HSL Femto » History » Version 4
laforge, 02/19/2016 10:47 PM
add notes on RSL TRAU / RTP
1 | 1 | laforge | [[PageOutline]] |
---|---|---|---|
2 | = The HSL 2.75G Femtocell = |
||
3 | |||
4 | The HSL 2.75G Femtocell is a relatively recent product implementing a single-ARFCN BTS with 23dBm maximum output power. |
||
5 | |||
6 | == Hardware == |
||
7 | |||
8 | The hardware seems to be a much more software radio approach than the nanoBTS, which are |
||
9 | built from telephone baseband processors. |
||
10 | |||
11 | * Ti DaVinci TMS320DM6443A (ARM9 CPU + DSP) |
||
12 | * Xilinx Spartan-3A FPGA (XC3SD1800A) |
||
13 | * 128 MByte DDR-2 RAM |
||
14 | * 128 MByte NAND flash |
||
15 | * Realtek RTL8201 Ethernet MAC |
||
16 | * Dual 12-bit 65Ms/sec ADC (ADS5232) |
||
17 | * Dual 14-bit 275Ms/sec DAC (DAC5672) |
||
18 | |||
19 | As you can see, the hardware is _much_ more powerful than you would ever |
||
20 | need for a simple single-ARFCN femtocell. Using the high-speed DAC/ADC, |
||
21 | the combined power of the FPGA (with DSP slices) and DSP, you can probably |
||
22 | expect that they will at least want to do multi-ARFCN (if not 3G) on the |
||
23 | same hardware at some later point. |
||
24 | |||
25 | There's a dedicated [wiki:HSL_Femto/Hardware] page with more details. |
||
26 | |||
27 | == Protocol == |
||
28 | They use an odd down-sized minimalistic dialect of the ip.access Abis/IP. |
||
29 | |||
30 | === ACS === |
||
31 | Prior to connecting to the BSC, the cell downloads its current configuration |
||
32 | via https, using a HTTP POST of its serial number. |
||
33 | |||
34 | === IPA layer === |
||
35 | The IPA multiplex layer does not have PING/PONG keepalives, and it does |
||
36 | not do the ID_GET/ID_RESP/ID_CONF identification with the Unit ID. |
||
37 | Furthermore, both OML and RSL are encapsulated in the same TCP connection. |
||
38 | |||
39 | Stream identifier 0xDD is used for passing string debug messages from the |
||
40 | BTS to the BSC. |
||
41 | |||
42 | Neither OML nor RSL are implemented fully, as per 12.21 / 08.58 |
||
43 | |||
44 | === RSL === |
||
45 | It seems to have a very 'creative' interpretation of the RSL specification. Some |
||
46 | examples: |
||
47 | * use of SACCH INFO MODIFY instead of SACCH FILLING for default SI5/SI6 |
||
48 | * it forgets to send RSL CHAN REL ACK on TS1...7 |
||
49 | * it does not implement RSL CHAN MODIFY |
||
50 | * it seems to be unable to run without DTX |
||
51 | * it often detects RACH requests where there are none (!) |
||
52 | |||
53 | === OML === |
||
54 | OML is almost not present at all. Only software download and setting of |
||
55 | ARFCN + BSIC are supported. No managed objects, no state transitions, no |
||
56 | software activation procedures/events at all. |
||
57 | |||
58 | The configuration of each timeslot seems to happen 'on demand', i.e. |
||
59 | there are no OML commands to configure the timeslots, but it depends on your |
||
60 | RSL CHAN ACT whether a timeslot will become a TCH/H or TCH/F. |
||
61 | |||
62 | I have not managed to use a SDCCH/8 anywhere, just TCH/F and TCH/H as well as |
||
63 | SDCCH/4. |
||
64 | |||
65 | The BCCH _claims_ to be a Combination 4, but in reality it is a Combination 5 |
||
66 | (i.e. including the SDCCH/4) |
||
67 | |||
68 | 4 | laforge | === RTP === |
69 | There is a proprietary RSL message used to connect the BTS to the TRAU. |
||
70 | |||
71 | Codec data is exchanged by RTP packets exchanged between BTS UDP port 1000 and the |
||
72 | TRAU IP and UDP port. |
||
73 | |||
74 | The CellID is used as SSRC of all RTP packets, enabling the TRAU to distinguish frames |
||
75 | from different cells |
||
76 | |||
77 | If multiple TCH are active, the RTP payload contains the codec frames from all active TCH |
||
78 | channels. The format is like a sequence of elements formatted like this: |
||
79 | * byte 1: RSL Channel number (e.g. 0x09 = TCH/F on TS 1) |
||
80 | * byte 2: length of codec frame (e.g. 0x22 hex for EFR) |
||
81 | * byte 3..length: Codec Data |
||
82 | |||
83 | 1 | laforge | === GPRS === |
84 | GPRS is quiite odd, too. The BSSGP is encapsulated in the RSL L3_INFO_IE, |
||
85 | this means we will have to run a NS link from the BSC to the SGSN, combining |
||
86 | all the BSSGP links from HSL Femtocells to the BSC. |
||
87 | 2 | laforge | |
88 | == Software support == |
||
89 | |||
90 | === wireshark === |
||
91 | |||
92 | We have some wireshark patches for adding HSL RSL/OML support: |
||
93 | * http://cgit.osmocom.org/cgit/openbsc/plain/wireshark/0005-rsl-hsl.patch |
||
94 | * http://cgit.osmocom.org/cgit/openbsc/plain/wireshark/0006-abis_oml-hsl.patch |
||
95 | |||
96 | 3 | laforge | === OpenBSC === |
97 | 2 | laforge | |
98 | OpenBSC support is being worked on in the {{{laforge/hsl}}} branch of openbsc.git: |
||
99 | * http://cgit.osmocom.org/cgit/openbsc/log/?h=laforge/hsl |