New TC_assignment_osmux_bts is added which tests Osmux used only
BTS<->BSC.
Existing TC_assignment_osmux is renamed to TC_assignment_osmux_cn,
and a new TC_assignment_osmux is added which tests using Osmux on both
sides (towards BTS and CN).
Related: SYS#5987
Change-Id: I6e82eb9d995de988b812001e1c4cf6923509de66
An emergency call often comes with a Location Request. Make sure
osmo-bsc handles it well.
Related: SYS#5916
Change-Id: I95037374c45943cb14401bc48f16a39c2fcbe1f5
According to 3GPP TS 48.008, section 3.2.1.71, the LCS QoS IE shall
be present if location of the target MS is requested and is optional
otherwise. Since [1], osmo-bsc started to check presence of this IE,
so let's add it to ts_BSSMAP_Perform_Location_Request.
Taking a chance, let's also add LCS Priority IE.
Change-Id: If2bd6e636d3ee695abab9ed40417dc53ec68fd12
Related: [1] osmo-bsc.git Ifeb359b0468845da0b4fed9e2e4b79256067fa81
Related: SYS#5891
According to 3GPP TS 48.008, section 3.2.1.71, the LCS Client Type
IE shall be present if the location type indicates a request for a
location estimate and is optional otherwise. Since [1], osmo-bsc
started to check presence of this IE, so let's make sure that
it's present in ts_BSSMAP_Perform_Location_Request by default.
Change-Id: I5c8d6962e957d587dc4b65d08bf56bd4ef2f0d6e
Related: [1] osmo-bsc.git Id3262e67c3dc25cb93fbd52a40689c5529ca2d41
Related: SYS#5891
So far, osmo-bsc ignored the Codec List (MSC Preferred) in inter-BSC
incoming HO Request messages. Starting with osmo-bsc
I117cc29d6d11db77d160de654f43f5993db6ee21, a missing codec list on AoIP
causes incoming inter-BSC HO to fail, as it should (3GPP TS 48.008
indicates that a codec list shall be included on AoIP). To avoid test
fallout when merging above osmo-bsc patch, add a codec list to HO
Request on AoIP.
Related: OS#5839
Change-Id: If06de9c9b43d79f749447a4e2a340176eef75c79
Move the ciphering calculations from f_mm_common() to new function
f_get_expected_encryption(), so that it can be re-used for ciphering in
inter-BSC handover (upcoming patch).
Add tr_BSSMAP_CipherModeCmd2() to conveniently use the values returned
by f_get_expected_encryption().
To verify the Ciphering Mode Command in f_mm_common(), use the new
tr_BSSMAP_CipherModeCmd2(), and rely on template matching instead of
checking each IE individually.
Related: SYS#5324
Change-Id: I1f775889fb801d441ea6c8b0f0c34718b814c09e
All msc tests involving classmarks suffer from the same problem: if a
existing subscriber is reused the old classmarks will stick, since the
msc only overwrites updated parts of the cm when receiving a new cm, so
"downgrading" the existing classmark information is not possible.
This is circumvented here here by using different imsi suffixes,
the last param passed to f_start_handler.
Additionally the handler will now properly respond to cm requests
by the msc, i.e. in case the early cm is not sufficient for a5/4
because it lacks cm3, so the msc attempts once to query the cm,
hoping to get a cm3.
Related: SYS#5324
Change-Id: Idc055a006b325f58a5eafa88bc4415181b3500a2
Validate in test that MSC sends Last Used E-UTRAN PLLMN Id IE when call
is started by SGs (CSFB).
Related: SYS#5337
Change-Id: I161529fd9c8cacb7d17ea18660998df06bb0b575
Both BSSMAP-LE and BSSMAP use the LCS Cause IE with identical definition. In
order to not add further dependencies from BSSMAP_Templates.ttcn to
BSSAP_LE_Types.ttcn to BSSLAP_Types.ttcn, duplicate the LCS Cause enum.
Change-Id: Ifee698c128a5345f6bf0301ad4dac9e083285d56
This way one can simply pass an IP addr in string format and return the
IE no matter the IP version.
Change-Id: I743dbb7c89e504762498b7f278c12e130352e5f0
BSSMAP_Templates.ttcn: In TTCN-3 module `BSSMAP_Templates':
BSSMAP_Templates.ttcn:181.1-192.1: In template definition `ts_BSSMAP_Reset':
BSSMAP_Templates.ttcn:181.1-192.1: While checking template restriction `value':
BSSMAP_Templates.ttcn:188.21-54: warning: Inadequate restriction on the referenced function `f_enc_osmux_support(osmux_enabled)', this may cause a dynamic test case error at runtime
BSSMAP_Templates.ttcn:174.9-179.1: note: Referenced function is here
BSSMAP_Templates.ttcn:207.1-217.1: In template definition `ts_BSSMAP_ResetAck':
BSSMAP_Templates.ttcn:207.1-217.1: While checking template restriction `value':
BSSMAP_Templates.ttcn:213.21-54: warning: Inadequate restriction on the referenced function `f_enc_osmux_support(osmux_enabled)', this may cause a dynamic test case error at runtime
BSSMAP_Templates.ttcn:174.9-179.1: note: Referenced function is here
Change-Id: I947e1a6aeb1fe40167eb268906906edd7e857232
* Semantic:
We don't really know which side the MSC first creates a CRCX for. Instead of
assuming that the RAN side is always CRCX'd first, simply handle a "first" and
a "second" CRCX, not making any assumptions which is for which side.
Notably, there still are quite a few places assuming which CRCX corresponds to
the RAN/CN side, but the changes are sufficient to still pass the tests when
osmo-msc swaps the CRCX order; sometimes for slightly obscure reasons, for
example because it doesn't matter that the wrong port number is returned during
a subsequent MDCX... Cleaning up the rest is still todo for later.
Remove code dup from call establishing code, particularly for MGCP.
Use f_mo_call_establish() and f_mt_call() where ever possible, to make all of
the call establishing tests handle upcoming changes in osmo-msc's order of
messages, without re-implementing the changes for each test individually.
The X-Osmux parameter was so far expected to appear in the first CRCX received,
assuming that this first CRCX is for the RAN. Instead, detect whether X-Osmux
is contained in a CRCX, and reply with an Osmux CID if so, regardless of it
being the first or second CRCX. Count the number of X-Osmux parameters
received in CRCX messages, and compare after call setup to verify X-Osmux
presence.
Since f_mo_call_establish() can't handle RANAP assignment, a few Iu tests that
worked with the older code dup will break by this patch. This is fixed by a
subsequent patch, see I0ead36333ab665147b8d222070ea5cf8afc555ec.
* Details, per patch chunk:
Change ts_BSSMAP_IE_AoIP_TLA4 to a non-value template, so that we can use a
wildcard for the assigned port number from MGCP (depending on RAN or CN CRCX
first, the RAN port number can be one or the other).
In CallParameters, move MGCP handling instructions into a separate record
"CrcxResponse", and have two of them for handling the first and the second
CRCX, replacing mgw_rtp_{ip,port}_{bss,mss} and mgcp_connection_id_{bss,mss}.
In CallParameters, add some flags for early-exiting call establishment with a
particular desired behavior, for specialized tests.
In CallParameters, use common default values and don't repeat them in each and
every call establishing test.
Set cpars.mo_call := {true,false} implicitly when f_{mo,mt}_call_establish()
are invoked.
Remove CRCX comments implying RAN or CN side, instead just talk of the "first"
and the "second" CRCX.
Implement one common f_handle_crcx() function, which is used by
f_mo_call_establish(), f_mt_call_complete(), as_optional_mgcp_crcx(), and
implicitly uses the first/second CRCX handling.
For Assigment, use a wildcard RTP port so that we don't have to assume which
CRCX was for the RAN side.
In f_mo_call_establish(), insert special case conditions to make it enact
errors at specific times, for individual tests. That saves re-implementing the
entire call establishment (code dup).
For error cases, add expectation of a CC Release message in the call
establishment. This should not apply for normal successful operation, but
because interleave does not support conditionals, add flags
got_mncc_setup_compl_ind and got_cc_connect to break the interleave when
establishing is complete, so that the CC Release is skipped.
A CC Release always breaks the interleave, at whatever time it arrives.
Tests adopting f_{mo,mt}_call instead of code dup:
f_tc_mo_setup_and_nothing()
f_tc_mo_crcx_ran_timeout()
f_tc_mo_crcx_ran_reject()
f_tc_mo_release_timeout()
f_tc_mo_cc_bssmap_clear()
Change-Id: I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
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
After new fields (osmux osmocom extensions) were added to BSSMAP Reset
and BSSMAP AssignReq/AssignCompl in titan.ProtocolModules.BSSMAP, we
need to set them in ts_* templates, otherwise TTCN3 runtimes fails with:
"""
BSC_Tests.ttcn:143 Dynamic test case error: Performing a valueof or send
operation on a non-specific template of type @BSSAP_Types.BSSMAP_IE_Osmo_OsmuxSupport.
"""
Fixes: fe0c6083bd
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: I568100376cf8a47c01a33bada97bf8eaa7c07fcd
Add three tests which exercise MSC behaviour when a CIPHER MODE
COMPLETE command lacks the optional chosenEncryptionAlgorithm IE.
Check for behaviour with A5/1, A5/3, and A5/1 + A5/3 configured
in the network, and expect the location update to succeed.
These tests pass on master, but they should somehow verify the
cipher the MSC ends up using. I am not quite sure how to do that.
Would inspecting the MSC's VTY be a reasonable approach? How
could his be done by code which runs on BSC_ConnectionHandler?
Change-Id: I1a2a126795c544613a7a87e238e1fc8c4e943885
Related: OS#2872
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
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
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
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
tr_BSSMAP_HandoverPerformed lacks the field speechVersion, lets add it
to make the template complete.
Change-Id: Id73c0aef5caa0936aa44308faf2aae1c20c7446c
Related OS#3645
The receive template for the BSSMAP HANDOVER PERFORMED MESSAGE is
missing, lets add one.
Related OS#3645
Change-Id: I527913203b2d5bfa26c181c4bb79481a9cd283ae
Add f_gen_handover_req() like f_gen_ass_req(), to match AoIP or SCCPlite
requirements.
For incoming HO, MSC_ConnHdlr needs to know the SCCP addresses to expect the
incoming SCCP Connection from MSC to BSC. Add 'handover' section to
TestHdlrParams, and pass in the addresses from test_CT via that.
In osmo-bsc.cfg, add a remote neighbor config, so that the VTY command
'handover any to arfcn 123 bsic any' can trigger an outgoing inter-BSC HO.
Add various BSSMAP handover templates to BSSMAP_Templates.ttcn.
Add RR Ho Command template to L3_Templates.ttcn.
Move ts_BSSAP_Conn_Req() from msc/BSC_ConnectionHandler.ttcn to
library/BSSMAP_Emulation.ttcn, so we can also model an SCCP Connection Request
in BSC_Tests.ttcn (this time from MSC to BSC).
Add the two new tests to bsc/expected-results.xml.
Related: OS#2283
Change-Id: Id22852d4be7f127d827e7a8beeec55db27c07f03
After osmo-msc I73c7cb6a86624695bd9c0f59abb72e2fdc655131, osmo-msc
sends a BSSMAP Classmark Request if encounters a missing Classmark,
which is the case during LU when A5/3 is enabled.
Fix this test by answering the Classmark Request, if any.
Change-Id: I25578c050b7e105ed71b064891d4cd418ee30fcf
Enhance TC_classmark to also include the BSSMAP Classmark Request -> RR
Classmark Enquiry part. So far it was only testing the return path of RR
Classmark Change -> BSSMAP Classmark Update.
This test will thus fail with current osmo-bsc master, and will succeed as soon
as osmo-bsc If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf is merged.
Add:
* ts_BSSMAP_ClassmarkRequest in BSSMAP_Templates.ttcn
* tr_RRM_CM_ENQUIRY in L3_Templates.ttcn
Change-Id: Idaab4d568cf986b4897ba008f6262c839d1592fb
This is an early WIP, we actually will need to establish two calls/legs
before the BSC is able to locally correlate them.
Related: OS#1602
Change-Id: Ie6d0b9c38027abf65c7c564fc79b889d013fa6a7
We will soon implement some LCLS related test cases, and hence
we need some templates for sending and matching received messages.
Change-Id: I5300418ae493f6c315248562938b47ae1931b452
In order to form a minimal HANDOVER REQUIRED message additional
Templates (ts_) are needed.
- Add Template ts_BSSMAP_IE_SpeechVersion
- Add Template ts_BSSMAP_IE_CurrentChannelType1
- Add Template ts_BSSMAP_IE_OldToNewBSSInfo
Change-Id: I41c2a036465d422db9348d4d2d66bb332e16e155
Related: OS#1609
The TTCN-3 data types are abstract data types, Encoding artefacts
like 'F' for padding shouldn't be seen by the user. Hence, let's
pass a 2-digit-long or 3-digit-long hexstring into the encoder
functions and let them determine if they should introduce any 'F'
for padding or not.
Change-Id: If4d3dfc16381493d7e710be746ed963975051fc1
The cell identifier used by the paging tests is 001-01, i.e. uses a
2-digit MNC. With the introduction of 3-digit MNC support in osmo-bsc,
the paging tests became incompatible with a osmo-bsc config with:
network country code 1
mobile network code 1
Explicitly declare a Cell_Identity with 2-digit MNC (includes an 'f').
Also, fix f_enc_mcc_mnc to properly encode 2-digit MNC values.
Related: OS#2847
Change-Id: Ide5228b403e43de8649b6eda18749ea2a9f592a9
It's a quite frequent requirement in encoding IMSI/BCD numbers, so
let's move it to the more generic GSM_Types module.
Change-Id: I6fb8d9a6f37c990f6901fb48b15312a157954fda
The existing code generating L3 sequence numbers in MO direction
made the assumption that the L3 message inside ComplL3 would always
be MM/CM, and increment the sequence number.
However, in case of a paging response, it is actually RR, which
does *not* have L3 sequence counters. So we must make the sequence
counter increment dependant on the L3 protocol discriminator.
Change-Id: I25a5dd0c180c9acfa870984c6b122ac0c46383b3
Oliver Smith
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Neels Hofmeyr
Eric Wild
Harald Welte
Philipp Maier
Daniel Willmann