Return an interface to the window base class so that the tbf base class
can access the common window methods, such as set_ws(). It will be used
in next commit to get rid of duplicated function enable_egprs in both
dl_tbf and ul_tbf subclasses.
The user of the function can then decide to access more specific
functionaltiites of the window class by static casting it to the
specific direction (which is known by the caller since it operates on a
ul_tbf or a dl_tbf).
Change-Id: Ia2e1decf91be1184668e28297c2126affb9c7ae4
This is a left-over from an earlier version of [1] that makes
Coverity think that there can be NULL pointer dereference,
even despite we assert(pdch != NULL).
[1] I8adc0cdb1b05a87b4df5d4bc196f6d381283a06f
Change-Id: I3490c38e0c1186dfd2fae63526a05c694547cebb
Fixes: CID#214230
The following test cases verify coding of the hopping parameters:
+ (RR) Immediate Assignment
- TC_pcuif_fh_imm_ass_ul_egprs,
- TC_pcuif_fh_imm_ass_ul,
- TC_pcuif_fh_imm_ass_dl,
+ (RLC/MAC) Packet Uplink/Downlink Assignment:
- TC_pcuif_fh_pkt_ass_ul,
- TC_pcuif_fh_pkt_ass_dl,
all of them pass with this (and the upcoming) change applied.
Change-Id: I8adc0cdb1b05a87b4df5d4bc196f6d381283a06f
Related: SYS#4868, OS#4547
It's quite odd to see that in write_packet_downlink_assignment()
we initialize an 'RlcMacDownlink_t', so then the caller can use
the power of CSN.1 codec to generate the final sequence of bytes
to be transmitted, while in write_packet_uplink_assignment() we
already compose the final RLC/MAC message straight away using
the low-level bitvec API (like bitvec_write_field()).
I guess the reason is that at the time of writing this code, the
CSN.1 codec was not stable enough, so it was safer to generate
the message 'by hand'. This would also explain why we *decode*
the final RLC/MAC message in create_ul_ass() right after encoding.
Rewrite write_packet_uplink_assignment(), so now it initializes
a caller-provided 'RlcMacDownlink_t' structure. Given that it's
allocated on heap using talloc_zero(), do not initialize presence
indicators of fields that are not present in the message.
This would facilitate handling of frequency hopping parameters
in the upcoming changes, in particular we can now introduce a
function that would compose Frequency Parameters IE for both
write_packet_{downlink,uplink}_assignment().
Tested manually by running a GPRS-enabled network, as well as by
running test cases from ttcn3-pcu-test => no regressions observed.
Change-Id: I2850b91e0043cdca8ae7498a5fc727eeedd029b6
Related: SYS#4868, OS#4547
In order to be able to encode frequency hopping parameters, let's
pass a const pointer to 'gprs_rlcmac_pdch' (PDCH slot) directly,
instead of passing all related parameters separately.
Change-Id: I6bccad508f0fdccc4a763211008dd847a9111a8d
Related: SYS#4868, OS#4547
According to 3GPP TS 44.060, section 12.12 "Packet Timing Advance",
the 'TIMING_ADVANCE_VALUE' field is optional, and takes 6 bits
if present. This means that a value that fits in range 0..63
(inclusive) can be encoded (0b111111 == 63).
It's possible that tbf->ta() returns GSM48_TA_INVALID == 220,
so the bitvec API would encode only 6 LSBs of it:
220 & 0b111111 == 28
Let's ensure that the 'TIMING_ADVANCE_VALUE' is present iff
tbf->ta() returns a correct (0 <= x <= 63), and absent otherwise.
Change-Id: I342288ea4ef1e218e5744e9be6a8e528d4e697fa
In get_paging_mi(), before this, an encoded buffer of Mobile Identity bytes is
returned. Code paths following this repeatedly decode the Mobile Identity
bytes, e.g. for logging. Also, in get_paging_mi(), since the TMSI is read in
from a different encoding than a typical Mobile Identity IE, the TMSI was
manually encoded into a typical Mobile Identity IE. This is essentially a code
dup of osmo_mobile_identity_encode(). Stop this madness.
Instead, in get_paging_mi(), return a decoded struct osmo_mobile_identity. Code
paths after this use the struct osmo_mobile_identity directly without repeated
decoding.
At the point of finally needing an encoded Mobile Identity IE (in
Encoding::write_paging_request()), do a proper osmo_mobile_identity_encode().
Since this may return errors, add an rc check for the caller of
write_paging_request(), gprs_rlcmac_paging_request().
A side effect is stricter validation of the Mobile Identity passing through the
Paging code path. Before, invalid MI might have passed through unnoticed.
Change-Id: Iad845acb0096b75dc453105c9c16b2252879b4ca
This is not something that should normally happen. If it happens,
then it's definitely a bug, and we should not tolerate it.
Change-Id: I6e46ba42650f0db2399649b536a1d2b3f0fcbf04
According to 3GPP TS 44.018 sec 10.5.2.40, Timing Advance value is 8 bit
and range is 0-63 (0-219 on GSM400). Unsigned value (uint8_t) is used
everywhere else, so avoid using a signed one here, and simply check for
GSM48_TA_INVALID here, which we use everywhere else to initialize when the
value is not known. Ideally we should check for value based on band, but
it makes more sense to check that when receiving the data and storing in
in set_ta().
Change-Id: I82b13561d0fe5ebafb5c3a8b9a501045c29809bc
We have same kind of object splitted into two layers, in coding_scheme
and gprs_coding_scheme. Let's merge them together and get rid of the
class, which is not really useful because it's only a set of functions
operating on one enum value.
This change also fixes gcc 10.1.0 error about memseting a complex type
in rlc.h init().
Change-Id: Ie9ce2144ba9e8dbba9704d4e0000a2929e3e41df
This is rather a cosmetic change aimed to make ASAN / Coverity happy.
In general, we never pass any input from an untrusted source.
Change-Id: I26d654da4c3bf5fd86a298c3027fd9820c932308
P-TMSI is optional IE, but IE is mandatory and hence always available.
Since the encoding is actually a Mobile Identity, the IMSI is used in
case P-TMSI is not available.
Change-Id: I4dbf8db04e81f98352a42ce34a5d91326be9bfd1
In most cases the length field was present and this field takes 7
bits of the maximum available 110 rest bits.
The length field was only removed when encoding huge bitmaps usually
only happen on lossy connections with packet lost.
However the cases without length field were encoded incorrect,
because all remaining bits must be used by the uncompressed bitmaps,
but the PCU violates this by encoding always the "release 5" bit.
Rather than fixing the encoding without length field, simply remove it
and always encode with length field. This also reduces the code
complexity.
Change-Id: I7bc2e18d647b72b8f17ba7a5c9c5e421d88275fb
The ESN, SSN and uncompress bitmap len are uint16_t. The Window is using uint16_t in
function arguments and return values. Don't do so many integer conversions.
Change-Id: If62fa09d7bfa8e91ce707824f7019edb1b83da9e
The last bits of the CRBB (compressed receive block bitmap) was incorrect
encoded when the CRBB is not byte aligned.
Related: OS#3728
Change-Id: I7261aa71b37d7ead52992f8db462f72a3804988e
Write initial bits of 3GPP TS 44.018 §10.5.2.16 IA Rest Octets the same
way as write_ia_rest_*() routines do.
This should also fix the issue addressed in
I75dd5bebc74eea85edf9582607c774d0bba0d2a6 initially by properly encoding
L/H bits.
Change-Id: I7ed5270bf95c3f6e9e026ff447eef8539f6f0314
Write TAI (if available) when generating Rest Octets for UL
Assignment. This should not affect actual PCU behavior because TAI is
not yet supported by upper layers but we have to adjust corresponding
tests anyway.
That's updated version of reverted commit.
Change-Id: I69407793bdb863be5fc42adadf75842d22f27335
Related: OS#3014
Use bitvec_set_*() directly without external write pointer tracking to
simplify the code. This is part of IA Rest Octets (3GPP TS 44.018
§10.5.2.16) which is the last part of the message so it should not
interfere with the rest of encoding functions.
The difference in the expected test output is due to proper handling of
TAI which should not be transmitted for SBA according to the Note in
Table 10.5.2.16.1 in 3GPP TS 44.018.
The change was manually tested against real mobile phone using options
'gprs mode gprs' in osmo-bsc.cfg and 'two-phase-access' in osmo-pcu.cfg
to make sure appropriate code path is actually triggered.
That's partially based on reverted commit 93d947f5e8.
Change-Id: I97d53c27c1ca9e032d431b3aa7f915027d63ddc0
Related: OS#3014
Use bitvec_set_*() directly without external write pointer tracking to
simplify the code. This is part of IA Rest Octets (3GPP TS 44.018
§10.5.2.16) which is the last part of the message so it should not
interfere with the rest of encoding functions.
That's partially based on reverted commit 93d947f5e8.
Change-Id: Ibe294b26ac374b9264a734db9663cacc105a4474
Related: OS#3014
Previously result of ".to_num() - 1" was used without any checks which
means that in case of to_num() returning zero we would effectively try
to encode (uint8_t)(-1).
Let's fix this by using proper mcs_chan_code() function which returns
Channel Coding Command for MCS without the need to further correct it
and adjust expected tests output accordingly.
Change-Id: I868062a81fffe6714a811c032215f25a79259905
In preparation for Channel Coding Command encoder in follow-up patches
let's add necessary helpers. Those are similar to previously used
helpers from GprsCodingScheme class but without CamelCase and with less
typo chances between Gprs and Egprs cases.
Change-Id: I6699cbc8d7ae766fa4d2b3d37e5f9ff1cf158b7e
The TAI is described as { 0 | 1 < TIMING_ADVANCE_INDEX : bit (4) > } in
3GPP TS 44.018 §10.5.2.16.1 so it should be encoded with if-else.
Change-Id: I54482790e1cf3cb13a635a99a481250576deabaf
Move functions which compute number of blocks or bits depending on
header type and corresponding enum outside of GprsCodingScheme
class. This will allows us to use standard libosmocore value_sting
functions in upcoming patches for IA Rest Octet encoding/decoding.
Change-Id: Id0873f85e1f16a72e17e7fbc4ad76b194917067f
Use bitvec_set_*() directly without external write pointer tracking to
simplify the code. This is part of IA Rest Octets (3GPP TS 44.018
§10.5.2.16) which is the last part of the message so it should not
interfere with the rest of encoding functions.
That's partially based on reverted commit 529ce88545.
Change-Id: I143b3dd02aa54b9ce206d9e780a5554f6d9fd118
Related: OS#3014
Use bitvec_set_*() directly without external write pointer tracking to
simplify the code. This is part of IA Rest Octets (3GPP TS 44.018
§10.5.2.16) which is the last part of the message so it should not
interfere with the rest of encoding functions.
That's partially based on reverted commit 529ce88545.
Change-Id: I19cc4226e7e831e7d7f70212b2078f5589a87ff0
Related: OS#3014
Use bitvec_set_*() directly without external write pointer tracking to
simplify the code. This is part of IA Rest Octets (3GPP TS 44.018
§10.5.2.16) which is the last part of the message so it should not
interfere with the rest of encoding functions.
That's updated version of commit with the same topic reverted earlier.
Change-Id: Ie180733d2584ebb16fb80b84526d0dbc70e3d441
Related: OS#3014
In preparation for upcoming patches with 11 bit RACH and TA support,
let's restructure existing encoders to simplify further modifications:
* move consistency checks to top-level Imm. Ass. encoder
* use consistent formatting
* constify pointers where appropriate
* split SBA and MBA encoders into separate functions
Those changes also make it obvious which parameters are necessary for
Rest Octets in each specific case (DL, UL-SBA, UL-MBA, UL-SBA-EGPRS,
UL-MBA-EGPRS).
There're no functional code changes so there's no need to adjust tests.
Change-Id: I0ad1bc786c3a8055ea9666f64ae82c512bd01603
Related: OS#1548
Add pointers to relevant parts of the spec. Tweak comments to be
more specific about the values being written and abbreviations used.
Change-Id: Ia5bf3f7f8846198b7b4e25ff1accf6206764be74
This reverts commit 529ce88545,
I2139fb347b3290621bbc3f6a031f7f213d372e65.
Commit I52ec9b07413daabba8cd5f1fba5c7b3af6a33389 /
896574e92b was found (empirically) to be a
regression, rendering GPRS service fatally unreliable.
This reverted commit seems to be related to the regression and is reverted
along with it.
Related: OS#3013
Change-Id: I3e8cc0e8ba3ba5bd444124fd4cb95ef92a71fdfb
This reverts commit 896574e92b,
I52ec9b07413daabba8cd5f1fba5c7b3af6a33389.
This commit was found (empirically) to be a regression, rendering GPRS service
fatally unreliable.
Related: OS#3013
Change-Id: Idcba0381f70eb7f7c9aefdee9dfeafd5de96a9be
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr