Project

General

Profile

Actions
History

OsmoBSC » BTS Hardware »

The ip.access nanoBTS are small BTS with an A-bis over IP interface. It's about the size of a WiFi access point.

There are multiple variants of the nanoBTS, most notably
  • the nanoBTS 900 for GSM900
    • supports FR, EFR, AMR speech codecs
    • supports TCH/F and TCH/H based telephony
    • supports GPRS
  • the nanoBTS 1800 for GSM1800, plus a GSM1900 variant thereof (almost identical hardware)
    • they support EDGE in addition to GPRS

A more detailed list of known nanoBTS models can be found at nanoBTSModels.

The A-bis over IP interface is spoken over a 100-base-TX Ethernet as physical layer. Power over Ethernet (PoE) is used as
a power supply to the nanoBTS.

A-bis RSL and OML are encapsulated by a small additional header; each run in their own TCP session. Instead of A-bis TRAU frames, the actual TCH speech data is inside RTP/UDP. Details are indicated below.

The OpenBSC project has never received any protocol specification or other detailed information about the nanoBTS hardware. All information here and in the source code was derived by looking at protocol traces of actual nanoBTS installations.

Deploying a new nanoBTS

The unconfigured ip.access nanoBTS needs to be configured as follows
  • The BTS is configued to automatically obtain an IP address via DHCP
  • The BTS is listening on UDP port 3006 for broadcast packets (e.g. should be found by abisip-find)
    • a typical response by abisip-find will be
      Trying to find ip.access BTS by broadcast UDP...
MAC Address='00:01:02:03:04:05'  IP Address='192.168.100.123'  Unit ID='65535/0/0'  Location 1=_  Location 2='BTS_NBT131G'  Equipment Version='165a029_55'  Software Version='168a302_v142b13d0'  Unit Name='nbts-00-02-95-00-4E-B3'  Serial Number='00123456'
  • The BTS is listening on TCP port 3006 for incoming Abis-over-IP connections. This is called Secondary OML Link
  • The BTS has an unconfigured Unit ID (65535/0/0) and will refuse to work until a Unit ID has been set
  • You can set the Unit ID and Primarly OML IP using ipaccess-config as follows:
    Remark: Setting both unit ID and OML IP at once is known to not work reliably on some firmwares. It is advised to first set up Unit ID, then set OML IP & restart.
$ ./ipaccess-config -u 1801/0/0 -o 192.168.100.11 -r 192.168.100.122
ipaccess-config (C) 2009 by Harald Welte
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY

Trying to connect to ip.access BTS ...
OML link established
setting Unit ID to '1801/0/0'
setting primary OML link IP to '192.168.100.11'
restarting BTS
Thu Apr 30 18:18:48 2009 <0020> abis_nm.c:2016 IPACCESS(0xf0): SET NVATTR ACK
Thu Apr 30 18:18:48 2009 <0020> abis_nm.c:2016 IPACCESS(0xf0): SET NVATTR ACK
  • Once a Unit ID and the Primary OML link IP address has been set, the BTS will try to connect to the BSC (tcp port 3002)
    18:22:49.801584 IP 192.168.100.122.48000 > 192.168.100.11.3002: Flags [S], seq 3405259716, win 16000, options [mss 1460], length 0

nanoBTS multi-TRX Setup

The nanoBTS can be operated in so-called multi-TRX mode, where you can run multiple units as multiple transceivers of one
BTS instead of each unit being a BTS in itself. The advantage of this is that you save capacity, as every BTS only needs one
timeslot for BCCH/CCCH, even if it has multiple transceivers.

To use this mode, a set of special cables are used to connect the nanoBTS stack:
  • The TIB cable (two RJ69 plugs with a slight dent milled away), connecting TIB OUT of one BTS with TIB IN of the other
  • A RF cable, connecting the AUX plug of one BTS with the hidden connector between the cooling fins on the back

You can stack a total of up to four nanoBTS this way.

Please refer to nanoBTSmultiTRX for more instructions.

A-bis over IP protocol

This is the description of the A-bis over IP protocol as we have reverse engineered it by looking at protocol traces between a commercial BSC and a nanoBTS. We did not and do not have access to the protocol specification of ip.access.

