Category Archives: Mobile Networks

Making use of Australian Elevation Data in Forsk Atoll

The Australian Government publishes elevation data online that’s freely available for anyone to use. There’s a catch – If you’re using Forsk Atoll, it won’t import without a fair bit of monkeying around with the data…

The data is published on a a system called ELVIS – Elevation – Foundation Spatial Data.

You draw around the area you want to download, enter your email address and you’re linked to a download of the dataset you’ve selected.

So now we download the data from the link, unzip it and we’re provided with a .tiff image with the elevation data in the pixel colour and geocoded with the positional information.

Problem is, this won’t import into Atoll – Unsupported depth.

Forsk Atoll - Unsupported Depth when importing

I found a tool called VTBuilder – A tool for messing with terrain data.

I fired it up, and imported the elevation tiff file we’d downloaded.

Selected “Elevation” waited a few seconds and presto!

We can export from here in the PNG 16 bit grayscale format Atoll takes, but there’s a catch, negative elevation values and blank data will show up as giant spikes which will totally mess with your propagation modeling.

So I found an option to remove elevation data from a set range, but it won’t deal with negative values…

So I found another option in the elevation menu to offset elevation vertically, I added 100 ft (It’s all in ft for some reason) to everything which meant my elevation data that was previously negative was now just under 100.

So if an area was -1ft before it was now 99ft.

Now I was able to use the remove range for anything from 0 100 ft (previously sea level)

Now my map only shows data above sea level

Now I offset the elevation vertically again and remove 100ft so we get back to real values

Now I was able to export the elevation data from the Elevation -> Export to menu

Atoll seems to like PNG 16 bit greyscale so that’s what we’ll feed it.

In Atoll we’ll select File -> Import and open the PNG we just generated.

Data type will be Altitude, Pixel size is 5m (as denoted in email / dataset metadata).

Next question is offset, which took me a while to work out…

The email has the Lat & Long but Atoll deals in WGS co-ordinates,

Luckily the GeoPlanner website allows you to enter the lat & long of the top corner and get the equivalent West and North values for the UTM dataum.

Enter these values as your coordinates and you’re sorted.

I can even able a Map layer and confirm it lines up:

Why GTP for Mobile Networks?

Let’s take a look at GTP, the workhorse of mobile user plane packet data.

This post covers all generations of mobile data (2.5 -> 5G), so I’m using generic terms.

GSM, UMTS, LTE & NR all have one protocol in common – GTP – The GPRS Tunneling Protocol.

So why do every generation of mobile data networks from GSM/GPRS in 2000, to 5G NR Standalone in 2020, rely on this one protocol for transporting user data?

So Why GTP?

GTP – the GPRS Tunnelling Protocol, is what encapsulates and tunnels IP packets from the internet / packet data network, to and from the User.

So why encapsulate the packets? What if the Base Station had access to the internet and routed the traffic to the users?

Let’s say we did that, we’d have to have large pools of IP addresses available at each Base Station and when a user connected they’d be assigned an IP Address and traffic for these users would be routed to the Base Station which would forward it onto the user.

This would work well until a user moves from one Base Station to another, when they’d have to get a new IP Address allocated.

TCP/IP was never designed to be mobile, an IP address only exists in a single location.

Breaking out traffic directly from a base station would have other issues, such as no easy way to enforce QoS or traffic policies, meter usage, etc.

How to fix IP’s lack of mobility? GTP.

GTP addressed the mobility issue by having a single fixed point the IP Address is assigned to (In GSM/GRPS/UMTS this is the Gateway GPRS Support Node, in LTE this is the P-GW and in 5G-SA this is the UPF), which encapsulates IP traffic to/from a mobile user into GTP Packet.

You can think of GTP like GRE or any of the other common encapsulation protocols, wrapping up the IP packets into a GTP packet which we can rerouted to different Base Stations as the users move from being served by one Base Station to another.

This easy redirecting / rerouting of user traffic is why GTP is used for NR (5G), LTE (4G), UMTS (3G) & GPRS (2.5G) architectures.

GTP Packets

When looking at a GTP packet of user data you’d be forgiven for thinking nothing much goes on,

Example GTP packet containing a DNS query

Like in most tunneling / encapsulation protocols we’ve got the original network / protocol stack of IPv4 and UDP, and a payload of a GTP packet.

The packet itself is pretty bare bones, there’s flags, denoting a few basics like version number, the message type (T-PDU), the length of the GTP packet and it’s payload (used for delineating the end of the payload), a sequence number an a Tunnel Endpoint Identifier (TEID).

In the payload, we can see the network / protocol stack and application layer of the contents of the GTP packet.

From a mobility standpoint, the beauty of GTP is that it takes IP packets and puts them into a media stream of sorts, with out of band signalling, this means we can change the parameters of our GTP stream easily without touching the encapsulated IP Packet.

When a UE moves from one base station to another, all that has to happen is the destination the GTP packets are sent to is changed from the old base station to the new base station. This is signalled using GTP-C in GPRS/UMTS, GTPv2-C in LTE and HTTP in 5G-SA.

Traffic to and from the UE would look the same as the screenshot above, the only difference would be the first IPv4 address would be different, but the IPv4 address in the GTP tunnel would be the same.

Roll your own USIMs for Private LTE Networks

I wrote a while ago about USIM basics and talked about what each of the fields stored on a USIM manage, but I thought I’d talk a little about my adventures in getting custom USIMs.

I started working on a private LTE project a while ago; RAN hardware (eNodeBs) were on the way, down to a shortlist of a few EPC platforms, but I still needed USIMs before anyone was connecting to the network.

So why are custom USIMs a requirement? Can’t you just use any old USIM/SIMs?

