The testcase TC_pcu_data_req_agch uses SAPI PCU_IF_SAPI_AGCH. Since we
now have a function f_PCUIF_tx_mac_block_agch() to send MAC blocks over
the AGCH using the recently introduced SAPI PCU_IF_SAPI_AGCH_2, lets use
this function instead.
Related: OS#5927
Change-Id: I341bbd01e8132fab913d307bfb4b2fb873cdde3c
In PCUIF v.11 it will be possible to get confirmations for IMMEDIATE
ASSIGNMENT messages sent through the AGCH.
Related: OS#5927
Change-Id: I40e05a2e68cca77d3c2f41df9af8d35762488abf
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
After fixing GCC and BCC transaction ID, the new head is:
b6602eb357673f097ea1a1d22edd568ecd239da1
Related: OS#4854
Change-Id: I2833750a8cf1def74f92a5a50f0d271891cee05f
This is useful in the scenarios where the client component submits a
IMSI-based transaction such as AIR, but its answer (AIA) contains no
IMSI (as per what's specified in TS 29.272 5.2.3.1). As a result, the
received AIA message would be enqueued in the DIAMETER_UNIT.
With this new feature, the test can create an expect using the
End-to-End Identifier of the message it is going to transmit, and
receive the answer in the same DIAMETER_CLIENT port the request was
transmitted, even if it contains no IMSI.
Related: OS#5757
Change-Id: I25e44146d2c49e308c1fb490b499e70ac6045f2f
The decoder function that decodes the RIM ROUTING ADDRESS should be
called dec_RIM_Routing_Address_GTPC and not dec_PCUIF_pch_dt
Change-Id: I4235bc727bf8e71d1ef4a43c830706b6e1c826c9
Prepare to add new CSD related tests that also need to configure the
call parameters for CSD.
Related: OS#4394
Change-Id: I49c29af736cc37c393cecde4c45c4ffd41322bf7
Verify that the MSC sends the CSData codec in the Assignment Request and
send this codec in the Assignment Complete towards the MSC.
Related: OS#4394
Change-Id: I7906e6fdb82c27f071aa55f2f73ba4108bfb46db
We are no longer "appending" imsi digits. This is now done properly
using a struct but let's still mention what we use the IMSI for.
Related: OS#5927
Change-Id: I3d943cd96e1d9627ad68e3439b2a649baa5785f1
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
Add tr_RUA_Disconnect_opt_ranap that matches RUA Disconnect with and
without RANAP payload.
Use this in RUA_Emulation as_main_rua(), to trigger a RUA_Disc_Ind to
the CLIENT also for Disconnect without RANAP data.
Rationale:
This patch exists for the line
RUA.receive(RUA_Disc_Ind:?);
in the TC_apply_sccp patch Ia1ff0cb56893edf045ea3cb3233882ca93445d21
In upcoming HNBGW_Tests.TC_apply_sccp, I want to test for an ungraceful
RUA Disconnect, which is sent without a RANAP payload. But
tr_RUA_Disconnect only matches when a RANAP Message IE is present. In
consequence, RUA_Emulation ignores "empty" RUA Disconnect, and my test
case cannot verify that the RUA Disconnect occurred. Fix that.
Change-Id: Ia0b89e9198794d196a88040ee89bdf24f3b08ae0
Only dispatch RUA_Disc_Ind to CLIENT when CLIENT is connected.
Reason:
If a test does not care much about conn cleanup, it may cause a
situation where the CLIENT has already disconnected when osmo-hnbgw
sends a RUA Disconnect. A disconnected CLIENT port will cause the final
verdict to become 'error'. Instead, if the CLIENT is already
disconnected, just don't bother, and allow tests to still pass.
This will become necessary, because:
So far a RUA Disconnect without any RANAP payload is not detected by the
RUA emulation. But patch Ia0b89e9198794d196a88040ee89bdf24f3b08ae0 will
fix it, so that *every* RUA Disconnect causes a RUA_Disc_Ind sent to the
CLIENT. From then on, we will see a bunch more RUA_Disc_Ind at the end
of tests. Some of those happen *after* the client already disconnected,
causing tests to error that have been passing for a long time.
Change-Id: Ia1403f39cfdc75139922292a3eace7a69a64a576
The record PCUIF_data_cnf_dt was added when the first experiments
with Ericsson RBS base stations were made. It is essentially a copy of
record PCUIF_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Related: OS#5927
Change-Id: Ie17d73d4c4bf2921800f87f6d6be7c05ce3a291d
The function f_PCUIF_tx_imm_ass_pch() retuns the frame number, that is
sent back from osmo-bts via PCUIF / gsm_pcu_if_data_cnf_dt. Since we are
about to remove this field from gsm_pcu_if_data_cnf_dt, lets no longer
access it here as well. Also the return code is never used anywhere in
the tests. (In osmo-pcu the fn parameter was used for logging only, in
osmo-bts it was set to constant 0)
Related: OS#5927
Change-Id: I0e5bad7a0d74e5032f2818f6fdf5b9b2ecb531cc
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
When sending the RAN INFORMATION REQUEST on GTP-C, we do not add a RIM
ROUTING ADDRESS + RIM ROUTING ADDRESS DISCRIMINATOR field. Those fields
are optional but commonly added so that the SGSN does not have to
disassemble the RAN TRANSPARENT CONTAINTER to know the destination
address.
see also: 3gpp TS 29.060, section 7.5.14 and
3GPP TS 23.060, section 8.1.5.2.2
Change-Id: Id944c66f28d787a18c6c6f7c9dc885997d83e94c
Related: OS#6095
Give some more wait time for RANAP RESET after f_cn_nr_init().
Intended to fix sporadic failures of HNBGW_Tests...
- TC_rab_assign_mgcp_to
- TC_ranap_cs_mo_disconnect
Change-Id: Ia5144dbbc5168b3707e714e12b805f5d640fa774
The proposed testcase models a full RIM RAN INFORMATION REQUEST that
originates at the eNB (S1AP), is forwarded by the MME towards GERAN
(GTP) and goes back towards the MME (GTP) and is eventually forwarded
by the MME back to the eNB (S1AP).
Related: OS#5760
Related: OS#5759
Change-Id: I22d5aaab64df2824099977fb574afb86a4b7e91f
The IE types RIM_RoutingAddress and RIM_RoutingAddress_Discriminator
have not coresponding templates yet.
Related: OS#6095
Change-Id: If79f94ac3b7ec9a76763141ee2d8cac50c69d60b
The GTP Templates lack the template restriction qualifiers (present,
value, omit) in many places.
Related: OS#6095
Change-Id: Ic439b4ae85b417fde0ddfb8fa00758d6486b57c8
docker-playground.git needs a config file change to be committed at the
same time as this patch, see 'Related'.
Depends: osmo-ttcn3-hacks I94aa0b2adfc48b98cb4b1efe595c2432fc603d6c
Change-Id: I027a059faed3f140f8801f84338956cd004043b5
Allow starting with a specific 'msc' / 'sgsn' instance without having to
read all the lower numbers along. For HNBGW_Tests.ttcn.
Change-Id: I9b74a1df9e115883b4b0ac0f606a370c6aca7f40
Most tests need to run f_start_hnbs() directly after f_init(), so make
that the default behavior.
The three tests that don't want f_start_hnbs() to run now pass a new
arg, f_init(start_hnb := false).
Change-Id: I2b29ce66aee0b2d57fa26e6110f06292c481ab6b
When forwarding RAN TRANSPARENT CONTAINERs containers on GTP-C, the
sender adds a RIM ROUTING ADDRESS and a RIM ROUTING ADDRESS
DISCRIMINATOR. The RIM ROUTING ADDRESS is represented as an
octet-string, so we need encoder/decoder functions for it.
Related: OS#6095
Change-Id: I45d1f5b019f3847fd611c38dc19d78d6fe027c5a
The testcase TC_pcu_data_req_imm_ass_pch uses the PCH to transmit the
IMMEDIATE ASSIGNMENT message but the log line mentions the AGCH.
Related: OS#5927
Change-Id: I7cb8d91f2c3f92009d33134167eab856ee02fdab
We are calling f_pcu_data_req() with SAPI PCU_IF_SAPI_AGCH or SAPI
PCU_IF_SAPI_PCH and use ts_nr 7.
In this particular case, the parameter ts_nr has no effect (see pcu_sock.c in
osmo-bts.git). However, to prevent confusion, lets use ts_nr 0 since AGCH and
PCH are actually is on TS 0 (on TRX 0).
Related: OS#5927
Change-Id: I20566de992809d6c857c9062bf0fb799efa43e45
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
The expectation table is used to deliver new connections with Handover
Request as well as with VGCS/VBS Setup and VGCS/VBS Assignment Request.
"handoverRequest" is renamed to "n_connect".
Related: OS#4854
Change-Id: I941c5db5235785841f3368ef908a409bbb12150e
Similar to Handover Requests the RAN Emulation can accept new SCCP
connections with VGCS/VBS Setup message and VGCS/VBS Assignment Request
message. The point code for the incoming connection can be registered
in the same way as for the Handover Request.
In order to allow multiple connections with the same point code, the
table entry in the ExpectTable must be released after receiving the
message. VGCS/VBS calls have multiple connections to the same BSC.
This patch does not break existing MSC handover tests.
Related: OS#4854
Change-Id: I3fc0c5efe7d9f270804e7295aeb65cfe7898bd7e