Common Header

Inside the TCP and UDP packets connection, every message is prefixed by a three-byte header:

struct ipaccess_head {
        u_int16_t len; /* network byte order */
        u_int8_t proto;
} +attribute+ ((packed));

where the first byte is zero, the second byte indicates the length of the message payload following the header, and the third byte indicates the protocol. The following protocol values have been observed:

  • 0x00 RSL messages as per GSM 08.58
  • 0xfe ip.access specific messages
  • 0xff OML messages as per GSM 12.21
The ip.access specific messages that we have seen are of the following message types (message type is the first byte behind the ipaccess_head):
  • 0x00 PING (from BTS to BSC)
  • 0x01 PONG (from BSC to BTS), indicates that the link is still alive
  • 0x04 Identity Get (from BSC to BTS)
  • 0x05 Identity Response (from BTS to BSC)
  • 0x06 Identity confirm (both ways, BTS->BSC is a request, BSC->BTS is acknowledgement)

OML Signalling Link

After obtaining an IP address from DHCP, the nanoBTS will attempt to make TCP connections to a IP address and port number pre-configured in the device. The standard port seems to be 3002.

vendor-specific OML messages

vendor-specific OML messages use a specific format but are closely following the spirit of GSM TS 12.21.

Look at the abis_nm_ipaccess_msg() function in abis_nm.c if you want to know the details.

RSL Signalling Link

There is a vendor-specific OML command 0xe0, which basically corresponds to what the usual Connect Terrestrial Signalling does. Instead of connecting te RSL link to a specific TEI on a E1 timeslot, it connects the RSL link to a specified TCP port (and optionally IP address).

After this command is issued (and acknowledged by 0xe1), the BTS will initiate a TCP connection to the specified TCP port.

vendor-specific RSL messages

There are a couple of vendor-specific RSL messages extending 08.58 to accommodate the IP-based link.

They all use the GSM 08.85 message discriminator 0x7e

0x70 Create Connection (CRCX in MGCP terms)

This command binds a given on-air timeslot to a BTS-local RTP port.

Attributes:
  • 0x01 GSM 08.58 Channel Number (same as BIND)
0x71 Create Connection (CRCX in MGCP terms) ACK

This message (BTS->BSC) acknowledges the BTS-local bind.

Attributes:
  • 0x01 GSM 08.58 Channel Number (same as BIND)
  • 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
  • 0xf3 local RTP port number, fixed length 2 bytes
  • 0xf5 local IP address, fixed length 4 bytes
  • 0xfc RTP payload type, 1 byte, content 0x7f
0x73 Modify Connection (MDCX in MGCP terms)

This command (BSC->BTS) instructs the BTS to connect a given GSM channel (timeslot) to the remote end

Attributes:
  • 0x01 GSM 08.58 Channel Number (on-air timeslot)
  • 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
  • 0xf0 remote IP address, fixed length 4 bytes
  • 0xf1 remote RTP port number, fixed length 2 bytes
  • 0xf4 speech mode, fixed length 1 byte, content 0x01
  • 0xfc RTP payload type, fixed length 1 byte, content 0x7f
0x74 Modify Connection (MDCX in MGCP terms) ACK

This message (BTS->BCS) confirms the successful CONNECT operation

Attributes:
  • 0x01 GSM 08.58 Channel Number (on-air timeslot)
  • 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
0x76 DISCONNECT INDICATION

This message (BTS->BSC) indicates a terminated RTP connection

Attributes:
  • 0x01 GSM 08.58 Channel Number (on-air timeslot)
  • 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
  • 0xf6 unknown, TLV with one byte length, content zero
  • 0x1a GSM 08.58 Cause

TRAU link

Not yet reverse engineered.

There are streams of RTP-in-UDP packets to the remote IP and remote port that were indicated by the CONNECT message in RSL.

There are also regular RTCP packets on the port number plus 1.

RTP

The packets are according to RFC1889 (RTP Version 2), the payload type is set to 127, which is a dynamically allocated payload type.

