The MSC pooling feature is implemented in osmo-bsc
Ifbdea197b26e88751a391c8a80c41f04e7d5e047.
A VTY command ('mscpool roundrobin next') that allows deterministic testing is
added in I2155d906505a26744966f442ffb1e87a6a9b494c.
osmo-bsc.cfg changes needed for these tests to succeed are in docker-playground
I1986e4ef43beee161c82193694421b56136c1afe
The new tests will fail until the above have been merged.
Change-Id: I21cbab193cd0de2e5692665442eae113d5f61904
Add BSSAP_N_UNITDATA_req to RAN_Conn_PT, so that we are able to send a Paging
from a test function that runs on MSC_ConnHdlr.
This will be needed by upcoming MSC pool tests, see
I21cbab193cd0de2e5692665442eae113d5f61904.
Change-Id: I36d486db05169b0fc3f19112b5a9008248d62930
For tr_RSL_PAGING_CMD, also check comp_ref against null.
Upon receiving a tr_RSL_PAGING_CMD, the code tries to dispatch the Paging
Command to all valid clients. However, the ConnectionTable[*].comp_ref is
*always* present, and actually null for unconnected clients.
So, before this patch, a Paging Command from osmo-bsc gets sent to a null
client, which disconnects the RSL emulation and aborts the test.
There is currently no test using this, but the upcoming MSC pool tests will:
see I21cbab193cd0de2e5692665442eae113d5f61904.
Change-Id: Iaf7730153a3a19e448a33298c3e12212a55929d5
Unlike the RSL_IE_MS_Power, where power_level is 5 bit long, in
the RSL_IE_BS_Power it's 4 bit long. Fix this.
Change-Id: Ic0cb2275ef585754b9ae5e3d8077ca652afd9365
f_gen_imei() calls f_enc_IMEI_L3() with a 14 digits argument, but the IMEI_L3
template used is hardcoded to 15 digits. So the oddevenIndicator must always
indicate odd, not depend on the digits argument.
f_gen_imei() should probably also compose a Luhn checksum, leaving that to
another patch.
Found by using the new osmo_mobile_identity API in osmo-msc, which is stricter
about odd/even and filler digits than our previous implementations.
See osmo-msc Idfc8e576e10756aeaacf5569f6178068313eb7ea .
Change-Id: Iaa9ba1214c4c15fd9620e68fe2e842fdf52912c0
Unfortunately, the latest release of osmo-bts still has a bug,
that has been fixed [1] in the recent master. Because of that,
most of the test cases in ttcn3-bts-test-latest currently fail.
The problem is that all transceivers use IPAC_PROTO_RSL_TRX0,
regardless of what the BSC tells them to use. Let's work this
around by patching IPA stream ID in ASP_RSL_Unitdata messages
coming from the IPA emulation.
[1] I5927f59a49724170a63e87be604973f7c9d5d8be
Change-Id: I66cecc9ea24ba79e1a03492e3fda2874951d37a0
- Get rid of f_L1CTL_DM_EST_REQ, it's not really needed.
- Derive ts_L1CTL_DM_EST_REQ_H0 from ts_L1CTL_DM_EST_REQ.
- Turn all its params into (value) templates.
- Turn it into a (value) template itself.
- Pass GsmArfcn directly to ts_L1CTL_DM_EST_REQ_H0.
Change-Id: I4f275e22d4309a23b4ed301a0779c4ecb92023a8
Related: OS#4546
Let's test the code path where UL TBF is requested through DL ACK/NACK
here, since we already test the usual UL TBF through CCCH approach in
most tests.
rlc_mode is changed to ACKED since that's the mode we are using so far
in tests.
Change-Id: I5a9a2e8107c87fdbf74cc2f09ae5eeafbb13ad55
Since change [1], the IPA emulation component allows us to handle
multiple IPA connections, thus multiple RSL connections. The idea
is to attach a TCP/IP connection identifier to each message.
On top of that, this change implements mapping between TCP/IP
connection identifiers and RSL stream identifiers, so we can
finally talk to any of connected transceivers (up to 4 for now),
not only the last connected one (as it was before). The actual
mapping is done during the IPA identification procedure.
Instead of forwarding ASP_IPA_EVENT_UP to a test case, the RSL
emulation component now sends a new event - RSLEM_EV_TRX_UP,
with transceiver number (actually, IPA stream-id) attached.
[1] I93c58c08cf296e5cea81d811650caa1a09b8a579
Change-Id: I86afb55ecc6703ce7a229aaa626223f9331a4778
Related: OS#4546
This would allow the RSL Emulation component to maintain several
transceiver connections in server mode. In order to send an RSL
message to a specific transceiver, its TCP/IP connection ID needs
to be included in the ASP_RSL_Unitdata message.
Change-Id: I5c48d043cd746aad03e4329d9ffd2a627b640f64
Related: OS#4546
This change basically does two simple things:
a) adds TCP connection identifier to ASP_IPA_Event,
b) splits g_ipa_conn_id into g_self_conn_id and g_last_conn_id.
Change a) would let the upper layers of code (based on the IPA
emulation component) know which TCP/IP connection a given event
belongs/relates to.
Change b) solves the problem, happening in server mode when a new
client connects, and TCP/IP connection identifier of another
previously connected client gets overwritten.
With this change applied, g_self_conn_id holds TCP/IP connection
identifier of the client or server itself (depending on g_mode),
while g_last_conn_id is only used in server mode and holds
connection identifier of the last connected client.
Change-Id: I93c58c08cf296e5cea81d811650caa1a09b8a579
Related: OS#4546
As a side effect of change [1], the RSL emulation component has
stopped to handle RSL messages from transceivers other than
TRX#0. Let's fix this by using template '?' for stream ID.
[1] I4c4a98458cfa33512db661b5435f484a38e2ef4f
Change-Id: I5ff05bbd985ddc5e39a390e4b775a16f066a53ea
Some stuff like EGPRS Ack/Nack description is still not implemented, but
it's enouh for now to be able to match against this kind of ACK blocks.
Change-Id: I8066fba0e71911f0c6344c1540a501f1853daa7f
The old name was a bit confusing, because this enumerated type
also contains ASP_IPA_EVENT_ID_ACK, among with UP/DOWN events.
Change-Id: I8f73a64de40d1c8e9b7f43f538d6b59dcede065f
Some types already available in GSM_RR_Types.ttcn will also be required
by messages sent over PDCH and which belong to RLCMAC_CSN1_Types. Since
GSM_RR_Types.ttcn already requires RLCMAC_CSN1_Types.ttcn, let's move
them there so they can be used in both places.
Change-Id: Iccaaa2743dc44a36046c19d4d4ff882dc02fb479
Old code was not setting Single Block Packet Access type, and 2phase
access was not properly triggered.
Once it's triggered, message flow changes quite a lot from the 1phase
access, specially because the 2nd Ul Assignment arrives through PDCH
instead of CCCH, which means a different record is received and hence
code for 1phase cannot be easily re-used.
For similar reasons, f_tx_rlcmac_ul_n_blocks() is modified to receive
the only required tfi param instead of a full dl_block.
Some functions are also extended to support SingleBlock Allocation
instead of usual DynamicAllocation.
Change-Id: If636a4898dfa175fdbd6baf04f7f2c955a9c525d
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
This function was written in a way that it tries to do as
many different (but related) things as possible:
a) send an RTS.req to the IUT, expect a DATA.ind in return,
b) decode RLC/MAC message contained in the received DATA.ind,
c) make sure that it's either GPRS or EGPRS data block,
d) calculate the last TDMA frame number of RRBP using
f_rrbp_ack_fn() regardless of its validity,
e) make sure that the block contains a given LLC payload.
Everything is ok except point d). The problem is that this is
only the case for the first block of RRBP, and not applicable
to the rest having 'rrbp_valid' flag unset. Furthermore, this
function did not match GPRS DL blocks with 'rrbp_valid' flag
unset, for some odd reason.
Let's move RRBP calculation into a separate function called
f_dl_block_ack_fn() and return TDMA frame number of the
received DATA.ind message instead.
Among with that, there are more little changes:
- simplify matching of (E)GPRS DL data blocks,
- use 'in' qualifier in parameter list where possible,
- turn parameter 'data' into a template (present).
Change-Id: I1528408b4399d0a149a23961805277eaab90d407
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Let's make this template more flexible, so it can be used to match
any GPRS DL data blocks, not only those with rrbp_valid == true.
Note that behavior of f_rx_rlcmac_dl_block_exp_data() is
intentionally left unchanged, and will be fixed later.
Change-Id: I3940216368cdbb58fe89420675d1d8d5f5e49b05
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
This template is not (yet) used anywhere, but let's fix it
anyway to avoid possible confusion.
Change-Id: Ic819f2b0eb292170de73abc7e200d79fcf02a76c
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
The resulting frame number shall be within the period of TDMA hyperframe.
Change-Id: I794a14f69293cbbc937d62d09dd5794956b882db
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Finally, we can get rid of hard-coded octetstrings and control
every field of the Rest Octets we're sending to the IUT.
Note that template 'ts_SI4_default' did not contain any Rest
Octets at all, thus the GPRS indicator was (and still is)
absent. This will be fixed in a follow up change.
Change-Id: I0a95b34b495267edf1f48692e24fcd5ede8ccdd1
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Due to a buggy nature of TITAN's padding attributes [1], we cannot
apply them to individual fields of the records that are embedded
into other structured types, like records and unions.
Ensure that encoded System Information messages are padded to
either 23 or 19 octets, depending on their type. In order to
achieve this, rename and wrap the external encoding function.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562849
Change-Id: I3368df52985e576ad180c9a74d4925dd9c952b55
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
As it turned out, the length constraints introduced in [1] were
too strict. In particular, the use of FIELDLENGTH attribute made
it impossible to assign an octetstring of a smaller size and then
pad the remaining octets with '2B'O. TITAN would just use '00'O
instead, ignoring all my attempts to talk some sense into it.
[1] I183d3ba9000e3ced8ecce74a4390b80075ddf25d
Change-Id: Ie1b6d4100c064b6ae08ed55cd797b9416c6faf14
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
The 'RestOctets' is a sub-type of the 'octetstring' with additional
padding attributes. Let's use it for SI2bis, SI2ter, and SI6 too.
Change-Id: I183d3ba9000e3ced8ecce74a4390b80075ddf25d
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Both are basically sub-types of GSM_RR_Types.RestOctets with length
constraints. We don't really need to have them as separate symbols,
especially since we have SI3RestOctets and SI4RestOctets now, so
let's apply these constraints within the corresponding records.
Change-Id: I2b126348ae5c5425fea4267ab2b77ea0192795ac
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Optional "Rest Octets S" part is left for later.
Change-Id: Ib0814e79f8627f3e2b4746b7e521e06ff82bf2d7
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Commit [1] introduced multiple regressions, because it basically
changed the byte order in all fields of the whole module from
'first' (implicit default) to 'last'. This is not what we need.
Instead, let's apply BYTEORDER(last) to 5 bit 'ext_ra' fields
unless the bug [2] in TITAN's RAW codec is fixed.
[1] I481a40daef3eed4a3daa687ad87c4128a13181b4
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562488
Change-Id: If998ef72c13787f04fee79e1e646cd9a6787028a
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
They will be used by tests, templates and RLCMAC_EncDec.cc itself.
MCS HEader Type 1 and 2 to CPS conversion lefts as a TODO with
placeholder functions to easily implement when needed.
Change-Id: I18ff55a8067165bf081bf21473b4f88af955bf5b
RLCMAC blocks have a lot of fields and we will potentially require lots
of different templates, as well as functions to handle related structs.
Change-Id: I9c6597178168aa3848b21930f33be698dd2ce545
* RlcmacUlBlock and RlcmacDlBlock gain a new union field "egprs_data",
which is chosen when msg contains an egprs data block. Hence one can
use same structure for both gprs/egprs data and simply check
"ischosen(block.data_egprs)" to know whether it contains egprs or gprs
data block.
* C++ code in RLCMAC_EncDec.cc takes care of encoding and decoding of
each data header type and exposes a generic ttcn3 struct
"UlMacDataHeader" and "DlMacDataHeader". Decoded header type can be
found in mac_hdr.header_type. This can be used t5ogether with CPS to
get the MCS of the message received. Similarly, the encoder will use the
same field to know how to encode the ttcn3 structure.
* In RLCMAC_EncDec.cc order of functions has been ordered to split
between encoding and decoding, and inside these split between Ul and
Dl messages.
* Only encoding of UL HeaderType3 and decoding of Dl HeaderType3 is
implemented so far in RLCMAC_EncDec.cc. However, all code is already
arranged and functions prepared (with FIXME fprintf) to easily add the
missing header types once needed.
* Actually only the decoding of DL HeaderType3 has been tested to work so far.
Encoding may still be missing to octet-align the data block after the header.
All these wil lbe fixed once a test using them exists.
Change-Id: I2bc4f877a5e17c57ffa8cf05565dc8593b45aae8
On top there's a lot of types related to data blocks. Having more
stylish section header helps orientating one self while looking through
the data blocks.
Change-Id: I87d4694031ea6874b233626818824cdc4f3505c6
Change [1] introduced a regression: PCU_Tests_RAW.TC_pcuif_suspend
fails since build #443. I have no idea why the BYTEORDER should be
set to 'first' (and not 'last'), but this is the only way I could
make TITAN's RAW encoder generate a valid MCC/MNC pair again.
[1] I481a40daef3eed4a3daa687ad87c4128a13181b4
Change-Id: I70a5b2eed3788be10d62fa421e3ba7444d66c655
Test sending MS RA capabilities through Packet Resource Request to
update GPRS multislot class.
EGPRS multislot will come in a later commit.
Change-Id: I5026d8b78a3fb82093956b65989d18fa6f6d5424
This change introduces three similar test cases:
- TC_egprs_pkt_chan_req_signalling,
- TC_egprs_pkt_chan_req_one_phase,
- TC_egprs_pkt_chan_req_two_phase,
which basically send several 11 bit RACH.ind messages to the IUT
containing different variations of EGPRS Packet Channel Request.
Depending on the establisment cause, for each RACH.ind we expect
to receive an Immediate Assignment containing an EGPRS Packet
Uplink Assignment in its Rest Octets.
All test cases make sure that Request Reference in the received
Immediate Assignment messages is set to 127 as required by 3GPP
TS 44.018 (see table 9.1.8.1, note 2b), and the Extended RA IE in
the Rest Octets matches 5 LSBs of the RA value that was sent.
Change-Id: Ib5732956ea160f93d82f06bf82bea45501f439d2
Related: OS#1548
By default, the BYTEORDER for BIT1..N sub-types is set to 'first'.
This may result in incorrect decoding of bit-fields located on the
boundary of two octets. For example:
IA Rest Octets
L... .... = First Discriminator Bit: Low
.H.. .... = Second Discriminator Bit: High
..0. .... = Discriminator bit: EGPRS Packet Uplink Assignment
...0 .... = Downlink/Uplink: EGPRS Packet Uplink Assignment
EGPRS Packet Uplink Assignment
.... 0001 1... .... = Extended_RA: 3 // <------------ (!)
.0.. .... = Access Technologies Request: Not Present
..1. .... = TFI/Multiblock: TFI Assignment Present
...0 0000 = TFI_Assignment: 0
As can be seen, the field 'Extended_RA' in this particular case
occupies 4 LSBs of the first octet and 1 MSB of the second. So
instead of '00011'B, TITAN's RAW codec decodes '10001'B.
For more details, see:
https://www.eclipse.org/forums/index.php/m/1826511/https://bugs.eclipse.org/bugs/show_bug.cgi?id=562488
Change-Id: I481a40daef3eed4a3daa687ad87c4128a13181b4
If mp_pcrf_local_ip is set to a non-empty string, the PGW testsuite
now emulates a PCRF and expects the PGW to perform the related
transactions - so far Credit-Control-Request INITIAL_REQUEST
at session creation, and TERMINATION_REQUST at session deletion.
Change-Id: I5f0c7a66d38e5c8b5f36b45717d49648a14ed7b2
During start of the test case, we must wait until the IUT has
established a DIAMETER/SCTP connection to the testsuite. Implement
this by means of a message on the DIAMETER_UNIT port and an associated
helper function.
Change-Id: I95434307efc67025ee6d373561f6d22398f959c5
So far, we hard-coded the Capabilities-Exchange-Answer for
HSS emulation. As we want to emulate other DIAMETER network
elements, let's parametrize the template as well as the respective
parameters for the emulation component.
Change-Id: Ie30ff1bac40ab3dc6058587f0586b643ff2b0cb6
Ths IMSI on the Gx interface is encoded into a different AVP than
on the S6a/S6d interfaces. Let's make sure our DIAMETER_Emulation
knows both formats.
Change-Id: I299fcc2e01e908914df32fda4fb93b1114402c77
This adds more DIAMETER types to our TTCN-3 module, specifically those
encountered on Gx between PGW and PCRF.
./AVP.sh Base_IETF_RFC3588.ddf BaseTypes_IETF_RFC3588.ddf AAAInterface_3GPP_TS29272_f10.ddf GxInterface_PCC_3GPP_TS29212_f10.ddf S6Interfaces_3GPP_TS29336_f00.ddf MobileIPv6_HA_IETF_RFC5778.ddf RxInterface_PCC_3GPP_TS29214_f20.ddf NetworkAccessServer_IETF_RFC4005.ddf CreditControl_IETF_RFC4006.ddf CxDxInterface_3GPP_TS29229_c30.ddf GiSGiInterface_3GPP_TS29061_d70.ddf
Change-Id: Ibe7321e695337ff62fdc912270f6e13e6c6d6cf2
it seems TITAN no longer supports 'ifpresent' in certain situations,
see https://www.eclipse.org/forums/index.php/m/1826175/#msg_1826175
Let's make the tests fail if we actually run in those cases, but at
least compile fine and be able to execute all the other tests.
Change-Id: Ia401c2d696979c0062872bca8da62c2ea153427b
All the records related to Mobile Identity IE (see 3GPP TS 24.008,
section 10.5.1.4) are defined in [1], so there is no real need to
dumplicate them. Moreover, most of the related templates in
library/L3_Templates.ttcn are based on these records.
[1] titan.ProtocolModules.MobileL3_v13.4.0/src/MobileL3_CommonIE_Types.ttcn
Change-Id: I27c2743c59db770d6f7e9447dc8c1f539b228ced
This additional couple of test cases reveals several bugs:
1) the IUT encodes a erroneous RR Paging Request message
containing P-TMSI, so TITAN fails to decode it;
2) the IUT prints an invalid P-TMSI in its log output
due to load of misaligned address (found by UBSan).
[1] I97fd5ffc15a4a58112d7c37c69b7ac42b0741a0e
[2] Icf8836f216793e342b239c8e6645aac1e82bf324
Change-Id: I7fbec5b2c5c3943a7413417b623f55c135c152d7
The license disclaimer already stated GPLv2-or-later, it just stated
confusingly you should look at the AGPL for reference. Fix that.
Change-Id: I673c5c177a8e4010921f1fed747ce376f274da54
TTCN-3 interestingly doens't seem to have any case-insensitive string
matching or functions to convert to uppwer/lowercase.
Change-Id: I2e6e0fd2da001a3cc6d9c31c9e766ae54bf17b2f
Used by upcoming D-GSM test, to pass the IP of the emulated GSUP server.
The code is based on f_enc_dns_hostname() in the same file.
Related: OS#4380
Change-Id: I8a5450988711680c93cfd657a34db759a56bc41e
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
Send an mslookup mDNS request to the home HLR, asking about a service
that is not "gsup.hlr". Hence the "_other" in the test name, service
"gsup.hlr" has different code paths, and related tests will be added in
follow-up patches.
This is the first test using MSLookup_mDNS_Emulation, so add related
test infrastructure.
Related: OS#4380
Depends: osmo-hlr I2fe453553c90e6ee527ed13a13089900efd488aa
Change-Id: Ia7f92d33691f910549353b16a7b0efc18e521719
Existing templates are moved to SCPP_Templates.ttcn and new ones
required for the test are added there.
Related: OS#4343
Change-Id: I7b56fe77ac3b350d722c74b043e6ecabc48dcf31
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
We already have 16 entries in the GsupImsiTable. Let's also extend
the GsupExpectTable, so we can have 16 components of type
BSC_ConnHdlr running in parallel.
Change-Id: Ibca0e9196c25ab00803041b81f7b490ba2f0a3ba
On channel establishment the first measurement result may lack the
measurement reports from the MS. This is normal behavior, so lets
tolerate that.
Change-Id: Ib2f511991349ab15e02db9c5e45f0df3645835a4
Related: OS#2975
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
Old versions of osmo-pcu print "Osmo-PCU" as VTY prompt. This commit
allows supporting this kind of prompt.
Change-Id: Ia5acbbe5828901726f7f15c4a99d596e94914c4b
Function f_rx_rlcmac_dl_block_exp_data() still misses proper
verification of data. Apparently the received message has 2 blocks,
first with expected 10 bytes, but next one contains 18 bytes with 4
actual bytes and other bits are padding.
Last DL ACK/NACK sent is not yet working correctly. osmo-pcu seems to be
unable to match it against sent DL block (I think due to non-matching
FN), and instead drops it and schedules after timeout an IMM ASS to try
to send DL block again.
Change-Id: Icf66dd5c07690368722c586632c38fb7e770053c
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
There's also DL_ACK_NACK message for which a template will be introduced
soon, so let's rename and fix typos/wrong descriptions to avoid
confusion later.
Change-Id: I4a2025ad282006953fcfadf429c980b77cb94371
Default the MNCC version to the current osmo-sip-connector's master branch MNCC
version.
As soon as the new version (6) is merged, we can bump it here to make tests for
master work again.
For 'latest' builds, we can adjust osmo-ttcn3-hacks to use version 5, and also
see those tests still passing.
Change-Id: I3eb6e0132dc99ebe41a98cc5c329ed4864b770d6
Make sure it is * everywhere, not "". Partially fix the SIP tests, where
tr_MNCC_RTP_CONNECT did not match anymore:
13:15:27.516387 5 SIP_Tests.ttcn:219 Message enqueued on MNCC from SIP_Test-MNCC(3) @MNCC_Types.MNCC_PDU : {
msg_type := MNCC_RTP_CONNECT (517),
u := {
rtp := {
callref := 5001,
ip := 0,
rtp_port := 0,
payload_type := 0,
payload_msg_type := 0,
sdp := "0"
}
}
} id 3
13:15:27.516604 5 SIP_Tests.ttcn:221 Matching on port MNCC .u.rtp.sdp := "0" with "" unmatched: First message in the queue does not match the template:
Together with I522ce7f206932a816a64f03d916799c3215bb8c7 in
osmo-sip-connector.git, this makes the testsuite work again for
osmo-sip-connector master.
In order to fix the TTCN-3 tests for the latest release, we would need
to add a second code path to the TTCN-3 code, that does not send the sdp
data based on a configuration option. Considering that I've spent quite
some time already to fix this up, it does not seem worth the effort.
Related: OS#4282
Fixes: 06b859ca31 ("msc: add sdp to MNCC")
Change-Id: Ic7a2df0b6faeaa88682880f816518618ced79a7e
* 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
SDP is added to the MNCC protocol in osmo-msc
Ie16f0804c4d99760cd4a0c544d0889b6313eebb7.
This patch adds SDP to the ttcn3 MNCC messaging.
These changes still work with current osmo-msc master that doesn't send SDP /
ignores received SDP in MNCC.
Change-Id: Ic9568c8927507e161aadfad1a4d20aa896d8ae30
Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: Ia5c4e504a21dc5508920553d3856027455dba1b1
Related: OS#4102, OS#1545
vsmartcard.git contains an implementation of a virtual card reader
(vpcd) which registers with PC/SC (such as pcsc-lite). It simply
binds to a TCP port and waits for a TCP client to connect to it,
implementing APDU transfer over TCP.
This code implements the related protocol as a TTCN-3 test port
for Eclipse TITAN, which will enable us to implement a 'virtual smart
card' in TTCN-3 tets cases, primarily for testing remsim-bankd at
this point.
Change-Id: Iac37dd231a0f2e1efd484887bca1a9d672b446bb
In the past, we were automatically running [large parts of] the nplab
M3UA and SUA test suites, but those implement only a fraction of the
functionality. Particularly, they don't cover the non-standard IPA
behavior, and they don't cover RKM (routing key management).
Let's introduce an initial set of STP tests with this patch. We try
to not duplicate nplab here, and implement bits not covered there.
Change-Id: I628a87385cac0dfe708a0d74a5088fbd5a4790cd
Split f_mgcp_find_param_entry() out of f_mgcp_find_param() to be able to act on
an MgcpParameterList without an enclosing MgcpMessage.
Will be used by upcoming I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
Change-Id: I90f213d2a1be979afa024e0faa25d532f9858636
This test case is aimed to verify handling of both PTCCH/U and
PTCCH/D logical channels, recently implemented in [1]. This is
done by sending 16 Access Bursts on PTCCH/U, and then by
sending a random data block on PTCCH/D.
The existing TC_pcu_data_req_ptcch does not cover PTCCH/U, and
moreover involves TBF handling which has nothing to do with
PTCCH. Let's keep it anyway.
[1] I232e5f514fbad2c51daaa59ff516004aba97c8a3
Change-Id: I011ffdfa63b698ce6085968d15ffb4ff4bd23ee5
Related: OS#4102
Do not hard-code PCU_IF_SAPI_RACH for RACH.ind templates. We need
to be able to specify other SAPIs (PCU_IF_SAPI_PTCCH) in the
upcoming test cases for Timing Advance control.
Change-Id: I7e2ebcbba5e47cf44f064e429c0517ef3acb15af
This message is sent on PACCH by the network to the mobile station
in order to update the mobile station timing advance or power
control parameters. See 3GPP TS 44.060, section 11.2.13.
Change-Id: Ie07000b08918501a99962ad760932a27eacae678
According to 3GPP TS 44.018, section 10.5.2.16 "IA Rest Octets",
the first bit of Packet Uplink Assignment defines whether it is
a dynamic (1) or single block (0) allocation.
Change-Id: If2bee9b1b065fcfedd0e57a6487040cefe2e50c5
This change introduces a new test case TC_cs_lqual_ul_tbf, which
is aimed to test the feedback of OsmoPCU on changing link quality
measurements in Uplink Data blocks during an active TBF.
Change-Id: Ia78d93e43a3c41b0b30e70df20a2da31077fd05f
Related: SYS#4607
In Ieefa61232eb215a19a02e490255332e28e23b8f8, I had to revert
I5808954b5c67c3239e795e43ae77035152d359ef, because that change
broke encoding of messages on the PCU interface.
Since we cannot use 'PADDING' attribute until its implementation
is fixed in TITAN, let's work this around by stripping padding
bytes manually in UD_to_PCUIF().
Change-Id: Ibd698094c897d395208e80189457444a91018beb
This change implements UL Packet Resource Request message as per
3GPP TS 44.060, section 11.2.16 (only mandatory fields), and a
send template 'ts_RlcMacUlCtrl_PKT_RES_REQ' for it.
Change-Id: I0d688beb4112d6db10ac89e2966b555e74887a6e
The problem of existing test cases is that they mix IUT (i.e. OsmoPCU)
with OsmoBTS (osmo-bts-virtual) and OsmocomBB (virt_phy). This approach
allows to avoid dealing with TDMA clock indications and RTS requests on
the PCU interface - this is done by OsmoBTS. On the other hand, our test
scenarios may be potentially affected by undiscovered bugs in OsmoBTS
and the virt_phy.
In order to solve that problem, this change introduces a set of new
components and the corresponding handler functions:
- RAW_PCUIF_CT / f_PCUIF_CT_handler() - PCU interface (UNIX domain socket)
handler. Creates a server listening for incoming connections on a given
'pcu_sock_path', handles connection establishment and message forwarding
between connected BTS components (see below) and OsmoPCU.
- RAW_PCU_BTS_CT / f_BTS_CT_handler() - represents a single BTS entity,
connected to OsmoPCU through the RAW_PCUIF_CT. Takes care about sending
System Information 13 to OsmoPCU, forwarding TDMA clock indications from
a dedicated ClckGen component (see below), and filtering the received
messages by the BTS number. Implements minimalistic scheduler for both
DATA.ind and RTS.req messages, so they are send in accordance with the
current TDMA frame number.
- RAW_PCU_ClckGen_CT / f_ClckGen_CT_handler() - TDMA frame clock counter
built on top of a timer. Sends clock indications to the BTS component.
All components communicate using TTCN-3 ports and explicitly defined sets
of messages (see RAW_PCU_MSG_PT). One noticeable kind of such messages is
events (see RAW_PCU_Event and RAW_PCU_EventType). That's how e.g. the PCUIF
component can notify the BTS component that OsmoPCU has just connected, or
the BTS component can notify the MTC that SI13 negotiation is completed.
Events may optionally have parameters (e.g. frame-number for TDMA_EV_*).
Furthermore, the proposed set of components allows to have more than one
BTS entity, so we can also test multi-BTS operation in the future.
+-----+ +----------+ +---------+
| MTC +---------------+ PCUIF_CT +------+ OsmoPCU |
+--+--+ +----+-----+ +---------+
| |
| |
| |
| +-----------+ | +---------------+
+----+ BTS_CT #1 +------+ | ClckGen_CT #1 |
| +-----+-----+ | +-------+-------+
| | | |
| +---------------------------+
| |
| +-----------+ | +---------------+
+----+ BTS_CT #2 +------+ | ClckGen_CT #2 |
| +-----+-----+ | +-------+-------+
| | | |
| +---------------------------+
| |
| +-----------+ | +---------------+
+----+ BTS_CT #N +------+ | ClckGen_CT #N |
+-----+-----+ +-------+-------+
| |
+---------------------------+
Change-Id: I63a23abebab88fd5318eb4d907d6028e7c38e9a3
For me this change causes MGCP parsing errors:
setverdict(fail): pass -> fail reason: "Could not extract parameters for code "C""
Apparently the \r is after all necessary to parse MGCP. Maybe the '\r' is
implicit when an '\n' occurs, but the non-SDP part of MGCP has *only* '\r' line
breaks.
This reverts commit a9a52fff15.
Change-Id: I81d105b951590310c67f14f0b5d0c2777e206c5e
Remove implied \r to fix following warnings:
"Duplicate character `\r' in the character set. Please note the \n
includes the \r implicitly. Use \q{0,0,0,10} if you would like to match
the LF only."
Change-Id: I99948e4b82b5b4bd5b8f7c1a4c60a97fcab3c0eb
Get rid of template t_IMM_ASS, which is a part of L1CTL_Types.ttcn.
Prepare generic (for both CS and PS) template on top of tr_IMM_ASS,
and use it in f_L1CTL_WAIT_IMM_ASS().
Change-Id: I3a410ec3c41e3eefd23071bfb0d80feda82177a5
This is a TITAN specific attribute that allows to indicate that
a field of type 'charstring' is '\0'-terminated. Without that
attribute, 'PCUIF_Text' is mixed with the padding characters:
"0.7.0.5-df0f" & char(0, 0, 0, 0) & char(0, 0, 0, 0) & ...
Change-Id: Ic81fff4c82871bb29a2385b9ee7a2dd98f67dfb0
This reverts commit dd6d5d1baa.
The PADDING seems to be a very experimental feature of TITAN. It works
very well for decoding of messages, so the padding bytes are getting
recognized as expected, but encoding is broken. Not only the data
buffer and its length are encoded in a wrong way, but other fields too.
Change-Id: Ieefa61232eb215a19a02e490255332e28e23b8f8
Get rid of t_IMM_ASS_TBF_UL_DYN, use tr_IMM_TBF_ASS instead. Also,
use both tr_PacketUlDynAssign and tr_PacketUlSglAssign for matching
UL TBF assignment.
Change-Id: Icb7dab04a1e2a833c14754d872bd4b85af3d58a5
Both 't_IMM_ASS_TBF_DL' and 't_RR_IMM_ASS_TBF_DL' templates were
introduced for a specific task - matching Packet Immediate
Assignment (Downlink TBF) by TLLI.
In the upcoming changes we will also need to match Uplink TBF
assignment, and more generic fields such as Timing Advance.
Let's add a generic template for Packet Immediate Assignment
and allow passing IaRestOctets as a parameter.
Change-Id: I492cf990820ba153ea71469b8b623e56e031e549
According to 3GPP TS 44.018, section 10.5.2.16, IA Rest Octets IE
starting with 'HH' bits may contain one of the following CSN.1
encoded components:
7 6 5 4 3 2 1 0 Bit Numbers
H H 0 0 . . . . Packet Uplink Assignment
H H 0 1 . . . . Packet Downlink Assignment
H H 1 . . . . . Second Part Packet Assignment
We already have (partial) support for the first two, while the
last type has not been supported so far. Let's add it.
Also, this change introduces several templates for IA Rest Octets
IE and some of its components mentioned above. This would allow
us to abstract the API users from dealing with further changes,
e.g. adding a coding attribute 'CSN.1 L/H' and missing fields.
Change-Id: Ib3a21e7c5fa1cad4466e3a09fa70540de7f6ecc5
For some reason TITAN starts padding not from the beginning of
record ImmediateAssignment, but from it's wrapper GsmRrMessage.
As a result, dec_GsmRrMessage() warns about undecoded octets:
Data remained at the end of the stream after successful decoding '2B2B2B'O
Similarly enc_GsmRrMessage() generates a shorter payload. Let's
work this around by applying PADDING attribute to GsmRrMessage.
Change-Id: I5fe327383402956213c20a68b18b8a48381156b5
Since I403d2141536303a966be7ff51b06c3de202412e6, IA Rest Octets is
a mandatory IE. When changing the definition of ts_IMM_ASS, I forgot
to mark its optional 'lh', 'hl', and 'hh' as omitted explicitly.
As a result, many of our TTCN-3 test cases were broken:
Dynamic test case error: Using an unbound optional field.
Also, in Ifdcdcf50709fcc03195cb8ef6092977e26f910ec I added an
optional field 'pad' to record 'IaRestOctets'. That was not the
best solution, because padding should be handled transparently.
Let's get rid of that dummy field and equip both 'ImmediateAssignment'
and 'IaRestOctets' records with proper padding attributes. The later
one needs to be marked with 'CSN.1 L/H' attribute in the future, but
for now we should keep it octet-aligned.
Change-Id: I69d5fbd8e3388e287bfa54f02454d207e62ee640
When the BSC receives an ETWS PN via CBSP, it must send it through all
established dedicated channels of the matching BTSs.
Related: OS#4046
Change-Id: Ib057bd251604e9bae968e71de245b3bbf737a356
All MS/UE must be notified of ETWS Primary Notifiations.
Depending on their state, the notification goes different paths:
* CS dedicated mode: BSC sends it as L3 message over LAPDm / DCCH
* CS/PS idle mode: BTS sends paging messages on PCH
* PS TBF active: PCU send Packet Application Info
This tests the last of the three methods by checking that a ETWS Primary
Notification sent on RSL to the BTS is received by the PCU socket.
Change-Id: I2661df7f7d870a0ac1c89bb8a85df81644b00b0a
Related: OS#4047, OS#4048
Depends: osmo-bts Ic0b3f38b400a0ca7e4089061ceb6548b0695faa6
According to 3GPP TS 04.08 (version 7.21.0), section 10.5.2.16 and
table 10.5.45, IA Rest Octets IE may contain spare bits. Let's add
an optional field 'pad' to record 'IaRestOctets'.
NOTE: somehow this change crashes my TITAN runtime:
dec_GsmRrMessage(): Stream before decoding: '2D063F100FE3673A096B0000C800300B2B2B2B2B2B2B2B'O
*** Error in `././PCU_Tests': malloc(): memory corruption: 0x000000000074a790 ***
while the recent version works just fine.
Change-Id: Ifdcdcf50709fcc03195cb8ef6092977e26f910ec
According to 3GPP TS 04.08 (version 7.21.0), table 9.18, IA Rest
Octets (see 10.5.2.16) is a mandatory IE, not optional.
Change-Id: I403d2141536303a966be7ff51b06c3de202412e6
PADDING is one of the TITAN specific language extensions [1], which
tells the RAW codec that an encoded payload shall end at a boundary
fixed by a multiple of 'padding' unit bits counted from the
beginning of the message.
Let's use it for record 'PCUIF_data', where the fixed-size buffer
is located in between the other fields, so padding will be ignored
by the RAW coding after decoding:
$HOST: dec_PCUIF_Message(): Decoded @PCUIF_Types.PCUIF_Message: {
msg_type := PCU_IF_MSG_DATA_REQ (0),
bts_nr := 0, spare := '0000'O,
u := {
data_req := {
sapi := PCU_IF_SAPI_AGCH (2),
len := 23,
data := '2D063F100FE3673A096B0000C800300B2B2B2B2B2B2B2B',
...
}
}
}
As a result, we don't have to deal with padding manually and
can safely use 'decmatch' statement in the receive templates.
[1] usrguide/referenceguide/4-ttcn3_language_extensions.adoc
Change-Id: I5808954b5c67c3239e795e43ae77035152d359ef
In this testsuite, we simulate BTS and CBC by attaching to RSL and CBSP
protocol interfaces of the BSC. We then issue a variety of CBSP
commands to the BSC and check for corresponding action on both the BTS-
facing RSL as well as responses on the CBSP side.
Change-Id: Ia6ffac181f50586d06d2f29bca1c57285179e861
For some reason, the 'ifpresent' annotation doesn't work in lists
of templates. This means we have to re-think the CBSP template
structure at some point. However, this would be a significant detour
and I'd rather have working tests right now, so we can verify the
actual functionality merged into the BSC right now.
Change-Id: I3fa174b4352c17feaea4d33f773877104d4913c4
Otherwise TTCN3 errors sproadically during shutdown:
""""
SCCP_Emulation.ttcn:5661 Receive operation on port SCCP_SP_PORT succeeded, message from SGSN_Test_0-RAN(414)
...
SCCP_Emulation.ttcn:5293 Sent on MTP3_SCCP_PORT to SGSN_Test_0-M3UA(415) @SCCP_Types.ASP_MTP3_TRANSFERreq_sccp
SCCP_Emulation.ttcn:5293 Outgoing message was mapped to @MTP3asp_Types.ASP_MTP3_TRANSFERreq
SCCP_Emulation.ttcn:5293 Dynamic test case error: Sending data on the connection of port MTP3_SCCP_PORT to 415:MTP3_SP_PORT failed. (Broken pipe)
SCCP_Emulation.ttcn:5293 setverdict(error): none -> error
"""
Similar shutdown is already done in f_cleanup() of SCCP_Tests.ttcn.
Related: OS#4176
Change-Id: I471eb851e5d41de5d8d974ec81be27024d7d313a
Make the decoding level (BSSGP, LLC, SNDCP, L3) configurable, so the
existing PCU tests, that expect messages only decoded to the BSSGP
level, can pass again. Move the SNDCP decoding in f_dec_bssgp above the
L3 decoding, so f_dec_bssgp goes through the layers in the reverse order
of f_send_bssgp_dec.
I have verified, that all testsuites using the BSSGP Emulation (SGSN,
PCU, PCU-SNS) are still working with this patch.
Related: OS#4180
Fixes: 955aa94504 ("BSSGP_Emulation: Abandon "BssgpDecoded" intermediate structure")
Change-Id: I8f76385528c1de98c557cee451c0e0dfd182b605
I am not aware that this caused breakage anywhere. But from reading the
patch, this is a regression that needs to be fixed.
Fixes: 955aa94504 ("BSSGP_Emulation: Abandon "BssgpDecoded" intermediate structure")
Change-Id: I36a9a4d61be52a4d86ac1cbf6e6976cf01cff7c6
This reverts commit 5932cd3463. It caused
a lot of tests in the ttcn3-bsc-test, ttcn3-bsc-test-latest,
ttcn3-bsc-test-sccplite and ttcn3-bsc-test-sccplite-latest testsuites to
fail with:
RAN_Adapter.ttcnpp:179 Dynamic test case error: Text encoder: Encoding an unbound optional value.
Related: OS#4156
Change-Id: I441c701553eef8e9e018d11923359eb3f3b26826
Back in JUne, Change-Id I4d1eca6b0008a395b7f7449e6ea3f9b6d41133c7
attempted to introduce compilation of IPA_Emulation without CTRL but
it failed to cover all references to CTRL with the correspondign
ifdef/endif blocks. Let's fix this.
Change-Id: I68349b32f613aacced84011601121f2265243600
The way how the TITAN support for DIAMETER works, is that there's
an awk-based shell script and lots of DIAMETER dictionaries in the
https://github.com/eclipse/titan.ProtocolModules.DIAMETER_ProtocolModule_Generator
repository.
I've used 'AVP.sh Base_IETF_RFC3588.ddf BaseTypes_IETF_RFC3588.ddf
AAAInterface_3GPP_TS29272_f10.ddf GxInterface_PCC_3GPP_TS29212_f10.ddf
S6Interfaces_3GPP_TS29336_f00.ddf MobileIPv6_HA_IETF_RFC5778.ddf
RxInterface_PCC_3GPP_TS29214_f20.ddf' to generate the DIAMETER_Types
file we use here.
DIAMETER is used as signaling protocol between the HSS and other core
element nodes in the EPC, such as the MME and S-GW.
Change-Id: I85834e98e238b7ff6058264a0f365d05c15cd669
this includes a GTPv2_CodecPort (for the usual transcoding)
as wella as an empty GTPv2_PrivateExtensions.ttcn without which
the TITAN GTPv2 ProtocolModule won't compile.
Change-Id: I1c1b8409077103dd4e64e467d21d33d8c9c4ac95
The SGSN_Tests.ttcn run into bugs when doing the isvalue() check on a const object.
Check explicit for "omit" to skip creation of the vc_RAN object
Change-Id: I639ab6d0586174c0f20b93a53169f0aa254970fa
So far, the RAN_Emulation only supported the CS domain, and not PS. Let's
change that so we can start having IuPS related tests.
Change-Id: I7ba4662e5a7ba31a2582b0c133b3140c8057678f
It originally seemed like a great idea to define a custom record
which aggregates the decoded BSSGP, LLC, L3 and/or SNDCP and passes
it to the individual ConnHdlr. However, particularly with testcase
interoperability for IuPS in mind, this seems bogus. Also, we
never really took advantage of this.
Let's now decode as far as we can decode any PDU, and then send the
decoded version of that PDU via the ports between the BSSGP_Emulation
and the ConnHdlr component.
Change-Id: I8c1082880902dd9a04935945f0293895f4d0c53a
This allows us to encode/decode 3GPP S1AP messages, as used on the S1
interface control plane between eNodeB and MME.
Change-Id: Ie019bef1f3ef9cc5f6c94a64c7f352c510fb5633
Add tests to play through various neighbor configurations.
Tests will pass as soon as osmo-bsc I29bca59ab232eddc74e0d4698efb9c9992443983
is merged.
Add RSL2 to allow triggering handover to BTS 2.
Adjust osmo-bsc.cfg to match the new tests. Also applied in docker-playground
I1c57a04747f5ec004ccf4657954dcb0b003c24fc.
- Actually enable handover.
- Add bts 3
Depends: osmo-bsc I8623ab581639e9f8af6a9ff1eca990518d1b1211 ('no neighbors')
Related: OS#4056
Change-Id: Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc
Fix MSC test TC_lu_by_imei, which uses tr_ML3_MT_MM_ID_Req with the
default "?" (AnyElement) parameter. It was failing with the following
runtime error:
Dynamic test case error: Performing a valueof or send operation on a non-specific template of enumerated type @L3_Templates.CmIdentityType.
Fixes: 3289845913 ("L3_Templates: add enum CmIdentityType")
Related: https://www.eclipse.org/forums/index.php/t/1099816/
Change-Id: Ie7fbe52ac3c0c8f233680dcc311febec77d2ed0b
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
This test case reproduces a real-world PCO capture including a broken
PAP AuthenticationReq. It triggers some weird behavior in OsmoGGSN
1.3.0 where it would send duplicate IPCP repsonses and no PAP response.
Change-Id: Ie89d984ed9e26fbbb2e4914bdb8623446d462a4c
Related: OS#3914
* Some scenarios like MGW BSC-attached in SCCPlite require handling of
2 MGCP-over-UDP sockets in MGCP Emulation: 1 for regular
libosmomgcp-client from osmo-bsc and another one from the forward socket
from osmo-bsc (of MGCP-over-IPA messages communicated with MSC).
* Old port is kept for backward compatibility with other tests and
enabled by default. It's also interesting to keep it because it makes
tests without special needs (2 sockets) to use the old port/API which
produces simpler code to read and mantain.
* Users of the new port have to enable multi_conn_mode parameter and
expect to interact with port MGCP_CLIENT_MULTI instead of MGCP_CLIENT,
which will offer messages containing information about the UDP
connection being used by that message.
Change-Id: Ic0ba8c5cde068c07671512a83095d83e28b86746
Some of our SMS related test cases are failing. The problem is
that SMS related RAN messages shall be sent on SAPI 3, as per
GSM TS 04.11, section 2.3, while they actually being sent on
SAPI 0.
For the messages coming from the TCs towards OsmoMSC over RANAP,
we need to convert from DLCI to SAPI in f_xmit_raw_l3(). OsmoMSC
also needs to be patched, because it seems to ignore SAPI IE.
Change-Id: I6199fd5f26774fb1ec419bc1ef9e1caeca3a0d35
Instead of having two similar variants of RANAP_DirectTransfer:
- t(s|r)_RANAP_DirectTransfer, and
- t(s|r)_RANAP_DirectTransferSAPI,
let's make the first one more flexible, and drop the last one.
This is achieved by introducing two supplementary functions:
- f_gen_ts_dt_ies(), and
- f_gen_tr_dt_ies,
which dynamically compose DirectTransfer.protocolIEs.
Change-Id: I7333d08c4d5a72159bfbd50fe8e7b1084cd61b9e
osmo-bts does currently not use the signaled lchan BS power level, nor
does it update the BS power IE returned in the measurement results.
Change-Id: If91fb57b4070c60bb277d0b55d69ee3dde47ee48
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
It's way more cleaner when you see:
Timeout waiting for L1CTL_RACH_CONF
instead of:
Timeout in RACH.
Change-Id: I25e8230c2e4b29b2583bf8954d0dedaa18e5d6ae
This is the case for SCCPlite between BSC and MSC (or BSC-NAT). MGCP and
CTRL can be multiplexed over the same underlaying IPA conn.
Related: OS#2012
Change-Id: Id90c1609f0439b00379166fb9e4028d181fc023e
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
Previous to this commit, BSSAP Reset (Ack) messages contained Osmux
Support IE even if transport was SCCPLite, where those IEs are actually
meaningless.
Change-Id: If6cc0f65a0f273297a4523e5d6a7564d966f0aa6
This will allow RAN_Emulation to have better knowledge on the protocol
stack in use, and behave differently based on that information.
For intance, forthcoming commit will append OsmuxSupport IE only if
transport is BSSAP AoIP.
Change-Id: Ife62e328af2d3f2475ff93249f2138820c7ddabb
This adds the following test cases to BTS_Tests_LAPDm.ttcn:
* TC_sabm_retransmit_bts()
* TC_sabm_invalid_resp()
* TC_sabm_dm()
* TC_establish_ign_first_sabm()
* TC_iframe_seq_and_ack()
* TC_iframe_timer_recovery()
Change-Id: I4e1136c0c0f10d5bc8d01e826ae5d92f17a0b2aa
The existing implementation dind't account for the two-byte L1 header
preset on the SACCH in both uplink and downlink.
Change-Id: Iae97ad153e9d1688306b39b5fb43ade323dbe500
The idea of this test case (as can bee seen from its name) is to
verify handover RACH detection. What we basically do is:
1. Activate a logical channel on the BTS side (HO_SYNC for now);
2. Switch the MS (e.g. trxcon) to that channel without waiting
for Immediate Assignment and sending Access Burst;
3. Send an Access Burst on that channel using RA = HO_REF;
4. Wait for RSL HANDOver DETected from the BTS;
5. Release a dedicated connection.
There is no way to verify if the Handover Reference received
from the MS matches the one that was sent to the BTS. We can
introduce a separate test case that would just send an Access
Burst with RA != HO_REF.
Change-Id: If2e8d9c9947823df62f4bcc9a7fcd20734ff7858
Depends on: (trxcon) Ia967820a536c99966ba2c60b63d2ea9edb093f46
In BTS_Tests.ttcn we used to compose L1ctlDataReq manually. This
can be done by ts_L1CTL_DATA_REQ_SACCH() template itself, so
let's abstract BTS_Tests.ttcn from doing that.
Change-Id: I1ae948bd0314cdf15c21ce4b6346d5e32f1fcf95
If a LAPDm message is shorter than the MAC block size, we must pad
it before seding it to L1. trxcon e.g. would ignore any frames with
the wrong length since Change-Id I258ee9f6d0124b183b1db23a73f1e523fcea89a8
Change-Id: I30bcce27f95974eaca4168a156d1548586c924d6
Related: OS#3415
In the existing TC_pcu_* test cases we use L1CTL_DATA_* messages
to send / receive (E)GPRS related MAC-blocks. The length of such
blocks can be greater than 23 octets (i.e. fixed MAC-block
length in GSM), up to 162 octets to be precise.
Change-Id: Iced78796882b757016d02a266d55bc2a98b62a3d
This test will currently fail due to a MODE MODIFY NACK, even though the
channel mode is not modified.
Related: OS##3750
Change-Id: I4cbea499bb6a331d314e6573548a4540945208b5
Bring our TTCN-3 view of how RSL channel numbers are defined in sync
with that of our other implementations (BTS, libosmocore, trxcon, ...)
Change-Id: I48908058ac2501a3b5ae7c74e4e8527cbaee1b01
Related: OS#4027
In OsmocomBB/trxcon Change-Id Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
we introduced a new mode CCCH_MODE_COMBINED_CBCH to indicate that the
channel combination is a CCCH+SDCCH/4 with one SDCCH stolen for CBCH.
Let's make sure we actually use that mode in our CBCH related tests
Change-Id: I27ee2c81bec7175c1ea09d4f3f6037f2866fe242
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
This test opens a SDCCH and sends a RR SUSPEND message from the
simulated MS. It then expects the BTS to pick that up and forward
it to the PCU socket rather than via RSL to the BSC.
Change-Id: I4da6e9d7c5dfbd0e017d2a63c6474da700c38e52
Related: OS#2249
Related: OS#4023
Test verifies once osmux is enabled in osmo-bsc, BSSMAP RESET (ACK)
contains Osmux Support IE and that it correctly handles BSSMAP ASsign
Req with Osmux CID.
Related: OS#2551
Depends: osmo-bsc 6de754cdde5319af3059d8fc6abf85037ec7eacc
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: If69c716dc06d61d810c32d1720a237c7535baca8
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
The existing code structure could only test for normal messages with a
NULL default, but didn't handle situations where normal and/or schedule
messages were superimposed on top of DEFAULT messages.
Also, prepare the infrastructure for testing both CBCH BASIC and CBCH
EXTENDED.
No new tests are introduced, the code should behave identical before
and after this patch.
Change-Id: I144c7d833b79c648b1ac69a6155f3603025ede5c
Related: OS#4011
During MGCP_Test's f_flow_modify, an RTP socket may be Tx-enabled, and
f_flow_modify first calls bind, then connect, with MDCX transaction in
the middle (which can take some time).
If T_transmit from RTP_Emulation triggers (RTP packet to be send),
during that time, TTCN3 will fail to send the packet:
RTP_Emulation.ttcn:312 Message enqueued on RTP from system @Socket_API_Definitions.PortEvent : { result := { errorCode := ERROR_SOCKET (4), connId := 2, os_error_code := 89, os_error_text := "Destination address required" } } id 1
Change-Id: I20e7aed35bb28200e30ee5efc718f77e036d8262
In any normal or handover related assignments, we don't have an
ImmediateAssignment that we can hand to f_L1CTL_DM_EST_REQ_IA(),
so let's intrduce a version that works with arfcn, chan_nr and TSC
directly.
Change-Id: Ie5b85d3bac57032f4762ea9cdc21fdcd70fd5c2a
According to 3GPP Ts 48.058, every logical channel can receive some
specific SACCH filling at the time of RSL channel activation. This
overrides the global SACCH FILLING.
Related: OS#3750
Change-Id: I8adb371a7e0b80792dd2fa35e5204802068df5ba
Neels Hofmeyr
Harald Welte
Vadim Yanitskiy
Pau Espin
Oliver Smith
Philipp Maier
Eric Wild