Project

General

Profile

NanoBTS » History » Version 24

Anonymous, 02/19/2016 10:48 PM

1 18 laforge
[[PageOutline]]
2
3 11 laforge
The ip.access nanoBTS are small BTS with an A-bis over IP interface.  It's about the size of a WiFi access point.
4 1 laforge
5
There are multiple variants of the nanoBTS, most notably
6 18 laforge
 * the nanoBTS 900 for GSM900
7
  * supports FR, EFR, AMR(HR) speech codecs
8 11 laforge
  * supports TCH/F and TCH/H based telephony
9
  * supports GPRS
10 18 laforge
 * the nanoBTS 1800 for GSM1800, plus a GSM1900 variant thereof (almost identical hardware)
11 11 laforge
  * they support EDGE in addition to GPRS
12
13 23 laforge
A more detailed list of known nanoBTS models can be found at [wiki:nanoBTS/Models].
14 13 laforge
15 1 laforge
The A-bis over IP interface is spoken over a  100-base-TX Ethernet as physical layer.  Power over Ethernet (PoE) is used as
16 11 laforge
a power supply to the nanoBTS.
17
18
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.
19
20 23 laforge
The OpenBSC project has never received any protocol specification or other detailed information about the [wiki:nanoBTS/Internals nanoBTS hardware].  All information here and in the source code was derived by looking at protocol traces of actual nanoBTS installations.
21 11 laforge
22 6 laforge
== Deploying a new nanoBTS ==
23
24
The unconfigured ip.access nanoBTS needs to be configured as follows
25
 * The BTS is configued to automatically obtain an IP address via DHCP
26
 * The BTS is listening on UDP port 3006 for broadcast packets (e.g. should be found by ipaccess-find)
27
  * a typical response by ipaccess-find will be
28 7 laforge
{{{
29 6 laforge
Trying to find ip.access BTS by broadcast UDP...
30 1 laforge
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'  
31
}}}
32 11 laforge
 * The BTS is listening on TCP port 3006 for incoming Abis-over-IP connections. This is called ''Secondary OML Link''
33 1 laforge
 * The BTS has an unconfigured Unit ID (65535/0/0) and will refuse to work until a Unit ID has been set
34 11 laforge
 * You can set the Unit ID and Primarly OML IP using ipaccess-config as follows:
35 7 laforge
{{{
36
$ ./ipaccess-config -u 1801/0/0 -o 192.168.100.11 -r 192.168.100.122
37
ipaccess-config (C) 2009 by Harald Welte
38
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
39
40
Trying to connect to ip.access BTS ...
41
OML link established
42
setting Unit ID to '1801/0/0'
43
setting primary OML link IP to '192.168.100.11'
44
restarting BTS
45
Thu Apr 30 18:18:48 2009 <0020> abis_nm.c:2016 IPACCESS(0xf0): SET NVATTR ACK
46
Thu Apr 30 18:18:48 2009 <0020> abis_nm.c:2016 IPACCESS(0xf0): SET NVATTR ACK
47
}}}
48 1 laforge
 * 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)
49
{{{
50
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
51
}}}
52
53 18 laforge
=== nanoBTS multi-TRX Setup ===
54
55
The nanoBTS can be operated in so-called ''multi-TRX'' mode, where you can run multiple units as multiple transceivers of one
56
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
57
timeslot for BCCH/CCCH, even if it has multiple transceivers.
58
59
To use this mode, a set of special cables are used to connect the nanoBTS stack:
60
 * The TIB cable (two RJ69 plugs with a slight dent milled away), connecting TIB OUT of one BTS with TIB IN of the other
61
 * A RF cable, connecting the AUX plug of one BTS with the hidden connector between the cooling fins on the back
62
63
You can stack a total of up to four nanoBTS this way.
64
65 23 laforge
Please refer to [wiki:nanoBTS/multiTRX] for more instructions.
66 18 laforge
67 1 laforge
== A-bis over IP protocol ==
68
69
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.
70 2 laforge
71 1 laforge
=== Common Header ===
72
73 2 laforge
Inside the TCP and UDP packets connection, every message is prefixed by a three-byte header:
74 1 laforge
{{{
75
struct ipaccess_head {
76 12 tnt
        u_int16_t len; /* network byte order */
77 1 laforge
        u_int8_t proto;
78
} __attribute__ ((packed));
79
}}}
80
81
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:
82
83
 * 0x00 RSL messages as per GSM 08.58
84
 * 0xfe ip.access specific messages
85
 * 0xff OML messages as per GSM 12.21
86
87
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):
88
 * 0x00 PING (from BTS to BSC)
89
 * 0x01 PONG (from BSC to BTS), indicates that the link is still alive
90
 * 0x04 Identity Get (from BSC to BTS)
91
 * 0x05 Identity Response (from BTS to BSC)
92
 * 0x06 Identity confirm (both ways, BTS->BSC is a request, BSC->BTS is acknowledgement)
93 2 laforge
94
=== OML Signalling Link ===
95
96
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.
97
98
==== vendor-specific OML messages ====
99
100
vendor-specific OML messages use a specific format but are closely following the spirit of GSM TS 12.21.
101
102
Look at the ''abis_nm_ipaccess_msg()'' function in ''abis_nm.c'' if you want to know the details.
103
104
=== RSL Signalling Link ===
105
106
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).
107
108
After this command is issued (and acknowledged by 0xe1), the BTS will initiate a TCP connection to the specified TCP port.
109 1 laforge
110 3 laforge
==== vendor-specific RSL messages ====
111
112
There are a couple of vendor-specific RSL messages extending 08.58 to accommodate the IP-based link.
113
114
They all use the GSM 08.85 message discriminator 0x7e
115
116 15 laforge
===== 0x70 Create Connection (CRCX in MGCP terms) =====
117 3 laforge
118
This command binds a given on-air timeslot to a BTS-local RTP port.
119
120
Attributes:
121
 * 0x01 GSM 08.58 Channel Number (same as BIND)
