Project

General

Profile

NanoBTS » History » Version 30

pespin, 07/26/2018 10:40 AM

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