In UMTS / LTE / NR networks there’s mutual network authentication, again I’ve written about this topic before, but unlike GSM where the network authenticates the UE, in later RAN standards, the UE also authenticates the network. (This mitigates any bad actor from setting up their own base stations and having UEs attach to it and have their traffic intercepted).

For roaming to work between carriers they’ve got to have their HSS / DRA connecting to the DRA or HSS of other carriers, to allow roaming subscribers to access the network, otherwise they too would fall foul of the mutual network authentication and the USIM wouldn’t connect to the network.

The first USIMs I purchased online through a popular online marketplace with a focus on connecting you to Chinese manufacturers.
They listed a package of USIMS, a USB reader/writer that supported all the standard USIM form factors and the software to program it, which I purchased.

The USIMs worked fairly well – They are programmable via a card reader and software that, although poorly translated/documented, worked fairly well.

USIM Programming Interface

K and OP/OPc values could be written to the card but not read, while the other values could be read and written from the software, the software also has the ability to sequentially program the USIMs to make bulk operations easier. The pricing worked out about $8 USD per USIM, which although expensive for the quantity and programmable element is pretty reasonable.

Every now and then the Crypto values for some reason or another wouldn’t get updated, which is exactly as irritating as it sounds.

Pretty quickly into the build I learned the USIMs didn’t include an ISIM service on the card, ISIM being the service that runs on the UCCID responsible for IMS / VoLTE authentication.

Again I went looking and reached out to a few manufacturers of USIMs.

The big vendors, Gemalto, Kona, etc, weren’t interested in providing USIMs in quantities less than 100,000 and their USIMs came from the factory pre-programmed, meaning the values could only be changed through remote SIM provisioning, a form of black magic.

In the end I reached out to an OEM manufacturer from China who provided programmable USIM / ISIMs for less than I was paying on the online marketplace and at any quantity I wanted with custom printing options, allocated ICCIDs, etc.

The non-programmable USIMs worked out less than $0.40 USD each in larger quantities, and programmable USIM/ISIMs for about $5 USD.

The software was almost identical except for the additional tab for ISIM operations.

USIM / ISIM programming
ISIM parameters

Smart Card Readers

In theory this software and these USIMs could be programmed by any smart card reader.

In practice, the fact that the ISO standard smart card is the same size as a credit card, means most smart card readers won’t fit the bill.

