Category Archives: RF

Funky Connectors for Cellular

I came across these the other day, they’re DC & Fibre in the same connector body.

Rather than breaking out to a fibre and an Anderson connector, you’ve got both in one connector, with provision for an extra fibre pair too, then on the other end this splits into the RRU power connector, used by Ericsson and Nokia, and a LC connector for the fibre into the RRU.

I pulled it all apart this to see how it fitted together, it looks like they’re factory pre-term cables, rather than being spliced to length, which I guess makes sense. Cool design!

Shiny things inside Cellular Diplexers

I recently ended up with a few Commscope RF combiners from a cell site, they’re not on frequencies that are of any use to us, so, let’s see what’s inside.

The units on the bench are Commscope Diplexer units, these ones allow you to put a signal between 694-862Mhz, and another signal between 880-960Mhz, on the same RF feeder up the tower.

It’s a nifty trick from the days where radio units lived at the bottom of the tower, but now with Remote Radio Units, and Active Antenna Units, it’s becoming increasingly uncommon to have radio units in the site hut, and more common to just run DC & fibre up the tower and power a radio unit right next to the antenna – This is especially important for higher frequencies where of course the feeder loss is greater.

Diplexer unit before it is maimed…

Anywho, that’s about all I know of them, after the liberal application of chemicals to remove the stickers and several burns from a heat gun, we started to get the unit open, to show the zillion adjustment bolts, and finely machined parts.

Thanks to Oliver for offering up the bench space when I rocked to up to their house with some stuff to pull apart.

Huawei BBU 3900 Architecture

Huawei BTS3900 eNB Configuration

Last year I purchased a cheap second hand Huawei macro base station – there’s lots of these on the market at the moment due to the fact they’re being replaced in many countries.

I’m using it in my lab environment, and as such the config I’ve got is very “bare bones” and basic. Keep in mind if you’re looking to deploy a Macro eNodeB in production, you may need more than just a blog post to get everything tuned and functioning properly…

In this post we’ll cover setting up a Huawei BTS3900 eNodeB from scratch, using the MML interface, without relying on the U2020 management tool.

Obviously the details I setup (IP Addressing, PLMN and RF parameters) are going to be different to what you’re configuring, so keep that in mind, where I’ve got my MME Addresses, site IDs, TACs, IP Addresses, RFUs, etc, you’ll need to substitute your own values.

A word on Cabinets

Typically these eNodeBs are shipped in cabinets, that contain the power supplies, alarm / environmental monitoring, power distribution, etc.

Early on in the setup process we’ll be setting the cabinet types we’ve got, and then later on we’ll tell the system what we have installed in which slots.

This is fine if you have a cabinet and know the type, but in my case at least I don’t have a cabinet manufactured by Huawei, just a rack with some kit mounted in it.

This is OK, but it leads to a few gotchas I need to add a cabinet (even though it doesn’t physically exist) and when I setup my RRUs I need to define what cabinet, slot and subrack it’s in, even though it isn’t in any. Keep this in mind as we go along and define the position of the equipment, that if you’re not using a real-world cabinet, the values mean nothing, but need to be kept consistent.

The Basics

Before we get started, familiarise yourself with the Huawei MML we’ll use for configuring the unit, and log into the Web UI and bring up an MML shell.

To begin we’ll need to setup the basics, by disabling DHCP and setting an local IP Address for the unit.


Obviously your IP address details will be different.
Next we’ll add an eNodeB function, the LMPT / UMPT can have multiple functions and multiple eNodeBs hosted on the same hardware, but in our case we’re just going to configure one:

 ADD ENODEBFUNCTION: eNodeBFunctionName="LTE", ApplicationRef=1, eNodeBId=9527;
 SET NE: NENAME="HUAWEI", LOCATION="NewSite", DID="NewSite12345", SITENAME="NewSite1", USERLABEL="NewInitSite";

Again, your eNodeB ID, location, site name, etc, are all going to be different, as will your location.

Next we’ll set the system to maintenance mode (MNTMODE), so we can make changes on the fly (this takes the eNB off the air, but we’re already off the air), you’ll need to adjust the start and end times to reflect the current time for the start time, and end time to be after you’re done setting all this up.

 SET MNTMODE: MNTMode=INSTALL, ST=2013&09&20&15&00&00, ET=2013&09&25&15&00&00, MMSetRemark="NewSite Install";

Next we’ll set the operator details, this is the PLMN of the eNodeB, and create a new tracking area.

 ADD CNOPERATOR: CnOperatorId=0, CnOperatorName="NickTest", CnOperatorType=CNOPERATOR_PRIMARY, Mcc="001", Mnc="01";
ADD CNOPERATORTA: TrackingAreaId=0, CnOperatorId=0, Tac=1;

Next we’ll be setting and populating the cabinets I mentioned earlier. I’ll be telling the unit it’s inside a APM30 (Cabinet 0), and in Cabinet Number 0, Subrack 0, is a BBU3900.

 //To modify the cabinet type, run the following command:
//Add a BBU3900 subrack, run the following command:
//To configure boards and RF datas, run the following commands:

And inside the BBU3900 there’s some cards of course, and each card has as slot, as per the drawing below.

In my environment I’ve got a LMPT in slot 7, and a LBBP in Slot 3. There’s a fan and a UPEU too, so:
We’ll add a board in Slot No. 7, of type LMPT,
We’ll add a board in Slot No. 3, of type LBBP working on FDD,
We’ll add a fan board in Slot No. 16, and a UPEU in Slot No. 18.


Huawei publish design guides for which cards should be in which slots, the general rule is that your LMPT / UMPT card goes in Slot 7, with your BBP cards (UBBP or LBBP) in slots 3, then 2, then 1, then 0. Fans and UPEUs can only go in the slots designed to fit them, so that makes it a bit easier.

Next we’ll need to setup our RRUs, for this we’ll need to setup an RRU chain, which is the Huawei term for the CPRI links and add an RRU into it:



With our RRU chains defined, we’ll need to setup our transport network to get the traffic back to the S-GW / MME:

ADD S1: S1Id=0, CnOperatorId=0, EpGroupCfgFlag=CP_UP_CFG, CpEpGroupId=0, UpEpGroupId=0;

We’ll need clocking and time as well, we’ll use NTP and GPS:



Next we’ll need to define a sector, sector equipment & cell, then link it to a sector equipment group:





Alright, now we can activate it:

//Modify the reference signal power.
MOD PDSCHCFG: LocalCellId=1, ReferenceSignalPwr=-81;

//Add an operator for the cell.
ADD CELLOP: LocalCellId=0, TrackingAreaId=0;

//Activate the cell.
ACT CELL: LocalCellId=1;

And lastly we can define some neighboring cells:

//Configure neighboring cells. 
ADD EUTRANINTERNFREQ: LocalCellId=1, DlEarfcn=3100, UlEarfcnCfgInd=NOT_CFG, CellReselPriorityCfgInd=NOT_CFG, SpeedDependSPCfgInd=NOT_CFG, MeasBandWidth=MBW100, PmaxCfgInd=NOT_CFG, QqualMinCfgInd=NOT_CFG;
ADD EUTRANEXTERNALCELL: Mcc="460", Mnc="02", eNodeBId=236, CellId=0, DlEarfcn=3100, UlEarfcnCfgInd=NOT_CFG, PhyCellId=236, Tac=33;
ADD EUTRANINTERFREQNCELL: LocalCellId=1, Mcc="460", Mnc="02", eNodeBId=236, CellId=0;

Inside a 32×32 MIMO Antenna

For the past few months I’ve had a Band 78 NR active antenna unit sitting next to my desk.

It’s a very cool bit of kit that doesn’t get enough love, but I thought I’d pop open the radome and take a peek inside.

Individual antenna elements

What I found very interesting is that it’s not all antennas in there!

… 29, 30, 31, 32. Yup. Checks out.

There are the expected number of antennas (I mean if I opened it up and found 31 antennas I’d have been surprised) but they don’t take up the whole volume of the unit, only about half,

AAU with Radome reinstalled

Well, after that strip show, back to sitting in my office until I need to test something 5G SA again…

Ericsson & Nokia RRU Power Connectors – Wiring and Tricks

Something that’s kind of great is that the current generation of Ericsson RRUs and Nokia RRUs, use the same power connector – The Amphenol “Amphe-OBTS” series connector.

Construction and wiring of these connectors is the same for both, and with one little trick, we can use the connector for both Ericsson and Nokia RRUs (Airscale and later).

This pin that stops the connector from being “universal” but is easily removed.

The connectors are not quite universal, in order to use it in both you need to knock off a small pin on the connector, I’d suggest doing this before you assemble it, put the connector on it’s back, facing upwards, and hit this with a screwdriver / chisel and it’ll pop off with very little effort.

Assembling the connectors starts by working out the diameter of the grommet you need to fit your cable, the connector comes with the grommet for 9-14mm, but in the bag you’ll usually get grommets for 6-9mm cable and 14-18mm cable.

Grab the correct one for your cable diameter, and pop into the black fingered cage (‘gland adapter’) shown in the bottom right of the below photo.

Grommets and gland adapter

Next we line all the parts up along the cable and screw it all together:

The end-cap is actually very useful for stopping the female end of the connector from spinning when you’re assembling the cable, so don’t throw it away!

The finished product
Huawei BBU 3900 Architecture

Huawei Baseband Cheat Sheet

Baseband Units (UBBP)

CardMax LTE Cells
UBBPd33×20 MHz 2T2R
UBBPd43×20 MHz 4T4R
UBBPd56×20 MHz 2T2R OR 3×20 MHz 4T4R
UBBPd66×20 MHz 4T4R
UBBPe13×20 MHz 2T2R
UBBPe23×20 MHz 4T4R
UBBPe36×20 MHz 2T2R OR 3×20 MHz 4T4R
UBBPe46×20 MHz 4T4R OR 3×20 MHz 8T8R
Max Cells in LTE FDD

Main Processing and Transmission (LMPT/UMPT)

In some instances two boards can be used together to double the max cells or max throughput values.

CardMax CellsMax Throughput
(at MAC Layer)
Max UEs
(In RRC Connected)
LMPT18 Cells (4T4R)Uplink 300Mbps
Downlink 450Mbps
UMPTa36 Cells (4T4R)Aggregate 1.5Gbps10800
UMPTb136 Cells (4T4R)Aggregate 1.5Gbps10800
UMPTb236 Cells (4T4R)Aggregate 1.5Gbps10800
UMPTb336 Cells (4T4R)Aggregate 2Gbps10800
UMPTb936 Cells (4T4R)Aggregate 2Gbps10800
UMPTe72 Cells (4T4R)Aggregate 10Gbps14400

Forsk Atoll – Importing Antennas

I recently had a bunch of antennas profiles in .msi format, which is the Planet format for storing antenna radiation patterns, but I’m working in Forsk Atoll, so I needed to convert them,

To load these into Atoll, you need to create a .txt file with each of the MSI files in each of the directories, I could do this by hand, but instead I put together a simple Python script you point at the folder full of your MSI files, and it creates the index .txt file containing a list of files, with the directory name.txt, just replace path with the path to your folder full of MSI files,

#Atoll Index Generator
import os
path = "C:\Users\Nick\Desktop\Antennas\ODV-065R15E-G"
antenna_folder = path.split('\\')[-1]
f = open(path + '\\' + 'index_' + str(antenna_folder) + '.txt', 'w+')
files = os.listdir(path)
for individual_file in files:
    if individual_file[-4:] == ".msi":
        f.write(individual_file + "\n")


Which you can then import into Atoll, easy!

Converting Elevation Data (DEM) for Forsk Atoll

After headaches importing elevation (DEM) data into Forsk Atoll, I found a better mechanism for converting them,

