Tag Archives: BTS

Huawei BTS 3900 LMPT Basic Config

This post is one in a series documenting my adventures attempting to configure a used BTS 3900 to function as a eNB in my lab.

There are 5 network ports on the LMPT card:

  • 2x SFP cages – SFP 0 and SFP 1
  • 1x 10/100 Ethernet port – ETH – Used to access the Local Maintenance terminal
  • 2x Fe/Ge ports – Fe/Ge0 and Fe/Ge1

Configuring the Ethernet Ports

What took me a little while to realise is that SFP0 and Fe/Ge0 are paired, they’re really only one interface. This means you can only use one at a time – you can’t use SFP0 and Fe/Ge0 simultaneously- Same with SFP1 and Fe/Ge1.

Before we get started we’ll list the current interfaces:

DSP ETHPORT:;

Assuming the interfaces aren’t there, we’ll need to add the interfaces, in my case the LMPT card is in Chassis 1, Slot number 7.

ADD ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD, PN=0, PA=AUTO, SPEED=AUTO, DUPLEX=AUTO, USERLABEL="SFP_Fe_Ge_0";
ADD ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD, PN=1, PA=AUTO, SPEED=AUTO, DUPLEX=AUTO, USERLABEL="SFP_Fe_Ge_1";

And then we’ve got to add an IP to one of the interfaces, in the below example I’ve added 10.0.1.210/24 to port 0 (which can be either SFP0 or Fe/Ge0).

ADD DEVIP: SRN=1, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0, IP="10.0.1.210", MASK="255.255.255.0", USERLABEL="SFP_Fe/Ge_0"; 

At this point I plugged into the Fe/Ge0 port into my switch, and from my laptop on the same 10.0.1.0/24 subnet, I was able to ping the eNodeB.

And now we can check the status of the port:

DSP ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD, PN=0;
+++    4-PAL0089624        2020-11-28 00:19:13
O&M    #806355532
%%DSP ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD;%%
RETCODE = 0  Operation succeeded.

DSP ETHPORT Result
------------------
                           Cabinet No.  =  0
                           Subrack No.  =  1
                              Slot No.  =  7
                         Subboard Type  =  Base Board
                              Port No.  =  0
                        Port Attribute  =  Copper
                           Port Status  =  Up
                 Physical Layer Status  =  Up
       Maximum Transmission Unit(byte)  =  1500
                             ARP Proxy  =  Enable
                          Flow Control  =  Open
                           MAC Address  =  DCD2-07FC-A9E8
                       Loopback Status  =  No Loop
               In Loopback Mode or Not  =  No
                 Ethernet OAM 3AH Flag  =  Disable
          Number of RX Packets(packet)  =  1682
              Number of RX Bytes(byte)  =  163929
Number of RX CRC Error Packets(packet)  =  2
                    RX Traffic(byte/s)  =  259
          Number of TX Packets(packet)  =  53
              Number of TX Bytes(byte)  =  13952
                    TX Traffic(byte/s)  =  0
  Local Configuration Negotiation Mode  =  Automatic Negotiation
         Local Actual Negotiation Mode  =  Automatic Negotiation
                           Local Speed  =  100M
                          Local Duplex  =  Full Duplex
          Peer Actual Negotiation Mode  =  Automatic Negotiation
                            Peer Speed  =  100M
                           Peer Duplex  =  Full Duplex
                         Number of IPs  =  1
                       IP Address List  =  10.0.1.210 255.255.255.0
(Number of results = 1)


---    END

On with the rest of the config,

Adding a default route:

ADD IPRT: RTIDX=0, SRN=1, SN=7, SBT=BASE_BOARD, DSTIP="0.0.0.0", DSTMASK="0.0.0.0", RTTYPE=NEXTHOP, NEXTHOP="10.0.1.1", MTUSWITCH=OFF, DESCRI="Default Route";

Setting a DNS Server:

ADD DNSSRV: DNSSRVID=0, IPVER=IPv4, DNSCIP4="10.0.1.210", DNSSIP4="1.1.1.1";

Ensure you can ping the DNS server & in my case the MME:

