Monthly Archives: October 2020

Huawei BBU (Baseband Unit) for LTE/UMTS/GSM also known as the BTS 3900 / BBU 3900

My used Huawei BTS3900 LTE RAN Adventure – The Impulse Purchase

Meta: The Australian government made up it’s mind some time ago that Huawei would be blacklisted from providing equipment for 5G networks.
Several other countries have adopted the same policy in regards, and as such, deployed Huawei tech is being replaced, and some of it filters down to online auction sites…

So I kind of purchased an item described as “Huawei BBU3900” with a handful of unknown cards and 2 LRFU units, for just over $100.

My current lab setup is a single commercial picocell and a draw of SDR hardware that works with mixed results, so the idea of having a commercial macro cell to play with seemed like a great idea, I put lowball offer in and the seller accepted.

Now would be a good time to point out I don’t know much about RAN and it’s been a long time since I’ve been working on power systems, so this is shaping up to be a fun project.

I did a Huawei RAN course years ago and remembered the rough ingredients required for LTE:

  1. You needed either RRUs (Remote Radio Units) or RFUs (Radio Frequency Units) to handle the RF side of things.
    RRUs are designed for outdoor use (such as mounting on the tower) and RFUs are designed for indoor use, like mounting in a cabinet.
    I’ve ended up with two LRFUe units, which I can join together for 2x MIMO, operate on Band 28 and can put out a whopping 80W of transmit power, yes I’m going to need some big attenuators…
  2. You need a Baseband Processor card to tell the Radio units what do do.
    The card connects the CPRIs (Typically optic fiber links) between the radio units and the baseband.
    The chassis I purchased came with a stack of WBBP (For WCDMA) cards and a single LBBP card for LTE. The LBBP card has 6 SFP ports for the CPRI interfaces, which is more than enough for my little lab. (You can also daisy-chain CPRIs so I’m not even limited to 6 Radio Units.)
  3. You need a backplane and a place for the cards to live – this is the BBU3900 chassis. It’s got basic switching to allow communication between cards, a chassis to distribute power and cooling.
    (Unlike the Ericson units there is actually a backplane for communications in the Huawei chassis – the Ericsson RBS series has is just power and cooling in the chassis)
  4. Optional – Dedicated transmission card, I’ve ended up with a Universal Transmission Processor (UTRP9) with 2x Gig Ethernet and 2x Fast Ethernet ports for transmission. This will only work for GSM and UMTS though, not LTE, so not much use for me.
  5. You need something to handle main processing (LTE / Universal Main Processing and Transmission Unit (LMPT / UMPT)).
    Unfortunately the unit I’ve ended up with only came with a WMPT (For WCDMA), so back online to find either an LMPT (LTE) or UMPT (Universal (2G/3G/4G))…
  6. You need a Universal Power and Environment Module (UPEU) to power up the chassis and handle external IO for things like temperature alarms, door sensors and fire detectors. This chassis has two for redundancy / extra IO & extra power capacity.

So in order to get this running I still need quite a few components:

  • Attenuators – I’ll be able to turn the power down, sure, but not to the levels required to be legal.
  • Antennas – These are FDD units, so I’ll need two antennas for each RFU, on Band 28
  • Feeder Cables – To connect the antennas
  • SMF cables and SFPs – I’ve got a pile in my toolbox, but I’ll need to work out what’s supported by these units
  • A big -48vDC rectifier (I got the BBU3900 unit powered up with an existing supply I had, but I’m going to need something bigger for the power hungry RFUs)
  • DC Distribution Unit – Something to split the DC between the RFUs and the BBU, and protect against overload / short
  • USB-Network adapter – For OAM access to the unit – Found these cheaply online and got one on the way
  • The LTE Main Processing & Transmission (LMPT) card – Ordered a second hand one from another seller

I powered up the BTA3900 and sniffed the traffic, and can see it trying to reach an RNC.

Unfortunately with no open source RNC options I won’t be posting much on the topic of UMTS or getting the UMTS/WCDMA side of things on the air anytime soon…

So that’s the start of the adventure.

I don’t know if I’ll get this all working, but I’m learning a lot in the process, and that’s all that really matters…

Note: I think this is the course I did from Huawei on the BBU3900…

5GC for EPC Folks – Control Plane Signalling

As the standardisation for 5G-SA has been completed and the first roll outs are happening, I thought I’d cover the basic architecture of the 5G Core Network, for people with a background in EPC/SAE networks for 4G/LTE, covering the key differences, what’s the same and what’s new.