I’d been having issues with as soon as the elevation passed 255 meters, resetting to 0 in the PNG as it didn’t understand values beyond this.

I was able to open the elevation data in GlobalMapper (You can use the trial if required), then selecting Export -> Export Raster/Image Format,

Then select Erdas Image File

Set file type to Elevation 16-bit integer samples,

Now you should be able to import it straight into Atoll as your elevation data.

Huawei BTS3900 – MML Basics

How do humans talk to base stations? For Huawei at least the answer to this is through MML – Man-Machine-Language,

It’s command-response based, which is a throwback to my Nortel days (DMS100 anyone?),

So we’re not configuring everything through a series of parameters broken up into sections with config, it’s more statements to the BTS along the lines of “I want you to show me this”, or “Please add that” or “Remove this bit”,

The instruction starts of with an operation word, telling the BTS what we want to do, there’s a lot of them, but some common examples are; DSP (Display), LST (List), SET (Set), MOD (Modify) and ADD (Add).

After the operation word we’ve got the command word, to tell the BTS on what part we want to execute this command,

A nice simple example would be to list the software version that’s running on the BTS. For this we’d run


And press F9 to execute, which will return a list of software on the BTS and show it in the terminal.

Note at the end the :; – the : (colon) denotes the end of a command word, and after it comes the paratmeters for the command, and then the command ends with the ; (semi-colon). We’ll need to put this after every command.

Let’s look at one more example, and then we’ll roll up our sleves and get started.

Note: I’m trying out GIFs to share screen recordings instead of screenshots. Please let me know if you’re having issues with them.

So once you’ve logged into WebLMT, selecting MML is where we’ll do all our config, let’s log in and list the running applications.

So far we’ve only got some fairly basic data, listing and displaying values, so let’s try something a bit more complex, taking a backup of the config, in encrypted mode, with the backup label “blogexamplebackup”,


If you’ve made it this far there’s a good chance you’re thinking there’s no way you can remember all these commands and parameters – But I’ve got some good news, we don’t really need to remember anything, there’s a form for this!

And if we want to upload the backup file to an FTP server, we can do this as well, in the navigation tree we find Upload Backup Configuration, fill in the fields and click the Exec button to execute the command, or press F9.

These forms, combined with a healthy dose of the search tab, allow us to view and configure our BTS.

I’ve still got a lot to learn about getting end-to-end configuration in place, but this seems like a good place to start,

DIY LTE RAN Adventure – POWER! (systems)

All the gear I’ve got so far for my DIY RAN Project requires -48vDC to power it up.

Back to online auction websites and preso I’ve ended up with an Eltek MPSU3000, from the mid 2000s.

The fellow I bought it from was even nice enough to throw a binder full of printed documentation, which included a full circuit layout diagram, however this was obviously in the days of old school printers, and each of the colours were offset, providing a literal headache when reading and a bit of a reminder of what printed documents were like to deal with…

I get a headache just looking at the colours in this…

So after a bit of tinkering, wiring and reconnecting the temperature probe, I managed to fire the unit up,

While it complained about the absence of batteries (As well as rectifying AC to DC it manages and maintains banks of batteries to provide a backup power supply), it worked, and provided a very stable, clean -54v DC.

I’ve got a very old (1948) Ring Generator / Ring Machine, (same as this one) so I wired it into the rectifier and it came to life, drawing 3 amps in the process.

The Huawei gear uses proprietary power connectors, I’ve managed to start it using crocodile clips and good luck to get it powered up, but I’ve got to work out a more permanent solution before I can rack all the gear and have it setup properly.

The Eltek rectifier has a number of relay contacts in the unit that can be programed to trigger in different conditions, ie mains power lost, battery fault, over temperature, etc.

These relay contacts are then wired into some sort of alarm input, to share alarm state with external monitoring equipment. (Modern rectifiers just have Ethernet and connect over TCP/IP, but this one just has a serial port and an AT command set for connecting it to a dialup modem.)

The BTS3900 has the Universal Power and Environment Unit (UPEU), which allows me to connect external alarm inputs, for things like this, water sensors, smoke detectors and intruder alarms, so hopefully I’ll get that in place when I’m further down the line.

But to program these requires the software, which I couldn’t find anywhere online. As a last ditch attempt I reached out to the manufacturer, Eltek, and asked if they’d be so kind as to send me a copy. I wasn’t expecting much, but the next day, they sent me back all the manuals and the software the next day, for a 15 year old, long surpassed product. Very impressed!

So with the aid of VMware, Windows XP, USB-Serial adapters and jumper wires, I managed to connect to the Rectifier Controller with the software and had a poke around.

While the unit can do some very clever things with battery management, for my lab setup I can’t see myself going to the effort of adding batteries. So for now the Rectifier’s just converting AC mains into -48vDC, but I may string some batteries in the future.

For anyone who’s ended up here looking for info on these units, or the first generation Eltek Flatpacks, I’ve attached some documentation below. The software isn’t readily available online, so I won’t post it here, but you can get it from Eltek directly.

So power system check! Now onto configuring the unit and getting the radios online…

Indoor LTE/GSM/UMTS mobile antennas, primarily used for in building coverage.

DIY RAN Adventures – Antennas

Note: This is one part of a series of posts where I cover my adventures attempting to bring on air a commercial Macro cell site for my lab, with scrounged components.

So the Huawei BTS3900 unit I’ve ended up with, is only one part of the overall picture for building a working LTE RAN. Power systems, feeders, connectors, CPRI, antennas, baseband processing and transmission are all hurdles I’ve still got to overcome. So today, let’s talk about antennas!

For the output/TX side (downlink) of the RF Unit, I’ve ordered some 25w 50 ohm dummy loads (I’ll still need to work out how to turn down the RF power to less than 25w on the RF units). Even with the dummy load, a tiny bit of RF power is leaked, which should be enough to provide the downlink signal for my UEs – Time will tell if this works…

