Tag Archives: RF

X-Polarised Antennas in Mobile Networks

15/08/20255G SA, EUTRAN, GSM, Mobile Networks, RF5G, Polarization, RFNick

Polarization Basics

Let’s imagine the coin slot on a payphone – Coins can only enter the slot if they’re aligned with the slot.

If you tried to rotate the coin by 90 degrees, it wouldn’t fit it in the slot.

If the slot on the payphone went from up-to-down, our coin slot could be described as “vertically polarized”.
Only coins in the vertically polarized orientation would fit.

Likewise, a payphone with the coin slot going side-to-side we could describe the coin slot as being “horizontally polarized”, meaning only coins that are horizontally polarized (on their side) would fit into the coin slot.

RF waves also have a polarization, like our coin slot.

A receiver wishing to receive into signals transmitted from a vertically-polarized antenna, will need to use a vertically-polarised antenna to pick up the signal.

Likewise a signal transmitted from a horizontally polarized antenna, would require a horizontally polarised antenna on the receiving side.

If there is a mismatch in polarization (for example RF waves transmitted from a horizontal polarized antenna but the receiver is using a vertically polarized antenna) the signal may still get through, but received signal strength would be severely degraded – in the order of 20dB, which is 1/100th of the power you’d get with the correct polarization.

You can think of polarization mismatches as like cutting up the coin to fit sideways through the coin slot – you’d get a sliver of the original coin that was cut up to fit. Much like you recieve a fraction of the original signal if your polarization doesn’t match on both ends.

different antenna polarizations — Plagiarised diagram showing antenna polarization

Useless Information: In Australia country TV stations and metro TV stations sometimes transmitted different programming. To differentiate the signals on the receiver side, country TV transmitters used vertical polarisation, while metro transmitters used horizontal polarization.
The use of different polarization orientation cuts down on interference in the border areas that sit in the footprint of the metro and country transmitters.
This means as you drive through metro areas you’ll see all the yagi-antennas are horizontally oriented, while in country areas, they’re vertically oriented.

Vertical Polarization

Early mobile phone networks used Vertical Polarization.

This means they used an flagpole like antenna that is vertically oriented (Omnidirectional antenna) on the base-station sites.

Oldschool mobile phones also had a little pop out omnidirectional antenna, which when you held the phone to your ear, would orient the antenna vertically.

This matches with the antenna on the base station, and away we go. You still sometimes see vertical polarization in use on base-station sites in low density areas, or small cells.

Vertically polarized mobile phone antenna, which is oriented vertically, like on the base station behind it.

Increasing subscriber demand meant that operators needed more capacity in the network, but spectrum is expensive. As we just saw a mismatch in polarization can lead to a huge reduction in power, and maybe we can use that to our advantage…

Shannon-Hartley Theorem

But first, we need to do some maths…

Stick with me, this won’t be that hard to understand I promise.

There are two factors that influence the capacity of a network, the Bandwidth of the Channel and the Signal-to-Noise Ratio.

So let’s look at what each of these terms mean.

Bandwidth

Bandwidth is the information carrying capacity.
A one-page sheet of A4 at 12 point font, has a set bandwidth. There’s only so much text you can fit on one A4 sheet at that font size.

We can increase the bandwidth two ways:

Option 1 to Increase Bandwidth: Get a larger transmission medium.
Changing the size of the medium we’re working with, we can increase how much data we can transfer.

For this example we could get a bigger sheet of paper, for example an A3 sheet, or a billboard, will give us a lot more bandwidth (content carrying capability) than our sheet of A4.

Changing from an A4 sheet to an A3 sheet, increases the number of characters we can store on the page (Slightly more than doubling the bandwidth).

Option 2 to Increase Bandwidth: Use more efficient encoding
As well as changing the size of the medium we are using, we can change how we store the data on the paper, for example, shrinking the font size to get more text in the same area, which also the bandwidth.

In communications networks this is also true: Bandwidth is determined by how much spectrum we have to work with (For example 10Mhz), and how we encode the data on that spectrum, ie morse-code, Binary-Phase-Shift-Keying or 16-QAM.
Each of the different encoding schemes have different levels of bandwidth for the same amount of spectrum used, and we’ll cover those in more detail in the future.