The AMFAuthentication & Mobility Function, serves much the same role as the MME in LTE/EPC/SAE networks.

Like the MME, the AMF only handles Control Plane traffic, and serves as the gatekeeper to the services on the network, connecting the RAN to the core, authenticating subscribers and starting data / PDN connections for the UEs.

While the MME connects to eNodeBs for RAN connectivity, the AMF connects to gNodeBs for RAN.

The Authentication Functions

In EPC the HSS had two functions; it was a database of all subscribers’ profile information and also the authentication centre for generating authentication vectors.

5GC splits this back into two network elements (Akin to the AuC and HLR in 2G/3G).

The UDM (Unified Data Management) provides the AMF with the subscriber profile information (allowed / barred services / networks, etc),

The AUSF (Authentication Server Function) provides the AMF with the authentication vectors for authenticating subscribers.

Like in UMTS/LTE USIMs are used to authenticate subscribers when connecting to the network, again using AKA (Authentication and Key Agreement) for mutual subscriber & network authentication.

Other authentication methods may be implemented, R16 defines 3 suporrted methods, 5G-AKA, EAP-AKA’, and EAP-TLS.

This opens the door for the 5GC to be used for non-mobile usage. There has been early talk of using the 5G architecture for fixed line connectivity as well as mobile, hence supporting a variety of authentication methods beyond classic AKA & USIMs. (For more info about Non-3GPP Access interworking look into the N3IWF)

The Mobility Functions

When a user connects to the network the AMF selects a SMF (Session Management Function) akin to a P-GW-C in EPC CUPS architecture and requests the SMF setup a connection for the UE.

This is similar to the S11 interface in EPC, however there is no S-GW used in 5GC, so would be more like if S11 were instead sent to the P-GW-C.

The SMF selects a UPF (Akin to the P-GW-C selecting a P-GW-U in EPC), which will handle this user’s traffic, as the UPF bridges external data networks (DNs) to the gNodeB serving the UE.

More info on how the UPF functions compared to it’s EPC counterparts can be found in this post.

Moving between cells / gNodeBs is handled in much the same way as done previously, with the path the UPF sends traffic to (N3 interface) updated to point to the IP of the new gNodeB.

Mobility between EPC & 5GC is covered in this post.

Connection Overview

When a UE attempts to connect to the network their signalling traffic (Using the N1 reference point between the UE and the AMF), is sent to the AMF.

an authentication challenge is issued as in previous generations.

Upon successful authentication the AMF signals the SMF to setup a session for the UE. The SMF selects a UPF to handle the user plane forwarding to the gNodeB serving the UE.

Key Differences

  • Functions handled by the MME in EPC now handled by AMF in 5GC
  • Functions of HSS now in two Network Functions – The UDM (Unified Data Management) and AUSF (Authentication Server Function)
  • Setting up data connections “flatter” (more info on the User Plane differences can be found here)
  • Non 3GPP access (Potentially used for fixed-line / non mobile networks)

See also: 5GC for EPC Folks – User Plane Traffic

5GC for EPC Folks – User Plane Traffic

As the standardisation for 5G-SA has been completed and the first roll outs are happening, I thought I’d cover the basic architecture of the 5G Core Network, for people with a background in EPC/SAE networks for 4G/LTE, covering the key differences, what’s the same and what’s new.

This posts focuses on the User Plane side of things, there’s a similar post I’ve written here on the Control Plane side of things.

UPF – User Plane Forwarding

The UPF bridges the external networks (DNs) to the gNodeB serving the UE by encapsulating the traffic into GTP, which has been used in every network since GSM.

Like the P-GW the UPF takes traffic destined to/from external networks and passes it to/from subscribers.

In 5GC these external networks are now referred to as “DN” – Data Networks, instead of by the SGi reference point.

In EPC the Serving-Gateway’s intermediate function of routing traffic to the correct eNB is removed and instead this is all handled by the UPF, along with buffering packets for a subscriber in idle mode.

The idea behind this, is that by removing the S-GW removes extra hops / latency in the network, and allows users to be connected to the best UPF for their needs, typically one located close to the user.

However, there are often scenarios where an intermediate function is required – for example wanting to anchor a session to keep an IP Address allocated to one UPF associated with a user, while they move around the network. In this scenario a UPF can act as an “Session Anchor” (Akin to a P-GW), and pass through “Intermediate UPFs” (Like S-GWs).

Unlike the EPCs architecture, there is no limit to how many I-UPFs can be chained together between the Session Anchoring UPF and the gNB, and this chaining of UPFs allows for some funky routing options.

