GSUP proxy routing, as it is implemented in an upcoming osmo-hlr patch,
requires that osmo-hlr returns a received Source Name IE back as Destination
Name IE. Add tests for these, for various situations.
These tests pass since GSUP request handling with request->response association
was introduced to osmo-hlr in I179ebb0385b5b355f4740e14d43be97bf93622e3.
Implement this by adding a source_name to the g_pars, which should be sent out
in ts_GSUP_* to osmo-hlr, and expected back as destination_name in returned
messages.
Add source_name and destination_name to various templates, with default :=
omit.
Add f_gen_ts_ies() and f_gen_tr_ies() to compose expected IEs more generically.
Change-Id: I3728776d862c5e5fa7628ca28d74c1ef247459fa
Prepare for upcoming D-GSM test, that lets OsmoHLR act as proxy. It
forwards the messages based on the destination name, so the testsuite
must set it correctly.
Related: OS#4380
Change-Id: I7623b7a7c7a18ba18a38d0834979d18ab0fbb961
Make it possible to do CS location update, not only PS. This is needed
for upcoming D-GSM related tests.
Related: SYS#4618
Change-Id: Idd699f054c9242614b9bea066428293f8b2da9c2
Unlike IMSI, both MSISDN and SMSC address in SM-RP-OA/DA not only
contain the BCD encoded digits, but also a little header with
NPI (Numbering Plan Identification), ToN (Type of Number), and
Extension fields.
Change-Id: I3f55834489f3e613f541cf1e216027e8d48ccaf0
Related: OS#4324
We added the RAT_TYPE_IE while the respective change in libosmocore
was still in gerrit review. Meanwhile the support there has been
split into two parts: A list of supported radio access types and
another IE indicating the current RAT. Let's catch up with that
in the GSUP implementation.
This makes TC_gsup_sai_eps() pass again.
Change-Id: I2c609dc523cbec562c6c6a05f4c7d600649ff52d
Extend BSC_ConnHdlr with new check IMEI related parameters. Add tests
for check IMEI and check IMEI early for multiple auth variations, as
well as variants where the HLR would respond with NOK or ERR.
Note that we can safely set "check-imei-rqd 0" in f_init(), because the
latest OsmoMSC version already suppors this VTY command.
Two tests do not always pass, sometimes the RAN connection breaks
before the test finishes (TC_lu_imsi_auth_tmsi_check_imei_err and
TC_lu_imsi_auth_tmsi_check_imei_nack). I have added them as expected
errors in the expected-results.xml.
Related: OS#2542
Change-Id: Ic34bb8dc8547cafb5a53df03884554dd4f72956d
Both ts_GSUP_PROC_SS_ERR() and tr_GSUP_PROC_SS_ERR() templates
used to compose the set of GSUP IEs manually, while similar ones
were using both f_gen_ts_ss_ies() and f_gen_tr_ss_ies().
This led to the following problems:
- tr_GSUP_PROC_SS_ERR was not tolerant to omitted
message class IE, which was recently introduced;
- code duplication.
Let's modify the both functions in order to accept an optional
Cause IE value, which is omitted by default, and use them in
the both templates.
Change-Id: I5cd6d2bc754bcedd1e721b3bd95ada9cdd44bcf0
Create tests for most code paths of rx_check_imei_req() in hlr.c (except
for subscriber create on demand, this will be in an upcoming patch).
Add missing message types to GSUP_Types.ttcn, and adjust the IMEI and
IMEI_Result IEs for consistency with the existing IEs, and to make the
tests compile.
Related: OS#2541
Change-Id: I97c8462f0817149feadd0c4865e3df6c2af92a80
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
In Change-Id I7d76c982ad4e198534fa488609c41e8892b268ab we merged
various changes to GSUP_Templates.ttcn, mostly related to adding
the tr_GSUP_IE_Message_Class IE.
In most caes, the specified MessageClass is correct. However in
tr_GSUP_PROC_SS_ERR we accidentially used OSMO_GSUP_MESSAGE_CLASS_SMS
instead of OSMO_GSUP_MESSAGE_CLASS_USSD.
This makes TC_lu_and_ss_session_timeout pass again.
Change-Id: I04fa1be24ec63ed1eb767a33de0297722b4366f1
This fixes the partial revert of c43c8cd275
to work for both situtions: Messages that have the OSMO_GSUP_MESSAGE_CLASS_USSD
and messages that don't.
The particular implementation is rather ugly, but we're waiting for
a response to https://www.eclipse.org/forums/index.php/t/1098847/
on how to solve this kind of problem in a more elegant way. Meanwile,
we make it work first.
Change-Id: Ibf137de6a41aaa43894cc0b6da8341ceb88b0756
Commit 0ac6315212 breaks all related GSUP SS tests because it require
all GSUP SS packages to have a OSMO_GSUP_MESSAGE_CLASS_USSD IE.
Change-Id: Iadbc37105fa67cf6383fb63b86ed653ccc7bddf7
Implement necessary messages for Procedure Check_IMEI_VLR (TS 23.018
Chapter 7.1.2.9). This lets the VLR ask the EIR to check if an IMEI
is valid. In the Osmocom stack, we don't have an EIR and this request
is handled by the HLR. We are able to store the IMEI in the HLR as
side-effect (OS#2541).
This is roughly based on TS 29.002 8.7.1 MAP_CHECK_IMEI service, but
only implements the bare minimum required IEs (imei and imei_result).
Related: OS#3733
Change-Id: Ie1ae5c66ad3f9b42b345020de62a0c276cd8d709
Both GSUP_SM_RP_{DA|OA} IE definitions have been merged before
the reference implementation in libosmocore. Recently it was
decided to use the following structure:
IEI | IE length | ID type | ID encoded data (optional)
instead of:
IEI | IE length | ID type | ID length | ID encoded data (optional)
so, let's remove ID length from both definitions.
Change-Id: I001cec53a80028ff153db3d8b0318b298f2bd8c2
According to 3GPP TS 29.002, section 12.4, MAP-READY-FOR-SM is
used between the MSC and VLR as well as between the VLR and the
HLR to indicate that a subscriber has memory available for SMS.
This change replicates this service in GSUP as READY_FOR_SM_*.
The only mandatory IE for this service (excluding Invoke ID) is
'Alert Reason' that is replicated by OSMO_GSUP_SM_ALERT_RSN_IE.
Change-Id: If2256607527ecfcb10285583332fb8b0515d7c78
Related: OS#3587
According to 3GPP TS 29.002, there are two services:
- MAP-MO-FORWARD-SHORT-MESSAGE (see 12.2),
- MAP-MT-FORWARD-SHORT-MESSAGE (see 12.9),
which are used to forward MO/MT short messages.
This change replicates both services as GSUP messages:
- OSMO_GSUP_MSGT_MO_FORWARD_SM_*,
- OSMO_GSUP_MSGT_MT_FORWARD_SM_*.
Please note, that only the 'must-have' IEs are introduced
by this change, in particular the following:
- OSMO_GSUP_SM_RP_MR_IE (see note below),
- OSMO_GSUP_SM_RP_DA_IE (see 7.6.8.1),
- OSMO_GSUP_SM_RP_OA_IE (see 7.6.8.2),
- OSMO_GSUP_SM_RP_UI_IE (see 7.6.8.4),
- OSMO_GSUP_SM_RP_MMS_IE (see 7.6.8.7),
- OSMO_GSUP_SM_RP_CAUSE_IE (see GSM TS 04.11, 8.2.5.4),
where both SM_RP_DA and SM_RP_OA IEs basically contain
a single nested TLV of the following format:
- T: identity type (see 'GSUP_SM_RP_ODA_IdType'),
- L: identity length,
- V: encoded identity itself.
According to GSM TS 04.11, every single message on the SM-RL has
an unique message reference (see 8.2.3), that is used to link
an RP-ACK or RP-ERROR message to the associated (preceding)
RP-DATA or RP-SMMA message transfer attempt.
In case of TCAP/MAP, this message reference is being mapped to the
Invoke ID. But since GSUP has no 'Invoke ID' IE, and it is not
required for other applications (other than SMS), this change
introduces a special 'SM_RP_MR' IE that doesn't exist in MAP.
Change-Id: Ibf49474a81235096c032ea21f217170f523bd94e
Related: OS#3587
In general, the order of IEs in a GSUP message doesn't matter.
Despite libosmocore's GSUP API encodes IEs in a fixed order,
it is capable to decode them in any arbitary order.
Meanwhile, in the current TTCN-3 definitions (i.e. templates)
the order makes a difference, because the 'GSUP_IEs' type is
a record, that according to the TTCN-3 documentation represents
an *ordered* sequence of elements.
Let's reorder the IEs of both t{r|s}_GSUP_PROC_SS_ERR templates
in a way that is used by the libosmocore's GSUP encoder.
This correction doesn't affect successful test case executions,
because we don't test possible problematic situations yet. But
if something went wrong on the HLR side (i.e. SUT), the matching
statements wouldn't match the PROC_SS_ERR message correctly
and continue to wait until the guard timer is expired.
Change-Id: I5eb2314f6a9ab0e9fc5e836390414cec6e1a12db
Both session state and session ID IEs are always being encoded
together by libosmocore's GSUP implementation. So, if a message
contains a session ID IE, session state IE shall also be there.
For some reason, the session state IE was missing in both
ts_GSUP_PROC_SS_ERR and tr_GSUP_PROC_SS_ERR templates. This
could led to incorrect matching in our test cases.
This change fixes both templates by adding the missing IE. Since
tr_GSUP_PROC_SS_ERR templete is used in HLR_Tests.ttcn, all the
affected matching statements were also corrected.
This correction doesn't affect successful test case executions,
because we don't test possible problematic situations yet. But
if something went wrong on the HLR side (i.e. SUT), the matching
statements wouldn't match the PROC_SS_ERR message correctly
and continue to wait until the guard timer is expired.
Change-Id: I44070396ce7119eab4608d9f9fb090bb223dfaa2
The comment in the c header of OSMO_GSUP_CANCEL_TYPE_UPDATE says:
1 = /* 0 on the wire */,
2 = /* 1 on the wire */
Change-Id: I4d22af9fee19e6036dbb555422759e3c1285416a
As OsmoHLR is getting support for external USSD Entities (EUSEs),
we have to implement this function in the test logic in order to
test it.
Change-Id: Ibab210b06abfd5a21e81c7f7fbe574c4f67414a0
The 'SS Info' IE is optional for GSUP_PROC_SS_{REQ|RSP} messages,
and is not carried in some cases, e.g. when a subscriber aborts
an active transaction by pressing the 'red button'.
Change-Id: I20d9028acbe0c457d2a2cf72eff372b749d8dc30
Recently we introduced a few new GSUP IEs, related to TCAP-like
session management and Supplementary Services in libosmocore.
Let's sync the TTCN-3 implementation and add the corresponding
templates for SS payloads.
Change-Id: I54767e49ae98db67f71dd28278b14435860313e0
We permit other subscriber data that's not the MSISDN, but we require
the MSISDN be somewhere within the IEs of the ISD_REQ
Change-Id: Ic63cd5c9a5e9ed46c70f7d7869b4ece281b97e44
OsmoMSC seems to have broken encoding of MSISDN which is not in-line
with the spec. Let's adapt to it.
Change-Id: I4892df63f1a135573dcac977f5eb0a79cbaffad3
Related: OS#2883