This option is fine for the power being pushed out of the RF unit, into the dummy load, where we have a lot of power available (too much power), but what about our very weak uplink signals from UEs?

For this I’d need some decent antennas to pickup the signals from the UEs, so I ended up with some Kathrein (Now owned by Ericsson) indoor multi-band omni antennas I found on an online auction site for $10 each. (I bought 4 so I can play with MIMO.)

Unfortunately, the RFUs I have are Band 28 (roughly 700Mhz-750Mhz uplink and 758Mhz to 798Mhz downlink), and reading the datasheet it seems this doesn’t cover the bands I need;

But beggars can’t be choosers, so I ran a calibration on the NanoVNA and swept the antenna from 700Mhz-750Mhz (Band 28 uplink frequencies) to see how it will perform when I get the rest of the solution together;

At the upper end of Band 28 Uplink (748Mhz) I’m getting a fairly respectable VSWR of 1.6 (Return Loss of -12.4dB), so I should be able to get away with these for what I’m doing,

I’v seen these white domes inside shopping centers and office buildings, so I was keen to crack open the case and see what magic inside, what I found was kind of underwhelming, just an aluminum plate with an aluminum reflector cone…

My ideas of putting the parts into the lathe and trying to lower it’s operating frequency by taking material off, were dashed when I realised taking material off would raise the operating frequency, not lower it…

NanoVNA showing LCD contents

Using a NanoVNA to analyse SDR Base Station Antennas

A few months back I posted my secret shame regarding some rubber-ducky antennas I had been using thinking they were on the GSM bands, that turned out to have the wrong connector and had never made contact in all the years I’d used them.

I recently got my hands on a NanoVNAv2 and thought I’d take a look at the antennas I’d purchased for my GSM SDR experimentation,

These antennas claimed to operate on 900/1800/2100MHz and this time had the correct connector (SMA not RP-SMA)…

I ordered two of these antennas for the princely sum of $3 and hooked them onto the NanoVNA to analyse the antennas – the poor man’s Anritsu SiteMaster!

The buttons on the NanoVNA are a bit tough to use but there’s great software out there for driving the NanoVNA from your computer (NanoVNA-saver), which is what used in the end,

I was operating the GSM network using ARFCN 871 with the SDR which translates to 1782 MHz for Uplink and 1877 MHz for Downlink, so I plugged in the values into the VNA to take a look at how it performs in those ranges,

Performance is actually pretty on point,

On the Uplink frequency we’ve got a VSWR of 1.15 which is about as good as it gets,

And in the downlink we’ve got a VSWR of 1.221, still pretty good.

Performance on the remainder of the 1800MHz band is pretty decent, with clear drops in VSWR where the Uplink and Downlink channels lie.

I measured the full band for Uplink on the 1800Mhz band (1710Mhz – 1785Mhz):

Analysis of Uplink Bands

Which shows not all channels are created equal, if you were looking for real performance on these antennas and not just playing, you’d probably want to put your uplink channel on one of the frequencies shown by the marker,

And the full band for Downlink on the 1800Mhz band (1805Mhz – 1890Mhz):

Again, varied performance, but the peaks and troughs line up on the uplink and downlink, so a lower ARFCN in the 1800Mhz band would put you about on the red marker for both,

Comparing the output of each of the antennas I’ve got

In reality I could be using a bent coat hanger for an antenna, the signals shouldn’t be able to leave the room, but it’s a good excuse to use the toys!

GSM with Osmocom: Handovers

With just one cell/BTS, your mobile phone isn’t all that mobile.

So GSM has the concept of handovers – Once BTS (cell) can handover a call to another cell (BTS), thus allowing us to move between BTSs and keep talking on a call.

Note: I’ll use the term BTS here, because we’ve talked a lot about BTSs throughout this series. Technically a BTS can be made up of one or more cells, but to keep the language consistent with the rest of the posts I’ll use BTS, even though were talking about the cell of a BTS.

If we’re on a call, in an area served by BTS1, and we’re moving towards BTS2, at some point the signal strength from BTS2 will surpass the signal strength from BTS1, and the phone will be handed over from BTS1 to BTS2.

Handovers typically only occur when a channel is in use (ie on a phone call) if a phone isn’t in use, there’s no need to seamlessly handover as a brief loss of connectivity isn’t going to be noticed by the users.


The question as to when to handover a call to a neighbouring cell, comes down to the signal strength levels the phone is experiencing.

The phone measures the signal strength of up to 6 nearby (neighbouring) BTSs, and reports what signal strength it’s receiving to the BTS that’s currently serving it.

The BTS then sends this info to the BSC, in the RXLEV fields of a RSL Measurement Report packet.

RXLEV fields of a RSL Measurement Report packet.

With this information the BSC makes the determination of when to handover the call to a neighbouring BTS.

There’s a lot of parameters that the BSC takes into account when making the decision to handover to a neighbouring BTS, but for the purposes of this explanation, we’ll simplify this and just imagine it’s based on which BTS has the strongest signal strength as seen by the phone.

Everybody needs good Neighbors

Our phone can only monitor the signal strength of so many neighboring cells at once (Up to 6). So in order to know which frequency (known as ARFCNs) to take signal strength measurements on, our phone needs to know the frequencies it should expect to see neighbours, so it can measure these frequencies.

The System Information Block 2 is broadcast by the BTS on the BCCH and SACCH channels, and contains the ARFCNs (Frequencies) of the BTSs that neighbour that cell.

With this info our Phone only needs to monitor the frequencies (ARFCNs) of the cells nearby it’s been told about in the SIB2 to check the received power levels on those frequences.

The Handover

This is vastly simplified…

So our phone is armed with the list of neighbouring cell frequencies (ARFCNs) and it’s taking signal strength measurements and sending them to the BTS, and onto the BSC. The BSC knows the strength of the signals around our phone on a call.

With this information the BSC makes the decision that the serving cell (BTS) the phone is currently connected to is no longer the best candidate, as another BTS would provide a higher signal strength and begins a handover to a neighbouring BTS with a better signal to the phone.

