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
Finally, we can get rid of hard-coded octetstrings and control
every field of the Rest Octets we're sending to the IUT.
Note that template 'ts_SI4_default' did not contain any Rest
Octets at all, thus the GPRS indicator was (and still is)
absent. This will be fixed in a follow up change.
Change-Id: I0a95b34b495267edf1f48692e24fcd5ede8ccdd1
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Optional "Rest Octets S" part is left for later.
Change-Id: Ib0814e79f8627f3e2b4746b7e521e06ff82bf2d7
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Neels Hofmeyr
Vadim Yanitskiy