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
Pau Espin
Vadim Yanitskiy
Harald Welte
Oliver Smith