3G is dead, you may think. From the perspective of large scale operators, that may well be the case, but this is precisely the reason why Open Source support for 3G is becoming increasingly interesting: when the focus for earning money shifts towards LTE infrastructure, the threshold for setting up 3G networks is becoming easier to surpass for everyone else.
We are implementing Iuh support in the Osmocom stack, mostly carried out by employees of sysmocom GmbH1, with highly appreciated (yet undisclosed) external backing.
Iu support in Osmocom will allow using a femto-cell aka hNodeB as BTS, thus enabling UMTS voice (IuCS) and data (IuPS) connectivity using FOSS software from the core network right up to the femto-cell's ethernet jack.
Here is an ASCII art overview of our current aim:
+------------+ +--------+ +----------+
UE <-->| hNodeB |<--Iuh---->| HNB-GW |<--IuCS-->| OsmoCSCN |
UE <-->| femto cell | ...-->| | ...-->| |
| | | | +----------+
+------------+<--GTP-U | |
\ | | +------+ +------+
| | |<--IuPS-->| SGSN |<--GTP-C-->| GGSN |
| +--------+ ...-->| | GTP-U-->| |
| +------+ / +------+
\_______________________________/
Iuh IuCS/IuPS
NAS +----+----+ +----+----+
Non-Access Stratum | CC | MM | | CC | MM |
- - - - - - - - - - - +----+----+-------+ +----+----+
| RANAP | | H | RANAP |
Access Stratum +---------+ HNBAP | N +---------+ - - SCCP USER SAP
| RUA | | B | SUA | \
+---------+-------+ - +---------+ |
| SCTP | G | SCTP | } SIGTRAN
+-----------------+ W +---------+ |
| IP | | IP | /
+-----------------+ +---------+
UE (User Endpoint) MS (Mobile Subscriber) mobile device
CSCN (Circuit Switched Core Network) == OsmoNITB without BSC
(Source: http://git.osmocom.org/osmo-iuh/tree/doc/protocols_around_hnbgw.txt )
3G Data Status¶
The best news first: in our lab, Daniel has successfully established the first functional UMTS data link!
In other words, the two GTP paths
hNodeB --Iuh--> HNB-GW --IuPS--> SGSN --GTP-C--> GGSN
hNodeB --GTP-U--> GGSN
are already functional in a basic fashion. To test it, you would need to checkout various branches in various git repositories. These shall soon be merged to the respective master branches, but currently, that would be:
- libasn1c: master
- asn1c: aper-prefix
- libosmocore: master
- libosmo-netif: sysmocom/sctp
- libosmo-sccp: laforge/wip
- osmo-iuh: master
- openbsc: daniel/gprs-iu
3G Voice Status¶
The voice link (IuCS) still needs some work before even the attempt of a location update will make sense. The point here is that previously, OsmoNITB would combine the roles of BSC with the MSC and further core network components. For Iuh, though, the BSC role is actually embedded in the hNodeB, and thus we are aiming to split the BSC part off of OsmoNITB.
The result will be called OsmoCSCN, CSCN meaning Circuit-Switched-Core-Network, which lives in openbsc.git/openbsc/src/osmo-cscn/ (branch sysmocom/cscn).
NOTE from the future: OsmoCSCN has since been renamed to OsmoMSC!
OsmoCSCN comprises of "only" the MSC and further CN components. It will feature an IuCS interface, as well as, eventually, a proper A-interface towards 2G BSCs, thus obsoleting the OsmoNITB at some point.
Implementing OsmoCSCN is mostly my task, and after sinking some time into training my eye on the fine line between BSC and MSC, I've finally started actual development with the dawn of 2016.
3G in a Nutshell¶
Let me illustrate some details of the Iu interfaces. The following is basically Harald's 3G talk at the 32c32, but with the sheer abundance of complexity it can't hurt to read it in prose.
HNB-GW¶
The HNB-GW, i.e. the HomeNodeB Gateway, merely reads the CN-DomainIndicator from the RUA layer, which says whether the frame is for voice or data comms (IuCS or IuPS). It then sends the actual RANAP payload either to the OsmoCSCN or the OsmoSGSN. The HNB-GW is implemented in osmo-iuh/src/hnbgw.c, compiling as osmo-hnbgw, and is (mostly?) complete.
An interesting factoid is that for an hNodeB, the GTP-Control handshaking goes via the HNB-GW, while the packet user data actually goes directly to/from the hNodeB and the GGSN.
HNBAP¶
HNBAP is merely the protocol employed to register an hNodeB with the HomeNodeB Gateway. After HNBAP is done, the hNodeB sends RANAP-over-RUA, which the HNB-GW happily passes on to the proper consumers.
SIGTRAN¶
Typically, the IuCS and IuPS interfaces would talk this layering of protocols:
CC/MM
RANAP
SCCP <--- note
M3UA <--- note
SCTP
IP
We do have SCCP support in Osmocom, but so far only for "connectionless" messages (like your standard UDP datagrams). Iu now adds the need for establishing and tearing down connections (like TCP).
However, since SUA does the same as SCCP-over-M3UA and is simpler to implement, our HNB-GW talks SUA towards IuCS and IuPS:
CC/MM
RANAP
SUA <--- note
SCTP
IP
To support third-party MSC and SGSN components, we would either add SCCP-over-M3UA capability, or simply use an external signalling gateway that supports both M3UA and SUA (should be possible e.g. with osmo_ss73).
Various SIGTRAN implementations:
IuCS/IuPS
usual
| simplest
| |
v v
+------+------+------+-----+
| SCCP | SCCP | | |
+------+------+ SCCP | |
| MTP3 | MTP3 | | |
+------+------+------+ SUA |
| MTP2 | | | |
+------+ M2UA | M3UA | |
| M2PA | | | |
+------+------+------+-----+
| SCTP |
+--------------------------+
| IP |
+--------------------------+
ASN1 Convolutions¶
RANAP, RUA and HNBAP, which make up the Iuh interface, are ASN1 encoded. Fair enough, but their ASN1 encoding uses APER, and heavily employs Information Object Classes (which basically means it wraps ASN1 encoded binary data in ASN1 IEs, with several levels of depth). In consequence, the libre asn1c compiler as-is unfortunately is not capable of generating de-/encoders for UMTS. The proprietary ffasn1c is capable of that, and we could publish the ffasn1c generated code without licensing problems, but we'd highly prefer to empower the FOSS community with the ability to modify and fix the ASN1 de-/encoders independently of proprietary software.
The great news is that Eurecom4 has worked on supporting both APER and the nested ASN1 structures ("Information Object Classes") in asn1c, and we are able to use their solutions in a FOSS way. With some fixes added, we have both their APER support and their pythonic solution for nested ASN1 available in Osmocom's libasn1c and asn1c git repositories5.
Another problem with the Iuh ASN1 is that various type names are identical across RANAP, RUA and HNBAP, while their encodings differ. This causes type name collisions in the code generated by asn1c, hence we have added prefixing support to our version of asn1c. This simply means that each RANAP-related type name or function begins with "ranap_", and RUA names begin with "rua_", thus avoiding any and all name collisions between those protocols. See osmo-iuh/include/osmocom/ranap/ and ../rua/.
It could be more beautiful, but the bottom line is that we now have fully free/libre support for Iuh ASN1 encodings. Cheers!
Conclusion¶
Osmocom is on a clear trajectory towards full 3G support, empowering remote communities and small to medium businesses worldwide. Work is ongoing, but the really hard problems have already been solved. Stay tuned!
External References
