The following bitstring in TITAN:
0 N // N = NF - 1
-------------------->
0001 1011 1110 0100 // '0001101111100100'B
needs to be be encoded as follows 'on the wire':
N 0 // N = NF - 1
<--------------------
0010 0111 1101 1000 // '0010011111011000'B
so it basically gets inversed => we need to use BYTEORDER(first).
Change-Id: Iea2e3a9a7a0557d1ab5d935877d2161ee0988077
Fixes: I70b1baf01859d0cf3b8cec1aed04d73fc097a9b1
Related: SYS#4868, OS#4547
- Length of field 'MA_BITMAP' is specified in bits, not bytes;
- The value range of field MA_LENGTH is 0..63, therefore:
- value 0 means that field 'MA_BITMAP' is 1 bit long,
- value 1 means that field 'MA_BITMAP' is 2 bits long,
- value 63 means that field 'MA_BITMAP' is 64 bits long.
Change-Id: Iec19da18637febfa15bc09175bc51504c721c42f
Related: SYS#4868, OS#4547
According to 3GPP TS 44.060, table 12.10a.2, given that the number
of bit positions in MA_BITMAP equals NF, the first bit position
in MA_BITMAP corresponds to ARFCN_INDEX = NF-1, the last position
corresponds to ARFCN_INDEX = 0.
To put differently, the following bitstring in TITAN:
0 N // N = NF - 1
-------------------->
0001 1011 1110 0100 // '0001101111100100'B
needs to be be encoded as follows 'on the wire':
N 0 // N = NF - 1
<--------------------
0010 0111 1101 1000 // '0010011111011000'B
so it basically gets inversed. Let's add both BYTEORDER and
BITORDER attributes to achieve that.
Change-Id: I8f2c8c7b234605523a4fd518210b45ea3c088ff6
Related: SYS#4868, OS#4547
When changing the PCUIF, we have to maintain backwards compatibility
with the release versions of both osmo-pcu and osmo-bts, not only
with the recent master. In order to achieve that, let's introduce
'mp_pcuif_version', so the PCUIF version can be adjusted.
Change-Id: I3cf7f908e606b91dd2cbddc168827dd074aed052
Related: SYS#4868, OS#4547
They're going to be used in other modules too, not only in BTS_Tests.
Also, take a chance to rearrange the list of arguments, so the ones
with default values are placed after mandatory ones.
Change-Id: Ia33ebf2e680f16f774a981fc33422dfe5036637f
Some types of System Information (mostly the Rest Octets) are not
fully implemented, so calling the generic dec_SystemInformation()
may result in a DTE. Let's add dec_SystemInformationSafeBT() with
"prototype(backtrack)", so it would return a non-zero integer if
decoding fails. Let's add a wrapper dec_SystemInformationSafe()
that would additionally check the RR Protocol Discriminator.
Change-Id: Id4d73e0f3347e1d4c4c77aec75b767311d662292
Related: OS#4662
Add more EUTRAN ARFCNs, reaching the maximum allowed amount.
Add tests with 12, 23, 42 EARFCNs, just for the sake of testing some arbitrary
numbers.
Add tests with 32 and 33 EARFCNs because before osmo-bsc
Iabeed10053ee5899b4def3509aedd25abb2410a9, only 32 EARFCNs could be stored by
osmo-bsc.
Add a test with 48 EARFCNs to verify the maximum amount of EARFCNs and maximum
amount of SI2quater multiplexes works as expected.
Add a test with 49 EARFCNs to verify the VTY error response when adding too
many EARFCNs, and showing that osmo-bsc still sends 16 SI2quater with 48
EARFCNs.
Depends: Iabeed10053ee5899b4def3509aedd25abb2410a9 (osmo-bsc)
Change-Id: I99bf9b3381812d1db6fd0757f65995bae48da776
So far the naming is so that the EUTRAN_NeighborCell sounds like it reflects a
single E-ARFCN, while in fact it contains a list of E-ARFCNs. In 3GPP TS 48.018
it is more accurately named "Neighbor Cells", in plural.
There is another "list layer" that allows repeating these lists of E-ARFCNs,
which the spec names Repeated Neighbor Cells, i.e. have a list of (=repeat) the
lists of E-ARFCNs.
Repeated Neighbor Cells = {
// first cells list
Neighbor Cells = {
cell descriptions = {
{ e_arfcn = 1, meas_bw = 3 },
{ e_arfcn = 2, meas_bw = 3 },
{ e_arfcn = 3, meas_bw = 3 },
},
prio, thresh, ...
},
// second cells list
Neighbor Cells = {
cell descriptions = {
{ e_arfcn = 4, meas_bw = 3 },
{ e_arfcn = 5, meas_bw = 3 },
{ e_arfcn = 6, meas_bw = 3 },
},
prio, thresh, ...
},
...
}
Adjust the naming of the SI2quaterRestOctets members to more closely resemble
this structure, adopting the naming in 3GPP TS 48.018:
EUTRAN_NeighborCell -> EUTRAN_NeighborCells
because it is really a collection of multiple E-ARFCNs
EUTRAN_NeighborCells -> EUTRAN_RepeatedNeighborCells
because it is a list of E-ARFCN lists, and 3GPP TS 48.018 names it
"Repeated Neighbor Cells".
Also rename the EUTRAN_NotAllowedCells accordingly.
Change-Id: Ib11d72c04cdb8997ec97321257fb58b2c113e790
This is a very minimalistic (incomplete) implementation of SI2quater
Rest Octets as per 3GPP TS 44.018, table 10.5.2.33b.1. Should be
enough to decode some of the E-UTRAN specific parameters though.
Some BITn fields might need to be replaced with more specific
enumerated or integer types. Beware [1], the bit ordering rules
are different for integer and bitstring (sub-)types if a field
ends up on boundary of the two octets!
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562488
Change-Id: I6a12c9ee12f8df8b4fc0976dd593152dc1195718
Related: SYS#4870
At the time of writing Ief0d9b096feeee7d37b5f2429dd3e80de0161806 I wasn't aware
of the 'inout' keyword, which allows to pass the counter list by reference.
Rather modify the counter lists in-place. Instead of requiring
list := f_counter_name_vals_add(list, ...)
rather implement by directly modifying list:
f_counter_name_vals_add(list, ...)
Change-Id: I85ac56b042fe4bb1db392c1f451c8e900582cc2a
First user will be new MSC pooling tests in ttcn3-bsc-test, see
I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f.
Change-Id: Ief0d9b096feeee7d37b5f2429dd3e80de0161806
Since change [1] has been merged, we see multiple regressions in
ttcn3-bsc-test (all LCLS test cases) and ttcn3-bsc-test-sccplite
(sporadic failures). In all failed cases, the reason is similar:
RSL for unknown Dchan
BSC_Tests.ttcn:4501 BSC_Tests control part
BSC_Tests.ttcn:2176 TC_assignment_codec_fr testcase
The mentioned change enables TCP_NODELAY option for all IPA based
connections, including both OML and RSL. This option disables
Nagle's algorithm [2], so we get less delays on IPA based links.
It took me a lot of time to investigate, and finally, I figured
out what is actually causing those regressions. The TCP_NODELAY
itself is not a problem, of course. As it turned out, the
problem is here, in our TTCN-3 test case framework.
Each test case involves several components (actors) running in parallel.
One of them is RSL_Emulation_CT, which is responsible for handling and
routing of RSL messages between the connected components.
A test case may register dedicated channel handlers by calling
f_rslem_register(), so DCHAN/RLL/IPACCESS messages will be matched
by RslChannelNr/TrxNr and routed to the corresponding one.
If no handler is found for a given RSL message, the RSL_Emulation_CT
would abort the test case execution. And that's where the problem is.
Given that all components are running in parallel, it may happen
that a received RSL message would be processed by the RSL emulation
component faster than the test case would call f_rslem_register().
The test case would be aborted due to "RSL for unknown Dchan".
Speaking in context of the failing BSC test cases, a test case
calls f_rslem_register() on receipt of an Assignment Command as
it contains all the assignment parameters. After that we expect
to receive an RSL ip.access CRCX for that channel.
The problem is that both Assignment Command and ip.access CRCX
messages are sent by the BSC simultaneously, so the later may
be handled faster than the first one. Race condition!
Let's work this around by maintaining a waiting queue, where the
messages, for which no handler was found, will be kept until the
corresponding dedicated channel is registered.
This is an optional feature that needs to be enabled explicitly
by calling f_rslem_dchan_queue_enable(), and then explicitly
disabled by calling f_rslem_dchan_queue_disable().
If at the moment of calling f_rslem_dchan_queue_disable() the
waiting queue is not empty, e.g. because the IUT sent us more
messages than we expected, test execution will be terminated.
The actial fix for the LCLS test cases will be submitted next.
[1] Ia3d4c41bf0659e682f0b7ae5f3d58ed0f28edb58
[2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm
Change-Id: I25e10e28de174337233e6a3bb32cc16f2d7d614e
Related: OS#4619
The MSC pooling feature is implemented in osmo-bsc
Ifbdea197b26e88751a391c8a80c41f04e7d5e047.
A VTY command ('mscpool roundrobin next') that allows deterministic testing is
added in I2155d906505a26744966f442ffb1e87a6a9b494c.
osmo-bsc.cfg changes needed for these tests to succeed are in docker-playground
I1986e4ef43beee161c82193694421b56136c1afe
The new tests will fail until the above have been merged.
Change-Id: I21cbab193cd0de2e5692665442eae113d5f61904
Add BSSAP_N_UNITDATA_req to RAN_Conn_PT, so that we are able to send a Paging
from a test function that runs on MSC_ConnHdlr.
This will be needed by upcoming MSC pool tests, see
I21cbab193cd0de2e5692665442eae113d5f61904.
Change-Id: I36d486db05169b0fc3f19112b5a9008248d62930
For tr_RSL_PAGING_CMD, also check comp_ref against null.
Upon receiving a tr_RSL_PAGING_CMD, the code tries to dispatch the Paging
Command to all valid clients. However, the ConnectionTable[*].comp_ref is
*always* present, and actually null for unconnected clients.
So, before this patch, a Paging Command from osmo-bsc gets sent to a null
client, which disconnects the RSL emulation and aborts the test.
There is currently no test using this, but the upcoming MSC pool tests will:
see I21cbab193cd0de2e5692665442eae113d5f61904.
Change-Id: Iaf7730153a3a19e448a33298c3e12212a55929d5
Unlike the RSL_IE_MS_Power, where power_level is 5 bit long, in
the RSL_IE_BS_Power it's 4 bit long. Fix this.
Change-Id: Ic0cb2275ef585754b9ae5e3d8077ca652afd9365
f_gen_imei() calls f_enc_IMEI_L3() with a 14 digits argument, but the IMEI_L3
template used is hardcoded to 15 digits. So the oddevenIndicator must always
indicate odd, not depend on the digits argument.
f_gen_imei() should probably also compose a Luhn checksum, leaving that to
another patch.
Found by using the new osmo_mobile_identity API in osmo-msc, which is stricter
about odd/even and filler digits than our previous implementations.
See osmo-msc Idfc8e576e10756aeaacf5569f6178068313eb7ea .
Change-Id: Iaa9ba1214c4c15fd9620e68fe2e842fdf52912c0
Unfortunately, the latest release of osmo-bts still has a bug,
that has been fixed [1] in the recent master. Because of that,
most of the test cases in ttcn3-bts-test-latest currently fail.
The problem is that all transceivers use IPAC_PROTO_RSL_TRX0,
regardless of what the BSC tells them to use. Let's work this
around by patching IPA stream ID in ASP_RSL_Unitdata messages
coming from the IPA emulation.
[1] I5927f59a49724170a63e87be604973f7c9d5d8be
Change-Id: I66cecc9ea24ba79e1a03492e3fda2874951d37a0
- Get rid of f_L1CTL_DM_EST_REQ, it's not really needed.
- Derive ts_L1CTL_DM_EST_REQ_H0 from ts_L1CTL_DM_EST_REQ.
- Turn all its params into (value) templates.
- Turn it into a (value) template itself.
- Pass GsmArfcn directly to ts_L1CTL_DM_EST_REQ_H0.
Change-Id: I4f275e22d4309a23b4ed301a0779c4ecb92023a8
Related: OS#4546
Let's test the code path where UL TBF is requested through DL ACK/NACK
here, since we already test the usual UL TBF through CCCH approach in
most tests.
rlc_mode is changed to ACKED since that's the mode we are using so far
in tests.
Change-Id: I5a9a2e8107c87fdbf74cc2f09ae5eeafbb13ad55
Neels Hofmeyr
Vadim Yanitskiy
Pau Espin
Harald Welte