They have sequence number and timestamp as well as 31 bytes of payload. It seems the payload first 4 bits are always 0xC, reducing
the actual payload to 30.5 bytes.

As it seems, the FR and EFR RTP payload format follows the specification in section 4.5.8 and 4.5.9 of RFC3551 (
see http://www.ietf.org/rfc/rfc3551.txt)

RTCP

It seems that about every 3 seconds there is a RTCP packet, containing a source description and sender report.

Wireshark dissector

We have developed a dissector for the popular wireshark network protocol analyzer. The dissector has been merged into
wireshark and is available in the stable version. Depending on the version of wireshark the dissector is either called
rsl (version <= 1.8) or gsm_abis_rsl (version >= 1.9). To look at ip.access specific RSL extensions you will
need to enable them in the RSL protocol preference.

Firmware Format

The file format is called "SDP" and it is a container that contain other SDP parts. To my knowledge the separate subparts are for separate functionality (e.g. bootcode) and for the different ProcessingUnits. It appears that only the first SDP header is stripped and that the remain is sent as one part to the BTS.

The outer SDP header appears to be

struct header1 {
    char headerr4 = " SDP";
    char versionr4 = { 0x10, 0x02, 0x0, 0x0 };
    u_int32_t total_header_length; // (bigendian)
    u_int32_t total_file_length;    // (bigendian)
    char stringr20; // up to 20 chars for a string;
    ... stuff not yet understood, but it appears to list the compatible bts
    ... it also includes a date string (viewable in a hex editor)
};

At the end of the total_header_length there is another " SDP" start with a similar header...

struct header2 {
     char headerr4 = " SDP";
     char versionr4 = { 0x10, 0x20, 0x0, 0x0 };
     ... not understood yet...
};

Telnet Debug Port

be activated on TCP port 3210 of the nanoBTS.

However, there is some kind of shared-secret challenge-response MD5 authentication required - otherwise the BTS will simply
disconnect you after a few seconds.

We have implemented a modified telnet client to add support for this challenge-response mode, and you can obtain it from

git clone git://git.osmocom.org/libtelnet.git

Simply build this package using normal autotools (it also needs the openssl-devel package for MD5) and type

./util/ipaccess-telnet BTS_IP 3210

and you are connected to it.

Navigation

Once you're connected, you'll see the copyright statement and the command prompt:

nanoBTS (c) ip.access Ltd 2001

>help
>
CLI Categories:

CONFIG      - Configuration commands
DANGER      - Commands which can render the BTS unusable
DEV         - Development commands
DIAG        - Diagnostic commands
FTT         - Factory Test commands
DEPPRECATED - Commands that are currently valid
              but will be removed in future releases

Each of these categories groups a set of commands, you can list them:

>help CONFIG
...
>help DEV
...

All commands regardless of the CLI categories belong to namespaces:

>namespace
There are 28 CLI namespaces registered:
 rm::
 genie::
 spirit::
...

so you must enter them together with the namespace prefix.

It's also possible to list commands by namespaces, for example:

>help rm::*

More detailed information is available for some commands, for example:

>help fpgatrace
>
fpgatrace                [<on|off> [module]]           Turn on/off FPGA tracing.

DSP specific commands

The DSP has its own set of commands, they need to be prefixed with 'dsp':

>dsp help
CLI Categories:

CONFIG      - Configuration commands
DANGER      - Commands which can render the BTS unusable
DEV         - Development commands
DIAG        - Diagnostic commands
FTT         - Factory Test commands
DEPPRECATED - Commands that are currently valid
              but will be removed in future releases

>dsp namespace
There are 10 CLI namespaces registered:
 [::]    (global namespace)
 [::]    (global namespace)
 lme::
 l3::
 l2::
 l1::
 amr::
 ti::
 spool::
 hpi::

>dsp help l3::*
l3::mpp                  [<chan>]                      Monitor Meas. Pre-Proc
l3::info                                               Display L3 info
l3::chaninfo             <ts> <sc> [q]                 Display L3 subchan info
l3::mpp3g                [<chan><mode>]                Monitor/check 3g MPP
l3::cbsdebug             <debug flags>                 Sets cellbcast dbg flags in HEX

>dsp help l2::*
l2::info                                               Display L2 info
l2::sysinfo                                            Display L2 SysInfo messages

Useful commands

  • links::info - show the OML/IML/RSL connections
  • im::info - show Managed Objects (Site Manager, BTS, Baseband Transceiver)
  • rsl::sysinfo - show received System Information messages
  • snmp::enable, snmp::disable - enable / disable SNMP
  • snmp::info - show SNMP configuration info
  • sendpagecmd, sendimmass - send arbitrary Paging / Immediate Assignment

Other interesting commands

  • rm::interference - Uplink/Downlink interference simulation for (E)GPRS
  • rsl::intercept - Unlawful intercept?!?

Firmware information:

>dir
RegionType Index TextDesc                   Date       Time  PartNum Version
----------|-----|--------------------------|----------|-----|-------|----------
Backhaul  |  0  |EDGE[Enc:A5/1,A5/2]       |28/05/08  |11:27|168a302|v142b13d0
Backhaul  |  1  |EDGE[Enc:A5/1,A5/2]       |28/05/08  |11:27|168a302|v142b13d0
TRX       |  0  |EDGE[Enc:A5/1,A5/2]       |28/05/08  |11:27|168a301|v142b13d0
TRX       |  1  |EDGE[Enc:A5/1,A5/2]       |28/05/08  |11:27|168a301|v142b13d0
BootCode  |  0  |EDGE[Enc:A5/1,A5/2]       |          |     |168a304|v142b13d0

Debug tracing

  • dbgcontrol on/off - turn global debug control on/off
  • rm::debug on/off [CATEGORY] - enable/disable PCU/GPRS related logging
< EGPRS Packet Downlink Ack/Nack >
        < DOWNLINK_TFI : bit(5) = 61 >
        < MS OUT OF MEMORY : bit(1) = 0 >
>       { 1      -- EGPRS Channel Quality Report
                < EGPRS BEP Link Quality Measurements IE >
                        { 1 < GMSK_MEAN_BEP: bit(5) = 6 >
                            < GMSK_CV_BEP: bit(3) = 7 > }
>                       { 0 }    -- No 8PSK BEP
                < C_VALUE: bit(6) = 63 >
                < EGPRS Timeslot Link Quality Measurements IE > ::=
>                       { 1      -- BEP_MEASUREMENTS
                                { 0 }
                                { 0 }
                                { 0 }
                                { 0 }
                                { 0 }
                                { 0 }
                                { 1 { 0 < GMSK_MEAN_BEP_TS6: bit(4) = 1 > } }
                                { 1 { 0 < GMSK_MEAN_BEP_TS7: bit(4) = 15 > } }
>                       { 0 } }  -- No INTERFERENCE_MEASUREMENTS
>       { 0 }    -- No Channel Request Description
>       { 0 }    -- No PFI
        { 0 }    -- No Extension bits
        < EGPRS Ack/Nack Description >
                1 < Length L: bit(8) = 15 >
>                       < FAI: bit(1) = 0 >
                        < BOW: bit(1) = 1 >
                        < EOW: bit(1) = 1 >
                        < SSN: bit(11) = 1909 >
>                       { 0 }   -- No Compressed bitmap
                        < URBB: bit(0) = 0x00000000 00000000 00000000 00000000 00000000 > }

Reset procedure

Kevin Redon described on the openBSC mailinglist how to hard reset a nanoBTS after forgetting a statically assigned IP address.
After the reset the nanoBTS will again request the network settings via DHCP.

  • power off the nanoBTS
  • short the pin 9+10 on the TIB+IN port (the one farest away from TIB+OUT). You could use a 10P10C connector (RJ50/RJ69). I used a small flat screwdriver.
  • power on the nanoBTS. The boot (LED on RED) will take longer then usual. At the end the LED will blink RED rapidly
  • power off the nanoBTS
  • remove the short from TIB+IN
  • power up the nanoBTS
  • it will be reseted (the LED will first be RED will booting, then blink red/green to tell that the UID has not been set

Updated by fixeria over 1 year ago · 38 revisions

Add picture from clipboard (Maximum size: 48.8 MB)