122
123 15 laforge
===== 0x71 Create Connection (CRCX in MGCP terms) ACK =====
124 3 laforge
125
This message (BTS->BSC) acknowledges the BTS-local bind.
126
127
Attributes:
128
 * 0x01 GSM 08.58 Channel Number (same as BIND)
129
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
130
 * 0xf3 local RTP port number, fixed length 2 bytes
131
 * 0xf5 local IP address, fixed length 4 bytes
132 23 laforge
 * 0xfc RTP payload type, 1 byte, content 0x7f
133 3 laforge
134 15 laforge
===== 0x73 Modify Connection (MDCX in MGCP terms) =====
135 3 laforge
136
This command (BSC->BTS) instructs the BTS to connect a given GSM channel (timeslot) to the remote end
137
138
Attributes:
139
 * 0x01 GSM 08.58 Channel Number (on-air timeslot)
140
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
141
 * 0xf0 remote IP address, fixed length 4 bytes
142
 * 0xf1 remote RTP port number, fixed length 2 bytes
143 23 laforge
 * 0xf4 speech mode, fixed length 1 byte, content 0x01
144
 * 0xfc RTP payload type, fixed length 1 byte, content 0x7f
145 3 laforge
146 15 laforge
===== 0x74 Modify Connection (MDCX in MGCP terms) ACK =====
147 3 laforge
148
This message (BTS->BCS) confirms the successful CONNECT operation
149
150
Attributes:
151
 * 0x01 GSM 08.58 Channel Number (on-air timeslot)
152
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
153
154
===== 0x76 DISCONNECT INDICATION =====
155
156
This message (BTS->BSC) indicates a terminated RTP connection
157
158
Attributes:
159
 * 0x01 GSM 08.58 Channel Number (on-air timeslot)
160
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
161
 * 0xf6 unknown, TLV with one byte length, content zero
162
 * 0x1a GSM 08.58 Cause
163
164
165 1 laforge
=== TRAU link ===
166
167
Not yet reverse engineered.
168 4 laforge
169 5 laforge
There are streams of RTP-in-UDP packets to the ''remote IP'' and ''remote port'' that were indicated by the ''CONNECT'' message in RSL.
170
171
There are also regular RTCP packets on the port number plus 1.
172
173
==== RTP ====
174
175
The packets are according to RFC1889 (RTP Version 2), the payload type is set to 127, which is a dynamically allocated payload type.
176
177
They have sequence number and timestamp as well as 31 bytes of payload.  It seems the payload first 4 bits are always 0xC, reducing
178 8 laforge
the actual payload to 30.5 bytes.
179 5 laforge
180 8 laforge
As it seems, the FR and EFR RTP payload format follows the specification in section 4.5.8 and 4.5.9 of RFC3551 (
181
see http://www.ietf.org/rfc/rfc3551.txt)
182 5 laforge
==== RTCP ====
183
184
It seems that about every 3 seconds there is a RTCP packet, containing a source description and sender report.
185
186 4 laforge
== Wireshark dissector ==
187
188 10 laforge
We have developed a dissector for the popular wireshark network protocol analyzer.   The dissector has been merged into
189 14 laforge
the current wireshak development versions.
190 5 laforge
191 21 laforge
Furthermore, there is a patch for adding the ip.access specific RSL extensions to the packet-rsl.c dissector at http://openbsc.osmocom.org/trac/browser/wireshark/rsl-ipaccess.patch
192 10 laforge
193 22 laforge
There's also a A-bis OML dissector plugin available from http://openbsc.osmocom.org/trac/browser/wireshark/abis_oml.patch
194 4 laforge
195
Once the code has stabilized more, we plan to submit this for inclusion into wireshark mainline.
196 16 laforge
197
== Firmware Format ==
198
199
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.
200
201
The outer SDP header appears to be
202
{{{
203 17 laforge
struct header1 {
204 16 laforge
    char header[4] = " SDP";
205
    char version[4] = { 0x10, 0x02, 0x0, 0x0 };
206
    u_int32_t total_header_length; // (bigendian)
207
    u_int32_t total_file_length;    // (bigendian)
208
    char string[20]; // up to 20 chars for a string;
209
    ... stuff not yet understood, but it appears to list the compatible bts
210 1 laforge
    ... it also includes a date string (viewable in a hex editor)
211 17 laforge
};
212
}}}
213
214
At the end of the total_header_length there is another " SDP" start with a similar header...
215
216
{{{
217
struct header2 {
218 1 laforge
     char header[4] = " SDP";
219
     char version[4] = { 0x10, 0x20, 0x0, 0x0 };
220
     ... not understood yet...
221
};
222
}}}
223 18 laforge
224
== Telnet Debug Port ==
225
226
When you set the NVRAM flag 0x400 (e.g. using {{{ipaccess-config -n 0x400/0x400 BTS_IP}}}), a special telnet console will
227
be activated on TCP port 3210 of the nanoBTS.
228
229
However, there is some kind of shared-secret challenge-response MD5 authentication required - otherwise the BTS will simply
230
disconnect you after a few seconds.
231
232
We have implemented a modified telnet client to add support for this challenge-response mode, and you can obtain it from
233
{{{
234 24 laforge
git clone git://git.osmocom.org/libtelnet.git
235 18 laforge
}}}
236
237
Simply build this package using normal autotools (it also needs the openssl-devel package for MD5) and type
238
{{{
239
./util/ipaccess-telnet BTS_IP 3210
240
}}}
241
and you are connected to it.
Add picture from clipboard (Maximum size: 48.8 MB)