GSM_RR_Types.ttcn: In TTCN-3 module `GSM_RR_Types':
GSM_RR_Types.ttcn:957.2-983.2: In template definition `ts_IMM_ASS':
GSM_RR_Types.ttcn:957.2-983.2: While checking template restriction `value':
GSM_RR_Types.ttcn:146.14-16: warning: Inadequate restriction on the referenced template parameter `len', this may cause a dynamic test case error at runtime
GSM_RR_Types.ttcn:145.44-63: note: Referenced template parameter is here
Change-Id: I0d17102294430d23eb683e16d5ac66abe806f2c1
L3_Templates.ttcn: In TTCN-3 module `L3_Templates':
L3_Templates.ttcn:120.1-125.1: In template definition `tr_MI_IMSI':
L3_Templates.ttcn:122.25-124.2: In template for record field `oddEvenInd_identity':
L3_Templates.ttcn:123.11-28: In template for union field `imsi':
L3_Templates.ttcn:123.23-28: In actual parameter list of function `@L3_Templates.f_tr_MI_IMSI':
L3_Templates.ttcn:123.24-27: In parameter #1 for `digits':
L3_Templates.ttcn:123.24-27: warning: Inadequate restriction on the referenced template parameter `imsi', this may cause a dynamic test case error at runtime
L3_Templates.ttcn:120.37-59: note: Referenced template parameter is here
Change-Id: Ia6979dff7d3c58f8609ebe55de2550446c3f1781
L3_Templates.ttcn:1099.1-1108.1: In template definition `ts_ML3_MO_CC':
L3_Templates.ttcn:1099.53-1108.1: warning: Field `msgs' is missing from template for record type `@MobileL3_Types.PDU_ML3_MS_NW'
Change-Id: Id131274ae7832846df6c09cbe6763b9e147ef372
RAN_Emulation.ttcn: In TTCN-3 module `RAN_Emulation':
RAN_Emulation.ttcnpp:1294.1-1343.1: In function definition `ExpectedCreateCallback':
RAN_Emulation.ttcnpp:1309.4-1313.2: In else statement:
RAN_Emulation.ttcnpp:1312.3-12: warning: Control never reaches this statement
RAN_Emulation.ttcnpp:1342.2-11: warning: Control never reaches this statement
Change-Id: I4e7cc0a7e6bff5c5e569458548fa70e814bd200c
StatsD_Types.ttcn: In TTCN-3 module `StatsD_Types':
StatsD_Types.ttcn:51.1-55.1: In template definition `tr_StatsDMetric':
StatsD_Types.ttcn:51.126-55.1: warning: Field `srate' is missing from template for record type `@StatsD_Types.StatsDMetric'
StatsD_Types.ttcn:57.1-61.1: In template definition `tr_StatsDMetricCounter':
StatsD_Types.ttcn:57.106-61.1: warning: Field `srate' is missing from template for record type `@StatsD_Types.StatsDMetric'
StatsD_Types.ttcn:63.1-67.1: In template definition `tr_StatsDMetricGauge':
StatsD_Types.ttcn:63.104-67.1: warning: Field `srate' is missing from template for record type `@StatsD_Types.StatsDMetric'
Change-Id: I6d3b40dc719b42481dacb5599eb7eeb3be0426b4
RSL_Emulation.ttcn: In TTCN-3 module `RSL_Emulation':
RSL_Emulation.ttcn:478.1-713.1: In function definition `main':
RSL_Emulation.ttcn:500.2-712.2: In while statement:
RSL_Emulation.ttcn:501.3-711.3: In alt construct:
RSL_Emulation.ttcn:695.4-28: In function instance:
RSL_Emulation.ttcn:725.9-744.1: In function definition `f_WaitingQueue_dispatch':
RSL_Emulation.ttcn:729.2-740.2: In for statement:
RSL_Emulation.ttcn:732.3-736.3: In if statement:
RSL_Emulation.ttcn:735.4-8: warning: Control never reaches this statement
Change-Id: I1e080a8543a9f26b45b345e47881b6f6d4c9b362
CBSP_Templates.ttcn:385.1-401.1: In function definition `ts_CBSP_REPLACE_CBS_COMPL':
CBSP_Templates.ttcn:396.2-398.2: In if statement:
CBSP_Templates.ttcn:397.3-50: In variable assignment:
CBSP_Templates.ttcn:397.40-50: In actual parameter list of template `@CBSP_Templates.ts_CbspCellList':
CBSP_Templates.ttcn:397.41-49: In parameter #1 for `list':
CBSP_Templates.ttcn:397.41-49: warning: Inadequate restriction on the referenced template parameter `cell_list', this may cause a dynamic test case error at runtime
CBSP_Templates.ttcn:387.8-68: note: Referenced template parameter is here
Change-Id: I54c21d17ab3235ec37d5f07867d8c6c83d699088
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
Keep a local next_idx so that lengthof() doesn't fail after adding a '*' entry.
Fixes this error in BSC_Tests_CBSP.TC_cbsp_write_then_kill:
Dynamic test case error: Performing lengthof() operation on a template of type @CBSP_Types.CBSP_IEs with no exact length.
Change-Id: I4d95a8ca311f145fa5ea371b6aed099db771d7b8
Invoke Clear Command with various Cause codes and verify that the RR Channel
Release reflects them.
Depends: I734cc55c501d61bbdadee81a223b26f9df57f959 (osmo-bsc)
Change-Id: Ie6c99f28b610a67f2d59ec00b3541940e882251b
Add a DCHAN and release to recently added SI2quater tests (because these tests
already configure various amounts of EARFCNs in osmo-bsc).
Verify that the RR Channel Release for CSFB contains all configured EARFCNs.
In GSM_RR_Types.ttcn, add coding for "Cell selection indicator after release of
all TCH and SDCCH IE".
In f_expect_chan_rel(), add optional arg csfb_expect_cells, and, if present,
decode the RR Channel Release message's L3 part, and in turn the Cell Selection
Indicator Value contained. Match against csfb_expect_cells.
In f_tc_si2quater_n_earfcns(), also compose a list of EARFCNs as found in the
RR Channel Release, and pass to f_expect_chan_rel().
Depends: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab (osmo-bsc)
Change-Id: I882c5e1f70bcc4833fc837a95c900ce291919cc5
During patch grooming of the previous fixup, one patch line went missing, which
breaks the ttcn3-bsc-test-latest completely. Add that change now.
Change-Id: I75295d638072df9f5213a7e74e4a960c009c2865
In f_vty_wait_for_prompt(), this:
testcase.stop(fail, "VTY: Unknown Command")
outputs:
failVTY: Unknown Command
The first stop() argument 'fail' is not actually a test verdict, but gets
rolled into a log output string, becoming "failVTY".
Fix that by simply using the normal pattern of setverdict() followed by
mtc.stop().
Change-Id: Id09986444de02c10b4fba582d454d54568b6e8a2
For the VTY "Unknown Command" code path, we must actually call 'repeat', to
avoid racey VTY behavior from cruft stuck in the VTY pipe.
The missing 'repeat' caused massive random fallout in the 'latest' builds,
which often hits the 'Unknown Command' code path; fixed by this patch.
Change-Id: Ibd5adb359b3fb302e2c70700d911878aef605ff3
When a new test uses a VTY configuration that may not yet be available in the
'latest' build, it can be useful to ignore the "Unknown VTY Command" error.
To be used by f_init() for multiple MSCs, setting a default 'allow-attach' flag
per MSC implicitly -- such vty config is not yet supported in the latest build.
Change-Id: I284c42e10c0cb282c8410db87959b471867edef6
This change introduces new version 10 specific extensions, in
particular: the frequency hopping parameters of each timeslot.
These parameters are used to compose Channel Description IE
in the packet resource assignment messages.
In order to maintain backwards compatibility with version 9 of
the PCUIF, and thus to still be able to run test cases against
the latest release of osmo-pcu, I kept the old parts of the
INFO.ind and gruoped them together with the new records
into union 'PCUIF_InfoTrxs'.
During decoding, the content of this union is resolved by the
TITAN's RAW codec itself, depending on value of the 'version'
field. During the encoding, it's the responsibility of the
API user to set a proper field of the union. I implemented
both f_PCUIF_ver_INFO_{Trxs,PDCHMask} helpers for that.
Version 9 is kept as default, so this change can be merged
independently of the actual implementation. We can bump
it and remove the compatibility glue once the new versions
of both osmo-bts and osmo-pcu are released.
Change-Id: Idf11bc4ba3ff0b00b32f2beab8fd020c67119d05
Related: SYS#4868, OS#4547
The following bitstring in TITAN:
0 N // N = NF - 1
-------------------->
0001 1011 1110 0100 // '0001101111100100'B
needs to be be encoded as follows 'on the wire':
N 0 // N = NF - 1
<--------------------
0010 0111 1101 1000 // '0010011111011000'B
so it basically gets inversed => we need to use BYTEORDER(first).
Change-Id: Iea2e3a9a7a0557d1ab5d935877d2161ee0988077
Fixes: I70b1baf01859d0cf3b8cec1aed04d73fc097a9b1
Related: SYS#4868, OS#4547
- Length of field 'MA_BITMAP' is specified in bits, not bytes;
- The value range of field MA_LENGTH is 0..63, therefore:
- value 0 means that field 'MA_BITMAP' is 1 bit long,
- value 1 means that field 'MA_BITMAP' is 2 bits long,
- value 63 means that field 'MA_BITMAP' is 64 bits long.
Change-Id: Iec19da18637febfa15bc09175bc51504c721c42f
Related: SYS#4868, OS#4547
According to 3GPP TS 44.060, table 12.10a.2, given that the number
of bit positions in MA_BITMAP equals NF, the first bit position
in MA_BITMAP corresponds to ARFCN_INDEX = NF-1, the last position
corresponds to ARFCN_INDEX = 0.
To put differently, the following bitstring in TITAN:
0 N // N = NF - 1
-------------------->
0001 1011 1110 0100 // '0001101111100100'B
needs to be be encoded as follows 'on the wire':
N 0 // N = NF - 1
<--------------------
0010 0111 1101 1000 // '0010011111011000'B
so it basically gets inversed. Let's add both BYTEORDER and
BITORDER attributes to achieve that.
Change-Id: I8f2c8c7b234605523a4fd518210b45ea3c088ff6
Related: SYS#4868, OS#4547
When changing the PCUIF, we have to maintain backwards compatibility
with the release versions of both osmo-pcu and osmo-bts, not only
with the recent master. In order to achieve that, let's introduce
'mp_pcuif_version', so the PCUIF version can be adjusted.
Change-Id: I3cf7f908e606b91dd2cbddc168827dd074aed052
Related: SYS#4868, OS#4547
They're going to be used in other modules too, not only in BTS_Tests.
Also, take a chance to rearrange the list of arguments, so the ones
with default values are placed after mandatory ones.
Change-Id: Ia33ebf2e680f16f774a981fc33422dfe5036637f
Some types of System Information (mostly the Rest Octets) are not
fully implemented, so calling the generic dec_SystemInformation()
may result in a DTE. Let's add dec_SystemInformationSafeBT() with
"prototype(backtrack)", so it would return a non-zero integer if
decoding fails. Let's add a wrapper dec_SystemInformationSafe()
that would additionally check the RR Protocol Discriminator.
Change-Id: Id4d73e0f3347e1d4c4c77aec75b767311d662292
Related: OS#4662
Add more EUTRAN ARFCNs, reaching the maximum allowed amount.
Add tests with 12, 23, 42 EARFCNs, just for the sake of testing some arbitrary
numbers.
Add tests with 32 and 33 EARFCNs because before osmo-bsc
Iabeed10053ee5899b4def3509aedd25abb2410a9, only 32 EARFCNs could be stored by
osmo-bsc.
Add a test with 48 EARFCNs to verify the maximum amount of EARFCNs and maximum
amount of SI2quater multiplexes works as expected.
Add a test with 49 EARFCNs to verify the VTY error response when adding too
many EARFCNs, and showing that osmo-bsc still sends 16 SI2quater with 48
EARFCNs.
Depends: Iabeed10053ee5899b4def3509aedd25abb2410a9 (osmo-bsc)
Change-Id: I99bf9b3381812d1db6fd0757f65995bae48da776
So far the naming is so that the EUTRAN_NeighborCell sounds like it reflects a
single E-ARFCN, while in fact it contains a list of E-ARFCNs. In 3GPP TS 48.018
it is more accurately named "Neighbor Cells", in plural.
There is another "list layer" that allows repeating these lists of E-ARFCNs,
which the spec names Repeated Neighbor Cells, i.e. have a list of (=repeat) the
lists of E-ARFCNs.
Repeated Neighbor Cells = {
// first cells list
Neighbor Cells = {
cell descriptions = {
{ e_arfcn = 1, meas_bw = 3 },
{ e_arfcn = 2, meas_bw = 3 },
{ e_arfcn = 3, meas_bw = 3 },
},
prio, thresh, ...
},
// second cells list
Neighbor Cells = {
cell descriptions = {
{ e_arfcn = 4, meas_bw = 3 },
{ e_arfcn = 5, meas_bw = 3 },
{ e_arfcn = 6, meas_bw = 3 },
},
prio, thresh, ...
},
...
}
Adjust the naming of the SI2quaterRestOctets members to more closely resemble
this structure, adopting the naming in 3GPP TS 48.018:
EUTRAN_NeighborCell -> EUTRAN_NeighborCells
because it is really a collection of multiple E-ARFCNs
EUTRAN_NeighborCells -> EUTRAN_RepeatedNeighborCells
because it is a list of E-ARFCN lists, and 3GPP TS 48.018 names it
"Repeated Neighbor Cells".
Also rename the EUTRAN_NotAllowedCells accordingly.
Change-Id: Ib11d72c04cdb8997ec97321257fb58b2c113e790
This is a very minimalistic (incomplete) implementation of SI2quater
Rest Octets as per 3GPP TS 44.018, table 10.5.2.33b.1. Should be
enough to decode some of the E-UTRAN specific parameters though.
Some BITn fields might need to be replaced with more specific
enumerated or integer types. Beware [1], the bit ordering rules
are different for integer and bitstring (sub-)types if a field
ends up on boundary of the two octets!
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562488
Change-Id: I6a12c9ee12f8df8b4fc0976dd593152dc1195718
Related: SYS#4870
At the time of writing Ief0d9b096feeee7d37b5f2429dd3e80de0161806 I wasn't aware
of the 'inout' keyword, which allows to pass the counter list by reference.
Rather modify the counter lists in-place. Instead of requiring
list := f_counter_name_vals_add(list, ...)
rather implement by directly modifying list:
f_counter_name_vals_add(list, ...)
Change-Id: I85ac56b042fe4bb1db392c1f451c8e900582cc2a
First user will be new MSC pooling tests in ttcn3-bsc-test, see
I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f.
Change-Id: Ief0d9b096feeee7d37b5f2429dd3e80de0161806
Since change [1] has been merged, we see multiple regressions in
ttcn3-bsc-test (all LCLS test cases) and ttcn3-bsc-test-sccplite
(sporadic failures). In all failed cases, the reason is similar:
RSL for unknown Dchan
BSC_Tests.ttcn:4501 BSC_Tests control part
BSC_Tests.ttcn:2176 TC_assignment_codec_fr testcase
The mentioned change enables TCP_NODELAY option for all IPA based
connections, including both OML and RSL. This option disables
Nagle's algorithm [2], so we get less delays on IPA based links.
It took me a lot of time to investigate, and finally, I figured
out what is actually causing those regressions. The TCP_NODELAY
itself is not a problem, of course. As it turned out, the
problem is here, in our TTCN-3 test case framework.
Each test case involves several components (actors) running in parallel.
One of them is RSL_Emulation_CT, which is responsible for handling and
routing of RSL messages between the connected components.
A test case may register dedicated channel handlers by calling
f_rslem_register(), so DCHAN/RLL/IPACCESS messages will be matched
by RslChannelNr/TrxNr and routed to the corresponding one.
If no handler is found for a given RSL message, the RSL_Emulation_CT
would abort the test case execution. And that's where the problem is.
Given that all components are running in parallel, it may happen
that a received RSL message would be processed by the RSL emulation
component faster than the test case would call f_rslem_register().
The test case would be aborted due to "RSL for unknown Dchan".
Speaking in context of the failing BSC test cases, a test case
calls f_rslem_register() on receipt of an Assignment Command as
it contains all the assignment parameters. After that we expect
to receive an RSL ip.access CRCX for that channel.
The problem is that both Assignment Command and ip.access CRCX
messages are sent by the BSC simultaneously, so the later may
be handled faster than the first one. Race condition!
Let's work this around by maintaining a waiting queue, where the
messages, for which no handler was found, will be kept until the
corresponding dedicated channel is registered.
This is an optional feature that needs to be enabled explicitly
by calling f_rslem_dchan_queue_enable(), and then explicitly
disabled by calling f_rslem_dchan_queue_disable().
If at the moment of calling f_rslem_dchan_queue_disable() the
waiting queue is not empty, e.g. because the IUT sent us more
messages than we expected, test execution will be terminated.
The actial fix for the LCLS test cases will be submitted next.
[1] Ia3d4c41bf0659e682f0b7ae5f3d58ed0f28edb58
[2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm
Change-Id: I25e10e28de174337233e6a3bb32cc16f2d7d614e
Related: OS#4619
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
Vadim Yanitskiy
Harald Welte
Neels Hofmeyr
Daniel Willmann
Pau Espin
Oliver Smith
Philipp Maier