PING: SRN=1, SN=7, SRCIP="10.0.1.210", DSTIP="1.1.1.1", CONTPING=DISABLE, APPTIF=NO;
PING: SRN=1, SN=7, SRCIP="10.0.1.210", DSTIP="10.0.1.183", CONTPING=DISABLE, APPTIF=NO;

And with that, you’ve got the network side of the config done on the eNodeB.

At this stage you’re able to unplug from the ETH port you’ve got the WebLMT connection to, and just connect to it like any other network device.

There’s a few more steps before we bring cells on the air, we’ve got to set timing sources, configure a connection to an MME and S-GW, configure the Carrier settings and add the radios and sectors, but this will get you to the stage where you no longer need to plug directly into the eNB to configure it.

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

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”,

BKP CFGFILE: ENCRYPTMODE=UNENCRYPTED, BL="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,

Connecting to a Huawei BTS3900

Meta: This post is a series chronicling my adventures with a second hand Huawei BTS3900 I purchased. You can find an index of these posts here.

So you purchased a used Macro base station online, good for you.

Now you need to know how to configure it.

First things first, you’ll need to connect to the MPT card – Main Processing & Transmission,

Chances are you’ll have a LMPT (LTE Main Processing & Transmission) or UMPT (Universal Main Processing & Transmission) card.

Set your Ethernet adaptor’s IP to 192.168.0.50/24,

If you’ve got a LMPT card you plug into the ETH port, and then browse to 192.168.0.49, to hit the WebLMT interface.

If you’ve got a UMPT card, you’d need to connect a USB-NIC to the USB port.

And presto, we can reach the WebLMT interface;

I’ve found Firefox on Linux works OK – some functions don’t work, but a VM running IE and Java 7 does the trick just fine.

Huawei BBU (Baseband Unit) for LTE/UMTS/GSM also known as the BTS 3900 / BBU 3900

My used Huawei BTS3900 LTE RAN Adventure – The Impulse Purchase

Meta: The Australian government made up it’s mind some time ago that Huawei would be blacklisted from providing equipment for 5G networks.
Several other countries have adopted the same policy in regards, and as such, deployed Huawei tech is being replaced, and some of it filters down to online auction sites…

So I kind of purchased an item described as “Huawei BBU3900” with a handful of unknown cards and 2 LRFU units, for just over $100.

My current lab setup is a single commercial picocell and a draw of SDR hardware that works with mixed results, so the idea of having a commercial macro cell to play with seemed like a great idea, I put lowball offer in and the seller accepted.

Now would be a good time to point out I don’t know much about RAN and it’s been a long time since I’ve been working on power systems, so this is shaping up to be a fun project.

I did a Huawei RAN course years ago and remembered the rough ingredients required for LTE:

  1. You needed either RRUs (Remote Radio Units) or RFUs (Radio Frequency Units) to handle the RF side of things.
    RRUs are designed for outdoor use (such as mounting on the tower) and RFUs are designed for indoor use, like mounting in a cabinet.
    I’ve ended up with two LRFUe units, which I can join together for 2x MIMO, operate on Band 28 and can put out a whopping 80W of transmit power, yes I’m going to need some big attenuators…
  2. You need a Baseband Processor card to tell the Radio units what do do.
    The card connects the CPRIs (Typically optic fiber links) between the radio units and the baseband.
    The chassis I purchased came with a stack of WBBP (For WCDMA) cards and a single LBBP card for LTE. The LBBP card has 6 SFP ports for the CPRI interfaces, which is more than enough for my little lab. (You can also daisy-chain CPRIs so I’m not even limited to 6 Radio Units.)
  3. You need a backplane and a place for the cards to live – this is the BBU3900 chassis. It’s got basic switching to allow communication between cards, a chassis to distribute power and cooling.
    (Unlike the Ericson units there is actually a backplane for communications in the Huawei chassis – the Ericsson RBS series has is just power and cooling in the chassis)
  4. Optional – Dedicated transmission card, I’ve ended up with a Universal Transmission Processor (UTRP9) with 2x Gig Ethernet and 2x Fast Ethernet ports for transmission. This will only work for GSM and UMTS though, not LTE, so not much use for me.
  5. You need something to handle main processing (LTE / Universal Main Processing and Transmission Unit (LMPT / UMPT)).
    Unfortunately the unit I’ve ended up with only came with a WMPT (For WCDMA), so back online to find either an LMPT (LTE) or UMPT (Universal (2G/3G/4G))…
  6. You need a Universal Power and Environment Module (UPEU) to power up the chassis and handle external IO for things like temperature alarms, door sensors and fire detectors. This chassis has two for redundancy / extra IO & extra power capacity.

