The dependency of PCUIF_Types creates also a dependency on
Replace the PCU_AddrType by an unix like address family defined
in the Osmocom_Types to reduce the dependency.
Change-Id: I0b4fda96accef401ffc009010f9f5621583fd6dd
NS_Emulation_CT:NSCP used to be a NS_CODEC_PT, which is a translation
port on top of the IPL4asp. Such ports need to be mapped to a system
port at start-up.
However, in I4d0b7ad0ed9447a038dd3eeee2b975146d10fba0 we introduced
a new underlying component called NS_Provider. Hence, NSCP is actually
connected to that underlying component, and no longer mapped.
The corresponding change in pcu/SGSN_Components.ttcn and sgsn/SGSN_Tests.ttcn
has unfortunately been missed in the above-mentioned change. Fix that.
Change-Id: I4c085210e6021e38a38ebc052ec3d9b345638cd2
Pass transceiver number to f_resolve_fh_params(), otherwise the
hopping parameters would always be generated for TRX#0, and thus
the expectations for TRX#N > 0 would be wrong.
Change-Id: If1a25f5ff1b1bca900d54cc56e2045df5a81f4e2
Fixes: I9bb164fd2c7c48b91e0d7bd1abaf3cfec155342c
Related: SYS#4868, OS#4547
The bit-mask in fhp.ma_map.ma is octet-aligned, so we cannot use
its length. Use the number of transceivers instead, since they
all belong to the same BTS.
Change-Id: I772d13841babd2856b6b2fcf126ba47fb20b055a
Fixes: Ibebbedecaed0a3f24a1bc7b520013fa563c4bbda
Related: SYS#4868, OS#4547
This is a step to prepare the NS_Emulation for operating on top of
Frame Relay, not just UDP/IP. We replace the NS_CodecPort (mapping to
a IPL4asp) with a newly introduced NS_Provider_CT, specifically a
NS_Provider_IPL4_CT.
This change removes any IP specific bits from NS_Emulation and moves
it into the newly-created NS_ProvideR_IPL4.
Change-Id: I4d0b7ad0ed9447a038dd3eeee2b975146d10fba0
Unlike osmo-pcu, osmo-bts does check length of the messages received
over the PCU interface, so I7a532d7abff8af354e40c5d706bb882efc6f905f
caused all the related test cases in ttcn3-bts-test to fail.
Reverting it is not a solution, because we cannot maintain different
padding attributes for two different protocol versions. Let's add
a wrapper function that would call enc_PCUIF_Message() and append
padding depending on the configured protocol version. In addition,
let's add a module parameter that would allow us to (optionally)
disable padding for ttcn3-pcu-test.
This change makes all broken PCUIF specific test cases pass.
Change-Id: Ica9e0c49c8b16e7d585a481670762c6433c61118
RAW_NS uses module parameter from SGSN_Components. To decouple
RAW_NS from SGSN_Component pass the cell_id via a function argument.
Change-Id: I91d9db85519675054aaab83c85fac43e67391f33
RAW_NS uses module parameter from SGSN_Components. To decouple
RAW_NS from SGSN_Component pass the NSConfiguration via f_init_ns_codec()
Change-Id: Ida8b8a6af815dc11b2ff4c65e19cc5ec25f18ae2
According to 3GPP TS 44.018, table 10.5.2.21.1 "Mobile Allocation
information element", in the cell allocation frequency list the
absolute RF channel numbers are placed in increasing order of ARFCN,
except that ARFCN 0, if included in the set, is put in the last
position in the list.
Let's verify that the IUT handles this corner case correctly.
Change-Id: I3afadfde03f6ea766c0756a181ef129e4b05c383
Related: SYS#4868, OS#4545
The Mobile Allocation IE generated by the IUT includes not only
the list of hopping ARFCNs, but also ARFCN of the transceiver
itself. This is the correct behaviour, and that's why we see
sporadic test case failures like this one:
Mobile Allocation IE does not match (tn := 1):
{ len := 3, ma := '001010101011111100000000'B }
vs expected
{ len := 2, ma := '0010101010111111'B }
The last '0'B bits may look like redundant padding, but actually
only 7 of them are. The MSB '0'B bit in the last (third) octet
corresponds to pre-configured ARFCN 871.
Since f_TC_fh_params_gen() generates all ARFCNs in GSM-900:
- in f_TC_fh_params_gen(), pick an ARFCN value from GSM-900;
- in f_TC_fh_params_set(), change ARFCN of a given transceiver;
- in f_TC_fh_params_gen_tr_ma(), consider that ARFCN;
- in f_TC_fh_params_unset(), bring it back to 871.
Change-Id: Id11be94087c18d8159af4b7988826023832f9944
Related: SYS#4868, OS#4545
This record must contain not only the hopping parameters, but
also ARFCN of the transceiver they belong to. Since ARFCN of
the transceiver also becomes part of the Mobile Allocation,
we need to take it into account in the matching functions.
Change-Id: I4722dc3f758a097806811cb0b59aa4093374c74c
Related: SYS#4868, OS#4545
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