I tried a few smart card readers, from the one built into my Thinkpad, to a Bluedrive II from one of the USIM vendors, in the end the MCR3516 Smart Card Reader which reads 4FF USIMs (Standard ISO size smart card, full size SIM, Micro SIM and Nano SIM form factors, which saved on so much mucking about with form factor adapters etc.

4FF Smart Card Reader for programming SIM/USIM/ISIM

Future Projects

I’ve got some very calls “Multi Operator Neutral Host” (MoNEH) USIMs from the guys at Telet Research I’m looking forward to playing with,

eSIMs are on my to-do list too, and the supporting infrastructure, as well as Over the Air updating of USIMs.

LTE / EUTRAN – Idle Detach

In order to keep radio resources free, if a UE doesn’t send or receive data for a predefined threshold, it’ll detach from the network and call back to Idle mode.

If the UE has data to send to the network, the UE will re-attach to the network, whereas if the network has data to send to the UE, it’ll Page the UE in the tracking area it’s currently in, the UE is always listening for it’s identifier (s-TMSI) on the paging channel, and if it hears it’s identifier called, the UE will re-attach.

I’ve also attached a PCAP file of the packet flow between the eNB and the MME.

UEContextReleaseRequest [RadioNetwork-cause=user-inactivity]

The first packet is sent by the eNB to the serving MME to indicate the user wishes to detach from the network.

PCAP of UEContextReleaseRequest from eNB to MME

UEContextReleaseCommand [NAS-cause=normal-release]

The next packet is sent from the MME back to the eNB confirming UE is releasing from the network.

UEContextReleaseCommand

UEContextReleaseComplete

Finally after the UE has released it’s radio resources the eNB sends a UEContextReleaseComplete so the MME knows the UE is now in Idle state and will need to be paged.

UEContextReleaseComplete response

Subscribed-Periodic-RAU-TAU-Timer

https://github.com/open5gs/nextepc/issues/238

Recently we saw Open5Gs’s Update Location Answer response putting the Subscribed-Periodic-RAU-TAU-Timer AVP in the top level and not in the AVP Code 1400 (APN Configuration) Diameter payload from the HSS to the MME.

But what exactly does the Subscribed-Periodic-RAU-TAU-Timer AVP in the Update Location Answer response do?

Folks familiar with EUTRAN might recognise TAU as Tracking Area Update, while RAU is Routing Area Update in GERAN/UTRAN (UMTS).

Periodic tracking area updating is used to periodically notify the availability of the UE to the network. The procedure is controlled in the UE by the periodic tracking area update timer (timer T3412). The value of timer T3412 is sent by the network to the UE in the ATTACH ACCEPT message and can be sent in the TRACKING AREA UPDATE ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE, until a new value is received.

Section 5.3.5 of 24301-9b0 (3GPP TS 24.301 V9.11.0)

So the Periodic Tracking Area Update timer simply defines how often the UE should send a Tracking Area Update when stationary (not moving between cells / tracking area lists).

The case for Header Compression in VoIP/VoLTE

On a PCM (G.711) RTP packet the payload is typically 160 bytes per packet.

But the total size of the frame on the wire is typically ~214 bytes, to carry a 160 byte payload that means 25% of the data being carried is headers.

This is fine for VoIP services operating over fixed lines, but when we’re talking about VoLTE / IMS and the traffic is being transferred over Radio Access Networks with limited bandwidth / resources, it’s important to minimize this as much as possible.

IMS uses the AMR codec, where the RTP payload for each packet is around 90 bytes, meaning up to two thirds of the packet on the wire (Or in this case the air / Uu interface) is headers.

Enter Robust Header Compression which compresses the headers.

Using ROHC the size of the headers are cut down to only 4-5 bytes, this is because the IPv4 headers, UDP headers and RTP headers are typically the same in each packet – with only the RTP Sequence number, RTP timestamp IPv4 & UDP checksum and changing between frames.

Open5Gs- Python HSS Interface

Note: NextEPC the Open Source project rebranded as Open5Gs in 2019 due to a naming issue. The remaining software called NextEPC is a branch of an old version of Open5Gs. This post was written before the rebranding.

I’ve been working for some time on Private LTE networks, the packet core I’m using is NextEPC, it’s well written, flexible and well supported.

I joined the Open5Gs group and I’ve contributed a few bits and pieces to the project, including a Python wrapper for adding / managing subscribers in the built in Home Subscriber Server (HSS).

You can get it from the support/ directory in Open5Gs.

NextEPC Python Library

Basic Python library to interface with MongoDB subscriber DB in NextEPC HSS / PCRF. Requires Python 3+, mongo, pymongo and bson. (All available through PIP)

If you are planning to run this on a different machine other than localhost (the machine hosting the MongoDB service) you will need to enable remote access to MongoDB by binding it’s IP to 0.0.0.0:

This is done by editing /etc/mongodb.conf and changing the bind IP to: bind_ip = 0.0.0.0

Restart MongoDB for changes to take effect.

$ /etc/init.d/mongodb restart

Basic Example:

import NextEPC
NextEPC_1 = NextEPC("10.0.1.118", 27017)

pdn = [{'apn': 'internet', 'pcc_rule': [], 'ambr': {'downlink': 1234, 'uplink': 1234}, 'qos': {'qci': 9, 'arp': {'priority_level': 8, 'pre_emption_vulnerability': 1, 'pre_emption_capability': 1}}, 'type': 2}]
sub_data = {'imsi': '891012222222300', \
             'pdn': pdn, \
             'ambr': {'downlink': 1024000, 'uplink': 1024001}, \
             'subscribed_rau_tau_timer': 12, \
             'network_access_mode': 2, \
             'subscriber_status': 0, \
             'access_restriction_data': 32, \
             'security': {'k': '465B5CE8 B199B49F AA5F0A2E E238A6BC', 'amf': '8000', 'op': None, 'opc': 'E8ED289D EBA952E4 283B54E8 8E6183CA'}, '__v': 0}

print(NextEPC_1.AddSubscriber(sub_data))                        #Add Subscriber using dict of sub_data

print(NextEPC_1.GetSubscriber('891012222222300'))               #Get added Subscriber's details

print(NextEPC_1.DeleteSubscriber('891012222222300'))            #Delete Subscriber

Subscriber_List = NextEPC_1.GetSubscribers()
for subscribers in Subscriber_List:
  print(subscribers['imsi'])
Open5Gs Logo

Open5GS – Splitting Network Elements

Note: NextEPC the Open Source project rebranded as Open5Gs in 2019 due to a naming issue. The remaining software called NextEPC is a branch of an old version of Open5Gs. This post was written before the rebranding.

I’ve been working for some time on Private LTE networks, and wrote my own HSS (See PyHSS – Python Home Subscriber Server).

The packet core I’m using is NextEPC, it’s well written, flexible and well supported.

I joined the Open5Gs group and I’ve contributed a few bits and pieces to the project.

One of which was how to split all the network elements in NextEPC:

NextEPC Splitting Network Elements

In a production network network elements would typically not all be on the same machine, as is the default example that ships with NextEPC.

NextEPC is designed to be standards compliant, so in theory you can connect any core network element (MME, PGW, SGW, PCRF, HSS) from NextEPC or any other vendor to form a functioning network, so long as they are 3GPP compliant.

To demonstrate this we will cover isolating each network element onto it’s on machine and connect each network element to the other. For some interfaces specifying multiple interfaces is supported to allow connection to multiple

In these examples we’ll be connecting NextEPC elements together, but it could just as easily be EPC elements from a different vendor in the place of any NextEPC network element.

ServiceIPIdentity
P-GW10.0.1.121pgw.localdomain
S-GW10.0.1.122 
PCRF10.0.1.123pcrf.localdomain
MME10.0.1.124mme.localdomain
HSS10.0.1.118hss.localdomain

External P-GW

In it’s simplest from the P-GW has 3 interfaces:

  • S5 – Connection to home network S-GW (GTP-C)
  • Gx – Connection to PCRF (Diameter)
  • Sgi – Connection to external network (Generally the Internet via standard TCP/IP)

S5 Interface Configuration

Edit /etc/nextepc/pgw.confand change the address to IP of the server running the P-GW for the listener on GTP-C and GTP-U interfaces.

pgw:
    freeDiameter: pgw.conf
    gtpc: 
      addr:
        - 10.0.1.121
     gtpu: 
      addr:
        - 10.0.1.121

Gx Interface Configuration

Edit /etc/nextepc/freeDiameter/pgwd.conf

Update ListenOn address to IP of the server running the P-GW:

ListenOn = "10.0.1.121";

Update ConnectPeer to connect to the PCRF on it’s IP.

ConnectPeer = "pcrf.localdomain" { ConnectTo = "10.0.1.123"; No_TLS; };

Restart Services

Restart NextEPC PGW Daemon:

$ sudo systemctl restart nextepc-pgwd

External S-GW

In it’s simplest form the S-GW has 2 interfaces:

  • S11 – Connection to MME (GTP-C)
  • S5 – Connection to the home network P-GW (GTP-C)

S5 Interface Configuration

Edit /etc/nextepc/sgw.confand change the address to IP of the server running the S-GW for the listener on GTP-C interface.

sgw:
    freeDiameter: pgw.conf
    gtpc: 
      addr:
        - 10.0.1.122

Restart NextEPC SGW Daemon:

$ sudo systemctl restart nextepc-sgwd

External PCRF

In it’s simplest from the PCRF has 1 network interface:

  • Gx – Connection to P-GW (Diameter)

Gx Interface Configuration

Edit /etc/nextepc/freeDiameter/hss.conf

Update ListenOn address to IP of the server running the HSS on it’s IP:

ListenOn = "10.0.1.123";

Update ConnectPeer to connect to the MME.

ConnectPeer = "pgw.localdomain" { ConnectTo = "10.0.1.121"; No_TLS; };

MongoDB Interface Configuration (NextEPC HSS only)

Edit /etc/nextepc/freeDiameter/hss.conf and change the db_uri: to point at the HSS: db_uri: mongodb://10.0.1.118/nextepc

Restart NextEPC PCRF Daemon:

$ sudo systemctl restart nextepc-pcrfd

External HSS

In it’s simplest form the HSS has 1 network interface:

  • S6a – Connection to MME (Diameter)

S6a Interface Configuration

Edit /etc/nextepc/freeDiameter/hss.conf

Update ListenOn address to IP of the server running the HSS on it’s IP:

ListenOn = "10.0.1.118";

Update ConnectPeer to connect to the MME.

ConnectPeer = "mme.localdomain" { ConnectTo = "10.0.1.124"; No_TLS; };

Restart NextEPC HSS Daemon:

$ sudo systemctl restart nextepc-hssd

MongoDB Interface Configuration (NextEPC specific)

If you are using NextEPC’s HSS you may need to enable MongoDB access from the PCRF. This is done by editing ‘‘/etc/mongodb.conf’’ and changing the bind IP to: bind_ip = 0.0.0.0

Restart MongoDB for changes to take effect.

$ /etc/init.d/mongodb restart

External MME

In it’s simplest form the MME has 3 interfaces:

  • S1AP – Connections from eNodeBs
  • S6a – Connection to HSS (Diameter)
  • S11 – Connection to S-GW (GTP-C)

S11 Interface Configuration

Edit /etc/nextepc/mme.conf, filling the IP address of the S-GW and P-GW servers.

sgw:
    gtpc:
      addr: 10.0.1.122

pgw:
    gtpc:
      addr:
        - 10.0.1.121

S6a Interface Configuration

Edit /etc/nextepc/freeDiameter/mme.conf

Update ListenOn address to IP of the server running the MME:

ListenOn = "10.0.1.124";

Update ConnectPeer to connect to the PCRF on it’s IP.

ConnectPeer = "hss.localdomain" { ConnectTo = "10.0.1.118"; No_TLS; };

Restart Services

Restart NextEPC MME Daemon:

$ sudo systemctl restart nextepc-mmed

Building Android APN / Carrier Config

As anyone who’s setup a private LTE network can generally attest, APNs can be a real headache.

SIM/USIM cards, don’t store any APN details. In this past you may remember having to plug all these settings into your new phone when you upgraded so you could get online again.

Today when you insert a USIM belonging to a commercial operator, you generally don’t need to put APN settings in, this is because Android OS has its own index of APNs. When the USIM is inserted into the baseband module, the handset’s OS looks at the MCC & MNC in the IMSI and gets the APN settings automatically from Android’s database of APN details.

There is an option for the network to send the connectivity details to the UE in a special type of SMS, but we won’t go into that.

All this info is stored on the Android OS in apns-full-conf.xml which for non-rooted (stock) devices is not editable.

Instead the devices get updates through the OS updates which pull the latest copy of this file from Google’s Android Open Source Git repo, you can view the current master file here.

This file can override the user’s APN configuration, which can lead to some really confusing times as your EPC rejects the connection due to an unrecognized APN which is not what you have configured on the UE’s operating system, but it instead uses APN details from it’s database.

The only way around this is to change the apns-full-conf.xml file, either by modifying it per handset or submitting a push request to Android Open Source with your updated settings.

(I’ve only tried the former with rooted devices)

The XML file itself is fairly self explanatory, taking the MCC and MNC and the APN details for your network:

<apn carrier="CarrierXYZ"
      mcc="123"
      mnc="123"
      apn="carrierxyz"
      type="default,supl,mms,ims,cbs"
      mmsc="http://mms.carrierxyz.com"
      mmsproxy="0.0.0.0"
      mmsport="80"
      bearer_bitmask="4|5|6|7|8|12"
/>

Once you’ve added yours to the file, inserting the USIM, rebooting the handset or restarting the carrier app is all that’s required for it to be re-read and auto provision APN settings from the XML file.

Further reading

APN and CarrierConfig | Android Open Source Project

Carrier Configuration | Android Open Source Project

UICC Carrier Privileges | Android Open Source Project

/etc/apns-full-conf.xml – Master Branch

Diameter Routing Agents (DRA)

Diameter is used extensively in 3GPP networks (Especially LTE) to provide the AAA services.

The Diameter protocol is great, and I’ve sung it’s praises before, but one issue operators start to face is that there are a lot of diameter peers, each of which needs a connection to other diameter peers.

https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem#/media/File:Ims_overview.png

This diagram is an “Overview” showing one of each network element – In reality almost all network elements will exist more than once for redundancy and scalability.

What you start to end up with is a rats nest of connections, lines drawn everywhere and lots of manual work and room for human error when it comes to setting up the Diameter Peer relationships.

Let’s say you’ve got 5x MME, 5x PCRF, 2x HSS, 5x S-SCSF and 5x Packet Gateways, each needing Diameter peer relationships setup, it starts to get really messy really quickly.

Enter the Diameter Routing Agent – DRA.

Now each device only needs a connection to the DRA, which in turn has a connection to each Diameter peer. Adding a new MME doesn’t mean you need to reconfigure your HSS, just connect the MME to the DRA and away you go.

I’ll cover using Kamailio to act as a Diameter routing agent in a future post.

PyHSS – Python 3GPP LTE Home Subscriber Server

I recently started working on an issue that I’d seen was to do with the HSS response to the MME on an Update Location Answer.

I took some Wireshark traces of a connection from the MME to the HSS, and compared that to a trace from a different HSS. (Amarisoft EPC/HSS)

The Update Location Answer sent by the Amarisoft HSS to the MME over the S6a (Diameter) interface includes an AVP for “Multiple APN Configuration” which has the the dedicated bearer for IMS, while the HSS in the software I was working on didn’t.

After a bit of bashing trying to modify the S6a responses, I decided I’d just implement my own Home Subscriber Server.

The Diameter interface is pretty straight forward to understand, using a similar structure to RADIUS, and with the exception of the Crypto for the EUTRAN Authentication Vectors, it was all pretty straight forward.

If you’d like to know more you can download PyHSS from my GitLab page, and view my Diameter Primer post and my post on Diameter packet structure.

Forsk Atoll – Setting up Environmental Data

Forsk Atoll is software for wireless network planning, simulation and optimization.

Atoll can do some amazingly powerful things, especially when you start feeding real world data and results back into it, but for today we’ll be touching upon the basics.

As I’m learning it myself I thought I’d write up a basic tutorial on setting up the environment, importing some data, adding some sites and transmitters to your network and then simulating it.

We’ll be using Christmas Island, a small island in the Indian ocean that’s part of Australia, as it’s size makes it easy and the files small.

The Environment (Geographic Data)

The more data we can feed into Atoll the more accurate the predictions that come out of it.

Factors like terrain, obstructions, population density, land usage (residential, agricultural, etc) will all need to be modeled to produce accurate results, so getting your geographic data correct is imperative.

Starting a new Document

We’ll start by creating a new document:

We’ll simulate an LTE network, so we’ll create it using the LTE project template.

Coordinate Reference

Before we can get to that we’re going to have to tell Atoll where we are and what datum we’re working in.

The data sets we’re working were provided by the Government, who use the Australian Geodetic Datum, and Christmas Island is in Zone 48.

We’ll select Document -> Properties

We’ll set the projection first.

Once that’s set we’ll set our display coordinates, this is what we’ll actually work in.

I’m using WGS 84 in the -xx.xxxxxx format, aka Lat & Long in decimal format.

Elevation

Elevation data is hugely important when network planning, your point-to-point links need LOS, and if your modeling / simulation doesn’t know there’s a hill or obstruction between the two sites, it’s not going to work.

There’s plenty of online sources for this data, some of which is paid, but others are provided free by Government agencies.

In this case the Digital Elevation Models for Christmas Island data can be downloaded from Geo-science Australia.

We’ll download the 5m DEM GDA94 UTM zone 48 Christmas Island.

The real reason I picked Christmas Island is that it’s DEM data is 16Mb instead of many Gigabytes and I didn’t want to wait for the download…

After a lot of messing around I found I couldn’t import the multi layered TIF provided by Geo Science Australia, Atoll gave me this error:

Atoll: RasterFile Unsupported data format (Tiled)

I found I could the TIFF formatted DEM files it in a package called VTBuilder, export it as a PNG and then import it into Atoll.

Using VTBuilder to convert DEMs in TIFF to PNG for importing into Atoll

To save some steps I’ve attached a copy of the converted file here.

You can then import the files straight into Atoll,

We’ll need to define what this dataset is, in our cases our Digital Elevation Models (aka Digital Terrain Models) contain Altitude information, so we’ll select Altitude (DTM)

We know from the metadata on the Geo Science Australia site we got the files from the resolution is 5m, so we’ll set pixel size to 5m (Each pixel represents 5 meters).

We’ll need a Geographic Coordinate, this is the Easting and Westing in relation to UTM Zone 48. The values are:

West557999.9999999991
North8849000

All going well you should see the imported topography showing up in Atoll.

I’ve noticed on the version I’m on I had some weirdness when zoomed out, if you try Zooming in to more than 1:10,000 you should see the terrain data. Not sure why this is but I’ve attached a copy of my Atoll config so far so you in case you get stuck with this.

Comms Sites

We’ll download real world sites from the ACMA’s database,

I’ll use the cheat way by just looking it up on their map and exporting the data.

We’ll download the CSV file from the Map.

One thing we’ll need to change in the CSV is that when no Altitude is set for the site ACMA puts “undefined” which Atoll won’t be able to parse. So I’ve just opened it up in N++ and replaced undefined with 0.

I’ve attached a copy here for you to import / skip this step. Mastering messing with CSV is a super useful skill to have anyways, but that’s a topic for another day.

Next we’ll import the sites into Atoll, to define our sites, we’ll jump to the Network Tab and double click on Sites.

Now we’ll import our CSV file

Next we’ll need to define the fields for the import

All going well you’ll now have a populated site list.

Now if we go back to view we should see these points plotted.

Clutter

Forested areas, large bodies of water, urban sprawl, farmland, etc, all have different characteristics and will cause different interference patterns, refraction, shadow fading, etc.

Clutter Data is the classification of land use or land cover which impacts on RF propagation.

There’s several online sources of Clutter data, including the Australian Government Land Use data.

However this dataset doesn’t include Christmas Island. Really shot myself in the foot there, huh?

For examples’ sake we’ll import the terrain data again as clutter.

We’d normally define terrain classes, for example, this area is residential low rise etc, but as we don’t have areas set out we’ll skip that for now.

You can set different layer visibility by enabling and disabling layers in the Geo tab, in this case I’ve disabled my Digital Terrain Model layer and just left the Clutter Heights we just imported.

I got hit with the same Zoom bug here, not sure if it’s still loading in the background or something but the clutter data is only visible when zoomed to 1:10,000 or more, but after doing so you should see the clutter data:

So now we’ve got our environment stuff we can start to add some cell sites and model the propagation & expected signal levels throughout the island in the next post.

Diameter Packet Structure

We talked a little about what the Diameter protocol is, and how it’s used, now let’s look at the packets themselves.

Each Diameter packet has at a the following headers:

Version

This 1 byte field is always (as of 2019) 0x01 (1)

Length

3 bytes containing the total length of the Diameter packet and all it’s contained AVPs.

This allows the receiver to know when the packet has ended, by reading the length and it’s received bytes so far it can know when that packet ends.

Flags

Flags allow particular parameters to be set, defining some possible options for how the packet is to be handled by setting one of the 8 bits in the flags byte, for example Request Set, Proxyable, Error, Potentially Re-transmitted Message,

Command Code

Each Diameter packet has a 3 byte command code, that defines the method of the request,

The IETF have defined the basic command codes in the Diameter Base Protocol RFC, but many vendors have defined their own command codes, and users are free to create and define their own, and even register them for public use.

3GPP have defined a series of their own command codes.

Application ID

To allow vendors to define their own command codes, each command code is also accompanied by the Application ID, for example the command code 257 in the base Diameter protocol translates to Capabilities Exchange Request, used to specify the capabilities of each Diameter peer, but 257 is only a Capabilities Exchange Request if the Application ID is set to 0 (Diameter Base Protocol).

If we start developing our own applications, we would start with getting an Application ID, and then could define our own command codes. So 257 with Application ID 0 is Capabilities Exchange Request, but command code 257 with Application ID 1234 could be a totally different request.

Hop-By-Hop Identifier

The Hop By Hop identifier is a unique identifier that helps stateful Diameter proxies route messages to and fro. A Diameter proxy would record the source address and Hop-by-Hop Identifier of a received packet, replace the Hop by Hop Identifier with a new one it assigns and record that with the original Hop by Hop Identifier, original source and new Hop by Hop Identifier.

End-to-End Identifier

Unlike the Hop-by-Hop identifier the End to End Identifier does not change, and must not be modified, it’s used to detect duplicates of messages along with the Origin-Host AVP.

AVPs

The real power of Diameter comes from AVPs, the base protocol defines how to structure a Diameter packet, but can’t convey any specific data or requests, we put these inside our Attribute Value Pairs.

Let’s take a look at a simple Diameter request, it’s got all the boilerplate headers we talked about, and contains an AVP with the username.

Here we can see we’ve got an AVP with AVP Code 1, containing a username

Let’s break this down a bit more.

AVP Codes are very similar to the Diameter Command Codes/ApplicationIDs we just talked about.

Combined with an AVP Vendor ID they define the information type of the AVP, some examples would be Username, Session-ID, Destination Realm, Authentication-Info, Result Code, etc.

AVP Flags are again like the Diameter Flags, and are made up a series of bits, denoting if a parameter is set or not, at this stage only the first two bits are used, the first is Vendor Specific which defines if the AVP Code is specific to an AVP Vendor ID, and the second is Mandatory which specifies the receiver must be able to interpret this AVP or reject the entire Diameter request.

AVP Length defines the length of the AVP, like the Diameter length field this is used to delineate the end of one AVP.

AVP Vendor ID

If the AVP Vendor Specific flag is set this optional field specifies the vendor ID of the AVP Code used.

AVP Data

The payload containing the actual AVP data, this could be a username, in this example, a session ID, a domain, or any other value the vendor defines.

AVP Padding

AVPs have to fit on a multiple of a 32 bit boundary, so padding bits are added to the end of a packet if required to total the next 32 bit boundary.

Diameter Basics

3GPP selected Diameter protocol to take care of Authentication, Authorization, and Accounting (AAA).

It’s typically used to authenticate users on a network, authorize them to use services they’re allowed to use and account for how much of the services they used.

In a EPC scenario the Authentication function takes the form verifying the subscriber is valid and knows the K & OP/OPc keys for their specific IMSI.

The Authorization function checks to find out which features, APNs, QCI values and services the subscriber is allowed to use.

The Accounting function records session usage of a subscriber, for example how many sessional units of talk time, Mb of data transferred, etc.

Diameter Packets are pretty simple in structure, there’s the packet itself, containing the basic information in the headers you’d expect, and then a series of one or more Attribute Value Pairs or “AVPs”.

These AVPs are exactly as they sound, there’s an attribute name, for example username, and a value, for example, “Nick”.

This could just as easily be for ordering food; we could send a Diameter packet with an imaginary command code for Food Order Request, containing a series of AVPs containing what we want. The AVPs could belike Food: Hawian Pizza, Food: Garlic Bread, Drink: Milkshake, Address: MyHouse.
The Diameter server could then verify we’re allowed to order this food (Authorization) and charge us for the food (Accounting), and send back a Food Order Response containing a series of AVPs such as Delivery Time: 30 minutes, Price: $30.00, etc.

Diameter packets generally take the form of a request – response, for example a Capabilities Exchange Request contains a series of AVPs denoting the features supported by the requester, which is sent to a Diameter peer. The Diameter peer then sends back a Capabilities Exchange Response, containing a series of AVPs denoting the features that it supports.

Diameter is designed to be extensible, allowing vendors to define their own type of AVP and Diameter requests/responses and 3GPP have defined their own types of messages (Diameter Command Codes) and types of data to be transferred (AVP Codes).

LTE/EPC relies on Diameter and the 3GPP/ETSI defined AVP / Diameter Packet requests/responses to form the S6a Interface between an MME and a HSS, the Gx Interface between the PCEF and the PCRF, Cx Interface between the HSS and the CSCF, and many more interfaces used for Authentication in 3GPP networks.

Qos in LTE (4G) – ARP

ARP in LTE is not the Ethernet standard for address resolution, but rather the Allocation and Retention Policy.

A scenario may arise where on a congested cell another bearer is requested to be setup.

The P-GW, S-GW or eNB have to make a decision to either drop an existing bearer, or to refuse the request to setup a new bearer.

The ARP value is used to determine the priority of the bearer to be established compared to others,

For example a call to an emergency services number on a congested cell should drop any other bearers so the call can be made, thus the request for bearer for the VoLTE call would have a higher ARP value than the other bearers and the P-GW, S-GW or eNB would drop an existing bearer with a lower ARP value to accommodate the new bearer with a higher ARP value.

ARP is only used when setting up a new bearer, not to determine how much priority is given to that bearer once it’s established (that’s defined by the QCI).

QoS in LTE (4G) – MBR/AMBR/APN-MBR

MBR stands for Maximum Bit Rate, and it defines the maximum rate traffic can flow between a UE and the network.

It can be defined on several levels:

MBR per Bearer

This is the maximum bit rate per bearer, this rate can be exceeded but if it is exceeded it’s QoS (QCI) values for the traffic peaking higher than the MBR is back to best-effort.

AMBR

Aggregate Maximum Bit Rate – Maximum bit rate of all Service Data Flows / Bearers to and from the network from a single UE.

APN-MBR

The APN-MBR allows the operator to set a maximum bit rate per APN, for example an operator may choose to limit the MBR for subscriber on an APN for a MVNO to give it’s direct customers a higher speed.

(This is only applied to Non-GBR bearers)

QoS in LTE (4G) – QCI

The QCI (Quality Class Indicator) is a value of 0-9 to denote the service type and the maximum delays, packet loss and throughput the service requires.

Different data flows have different service requirements, let’s look at some examples:

A VoLTE call requires low latency and low packet loss, without low latency it’ll be impossible to hold a conversation with long delays, and with high packet loss you won’t be able to hear each other.

On the other hand a HTTP (Web) browsing session will be impervious to high latency or packet loss – the only perceived change would be slightly longer page load times as lost packets are resent and added delay on load of a few hundred ms.

So now we understand the different requirements of data flows, let’s look at the columns in the table above so we can understand what they actually signify:

GBR

Guaranteed Bit Rate bearers means our eNB will reserve resource blocks to carry this data no matter what, it’ll have those resource blocks ready to transport this data.

Even if the data’s not flowing a GBR means the resources are reserved even if nothing is going through them.

This means those resource blocks can’t be shared by other users on the network. The Uu interface in the E-UTRAN is shared between UEs in time and frequency, but with GBR bearers parts of this can be reserved exclusively for use by that traffic.

Non-GBR

With a Non-GBR bearer this means there is no guaranteed bit rate, and it’s just best effort.

Non-GBR traffic is scheduled onto resource blocks when they’re not in use by other non-GBR traffic or by GBR traffic.

Priority

The priory value is used for preemption by the PCRF.

The lower the value the more quickly it’ll be processed and scheduled onto the Uu interface.

Packet Delay Budget

Maximum allowable packet delay as measured from P-GW to UE.

Most of the budget relates to the over-the-air scheduling delays.

The eNB uses the QCI information to make its scheduling decisions and packet prioritisation to ensure that the QoS requirements are met on a per-EPS-bearer basis.

(20ms is typically subtracted from this value to account for the radio propagation delay on the Uu interface)

Packet Error Loss Rate (PELR)

This is packets lost on the Uu interface, that have been sent but not confirmed received.

The PELR is an upper boundary for how high this can go, based on the SDUs (IP Packets) that have been processed by the sender on RLC but not delivered up to the next layers (PDCP) by the receiver.

(Any traffic bursting above the GBR is not counted toward the PELR)

(The list is now larger than 0-9 with 3GPP adding extra QCI values for MCPTT, V2X, etc, the full list is available here in table 6.1.7A)

QoS in LTE (4G) – GBR & Non-GBR Bearers

GBR is a confusing concept at the start when looking at LTE but it’s actually kind of simple when we break it down.

GBR stands for Guaranteed Bit Rate, meaning the UE is guaranteed a set bit rate for the bearer.

The default bearer is always a non-GBR bearer, with best effort data rates.

Let’s look at non-GBR bearers to understand the need for GBR bearers:

As the Uu (Air) interface is shared between many UEs, each is able to transfer data. Let’s take an example of a cell with two UEs in it and not much bandwidth available.

If UE1 and UE2 are both sending the same amount of data it’ll be evenly split between the two.

But if UE1 starts sending a huge amount of data (high bit rate) this will impact on the other UEs in the cells ability to send data over the air as it’s a shared resource.

So if UE2 needs to send a stream of small but important data over the air interface, while UE2 is sending huge amounts of data, we’d have a problem.

To address this we introduce the concept of a Guaranteed Bit Rate. We tell the eNB that the bearer carrying UE2’s small but important data needs a Guaranteed Bit Rate and it reserves blocks on the air interface for UE2’s data.

So now we’ve seen the need for GBR there’s the counter point – the cost.

While UE1 can still continue sending but the eNB will schedule fewer resource blocks to it as it’s reserved some for UE2’s data flow.

If we introduced more and more UEs each requiring GBR bearers, eventually our non-GBR traffic would simply not get through, so GBR bearers have to be used sparingly.

Note: IP data isn’t like frame relay or circuit switched data that’s consistent, bit rate can spike and drop away all the time. GBR guarantees a minimum bit rate, which is generally tuned to the requirements of the data flow. For example a GBR for a Voice over IP call would reserve enough for the media (RTP stream) but no more, so as not to use up resources it doesn’t need.

RF Planning with Forsk Atoll - Importing environmental data

Forsk Atoll – WMS Map Tiles

A hack I found useful to add Google Maps / Google Satelite View / Bing Maps / Bing Arial / Open Street Maps in Forsk Atoll.

Close Atoll,

Go to C -> Program Files -> Atoll

Edit the file named atoll.ini

Paste the following into it:

[OnlineMaps]
Name1 = OpenStreetMap Standard Map
URL1 = http://a.tile.openstreetmap.org/%z/%x/%y.png
Name2 = MapQuest Open Aerial
URL2 = http://otile1.mqcdn.com/tiles/1.0.0/sat/%z/%x/%y.jpg
Name3 = 2Gis
URL3 = http://static.maps.api.2gis.ru/1.0?c...z&size=256,256
Name4 = 2Gis without logo
URL4 = http://tile2.maps.2gis.com/tiles?x=%x&y=%y&z=%z&v=37 
Name5 = Bing Aerial
URL5 = http://ecn.t3.tiles.virtualearth.net.../a%q.jpg?g=392
Name6 = Bing Hybrid
URL6 = http://ecn.t3.tiles.virtualearth.net.../h%q.jpg?g=392
Name7 = Bing Road
URL7 = http://ecn.t3.tiles.virtualearth.net.../r%q.jpg?g=392
Name8 = Yandex Road
URL8 = http://static-maps.yandex.ru/1.x/?ll...=%z&l=map&key=
Name9 = Yandex Aerial
URL9 = http://static-maps.yandex.ru/1.x/?ll...=%z&l=sat&key=
Name10 = Yandex Hybrid
URL10 = http://static-maps.yandex.ru/1.x/?ll...l=sat,skl&key=
Name11 = ArcGIS
URL11 = http://services.arcgisonline.com/Arc...e/%z/%y/%x.png
Name12 = opencyclemap
URL12 = http://tile.opencyclemap.org/cycle/%z/%x/%y.png
Name13 = Google Terrain
URL13 = http://mt.google.com/vt/lyrs=t&hl=en&x=%x&y=%y&z=%z
Name14 = Google Map
URL14 = http://mt.google.com/vt/lyrs=m&hl=en&x=%x&y=%y&z=%z
Name15 = Google Hybrid (Map + Terrain)
URL15 = http://mt.google.com/vt/lyrs=p&hl=en&x=%x&y=%y&z=%z
Name16 = Google Hybrid (Map + Satellite)
URL16 = http://mt.google.com/vt/lyrs=y&hl=en&x=%x&y=%y&z=%z
Name17 = Google Satellite
URL17 = http://mt.google.com/vt/lyrs=m&hl=en&x=%x&y=%y&z=%z
Name18 = Google Scheme
URL18 = http://mt.google.com/vt/lyrs=h&hl=en&x=%x&y=%y&z=%z
Name19 = Google Scheme2 
URL19 = http://mt.google.com/vt/lyrs=r&hl=en&x=%x&y=%y&z=%z

Save and open Atoll,

Open the Geo Tab,

Right click on Online Maps, click “New”

Select the map source (In this example I’m using OSM) & hit Ok.

Enable the Online Map layer by ticking the layer.

Bam, done.

RF Planning with Forsk Atoll - Laying out environmental data

LTE (4G) – TMSI & GUTI

We’ve already touched on how subscribers are authenticated to the network, how the network is authenticated to subscribers and how the key hierarchy works for encryption of user data and control plane data.

If the IMSI was broadcast in the clear over the air, anyone listening would have the unique identifier of the subscriber nearby and be able to track their movements.

We want to limit the use of the IMSI over the air to a minimum.

During the first exchange the terminal is forced to send it’s IMSI, it’s the only way we can go about authenticating to the network, but once the terminal is authenticated and encryption of the radio link has been established, the network allocates a temporary identifier to the terminal, called the Temporary Mobile Subscriber Identity (TMSI) by the serving MME.

The TMSI is given to the terminal once encryption is setup, so only the network and the terminal know the mapping between IMSI and TMSI.

The TMSI is used for all future communication between the Network and the Terminal, hiding the IMSI.

The TMSI can be updated / changed at regular intervals to ensure the IMSI-TMSI mapping cannot be ascertained by a process of elimination.

The TMSI is short – only 4 bytes long – and this only has significance for the serving MME.

For the network to ascertain what MME is serving what TMSI the terminal is also assigned a Globally Unique Temporary (UE) Identity (GUTI), to identify the MME that knows the TMSI to IMSI mapping.

The GUTI is made up of the MNC/MCC combination, then an MME group ID to identify the MME group the serving MME is in, a MME code to identify the MME that allocated the TMSI and finally the TMSI itself.

The decision to use the TMSI or GUTI in a dialog is dependant on the needs of the dialog and what information both sides have. For example in an MME change the GUTI is needed so the original IMSI can be determined by the new MME, while in a normal handover the TMSI is enough.