Like BVCI=PTP, the BVCI=0 messages must be dispatched by their
TLLI, but using the BSSGP_SP_SIG port instead of BSSGP_SP.
Change-Id: Ic456d43ec07600162991698ec3d75d36785b2fb8
Not all parts of the code explicitly specify each and every parameter
of the Cell Gobal Identifier (particularly we don't do that for the PCU
INFO IND), and hence multiple parts only interoperate if the same
defaults are used in all locations.
Change-Id: Iac9be9a8d4ccb4d01cc343d763d2e35873e3844f
The handling of the AMR rate configuration bits S15-S0 is currently only
superficially checked. Lets add more some more elaborated testcases to
check through varios different situations. Also make sure that the
resulting mr configuration IE is verified
Change-Id: Ica323deb9836deea72982e093c9cb31deb5a216b
Related: SYS#4470
When creating an RTP flow, there is currently no way to set SDP fmtp
parameters. Lets add a template and a parameter in order to be able to
set those parameters.
Change-Id: Ic1840d5023cb3888a17980f4ed08c19175864896
Related: SYS#4470
Add related templates based on 3GPP TS 29.060 Figure 37A and create
tests based on existing IPv4 and v6 ones.
Related: OS#2900
Change-Id: I3bab7df5caddc5c8b973c81544f954d5473ac234
So far we omit a Speech Codec (Chosen) from Assignment Complete messages, which
is actually a mandatory parameter. osmo-msc seems to carry on nevertheless, but
it actually shouldn't be able to.
Always send a Speech Codec (Chosen).
Change-Id: Ib35f019383db8ace05a9dc349648e2da7ba58bfa
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
The configuration of the RTP Emulation (RtpemConfig) allows to set a
fixed RTP payload that is then used when RTP packets are transmitted.
However, when packets are received, then the payload is not checked.
Lets check the received data against some user configurable rx payload,
that is by default set to the tx payload.
Change-Id: Id0b125aaf915497d0a4f051af890fc34e09da61d
Related: OS#3807
When a CSFB voice call is cleared by the MSC, it must include the
CSFB INDICATOR in order to trigger the BSC to perform actions
required for Fast Return to LTE.
This patch changes TC_sgsap_lu_and_mt_call() and
TC_bssap_lu_sgsap_lu_and_mt_call() to ensure the CSFB INDICATOR IE
is present as expected.
Change-Id: I6ce3a34f85aca7143cf7925cb9319bc679e8d395
In TTCN-3, a 4-byte octetstring is the more usual representation for
IP addresses, not an integer type. This is also what functions like
f_inet_addr() etc. are using as types, and we may want to use them
in combination with the PCUIF.
Change-Id: Ia08e1bb8a9bfbd5bf5b63922c77bb221ce1a12f5
Our TTCN-3 PCUIF code so far was only used to simulate the PCU side
of the interface: connecting to the socket as a client. However,
it's also useful to emulate the BTS side of the interface: Listening
for a connection as a server.
Also, the send/receive templates are prepared for the inverse role.
Change-Id: I779ff2903cab8c13ffb8fe10a4cacd996bafe69a
When a MSC releases a connection using the BSSMAP CLEAR CMD, it can
specify that this call was part of CSFB.
The BSC is then supposed to add a special IE to the RR RELEASE
message which will help the phone to switch back to LTE as soon
as possible.
This commit adds a new test case testing for exactly that behavior.
The test does *not* verify if the EARFCN information contained is
actually correct, only that the IE is present in the RR RELEASE.
Change-Id: I7501fb25578412c882ff92da5d388f3079bbce7f
Requires: osmo-bsc Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Related: OS#3777
The 'decmatch' keyword allows us to match the decoded version of some
octetstring, which is very useful in the situations where we have
the L3 message only as octetstring but want to check if it matches
some L3 template.
Change-Id: I0a91e067f7e8062bf991fef8b0d4d8da740bfafc
This extens MSC_Tests.ttcn with an initial set of SGs interface test
cases for RESET, LU, DETACH, PAGING, SMS and CSFB procedures
In particular the following testcases are added:
- TC_sgsap_reset: isolated reset procedure test
- TC_sgsap_lu: isolated location update with TMSI realloc
- TC_sgsap_lu_imsi_reject: location update, reject case
- TC_sgsap_lu_and_nothing: location update with failed TMSI realloc
- TC_sgsap_expl_imsi_det_eps: detach from EPS serveces
- TC_sgsap_expl_imsi_det_noneps: detach from non-EPS services
- TC_sgsap_paging_rej: isolated paging, reject case
- TC_sgsap_paging_subscr_rej: isolated paging, subscr rejects call
- TC_sgsap_paging_ue_unr: isolated paging, ue is unreachable
- TC_sgsap_paging_and_nothing: page, but don't respond
- TC_sgsap_paging_and_lu: check paging followed by an LU
- TC_sgsap_mt_sms: mobile terminated SMS through SGs Interface
- TC_sgsap_mo_sms: mobile originated SMS through SGs Interface
- TC_sgsap_mt_sms_and_nothing: trigger SMS, but don't respond to paging
- TC_sgsap_mt_sms_and_reject: trigger SMS, but reject paging
- TC_sgsap_unexp_ud: Send unexpected unitdata (SGs Association: NULL)
- TC_sgsap_unsol_ud: Send unsolicited unitdata (subscriber not in VLR)
- TC_bssap_lu_sgsap_lu_and_mt_call: LU on 2G, LU on SGs and CSFB call
- TC_sgsap_lu_and_mt_call: LU on SGs, and CSFB call
Change-Id: I38543c35a9e74cea276e58d1d7ef01ef07ffe858
Depends: osmo-msc I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3645
Usually the MS power is controlled by the BTS and there is no continous
supervison by the BSC needed. However, a scheme where the BSC takes care
of the power control loop exists. The power is then set via RSL using an
RSL MS POWER CONTROL message.
This tests establishes a dchan and then sends MS POWER CONTROL messages
with differen power levels and then checks the presence of the power
level set in the MS POWER LEVEL field of the SACCH L1 header.
Change-Id: I82b04a3bf94d355175f7f6ff3fdc43672e8080a2
Related: OS#1622
The MM Info message is an optional message that is set to the MS usually
after the location update. It contains the full network name and time
information. At the moment the presence of this message is not checked
or expected since sending of MM-Info is explicitly disabled in the
osmo-msc configu.
This patch adds an optional check of MM Info that is disabled by
default.
Change-Id: I431f50c2ff3536f87f0c7c3caf23b7a38d501904
Related: OS#3615
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
At the moment the function f_ipa_ctrl_start() is starting the IPA
emulation client with parameter -1 for local port. This is internally
translated to port number 9999, which is a fixed number. This makes
it impossible to have two control interfaces at the same time.
Lets use 0 as local port, so that the OS is selecting a free port
number automatically.
Change-Id: Ie6648f8f4c1e065c174868c35eb64ee034ace3ce
Related: OS#3645
It's unclear why those variants were commented - looks like artifact
from initial development. Let's drop them to avoid confusion.
Change-Id: I3f11a93634fc50243a7210edcd501bd4b90d6dcd
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
tr_BSSMAP_HandoverPerformed matches all optional fields on "omit". This
does not make much sense as a safe default. Lets match on "*" instead.
(See also other tr_ templates)
Related OS#3645
Change-Id: Icd55afdaebdda8ba98431f358148035f7d220b8a
Implement a basic paging test for the PCU, which is passing for paging
via TMSI (but only if osmo-pcu is started after the test is started).
Previously, this test code amounted to a debugging loop which
never terminated.
Change-Id: Id0384e0742ab91983615e4f1c883bb044c1c8b18
Related: OS#2404
tr_BSSMAP_HandoverPerformed lacks the field speechVersion, lets add it
to make the template complete.
Change-Id: Id73c0aef5caa0936aa44308faf2aae1c20c7446c
Related OS#3645
MSC tests were unable to match odd-length digit strings in
a CallingPartyBCD_Number template created by tr_Calling().
This happens because the raw encoder for CallingPartyBCD_Number
pads odd-length digits with 1-bits ('F'H). Do the same when
constructing such a template in our own code to ensure that
we'll match the actual data received.
Change-Id: I34439c8750f588802a5403375e2a3d6e74dae70c
Related: OS#2930
Add two helper functions which retry a VTY command until the
result matches a regular expression or a configurable timeout
expires.
Use these functions in BSC test's f_ts_dyn_mode_get, which has
seen sporadic failures due to a race condition during channel
reconfiguration, in order to hopefully close this race.
Change-Id: I308ddb06e440c165fe1e73fe2c1fb78be2e1d510
Related: OS#3690
The receive template for the BSSMAP HANDOVER PERFORMED MESSAGE is
missing, lets add one.
Related OS#3645
Change-Id: I527913203b2d5bfa26c181c4bb79481a9cd283ae
Drop 'return' statements after 'mtc.stop' as they cause following
warning from TTCN-3 compiler:
warning: Control never reaches this statement
Change-Id: I6210ecf5fcb39f751116ad63a69d2ae8651a60c5
We cannot notify RSL Emulation layer about expecting a specific FN
(during ts_RSLDC_ChanRqd) because we only know the FN after sending the
RACH request, and since notification to RSL Emulation happens async, it
can happen (verified) that ChanRqd message from BTS arrives and is
handled before we register the RACH req into the ConnectionTable.
Change-Id: I438fd3ee82d88498d928dbcc89ce9bd80d37ab64
Harald Welte
Philipp Maier
Max
Oliver Smith
Pau Espin