So far we are omitting the GlobalRNC-ID from all of our RANAP RESET
messages, because clearly, in 3GPP TS 25.413 9.1.39, the Global RNC-ID
is listed as optional.
OTOH, section 126.96.36.199 says
"The RNC shall include the Global RNC-ID IE in the RESET message."
Apparently an RNC must include this ID, while a CN omits it.
ranap_cn_rx_co and ranap_cn_rx_cl both have a void *ctx argument, that
gets passed to:
* a callback function and
* to various decode functions in the same file.
As it is named "ctx", it looks like a talloc context. But the decode
functions don't use ctx at all and so in reality it is private userdata
for the callback. It is used as such by test/hnb-test-rua and in
Start cleaning this up by removing the unused ctx args, a future patch
will rename it to priv and yet another patch will fix a compiler warning
in test/hnb-test-rua by properly using it as userdata arg.
Fix warnings from generated asn1 code in order to build osmo-iuh with
werror in a future patch:
../../include/osmocom/hnbap/HNBAP_CriticalityDiagnostics-IE-List.h:29:23: error: ‘struct HNBAP_CriticalityDiagnostics_IE_List__Member’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
These visibility warnings come from "SEQUENCE … OF SEQUENCE" definitions
in the asn1 source files, as described in detail here:
It is not possible to tell gcc to just ignore these warnings since they
don't have their own type (unlike e.g. -Wuninitialized). Also it seems
like a huge effort to patch this in asn1c.
So work around the problem the same way the author of the issue worked
around it by rewriting the lines to "SEQUENCE … OF …-Value" and adding
a "…-Value ::= SEQUENCE" line below. Add a script in
asn1/utils/asn1_restructure_sequence_of_sequence.py for the
transformation and apply it.
The message encoder functions that decode a message to a struct
ranap_message are only accessible via a callback function that is passed
to ranap_cn_rx_cx The decoded ranap_message only lives inside the callback
since it is freed by ranap_cn_rx_cx when the callback is done. In some
situations this might make using the decoder incredibly difficult since
it is not possible to keep the decoding results for an extended amount
of time. Lets put the decoding into a separate function and use this
function in ranap_cn_rx_cx. Then lets make the decoder and the free
function public so that the decoder can be used in a more open way.
The functions new_transp_info_rtp and new_transp_info_gtp are needed to
generate the transport layer information struct. The functions are currently
not public since they are only used in ranap_msg_factory.c but to
reqwrite the RANAP RAB AssignmentReqtest / AssignmentResponse messages we
can reuse this code, so lets make them public.
Same as already done for libosmo-ranap.
This allows applications setting the cateogy dynamically, and will allow
untangling library tests using hnbgw log categories in this repo.
This is an option enabled by default and not existent as cmdline param
since asn1c 0.9.26.
For some reason, when dropping it, asn1c generates different description
comment section on related files. In any case, this makes hnbap look
like other libraries which already got this param removed and hence also
generateds code looks the same.
Other libraries already use ASN1C_PREFIX except the HNBAP one. Let's use
it here to avoid collisions.
All new include/osmocom/hnbap/HNBAP_*.h and src/hnbap/HNBAP_*.c are
generated using the updated src/hnbap/Makefile.am.
Files such as src/*.c, test/* and include/osmocom/hnbap/hnbap_common.h
are modified manually to update structs/enums to new prefix.
This allows the SGSN always having feedback on the resolution of the
release, hence being able to stay in PMM CONNECTED state until the
resolution is received, then moving to PMM IDLE.
So far we don't really have any way of matching a given log message
to a specific hNB. Let's introduce a new log macro, together with
a configuration directive to select whether the hNB-ID or the
UMTS CellID shall be used.
This uses the (modified) Osmocom asn1c on the (modified) SABP ASN.1
syntax to generate C code + header files for SABP parsing/encoding.
It also adds some helper code for message encoding and decoding as well
as a new libosmo-sabp shared library which can be used by programs to
implement SABP related functionality.
Allow to free UE ctx when receiving a Iu Release Complete.
In preparation of ranap_iu_tx_release_free() it requires
a field to free the Iu ctx on it's own without depending
on the upstream user.
ranap_iu_tx_release_free is a fire and forget function to release
gracefully if possible. It first sends a Iu Release Command. After
a certain timeout the connection will be released.
The iu_client is informing the library user about global event.
In prepration to the tx_iu_release_free() call allow to
disable upstream notificatiosn
Include RANAP_KeyStatus.h so that we use the global enum RANAP_KeyStatus
instead of defining another only within the ranap_new_msg_sec_mod_cmd()
Add the 'show hnb NAME' VTY command which displays just
one specific HNB, addressed by its identity string.
This augments the functionality provided by 'show hnb all'.
The read callback should catch all errors already.
Previous when a read fails it:
* hnb_context_release() -> osmo_stream_srv_destroy() -> hnb_context_release()
On the second hnb_context_release() the hnbgw will crash because calling
llist_del() twice on the same object.
If we receive a HNB-REGISTER-REQ with a cell ID which is already used
by another registered NNB, log an error and send HNB-REGISTER-REJECT.
Tested manually by running two 'hnb-test' programs concurrently (they
need to listen on different telnet ports; this port is hard-coded so
I compiled two different hnb-test binaries).
Then I issued the 'hnbap hnb register' command on the telnet interface
of each, and verified that the correct action is logged by osmo-hnbgw.
Both hnb-test programs can connect, but only one of them can register
at a time. Killing a registered 'hnb-test' program terminates its
connection and allows the previously rejected one to register.
The new rejection log message looks like this:
hnbgw_hnbap.c:429 rejecting HNB-REGISTER-REQ with duplicate cell
This change depends on a new API in libosmo-netif, which is added in
Instead of listing each and every context map, rather output a summary of
Rationale: in a list of a hundred HNBs, I don't want to also see a dozen (or
potentially thousands of) context map lines for each. Furthermore, the conn IDs
aren't necessarily useful on network traces either.
For example, what was shown as SUA Id is incidentally the SCCP Reference, but
this is not a hard requirement and may change. Also, the reference is shown in
wireshark as a hex in mismatching byte order ... so rather don't bother.
The result now looks like
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "email@example.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS: 1 contexts: inactive-reserved:1
IuPS: 1 contexts: active:1
1 HNB connected
Related: OS#2772 OS#2773
add ranap_transp_assoc_decode() to decode the port information from
an RANAP_IuTransportAssociation_t field.
add ranap_transp_layer_addr_decode() to decode the ip-address from
an RANAP_TransportLayerAddress_t field.
In the vty config, use the SCCP address book to configure the local and remote
SCCP addresses. Add VTY commands to set the remote SCCP addresses by name,
derive the ss7 instance from these addresses:
cs7 instance 1
Enforce that both IuCS and IuPS use the same ss7 instance. In the future, we
may add the feature to use two separate instances.
Depends: libosmo-sccp I75c67d289693f1c2a049ac61cf2b2097d6e5687d,
To help split openbsc.git to separate MSC and SGSN repositories, place the
common Iu interface related code here in libosmo-ranap. Also apply various
improvements while moving (from intermittent code review).
The code depends on libosmo-ranap tightly. One reason to want this separate
from libosmo-ranap could be that it uses libosmo-sigtran, accepting an sccp
instance. However, including in libosmo-ranap is the simplest way to go. The
osmo-iuh build depends on libosmo-sigtran anyway because of OsmoHNBGW, and all
current users of libosmo-ranap also naturally link libosmo-sigtran already.
Apply prefix ranap_iu_ and RANAP_IU_ to allow smooth transition from the
openbsc.git iu_ to the libranap ranap_iu_ implementations.
Prune unneeded #include statements.
Instead of sccp_addr, store an rnc pointer in the ue_conn_ctx. To facilitate,
- Move iu_rnc struct to iu_client.h (as ranap_iu_rnc).
- Instead of sccp_addr, pass rnc to ue_conn_ctx_alloc().
- Pass a local struct new_ue_conn_ctx containing the sccp_addr and conn_id up
the RANAP handling stack in case of an InitialUE message.
- Separate the InitialUE message handling from cn_ranap_handle_co(), by moving
to new and separate cn_ranap_handle_co_initial(), so we can still pass a
looked-up ue_conn_ctx to all other cn_ranap_handle_co() code paths.
- Allocate the ue_conn_ctx only in ranap_handle_co_initial_ue(), not as early
Note that we are not actually ever using the rnc pointer now present in
ue_conn_ctx. It could be used for more concise paging, to first page only the
RNC where we last saw the subscriber. So far we page all matching LAC/RACs.
Tweak error logging: use __func__ instead of writing the function names as
- Move the asn.1 debug commands from logging over to the iu node. They are not
specific to the logging target. They could qualify for an entirely separate
'asn1' root node, but for simplicity place under 'iu'.
- Add the 'asn1' commands to ranap_iu_vty_config_write(), so far missing.
- remove the legacy "net." from a VTY error message, it is not known which name
the parent node of 'iu' has.
Depends: libosmo-sccp I85b46269dbe7909e52873ace3f720f6292a4516c,
libosmo-sigtran now has a "proper" SCCP/M3UA stack, so we can make our hnb-gw
3GPP compliant by switching from the old SUA code to the new universal SCCP
user API with support for (currently) M3UA and SUA.
Use one cn_link to STP: We will connect to the core network using an (Osmo)STP
instance that routes to MSC and SGSN, so we want one SCCP link instead of two.
The only difference between IuCS and IuPS is a different remote osmo_sccp_addr.
This has various effects through the messaging code; the patch is a bit larger
than I would like, but it is hard to separate out truly independent smaller
CS or PS domain was previously flagged in the separate cn_link, as ctx pointer
for two separate sccp_sap_up()s. Now there's just one such ctx, so determine
is_ps from the RANAP Domain Indicator, or from the conn's hnbgw_context_map:
- Add is_ps to context_map_alloc_by_hnb().
- To find a matching context, the RUA ID alone is no longer sufficient, also
match is_ps (possible optimization todo: separate lists).
We would send separate CS or PS Reset messages based on the cn_link, instead
send both CS and PS Reset at the same time for the single cn_link. This could
be adjusted to detect presence of MSC or SGSN instead.
Pending: adjust the VTY config to reflect that there is only one remote
address. Place a TODO comment for that.
rua_to_scu(): populate called and calling addresses for N_CONNECT and
Don't build dummy_cn, which is still implemented on SUA. Mark todo to maybe
re-include it based on M3UA later.
In hnbgw_cnlink, place sccp related items in a separate sub-struct.
Do not keep an llist of cn_links, just have the one. Remove iteration and list
Change jenkins script to build libosmo-sccp master.
Patch-by: hwelte, nhofmeyr
Basically copy-paste the Iuh local-ip and local-port code to provide
parameterization of the IuCS and IuPS remote addresses.
Add IUCS and IUPS nodes, enhance go_parent_cb and config writing accordingly.
Prepare for parameterization of IuCS and IuPS addresses:
Conform internal variable naming to local-ip, local-port, remote-ip,
remote-port (instead of bind-ip).
Rename HNBGW_IUH_LOCAL_IP_DEFAULT to HNGGW_LOCAL_IP_DEFAULT to be more general
and move it to the top.
Move a function doc comment to the .c file.
The standard osmo VTY terminology is 'remote-ip', 'remote-port', 'local-ip',
'local-port'. Conform to that. osmo-hnbgw is so far not rolled out widely, so
it makes sense to do this now.
Add the option to allow UE Register Requests with a TMSI identity.
Add VTY command to enable this option, 'hnbap-allow-tmsi'.
HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
UE registers with only a TMSI, we obviously can't store an IMSI. However, since
we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
accept the TMSI registration and carry on as usual. All that is needed for
proper operation is a valid UE context.
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected. So far this caused failures and the need to
make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
different network), so that UE registration switched back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current code
For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
upon first registration to the network.
Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
does include a page-to-all-HNBs in case the first HNB paging fails. But we must
be aware that UEs that register by TMSI will simply not have an IMSI recorded
in the list of UE contexts, so a lookup based on IMSI may fail.
Patch-by: Harald Welte <firstname.lastname@example.org>, me