Project

General

Profile

NanoBTS » History » Version 7

laforge, 02/19/2016 10:48 PM
instructions on how to set OML ip and unit id

1 1 laforge
The ip.access nanoBTS are small BTS with an A-bis over IP interface.  RSL and OML are encapsulated in a single TCP session, whereas the TRAU frames on the actual TCH seem to be inside RTP/UDP.
2
3 6 laforge
== Deploying a new nanoBTS ==
4
5
The unconfigured ip.access nanoBTS needs to be configured as follows
6
 * The BTS is configued to automatically obtain an IP address via DHCP
7
 * The BTS is listening on UDP port 3006 for broadcast packets (e.g. should be found by ipaccess-find)
8
  * a typical response by ipaccess-find will be
9
{{{
10
Trying to find ip.access BTS by broadcast UDP...
11 7 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'  
12 6 laforge
}}}
13
 * The BTS is listening on TCP port 3006 for incoming Abis-over-IP connections
14 1 laforge
 * The BTS has an unconfigured Unit ID (65535/0/0) and will refuse to work until a Unit ID has been set
15 7 laforge
 * You can set the Unit ID and OML IP using ipaccess-config as follows:
16
{{{
17
$ ./ipaccess-config -u 1801/0/0 -o 192.168.100.11 -r 192.168.100.122
18
ipaccess-config (C) 2009 by Harald Welte
19
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
20
21
Trying to connect to ip.access BTS ...
22
OML link established
23
setting Unit ID to '1801/0/0'
24
setting primary OML link IP to '192.168.100.11'
25
restarting BTS
26
Thu Apr 30 18:18:48 2009 <0020> abis_nm.c:2016 IPACCESS(0xf0): SET NVATTR ACK
27
Thu Apr 30 18:18:48 2009 <0020> abis_nm.c:2016 IPACCESS(0xf0): SET NVATTR ACK
28
}}}
29
 * 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)
30
{{{
31
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
32
}}}
33 6 laforge
34 1 laforge
== A-bis over IP protocol ==
35
36
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.
37 2 laforge
38 1 laforge
=== Common Header ===
39
40 2 laforge
Inside the TCP and UDP packets connection, every message is prefixed by a three-byte header:
41 1 laforge
{{{
42
struct ipaccess_head {
43
        u_int8_t zero;
44
        u_int8_t len;
45
        u_int8_t proto;
46
} __attribute__ ((packed));
47
}}}
48
49
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:
50
51
 * 0x00 RSL messages as per GSM 08.58
52
 * 0xfe ip.access specific messages
53
 * 0xff OML messages as per GSM 12.21
54
55
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):
56
 * 0x00 PING (from BTS to BSC)
57
 * 0x01 PONG (from BSC to BTS), indicates that the link is still alive
58
 * 0x04 Identity Get (from BSC to BTS)
59
 * 0x05 Identity Response (from BTS to BSC)
60
 * 0x06 Identity confirm (both ways, BTS->BSC is a request, BSC->BTS is acknowledgement)
61 2 laforge
62
=== OML Signalling Link ===
63
64
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.
65
66
==== vendor-specific OML messages ====
67
68
vendor-specific OML messages use a specific format but are closely following the spirit of GSM TS 12.21.
69
70
Look at the ''abis_nm_ipaccess_msg()'' function in ''abis_nm.c'' if you want to know the details.
71
72
=== RSL Signalling Link ===
73
74
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).
75
76
After this command is issued (and acknowledged by 0xe1), the BTS will initiate a TCP connection to the specified TCP port.
77 1 laforge
78 3 laforge
==== vendor-specific RSL messages ====
79
80
There are a couple of vendor-specific RSL messages extending 08.58 to accommodate the IP-based link.
81
82
They all use the GSM 08.85 message discriminator 0x7e
83
84
===== 0x70 BIND =====
85
86
This command binds a given on-air timeslot to a BTS-local RTP port.
87
88
Attributes:
89
 * 0x01 GSM 08.58 Channel Number (same as BIND)
90
91
===== 0x71 BIND ACK =====
92
93
This message (BTS->BSC) acknowledges the BTS-local bind.
94
95
Attributes:
96
 * 0x01 GSM 08.58 Channel Number (same as BIND)
97
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
98
 * 0xf3 local RTP port number, fixed length 2 bytes
99
 * 0xf5 local IP address, fixed length 4 bytes
100
 * 0xfc unknown, fixed length 1 byte, content 0x7f
101
102
===== 0x73 CONNECT =====
103
104
This command (BSC->BTS) instructs the BTS to connect a given GSM channel (timeslot) to the remote end
105
106
Attributes:
107
 * 0x01 GSM 08.58 Channel Number (on-air timeslot)
108
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
109
 * 0xf0 remote IP address, fixed length 4 bytes
110
 * 0xf1 remote RTP port number, fixed length 2 bytes
111
 * 0xf4 unknown, fixed length 1 byte, content 0x01
112
 * 0xfc unknown, fixed length 1 byte, content 0x7f
113
114
===== 0x74 CONNECT ACK =====
115
116
This message (BTS->BCS) confirms the successful CONNECT operation
117
118
Attributes:
119
 * 0x01 GSM 08.58 Channel Number (on-air timeslot)
120
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
121
122
===== 0x76 DISCONNECT INDICATION =====
123
124
This message (BTS->BSC) indicates a terminated RTP connection
125
126
Attributes:
127
 * 0x01 GSM 08.58 Channel Number (on-air timeslot)
128
 * 0xf8 unknown, maybe something like local RTP instance number, fixed length two bytes.
129
 * 0xf6 unknown, TLV with one byte length, content zero
130
 * 0x1a GSM 08.58 Cause
131
132
133 1 laforge
=== TRAU link ===
134
135
Not yet reverse engineered.
136 4 laforge
137 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.
138
139
There are also regular RTCP packets on the port number plus 1.
140
141
==== RTP ====
142
143
The packets are according to RFC1889 (RTP Version 2), the payload type is set to 127, which is a dynamically allocated payload type.
144
145
They have sequence number and timestamp as well as 31 bytes of payload.  It seems the payload first 4 bits are always 0xC, reducing
146
the actual payload to 30.5 bytes.  A EFR/FR speech frame consists of 32.5 bytes, however.
147
148
Any additional information about the content/encoding of the payload would be appreciated.
149
150
==== RTCP ====
151
152
It seems that about every 3 seconds there is a RTCP packet, containing a source description and sender report.
153
154 4 laforge
== Wireshark dissector ==
155
156
We have developed a dissector for the popular wireshark network protocol analyzer.   The patch can be found at this location in our svn: http://bs11-abis.gnumonks.org/trac/browser/trunk/wireshark/abisip.patch
157 5 laforge
158
Furthermore, there is a patch for adding the ip.access specific RSL extensions to the packet-rsl.c dissector at http://bs11-abis.gnumonks.org/trac/browser/trunk/wireshark/rsl-ipaccess.patch
159 4 laforge
160
Once the code has stabilized more, we plan to submit this for inclusion into wireshark mainline.
Add picture from clipboard (Maximum size: 48.8 MB)