If test calls RTPEM_bind twice, the previous socket is kept open
(ConnId 1) while the new one is assigned to the the expected ConnId for
RTP/RTCP packets received (ConnId), however, if remote was already
sending packets, it may happen that the port still receives those with
ConnId=1, which may make test fail with message:
"Received unexpected type from RTP"
Change-Id: I73f4af4e590dd3958e3f4d1dba0496c0750d642d
My initial assumption was that we can skip redundant '0'B bits or
even '00'O octets in the Mobile Allocation IE, and thus reduce
the overall size of this element. Unfortunately, this is wrong.
3GPP TS 44.018, section 10.5.2.21 clearly states that the Mobile
Allocation IE contains a bit-string of size NF, where NF is the
number of frequencies in the cell allocation. If NF % 8 != 0,
then '0'B padding bits must be appended to make it octet-aligned.
In other words, if the cell allocation contains let's say 13
frequencies, but a hopping timeslot makes use of only a small
fraction of it (e.g. 4 first channels), we would still need to
transmit at least 13 bits (+padding), including all redundant
bits and octets.
In RLC/MAC frames though it's not required to make the bit-string
octet aligned, so we need to send exactly NF bits without padding.
In order to achieve that:
a) add MA length field to INFO.ind (record PCUIF_InfoTrxTs);
b) ajust the existing test cases to use this field.
It's safe to merge this change as the related patches have not
been merged to osmo-pcu and osmo-bts yet.
Change-Id: I2709673c90a0cd7d76de9db8b8ad82ac59ca84a0
Related: SYS#4868, OS#4547
Otherwise TITAN would refuse to decode any messages:
Dynamic test case error: While RAW-decoding type
'@BSSAP_LE_Types.PDU_BSSAP_LE': Can not decode type
'@BSSAP_LE_Types.PDU_BSSAP_LE', because invalid message was received
Change-Id: I3db7e8784efd067ccf0bc7dbc234d9b4ff1c033c
Related: OS#4597
This way one can simply pass an IP addr in string format and return the
IE no matter the IP version.
Change-Id: I743dbb7c89e504762498b7f278c12e130352e5f0
Similar to [1], the existing implementation [2] is unfriendly
to use, so let's work this around by defining a minimalistic
implementation of (RR) Handover Command.
[1] If1a5244a688abed6e6de2bf3f6e19e0e28129ea5
[2] titan.ProtocolModules.MobileL3_v13.4.0
MobileL3_RRM_Types.PDU_RRM_HandoverCommand_NW_MS
Change-Id: I08e6d33a725f99e2c92f93153b2369c4c764c012
Related: SYS#4868, OS#4545
Unfortunately, the existing implementation [1] is somewhat
incomplete and unfriendly to build templates on:
- some fields holding integer numbers defined as BITx,
so we would have to do bit2int() / int2bit();
- some bit-map fields defined as octetstrings;
- some fields are not decoded at all (raw octetstrings).
Let's work this around by defining a minimalistic implementation
of (RR) Assignment Command with all mandatory and some optional
fields. Reuse some IEs directly from MobileL3_RRM_Types.
[1] titan.ProtocolModules.MobileL3_v13.4.0
MobileL3_RRM_Types.PDU_RRM_AssignmentCommand_NW_MS
Change-Id: If1a5244a688abed6e6de2bf3f6e19e0e28129ea5
Related: SYS#4868, OS#4545
Most likely, the second part of the condition was copy-pasted
from ra_is_ps(), where the specs. require that at least one
of the three LSB's shall be zero. This requirement does not
apply to emergency RA values in range '101xxxxx'B.
Change-Id: I4c923682edfeee9c6bf3aeeeb67438809a54109f
Those two modules are analogous to BSSAP/BSSMAP CodecPort and Emulation,
but for the Lb interface (BSC-SMLC) instead of the A interface.
Change-Id: I92fd91056731abb8d3c01560f80c01c6a48a6fc9
osmo-pcu.git 0052051c07af63da98137c9f8e3b3119642eb587 introduced a bug
(fixed in 1d68cdff928f32941aff36c70e4543203c283d15) where no MS could
GMM attach to the network, but no test showed the issue.
This couple test verifies both correct behavior and also ensures wrong
IMSI is detected and reported.
Related: OS#4729
Change-Id: I5072d80b7ed9945a6083cdf3254efb8b8f119c54
GSM_RR_Types.ttcn: In TTCN-3 module `GSM_RR_Types':
GSM_RR_Types.ttcn:957.2-983.2: In template definition `ts_IMM_ASS':
GSM_RR_Types.ttcn:957.2-983.2: While checking template restriction `value':
GSM_RR_Types.ttcn:146.14-16: warning: Inadequate restriction on the referenced template parameter `len', this may cause a dynamic test case error at runtime
GSM_RR_Types.ttcn:145.44-63: note: Referenced template parameter is here
Change-Id: I0d17102294430d23eb683e16d5ac66abe806f2c1
L3_Templates.ttcn: In TTCN-3 module `L3_Templates':
L3_Templates.ttcn:120.1-125.1: In template definition `tr_MI_IMSI':
L3_Templates.ttcn:122.25-124.2: In template for record field `oddEvenInd_identity':
L3_Templates.ttcn:123.11-28: In template for union field `imsi':
L3_Templates.ttcn:123.23-28: In actual parameter list of function `@L3_Templates.f_tr_MI_IMSI':
L3_Templates.ttcn:123.24-27: In parameter #1 for `digits':
L3_Templates.ttcn:123.24-27: warning: Inadequate restriction on the referenced template parameter `imsi', this may cause a dynamic test case error at runtime
L3_Templates.ttcn:120.37-59: note: Referenced template parameter is here
Change-Id: Ia6979dff7d3c58f8609ebe55de2550446c3f1781
L3_Templates.ttcn:1099.1-1108.1: In template definition `ts_ML3_MO_CC':
L3_Templates.ttcn:1099.53-1108.1: warning: Field `msgs' is missing from template for record type `@MobileL3_Types.PDU_ML3_MS_NW'
Change-Id: Id131274ae7832846df6c09cbe6763b9e147ef372
RAN_Emulation.ttcn: In TTCN-3 module `RAN_Emulation':
RAN_Emulation.ttcnpp:1294.1-1343.1: In function definition `ExpectedCreateCallback':
RAN_Emulation.ttcnpp:1309.4-1313.2: In else statement:
RAN_Emulation.ttcnpp:1312.3-12: warning: Control never reaches this statement
RAN_Emulation.ttcnpp:1342.2-11: warning: Control never reaches this statement
Change-Id: I4e7cc0a7e6bff5c5e569458548fa70e814bd200c
StatsD_Types.ttcn: In TTCN-3 module `StatsD_Types':
StatsD_Types.ttcn:51.1-55.1: In template definition `tr_StatsDMetric':
StatsD_Types.ttcn:51.126-55.1: warning: Field `srate' is missing from template for record type `@StatsD_Types.StatsDMetric'
StatsD_Types.ttcn:57.1-61.1: In template definition `tr_StatsDMetricCounter':
StatsD_Types.ttcn:57.106-61.1: warning: Field `srate' is missing from template for record type `@StatsD_Types.StatsDMetric'
StatsD_Types.ttcn:63.1-67.1: In template definition `tr_StatsDMetricGauge':
StatsD_Types.ttcn:63.104-67.1: warning: Field `srate' is missing from template for record type `@StatsD_Types.StatsDMetric'
Change-Id: I6d3b40dc719b42481dacb5599eb7eeb3be0426b4
RSL_Emulation.ttcn: In TTCN-3 module `RSL_Emulation':
RSL_Emulation.ttcn:478.1-713.1: In function definition `main':
RSL_Emulation.ttcn:500.2-712.2: In while statement:
RSL_Emulation.ttcn:501.3-711.3: In alt construct:
RSL_Emulation.ttcn:695.4-28: In function instance:
RSL_Emulation.ttcn:725.9-744.1: In function definition `f_WaitingQueue_dispatch':
RSL_Emulation.ttcn:729.2-740.2: In for statement:
RSL_Emulation.ttcn:732.3-736.3: In if statement:
RSL_Emulation.ttcn:735.4-8: warning: Control never reaches this statement
Change-Id: I1e080a8543a9f26b45b345e47881b6f6d4c9b362
CBSP_Templates.ttcn:385.1-401.1: In function definition `ts_CBSP_REPLACE_CBS_COMPL':
CBSP_Templates.ttcn:396.2-398.2: In if statement:
CBSP_Templates.ttcn:397.3-50: In variable assignment:
CBSP_Templates.ttcn:397.40-50: In actual parameter list of template `@CBSP_Templates.ts_CbspCellList':
CBSP_Templates.ttcn:397.41-49: In parameter #1 for `list':
CBSP_Templates.ttcn:397.41-49: warning: Inadequate restriction on the referenced template parameter `cell_list', this may cause a dynamic test case error at runtime
CBSP_Templates.ttcn:387.8-68: note: Referenced template parameter is here
Change-Id: I54c21d17ab3235ec37d5f07867d8c6c83d699088
BSSMAP_Templates.ttcn: In TTCN-3 module `BSSMAP_Templates':
BSSMAP_Templates.ttcn:181.1-192.1: In template definition `ts_BSSMAP_Reset':
BSSMAP_Templates.ttcn:181.1-192.1: While checking template restriction `value':
BSSMAP_Templates.ttcn:188.21-54: warning: Inadequate restriction on the referenced function `f_enc_osmux_support(osmux_enabled)', this may cause a dynamic test case error at runtime
BSSMAP_Templates.ttcn:174.9-179.1: note: Referenced function is here
BSSMAP_Templates.ttcn:207.1-217.1: In template definition `ts_BSSMAP_ResetAck':
BSSMAP_Templates.ttcn:207.1-217.1: While checking template restriction `value':
BSSMAP_Templates.ttcn:213.21-54: warning: Inadequate restriction on the referenced function `f_enc_osmux_support(osmux_enabled)', this may cause a dynamic test case error at runtime
BSSMAP_Templates.ttcn:174.9-179.1: note: Referenced function is here
Change-Id: I947e1a6aeb1fe40167eb268906906edd7e857232
Keep a local next_idx so that lengthof() doesn't fail after adding a '*' entry.
Fixes this error in BSC_Tests_CBSP.TC_cbsp_write_then_kill:
Dynamic test case error: Performing lengthof() operation on a template of type @CBSP_Types.CBSP_IEs with no exact length.
Change-Id: I4d95a8ca311f145fa5ea371b6aed099db771d7b8
Invoke Clear Command with various Cause codes and verify that the RR Channel
Release reflects them.
Depends: I734cc55c501d61bbdadee81a223b26f9df57f959 (osmo-bsc)
Change-Id: Ie6c99f28b610a67f2d59ec00b3541940e882251b
Add a DCHAN and release to recently added SI2quater tests (because these tests
already configure various amounts of EARFCNs in osmo-bsc).
Verify that the RR Channel Release for CSFB contains all configured EARFCNs.
In GSM_RR_Types.ttcn, add coding for "Cell selection indicator after release of
all TCH and SDCCH IE".
In f_expect_chan_rel(), add optional arg csfb_expect_cells, and, if present,
decode the RR Channel Release message's L3 part, and in turn the Cell Selection
Indicator Value contained. Match against csfb_expect_cells.
In f_tc_si2quater_n_earfcns(), also compose a list of EARFCNs as found in the
RR Channel Release, and pass to f_expect_chan_rel().
Depends: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab (osmo-bsc)
Change-Id: I882c5e1f70bcc4833fc837a95c900ce291919cc5
During patch grooming of the previous fixup, one patch line went missing, which
breaks the ttcn3-bsc-test-latest completely. Add that change now.
Change-Id: I75295d638072df9f5213a7e74e4a960c009c2865
In f_vty_wait_for_prompt(), this:
testcase.stop(fail, "VTY: Unknown Command")
outputs:
failVTY: Unknown Command
The first stop() argument 'fail' is not actually a test verdict, but gets
rolled into a log output string, becoming "failVTY".
Fix that by simply using the normal pattern of setverdict() followed by
mtc.stop().
Change-Id: Id09986444de02c10b4fba582d454d54568b6e8a2
For the VTY "Unknown Command" code path, we must actually call 'repeat', to
avoid racey VTY behavior from cruft stuck in the VTY pipe.
The missing 'repeat' caused massive random fallout in the 'latest' builds,
which often hits the 'Unknown Command' code path; fixed by this patch.
Change-Id: Ibd5adb359b3fb302e2c70700d911878aef605ff3
When a new test uses a VTY configuration that may not yet be available in the
'latest' build, it can be useful to ignore the "Unknown VTY Command" error.
To be used by f_init() for multiple MSCs, setting a default 'allow-attach' flag
per MSC implicitly -- such vty config is not yet supported in the latest build.
Change-Id: I284c42e10c0cb282c8410db87959b471867edef6
This change introduces new version 10 specific extensions, in
particular: the frequency hopping parameters of each timeslot.
These parameters are used to compose Channel Description IE
in the packet resource assignment messages.
In order to maintain backwards compatibility with version 9 of
the PCUIF, and thus to still be able to run test cases against
the latest release of osmo-pcu, I kept the old parts of the
INFO.ind and gruoped them together with the new records
into union 'PCUIF_InfoTrxs'.
During decoding, the content of this union is resolved by the
TITAN's RAW codec itself, depending on value of the 'version'
field. During the encoding, it's the responsibility of the
API user to set a proper field of the union. I implemented
both f_PCUIF_ver_INFO_{Trxs,PDCHMask} helpers for that.
Version 9 is kept as default, so this change can be merged
independently of the actual implementation. We can bump
it and remove the compatibility glue once the new versions
of both osmo-bts and osmo-pcu are released.
Change-Id: Idf11bc4ba3ff0b00b32f2beab8fd020c67119d05
Related: SYS#4868, OS#4547
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
Pau Espin
Vadim Yanitskiy
Alexander Couzens
Harald Welte
Daniel Willmann