Our BSC starts by giving the new BTS a heads up it’s going to hand a call of to it, by setting up the channel to use on the new BTS, through a Channel Activation message.

Next a handover command is sent to the phone via the BTS it was initially connected to (RSL Handover Command), telling the phone to begin handover to the new BTS and the channel it should move to on the new BTS it setup earier.

Screenshot of a packet capture showing a GSM Handover

The phone moves to the new BTS, and is acknowledged by the phone. The channels the phone was using on the old BTS are released and the handover is complete.

Simplified Diagram of the Process

There is a lot more to handovers than just this, which we’ll cover in a future post.

Osmocom Logo

GSM with Osmocom: Channel Types

When setting up the timeslots on the TRX for each BTS on your BSC, you’ll notice you have to set a channel type.

So what do these acronyms mean, and how do they affect the performance of the network?

GSM channels break down into one of to categories, control channels – used for signalling, and traffic channels, used for carrying information to/from a user.

A network with only control channels wouldn’t allow a call to be made, as there would be no traffic channels to carry the audio of the call,

Conversely a network with only traffic channels would have plenty of capacity for calls, but without a control channel would have no way of setting them up.

Traffic Channels

Traffic channels break down into a further two categories, voice channels for carrying call audio, and data channels for carrying GPRS data.

Traffic Channels for Voice

There’s a few variants of voice channel based on the codec used for encoding the voice data, the more compressed / small the audio signal is, the more you can cram in per channel, at the sacrifice of voice quality.

Common options are Traffic Channel – Full Rate (TCH/F), & Traffic Channel – Half Rate (TCH/F) channels.

Traffic Channels for Data

When GPRS was introduced it needed to be transported on a traffic channel, but unlike a voice channel, the resources weren’t going to be used 100% of the time (like in a voice call) and could be shared on an as-needed basis.

Data channels are also also broken down into full rate and half rate channels, like Traffic Channel – Full Rate (TCH/F), & Traffic Channel – Half Rate (TCH/F) channels.

Control Channels

Control channels carry the out of band signalling between the Phone and the BTS.

Broadcast Channels

Broadcast Channels are by their very nature – Broadcasted, this means every phone on the BTS gets these messages.

There are 3 broadcast channels, the FCCH for frequency corrections, SCH for synchronisation and BCCH for a common channel that transmits information to all phones, containing info on the network such as the PLMN, neighbouring cells, etc.

Common Channels

The PCH – Paging Channel, is used to page phones in idle mode. All phones will listen on the paging channel, and if they hear their identifier will establish a connection back to the network.

RACH the Random Access Control Channel is used for when the phone wants to establish a connection with the network, by picking a random timeslot to transmit it’s data on the RACH.

The ACGC is the Access Grant Channel, containing information about dedicated channels to be assigned to phones.

Dedicated Control Channels

Like dedicated traffic channels, dedicated channels are only in use by one phone at a time.

The SDCCH is the standalone dedicated control channel, over which location updates, SMS, authentication & call setup / teardown signalling is transferred.

The SACCH – slow Associated Control Channel is used for timing advance (when users are further from the BTS timing advances are needed to ensure propogation time is taken into account), power control information, signaling data and radio measurements.

Finally the FACCH – Fast Associated Control is used for transferring larger messages such as for handover information,

GSM with Osmocom: GPRS & Packet Data

So far we’ve focused on building a plain “2G” (voice and SMS only) network, which was all consumers expected twenty years ago.

As the number of users accessing the internet through DSL, Dial Up & ISDN grew, the idea of getting this data “on the go” became more appealing. TCP/IP was becoming the dominant standard for networking, the first 802.11 WiFi spec had recently been published and demand for mobile data was growing.

There’s a catch however – TCP/IP was never designed to be mobile.

An IP address exists in a single location.

(Disclaimer: While you can “move” a subnet by advertising itself out in a different location via BGP peering relationships with other operators, it’s cumbersome, can only be done per /24 or larger, and most importantly it’s painfully slow. IPv6 has MIPv6 which attempts to fix some of these points, but that’s outside of this scope.)

GPRS addressed the mobility issue by having a single fixed point the IP Address is assigned to (the Gateway GPRS Support Node), which encapsulates IP traffic to/from a mobile user into GTP Packet (GPRS Tunnelling Protocol), like GRE or any of the other common routing encapsulation protocols, allowing the traffic to be rerouted to different destinations as the users move from being served by one BTS to another BTS.

I’ve written about GTP here if you’d like to learn more.

So now we’ve got a method of encapsulating our data we’ve got to work out how to get that data out over the air.

BTS Time Slots

Way back when we were first setting up our BSC and adding our BTS(s) you will have configured timeslots for each BTS configured on your BSC.

Chances are if you’ve been following along with this tutorial, that you configured the first time slot (timeslot 0) as a CCCH+SDCCH4, meaning Common Control Channel and 4 standalone dedicated control channels, and all the subsequent timeslots (timeslot 1 – 7) as Traffic Channels (full rate) – TCH/F.

This works well if we’re only carrying voice, but to carry data we need timeslots to put the data traffic on.

For this we’ll re assign a timeslot we were using on our BSC as a voice traffic channel (TCH/F) as a PDCH – a Packet Data Channel.

This means that on the BSC your timeslot config will look something like this:

   timeslot 6
    phys_chan_config PDCH
    hopping enabled 0
   timeslot 7
    phys_chan_config PDCH
    hopping enabled 0

In the above example I’ve assigned two timeslots for Packet Data Channels,

The more timeslots you allocate for data, the more bandwidth available, but the fewer voice resources available.

(Most GSM networks today have few data timeslots as more recent RATs like 3G/4G are taking the data traffic, and GSM is used primarily for voice and low bandwidth M2M communications)


GPRS comes in two flavors, GPRS and EDGE.