So now we’ve covered increasing the bandwidth, now let’s talk about the other factor:

Signal-to-Noise Ratio

Signal-to-Noise Ratio (SNR) is the ratio of good signal, to the background noise.

On the train my headphones on block out most of the other sounds.
In this scenario, the signal (the podcast I’m listening to on the headphones) is quite high, compared to the noise (unwanted sounds of other people on the train), so I have a good Signal-to-Noise ratio.

When we talk about the Signal-to-Noise Ratio, we’re talking about the ratio of the signal we want (podcast) to the noise (signal we don’t want).

When I’m on the train if 90% of what I hear is the podcast I’m listening to (the “signal”) and 10% is random background sounds (the “noise”) then my signal-to-noise-ratio is really good (high).

Capacity and SNR

Let’s continue with the listening to a podcast analogy.

The average human talks about 150 words per minute. So let’s imagine I’m listening to a podcast at 150 words per minute.

If I’m listening in an anechoic chamber, then I’ll be able to hear everything that’s being said, so my bandwidth will 150 words per minute. As there is no background noise, my capacity will also be 150 words per minute.

But if I leave an anechoic chamber (much as I love spending time in anechoic chambers), and go back on the train, I won’t hear the full 150 words per minute (bandwidth) due to the noise on the train drowning out some of the signal (podcast).

The Shannon-Hartley Theorem, states that the capacity is equal to the bandwidth multiplied by the signal to noise ratio.

So on the train hearing 90% of what’s said on the podcast, 10% drowned out, means my signal-to-noise ratio is 0.9 (pretty good).

So according to Shannon-Hartley Theorem the capacity of me listening to a podcast on the train (150 words per minute of bandwidth multiplied by 0.9 Signal-to-Noise Ratio) would give me 135 words per minute of capacity.

Claude Shannon: Juggling Unicyclist Who Changed the World | Time — Claude Shannon, of 1/2 of the Shannon-Hartley Theorem, with an electromechanical mouse maze.

How this applies to RF Networks

In an RF context, our Bandwidth has a fixed information carrying capacity, for example on LTE, with a 5Mhz wide channel using 16QAM has 12.5Mbps of bandwidth available.

In a simple system, we have two levers we can pull to increase the bandwidth:

Increasing the size of the channel – If we went from a 5Mhz wide channel to a 20Mhz channel, this would give us 4x the available Bandwidth (Actually slightly more in LTE, but whatever)
Changing the encoding to cram more data on the same a size channel (From 16QAM to 64QAM would also give us 4x the available Bandwidth).

As we’ll see later in this post, there are some extra tricks (MIMO and Diversity) that we’ll look at later in this post, to increase the bandwidth of the system.

Our Signal-To-Noise (SNR) is constantly variable with a gazillion things that can influence the result.
Some of the key factors that impact the SNR are the distance from the transmitter to the receiver and anything blocking the path between them (trees, buildings, mountains, etc), but there’s so many other factors that go into this. From atmospheric conditions, flat surfaces the signal can reflect off leading to multipath noise, other nearby transmitters, etc, can all influence our SNR.

Our capacity is equal to our Bandwidth multiplied by the Signal-to-Noise ratio.
Shannon-Hartley Theorem (ish)

As a goal we want capacity, and in an ideal world, our capacity would be equal to our bandwidth, but all that noise sneaks in and reduces our available capacity, based on the current SNR value.

So now we want to get more capacity out of the network, because everyone always wants to add capacity to networks.

One trick that we can use it to use multiple antennas with different polarization.

If our transmitter sends the same signal data out multiple antennas, with some clever processing on the transmitter and the receiver, we use this to maximize the received SNR. This is called Transmit Diversity and Receive Diversity and it’s a form of black magic.

The Transmitter uses feedback from the receiver to determine what the channel conditions are like, and then before transmitting the next block of data, compensates for the channel conditions experienced by the receiver, this increases the SNR and allows for higher MCS / encoding schemes, which in turns means higher throughput.

You’ll notice on most Antennas in the wild today you’ve got at least two ports for each frequency, which are + and -, which are the two polarizations.

Modern mobile networks use ±45° slant polarization (aka X Polarization), which works better in the orientations end users hold their phones in.

