The component architecture in PCU_Tests is quite complex to follow.
Update the diagram in order to make it easier for people to gasp the big
picture.
Change-Id: Ie592a9301b7a900334650741ed633cd70535a2b1
In ts_PCUIF_INFO_default we set the bts_model member to
PCU_IF_BTS_MODEL_UNSPEC. This means that the PCU will not know the BTS
model and thus it is not able to comply to the specific pecularities of
the BTS model that is used. In PCU_Tests.ttcn we simulate the behavior
of an OsmoBTS with OsmoTRX, therefore we should set the BTS model to
PCU_IF_BTS_MODEL_TRX.
This will also fix the problems we have with unexpected DUMMY messages
we currently receive since in an OsmoTRX based BTS model those frames
will be generated by OsmoTRX and do not appear on the PCUIF interface.
When the BTS model is left unspecified, then the PCU will generate those
DUMMY messages and irretate the testsuite.
Related: OS#6191
Change-Id: I6b516eece6acc96ebde9759bcb609197a245dd84
We have added an additional bts_model field to the PCUIF_info_ind. This
also means that we have to increment the PCUIF version number since
adding fields is a major change to the protocol. This patch updates the
related TTCN3 record and also increments the PCUIF version number.
Related: OS#6191
Depends: osmo-pcu.git I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
Change-Id: Ib1516e66c70f021adee49f41bd707803fc06f9cf
The tesctcase TC_pcuif_rach expects an immediate assignment message on
the AGCH but the template still uses the now deprecated (old v10 PCUIF)
SAPI PCU_IF_SAPI_AGCH. With PCUIF v.11 we must use PCU_IF_SAPI_AGCH_2
Related: OS#5927
Change-Id: Ie8b2e21e184282f70c92d6b9f716cfda1405ef4d
Whenever we send a ts_BSSGP_DL_UD via BSSGP and we expect the downlink
assignment on the paging channel by calling
f_ms_exp_dl_tbf_ass_ccch(ms), then we should make sure that
ts_BSSGP_IMSI actually contains an IMSI (paging group)
Related: OS#5927
Change-Id: I356d93edd03c7e7564bde88d34effcf1b1967621
When we send BSSGP DL UD, we should include an IMSI, since we are
expecting the paging request to appear on the PCH
Related: OS#5927
Change-Id: If62c2c7db9717cd08116374ee6ca939211bdf01e
In many of our tests we trigger a paging by the PCU by sending some data
through BSSGP. However, we often do this without putting an IMSI into
the ts_BSSGP_DL_UD template. The PCU then send the paging through the
AGCH because without IMSI no paging group can be calculated. The tests
still expect the paging to appear on the PCH and fail.
Let's fix this by adding an IMSI to the BSSGP request so that the PCU
knows the and the paging is sent through the PCU.
Change-Id: I7a70cc2a8af9d088071841861a8120afb9af86f9
We currently send a confirmation back when the SAPI was PCH. This is no
longer correct. We now have to check if the receiving end has actually
requested a confirmation.
Related: OS#5927
Change-Id: I339dfd0c057d957d2ace24fd6821e54c25fe8eb2
When receiving an IMSI from PCUIF (see type record PCUIF_pch), it is
represented as a null terminated string. The field is set to be 17
characters wide with a pdding of zeros at the end (as it ought to be
for a null terminated string). Unfortunately TTCN3 will not chop off
the trailing zeros, and also include them when the string length is
determined using lengthof(). This means we must take care of this
ourselves.
Let's use a regular expression to make sure any non numerical digits
are trimmed off before passing the IMSI string on to higher layers.
Related: OS#5927
Change-Id: I7bfea59a306e75211856e4e80985ebf000c42224
The function f_pcuif_rx_pch_pag_req1 tries to read the IMSI suffix from
the raw data that was exchanged on the PCUIF interface. This is no
longer the appropriate way in PCUIF v.11. There is now a dedicated imsi
member in type record BTS_CCCH_Block, which is used for that purpose.
Related: OS#5927
Change-Id: I0c7c6a31cbf7ed533e665728c157de0ac9e0fe8d
OsmoPCU has support for PCUIF v.11 for quite some time now. Let's
upgrade the testsuite as well.
Related: OS#5927
Change-Id: I6c4042f2224cd48aecc1b1499226f7d23caddd4f
Since osmo-bts 1.7.0 & osmo-pcu 1.3.0, which were just released
PCUIF v11 is supported, so use it by default.
Change-Id: I8e5f44fc1d613c12eaf984dff860ee6f05c2c171
The record BTS_CCCH_Block has an optional field "confirm". However, this
field is not marked as optional. Also f_BTS_CT_handler should make sure
that this field is populated with "omit" when it is not present.
Related: OS#5927
Change-Id: Ifcbb72c22b93855bed89f4970cf63bd2d6fcd128
When we receive a PCUIF_DATA_REQ, f_BTS_CT_handler will mangle the
incoming message for us. The resulting BTS_CCCH_Block that is sent up to
the component not only contains the PCUIF message, but will also have
the already parsed MAC block attached. This currently only works for
PCU_IF_SAPI_PCH and PCU_IF_SAPI_PCH_2 but not for PCU_IF_SAPI_AGCH_2.
Let's add compatibility for PCU_IF_SAPI_AGCH_2.
Related: OS#5927
Change-Id: Ife67bde444d957822a953391b80d01d49fff064b
In the recent PCUIF change of osmo-pcu (see Depends) a confirm flag
is added to struct gsm_pcu_if_pch. This flag tells the receiving end
(OsmoBSC or OsmoBTS) that the sending of the received MAC block has
to be confirmed towards the PCU. OsmoBTS and OsmoPCU now rely on the
conformation flag.
Let's update the BTS_and PCU testsuites accordingly.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I7017ca20ca7e0b77d0f363121e4f17280e39e8ac
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0
Related: OS#5927
Change-Id: I15e754ce3ceed92a517586a073d3e3ed008b5eef
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related record member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6
Change-Id: I1db29d5b1920e351c452b798c3260654c2cbe0cb
This allows shrinking some tests which wish to send specificaly crafter
LlcBlocks (since the way LlcBlocks are created for f_ms_tx_ul_data_block
only allows sending data related to the same upper LLC PDU)
Change-Id: I81176fa5c7caa2535bcc97eec26833579933ed7a
When we receive a PCUIF_DATA_REQ, f_BTS_CT_handler will mangle the
incoming message for us. The resulting BTS_CCCH_Block that is sent up to
the component not only contains the PCUIF message, but will also have
the already parsed MAC block attached. This currently only works for
PCU_IF_SAPI_PCH, but not for PCU_IF_SAPI_PCH_DT.
Let's add compatibility for PCU_IF_SAPI_PCH_DT.
Related: OS#5927
Change-Id: Ibaa6d170ef0f1f61b708a872a3c2364585063503
The function that assigns the downlink TBF f_ms_exp_dl_tbf_ass_ccch()
uses SAPI PCU_IF_SAPI_AGCH as default but actually downlink TBFs are
assigned via the PCH. This means we have to put PCU_IF_SAPI_PCH into the
parameter list on every function call, so it makes sense to change the
default to PCU_IF_SAPI_PCH and omit the SAPI when calling the function
Related: OS#5927
Change-Id: I49c59bad0162cb303669f6108201f154918b1db3
When the PacketCellChangeNotification proposes an UTRAN or E-UTRAN cell,
then the PCU will not provide system information. Instead it will directly
conclude the NACC procedure with a PacketCellChangeContinue message.
Related: OS#6044
Change-Id: Idae86a458fd44ac81bab183ed1865b1c1bdbfd66
The testcase TC_nacc_outbound_success tests the NACC procedure. The cell
that is proposed in the PacketCellChangeNotification is a GERAN cell.
This means that the PCU should conclude the procedure with a
PacketCellChangeNotification that contains the ARFCN and BSIC of the
proposed cell. Let's make sure that this actually is the case.
Related: OS#6044
Change-Id: I4b8f3312088e3d2bc4b90702485e7c6a8d39f954
Since osmo-pcu.git 95ec50c9e4821ed1bdd15e9e30da1278ec1280c1, OsmoPCU
doesn't allow receiving a FINAL_ACK in FLOW state. This test was not
written properly and was taking advantage of that permissive logic in
osmo-pcu to trigger the target use case. Fix it to have the PCU send the
last DL data block (FBI=1) so that it can send a PKT DL ACK/NACK with
FinalAck=1 to terminate the DL TBF.
Change-Id: Ibd445bdd5cc1d1ffd810eea157829403b4b65f1f
N3105 is used for DL TBFs only (as tested by TC_n3105_max_t3195). The
test TC_ul_tbf_reestablish_with_pkt_resource_req_n3105_max is hence
wrongly written and should be based on T3168. Since recently, osmo-pcu
also moved to using T3168 in the scenario triggered by this test, hence
move to using it.
Related: osmo-pcu.git Change-Id I87dff68dedd06b60501e7586d20faf02bb1f0c93
Change-Id: Ibdfa9879cc56f5e2090cee0d3d70ee5df7c90454
The TC_nacc_outbound_pkt_cell_chg_notif_dup is currently failing
because in [1] we changed the default hard-coded MCC/MNC values in
ts_BssgpCellIdDstAddr_default, however these it's still using
hardcoded MCC=023/MNC=43. I overlooked this in [2].
Let's split up the f_handle_nacc_rac_ci_query() into four functions:
* f_ctrl_rx_nacc_rac_ci_req() / f_ctrl_tx_nacc_rac_ci_rsp(),
* f_pcuif_rx_nacc_rac_ci_req() / f_pcuif_tx_nacc_rac_ci_rsp(),
and use them in TC_nacc_outbound_pkt_cell_chg_notif_dup. Also
employ them in TC_nacc_outbound_pkt_cell_chg_notif_twice.
Change-Id: I3e84f55eedd278fb239600d6a0465bd34fd8cd0b
Related: [1] 03f74d4132
Fixes: [2] 7295661af5
Related: OS#5901
This patch fixes TC_nacc_outbound_si_resolve_timeout, which is still
using old hard-coded MCC/MNC values. The altstep does the same, but
relies on the updated values from ts_BssgpCellIdDstAddr_default.
Change-Id: I9f6dbe97e9a494a4e8fdb441a70999d3040f6cfd
Related: OS#5901
There is no such country/operator with MCC=023/MNC=43. Wireshark
complains about that when looking at the BSSGP messahes:
Mobile Country Code (MCC): Unknown (23)
Mobile Network Code (MNC): Unknown (43)
This may look confusing, let's better use some real country/operator:
Mobile Country Code (MCC): Central African Rep. (623)
Mobile Network Code (MNC): Celca (Socatel) (03)
Change-Id: Idc22128657d10893aa5c6d8ec80538a764de5c42
Related: OS#5901
The enc_* functions usually return an octetstring. However, both
f_enc_BcdMccMnc[_int]() return a sub-type of hexstring (BcdMccMnc),
so let's rename them to avoid confusion.
A follow-up patch adds the actual encoding function for BcdMccMnc.
Change-Id: I0332fe7396310da49910e89571f7181fb1604182
This config is out of sync with the one in docker-playground.git.
The 'neighbor resolution' param makes osmo-pcu use the CTRL interface.
Change-Id: I8d59096644afd5a5278bc7bb1335670edad72576
Related: OS#5901
It can happen that the RLCMAC req arrives at osmo-pcu before the
CS_PAGING we send to it over BSSGP, in which case osmo-pcu will schedule
an RLCMAC DL Dummy Block. Take into account this scenario to avoid
failing id it occurs.
Change-Id: I30da93835c7738aefcd84691d83f39759dd4b599
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: Icc94eb0544226facddcd65be65a8a41bcfc662cc
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: I67483bc423567d1fc98eb912ece1cf5cda746119
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state.
Change-Id: If7121473a3580b40d3a658dc38b9bb1421196127
Pau Espin
Harald Welte
Vadim Yanitskiy
Philipp Maier