The UPF is dumb by design. The primary purpose is just to encapsulate traffic destined from external networks to subscribers into GTP-U packets and forward them onto the gNodeB serving that subscriber, and the same in reverse. Do one thing and do it well.

SMF – Session Management Function

So with dumb UPFs we need something smarter to tell them what to do.

Control of the UPFs is handled by the SMF – Session Management Function, which signals using PFCP down to the UPFs to tell them what to do in terms of setting up connections.

While GTP-U is used for handling user traffic, control plane traffic no longer uses GTPv2-C. Instead 5GC uses PFCP – Packet Forwarding Control Protocol. To get everyone warmed up to Control & User Plane separation 3GPP introduced as seen in CUPS into the EPC architecture in Release 14.

This means the interface between the SMF and UPF (the N4 interface) is more or less the same as the interface between a P-GW-C and a P-GW-U seen in CUPS.

When a subscriber connects to the network and has been authenticated, the AMF (For more info on the AMF see the sister post to this topic covering Control Plane traffic) requests the SMF to setup a connection for the subscriber.

Interworking with EPC

For deployments with an EPC and 5GC interworking between the two is of course required.

This is achieved first through the implementation of CUPS (Control & User Plane Separation) on the EPC, specifically splitting the P-GW into a P-GW-C for handing the Control Plane signalling (GTPv2c) and a P-GW-U for the User Plane traffic encapsulated into GTP.

The P-GW-C and P-GW-U communications using PFCP are essentially the same as the N4 interface (between the SMF and the UPF) so the P-GW-U is able to act as a UPF.

This means handovers between the two RATs / Cores is seamless as when moving from an LTE RAT and EPC to a 5G RAT and 5G Core, the same UPF/P-GW-U is used, and only the Control Plane signalling around it changes.

When moving from LTE to 5G RAT, the P-GW-C is replaced by the SMF,
When moving from 5G RAT to LTE, the SMF is replaced by the P-GW-C.
In both scenarios user plane traffic takes the same exit point to external Data Networks (SGi interface in EPC / N6 interface in 5GC).

Interfaces / Reference Points

N3 Interface

N3 interface connects the gNodeB user plane to the UPF, to transport GTP-U packets.

This is a User Plane interface, and only transports user plane traffic.

This is akin to the S1-UP interface in EPC.

N4 Interface

N4 interface connects the Session Management Function (SMF) control plane to the UPF, to setup, modify and delete UPF sessions.

It is a control plane interface, and does not transport User Plane traffic.

This interface relies on PFCP – Packet Forwarding Control Protocol.

This is akin to the SxB interface in EPC with CUPS.

N6 Interface

N6 interface connects the UPF to External Data Networks (DNs), taking packets destined for Subscribers and encapsulating them into GTP-U packets.

This is a User Plane interface, and only transports user plane traffic.

This is akin to the SGi interface in EPC.

N9 Interface

When Session Anchoring is used, and Intermediate-UPFs are used, the connection between these UPFs uses the N9 interface.

This is only used in certain scenarios – the preference is generally to avoid unnecessary hops, so Intermediate-UPF usage is to be avoided where possible.

As this is a User Plane interface, it only transports user plane traffic.

When used this would be akin to the S5 interface in EPC.

N11 Interface

SMFs need to be told when to setup / tear down connections, this information comes from the AMF via the N11 interface.

As this is a Control Plane interface, it only transports control plane traffic.

This is similar to the S11 interface between the MME and the S-GW in EPC, however it would be more like the S11 if the S11 terminated on the P-GW.

Meta: 5G on this Blog

I’ve tried to steer well clear of the fever-pitched hype over 5G recently (I mean, this year I wrote 22 posts about building GSM networks with Osmocom to avoid talking about 5G), but the time has come to start sharing more about 5G.

But before we do…

My promise to you:
No talk of Augmented Reality, Holographic Video calls, 5G connected cities, sales buzzwords.

Just info for nerds about real (actually standardized) 5G.

As always I’ll reference specs where possible.

Let’s get building!

Link to all 5G tagged posts.

SIP Hold – With RFC6337

I had a discussion with a friend the other day about if hold is signified with a=sendonly or a=recvonly, which led me to revisiting the RFC to confirm, so here’s an overview of how “Call Hold” works in SIP.

By the Book

According to RFC 6337 a user can hold calls by sending a new SDP offer in an established session (Re-INVITE on active call), with an SDP payload of a=sendonly for each media stream the user want’s to hold.

The SIP Switch / PBX / UAS replies with an updated SDP where each media stream’s SDP contains a=recvonly.

