The Handover is informed to the EPDG by the PGW, who sends a
DeleteBearerRequest when receiving an attach from the 3GPP network once
the phone has jumped there.
Related: OS#6046
Change-Id: I299faf28fa51dbc5d2de6c72a39a01eca67a5775
Add templates for RFC 5447 MIP6-Feature-Vector.
This AVP is a bitmask which as only a few bits defined in RFC 5447, with
other interfaces using this AVP adding interface-specific bits in the
spec of each interface.
The templates are added in a new separate file with the aim of start
splitting the tons of AVPs originating from different specs in order to
be able to quickly identify them and avoid confusion.
Change-Id: I0fc646e5354d78283a2f3e1b9bb9c4688cf744a1
S6b Diameter interface (TS 29.273 section 9) uses the
MIP6-Feature-Vector, which according to TS 29.273 9.2.3.2.3 is defined
in RFC 5447.
Related: OS#6229
Change-Id: I478eff657d876d4ec9a5a1906cab48fbaaaae1b9
The templates are added in a new separate file with the aim of starting
splitting the tons of AVPs originating from different specs in order to
be able to quickly identify them and avoid confusion.
Change-Id: I77f917404dd70559b2b2cc62199ed70289ab0825
15-digit IMSIs are len(imsi)=15, but decoded messages are
octet-aligned, hence the hexstring in messages is len(imsi)=16,
where the last hex char is a padding 'F'H.
* Make sure IMSIs stored in GTPv2_Emulation are padded to 16 digits (8
octets) to process matches easily.
* Update tr_ template to transparently adapt passed hexstrings to match
the octet-aligned value received from the wire.
Change-Id: Ie2f316ccb5bc69ec15e861616de4fd5babc4004e
Those are required/used in SWx interface (3GPP TS 29.273), but are
specified on other documents.
Related: OS#6204
Change-Id: If31e14215fc7fb18cef12d68600b4f170bbb68af
The name sysmo_direct_dsp is not entirely correct. It should be just
"sysmo" if we follow the rules that the "PCU_IF_FLAG_" prefix is
supposed to be chopped off here.
In pcuif_proto.h, we have renamed PCU_IF_FLAG_SYSMO to
PCU_IF_FLAG_DIRECT_PHY. (see Depends), so let's rename the flag here to
"direct_phy".
Related: OS#6191
Depends: osmo-pcu.git I29b7b78a3a91d062b9ea3cd72623d30618cd3f0b
Change-Id: Ib67c4441d0077822d0f9cbf29338fedeb916f287
The msg_id in record record PCUIF_data_cnf lacks the variant
BYTEORDER(last), (which we use in record PCUIF_agch and record
PCUIF_pch). This causes the msg_id to be sent back in the wrong
endieness format.
Related: OS#5927
Change-Id: I69c1ccc37dac1e06ebe29484c767014954ff55e2
With a new HLR version there are multiple APN possible in the
Subscriber Data (PDP Info).
Related: SYS#6391
Change-Id: I8d0c08272bc239370e800d6014ab9c68087b8989
When GTPv2 unit-data is passed around, there is always the problem that
it is routed to the MTC_CT (TEID0). The reason for this is that GTPv2_Emulation
cannot determine a specific receiver component because unit-data does
not contain any addressing fields that would identifiy a specific vc_conn.
In GTPv2_Emulation there is already a mechanism implemented that detects
responses by their sequence number. Untfortunately this does only work
when the vc_conn has send a unit-data message before so that the
sequence number of the response can be guessed.
In case the first messages comes from the IUT, there is no way to
determine the receiving vc_conn, so this message is then routed to the
MCT_CT (TEID0). This can be a problem for testcases that run from inside
a ConnHdlr componet.
The solution that is proposed in this patch uses a mechanism that allows
to create an expectation for a specific messageType. When the GTPv2_Emulation
sees a unit-data message with the expected messageType, it will forward
it to all ConnHdlr (vc_conn) components that have registered for this
messageType previously.
Related: OS#5760
Change-Id: I02bb74d7bd547347168b5c64ee6512c71e8fd960
We do have ts_NAS_MobileId_IMSI/IMEI/GUTI, those can not be used when
crafting EPS messages. However, we can use them to craft
ts_EPS_MobileId_IMSI/IMEI/GUTI templates.
Related: OS#5760
Change-Id: I1adf8c652530904a8e9bd988e78c995c75bb49ab
The template ts_NAS_GUTI permutates the MCC/MNC digits in a weird way,
which seems to map to a format that is not used anywhere else. Also the
template is not used anywhere yet.
Let's not permutate the MCC/MNC digit, instead let's put a comment that
makes clear which format has to be used.
Change-Id: I9546993987b873e8ae921664238b234608e37bba
Related: OS#5760
In function f_init, we activate altstep as_uecups_ind at the end of the
function. In as_uecups we use the template generator function
tr_UECUPS_RecvFrom_R(). In this function we use g_uecups_conn_id, which
is only populated when use_gtpu_daemon is set to true. When
use_gtpu_daemon is false g_uecups_conn_id will be <unbound>, which leads
into an error.
Related: OS#5760
Change-Id: Ifc2e8d9de13d5d183d6f052b2092c356ab4973d1
This fixes following error while running test
GGSN_Tests.TC_pdp46_act_deact_apn4:
"GTP_Templates.ttcn:315 Dynamic test case error: Restriction `omit' on
template of type octetstring violated."
Change-Id: I3846d2a077e4bc53a772e354fcc3c38ca952b38f
This patch fixes BTS_Tests.TC_pcu_data_ind_lqual_cb, which is currently
failing due to incorrect decoding of the 'lqual_cb' field:
"Link quality -32512 does not match expected value -256"
The COMP attribute is documented in TITAN's reference guide,
see 4-ttcn3_language_extensions.adoc#attributes for more info.
Change-Id: I79b8cd41010f212898fbf39c4c600ace69603e79
Related: OS#5954
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