CGI-PS type doesn't exist in GSM 08.08 Cell Id lists. That type of cell
id is osmocom-specific and used internally. In here CGI-PS is
automatically converted to CGI (since the later is an extension of this
one).
The encode/decode_cell_id_u are left intact (comment added) since those
can still be used (and are used by RIM code) to encode/decode TS 48.018
Cell Identifiers.
Related: SYS#4909
Change-Id: Id74f4577c397c1ba696f00395858311bd82cb2c8
It's a static internal function, so it makes sense to have it at start
of its related section.
It will be used by other functions in follow up patches.
Change-Id: I60f61f8f7bb6543feb068bdcee76d3b752565c95
Move it above the place where the bit is set, since the bit represents
whether Extension Information is available, not whether R99 is
available.
Change-Id: Ice592acc50a24efd7fe4cf1a91f1d48fd74f38d8
Comparing struct gprs_ra_id using memcmp can be error prone, so lets add
a compare function to compare two struct gprs_ra_id values reliably.
Change-Id: I4d7558c04d9d01761516526086be5104bb2eeada
Related: SYS#5103
Using 'uint8_t' for the length argument is definitely a bad idea.
Because of this, packing more than 255 septets would not work as
expected. Deprecate the old function and use 'size_t' instead.
Change-Id: Ib1aac538afeb0a5c76a1df472d555139a496e12e
This feature is used by BSC to gain knowledge on whether a given BTS
supports GPRS Cell Change Notification (CCN) related procedures on PDCH,
and as a result enable or not by default the CCN_ACTIVE bit in SI13 to
announce the support it is allowed to use the feature.
Related: SYS#4909
Change-Id: I61991266b95d0c13d51b47906cc07846e9cf1390
Older commit adding the 2 bits for Rel-4 extension forgot to increase
the length field (see TS 44.060 Table 12.24.1)
Fixes: 946bb95af1
Change-Id: I20efb4403cdf6c5bc717502a7075630044142f17
The libosmocore TLV parser had a number of insufficient bounds checks
leading to reads beyond the end of the respective input buffer.
This patch
* adds proper out-of-bounds checks to all TLV types
* simplifies some of the existing checks
* introduces test cases to test all the corner cases
where either TAG, or length, or value are not fully contained
in the input buffer.
Thanks to Ilja Van Sprundel for reporting these problems.
Change-Id: I98b02c914c9e3ecf56050af846292aa6979d7508
This structure is needed in order to identify a given cell within the
BSS during RIM transactions.
The naming was made up by myself since I couldn't find any naming
reference for this kind of data (RAI + CI).
Since LAI + CI = CGI, then RAI + CI = CGI-PS
osmo_rai_name2 family of functions get a "2" suffix due to already
existing functions handling struct struct gprs_ra_id in gsm48.h
Change-Id: If48f412c32e8e5a3e604a78d12b74787a4786374
We used to suppress/drop any "zero length" messages, but we didn't
include the header when computing the length. However, in CBSP there
are messages (at least KEEP-ALIVE-COMPLETE) which only consist of the
header without any information elements. We cannot simply drop such
messages.
This also fixes the return value of osmo_cbsp_recv_buffered() to be
the total number of received octets (including the header).
Change-Id: Ib620128a167cb77f061ee57e8f8ad707b96b1c0d
This is a fixed-length Tag-Value IE. Our decoder already parsed
it correctly, but the encoder encoded it as TLV, which is wrong.
Change-Id: I7e1d7eab8b8e51acd9a24c38e2d3d30bbf00847a
This reverts commit c9eab828ea.
The initial code was correct, which has also been used in osmo-bsc until
recently, where it moved to use this function from libosmocore and
errors started to show up in TTCN3 tests.
See 3GPP TS 44.018 Section 10.5.2.34 / Table 10.5.2.34.1: "SI 3 Rest
Octets information element":
"""
<SI3 Rest Octet> ::=
...
<3G Early Classmark Sending Restriction>
...
<3G Early Classmark Sending Restriction>::= L | H;
"""
Change-Id: I0ee48d3240c62c4d2e15063b26da7a2a617f383e
Related: OS#3075
Related: SYS#4021
We must always send the RELEASE.{indication,confirm} last before
returning from a function. We cannot rely on the datalink to
still be around after the call, as the SAP user might have destroyed
the data link meanwhile.
This fixes a heap use-after-free (at least) with RBS2000 when the BTS
is fully brought up and the OML data link is lost, see OS#1762
Change-Id: I8ccca8d5e5d07b666557afe12ab8ac4910ddfb00
Related: OS#1761
Related: OS#1762
This is required in order to tell MS that osmo-pcu now supports
Network Assisted Cell Change (NACC).
Related: SYS#4909
Change-Id: I2aaa8c1107c977f711c2d7530034f57e36e3a237
Commit bd6e7a9f2d did the initial porting
of rest_octet APIs from osmo-bsc, but introduced a bug when moving
bts->e_offset to a generic pointer independent of bts structure.
As a result, using this API from osmo-bsc makes gsm0408 unit test fail
due to bad encoding of several EARFCNs in si2quater.
Fixes: bd6e7a9f2d
Change-Id: I2bf5635b8536b11d69774d17ac1908019633e3af
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25.
Removing only 25 bits from the budget resulted in malformed SI2quater starting
with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits.
These malformed SI2quater were also expected in gsm0408_test.c. Update the
expected SI2quater to what is being generated now. This patch passes the ttcn3
testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some
confidence that the coding expected in gsm0408_test.c is now correct.
This commit is a cherry-pick of osmo-bsc.git 6589f7c3a8dfdaaf66dda3afa6bbb1118ec825f9
Change-Id: Icc1ece39ad162d09720e104c5cbc12b07d6771a8
Related: OS#4652
When we add an EARFCN to to the SI2quater struct we do not add Serving
Cell Priority Parameters. This essentially causes to MS to ignore the
EARFCN because it is still undefined under which conditions the MS
should change to LTE.
This is a cherry-pick from osmo-bsc.git 295c965c063a8c431507191f6aef1ef78b720685
Related: SYS#4510
Change-Id: If9134759e9bc4ae0920800972632fd8c5dc9c2d9
This extends our existing TLV parser with the ability to
* validate that mandatory IEs of a given message are present
* validate that all present IEs are of required minimum length
Introducing this generic layer will help us to reduce open-coded
imperative verification across virtually all the protocols we
implement, as well as add validation to those protocols where we
don't properly perform related input validation yet.
Change-Id: If1e1d9adfa141ca86001dbd62a6a339f9bf9a912
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
This is fixed version of Ic8b2bfd00330235f5bed00771e421588abfaac1f,
which got reverted because it used the keyword "class" as struct member,
which lead into problems with c++ builds. This is now fixed.
Change-Id: Id8732551b33616227609cd6fcf6c3133751a89eb
Related: OS#4796 SYS#5114
This reverts commit a4939dc846,
which caused massive build failures in C++ programs like osmo-pcu
- unsurprisingly, as it calls a struct member "class", which is a
reserved keyword in C++.
Change-Id: Ia43e56385e7b580f492c560aee8ff8b1e8a0e1d8
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
Change-Id: Ic8b2bfd00330235f5bed00771e421588abfaac1f
Related: OS#4796 SYS#5114
3GPP TS 24.008, section 10.5.1.7 specifies a Repeated ACCH Capability
bit in the Classmark 3 IE. Unfortunately, there is no way specified how
the Repeated ACCH feature should be controlled on RSL level. Since it is
not unusual that BTS/BSC vendors occassionally add proprietary IEs to
different RSL messages we may pick this as a solution as well and add a
propritary RSL_IE_OSMO_REP_ACCH_CAP IE, so that we can enable repeated
FACCH/SACCH on the BTS side when we send RSL CHAN ACT or RSL CHAN MODE MODIFY
messages.
Change-Id: I61ea6bf54ea90bd69b73ea0f0f3dc19a4214207b
Related: OS#4796 SYS#5114
It could be that this spelling variant was originally used in the
specs., but now at least in 3GPP TS 44.018 they use 'existEnt'.
Change-Id: I847de910411f2edf7cc45b8c296b43e65fed5447
3GPP TS 44.006 8.6.3 "Procedures for re-establishment" is quite
explicit:
"""
When the data link layer receives in the multiple frame established state
or !!!timer recovery state!!! a DL-ESTABLISH- REQUEST primitive from layer
3 or an SABM (with L=0), the normal establishment procedure of sub-clause
8.4.1.2 shall be initiated.
"""
If L>0 in that state, send a DM as stated in 8.4.1.2:
"""
If the data link layer entity is unable to enter the multiple-frame-established
state, it shall respond to the SABM command with a DM response with the F bit
set to the same binary value as the P bit in the received SABM command.
"""
Related: OS#4549
Related: OS#4819
Change-Id: I7959dc39f883cd5c56c36a21176a2401838d7b62
As pespin point out, the kernel coding style says:
Do not unnecessarily use braces where a single statement will do.
[...]
This does not apply if only one branch of a conditional statement is a single
statement; in the latter case use braces in both branches:
Change-Id: Ia23c4bd018db141ff0afe77fe25678a9b2a395f0
The DEC_ERR() macro has a check for a missing type, but when used on the uint
h.type variable, emits a warning about an always-true statement. Try to work
around that warning with a cast to (int).
Related: CID#214888 CID#214890 CID#214891
Change-Id: Ic5fa87d23a6f0ce872de9c1dcfe36023981f70de
BSSLAP: there are APDUs transferred in BSSMAP-LE Connection Oriented
Information messages on Lb between BSC and SMLC.
Add BSSLAP coding for these APDU messages:
- TA Layer3
- TA Request
- TA Response, possibly containing Location Estimate coded in GAD
- Reject
- Reset (for intra-BSS handover during TA Request)
- Abort (for inter-BSS handover)
Add encoding and decoding tests.
Change-Id: I6409c4bcac402dc7626a3afce9081c59cd715fe8
GAD, Universal Geographical Area Description:
- raw coding for all GAD elements.
- SI-units encoding and decoding for Ellipsoid point with uncertainty circle,
which I presume is the typical "at most N meters away from cell tower located
at X,Y", which corresponds to the TA positioning currently being implemented.
- other SI-units GAD element encodings are so far not implemented.
Add encoding and decoding tests.
In gsm/protocol/gsm_23_032.h are the raw coding structs as defined in 3GPP TS
23.032.
In gsm/gad.h are structs carrying consistent units based on meters and degrees,
for convenient / less error prone handling of GAD data, and for human readable
representations of the GAD data.
The separation of the two is desirable because OsmoBSC will receive GAD data
from OsmoSMLC on the Lb interface, and pass on this data to the MSC via the A
interface. It is better to pass the GAD data as-is without de/encoding.
Change-Id: I7a9dd805a91b1ebb6353bde0cd169218acbf223c
According to 3GPP TS 48.008, section 3.2.2.44, the Chosen Encryption
Algorithm IE, which may be included in the following messages:
- 3.2.1.2 ASSIGNMENT COMPLETE
- 3.2.1.8 HANDOVER REQUEST
- 3.2.1.10 HANDOVER REQUEST ACKNOWLEDGE
- 3.2.1.12 HANDOVER COMPLETE
- 3.2.1.25 HANDOVER PERFORMED
- 3.2.1.31 CIPHER MODE COMPLETE
is coded as follows:
0000 0001 No encryption used
0000 0010 GSM A5/1
0000 0011 GSM A5/2
0000 0100 GSM A5/3
0000 0101 GSM A5/4
0000 0110 GSM A5/5
0000 0111 GSM A5/6
0000 1000 GSM A5/7
basically A5/X => X + 1. All other values are Reserved for future
international use. As can be seen, value 0x00 is RFU. Passing
this value to some encoding functions would result in a PDU with
this IE omitted. Although, some functions would still encode
Chosen Encryption Algorithm IE with this RFU value.
Let's ensure that all functions behave consistently.
Change-Id: If10e433a8174eabe6aa6d2c2937bf9cf5d14d7c9
According to 3GPP TS 44.005, section 4.2.2 "Priority":
a) on DCCH, a SAPI=0 frame always has higher priority than SAPI=3;
b) on ACCH, the priority arrangement is more complex:
b1) if a SAPI = 3 frame is awaiting transmission, two SAPI=0
frames shall not be sent in consecutive SACCH frames;
b2) on the network side (LAPDM_MODE_BTS), it must also be ensured
that any SAPI=3 frame is followed by at least one SAPI=0 frame;
b3) a SAPI = 0 frame may be repeated in the next SACCH period
if the Repeated SACCH is supported (see 3GPP TS 44.006, section 11).
We definitely need to extend our testing coverage to ensure that
we implement b) correctly, but for now let's focus on DCCH:
a) for DCCH, ensure that SAPI=0 frames preceed SAPI=3 ones;
b) for ACCH, re-use the existing round-robin implementation.
Change-Id: Ia3780bce1222b312ae2fd2d21496a4d6c5ccb6e0
Related: SYS#5047, OS#4731
Pau Espin Pedrol
Pau Espin
Vadim Yanitskiy
Philipp Maier
Harald Welte