So it’s both, depending on which leg you’re looking at.

In Common Practice

When a UAC puts a call in hold, it does so by sending a SIP re-INVITE, updating the SDP to include the attribute line “sendonly”

See the bottom line of the SDP is a=sendonly ? That’s denoting the call is to be put on hold,

If the call hold was sucesful the UAS sends back a 200 Ok, with the SDP attribute set to recvonly

The a=recvonly denotes the call has been held.

To retrieve the call another SIP re-invite is sent by the UAC, this time setting the media attribute back to sendrecv

If sucesful a 200 OK is sent by the UAS with the a=sendrecv also set.

Packet Gateway (P-GW) used in LTE EPC Networks

LTE EPC: Packet Gateway (P-GW) Basic Function

The Packet Gateway connects users of an LTE network to external networks like the Internet, by encapsulating IP packets inside GTP and forwarding them on to reach our subscriber wherever in the network they are.

To understand the P-GW, first it’s a good idea to first get a grasp on what GTP is and why we use GTP to transport subscriber’s data through the LTE Evolved Packet Core.

So we use GTP to encapsulate user’s traffic, making it easy to carry it transparently from outside networks (Like the Internet) to the eNodeB and onto our UE / mobile phones, and more importantly redirect where the user’s traffic it’s going while keeping the same IP address.

But we need a network element to take plain old IP from external networks / Internet, and encapsulate the traffic into the GTP packets we’ll send to the subscriber.

This network element will have to do the same in reverse and decapsulate traffic coming from the subscriber to put it back onto the external networks / Internet.

That’s the role of the Packet Gateway (P-GW). The P-GW sits on the border between the outside network (An interface / reference point known as the SGi Interface) and the rest of the packet core (Serving-Gateway then onto eNodeB & UE) via the S5 Interface.

Let’s look at how the P-GW handles an incoming packet:

  1. An IP packet comes in from the Internet destined for IP 1.2.3.4 and routed to the P-GW.
  2. The P-GW looks up in it’s internal database what Tunnel Endpoint Identifier (TEID) IP Address 1.2.3.4 is associated with.
  3. The P-GW encapsulates the IP packet (Layer 3 & up) into a GTP packet, adding the Tunnel Endpoint Identifier (TEID) to the GTP header.
  4. The P-GW looks up in it’s internal database which Serving Gateway is handling traffic for that TEID.
  5. The P-GW then sends this GTP packet containing our IP packet to the Serving Gateway.

In order to start relaying traffic to/from the S5 & SGi interfaces, the P-GW needs a set of procedures for setting up these sessions, (IP Address allocation and TEID allocation) known as bearers. This is managed using GTPv2 (aka GTPv2-Control Plane / GTPv2-C).

GTPv2-C has a set of procedures for creating these sessions, the key ones used by the P-GW are:

  • Create Session Request / Response – Sets up GTP sessions / bearers
  • Delete Session Request / Response – Removes GTP session / bearers

The Create Session Request is sent by the S-GW to the P-GW and contains the APN of the network to be setup, the IP Address to be assigned (if static) and information regarding the maximum throughput the user will be permitted to achieve.

If the P-GW was able to setup the connection as requested, a Create Session Response is sent back to the P-GW, with the IP Address for the UE to use, and the TEID (Tunnel Endpoint Identifier).

At this stage the tunnel is up and ready to go, traffic to the P-GW to the IP of the UE will be encapsulated in GTP-U packets with the TEID for this bearer, and forwarded on to the S-GW serving the user.

LTE EPC: Serving Gateway (S-GW) Basic Function

As our subscribers are mobile, moving between base stations / cells, the destination of the incoming GTP-U packets needs to be updated every time the subscriber moves from one cell to another.

If you’re not familiar with GTP take a read of this primer.

As we covered in the last post, the Packet Gateway (P-GW) handles decapsulating and encapsulating this traffic into GTP from external networks, and vise-versa. The Packet Gateway sends the traffic onto a Serving Gateway, that forwards the GTP-U traffic onto the eNodeB serving the user.

So why not just route the traffic from the Packet Gateway directly to the eNodeB?

As our users are inherently mobile, the signalling load to keep updating the destination of the incoming GTP-U traffic to the correct eNB, would put an immense load on the P-GW. So an intermediary gateway – the Serving Gateway (S-GW), is introduced.

The S-GW handles the mobility between cells, and takes the load of the P-GW. The P-GW just hands the traffic to a S-GW and let’s the S-GW handle the mobility.