GPRS (General Packet Radio Services) was the first of the two, standardised in R97, and allowed users to reach a downlink speeds of up to 171Kbps using GMSK on the air interface to encode the data.

Users quickly expected more speed, so EDGE (Enhanced Data rates for Global Evolution) was standardised, from a core perspective it was the same, but from a BTS / Air interface perspective it relied on 8PSK instead of GMSK allowed users to reach a blistering 384Kbps on the downlink.

These speeds are the theoretical maximums.

As the difference between GPRS and EDGE is encoding on the air interface, from a core perspective it’s treated the same way, however as our BTS gets all it’s brains from the BSC, we’ll need to specify if the BTS should use EDGE or GPRS it in the BSC’s BTS config.

BSC Config

On the BSC for each BTS we want to enable for packet data, we’ll need to define the parameters.

There’s two other values we’ll introduce when setting this up,

The first is NSEI – the Network Service Entity Identifier, which is the identifier of the BTS’s Packet Control Unit, like the cell identity.

The second value we’ll touch on is the BVCI – the BSSGP Virtual Connections Identifier, which is used for addressing between the BTS PCU and the SGSN.

bts 0
  gprs mode egprs
  gprs 11bit_rach_support_for_egprs 0
  gprs routing area 0
  gprs network-control-order nc0
  gprs cell bvci 2
  gprs cell timer blocking-timer 3
  gprs cell timer blocking-retries 3
  gprs cell timer unblocking-retries 3
  gprs cell timer reset-timer 3
  gprs cell timer reset-retries 3
  gprs cell timer suspend-timer 10
  gprs cell timer suspend-retries 3
  gprs cell timer resume-timer 10
  gprs cell timer resume-retries 3
  gprs cell timer capability-update-timer 10
  gprs cell timer capability-update-retries 3
  gprs nsei 101
  gprs ns timer tns-block 3
  gprs ns timer tns-block-retries 3
  gprs ns timer tns-reset 3
  gprs ns timer tns-reset-retries 3
  gprs ns timer tns-test 30
  gprs ns timer tns-alive 3
  gprs ns timer tns-alive-retries 10
  gprs nsvc 0 nsvci 101
  gprs nsvc 0 local udp port 23001
  gprs nsvc 0 remote udp port 23000
  gprs nsvc 0 remote ip

The OsmoBSC docs cover each of these values, they’re essentially defaults.

There are quite a few changes required on the BSC for each BTS we’re setting this up for. Instead of giving you info on what fields to change, here’s the diffs.

In the next post we’ll cover the GGSN and the SGSN and then getting a device on “the net”.

Dumb Lesson in RF Connectors

When the YateBTS project launched 6 or 7 years ago I went out and purchased what was to be my first “real” SDR – The BladeRF x40.

At the time I wanted to play with GSM stuff, and so I grabbed two rubber duck antenna off an Alarm GSM Dialer I had in a junk box, thinking they’d do a better job than the stock “everything-band” antenna that came with the SDR hardware.

The offending antennas

These two became my “probably roughly aligned with the common commercial RAN bands” antennas,

I’ve used these antennas on pretty much all my RAN related projects on the BladeRF, HackRF and the LimeSDR,

I had some issues a recently I attributed to “probably rubbish antennas” so decided to get a pair of paddle antenna tuned for the frequencies I was working with.

While working out what to get I had a look and noted the connectors on all my SDR hardware is SMA-Female connector. Easy, so I need an SMA-Male connector on the antennas, purchase made.

Cut forward to today when the antennas arrive at my door, they’re exactly as described, however I notice some resistance when connecting them, the male pin is stiff to go into the LimeSDR, whereas there’s no resistance at all from my “trusty” rubber duck antennas.

That’s when I realised.

The two antennas I’ve been using for about 7 years at this point, have the wrong connectors (SMA and RP-SMA) and have not made contact on the signal centre pin that entire time…

They’re RP-SMA male and I need SMA male.

Wasn’t just reverse polarity – it was no polarity.

I’m a walking encyclopedia of connectors, acronyms and layer 1 stuff, but apparently this I missed.

I’m an idiot – a lucky one who didn’t burn out his SDR hardware.

An idiot with greatly improved RSSI though…

NBN Skymuster Satellite Technical Overview

I’m a bit of a radio nerd & I’ve worked Satellites before, so the Skymuster / LTSS program had me curious. So here’s some nitty-gritty details on NBNCo’s Skymuster Satellite service.

The Payload

NBNco called the LTSS (Long Term Satellite service) but before launch they re-branded as “Skymuster”.

NBNco provided an Interim service called ISS (Interim Satellite Service). before the launch. IPSTAR satellite (Formerly ABG) and Optus services delivered this. Both of these had limited bandwidth and has since been largely replaced by the Skymuster / LTSS.

NBNCo contracted Space Systems / Loral, a US based satellite manufacturer to design and build the payloads. It’s based on the SSL 1300 platform.

When deployed, the payload itself measures 26 metres long, 9 metres tall and 12 metres wide, and weighs in at 6400Kg. Before deployment, in the satellite’s compressed form it fits within a 5-meter launch-vehicle fairing.

Communication to earth is via Ka-band frequencies which allows for greater density of spot beams and frequency reuse. However, capacity improvement through higher frequencies does come with some tradeoffs. Ka-band frequencies, are more susceptible to weather related conditions compared to Ku-band frequencies. Directional accuracy becomes way more important when aligning the customer dishes in Ka band also.

SSL provided image of SL-1300
DirectionMin FreqMax Freq
Earth to Satellite27Ghz31Ghz
Satellite to Earth17.7Ghz22Ghz

These emissions are within the range of the higher end software defined radio receivers. I’m curious to see what’s being transmitted, but that’s a topic for another day.

The downlink uses RH and LH circular polarisation.

The Journey

SSL assembled the satelite in California.

SSL staff packed it into a crate and loaded into the belly of an Antinov An-124 which is flown to the launch site.

