The testcase TC_emerg_premption does not set a verdict when done. Make
sure that the verdict is set to pass when the test is done.
Change-Id: Ie612b32cfa9cedd1e0f1d51e48911da94ec325cf
Related: OS#4549
the respective changes we had have long been merged upstream, so
let's switch back from our own forks to upstream
Change-Id: I52bdac20745bc3f5ce618ea804686781483a6f4c
There is no reason whatsoevery why a L3_Templates.ttcn file should
ever include types from RLC/MAC. This creates a dependency nightmare.
The type for which ts_RaCapRec is written (MSRACapabilityValuesRecord)
originates from titan.ProtocolModules.MobileL3 so it's completely
unclear how any of that ever related too RLC/MAC.
Change-Id: Ie1ccef090ad51e26ccae17998e4294c6e27cf9c8
This in turn means Osmocom_Gb_Types doesn't need to depend on
GSM_RR_Types anymore, which is particularly ugly as the latter
now depends on RLCMAC_*, creating a long chain of dependencies.
Change-Id: I8c8da7709695ff0023f71b3999291e2515b22e46
osmo-bsc is using the same LTE neighbors of the SI2quater in the Channel Release -
Cell selection indicator after release of all TCH and SDCCH IE. Ensure the same measurement bandwidth
is present to not overwrite the measurements bandwidth from the SI2quater.
Change-Id: I9aa30dfd1e2c1b80e037bd71ebc4cdd3752638b4
This scenario appeared in jenkins runs of BSC_Tests making
TC_ctrl_msc_connection_status fail (the first test in the suite). I
could however not reproduce it on my local docker setup because it
really seems like a timing race condition.
The scenario is:
TTCN3 -> BSC: RESET
TTCN3 <- BSC: RESET
TTCN3 -> BSC: RESET-ACK
In there, TTCN3's f_legacy_bssap_reset() expected a RESET-ACK to be
received, but it may well be that the other end never saw the RESET and
hence it will never sent the RESET-ACK, since it indicated it became
available afterwards. In that case (RESET received), let's not fail if a
RESET-ACK is never received, since the connection is actually in the
desired state and this scenario can happen and it's all fine.
Change-Id: Ic92e0fb7033e5134b66e485a11371394adaba78a
These tests verify that osmo-mgw handles requests no matter of IP
version used in the remote address.
Change-Id: Ib134dda5a8f7c8f50968b6ce330f9986ae72575d
Send the remote address to MGW so it knows which IP version to return
during CRCX ACK. This actually better suits the test, since there's less
point in checking whether we receive something if we never pass the
IP/port to MGW. In any case, the "recvonly" should still tell MGW to
refrain from sending stuff to us, so we are really testing that here.
Change-Id: Id3452cecf7fb281e5e46471f7f53983c08c6bfdf
rtpem should be set to BIDIR at the same time where MDCX "sendrecv" is
sent, otherwise if MGW sends us RTP packets (because we set the conn to
sendrecv) they will be counted incorrectly in
stats[0].num_pkts_rx_err_disabled.
This issue doesn't trigger in current code because the MGW doesn't know
anyway the remote IP address of the other connection until an MDCX is
sent to it. However, if for whatever reason the IP address is known (for
instance because it is set during CRCX, which will be done in next
commits), then RTP messages would be sent and the error counter would
be > 0.
Change-Id: I8f2c4e497e522fc17e5cfe76987f802265c486ab
rtpem should be set to BIDIR at the same time where MDCX "sendrecv" is
sent, otherwise if MGW sends us RTP packets (because we set the conn to
sendrecv) they will be counted incorrectly in
stats[0].num_pkts_rx_err_disabled.
This issue doesn't trigger in current code because the MGW doesn't know
anyway the remote IP address of the other connection until an MDCX is
sent to it. However, if for whatever reason the IP address is known (for
instance because it is set during CRCX, which will be done in next
commits), then RTP messages would be sent and the error counter would
be > 0.
Change-Id: I653eb75439321f9a488dc56dca5d3fc5a8811547
This will be needed once IPv4+IPv6 support is used, since we want to set
the remote IP addr in CRCX for convinience to get an IP adr from ther
same family during CRCX, while still allowing for testing Osmux CID
wildcard value.
Change-Id: I3abd80b1c0053004aab3d03e09fada1129a59765
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
It tests IPv6 Transport Address are passed correctly through BSSAP, and
forwards handles them correctly as an MGCP client too.
Change-Id: Id616926dd4a9febc4268eea2ee1e377b2d22753a
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 TC_fh_params_assignment_cmd, this test case verifies
presence and correctness of the hopping parameters in the following
messages and their IEs:
1. (RR) Handover Command
1.1. Description of the First Channel, after time IE
1.2. Cell Channel Description IE (presence)
1.3. Mobile Allocation, after time IE
The hopping parameters are randomly generated and configured
via the VTY interface in the beginning, and unset in the end.
Since the C0/TS0 (BCCH+SDCCH4+CBCH) shall not be hopping, let's
temporarily re-configure TS0 as BCCH, and TS1 as SDCCH8 on TRX0
of BTS1 (handover tagret).
Change-Id: I0ddea535dce7e5558793be5cddaad0ab46e978ec
Related: SYS#4868, OS#4545
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.
Change-Id: Ia79efc9aa07b5088913d6679715f351d30f48d13
Related: SYS#4868, OS#4545
Change [1] introduced a regression that caused some TC_cbsp_*
test cases to fail. The problem is that TC_fh_params_si4_cbch
re-configures TS0 as CCCH+SDCCH4 instead of CCCH+SDCCH4+CBCH,
so the CBCH channel vanishes after this test case is executed.
[1] Ibc3b73697a1d2c8dbb27274e48f5e5ba21fdd540
Change-Id: Ia249f10c1b768a5af2b6c92ecba5d2941528f876
Related: SYS#4868, OS#4545
The ALIVE PDU does not have to be sent before an UNBLOCK message.
Ignore UNBLOCK messages in cases a single ALIVE is expected.
According to TS 48.016 v5.2.0, 7.4:
"Upon successful completion of an NS-VC reset procedure,
a BSS (or SGSN) shall start timer Tns-test, then [..]"
The ALIVE should arive Tns-test after the reset procedure (typ. 1s-60s).
Change-Id: I11d77b7477981998082967e5123b61636af2b980
Make it possible to call them from a testcase / function
running on any kind of component, not only on MSC_ConnHdlr.
Change-Id: Ifbcc24c5a0299ba43a998ccbdd0f77bc109c6935
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
This test case verifies presence and correctness of the hopping
parameters in (RR) System Information Type 4 (CBCH description).
Since the C0/TS0 (BCCH+SDCCH4+CBCH) shall not be hopping, let's
temporarily re-configure TS0 as BCCH, and TS1 as SDCCH8+CBCH.
According to 3GPP TS 44.018, section 9.1.36.1, if CBCH is active
in the cell, the CBCH Channel Description IE indicates where to
find it (physical channel description).
According to section 9.1.36.2, the CBCH Mobile Allocation IE shall
be included if CBCH Channel Description IE indicates that frequency
hopping is in use.
Change-Id: Ibc3b73697a1d2c8dbb27274e48f5e5ba21fdd540
Related: SYS#4868, OS#4545
This test case verifies presence and correctness of the hopping
parameters in the following messages and their IEs:
1. (RR) Assignment Command
1.1. Description of the First Channel, after time IE
1.2. Mobile Allocation, after time IE
Change-Id: Id12509385b444c426f4af7a0cf0d46efe2cb0eda
Related: SYS#4868, OS#4545
This test case verifies presence and correctness of the hopping
parameters in the following messages and their IEs:
1. RSL CHANnel ACTIVation
1.1. Channel Identification IE
2. RSL IMMEDIATE ASSIGN COMMAND
2.1. Channel Description IE
2.2. Mobile Allocation IE
The hopping parameters are randomly generated and configured
via the VTY interface in the beginning, and unset in the end.
Change-Id: Ib9218b61a2b0c0467340656e4b65a36b7b0ba302
Related: SYS#4868, OS#4545
Vadim Yanitskiy
Philipp Maier
Harald Welte
Alexander Couzens
Pau Espin