Project

General

Profile

News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall): OsmoCon 2017 updates: Schedule, Travel Grants

Added by laforge over 7 years ago

OsmoCon 2017 updates

There are some updates related to OsmoCon2017, the first Osmocom Conference, held on April 21st, 2017 in Berlin, Germany.

Summary

Summary (for those too busy to read the full post):
  • Schedule of talks has been released
  • Travel Grants available for participants who are otherwise unable to travel to Berlin
  • Social Event details available, including menu
  • April 21st is approaching fast, make sure you get your Ticket in time. Limited number of seats available.

Details

Schedule has been release

The list of talks with their abstracts has been on the website for quite some time, but now we actually have put together a schedule based on those talks.

Please see OsmoCon2017 for the schedule.

As you can see, the day is fully packed with talks about Osmocom cellular infrastructure projects. We had to cut some talk slots short (30min instead of 45min), but I'm confident that it is good to cover a wider range of topics, while at the same time avoiding fragmenting the audience with multiple tracks.

Travel Grants

We are happy to announce that we have received donations to permit for providing travel grants!

This means that any attendee who is otherwise not able to cover their travel to OsmoCon 2017 (e.g. because their interest in Osmocom is not related to their work, or because their employer doesn't pay the travel expenses) can now apply for such a travel grant.

For more details see OsmoCon2017_TravelGrants and/or contact .

Social Event

Tech Talks are nice and fine, but what many people enjoy even more at conferences is the informal networking combined with good food. For this, we have the social event at night, which is open to all attendees.

See more details about it at OsmoCon2017_SocialEvent.

Cellular Network Infrastructure: Osmocom 3G and 2G Now Support Milenage Authentication

Added by neels over 7 years ago

The Osmocom core network landscape is transforming. Adding full UMTS Authentication support, paired with the 3G developments of the past year, has rocked the boat of the good old OsmoNITB. Here is why:

From previous 3G announcements1, you may already know that the OsmoNITB, the Network-In-The-Box, combines BSC, MSC and HLR (among other things), which has drawbacks. Our MSC code was nicely placed in a separate libmsc, but libmsc never stood on its own. From the start it always had its fingers deep in libbsc data structures. In 3G core networks, there no longer is a BSC, so we needed a clear interface to talk to libmsc, and make it not depend on libbsc. We do have a standalone OsmoBSC, so technically, it could talk to a standalone MSC implementation, instead of having both in the same program. Thus, on the 3G branch, we basically killed off the BSC part of OsmoNITB: the first step towards our brand new standalone OsmoMSC.

But what is a 3G core network without full 3G authentication? UMTS AKA2 was published in Release 1999 of the 3GPP technical specifications (R99) and provides the means for mutual authentication, usually using the Milenage algorithm. Since R99, SIM cards (USIM) not only verify their authenticity to the core network, they also expect the core network to verify its own authenticity, hence the term mutual authentication. 3G USIMs may fall back to pre-R99 authentication, but in general, 3G is expected to be synonymous with UMTS AKA. So far, Osmocom fell short of that.

We have had the Milenage algorithms implemented in libosmocore for years, but our stock OsmoNITB is unable to use it. The main reason: the subscriber database is incapable of managing UMTS AKA tokens. Another shortcoming of this database is that it runs synchronously in the OsmoNITB process: if it is locked or needs a bit longer, our entire core network stalls until the request is completed. And a third clumsy fact is that the OsmoSGSN cannot use OsmoNITB's subscriber database, duplicating the authorization configuration.

It made sense to solve all of these subscriber database problems in one effort, again trimming OsmoNITB, but this time at the other end. Enter stage the brand new OsmoHLR, a separate process managing the subscriber database:

  • OsmoHLR has full UMTS AKA support.
  • It serves GSUP to both our MSC and SGSN.
  • As a separate process, the HLR now runs fully asynchronously.

Of course, the MSC needs to act as a GSUP client to use the separate OsmoHLR server. We needed to teach libmsc to handle GSUP requests asynchronously. In the 3GPP TS specifications, this is handled by the VLR, the Visitor Location Register. So far the VLR existed implicitly within OsmoNITB, basically as an in-RAM storage of subscriber data read directly from the database storage. But the VLR is more than that: it is specified to follow detailed state machines interacting with MSC and HLR, which allow, you guessed it, asynchronous handling of subscriber data. With the HLR moving to a separate process, we needed to implement a VLR proper. A generic finite state machine implementation has been added to libosmocore, and the specs' state machine definitions for the VLR have been implemented, supporting UMTS AKA right from the start.

Adding the new feature set had the logical consequence of profound code changes. In the 3G developments, we have for some time called the OsmoNITB-without-BSC a Circuit-Switched Core Network (OsmoCSCN). As it turns out, OsmoCSCN was merely a working title, it is already gone from code and documentation. Because, what do you get when you also strip from it the HLR? You get an OsmoMSC! (Technically, to accurately call it "OsmoMSC", we would also need to externalize the SMS storage3. It's on the todo list!)

By now it may be clear to you that OsmoNITB will not be around for long. But the transition away from OsmoNITB is not trivial: users have to get familiar with the new OsmoHLR. OsmoNITB's VTY configuration commands for subscriber management no longer exist. And, of course, our OsmoMSC cannot talk to OsmoBSC yet: to fully replace OsmoNITB with OsmoBSC + OsmoMSC + OsmoHLR, we also need a proper A-interface implementation on the OsmoMSC side. Even though OsmoNITB will stick around as a 2G solution until then, the move to an external HLR process in itself is a profound change in admin processes.

In consequence, we have taken yet another profound decision: we will not merge these new developments to openbsc.git's master branch. To clearly mark the move to the new Osmocom core network topology with the VLR-HLR separation and support for 3G by the new OsmoMSC program, we will create a brand new git repository that will be the focus of ongoing development. The current openbsc.git repository will remain as it is; it may see backports in urgent cases, but in essence it will be laid to rest and clearly marked as legacy4. Before we can flip that switch, we still need to sort out some petty details of what should move where, and then agree on a good name for the new repository. Until then, 2G with UMTS AKA support will live on the openbsc.git vlr_2G branch, while 3G with UMTS AKA support will live on the vlr_3G branch. The vlr_2G branch still features an OsmoNITB, but with an external OsmoHLR. The vlr_3G (previously sysmocom/iu) extends the vlr_2G branch to transform OsmoNITB to OsmoMSC and support the IuCS interface.

What about UMTS AKA on packet-switched connections? OsmoSGSN has had a GSUP client for quite some time now5. In fact GSUP was initially named "GPRS Subscriber Update Protocol" -- the G now re-coined to "Generic". Adding UMTS AKA to the OsmoSGSN was a breeze. You don't even need a special branch for that, it's already merged to master.

UMTS AKA is not limited to 3G. Any 2G network that indicates compliance with Release 1999 in the System Information bits can benefit from mutual authentication, and so does Osmocom, now.

Here is an overview of the current landscape:

Legacy 2G without UMTS AKA
openbsc.git master

                   ┌────────────────────────┐
                   │ OsmoNITB               │
  ┌─────┐          ├╌╌╌╌╌┐ ╔═════╤════════╗ │
  │ BTS │ <-Abis-> │ BSC ┆ ║ SMS ┆ subscr ║ │
  │     │          └─────┴─╨─────┴────────╨─┘
  │     │
  │     │          ┌──────────┐         ┌──────────┐
  │ PCU │ <-Gb---> │ OsmoSGSN │ <-GTP-> │ OpenGGSN │
  └─────┘          └──────────┘         └──────────┘

2G with UMTS AKA
openbsc.git vlr_2G

                   ┌─────────────────────┐
                   │ OsmoNITB            │
  ┌─────┐          ├╌╌╌╌╌┐ ╔═════╗ ┌╌╌╌╌╌┤          ┌────────────┐
  │ BTS │ <-Abis-> │ BSC ┆ ║ SMS ║ ┆ VLR │ <-GSUP-> │ OsmoHLR    │
  │     │          └─────┴─╨─────╨─┴─────┘          │            │
  │     │                                           │            │
  │     │          ┌─────────────────────┐          │ ╔════════╗ │
  │ PCU │ <-Gb---> │ OsmoSGSN            │ <-GSUP-> │ ║ subscr ║ │
  └─────┘          │                     │          └─╨────────╨─┘
                   │                     │          ┌──────────┐
                   │                     │ <-GTP--> │ OpenGGSN │
                   └─────────────────────┘          └──────────┘

3G with UMTS AKA
openbsc.git vlr_3G

                                               ┌─────────────────────┐
                                               │ OsmoMSC             │
  ┌───────────┐         ┌───────────┐          │       ╔═════╗ ┌╌╌╌╌╌┤          ┌────────────┐
  │ 3G hNodeB │ <-Iuh-> │ OsmoHNBGW │ <-IuCS-> │       ║ SMS ║ ┆ VLR │ <-GSUP-> │ OsmoHLR    │
  └───────────┘         │           │          └───────╨─────╨─┴─────┘          │            │
                        │           │                                           │            │
                        │           │          ┌─────────────────────┐          │ ╔════════╗ │
                        │           │ <-IuPS-> │ OsmoSGSN            │ <-GSUP-> │ ║ subscr ║ │
                        └───────────┘          │                     │          └─╨────────╨─┘
                                               │                     │          ┌──────────┐
                                               │                     │ <-GTP--> │ OpenGGSN │
                                               └─────────────────────┘          └──────────┘

2G with UMTS AKA and 3G support are not packaged yet. To use them, you need to build the software from source.

  • For OsmoNITB with 2G UMTS AKA, you need to build openbsc.git using the vlr_2G branch.
  • For 3G including UMTS AKA support, refer to the 3G wiki page.

To get assistance, you may ask on the mailing list, or contact for example sysmocom for professional support and development services.

With the help of Osmocom's sponsors and supporters, including but not limited to NLnet and sysmocom, we were able to invest due time and effort and have reached a remarkable milestone: UMTS AKA is now supported on Osmocom 3G as well as 2G networks, using Free Software all the way. Thank you for making this possible!


1 News post: 3G Voice Works


2 Universal Mobile Telecommunications System, Authentication and Key Agreement protocol


3 So far our OsmoMSC has a local sqlite database to manage SMS persistently, which is still a potential source of stalling due to synchronism.


4 Another reason for moving to a new repository: OpenBSC was the early name of the project, but by now the lack of "Osmo" in its name is a source of confusion among new users, since "OpenBSC" wrongly suggests affiliation with the unrelated OpenBTS project.


5 See config item auth-policy remote.

Cellular Network Infrastructure: Call for accelerate3g5 Proposals Concluded

Added by neels over 7 years ago

The lucky receivers of a free nano3G femto cell sponsored by sysmocom have been contacted.
The selected projects will be documented at the [[cellular infrastructure:accelerate3g5|accelerate3g5 wiki page]].
If your project has been selected, kindly follow the instructions found there and mark the start of your project.

We are glad to have reached many new community members and are looking forward to seeing your projects evolve.
Here is a huge Thank You to all contestants from the Osmocom community and the sysmocom team!

Cellular Network Infrastructure: First OsmoCon Conference on April 21st, 2017

Added by neels over 7 years ago

The OsmoCon 2017 is the first technical conference for Osmocom users, operators and
developers and will be held on April 21st, 2017 in Berlin, with kind organizational
support by sysmocom s.f.m.c. GmbH.

For the first time ever, the Osmocom Conference brings together users, operators
and developers of the Osmocom Open Source cellular infrastructure projects, such as
OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others.

Join us for a day of presentations and discussions with the main developers behind
Open Source Mobile Communications, as well as commercial and non-profit users of
the Osmocom cellular infrastructure software.

Read more on our OsmoCon 2017 wiki page

Qualcomm Linux Modems by Quectel & Co: Qualcomm/Quectel Modem reverse engineering project launched

Added by laforge over 7 years ago

One week ago at the 33C3 conference, Osmocom core developers Holger and Harald first publicly presented about a new Osmocom project to analyze and reverse engineer a series of Qualcomm-based Cellular modems that run a version of GNU/Linux inside the modem itself. Feel free to see the video recording and/or the slides for more information

At the time the talk was presented, all related information that was gathered by them has been released inside the wiki of a new Osmocom project called Qualcomm Linux Modems by Quectel & Co

We're looking forward to grow this resource further and further - hopefully with your help. Osmocom is a collaborative, community based project, after all.

Cellular Network Infrastructure: Join 3.5G Osmocom Development, With Your Own Free Femtocell

Added by laforge over 7 years ago

Osmocom's support for 2G/GSM is mature and widespread. Since 2016, we're taking
on the next level: 3G/3.5G. The key to running your own 3G network is to obtain
actual 3G cell hardware -- here is an exciting opportunity to get started:

No less than 50 femtocells will be given away for free by sysmocom, one of the
main drivers of the Osmocom project. To receive a free 3G femtocell, tell
sysmocom how you will help the Osmocom project drive 3.5G forward if you had
one, before the end of January 2017. This marks the launch of the 3.5G
Acceleration Project, backed by the Osmocom community. Join us!

Find further details on the 3.5G Acceleration Project and receiving your own 3G
femtocell for free at https://sysmocom.de/downloads/accelerate_3g5_cfp.pdf.

mPCIe WWAN modem USB breakout board: mPCIe WWAN modem USB breakout board released

Added by laforge over 7 years ago

There are plenty of cellular modems on the market in the mPCIe form factor.

Playing with such modems is reasonably easy, you can simply insert them in a mPCIe
slot of a laptop or an embedded device (soekris, pc-engines or the like).

However, many of those modems actually export interesting singals like digital PCM
audio or UART ports on some of the mPCIe pins, both in standard and in non-standard ways.
Those signals are inaccessible in those embedded devices or in your laptop.

So I built a small break-out board which performs the basic function of exposing the mPCIe
USB signals on a USB mini-B socket, providing power supply to the mPCIe modem, offering a
SIM card slot at the bottom, and exposing all additional pins of the mPCIe header on a
standard 2.54mm pitch header for further experimentation.

The design of the board (including schematics and PCB layout design files) is available
as open hardware under CC-BY-SA license terms. For more information see mpcie-breakout.

If you don't want to build your own board, fully assembled and tested boards are available
via sysmocom

multi-voltage USB UART: multi-voltage USB UART board released

Added by laforge over 7 years ago

During the past 16 years I have been playing a lot with a variety of embedded devices.

One of the most important tasks for debugging or analyzing embedded devices is usually
to get access to the serial console on the UART of the device. That UART is often exposed
at whatever logic level the main CPU/SOC/uC is running on. For 5V and 3.3V that is easy,
but for ever more and more unusual voltages I always had to build a custom cable or a custom
level shifter.

In 2016, I finally couldn't resist any longer and built a multi-voltage USB UART adapter.

This board exposes two UARTs at a user-selectable voltage of 1.8, 2.3, 2.5, 2.8, 3.0 or 3.3V.
It can also use whatever other logic voltage between 1.8 and 3.3V, if it can source a reference
of that voltage from the target embedded board.

Rather than just building one for myself, I released the design as open hardware under CC-BY-SA
license terms. Full schematics + PCB layout design files are available.
For more information see mv-uart.

In case you don't want to build it from scratch, ready-made machine assembled boards are also made
available from sysmocom

OpenBSC: 3G Voice Works (2 comments)

Added by neels over 7 years ago

I am glad to announce that we have succeeded in placing a 3G voice call between
two phones using an hNodeB cell and the Osmocom 3G core network. Find attached
a full network trace including IuCS signalling as well as the RTP voice stream.
This, proudly, is the first publicly available pcap of Iuh, IuCS and IuPS, and
it was created using exclusively free software in the core network stack.

The Osmocom 3G stack is being developed at sysmocom, supported by highly
appreciated sponsoring from NLnet and sysmocom customers -- thank you for
making this possible!

Osmocom has had 3G data connectivity working for some months now3, and the
IuPS code has already been merged to OpenBSC's master branch (though it still
requires libosmo-netif, libosmo-sccp and asn1c to be built from the branches
indicated below).

The 3G voice counterpart is taking somewhat longer, not because it's more
difficult per se, but mostly because it needs profound refactoring of our MSC.
So far our MSC was closely tied to the BSC code, and to include IuCS, we need to
separate them.

Are we done with 3G now? Not quite. Things need to be made fully configurable,
proper 3G authentication needs to be integrated, and all work needs to be put in
a stable release. We would also like to have a proper 2G A interface as a
companion to the 3G IuCS interface, which would allow us to completely replace
the OsmoNITB with the new OsmoCSCN.

NOTE from the future: OsmoCSCN has since been renamed to OsmoMSC!

Read this as a humble invitation to join NLnet1 and other sysmocom customers
in funding the open source 3G core network development here at sysmocom2.
The resulting software stack is free for everyone, including you, both in the
sense of free speech as well as the proverbial free beer, and we can still use
all the support we can get to wrap this up. If you would like to see this working
sooner rather than later, do not hesitate to contact us2.

So, we're still working on Osmocom 3G, but if you would like to take a look
ahead, here is how:

We have a 3G authentication implementation ready, but since this is not yet
integrated in our HLR/VLR and MSC libraries, we're still working with hardcoded
2G authentication tokens. So to test, you still need specially provisioned SIM
cards. Firstly, they must be incapable of 3G authentication, so that the phone
decides to fall back to 2G auth. Secondly, they must all be programmed with a
Ki of 000102030405060708090a0b0c0d0e0f. If you need help here, feel free to
contact us2 -- we're in the meantime working on integrating full 3G
authentication with osmo-cscn and osmo-sgsn.

To set up a 3G core network based on free Osmocom software, this is what you
need:

                                 +--------+
                             ,-->| MGCPGW |<--RTP--...
                            /    |        |
                            |    |        |<--MGCP
                            |    +--------+       \
                            /                     |
        +------------+<--RTP     +--------+       `->+----------+
 UE <-->| hNodeB     |           | HNB-GW |          | OsmoCSCN |
 UE <-->|            |<--Iuh---->|        |<--IuCS-->|          |
        |            |     ...-->|        |    ...-->|          |
        |            |           |        |          +----------+
        +------------+<--GTP-U   |        |
                              \  |        |          +------+           +------+
                              |  |        |<--IuPS-->| SGSN |<--GTP-C-->| GGSN |
                              |  +--------+    ...-->|      |   GTP-U-->|      |
                              |                      +------+  /        +------+
                              \_______________________________/

Instead of a traditional NodeB, we use "smaller" hNodeB 3G cell hardware to take
care of the radio interface. This has the advantage that it already has an RNC
integrated, which we would otherwise need to implement separately. The RNC will
talk Iuh, i.e. HNBAP and RANAP4, to OsmoHNBGW running on your box, let's call it
the core network computer (CN).

Besides the HNB-GW, your CN further comprises of OsmoCSCN for voice signalling
as well as the OsmoMGCPGW to direct RTP streams. For data, there are OsmoSGSN
and OpenGGSN.

In short, Iuh is the combined voice (IuCS, Iu circuit switched) and data (IuPS,
Iu packet switched) signalling, which the HNB-GW splits to OsmoCSCN (circuit
switched core network) and OsmoSGSN. When a phone (UE, user equipment) starts
a call, OsmoCSCN takes care of all the signalling, from authentication to RAB
assignment, and instructs the MGCPGW to forward the RTP streams from the hNodeB,
in our case, back to the same hNodeB and to the other UE. In the field, the
MGCPGW would instead forward to a remote media gateway.

To set up your CN, build and install the following projects from
http://git.osmocom.org, using below branches; the current state of which have
also been tagged as '3G_2016_09':

Once the CN stack is built, set up the configuration. Find attached files for an
example of a local test setup. Some details explained:

Tell the osmo-hnbgw which local IP address to use to listen for Iuh connections.
This needs to be on an interface reachable by the hNodeB. The IuCS and IuPS
links towards the osmo-cscn and osmo-sgsn are so far still hardcoded as
127.0.0.1 and 127.0.0.2, respectively, i.e. osmo-cscn and osmo-sgsn should run
on the same machine as the osmo-hnbgw. These will listen on the proper port
without further configuration (still hardcoded).

Also tell the MGCPGW (osmo-bsc_mgcp) which local IP address to bind to, which
has to be reachable both by the hNodeB as well as the osmo-cscn process. The
osmo-cscn.cfg is then told where to reach the MGCPGW.

A notable detail for 3G data is that the GGSN has to be reachable by the hNodeB.
Since the GTP standard defines fixed port numbers which both SGSN and GGSN have
to to use, the SGSN may not bind on the same IP address as the GGSN.

Once you have configured the IP addresses, start up your core network: launch
osmo-cscn, osmo-bsc_mgcp, osmo-sgsn, ggsn and osmo-hnbgw. You should see log
messages indicating established IuCS and IuPS links (HNBGW, CSCN and SGSN).

With your CN up and running, configure the hNodeB to contact osmo-hnbgw. Also
make sure the PLMN ID and LAC are configured correctly, to match the MCC and
MNC in the osmo-cscn.cfg -- otherwise the hNodeB may reject all attach requests.
Finally, do authorize the SIM card's IMSI, e.g. using osmo-cscn's telnet VTY,
and if necessary configure the hNodeB to allow access by this IMSI.

The attached pcap file contains a complete network trace of:

  • HNBAP of hNodeB registering at the HNB-GW;
  • two UEs registering first at the HNB-GW (HNBAP UE Register) and then on IuCS
    and IuPS (MM Location Updating, GMM Attach), coming in via Iuh at the HNB-GW
    and forwarded to OsmoCSCN and OsmoSGSN;
  • the two UEs browsing the websites nlnet.nl5 and the current xkcd webcomic,
    with PDP Context allocation as well as GTP-C and GTP-U6;
  • a voice call where the one UE calls the other (i.e. MO with Service Request to
    MT with Paging), with the RTP stream directed through our MGCP GW using CRCX
    and MDCX instructions;
  • each UE sending an SMS to the other.

The IP addresses used in attached network trace are:

  • 10.9.1.11: hNodeB 3G femto cell;
  • 10.9.1.120: CN computer's interface for Iuh and RTP, as well as the SGSN's
    GTP-C side towards the GGSN;
  • 10.9.1.13: CN computer's interface for GTP-U towards the hNodeB as well as
    GTP-C towards the SGSN7;
  • 127.0.0.1: loopback on the CN computer for IuCS;
  • 127.0.0.2: loopback on the CN computer for IuPS;
  • 10.23.42.*: IP addresses given to UEs within the GTP tunnel;
  • all other IP addresses are remote servers contacted by the UEs.

When looking at network traces, note the various protocols: Iuh, IuCS and IuPS
communicate via SCTP (as opposed to TCP or UDP). You will see the same Iu
messages twice8, e.g. once on IuCS between HNB-GW and CSCN, encapsulated in
RANAP/SUA9, and again on Iuh between HNB-GW and hNodeB, encapsulated in
RANAP/RUA. In contrast, the MGCP configuration and RTP streams for voice use
UDP, and so do GTP-U and GTP-C for the data link.

In conclusion, we still need some work to reach our goal of a fully operational
3G core network. The attached trace of a 3G voice call using exclusively free
Osmocom software proves that we are now very close indeed.

We invite you to test and use our 3G core network stack, and if you can,
consider joining NLnet and sysmocom as sponsor of the ground breaking work in
the Osmocom community.

Edit: see also [[Cellular Infrastructure:Getting Started with 3G]]


1 NLnet foundation, https://nlnet.nl


2 sysmocom systems for mobile communications GmbH, https://sysmocom.de /


3 http://osmocom.org/news/30


4 See also this protocol stack diagram


5 nlnet.nl is browsable by https only, so all you see is TLS encrypted data.
I would have liked to see a DNS query for nlnet.nl, but the UE had already
cached its resolution to 193.200.132.212. There are, however, other DNS queries,
as well as a plain http session for xkcd.com.


6 I have, for privacy reasons, filtered from the pcap some services that the
UEs eagerly contacted but which were not browsed explicitly during the test.


7 It is however possible that few GTP-U packets end up at the SGSN between
activating the PDP context and redirecting GTP-U towards the hNodeB's address,
which can only be known after the IuPS RAB Assignment is complete.


8 Note that the timing differences between the internal loopback and eth0
interfaces may cause their ordering to appear slightly out of sync in the pcap.


9 RANAP/SUA is our non-standard choice of SIGTRAN for IuCS and IuPS, since it
has simpler layering than the standard RANAP/SCCP/M3UA. See also4.


(171-180/254)

Also available in: Atom

Add picture from clipboard (Maximum size: 48.8 MB)