It’s worth keeping in mind that most LTE connections are not “always on”. Subscribers (UEs) go into “Idle Mode”, in which the data connection and the radio connection is essentially paused, and able to be bought back at a moments notice (this allows us to get better battery life on the UE and better frequency utilisation).

When a user enters Idle Mode, an incoming packet needs to be buffered until the Subscriber/UE can get paged and come back online. Again this function is handled by the S-GW; buffering packets until the UE comes available then forwarding them on.

FreeSWITCH WebRTC with sipML5

Most people think of SIP when it comes to FreeSWITCH, Asterisk and Kamailio, but all three support WebRTC.

FreeSWITCH makes WebRTC fairly easy to use and treats it much the same way as any SIP endpoint, in terms of registration and diaplan.

Setting up the SIP Profile

On the SIP profile we’ll need to activate WebRTC you’ll need to ensure a few lines of config are present:

    <!-- for sip over secure websocket support -->
    <!-- You need wss.pem in $${certs_dir} for wss or one will be created for you -->
    <param name="wss-binding" value=":7443"/>

Next you’ll need to restart FreeSWITCH and a self-signed certificate should get loaded,

Once you’ve restarted FreeSWITCH will fail to detect any WebSocket certificate and generate a self signed certificate for you. This means that you can verify FreeSWITCH is listening as expected using Curl:

curl https://yourhostname:7443 -vvv

You should see an error regarding the connection failing due to an invalid certificate, if so, great! Let’s put in a valid certificate.

If not double check the firewall on your server allow traffic to port TCP 7443,

Loading your TLS Certificate

WebRTC & websocket are recent standards – this means a valid TLS certificate is mandatory. So to get this to work you’ll need a valid SSL certificate.

Let’sEncrypt should work fine, if you’ve got your own CA that’s in the trusted CA list on your machine that’ll do, or I’m using a cert I generated with Mkcert.

When we restarted FreeSWITCH after adding the wss-binding config a certificate was automatically generated in the $${certs_dir} of FreeSWITCH,

You can verify where the certs_dir is by echoing out the variable in FreeSWITCH:

fs_cli -x 'eval $${certs_dir}'

Unless you’ve changed it you’ll probably find your certs in /etc/freeswitch/tls/

The certificate and private key are stored in a single file, with the Certificate and the Private Key appended to the end,

In my case the certificate is called “webrtc.pem” and the private key file is “webrtc-key.pem”,

I’ll need to start by replacing the contents of the current certificate/ key file wss.pem with the certificate I’ve got webrtc.pem, and then appending the private key – webrtc-key.pem to the end of wss.pem,

cat /home/nick/webrtc.pem > /etc/freeswitch/tls/wss.pem
cat /home/nick/webrtc-key.pem >> /etc/freeswitch/tls/wss.pem

Next up I’ll restart FreeSWITCH, and run Curl again to verify this time the certificate is valid:

curl https://yourhostname:7443 -vvv

All going well no certificate error will be reported and we can setup our WebRTC client.

Configuring sipML5

Dubango Telecom’s sipML5 is a BSD licenced HTML5 SIP client,

I’ll use the demo version on their website to connect to my FreeSWITCH WebRTC server, which you can run in your browser from here,

We’ll start by clicking the “Export Mode” button to set our wss:// URL;

Change the WebSocket Server URL to the URL of your FreeSWITCH instance (you must use a domain, not an IP Address)

If you’re running behind a NAT adding ICE servers is probably a good idea, although this will slow down connection times, you can use Google’s public STUN server by pasting in the below value:

[{ url: 'stun:stun.l.google.com:19302'}]

Finally we’ll save those settings and return back to the main tab,

You’ll need to register with a username and password that’s valid on the FreeSWITCH box, in my case I’m using 1000 with the password 1000 (exists by default),

Replace webrtc with the domain name of your FreeSWITCH instance,

Finally you should be able to click Login and see Connected above,

Then we can make calls to endpoints on FreeSWITCH using the dial box;

The Debug console in your browser will provide all the info you need to debug any issues, and you can trace WebSocket traffic using Sofia like any other SIP traffic.

Hopefully this was useful to you – I’ll cover more of WebRTC on Asterisk and also Kamailio in later posts!

Docker Cheatsheet

I kept forgetting the basic Docker commands, so I made a cheat sheet for myeslf and thought I’d share:

List running Containers:
docker ps
List all Containers (Including stopped)
docker ps -a
Start a Container
docker run sdfjkdskj/sdfdsafa
List Images
docker image list
Build an Image
docker build -t myapp:v1 .
Connect to Shell of running Container
docker exec -it intelligent_chebyshev /bin/bash