There are two Skymuster Satellites, NBN-Co 1A & 1B. 1B provides infill / capacity layer for 1A but both are identical. If the 1A satellite was lost during launch / deployment, 1B could be sent up in it’s place. This is still a real risk when launching anything.

NBN-Co 1A was the first launched, riding on a Ariane-5ECA from Guiana Space Centre in French Guiana, South America. 1A launched on 30.09.2015 and 1B launched 05.10.2016 in the same configuration.

After launch to a transit orbit, the satellites had to navigate up into a geostationary orbit at ~36,000Km. This was done using it’s 4 × SPT-100 plasma thrusters, which are exactly as cool as they sound. The final navigation process took up 40% of the fuel in the satellite. Fuel is the determining factor for the expected ~15 year lifetime of the two satellites.

SPT-100 – Source: NASA

Once in final position SSL performed 2 months worth of tests referred to as “In Orbit Testing”. SSL then handed over operational Telemetry, Tracking and Command (TT&C) to Optus Satellite (Singtel). Optus are tasked with keeping it in it’s current position.

Customer Hardware

Ericsson manage the installation, and subcontract to Hills and Skybridge for the actual work.

Out Door Unit (ODU)

There are currently 3 Satellite Antenna options that are available for
installation, 80cm, 1.2m & 1.8m.

NBNco’s Test Setup

Narrower Ka-Band signals drops off more rapidly than Ku-Band signals. This means that aligning the Ka-Band antenna within the degrees of usable Azimuth within the Line of Sight maximises the antenna gain.

Required accuracy for each of the antennas:

  • 80 cm: 1.4 degrees,
  • 120 cm: 1.0 degrees
  • 180 cm: 0.7 degrees

The below graph shows being off by 1 degree from the required accuracy, leads to -30dB drop. This translates to a power ratio of 1000, or 1/1000 of the power if correctly aligned.

The alignment process is done by the installer pointing the dish in the correct azimuth / elevation. This is based on compass / inclinometer readings, or smart phone apps. Once a rough alignment has been set, a tone-generator on the TIRA is used to align the dish.

This process requires a 16 digit installation key.

