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).
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?
Last year we deployed some Hughes HL1120W OneWeb terminals in one of the remote cellular networks we support.
Unfortunately it was failing to meet our expectations in terms of performance and reliability – We were seeing multiple dropouts every few hours, for between 30 seconds and ~3 minutes at a time, and while our reseller was great, we weren’t really getting anywhere with Eutelsat in terms of understanding why it wasn’t working.
Luckily for us, Hughes (who manufacture the OneWeb terminals) have an unprotected API (*facepalm*) from which we can scrape all the information about what the terminal sees.
As that data is in an API we have to query, I knocked up a quick Python script to poll the API and convert the data from the API into Prometheus data so we could put it into Grafana and visualise what’s going on with the terminals and the constellation.
After getting all this into Grafana and combining it with the ICMP Blackbox exporter (we configured Blackbox to send HTTP requests and ICMP pings out of each of the different satellite terminals we had (a mix of OneWeb and others)) we could see a pattern emerging where certain “birds” (satellites) that passed overhead would come with packet loss and dropouts.
It was the same satellites each time that led to the drops, which allowed us to pinpoint to say when we see this satellite coming over the horizon, we know there’s going to be some packet loss.
In the end Eutelsat acknowledged they had two faulty satellites in the orbit we are using, hence seeing the dropouts, and they are currently working on resolving this (but that actually does require rockets, so we’re left without a usable service for the time being) but it was a fun problem to diagnose and a good chance to learn more about space.
Packet loss on the two OneWeb terminals (Not seen on other constellation) correlated with a given satellite pass
The repo has instructions for use and the Grafana templates we used.
At one point I started playing with the OneWeb Ephemeris data so I could calculate the azimuth and elevation of each of the birds from our relative position, and work out distances and angles from the terminal. The maths was kinda fun, but oddly the datetimes in the OneWeb ephemeris data set seems to be about 10 years and 10 days behind the current datetime – Possibly this gives an insight into OneWeb’s two day outage at the start of the year due to their software not handling leap years.
Despite all these teething issues I’m still optimistic about OneWeb, Kupler and Qianfan (Thousand Sails) opening up the LEO market and covering more people in more places.
Update: Thanks to Scott via email who sent this: One note, there’s a difference between GPS time and Unix time of about 10 years 5 days. This is due to a) the Unix epoch starting 1970-01-01 and the gps epoch starting 1980-01-05 and b) gps time is not adjusted for leap seconds, and ends up being offset by an integer number of seconds.
Technology is constantly evolving, new research papers are published every day.
But recently I was shocked to discover I’d missed a critical development in communications, that upended Shannon’s “A mathematical theory of communication”.
I’m talking of course, about the GENERATION X PLUS SP-11 PRO CELL ANTENNA.
I’ve been doing telecom work for a long time, while I mostly write here about Core & IMS, I am a licenced rigger, I’ve bolted a few things to towers and built my fair share of mobile coverage over the years, which is why I found this development so astounding.
With this, existing antennas can be extended, mobile phone antennas, walkie talkies and cordless phones can all benefit from the improvement of this small adhesive sticker, which is “Like having a four foot antenna on your phone”.
So for the bargain price of $32.95 (Or $2 on AliExpress) I secured myself this amazing technology and couldn’t wait to quantify it’s performance.
Think of the applications – We could put these stickers on 6 ft panel antennas and they’d become 10ft panels. This would have a huge effect on new site builds, minimize wind loading, less need for tower strengthening, more room for collocation on the towers due to smaller equipment footprint.
Luckily I have access to some fancy test equipment to really understand exactly how revolutionary this is.
The packaging says it’s like having a 4 foot antenna on your phone, let’s do some very simple calculations, let’s assume the antenna in the phone is currently 10cm, and that with this it will improve to be 121cm (four feet).
Projected Gain (Post Sticker)Formulas Used
According to some basic projections we should see ~21dB gain by adding the sticker, that’s a 146x increase in performance!
Man am I excited to see this in action.
Fortunately I have access to some fun cellular test equipment, including the Viavi CellAdvisor and an environmentally controlled lab my kitchen bench.
I put up a 1800Mhz (band 3) LTE carrier in my office in the other room as a reference and placed the test equipment into the test jig (between the sink and the kettle).
We then took baseline readings from the omni shown in the pictures, to get a reading on the power levels before adding the sticker.
We are reading exactly -80dBm without the sticker in place, so we expertly put some masking tape on the omni (so we could peel it off) and applied the sticker antenna to the tape on the omni antenna.
At -80dBm before, by adding the 21dB of gain, we should be put just under -60dBm, these Viavi units are solid, but I was fearful of potentially overloading the receive end from the gain, after a long discussion we agreed at these levels it was unlikely to blow the unit, so no in-line attenuation was used.
Okay, </sarcasm> I was genuinely a little surprised by what we found; there was some gain, as shown in the screenshot below.
Marker 1 was our reference without the sticker, while reference 2 was our marker with the sticker, that’s a 1.12dB gain with the sticker in place. In linear terms that’s a ~30% increase in signal strength.
Screenshot
So does this magic sticker work? Well, kinda, in as much that holding onto the Omni changes the characteristics, as would wrapping a few turns of wire around it, putting it in the kettle or wrapping it in aluminum foil. Anything you do to an antenna to change it is going to cause minor changes in characteristic behavior, and generally if you’re getting better at one frequency, you get worse at another, so the small gain on band 3 may also lead to a small loss on band 1, or something similar.
So what to make of all this? Maybe this difference is an artifact from moving the unit to make a cup of tea, the tape we applied or just a jump in the LTE carrier, or maybe the performance of this sticker is amazing after all…
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.
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.
To begin we’ll need to setup the basics, by disabling DHCP and setting an local IP Address for the unit.
SET DHCPSW: SWITCH=DISABLE;
SET LOCALIP: IP="192.168.5.234", MASK="255.255.248.0";
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:
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.
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 CABINET:CN=0,TYPE=APM30; //Add a BBU3900 subrack, run the following command: ADD SUBRACK:CN=0,SRN=0,TYPE=BBU3900; //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:
//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;
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…
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!
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()
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
LST SOFTWARE:;
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,
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.
Pretty impressive functionality for something this old, but no ability to monitor if MCBs have been tripped or remotely power off/on outputs.
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.
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…
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!
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!
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.
Measurements
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.
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,
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.
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:
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 and EDGE
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.
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.
An idiot with greatly improved RSSI though…
Want more telecom goodness?
I have a good old fashioned RSS feed you can subscribe to.