These two polarizations, each connected to a distinct transmit/receive path on the phone (UE) end and on the base station end, allows multiple data streams to be sent at the same time (spatial multiplexing, the foundation for MIMO) which enables higher throughput or can be configured enable redundancy in the transmission to better pick up weak signals (Diversity).

Importing building footprints into Forsk Atoll from OpenStreetMap data

01/08/20255G SA, EUTRAN, GSM, LTE, Mobile Networks, RF, SoftwareAtoll, Forsk, RF, RF PlanningNick

Having building footprints inside Atoll is super-duper valuable, this means you can calculate your percentage of homes / buildings covered, after all geographic coverage and population coverage are two very different things.

Download the data from OSM data – If you only need a small are you can use the Export OSM page, or if you need a wider area Geofabrik provides country level exports of the data, or if you’re really keen you can download all the OSM data.

Once you’ve got the export, we’ll load the .gpkg file (or files) into GlobalMapper

Select one layer at a time that you want to export into Atoll. (This also works for roads, geographic boundaries, POIs, etc)

Export the selected layer from Export -> Export Vector / Lidar Format

Set output type to “Shapefile”

Set output filename in “Export Areas” (This will be the output file). If you want to limit the export to a given area you can do that in Export Bounds.

Now we can import this data into Atoll.

File -> Import

Select the exported Shapefile we just created.

Set the projection and import

Bingo now we’ve got our building footprints,

We can change the style of the layer and the labels as needed.

Now we can use the buildings as the Focus Zone / Compute Zone and then run reports and predictions based on those areas.

For example I can run Automatic Cell Planning with the building layers as the Focus zones, to optimize azimuths, tilts and powers to provide coverage to where people live, not just vacant land.

Importing Global Clutter data into Forsk Atoll

11/07/20255G SA, EUTRAN, GSM, LTE, Mobile Networks, Notes, RF, SoftwareAtoll, Forsk, RF, RF PlanningNick

Clutter data describes real world things on the planet’s surface that attenuate signals, for example trees, shrubs, buildings, bodies of water, etc, etc. There’s also different types of trees, some types of trees attenuate signals more than others, different types of buildings are the same.

Getting clutter data used to be crazy expensive, and done on a per country or even per region basis, until the European Space Agency dropped a global dataset free of charge for anyone to use, that covered the entire planet in a single source of data.

So we can use this inside Forsk Atoll for making our predictions.

First things first we’ll need to create an account with the ESA (This is not where they take astronaut applications unfortunately, it just gives you access to the datasets).

Then you can select the areas (tiles) you want to download after clicking the “Download” tab on the right.

We get a confirmation of the tiles we’re download and we’ll get a ZIP file containing the data.

We can load the whole ZIP file (Without needing to extract anything) into GlobalMapper which loads all the layers.

I found the _Map.tif files the highest resolution, so I’m only exporting these.

Then we need to export the data to GeoTiff for use in Atoll (The specific GeoTiff format ESA produces them in is not compatible with Atoll hence the need to convert), so we export the layers as Raster / Image format.

Atoll requires square pixels, and we need them in meters, so we select “Calculate Spacing in Other Units”.

Then set the spacing to meters (I use 1m to match everything else, but the data is actually only 10m accurate, so you could set this to 10m).

You probably want to set the Export Bounds to just the areas you’re interested in, otherwise the data gets really big, really quickly and takes forever to crunch.

Now for the fancy part, we need to import it into Atoll.

When we import the data we import it as Raster data (Clutter Classes) with a pixel size of 1m.

Alas when we exported the data we’ve lost the positioning information, so while we’ve got the clutter data, it’s just there somewhere on the planet, which with the planet being the size it is, is probably not where you need it.

So I cheat, I start put putting the West and North values to match the values from a Cell Site I’ve already got on the map (I put one in the top left and bottom right corners of the map) and use that as the initial value.

Then – and stick with me, this is very technical – I mess with the values until the maps line up into the correct position. Increase X, decrease Y, dialing it it in until the clutter map lines up with the other maps I’ve got.

Right, now we’ve got the data but we don’t have any values.

Each color represents a clutter class, but we haven’t set any actual height or losses for that material.

To know what each colour means we need to RTFM – ESA WorldCover 2020 User Manual.

