In the inter-BSC 'Handover Required', do not send a LAI cell identifier,
but a CGI one.
Rationale:
As explained in OS#5188, 3GPP TS 48.008 allows a LAI identification only
in the Cell Identifier List IE, but not in the single Cell Identifier
IE.
In the inter-BSC HO test's Handover Required message, we so far send a
LAI identifier in a List IE to osmo-msc. And so far, osmo-msc simply
echos that in the Handover Request message's single Cell Id IE.
The LAI is, as actually defined in the spec, omitted from the single IE
in deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn, and when
osmo-msc sends the non-standard LAI Id, ttcn3 fails to parse the BSSMAP
Handover Request message: the Cell Identifier IE gets wrong values, and
all remaining IEs are parsed as 'omit' even though they are present on
the wire. So as long as osmo-msc sends back a LAI Id, we cannot sanely
verify the Handover Request received from the MSC.
The CGI identifier type is supported in both IEs. So when the test sends
a CGI identifier in the Handover Required, osmo-msc will also reflect a
CGI identifier in the Handover Request, and ttcn3 parsing works.
This prepares for adding verification of the ciphering in inter-BSC
handover, in turn a preparation for adding tests of A5/4.
Related: OS#5188 SYS#5324
Change-Id: I48276acf923626db171683dfa03ef43614a71380
Only ho-into-this-bsc tests are required, since the out-of-this-bsc
message (Handover Required) does not involve any encryption information.
Related: SYS#5324
Change-Id: I8de65eb9a5bd9a58add55e821f2a559c9a81edc1
In f_tc_ho_int(), verify encryption information for the handover
target's chan act.
Add test cases calling f_tc_ho_int() with various A5/n encryption modes.
Related: SYS#5324
Change-Id: Iaab26c708c106a61b762234d42ed9a52cdc2998c
The verification of correct encryption information so far is part of
f_cipher_mode(); put it in a separate new function f_verify_encr_info()
so that it can be re-used for handover channel activation.
Related: SYS#5324
Change-Id: I11602d23670f436a22b891fc744fe07e470f2b79
Sometimes, VAMOS related test cases fail due to a DTE:
Dynamic test case error: Sending data on the connection of port
CCHAN_PT to 1:RSL_CCHAN failed. (Broken pipe)
Call f_shutdown() to ensure that all components are properly
terminated, so there will be no race conditions like this.
Change-Id: I690412a29b24571109415d32b09543de459076d1
Related: SYS#4895
Allow only A5/4, but omit the Kc128 IE from MSC's msg. Expect Cipher
Mode Reject.
Related: SYS#5324
Change-Id: I7734a4a59797a9b21523c33f48815a8094f4e6ec
Implement tools for OsmoBSC a5/4 support testing:
- in f_cipher_mode() and f_check_chan_act(), expect Kc128 key as
appropriate, using recently added g_pars.encr.enc_kc128
- osmo-bsc.cfg: allow a5/4
Related: SYS#5324
Change-Id: Ifa48a8498dde7d04fb29f497013bdb5a1e5f3597
Instead of passing each part individually, simply pass the entire
TestHdlrEncrParams to f_cipher_mode().
Preparation for A5/4.
Add the kc128 to TestHdlrEncrParams instead of a function arg. kc128 is
so far unused, but will be used in an upcoming patch adding A5/4.
Related: SYS#5324
Change-Id: I2cb8282e55436da5ae64ab569df87d5d5a0dd2f0
reasons:
* TC_assignment_fr_a5_4() runs an unusual sequence of messages: it first
fully assigns an lchan, and after that sends a Cipher Mode Command.
Usually, the ciphering happens as part of attaching (Compl L3).
The new test TC_assignment_fr_a5_not_sup() does the ciphering in the
usual sequence, and properly expects a Cipher Mode Reject.
* TC_assignment_fr_a5_4 means to ask for an *unsupported* encryption
algo. Since we are going to introduce A5/4 support shortly, we'll need
to free up this name, for a successful A5/4 encryption test.
New test TC_assignment_fr_a5_not_sup() asks for A5/5 encryption, which
is not supported.
Related: SYS#5324
Change-Id: I83eca18d1b3d8d58177aa3750935ec5a3a985ca4
Since recently, we do have NOPE indications in the virtual Um
environment. Somehow this broke test cases for the MS power
control. Releasing the channel makes everything work again.
Change-Id: I6a204bbecfe116aa302eae28ff24d6bb899fa8b7
Related: SYS#5313, OS#1569, OS#1866
This adds a few tests that ensure that the encryption algorithm dynamically chosen is
1) one actually supported by both the sgsn and the UE
2) the strongest one available both have in common
Change-Id: Iad65cbf9840aa883cb34e53554b94a4142c82638
Related: SYS#5324
RAW_NS used previous a single TTCN3 port for a single UDP port
(source/listen side).
This has the limitation that only a single NSVC could be tested for a
local UDP port. However SNS tests require multiple NSVCs over a single UDP port.
NS_Provider_IPL4 already supports multiple NSVCs for the NS_Emulation.
Extend the support in NS_Provider_IPL4 to also allow RAW_NS to use
multiple NSVCs.
Related: OS#5036
Change-Id: Iafd9310e04066958914201da0cbdcd563bd5c976
The function didn't wait to receive the 2 messages from the BSC. As a
result, they may have arrived while tearing down the test components
shortly after exiting the function and provoke a Dynamic Test Error
while pushing the messages up the stack since some of the stack layers
may already be unavailable.
Test TC_ho_out_of_this_bsc() workarounded this by using a f_sleep(1),
but TC_srvcc_eutran_to_geran_ho_out() didn't, making it fail sometimes.
Change-Id: I590b09353900dfe6c4f648812ab675fed1908589
As 3GPP TS 48.016 § 7.4b.1.1 specifies this behaviour.
1. do success SNS configuration
2. change sig weight of the seconds inactive bind
3. add second bind to SNS
4. stop reacting to NS_ALIVE on first NSVC (only NSVC with sig weight)
5. expect SNS SIZE
Related: OS#5039
Change-Id: Id06e34e7235d94a06152a0015487a507d6492a97
1. do SNS configuration
2. add a bind
3. receive the SNS_ADD
4. before answering the SNS_ADD, change the weight via vty and remove the bind
Related: OS#5036
Change-Id: Ibc565bba4c7e0a0b4dd28a48847dbdb998c8528d
Recent changes [1] to osmo-bts make it periodically send the
RF RESource INDication messages for each transceiver over the
A-bis/RSL. These messages block the queue of 'RSL_CCHAN' port
and make the paging related test cases fail. Ignore them.
Change-Id: I18b879235c6eefb2dd89a3f4502b0830efeac6bb
Related: [1] Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
Some test cases change the weight of the binds. Ensure all test cases
starts with the same configuration.
Related: OS#5036
Change-Id: Iae2ba130b2f7d29ec8b417f07d0bef87f74ce5a4
The SGSN/PCU will use a different NSVC as the NSVC which will be changed weight'ed.
Related: OS#5036
Change-Id: I5766afaa74db30d94318312ab775e7933b9df783
A local tccn3 test run for VAMOS looks like:
while sleep 1; do osmo-bts-omldummy -f vamos 127.0.0.1 1234; done
osmo-stp
osmo-bsc -c osmo-bsc-vamos.cfg
make compile
make -j 5
../start-testsuite.sh BSC_Tests BSC_Tests_VAMOS.cfg
../log_merge.sh BSC_Tests --rm
Change-Id: Iabda4c864b02e6ddbf03386c75d67a37f92992f4
In BSC_Tests_VAMOS.ttcn, in f_est_and_reassign_to_secondary_lchan()
there is a missing channel release ack. By allowing ASP_RSL_UD, this rel
ack can be sent trivially.
Change-Id: Icd04184ed87c359349d86c5e0893c2ce9de2f7f1
BSC_Tests_VAMOS.ttcn is separate from BSC_Tests.ttcn in order to
instruct osmo-bts-omldummy to pass BTS_FEAT_VAMOS == true in the OML BTS
attributes.
Add tests:
TC_chan_act_to_vamos()
TC_mode_modify_to_vamos_fr()
TC_mode_modify_to_vamos_hr()
TC_assign_to_secondary_lchan_fr()
TC_assign_to_secondary_lchan_hr()
TC_vamos_multiplex_tch_f_tch_f()
TC_vamos_multiplex_tch_h_tch_h_tch_h_tch_h()
Change-Id: I2c504099163a30ea102cbd26d3615ca2e5ce1e64
In a recent osmo-bsc patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
c33eb8d56943b8981523754b081967e6ff5f245d
Ic665125255d7354f5499d10dda1dd866ab243d24
I accidentally changed the default behavior of the Training Sequence
Code sent to BTS and MS. So now, make sure that we verify the expected
Training Sequence Code in BSC_Tests, in:
RSL Channel Activate
RR Immediate Assignment
RR Assignment Command
RR Channel Mode Modify
RSL Mode Modify
Related: OS#5172 SYS#5315
Change-Id: Id67a949e0f61ec8123976eb8d336f04510c55c01
Without the SMLC routing in place, virtually all BSC_Tests fail with:
VirtSMLC-BSSAP_LE(8)@x42: setverdict(fail): none -> fail reason: "BSSMAP-LE: Timeout waiting for RESET-ACK after sending RESET"
Copy the SMLC part of osmo-stp.cfg from
docker-playground/ttcn3-bsc-test/osmo-stp.cfg and localhost-ize it.
Change-Id: I274515e7e9205c895cd250abed7361aef5a33f56
During f_create_chan_and_exp() (part of f_establish_fully()), announce
the BSSAP L3 expectation before activating the lchan.
In RSL_Emulation f_chan_est(), we go through Chan Request, Channel Act
and Immediate Assignment followed by EST IND. Right after that, osmo-bsc
sends a Complete Layer 3 on BSSAP. But in f_create_chan_and_exp(), we
only create the expectation of the BSSAP right after the call to
f_chan_est(), i.e. only after sending the EST IND. So far it was always
juuust in time to work, but when I added a little check to the end of
f_chan_est(), or alternatively an f_sleep(0.2), then BSC tests always
fail with:
Test case TC_reassignment_fr finished. Verdict: fail reason: Couldn't find Expect for incoming connection { [...] pdu := { bssmap := { completeLayer3Information... }
With the BSSAP expectation done first, this error is avoided.
Change-Id: I1d4af737dcc0f9c9fa6cdaff3a92813d532e730c
In a busy network, there can be a significant delay between resource
allocation (Packet Uplink Assignment above) and the actual time when
the MS is allowed to transmit the first Uplink data block.
Verify Timing Advance value indicated in Packet Uplink ACK/NACK message
sent in response to the first Uplink block after resource allocation.
Change-Id: I30f82c51b3e9a167af4dbce3e74697dd79ff15bf