The key containing the frequency used in the installation, beam Assignment & TRIA Polarisation (The 6w version has automatic (Polarisation).

That’s entered into the installation setup page at:

TIRA’s has a built in Tone Generator which is used to “Point and Peak” the dish from the roof. The tones are:

  • Heartbeat 3KHz
  • Pointing Tones 2.5 – 3.1KHz
  • Peaking Tones 2.5, 2.95, 3.1 and 3.3KHz

ViaSat have videos on how the alignment process is performed.

IDU (Modem) / NTD

The modem itself is manufactured by ViaSat. I can’t find any specifics it seems to be in the RM511x line of Satellite modems.

There were some issues with a firmware update on these in 2018, that saw firmware getting rolled back.

The modems / IDU / NTDs for the ISS are not compatible with the LTSS.

There’s some nice teardown photos of a similar ViaSat modem here.

TRIA (Transmit/Receive Integrated Assembly )

The TRIA is the equivalent of a feed horn, an all in one Tx/Rx assembly. They are available in 3w and 6w variants, based on the estimated signal levels of the installation location. That’s determined by factors like high rain areas or if the subscriber is on the edge of a beam.

3W Version

The 6W version has an extra F-Connector for the required DC power injection. The 6w version also has a two F-Connector gang-plate / wallplate when installed for the second RG6 run to power it.

Interestingly there’s a minimum length of cable run (8m) specified for these installations. Anything less than 8m leads to lower resistance and possible overheating.

There is a minimum length of 8m for the cable run this is very
important as it provides the right amount of cable resistance so
the modem does not get hot and over heat. Max cable run is 50m.


Transparent Performance Enhancing Proxy (TPEP)

TPEP aka Web Acceleration, is a service offered by NBNco to spoof TCP replies, to make the handshake more efficient. It can, unsurprisingly, lead to headaches accessing services, particularly those that employ TLS.

Web Interface
user name = ADMIN and the password = operator (lower case)

Beam Selection

The installer key sets the beam, and his can be remotely changed by NBNco MAC / NOC team.

BIRRAUS have a good article explaining the spot beams available.

Educational Port

Like the other NBNco NTDs, there are multiple UNI-D ports available on the Skymuster modem allowing segregation of services.

One option that seems to be gaining traction is a dedicated port on the modem for educational use, on one of the UNI-D ports on the modem.

Educational Ports are configured to allow access for remote / distance education students.

The local state government sets pricing, speeds and data usages.

Ground Stations

There are 9 active and one standby ground stations, geographically spread across Australia, with a standby in Wolumna, NSW. The standby is capable of assuming control for any of the other ground stations.

ViaSat built the equipment and services different spot beams.

Again, BIRRAUS have this covered in their article, but here’s an extract they’ve made listing the ground stations and beams serviced.

Wolumla ground station


Solar Transit

Solar transits happen twice yearly when the satellite is aligned directly between the sun and Australia.

The immense solar radiation from the sun overloads the transceivers on the ground, as they’re positioned at the satelite, with the sun behind it overloading the signals.

This lasts for about 6 minutes twice yearly, and affects different ground stations and each of the satellites at different times.

Copper Cutoff

Currently the copper decommissioning does not apply to Skymuster services. This means customers with a copper POTS line, can keep it indefinitely.

This has lead to headaches with incumbent providers who had intended to decommission / sell off remote exchanges, but will be required under Universal Service Obligation to keep them active.

3rd Satellite

Due to unexpectedly large uptake of Skymuster services, NBNco had floated the possibility of launching a 3rd Satelite in 2020:

Scenario 3: Third satellite – This scenario assumes that NBN Co constructs and launches a third satellite at the end of CY20. This mitigates the need to build some fixed wireless base stations and FTTN distribution areas. The capacity of this satellite will only be partially required to meet NBN Co’s needs

Scenario 4: Third satellite in partnership – This scenario mirrors Scenario 3, but assumes that NBN Co enters into a partnership with an external party to access only the required capacity on a third satellite rather than building and owning it outright.

Source – NBNco Fixed Wireless & Satellite Review

Portable Services

Apart from spot-beam migration, there are no technical limitations preventing portable Skymuster services from becoming a service offered.

Qantas are using this to power the in-flight WiFi on their domestic fleet of 80 Boeing 737 and Airbus A330s. Though it seems that may no longer be the case.

The NBNco launched a fleet of “Road Muster” 4WDs for promotion of the services. They drive from town to town, spruiking the benefits of Skymuster.

On the roof of the 4WD is a Satellite ODU, which seems to be self / remote positioning.

Online sleuthing reveals it’s a EXPLORER 8120 manufactured by Cobham. It featuring auto-acquire, drive-away antenna system using Dynamic Pointing Correction technology. At $32k USD, it’s rather pricey, and outside the range of most grey-nomads and campers.

If a user wanted to manually position the dish, they could using a service like or Wolfram Alpha.  This would give a rough alignment and then the tone generator “Point and Peak” for the fine adjustment.

Layer 3 Services

Skymuster services are setup as L2 services.

NBNCo has highlighted from day 1, the option of using Layer 3 for deliver to enable deep packet inspection.

This would allow them to prioritise traffic more easily / efficiently.


Please let me know in the comments if I’ve got anything here wrong.

Noka GSM phones on Osmocom

GSM with Osmocom Part 9: Calls & SMS at last!

So now we’ve covered the basics of what’s involved let’s get some traffic on our network.

For starters we’ll need to start each of our network elements and bring up whichever BTS hardware we’re using.

In order for our calls to have audio, we’ll need to set a parameter on the Media Gateway. We’ll cover the Media Gateway in more detail down the line, but there’s one value in the MGW we’ll need to set in order to have calls working, and that’s the rtp bind-ip value.
You can either set it in the config file or via VTY/Telnet on port 4243.

We’ve talked about using systemctl to start all the services, but there’s a script in the /etc/osmocom directory called which starts all the network elements for us.

Once you’ve got all the services started I’d suggest hopping onto the OsmoBSC and enabling all the logging you can, then connecting / starting your BTS.

You should see the Abis over IP connection & OML link come up as the BTS connects to the BSC.

And then, hold your breath, power up a phone and search for networks.

All going well you’ll see OsmoMSC in the network search, select it and you should see log data flying by as the phone (“terminal”) connects to the network.

Assuming you configured the IMSI of the SIM on the HLR you should be connected to the network and showing bars on the phone.

You can check your phone number (MSISDN) by dialling the USSD code *#100#

But it’s not a network with just one phone connected, connect a second phone, check it’s phone number the same way and call from one to the other.

SMS should also just work.

And there you have it, a functional GSM network!

But this isn’t the end for us, it’s really just the beginning.

There’s still so much more to learn and work on – Over the next few weeks / months we’ll add packet data to the network with GPRS or EDGE, connect into external call routing and SMS routing interfaces, use Circuit Switched Fallback to provide voice service to users on LTE networks and roam between them.

Magic SIM Card Art

16 in 1 Magic SIM Card Revisited

I found a “16-in-1 Super SIM X-SIM” in my SIM card drawer, I think I ordered these when I was first playing with GSM and never used it.

I was kind of curious about how these actually worked, so after some online sleuthing I found a very suspicious looking rar file, which I ended up running in a VM and mapping the Card Reader to the VM.

What a treat I was in for in terms of UI.

The concept is quite simple, you program a series of IMSI and K key values onto the SIM card, and then using a SIM Toolkit application, you’re able to select which IMSI / K key combination you want to use.

A neat trick, I’d love a LTE version of this for changing values on the fly, but it’d be a pretty niche item considering no operator is going to give our their K and OPc keys,

But come to think of it, no GSM operator would give out K keys, so how do you get the K key from your commercial operator?

I noticed the grayed out “Crack” icon on the menu.

After rifling through my SIM drawer I found a few really old 2G SIMs, stuck one in, reconnected and clicked “Crack” and then start.

I left it running in the background after the manual suggested it could take up to 24 hours to run through all the codes.

To my surprise after 2 minutes the software was requesting I save the exported data, which I did.

Then I put the 16 in 1 back in, selected Magic and then imported the cracked SIM data (IMSI, ICCID, Ki & SMSp).

By the looks of it the software is just running a brute force attack on the SIM card, and the keyspace is only so large meaning it can be reversed in.

I did a bit of research to find out if this is exploiting any clever vulnerabilities in UCCID cards, but after running some USB Pcap traces it looks like it’s just plain old brute force, which could be easily defended against by putting a pause between auth attempts on the SIM.

I’ve no idea if that’s the actual K value I extracted from the SIM – The operator that issued the SIM doesn’t even exist anymore, but I’ll add the details to the HLR of my Osmocom GSM lab and see if it matches up.

Out of curiosity I also connected some of my development USIM/ISIM/SIM cards that I can program, the software is amazing in it’s response:

Configuring YateBTS for Software Defined GSM/GPRS

I did a post yesterday on setting up YateBTS, I thought I’d cover the basic setup I had to do to get everything humming;


In order to actually accept subscribers on the network you’ll need to set a Regex pattern to match the prefix of the IMSI of the subscribers you want to connect to the network,

In my case I’m using programmable SIMs with MCC / MNC 00101 so I’ve put the regex pattern matching starting with 00101.

BTS Configuration

Next up you need to set the operating frequency (radio band), MNC and MCC of the network. I’m using GSM850,

Next up we’ll need to set the device we’re going to use for the TX/RX, I’m using a BladeRF Software Defined Radio, so I’ve selected that from the path.

Optional Steps

I’ve connected Yate to a SIP trunk so I can make and receive calls,

I’ve also put a tap on the GSM signaling, so I can see what’s going on, to access it just spin up Wireshark and filter for GSMMAP