Cellular Network Infrastructure

h1. OSmux

OSmux is a multiplex protocol that proxies voice (RTP-AMR) and signalling traffic in order to reduce the bandwidth consumption, which can be specially important in satellite based GSM back-haul systems. Development of the protocol has been so far mainly accomplished by "sysmocom GmbH":http://sysmocom.de/ and funded by "On-Waves ehf":http://on-waves.com/.

The latest version of the reference specification can be found in the nightly build of osmo-gsm-manuals: "osmux-reference.pdf":http://ftp.osmocom.org/docs/latest/osmux-reference.pdf

Reference implementation can be found in libosmo-netif: "osmuxh.h":http://git.osmocom.org/libosmo-netif/tree/include/osmocom/netif/osmux.h "osmux.c":http://git.osmocom.org/libosmo-netif/tree/src/osmux.c

So far, main use of OSmux has been connecting several project:osmobsc with a [[bsc_nat]] through a satellite link to multiplex and batch calls together. Both use the implementation in libosmo-netif to gain OSmux support. Use of OSmux protocol in those projects can be configured using the VTY configuration interface.

h2. Wireshark

Wireshark gained initial support to dissect Osmux packets in mid July 2016 ("fdbf443d27":https://github.com/wireshark/wireshark/commit/fdbf443d27130628918ac247c682d32bcb314b49, after release 2.3.0rc0).

The packet dissector can be found in "packet-gsm_osmux.c":https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-gsm_osmux.c

Support for Osmux was later improved during May-June 2017. Some of the new features include:

* Support dissecting more than one OSmux frame per UDP packet.

* Display each AMR payload separately instead of showing all of them together.

* Display the RTP M bit in the packet tree.

* Add menu "Telephony->Osmux" to run the "Packet counter" stats tree, both for wireshark-gtk and wireshark-qt.

* Support and display correctly both old Dummy packets (see below) and official dummy packets.

* Add support to identify different OSmux streams, assigning an ID to each of them. This ID is showed in the packet tree for each packet, and can be used as a filter ("osmux.stream_id == 123").

h3. How-To use the OSmux Wireshark dissector

First, load a pcap file or start recording on an interface with an OSmux connection ongoing.

If the Osmux connection is not detected and it only shows up as a regular UDP flow, then select any of the UDP packet flows and right click to open the menu, then select "Decode As...". A window with a list of protocol will show up. Select "GSM Osmux" and press "Apply". At this point, the dissector should be displaying all OSmux information for packets on that UDP flow. See screenshot section below to have an idea how it should look like.

On the info column, for each UDP packet you should see a summary of what does that packet contain from OSmux point of view. It will show the OSmux frame type. If there is more than one OSmux frame per packet, then all will be shown separated by commas.

Packets displayed as "Old Dummy" are specifically crafted packets from early specs/implementation days of Osmux. Support to dissect them is left for backward compatibility and to be able to dissect correctly old pcap traces. They can be identified because its Osmux frame length is 2 bytes containing only the control byte (1st byte) and the CID (2nd byte). In this kind of packets, the control bytes has the value 0x23

You can select any packet and you will see all the bits decoded in the packet tree.

Every OSmux frame will contain an "Osmux Stream ID". That's a value calculated by Wireshark which identifies uniquely every tuple [ip-src, port-src, ip-dst, port-dst, cid], which means for each call between A<->B, you will have 2 streams, one for each flow direction. You can right click on the "Osmux Stream ID" field on the packet tree and use it as a filter ("Apply As Filter"->"Selected") to filter and list packets for a specific stream.

*Limitation*: If you record for long enough or the same tuple (IPs, ports and CID) is reused fast enough to set up a new call, the code in the Osmux dissector won't be able to differentiate between the old call and the new call, and thus both will be assigned the same "Osmux Stream ID", which is bad specifically if you want to calculate the statistics using the stats tree, as then the calculated values will probably be wrong. The advise here is to manually review and make sure this doesn't happen, by knowing context of the trace or following some heuristics like "this stream didn't receive packets for a long time and after that packets start flowing again, probably starting with a few Dummy packets". If it's the case, identify manually the different streams and split them into a different capture to have good results from the OSmux tree.

h3. How-To use the OSmux Wireshark stats tree

The stats tree is a built-in graphical interface from Wireshark to display a few variables and counters over a set of packets.

OSmux uses this interface to display some statistics for each stream ID identified. To open the stats tree GUI for OSMux streams, use the following menu: "Telephony->Osmux->Packet Counter". A new small window will appear which let's you apply a filter to calculate statistics for only a subset of the packets already detected as OSmux by the dissector. For instance, if you want to calculate statistics only for a certain stream with ID 123, you can pass osmux.stream_id == 123", then press "Create Stat".

The stats tree GUI will appear, listing the streams according to the applied filter. See screenshot section below to have an idea how it should look like. Each stream is shown in the following format:

<pre>

STREAM_ID ([IP_SRC:PORT_SRC->IP_DST:PORT_DST]:CID)

</pre>

On the _Count_ column you will find the number of packets which are part of that stream.

For each stream, the following fields are displayed:

* *Count: AMR frames*: In the _Count_ column, number of packets for that stream which are of type _AMR Codec (1)_.

* *Count: Osmux Packets*: In the _Count_ column, number of packets for that stream.

* *Field: FT AMR*: In the _Count_ column, number of packets for that stream which are of type _AMR Codec (1)_ and are not _Old Dummy_ packets.

* *Field: Old Dummy*: In the _Count_ column, number of packets for that stream which are of type _AMR Codec (1)_ and are _Old Dummy_ packets.

* *Field: RTP Marker (M)*: In the _Count_ column, number of packets for that stream which are of type _AMR Codec (1)_ and have the RTP Marker (M) bit set, as explained in the OSmux specification.

* *Jitter Analysis: Relative Transmit Time [ms]*:

** column _Count_, number of packets used to calculate the value (should be the same as the one in _Field: FT AMR_).

** column _Average_, average value of Relative Transit Time for the stream as specified in "RFC3550 section 6.4.1":https://tools.ietf.org/html/rfc3550#section-6.4.1 field "interarrival jitter", calculated in milliseconds.

** column _Min val_, the minimum value registered (Take into account the value is signed but Wireshark shows it as an unsigned value, so you may need to convert manually).

** column _Max val_, the minimum value registered.

* *Jitter Analysis: Relative Transmit Time (abs) [ms]*:

** column _Count_, number of packets used to calculate the value (should be the same as the one in _Field: FT AMR_).

** column _Average_, last value of Relative Transit Time for the stream as specified in "RFC3550 section 6.4.1":https://tools.ietf.org/html/rfc3550#section-6.4.1 field "interarrival jitter", absolute value calculated in milliseconds.

** column _Min val_, the minimum value registered.

** column _Max val_, the minimum value registered.

* *Jitter Analysis: Jitter [ms]*:

** column _Count_ column, number of packets used to calculate the value (should be the same as the one in _Field: FT AMR_).

** column _Average_, last value of Jitter for the stream as specified in "RFC3550 appendix a.8":https://tools.ietf.org/html/rfc3550#appendix-A.8, calculated in milliseconds.

** column _Min val_, the minimum value registered.

** column _Max val_, the minimum value registered.

* *SeqNum Analysis: Consecutive Repeated*: Number of times that a packet has the same OSmux Seq field as the previous one, i.e. number of duplicated packets.

* *SeqNum Analysis: Lost*: Estimation of packets lost based on Osmux seq field values jumping forward increasing more than 1 since last packet received (+ some heursitics to check for wrap).

* *SeqNum Analysis: In Order*: Regular situation in which Osmux seq field value N+1 comes after N (+ some heursitics to check for wrap).

* *SeqNum Analysis: Out of Order*: Estimation of packets received in a later timer with a Osmux seq field value smaller than the higher one we received previosuly (+ some heursitics to check for wrap).

Fields which have no packets matching are not shown and their values can be usually understood to be zero or similar logical value.

h3. Screenshot

Screenshot summarizing current features:

!osmux-stats.png!