Which has a table:

Alas the Map Code does not match with the table in the manual, but the colours do, here’s what mine map to:

Which means when hovering over a layer of clutter I can see the type:

Next we need to populate the heights, indoor and outdoor losses for that given clutter. This is a little more tricky as it’s going to vary geography to geography, but there’s indicative loss numbers available online pretty easily.

Once you’ve got that plugged in you can run your predictions and off you go!

RAN Builds – Can we just get the same connectors thanks?

09/05/2025EUTRAN, LTE, Mobile Networks, RFBuild, RAN, RFNick

Concrete, steel and labor are some of the biggest costs in building a cell site, and yet all the focus on cost savings for cell sites seems to focus on the RAN, but the actual RAN equipment isn’t all that much when you put it into context.

I think this is mostly because there aren’t folks at MWC promoting concrete each year.

But while I can’t provide any fancy tricks to make towers stronger or need less concrete for foundations, there’s some potential low-hanging fruit in terms of installation of sites that could save time (and therefor cost) during network refreshes.

I don’t think many folks managing the RAN roll-outs for MNOs have actually spent a week with a tower crew rolling this stuff out. It’s hard work but a lot of it could be done more efficiently if those writing the MOPs and deciding on the processes had more experience in the field.

Disclaimer: I’m primarily a core networks person, this is the job done from a comfy chair. This is just some observations from the bits of work I’ve done in the field building RAN.

Standardize Power Connectors

Currently radio units from the biggest RAN vendors (Ericsson, Nokia, Huawei, ZTE & Samsung) each use different DC power connectors.

This means if you’re swapping from one of these vendors to another as part of a refresh, you need new power connectors.

If you’re lucky you’re able to reuse the existing DC power cables on the tower, but that means you’re up on a tower trying to re-terminate a cable which is a fiddly job to do on the ground, and far worse in the air. Or if you’re unlucky you don’t have enough spare distance on the DC cables to do the job, then you’re hauling new DC cables up a tower (and using more cables too).

The Nokia and Ericsson connectors are very similar, and with a pair of side cutters you can mangle an Ericsson RRU connector to work on a Nokia RRU and visa-versa.

While Huawei and ZTE have adopted for push connectors with the raw cables behind a little waterproof door.

If we could just settle on one approach (either is fine) this could save hours of install time on each cell site, extrapolate that across thousands of cell sites for each network, and this is a potentially large saving.

Standardize Fiber Cables

The same goes for waterproofing fibre, Ericsson has a boot kit that gets assembled inline over the connectors, Nokia has this too, as well as a rubber slide over cover boot on pre-term cables.

Again, the cost is fairly minimal, but the time to swap is not. If we could standardize a break out box format on the top of the tower and a LC waterproofing standard, we could save significant time during installs, and as long as you over-provision the breakout (The cost difference between a 6 core fiber vs a 48 core fibre is a few dollars), you can save significant time having to rerun cables.

Yes, we’ve all got horror stories about someone over-bending fiber, and if you reused fibre between hardware refresh cycles, but modern fiber is crazy tough so the chances of damaging the reused fiber is pretty slim, and spare pairs are always a good thing.

Preterm DC Cables

Every cell site install features some poor person squatting on the floor (if they’re savvy they’ve got a camping stool or gardening kneeling mat) with a “gut buster” crimping tool swaging on connectors for the DC lugs.

If we just used the same lugs / connectors for all the DC kit inside the cell sites, we could have premade DC cables in various lengths (like everyone does with Ethernet cables now), rather than making each and every cable off a spool (even if it is a good ab workout).

I dunno, I’m just some Core network person who looks at how long all this takes and wonders if there’s a way it could be done better, am I crazy?

Seeing the Airwaves – QCsuper

06/09/2024EUTRAN, Mobile Networks, RF, UncategorizedLTE, NAS, NR, QCSuper, Qualcomm, RF, RRCNick

Recently we were on a project and our RAN guy was seeing UEs hand between one layer and another over and over. The hysteresis and handover parameters seemed correct, but we needed a way to see what was going on, what the eNB was actually advertising and what the UE was sending back.

