Project

General

Profile

HSL Femto » History » Version 7

laforge, 02/19/2016 10:47 PM
add note about behavior of vendor

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