enum gsm0808_permitted_speech does not have any value strings. Lets
add value strings to make debugging easier.
Change-Id: I5b5612a5df2758b0137a34c17f7c8c2b3f07c806
The value string table gsm48_chan_mode_names[] lacks a function
to get the value string by a value. Lets add one.
Change-Id: I0757bcc278c140e18249e35864338e19cdaa3cf7
Add:
gsm0808_create_handover_detect()
gsm0808_create_handover_complete()
gsm0808_create_handover_failure()
To existing structs gsm0808_old_bss_to_new_bss_info and
gsm0808_handover_required, add a final 'more_items' flag that makes future
extensions API and ABI compatible.
Fix the msgb string for Handover Request Ack.
Extend some API doc comments.
Related: OS#2283 (inter-BSC Handover, BSC side, MT)
Change-Id: I03ee7ce840ecfa0b6a33358e7385528aabd4873f
In Change-Id I1cee271fed0284a134ffed103c0d4bebbcfde2a8 we added support
for a new session state IE, but we didn't add any value_string array
for string conversion of it. Let's fix this.
Change-Id: I3d9f087786dc37c42498fa9a2be07483ec93ba7b
This function can be used to resolve the error message type for
a given message type. Can be used by generic error handlers that
work for any incoming message type.
Change-Id: Ic637bec53dd7fe3ec83da99b49b4eae34d5602b2
This function can be used when there is only a part of GSM 04.80
message available - Facility IE, e.g. when a message is carried
over GSUP/MAP. Let's expose it.
Refactoring includes the following:
- adding the 'gsm0480_' prefix;
- correcting inverted return value;
- cosmetic code style changes.
Change-Id: I623c39ffbe6cdee65eade8435a2faa04d0da193e
In some cases, there is no need to parse the whole message,
e.g. during the conversion from DTAP to GSUP/MAP. This
function can be used to extract given IE from a message.
Change-Id: I3989d061903352473305f80712f1a1560d05df3d
In order to be able to transfer SS/USSD messages via GSUP,
this change introduces the following new message types:
- OSMO_GSUP_MSGT_PROC_SS_*,
and the following new IE:
- OSMO_GSUP_SS_INFO_IE
which represents an ASN.1 encoded MAP payload coming to/from
the mobile station 'as is', without any transcoding.
Change-Id: Ie17a78043a35fffbdd59e80fd2b2da39cce5e532
Related: OS#1597
Unlike TCAP/MAP, GSUP is just a transport layer without the
dialogue/context. This prevents us from having session based
communication, required e.g. for USSD. But we can emulate
TCAP dialogue by adding additional IEs, which would allow
to relate each message to a particular session.
This change introduces the following IEs:
- OSMO_GSUP_SESSION_ID_IE,
- OSMO_GSUP_SESSION_STATE_IE,
which optionally can be used to indicate that the message is
related to a session with given ID, and to manage session
state, i.e. initiate, continue, and finish.
Change-Id: I1cee271fed0284a134ffed103c0d4bebbcfde2a8
Related: OS#1597
The idea is to be able to add a gsm0808_cell_id to a gsm0808_cell_id_list2:
first convert it to a list, then re-use gsm0808_cell_id_list_add(). It will be
used by osmo-bsc to manage neighbor-BSS cell identifiers from VTY.
Change-Id: Ibf746ac60b1b1e920baf494b396658a5ceabd788
For some strange reason, the osmo_mncc_name() inline function
was not in the mncc.h header, but in the mncc.c file. Let's fix that.
Change-Id: I2c3666510c981dffa4ba25bed517fd7ebd1250f5
Add:
- gsm0808_current_channel_type_1()
- gsm0808_permitted_speech()
- gsm0808_chosen_channel()
- gsm0808_channel_type_name()
gsm0808_permitted_speech() is moved from osmo-bsc's bssap_speech_from_lchan();
gsm0808_chosen_channel() is moved from osmo-bsc's lchan_to_chosen_channel();
Rationale: will be re-used by inter-BSC handover, makes sense to keep with the
other gsm0808 utils.
Related: OS#2283 (inter-BSC handover, BSC side)
Change-Id: I8a3cc5d4548e9a78d945d54c69ccced251edcec9
According to TS 24.008 10.5.4.7 the called party BSC number IE
has a maximum length of 43 octets.
This length is assumed inside osmo-hlr with a magic number:
uint8_t msisdn_enc[43]; /* TODO use constant; TS 24.008 10.5.4.7 */
This change makes libosmocore provide a constant which osmo-hlr can use.
Change-Id: Ia0bf6ceadcac38a8c75d166402b54058e5c6c6d4
Ericsson supports a RSL command to page and immediate assign
as single command. For paging a MS the BTS must know the
paging group.
Change-Id: I9194500e307ad69f8da07510bc965a7a5cd82a2a
We are alredy doing the same way for ip.access and siemens ones, and
this way we avoid using the hardcoded value in osmo-bsc.
Change-Id: I7cb65f3ff1cfdbe4eee97b7545bcd13a38c72e25
Provide comprehensive API to obtain string representations of Cell Identifiers
and -Lists.
Change gsm0808_test.c to use the new functions (which simplifies the output a
bit), so that we don't duplicate printing code in gsm0808_test.c, and so that
the not-so-trivial printing code is also tested.
In gsm0808_test, also test gsm0808_cell_id_list_name_buf()'s return value and
truncation behavior.
The rationale for gsm0808_cell_id_list_name(), i.e. printing an entire list of
cell identifiers, is that even though the maximum is 127 elements, a list of
more than a few elements is hardly ever expected in practice (even more than
one element isn't actually expected: either "entire BSS" or a single LAC). It
is thus useful to log the entire list when it shows up in Paging and Handover.
Change-Id: I9b2106805422f96c5cc96ebb9178451355582df3
Rationale: so far we use code like
if (TLVP_PRESENT(&tp, VERY_LONG_ENUM_VALUE_NAME_THAT_NEVER_ENDS)) {
val = TLVP_VAL(&tp, VERY_LONG_ENUM_VALUE_NAME_THAT_NEVER_ENDS);
len = TLVP_LEN(&tp, VERY_L0NG_ENUM_VALUE_NAME_TH4T_NEVER_EMDS);
}
This is a) very long and b) prone to picking the wrong name one of the three
times, which would use the wrong length or val without necessarily being
noticed. A safer and shorter, more readable pattern is:
struct tlv_p_entry *e = TVLP_GET(&tp, VERY_LONG_ENUM_VALUE_NAME_THAT_NEVER_ENDS);
if (!e)
return -ENOENT;
hexdump(e->val, e->len);
Change-Id: I445de17fc2daa3ab051f5708dd0cc185b23dc048
According to the GSM TS 04.07, section 11.2.3.1.1 "Protocol
discriminator", bits 1 to 4 of the first octet of a standard
L3 message contain the protocol discriminator IE.
Meanwhile, the GSM48_PDISC_USSD represents value 0x11, i.e.
0b10001, that requires 5 bits, and moreover it is not
documented anywhere. Let's drop it.
Change-Id: Ic4eb8a6db4ff1dfd535bd0c84e7acf1908422f64
Clarify semantics and micro-optimise for the case of single Cell Identifer IEs.
Test in gsm0808_test.c
So far we have gsm0808_enc_cell_id_list2(), but there also exist instances of
single Cell Identifiers (3GPP TS 48.008 3.2.2.17).
It is possible to decode the same using the cell identifier list API, but this
forces the caller to also keep a full struct gsm0808_cell_id_list2 with all its
127 entries around.
E.g. for handover, there are two Cell Identifiers (Serving and Target); I'd
need two full cell id lists for each, and these would be dynamically allocated
for each handover operation, whether it uses them or not.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: I9f9c528965775698ab62ac386af0516192c4b0cc
Allow passing multiple struct tlv_parsed in an array, to allow parsing as many
repeated IEs as are expected by the caller.
From tlv_parse(), call tlv_parse2() with dec_multiple = 1 to yield the previous
behavior. tlv_parse() remains valid API.
An example of multiple IEs is the BSSMAP Handover Request, containing Cell
Identifier (Serving) and Cell Identifier (Target), both defined by 3GPP TS
48.008 3.2.2.17 with identical IE tags; both are mandatory.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: Id04008eaf0a1cafdbdc11b7efc556e3035b1c84d
This will be used by the upcoming neighbor_ident API in osmo-bsc, where the vty
interface allows composing neihbor BSS cell identifier lists, and we want to
allow adding individual items from individual user commands.
It will also be useful to accumulate cell identifiers in case a subscriber sees
multiple alternative cells from a neighboring BSS, and we want to pass these on
to the MSC in a Handover Required.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: I5781f5fa5339c92ab2e2620489b002829d206925
This will be used by cell idenitifier list code, like upcoming neighbor_ident
VTY in osmo-bsc and regression tests.
Change-Id: Iebc5cdf61b697b1603900993fc265af3eca0cedf
All our projects have seen patches to move to 3-digit MNC handling.
Furthermore, since our builds no longer break from deprecation warnings, I shall
no longer refrain from deprecating old API.
Change-Id: I55dfaf7ce74870de44120b26c42d45bb7b184341
There seems to be quite some confusion / overlap between enum
gsm48_reject_value, gsm48_gsm_cause and gsm48_gmm_cause. I tried to go with
gsm48_gsm_cause_names[], but e.g. GSM48_REJECT_CONGESTION is not represented.
Instead of attempting to mix/merge those enums, provide a separate value string
array for enum gsm48_reject_value.
This will be used by osmo-msc's libvlr (refactoring of FSM result handling),
I27bf8d68737ff1f8dc6d11fb1eac3d391aab0cb1.
Change-Id: I6661f139e68a498fb1bef10c266c2f064b72774a
As it was already documented before, the 'ss_request' struct has
a rudiment of deprecated 'ussd_request' struct - the 'ussd_text'
field. It represents the data either of an INVOKE component,
either of a RETURN_RESULT component, encoded as ASCII in case
if DCS is 0x0f (i.e. decoded by the code itself), otherwise
raw bytes 'as is'.
Previously, there was no possibility to distinguish between
ASCII and raw bytes with different DCS. Moreover, the payload
decoding is not desired in some cases.
Let's introduce the new fields, which will carry the raw
unmodified payload, its length and DCS (Data Coding Scheme).
Change-Id: Ia193d175021e145bb3b131290231f307dbefc64a
libosmocore has no value strings for BSSMAP cause codes yet.
- Add value strings for BSSMAP cause codes and a function
to retrieve them
Change-Id: I313dd8d7b06374e1e35ddc18b7a42562d9e25d45
Related: OS#1609
The speech codec defaults are not correct. The defaults recommended
in 3GPP TS 28.062, Table 7.11.3.1.3-2 are limited by 3GPP TS 48.008,
Section 3.2.2.103. Some defaults are actually reserved for future
use. Also the endianess of the 16 bit values is reversed.
- correct values so that they match the specification
- transmit bytes in the correct endianess
Change-Id: I6c3a34d39a375d71c4128fd38f06629e8b98b100
This is a more modern way of printing the Abis OML Formatted Object
Header, without assuming that it would be used in a log statement
or prescribing the log level to be used.
Change-Id: I9b2c2afec28882b817d104d5b062651ade7aadd8
Introduce gsm0808_dec_cell_id_list2() with supports additional types of
cell identifier lists. The new parsing routines are based on similar
routines used by the paging code in osmo-bsc's osmo_bsc_bssap.c.
Likewise, introduce gsm0808_enc_cell_id_list2() with support for the
same additional types of cell identifier lists.
The old API using struct gsm0808_cell_id_list is deprecated.
The previous definition was insufficient because it assumed that all
decoded cell ID types could be represented with a single uint16_t.
It was declared in a GSM protocol header (gsm/protocol/gsm_08_08.h)
despite being a host-side representation of data in an IE.
The only user I am aware of is in osmo-msc, where this struct is used
for one local variable. osmo-msc releases >= 1.1.0 make use of this API.
While here, fix a small bug in a test:
test_gsm0808_enc_dec_cell_id_list_bss() set the cell ID type to 'LAC'
but obviously wants to use type 'BSS'.
Change-Id: Ib7e754f538df0c83298a3c958b4e15a32fcb8abb
Related: OS#2847
The functions osmo_bts_set_feature() and osmo_bts_has_feature() are
currently defined as inline. Since inline is a hinting, the compiler
might choose not to inline the function. This eventually leads to
linker problems because the function is then defined multiple times.
- use "static inline" instead of "inline" only.
This patch is a follow up patch to
Change Id 680acae725
Change-Id: Iddd97415a17b06b69f69ddca2e2e296eb2f23a89
I found myself often using osmo_mnc_from_str() to also decode an MCC and be
strict about it, but each time I felt the need to comment like "using
osmo_mnc_from_str() also for MCC". Rather formalize this properly.
Use a static inline function, no need to add more symbols to libosmo-gsm.
Change-Id: I020a4f11791c61742a3d795f782805f7b7e8733e
osmo-bsc and osmo-bts share enums and value strings to describe
feature data that is exchanged via OML (manufacturer id) on startup.
Also the functions to set and get the respecitive bits in the feature
bitvectors are in osmo-bsc and osmo-bts. This is a code duplication
and should be resolved.
- add enum osmo_bts_features (replaces enum gsm_bts_features)
- add osmo_bts_features_descs (replaces gsm_bts_features_descs)
- add osmo_bts_set_feature (replaces gsm_btsmodel_set_feature)
- add osmo_bts_has_feature (replaces gsm_btsmodel_has_feature)
Change-Id: Id0c35aef11aa49aa40abe7deef1f9dbd12210776
In some cases, we want to mark an unset MCC-MNC. Define uint16-max for this
purpose.
osmo-bsc code is already doing so with a -1 and using int data types, which
will become inconvenient with the new API that handles MCC and MNC as uint16_t.
Change-Id: Ieee7add0bd6d94cf84743a49794bbcd38561b72f
osmo_mnc_from_str() preserves leading zeros in the string and is useful for
VTY config parsing (osmo-bsc, osmo-msc, osmo-sgsn, osmo-pcu).
osmo_{plmn,mnc}_cmp() takes care of the slight intricacy of ignoring the 3-digit flag
if the MNC is anyway >99. Will be used by osmo-sgsn.git and osmo-bsc.git. (All
current users just care about identical MNC, but a proper cmp doesn't hurt.)
Change-Id: Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6
Enable representing three-digit MNC with leading zeros. The MNCs 23 and 023 are
actually different; so far we treated both as 23. Re-encode an incoming BCD or
string of 023 as it were, i.e. not dropping the leading zero as 23.
Break ABI compatibility by changing the size and ordering of structs
gprs_ra_id, osmo_plmn_id, osmo_cell_global_id, ... by adding an mnc_3_digits
flag.
Change ordering in gprs_ra_id because the canonical oder is {Mobile Country
Code, Mobile Network Code}, so have the mcc member first.
ABI compatibility cannot be maintained for struct gprs_ra_id, since it is a
direct member of structs bssgp_bvc_ctx and bssgp_paging_info, and even just
adding a flag to the end would cause ABI changes of those structs. Similarly,
osmo_plmn_id is a direct member of osmo_location_area_id, and so forth.
Add new API to set and read this additional flag to preserve leading zeros:
- osmo_plmn_to_bcd(), osmo_plmn_from_bcd() after
gsm48_mcc_mnc_to_bcd() and gsm48_mcc_mnc_from_bcd().
- gsm48_decode_lai2(), gsm48_generate_lai2() after
gsm48_decode_lai(), gsm48_generate_lai().
- gsm0808_create_layer3_2() after gsm0808_create_layer3() and gsm0808_create_layer3_aoip().
- various osmo_*_name() functions in gsm23003.h (osmo_rai_name() still in
gsm48.h close to struct gprs_ra_id definition). The amount and duplication of
these may seem a bit overboard, but IMO they do make sense in this way.
Though most code will soon see patches unifying the data structures used, in
some cases (vty, ctrl) they are required singled out. Without these
functions, the formatting ("%0*u", mnc_3_digits ? 3 : 2, mnc) would be
duplicated all over our diverse repositories.
In various log output, include the leading MNC zeros.
Mark one TODO in card_fs_sim.c, I am not sure how to communicate a leading zero
to/from a SIM card FS. The focus here is on the core network / BSS.
To indicate ABI incompatibility, bump libosmogsm and libosmogb LIBVERSIONs;
adjust debian files accordingly.
Implementation choices:
- The default behavior upon zero-initialization will be the mnc_3_digits flag
set to false, which yields exactly the previous behavior.
- I decided against packing the mnc with the mnc_3_digits field into a
sub-struct because it would immediately break all builds of dependent
projects: it would require immediate merging of numerous patches in other
repositories, and it would make compiling older code against a newer
libosmocore unneccessarily hard.
Change-Id: Id2240f7f518494c9df6c8bda52c0d5092f90f221
So far, we used quarter-bits across the L1SAP between the hardware/PHY
specific part of OsmoBTS and the common part. In order to increase
the resolution, let's add fields/members for 1/256th bit.
In order to keep ABI and API compatibility, we use a union around the
old and new values, so old code will still compile + work withe new
libosmocore.
Change-Id: Ibb58113c2819fe2d6d23ecbcfb8b3fce4055025d
Harald Welte
Pau Espin
Philipp Maier
Neels Hofmeyr
Keith Whyte