In a past life I had access to expensive complicated dedicated tooling that could view this information transmitted by the eNB, but now, all I need is a cellphone or a modem with a Qualcomm chip.

QCsuper is a super handy tool that gives access to the Diag interface on Qualcomm chipsets. That’s the same interface QXDM uses, but without the massive headache and usability issues that come with QXDM, plus it puts everything in Wireshark to make it super easy to view everything.

You can see RRC, NAS and even the user plane traffic, all from Wireshark.

I’ve tested this with a rooted Xiaomi Pro 12 and a Quectel modem in a M.2 to USB adapter.

This is really cool and I’m looking forward to using it more in the field, or just if I’m bored on the train scanning the airwaves!

Funky Connectors for Cellular

12/01/2024Mobile Networks, RFRAN, RFNick

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

22/12/2023EUTRAN, GSM, Mobile Networks, RFCommscope, Diplexer, RFNick

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.

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.

Forsk Atoll – Importing Antennas

21/08/2021Python, RFAtoll, Python, RF, RF PlanningNick

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":
        print(individual_file)
        f.write(individual_file + "\n")

f.close()

Which you can then import into Atoll, easy!

Dumb Lesson in RF Connectors

28/06/2020RFBladeRF, OsmoBTS, RF, SRSLTE, YateBTSNick

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.

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…

IMTx: NET02x (4G Network Essentials) – Management of Data Flows – 1. Principle of Encapsulation

29/04/2019EPC, EUTRAN, LTE, Mobile Networks, RFencapsulation, EUTRAN, GTP, LTE, NET02x, NOTES, RFNick

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

Mobile networks are by definition, mobile.

In a fixed network, if I were to connect my laptop to my network at home, I’d get a different address to if I plug it in at work.

In a mobile network UEs are often moving, but we can’t keep changing the IP address – that would lead to all sorts of issues.

The UE must maintain the same IP address, at least for the duration of their session.

Instead the IP address of a UE is allocated by the P-Gateway (P-GW) when the UE attaches.

The IP the P-GW allocates to the UE is in a subnet managed by the P-GW – that IP prefix is associated with the P-GW, so traffic is sent to the P-GW to get to the UE.

Therefore all traffic destined for the UE from external networks will be sent to the P-GW first.

Because the UE is mobile and changing places inside the network, we need a way to keep the UE’s IP even though it’s moving around, something that by default TCP/IP networks don’t cater for very well.

To achieve this we use a technique known as encapsulation where we take the complete IP packet for the UE, and instead of forwarding it on to the UE on a Layer 3 or Layer 2 level, we bundle the whole packet up and put it inside a new IP packet we can forward on anywhere regardless of what’s insude, until it gets to the eNB the UE is on when it can be unpacked and sent to the UE, which is unaware of all the steps / hops it went through.

The concept is very similar to GRE to a VPN (PPTP, IPsec, L2TP, etc) where the user’s IP packets are encapsulated inside another IP packet.

We encapsulate the data using GTP – GPRS Tunneling Protocol.

From a Layer 3 perspective the fact the contents of the GTP packet (another IP packet) is irrelevant, and it’s just handled like any other IP packet being sent from the P-GW to the S-GW.

Getting traffic to the UE

When a packet is sent to the UE’s IP Address from an external destination, it’s first sent to the P-GW, as the P-GW manages that IP prefix.

The P-GW identifies the packet as being destined for a UE, so it encapsulates the entire packet for the UE, by wrapping it up inside a GTP packet.

UE’s IP Packet encapsulated by the P-GW and sent to the IP of the S-Gw

The P-GW then forwards the GTP packet to the serving Serving-Gateway (S-GW)’s IP Address, so the S-GW can forward it to the eNB to get to the UE.

(The P-GW forwards the traffic to the S-GW so the S-GW can get it to the correct eNB for the UE, the reason for having two nodes to manage this is so it can scale better)

Once the traffic gets to the the eNB serving the UE, the eNB de-encapsulates the data, so it’s now got an IP packet with the destination IP of the UE.

It takes the data and puts it onto a transport block sent to the specific RNTI of the UE.

The hops between the UE and the P-GW are transparent to the UE – it doesn’t see the IP Address of the eNB or the S-GW, or any of the routers in between.

Nick vs Networking

Telco Network Engineering