We cannot handle this in as_ptp_allstate(), as the respective clauses
are never hit: In as_ptp_unblocked() we broadcast all BSSGP messages
without a TLLI, "hiding" the BVC-RESET handling.
Change-Id: Ie3e7a997554e6af42ae7e7294829b6f8d2447d60
Add a log label argument to f_vty_wait_for_prompt(), and feed the sent
command from f_vty_transceive*(), so that the failure verdict already
lists the vty command that caused the failure.
A common error is to issue insufficient 'exit' commands, so that I often
think the newly added VTY command failed, even though it is a subsequent
command causing the failure. I want to shorten the "time-to-aha" there.
Change-Id: Icfd739db150d86e9256a224f12dc979dcd77879f
The per-NSE BSSGP_CT gets a new GLOBAL port which is used for procedures
that are not specific to one BVC, such as the SUSPEND/RESUME related
PDUs, which all are on the signalling BVC without any BVCI in the BSSGP.
Change-Id: I40d973d80709f5d56f59247e8647b52754f09bc8
In some cases GsmArfcn itself is not enough. It case of L1CTL
and GSMTAP, it needs to be equipped with a band discriminator:
- DCS / PCS (as the numbers may overlap),
- Downlink / Uplink (not yet there).
Let's rename this record and move it to GSM_Types. Also, add
send / receive tamplates, so we can add new fields later.
Change-Id: I7a63f03bbd15a06caafb786122dc12991d115771
The primitive normally only contains NSE + BVCI, but in a tester
we actually want to verify which NS-VC a given message has arrived on,
and hence it makes sense to add the NSVCI, too.
Change-Id: I9402bf0be47e5b93c9cfb081eb8f9fa6734c9227
This took me quite some time: Tried to use NS_PROVIDER_FR, but the
code was compiled without support for it. It just failed silently
without printing any error or ever sending any message on the FR link.
Change-Id: I96475127a2079830b3456a8e288adf4c6c908887
This port can (optionally) be connected to, and it will receive
state change notifications as well as permit the user to block/unblock
and reset the specific PTP BVC.
Change-Id: I1f0289c8805168e3daace4a7d76764b45cead3d0
The existing BSSGP Code assumed that the TLLIs were always known "a
priori" by the test case. With the newly-introduced create_cb,
the user can provide a function to handle any incoming messages for an
unknown TLLL. The default handler behaves like before: fail +
terminate.
Change-Id: Ice0e145f5a6518ff79547dd851042b7965f38e00
The template restrictions are quite useful, becaue they give hints
to the TTCN-3 compiler, so it can spot more bugs. For example,
the lack of thereof would not prevent one from passing 'omit' to
a template, that assigns a value to a non-optional field, so that
might lead to a DTE at run-time in some cases.
Since adding 'template (restriction) ' to each template parameter
obviously makes templates look more cumbersome, let's move the
part with template name and arguments onto a separate line, just
like it's sometimes done for function definitions in C.
Change-Id: I7e6846381e0b3fb611059fcfbafb19bd6c15cfd8
Those functions don't depend on any L3 specific data structurs, and
it is not a good idea to burden every user with having to impot all
of a 2G/3G Layer3 just to generate some hexstring identifiers.
Change-Id: I6fc41ed94e97e0ec44dc4ea56d110bdd9ac77a72
Those functions don't depend on any L3 specific data structurs, and
it is not a good idea to burden every user with having to impot all
of a 2G/3G Layer3 just to generate some hexstring identifiers.
Change-Id: I7880633a46afc607f16f8aa6ea1a277f7958c95b
The Load Sharing Function distributes traffic among all unblocked NS-VC
within a NS-VCG. The sharing is done based on a LSP (Link Selector
Parameter) which is passed with the NS-UNITDATA.req primitive from BSSGP
to NS. Details are implementation specific, but NS must ensure that all
traffic of one LSP is always sent through the same NS-VC, as long as
that NS-VC is alive/unblocked.
We use the LSP as follows:
* Signaling BVC always only uses lsp 0
* PTP BVC messages unrelated to user straffic use a per-BVC static LSP,
which is the BVCI
* User traffic can set whatever LSP it wants
* NS keeps an array of NSVCs currently unblocked and uses the LSP modulo
the array size as an index into it
Change-Id: I8b960ec4d729f50cadca353bb52685311cd45eed
Related: SYS#5084
In case of a NS-VCG with multiple NS-VC, we must BVC-RESET only when the
first NS-VC becomes unblocked, i.e. as soon as we have any connection
to the peer at all. Whether we have further additional links doesn't
matter, at least not in the sense that all state should be reset.
Change-Id: I69b2e9bd919fc981f189b6671b4234c3642e2449
This is something we need to simulate more complex scenarios,
particularly in the context of frame relay.
Change-Id: If1220852785853f8a5d8de183d5053ddd6ccb958
Previous commit implemented the CS/MCS verification, and hence now some
tests fail because they had too restrictive checks.
In theory the verifications could be done so restrictive by configuring
the PCU accordingly at the start of the test, but we are not
really interested in checking the exact CS/MCS in these tests, only
checking if GPRS/EGPRS is being used.
Change-Id: I79b81d473b7428b57a0ec501c5bd0d88e35c81e3
Let's provide this information to higher layer since CS is mostly
discovered by original bitstring size which is available during
decoding.
Call the size2mcs converter in each function to avoid having to pass it
as a parameter and have it selfcontained, meaning one can simply call
decode(bitstring) from TTCN3 code and be done with it.
Change-Id: I80ed44e575cc0a11510832e5bbfc07173e7b75b8
Once GPRS/EGPRS multiplexed support is ready, it will be controlled
through pcu info_ind.flags by enabling
MCS or not; the "egprs only" VTY comamnd will be dropped.
The usual setup would be to support both GPRS+EGPRS, so make that the default.
Most tests require to be passed the _noMCS variant to work in older
versions of PCU, since those versions use the "egprs only" concept which
will reject egprs_ms_class=0. Same tests enabling MCS in newer osmo-pcu
shouldn't be a problem.
Related: OS#4544
Change-Id: Ib95aae155b0712313a30f0c5404a8cb1f28b98f5
ARFCNs are allocated sequentially, so that conversion between
arfcn<->trx_nr is easily done.
Some helper functions are introduced to be able to submit and expect
messages on a given TRX+TS, which is required for setups with several
TRX and PDCH-enabled TS different than the default. These new APIs
will be used in PCU_Tests.ttcn in subsequent patches.
Change-Id: I28430e6d8c77d2b7dc630d186d425a5d82587b82
With PCUIF 10 the remote can be IPv4 or IPv6.
Add all missing parts including SNS IPv6 elements,
the support to omit IPv4 elements and a PCU_Tests_SNSv6.cfg
configuration to run all tests with IPv6
Change-Id: I43d64caca600fff78f3fbbb3e8179f447f235d46
This way it's consistent with ts_RSL_ChanMode, and there is
no need to pass dtx_downlink := false as the first param.
Change-Id: I0b87ef87f8cfff1c96b0beead29d549d5fe0b7c6
The testcase TC_meas_res_sign_tchX activates a traffic channel in
signalling mode and checks the RSL resulting measurement reports.
The CHANnel ACTIVation message sets "SDCCH" as "Channel rate and Type"
value. This is invalid, the "Channel Rate and Type" sould be set to "Half /
Full rate TCH Channel Lm / Bm" (while the speech or data indicator is
still set to "Signalling")
Change-Id: I51887b0d0379fcc1f4483d08dfdd6869e7a9f963
Related: OS#4799
Calypso PHY (unlike trxcon) needs to be explicitly configured to
enable forwarding of the TCH traffic. Otherwise it's handled
internally by the DSP and routed to/from the built-in speaker/mic.
Change-Id: I5b9ca5683627716868e85dc33f91d8ca4824cd61
Related: OS#4799
Otherwise the L1 (trxcon or Calypso PHY) would 'think' that we're
in signalling mode, and would not send us Bad Frame Indications.
Change-Id: I0ade3bd63f604c7f0665124b182a023d50030d0b
Depends: I6f403ed0506b4b1872361d9976d3186bfe514b52
Related: OS#4799
A TRAFFIC.ind with 'num_biterr' > 0 or 'fire_crc' != 0 is still
a valid TCH frame - Bad Frame Indication. Let's relax those
parameters for tr_L1CTL_TRAFFIC_IND().
Change-Id: Ia3357e06f986ae59dd0438f9ace3042cae8d3684
Related: OS#4799
In osmocom-bb 'struct l1ctl_dm_est_req' is defined as follows:
struct l1ctl_dm_est_req {
uint8_t tsc;
uint8_t h;
union {
struct l1ctl_h0 h0;
struct l1ctl_h1 h1;
},
uint8_t tch_mode;
uint8_t audio_mode;
} __attribute__((packed));
so the overall size of the union is size of the biggest member:
sizeof(struct l1ctl_h0) is 2
sizeof(struct l1ctl_h1) is 132
Therefore we need to fix our definitions:
- introduce 'record L1ctlH0' (with padding),
- introduce 'union L1ctlH0H1':
- move hopping indicator to L1ctl{H0,H1},
- use it as 'TAG' in 'union L1ctlH0H1'.
Change-Id: I53964f794260f0676cc2771a7acbb679befb06d5
Related: OS#4799
When a RESET-ACK times out, the logs currently are indistinguishable between
BSSMAP and BSSMAP-LE. Add protocol naming for each RESET / RESET-ACK logging to
make sure the information does not need guesswork.
Example of a test failure shown in jenkins:
BSC_Tests.TC_unsol_ass_compl
Stacktrace
Timeout waiting for RESET-ACK after sending RESET
BSC_Tests.ttcn:8295 BSC_Tests control part
BSC_Tests.ttcn:4274 TC_unsol_ass_compl testcase
Nothing conveys that it is (presumably) the background *BSSMAP-LE* timeout
halting the test 5 seconds in, and not an A-interface failure.
Change-Id: I874567e68b8279bf2460b9474241f0a9fe5ff0ff
If IP-SNS is not used we should wait for the RESET procedure to finish
before sending NS-ALIVE.
For IP-SNS start NS-ALIVE in both roles (sgsn and bss) and don't handle
NS-RESET.
Also unified the log messages a bit (received -> Rx).
Related: SYS#5002
Change-Id: Ie01fee70297255b3d9c091bc2cec75b0f915c588
This should not have been merged. It is an intermediate attempt to make the BSC
send the BSSMAP-LE RESET, which doesn't work because the BSC is not restarted
across test runs. I dropped the patch from my branch, while it remained on
gerrit accidentally; then someone else merged it without noticing that it was
no longer part of my lcs branch.
This reverts commit b2b3704d2a.
Change-Id: If191cf0ee5c239066fa41621e812efbdcca2a2b8
Both BSSMAP-LE and BSSMAP use the LCS Cause IE with identical definition. In
order to not add further dependencies from BSSMAP_Templates.ttcn to
BSSAP_LE_Types.ttcn to BSSLAP_Types.ttcn, duplicate the LCS Cause enum.
Change-Id: Ifee698c128a5345f6bf0301ad4dac9e083285d56
Expecting OsmoBSC to send a RESET to the SMLC implies that the virtual SMLC
stays quiet until a RESET is received. Add flag to configure RESET behavior of
BSSMAP-LE.
Change-Id: I49a749b037b614f922044165a4357fe20b68860b
Those can help to match if messages meet certain constraints stipulated
in the BSSGP specification.
Change-Id: I05c768f5a9e4f0b5c1375c2603135a349c38e849
The BVC-RESET / BVC-RESEt-ACK follow a set of rules:
* Signaling BVCI=0 never has a CellId in BVC-RESET nor BVC-RESET-ACK
* Any BVC-RESET or BVC-RESET ack in BSS->SGSN direction must have CellID
* Any BVC-RESET or BVC-RESET ack in SGSN->BSS direction must NOT have CellID
Let's adjust our test expectations accordingly.
This will break tests against "latest", but the amount of work-arounds
needed in this code outweighs the benefit.
Change-Id: Ic8a83f5214c372faa15178dd9b54364e7d2a60cb
The existing BSSGP_Emulation is built around the assumption that every
instance of BSSGP_Emulation only servers one signaling-BVC and one
PTP-BVC. While this is true for osmo-pcu at this point (BTS-colocated
PCU), other BSS/PCU implementations differ.
In general, there can always be any number of PTP BVC (one per cell)
next to the signaling BVC (one per BSS). Let's represent this in
BSSGP_Emulation so we can create more comprehensive tests.
Change-Id: I7e30b4c4e188518a574e082962fba457b3a97ce3
This is required by the spec, and implemented libosmocore since
Change-Id Ie87820537d6d616da4fd4bbf73eab06e28fda5e1
So let's change our test expectations. Meanwhile, introduce
mp_tolerate_bvc_reset_cellid for working around the bug in 'latest'.
Change-Id: Icebee25b53fef623db6ae91ca0d943e70a3c86b7
This is required by the spec, and implemented libosmocore since
Change-Id Ie87820537d6d616da4fd4bbf73eab06e28fda5e1
So let's change our test expectations. Meanwhile, introduce
mp_tolerate_bvc_reset_cellid for working around the bug in 'latest'.
Change-Id: If6245d73ed701e631b67146ace4ba028bdb4226c
We always used to include the CellID IE, but 3GPP TS 48.018 is
actually quite specific about when it should be present and when not.
Change-Id: Iffd023f0272c9ccb087bdd225fcfb08424a46bdf
We want to see useful identification for components in the log, and
hence must be giving every component a name at create() time.
Change-Id: I0fe650243953e4d85161684865acd0354b2e465f
This makes for much more readable code, and we can even do without
activating any default altsteps.
Change-Id: I4c38dd55b7c27899735f5730851d36c1410d96a8
This allows NS_Emulation to react to changes of the underlying
transport layer (e.g. Frame Relay Link/DLCI up).
Change-Id: If00e9c50dc664ce62b6c0cbde99d741e8173169b
This adds a NS_Provider_FR which interfaces between FrameRelay_Emulation
and NS_Emulation. Include support for it only if enabled at compile
time to avoid pulling in a dependency on the FrameRelay stack for every
user of NS_Emulation.
Change-Id: I42ca811d23e383e362d2527c8ff2c916a62a5b42
NSConfiguration currently contains parameters relevant only for IP
based transport. Move IP/UDP parameters into a sub-structure in
anticipation of Frame Relay support.
Change-Id: I6904520d8c2f546327029777d68b1907611a8cf5
Both osmo-bts and osmo-pcu are switching to PCUIFv10 soon, so let's
use the new version by default. For older (latest) IUT versions
not supporting PCUIFv10, one would need to override this module
parameter in {BTS,PCU}_Tests.cfg.
Change-Id: I9350c4a54434c3d46ce9424f382ca0057e58d053
Related: SYS#4868, SYS#4915
The dependency of PCUIF_Types creates also a dependency on
Replace the PCU_AddrType by an unix like address family defined
in the Osmocom_Types to reduce the dependency.
Change-Id: I0b4fda96accef401ffc009010f9f5621583fd6dd
This is a step to prepare the NS_Emulation for operating on top of
Frame Relay, not just UDP/IP. We replace the NS_CodecPort (mapping to
a IPL4asp) with a newly introduced NS_Provider_CT, specifically a
NS_Provider_IPL4_CT.
This change removes any IP specific bits from NS_Emulation and moves
it into the newly-created NS_ProvideR_IPL4.
Change-Id: I4d0b7ad0ed9447a038dd3eeee2b975146d10fba0
Unlike osmo-pcu, osmo-bts does check length of the messages received
over the PCU interface, so I7a532d7abff8af354e40c5d706bb882efc6f905f
caused all the related test cases in ttcn3-bts-test to fail.
Reverting it is not a solution, because we cannot maintain different
padding attributes for two different protocol versions. Let's add
a wrapper function that would call enc_PCUIF_Message() and append
padding depending on the configured protocol version. In addition,
let's add a module parameter that would allow us to (optionally)
disable padding for ttcn3-pcu-test.
This change makes all broken PCUIF specific test cases pass.
Change-Id: Ica9e0c49c8b16e7d585a481670762c6433c61118
There is no reason whatsoevery why a L3_Templates.ttcn file should
ever include types from RLC/MAC. This creates a dependency nightmare.
The type for which ts_RaCapRec is written (MSRACapabilityValuesRecord)
originates from titan.ProtocolModules.MobileL3 so it's completely
unclear how any of that ever related too RLC/MAC.
Change-Id: Ie1ccef090ad51e26ccae17998e4294c6e27cf9c8
This in turn means Osmocom_Gb_Types doesn't need to depend on
GSM_RR_Types anymore, which is particularly ugly as the latter
now depends on RLCMAC_*, creating a long chain of dependencies.
Change-Id: I8c8da7709695ff0023f71b3999291e2515b22e46
If test calls RTPEM_bind twice, the previous socket is kept open
(ConnId 1) while the new one is assigned to the the expected ConnId for
RTP/RTCP packets received (ConnId), however, if remote was already
sending packets, it may happen that the port still receives those with
ConnId=1, which may make test fail with message:
"Received unexpected type from RTP"
Change-Id: I73f4af4e590dd3958e3f4d1dba0496c0750d642d
My initial assumption was that we can skip redundant '0'B bits or
even '00'O octets in the Mobile Allocation IE, and thus reduce
the overall size of this element. Unfortunately, this is wrong.
3GPP TS 44.018, section 10.5.2.21 clearly states that the Mobile
Allocation IE contains a bit-string of size NF, where NF is the
number of frequencies in the cell allocation. If NF % 8 != 0,
then '0'B padding bits must be appended to make it octet-aligned.
In other words, if the cell allocation contains let's say 13
frequencies, but a hopping timeslot makes use of only a small
fraction of it (e.g. 4 first channels), we would still need to
transmit at least 13 bits (+padding), including all redundant
bits and octets.
In RLC/MAC frames though it's not required to make the bit-string
octet aligned, so we need to send exactly NF bits without padding.
In order to achieve that:
a) add MA length field to INFO.ind (record PCUIF_InfoTrxTs);
b) ajust the existing test cases to use this field.
It's safe to merge this change as the related patches have not
been merged to osmo-pcu and osmo-bts yet.
Change-Id: I2709673c90a0cd7d76de9db8b8ad82ac59ca84a0
Related: SYS#4868, OS#4547
Otherwise TITAN would refuse to decode any messages:
Dynamic test case error: While RAW-decoding type
'@BSSAP_LE_Types.PDU_BSSAP_LE': Can not decode type
'@BSSAP_LE_Types.PDU_BSSAP_LE', because invalid message was received
Change-Id: I3db7e8784efd067ccf0bc7dbc234d9b4ff1c033c
Related: OS#4597
This way one can simply pass an IP addr in string format and return the
IE no matter the IP version.
Change-Id: I743dbb7c89e504762498b7f278c12e130352e5f0
Similar to [1], the existing implementation [2] is unfriendly
to use, so let's work this around by defining a minimalistic
implementation of (RR) Handover Command.
[1] If1a5244a688abed6e6de2bf3f6e19e0e28129ea5
[2] titan.ProtocolModules.MobileL3_v13.4.0
MobileL3_RRM_Types.PDU_RRM_HandoverCommand_NW_MS
Change-Id: I08e6d33a725f99e2c92f93153b2369c4c764c012
Related: SYS#4868, OS#4545
Unfortunately, the existing implementation [1] is somewhat
incomplete and unfriendly to build templates on:
- some fields holding integer numbers defined as BITx,
so we would have to do bit2int() / int2bit();
- some bit-map fields defined as octetstrings;
- some fields are not decoded at all (raw octetstrings).
Let's work this around by defining a minimalistic implementation
of (RR) Assignment Command with all mandatory and some optional
fields. Reuse some IEs directly from MobileL3_RRM_Types.
[1] titan.ProtocolModules.MobileL3_v13.4.0
MobileL3_RRM_Types.PDU_RRM_AssignmentCommand_NW_MS
Change-Id: If1a5244a688abed6e6de2bf3f6e19e0e28129ea5
Related: SYS#4868, OS#4545
Most likely, the second part of the condition was copy-pasted
from ra_is_ps(), where the specs. require that at least one
of the three LSB's shall be zero. This requirement does not
apply to emergency RA values in range '101xxxxx'B.
Change-Id: I4c923682edfeee9c6bf3aeeeb67438809a54109f
Those two modules are analogous to BSSAP/BSSMAP CodecPort and Emulation,
but for the Lb interface (BSC-SMLC) instead of the A interface.
Change-Id: I92fd91056731abb8d3c01560f80c01c6a48a6fc9
osmo-pcu.git 0052051c07af63da98137c9f8e3b3119642eb587 introduced a bug
(fixed in 1d68cdff928f32941aff36c70e4543203c283d15) where no MS could
GMM attach to the network, but no test showed the issue.
This couple test verifies both correct behavior and also ensures wrong
IMSI is detected and reported.
Related: OS#4729
Change-Id: I5072d80b7ed9945a6083cdf3254efb8b8f119c54
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
Harald Welte
Neels Hofmeyr
Daniel Willmann
Vadim Yanitskiy
Pau Espin
Philipp Maier