8 Feb
2011
8 Feb
'11
7:02 p.m.
Hi all,
Some people have been working together in order to finally start with
support of the Ericsson RBS2308 (and similar models) in OpenBSC.
The biggest issue so far is bringing up the actualy LAPD on the E1/T1 link.
It seems Ericsson is using some dynamic timeslot configuration between BSC
and BTS, so unlike e.g. Siemens, you cannot explicitly configure the OML E1
timeslot on the BTS using local configuration tools.
The current working assumption is: Somehow the BSC produces bit-patterns on the
E1 link and uses them to let the BTS know where to start LAPD for OML.
One contributor was friendly enough to do raw bit-traces of a Racal 6113
connected to the Ericsson RBS, and they look like this:
Racal to BTS
Initialization
openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
*
00092e0 aaaa aaaa aaaa aaaa aaaa aaaa aaaa 55aa
00092f0 ffff ffff ffff ffff ffff ffff ffff ffff
*
0009600 ffff ffff ffff ffff ffff ffff ffff 7e7e
0009610 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
00096b0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e
00096c0 3e5f 49ce cfef cfcf cfcf cfcf cfcf cfcf
00096d0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*
I've written a small C program to do soft-hdlc decode.
* a pattern of alternating bits (0xaa)
* a pattern of all-1 bits(0xff)
* a sequence of FLAG symbols (01111110)
* a HDLC message FA 7D 7F 4E F2, which is a TEI=62/SAPI=62 SABME
(SAPI 62 / TEI62 is configured for OML on the BTS)
The interesting part is:
1) this is a SABME from BSC to BTS, whereas GSM 08.56
specifically says the BTS is the TE and the BSC the NT
2) we have not seen any TEI manager related messages(L2ML)
Keep alives afterwards, about every 8 seconds
001d5e0 cfcf cfcf cfcf ebcb 04e4 a805 f323 f3f3
001d5f0 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0031630 f3f3 f2f3 f9fa 0101 086a fcfc fcfc fcfc
0031640 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
0045680 fcfc fcfc fcfc fcfc fcfc fcfc bebe 4040
0045690 825a 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
00456a0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
*
00596e0 3f3f 2f3f 90af 1610 8fa0 cfcf cfcf cfcf
00596f0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*
006d730 cfcf cfcf cfcf cfcf cbcf e4eb 0504 23a8
006d740 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0081790 faf2 01f9 6a01 fc08 fcfc fcfc fcfc fcfc
00817a0 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
00957e0 fcfc fcfc fcfc befc 40be 5a40 3f82 3f3f
00957f0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
If you decode this, you get
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 21 AC (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
If we look at the BTS to Racal 6113 side:
Initialization
openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
000fe00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e5e7 f3f5
000fe10 1039 f971 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
000fe20 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*
Keep Alives, every 8 seconds
0023e40 f9f9 f9f9 f9f9 f9f9 f9f9 7c7d 8080 04b5
0023e50 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0037ea0 5f5f 2020 412d 9f1f 9f9f 9f9f 9f9f 9f9f
0037eb0 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
004bef0 9f9f 9f9f 9f9f 9f9f 979f c8d7 0b08 4750
004bf00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
005ff40 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 f5e5
005ff50 02f2 d402 f911 f9f9 f9f9 f9f9 f9f9 f9f9
005ff60 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*
0073fa0 f9f9 f9f9 f9f9 7c7d 8080 04b5 7e7e 7e7e
0073fb0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0087ff0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e 205f
0088000 2d20 1f41 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
0088010 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
009c050 9f9f 9f9f 979f c8d7 0b08 4750 e7e7 e7e7
009c060 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
Decoded, we get:
FA 7D 73 60 3A (LAPD UA)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 25 25 AD 20 (LAPD unknown??)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
So as a summary, it seems that
1) the BSC applies some magic pattern (0xaa / 0xff)
2) the BSC establishes the LAPD session for OML TEI/SAPI
3) there is no L2ML, contrary to lots of Ericsson Abis documentation
that you can find online.
We'll continue our attempts and see if we can get the OML up...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9 Feb
9 Feb
12:19 a.m.
Hi all,
I've connected my 6113 to a DAHDI card in raw mode and sampled the
data, it can be found (together with some tools) in osmo-rbs.git
on git.osmocom.org
To me, it seems as if it simply sending a continuous sequence of SABM
commands for TEI=62/SAPI=62 on timeslot 1, interspaced with idle pattern
of FLAG bytes.
However, if I attempt to send this sequence (using dslot=1, i.e. the HDLC
support within DAHDI) and the rbs_sabm.c program on /dev/dahdi/1), there is no
response from the RBS.
On all other timeslots, the 6113 will just produce a default pattern of
alternating 0 and 1 bits (0xAAAAAAA).
We still must be doing something wrong here...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
12:54 a.m.
One thing I noticed in your sample program is the size of the frame
you're sending to DAHDI. Try adding 2 to the size parameter when you
write() on the device (assuming you're still using dahdi HDLC).
Also, you must append 2 empty bytes to the frame you write down to the
DAHDI dchan as a placeholder for the CRC.
So change:
-const uint8_t sabme_frame_nonraw[] = { 0xFA, 0x7D, 0x7F };
to:
+const uint8_t sabme_frame_nonraw[] = { 0xFA, 0x7D, 0x7F, 0x00, 0x00 };
And that should take care of both things I mentioned above.
Be warned though, a DAHDI channel set to be a "dchan" will send HDLC
idle bit patterns when no data is sent (0x7e) on it. This means that
if you need to send 0xff or 0xaa or some pattern like you posted
above, you will need to use custom HDLC code, or modify the DAHDI hdlc
code to send your required idle pattern.
Matthew Fredrickson
On Tue, Feb 8, 2011 at 5:19 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi all,
I've connected my 6113 to a DAHDI card in raw mode and sampled the
data, it can be found (together with some tools) in osmo-rbs.git
on git.osmocom.org
To me, it seems as if it simply sending a continuous sequence of SABM
commands for TEI=62/SAPI=62 on timeslot 1, interspaced with idle pattern
of FLAG bytes.
However, if I attempt to send this sequence (using dslot=1, i.e. the HDLC
support within DAHDI) and the rbs_sabm.c program on /dev/dahdi/1), there is no
response from the RBS.
On all other timeslots, the 6113 will just produce a default pattern of
alternating 0 and 1 bits (0xAAAAAAA).
We still must be doing something wrong here...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9:25 p.m.
Hi again,
On Tue, Feb 08, 2011 at 05:54:09PM -0600, Matthew Fredrickson wrote:
One thing I noticed in your sample program is the size
of the frame
you're sending to DAHDI. Try adding 2 to the size parameter when you
write() on the device (assuming you're still using dahdi HDLC).
Also, you must append 2 empty bytes to the frame you write down to the
DAHDI dchan as a placeholder for the CRC.
ok, thanks a lot. I've modified the program accordingly. However, still
no success in getting any response from the RBS2308.
On the other hand, on a RBS2401 this works. As soon as you send something
like one SABME per second on timeslot 1, after a couple of seconds the RBS
will start answering using UA and later I-frames.
Now the only mystery remains about the RBS2308.
And somebody (*hint to the list*) will still have to write a OM2000 BSC-side
implementation, basically what we have with abis_nm is for TS 12.21, but for
the proprietary Ericsson OM2000 protocol (details see my wireshark dissector).
But at least for the 2401 we should have all required information now.
Regards,
Harrald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
12:54 a.m.
Is the data dump output from /dev/dahdi/1 the output of a single
timeslot (bchan=1), or this in clear channel mode with all timeslots
bonded together in DAHDI (clear=1-31)?
Matthew Fredrickson
On Tue, Feb 8, 2011 at 12:02 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi all,
Some people have been working together in order to finally start with
support of the Ericsson RBS2308 (and similar models) in OpenBSC.
The biggest issue so far is bringing up the actualy LAPD on the E1/T1 link.
It seems Ericsson is using some dynamic timeslot configuration between BSC
and BTS, so unlike e.g. Siemens, you cannot explicitly configure the OML E1
timeslot on the BTS using local configuration tools.
The current working assumption is: Somehow the BSC produces bit-patterns on the
E1 link and uses them to let the BTS know where to start LAPD for OML.
One contributor was friendly enough to do raw bit-traces of a Racal 6113
connected to the Ericsson RBS, and they look like this:
Racal to BTS
Initialization
openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
*
00092e0 aaaa aaaa aaaa aaaa aaaa aaaa aaaa 55aa
00092f0 ffff ffff ffff ffff ffff ffff ffff ffff
*
0009600 ffff ffff ffff ffff ffff ffff ffff 7e7e
0009610 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
00096b0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e
00096c0 3e5f 49ce cfef cfcf cfcf cfcf cfcf cfcf
00096d0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*
I've written a small C program to do soft-hdlc decode.
* a pattern of alternating bits (0xaa)
* a pattern of all-1 bits(0xff)
* a sequence of FLAG symbols (01111110)
* a HDLC message FA 7D 7F 4E F2, which is a TEI=62/SAPI=62 SABME
(SAPI 62 / TEI62 is configured for OML on the BTS)
The interesting part is:
1) this is a SABME from BSC to BTS, whereas GSM 08.56
specifically says the BTS is the TE and the BSC the NT
2) we have not seen any TEI manager related messages(L2ML)
Keep alives afterwards, about every 8 seconds
001d5e0 cfcf cfcf cfcf ebcb 04e4 a805 f323 f3f3
001d5f0 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0031630 f3f3 f2f3 f9fa 0101 086a fcfc fcfc fcfc
0031640 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
0045680 fcfc fcfc fcfc fcfc fcfc fcfc bebe 4040
0045690 825a 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
00456a0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
*
00596e0 3f3f 2f3f 90af 1610 8fa0 cfcf cfcf cfcf
00596f0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*
006d730 cfcf cfcf cfcf cfcf cbcf e4eb 0504 23a8
006d740 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0081790 faf2 01f9 6a01 fc08 fcfc fcfc fcfc fcfc
00817a0 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
00957e0 fcfc fcfc fcfc befc 40be 5a40 3f82 3f3f
00957f0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
If you decode this, you get
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 21 AC (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
If we look at the BTS to Racal 6113 side:
Initialization
openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
000fe00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e5e7 f3f5
000fe10 1039 f971 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
000fe20 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*
Keep Alives, every 8 seconds
0023e40 f9f9 f9f9 f9f9 f9f9 f9f9 7c7d 8080 04b5
0023e50 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0037ea0 5f5f 2020 412d 9f1f 9f9f 9f9f 9f9f 9f9f
0037eb0 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
004bef0 9f9f 9f9f 9f9f 9f9f 979f c8d7 0b08 4750
004bf00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
005ff40 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 f5e5
005ff50 02f2 d402 f911 f9f9 f9f9 f9f9 f9f9 f9f9
005ff60 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*
0073fa0 f9f9 f9f9 f9f9 7c7d 8080 04b5 7e7e 7e7e
0073fb0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0087ff0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e 205f
0088000 2d20 1f41 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
0088010 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
009c050 9f9f 9f9f 979f c8d7 0b08 4750 e7e7 e7e7
009c060 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
Decoded, we get:
FA 7D 73 60 3A (LAPD UA)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 25 25 AD 20 (LAPD unknown??)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
So as a summary, it seems that
1) the BSC applies some magic pattern (0xaa / 0xff)
2) the BSC establishes the LAPD session for OML TEI/SAPI
3) there is no L2ML, contrary to lots of Ericsson Abis documentation
that you can find online.
We'll continue our attempts and see if we can get the OML up...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:54 a.m.
On Tue, Feb 08, 2011 at 05:54:56PM -0600, Matthew Fredrickson wrote:
Is the data dump output from /dev/dahdi/1 the output
of a single
timeslot (bchan=1), or this in clear channel mode with all timeslots
bonded together in DAHDI (clear=1-31)?
this is bchan=1 output of the single timeslot
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4:29 p.m.
Hi all,
based on some more traces taken from a different Racal 6113 in RBS2000 mode,
there is a consistent observation:
1) the BSC applies some magic pattern (0xaa / 0xff)
2) the BSC establishes the LAPD session for OML TEI/SAPI
3) there is no L2ML, contrary to lots of Ericsson Abis documentation
that you can find online.
The 0xAA /0xFF pattern is only applied once at the very start-up of the
6113. After that, the 6113 loops in sending SABM (SAPI=62/TEI=62)
messages in a lot of 0x7E LAPD idle pattern.
So my assumption is that the initial 0xAA / 0xFF is more like an artefact
of the 6113 starting up or initializing its A-bis timeslots, whereas the
repeated SABM messages are what the BTS/RBS locks onto.
However, using a small demo program (rbs_sabm.c) sending the exact same
SABM messages (utilizing the in-kernel DAHDI HDLC in dslot=1) does not
trigger any response from the RBS. The RBS just simply continues to send
its 0x7F pattern on all timeslots.
The physical connection is definitely fine, i.e. if we enable TNOM on TS 24
of the RBS, we can clearly see valid HDLC traffic on TS24 - but of course
only for this TNOM and not for OML.
Also, if the RBS boots, the 0x7F pattern disappears for some time.
I'm right now really out of ideas. Applying the 0xAA / 0xFF pattern at the
very beginning is difficult using any standard DAHDI/mISDN HDLC implementation,
as you can either switch the line into raw mode and then transmit that pattern,
or switch into d-channel mode where the driver will do the HDLC framing but
generate the default 0x7E idle pattern only. And as indicated, I really don't
believe it will make any difference, as it only happens on 6113 start, but
not during the lopp while it waits for the RBS connection to establish.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
13 Feb
13 Feb
10:16 a.m.
Hi all,
meanwhile some things have happened, so here some update:
1) activating the OML link to the IXU/DXU in the Ericsson BTS works
much more reliably from a Racal 6113 than from our own code sending
a flood of SABME on TS0. This might be DAHDI related.
2) after the BTS has seen SABME for TEI=62/SAPI=62, it will memorize this
and we can switch the cable from the 6113 to our DAHDI+OpenBSC setup
3) The current laforge/rbs2000 branch will establish the primary OML Link
and will start to initialize the CF (central function). After that, you
will have to manually use the telnet interface with a sequence of commands
like this:
enable
bts 0 om2000 class is 0 255 0
connect-command
is-cof-req
enable-request
At this point the TRX0 should be connected to the same signalling slot
and based on the protocol traces I've done between the 6113 and the BTS,
we should now establish a _second_ OML connection, but this time to TEI=0
(SAPI still 62). No code for this exists yet in the laforge/rbs2000 branch.
For some reason the last operation (SABME to SAPI=62/TEI=0) does not work on my
BTS, neither with the Racal 6113 nor from custom code. So I believe something
is wrong with the actual hardware setup...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:34 a.m.
On Sun, Feb 13, 2011 at 10:16:49AM +0100, Harald Welte wrote:
Hi all,
meanwhile some things have happened, so here some update:
1) activating the OML link to the IXU/DXU in the Ericsson BTS works
much more reliably from a Racal 6113 than from our own code sending
a flood of SABME on TS0. This might be DAHDI related.
I have just checked my logs from the MA-10 protocol analyzer. It sends SABME
frames at intervals of 0.3 seconds. If I use the same timing from our
rbs_init.c, I can initialize the A-bis path to the RBS 2308.
Quite strange that apparently 1 second delay is not sufficient, and 50
milliseconds is too often...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3:55 p.m.
Ok guys,
I'm giving up for now, definitely have to take care of more important work
right now :(
The status is as follows:
* You need 'dchan=1,4' in your /etc/dahdi/system.conf
* laforge/rbs2000 has been merged master as it doesn't touch common code
* OpenBSC happily 'initializes' the A-bis link now (IXU OML LAPD+TEI 62)
* The IS MO can (must) be configured manually via the VTY (see last mail)
* SABM on TEI=0/SAPI=62 (TS0) as well as TSI=1/SAPI=62 (TS4) for TRX0
and TRX1 fail. OpenBSC now tries to establish those SAPIs according
to the TRX you configure in openbsc.cfg
* If I configure the IS to route (524,16,4), i.e. connect ICP 524..527 to
ICP 16..19, I get a valid HDLC idle pattern (0x7e) on TS 4, which confirms
the assumption that the ICP assignments are as follows:
ICP 0..3 : E1 Port A TS 1
ICP 4..7 : E1 Port A TS 2
ICP 8..11 : E1 Port A TS 3
ICP 12..15 : E1 Port A TS 4
...
ICP 512..515 : TRX 0 Signalling
ICP 516..519 : TRX 0 Um TS 0..3
ICP 520..523 : TRX 0 Um TS 4..7
ICP 524..527 : TRX 1 Signalling
ICP 528..531 : TRX 1 Um TS 0..3
ICP 532..535 : TRX 1 Um TS 4..7
...
* The DCP numbers referenced in some documents are DCP = ICP / 4
* Further observations:
* Unused traffic slots seem to generate raw bit pattern 0x5555
* Unallocated slots (no assignment in IS) generate raw bit pattern 0x5454
If anyone wants to play with it, feel free to do so. I would definitely
want to know if anyone else gets the SAPI 62 to TRX0 or TRX1 up. As in my
setup not even the Racal 6113 can get that SAPI up, I think I may be facing
soem malfunction/misconfiguration in my RBS.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
14 Feb
14 Feb
5:21 p.m.
Finally,
all problems regarding LAPD and (IS) Interface Switch seem to have been
solved.
Using current openbsc 'master' branch and the openbsc.cfg.rbs2308-4trx
in it, I am able to initialize all 9 LAPD links (1x IXU-OML, 4x TRX-OML,
4x TRX-RSL) to the RBS 2308.
The IS configuration can now be done as part of the BTS configuration in
the OpenBSC VTY. The config file example configures like follows:
E1/T1 TS 1: IXU-OML, TRX0 (OML+RSL)
E1/T1 TS 2: TRX0 TS0..3
E1/T1 TS 3: TRX0 TS4..7
E1/T1 TS 4: TRX1 (OML+RSL)
E1/T1 TS 5: TRX1 TS0..3
E1/T1 TS 6: TRX1 TS4..7
E1/T1 TS 7: TRX2 (OML+RSL)
E1/T1 TS 8: TRX2 TS0..3
E1/T1 TS 9: TRX2 TS4..7
E1/T1 TS 10: TRX3 (OML+RSL)
E1/T1 TS 11: TRX3 TS0..3
E1/T1 TS 12: TRX3 TS4..7
If you want to aggregate the OML+RSL links onto one E1 timeslot, the CON
unit has to be used. While you can already enter CON configuration on the
VTY, it is not yet sent to the BTS.
What's missing now is the OML bring-up of the TRX + TS (TRXC,RX,TX,TS Managed
Objects). After that, it should be ready to go for regular RSL messages.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4831
days inactive
4837
days old
10 comments
2 participants
participants (2)
-
Harald Welte -
Matthew Fredrickson