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.
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!
Up close view of the connectorDC breaks out when you pull it apartAnd the fibres are held in with springs to the top half of the connector bodyAnd the breakout to LC and RRU DC connectors
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.
A lot of screwsBonus TMA
Thanks to Oliver for offering up the bench space when I rocked to up to their house with some stuff to pull apart.
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()
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,
GSM with YateBTS
GSM with Osmocom
LTE with srsLTE
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.
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.