So in order to get this running I still need quite a few components:

  • Attenuators – I’ll be able to turn the power down, sure, but not to the levels required to be legal.
  • Antennas – These are FDD units, so I’ll need two antennas for each RFU, on Band 28
  • Feeder Cables – To connect the antennas
  • SMF cables and SFPs – I’ve got a pile in my toolbox, but I’ll need to work out what’s supported by these units
  • A big -48vDC rectifier (I got the BBU3900 unit powered up with an existing supply I had, but I’m going to need something bigger for the power hungry RFUs)
  • DC Distribution Unit – Something to split the DC between the RFUs and the BBU, and protect against overload / short
  • USB-Network adapter – For OAM access to the unit – Found these cheaply online and got one on the way
  • The LTE Main Processing & Transmission (LMPT) card – Ordered a second hand one from another seller

I powered up the BTA3900 and sniffed the traffic, and can see it trying to reach an RNC.

Unfortunately with no open source RNC options I won’t be posting much on the topic of UMTS or getting the UMTS/WCDMA side of things on the air anytime soon…

So that’s the start of the adventure.

I don’t know if I’ll get this all working, but I’m learning a lot in the process, and that’s all that really matters…

Note: I think this is the course I did from Huawei on the BBU3900…

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.

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.

GSM base Station

GSM with Osmocom Part 2: BTS Basics

By far the most visable part of any mobile network (apart from your phone!) is the Base (Transciver) Stations.

Dotted around the countryside, on masts, towers and monopoles, whether you notice them or not, base stations are everywhere.

The Architecture

The RF side of LTE has an eNodeB, which is a smart device. – You connect it to a TCP/IP network, it establishes a connection with your MME(s) and away you go.

A GSM BTS (Base Transceiver Station) isn’t all that clever…

The BTS is a similar to the WiFi access points that talk to a centralised controller for all their thinking.
A BTS gets most of its brains from elsewhere and essentially just handles the TX/RX of baseband data.

That elsewhere is the BSC – Base Station Controller. Each BTS connects to a BSC, and a BSC would typically control a number of BTS.

We’ll explore the BSC and it’s connections in depth, but I’ve put together a basic diagram of how everything fits together below.

Basic GSM Access Architecture

Um Interface

The Um interface is the Air Interface of GSM. It’s what takes the data and sends it out “over the air”.

There’s a lot to know about air interfaces, and I know very little. What I do know is I need to set the Um interface to use a frequency band my mobile phone supports (so I can see and connect to the network).

The Abis Interface

The fact that GSM was first deployed in 1991, explains why the Abis interface used ISDN E1/T1 TDM links to connect the Base Transceiver Stations (BTSs) to the Base Station Controller (BSC).

While now looking back you may ask why TCP/IP wasn’t used for the Abis interface, keep in mind that Windows 95 was the first version to include TCP/IP support, and that gives you an idea of the state of play. ISDN is very reliable and was well known in the telco space at that time.

I no longer have any ISDN hardware, so for me this is all going to be built using packet switched networks working as circuit switched.

Osmocom does have support for E1/T1 interfaces, so if you’ve got BTS hardware that only communicates over TDM links, that’s an option too.

GSMA never wrote a standard for taking Abis over IP, so as such each vendor has implemented it differently.

Osmocom have a flavour of Abis over IP protocol they’ve developed based on traces from a commercial implementation which we’ll be using. You can find the full protocol spec for Osmocom’s Abis over IP interface here.

OML Interface

With all the brains for the BTS residing in the BSC, there’s a need to control the BTS from the BSC. The Operation and Maintenance Link (OML) is a protocol for changing certain parameters of the BTS from the BSC.

A prime example of use of the OML would be the BSC turning the BTS off/on.

We’ll see a tiny bit of OML usage in the next post, just for turning the BTS off and on.

So let’s put this into practice and setup a virtual BTS with Osmocom.