Feature #1821

BSC-side PCU socket interface for paging and RACH

Added by laforge 5 months ago. Updated about 1 month ago.

Start date:
Due date:
% Done:


Spec Reference:


When the PCU is co-located with the BTS, there's a pcu_socket interface between the two of them. This interface is usd for a lot of things, but also for
  • passing of paging requests from PCU to BTS for transmission on the PCH
  • passing of RACH requests for packet from BTS to PCU

In case the PCU is co-located with the BSC, this interface will have to be introduced to libbsc.

Important things to keep in mind
  • there will be no PH-DATA.req/.ind messages on this BSC-side PCU socket. The actual data frames are passed directly into the PCU (from E1 timeslot devices/sockets), similar to the pcu_socket bypass on the sysmoBTS devices
  • on a BTS-located PCU there is a 1:1 mapping for PCU and BTS. So both ends of the socket don't need any further addressing information. In the case of a BSC-located PCU, this is different. There might be many BTSs connected to a single BSC, so when we pass around paging and RACH requests, we need to make sure from/for which BTS they actually were. The architecture is not quite clear yet. It might actually make sense to run one osmo-pcu process for each BTS, resulting in many PCUs connecting to one BSC...

system_info_type_13_as_0x0C.pcap (30.8 KB) dexter, 10/31/2016 02:37 PM

system_info_type_13_as_0x0C_2.pcap (23.1 KB) dexter, 10/31/2016 02:37 PM

system_info_type_13_as_0x0C_and_f200_extended.pcap (21.6 KB) dexter, 10/31/2016 02:37 PM

system_info_type_13_as_0x2C.pcap (25.1 KB) dexter, 10/31/2016 02:37 PM

system_info_type_13_as_0x28.pcap (22.5 KB) dexter, 10/31/2016 02:37 PM

system_info_type_13_ericsson_msg_replay.pcap (21.4 KB) dexter, 10/31/2016 02:37 PM

difference_between__openbsc_lapd_and_ericsson_hdlc.png (41.4 KB) dexter, 10/31/2016 03:21 PM



#1 Updated by laforge 5 months ago

  • Target version set to RBS2000 with BSC-located PCU

#2 Updated by dexter 5 months ago

had a closer look at pcu_if.h, pcuif_proto.h and pcu_sock.c

To forward a rach-request to the PCU and to pass the paging back and forth we need to implement the follwing messages/functions on the BSC side:

  • pcu_tx_data_ind(): To pass the transceiver information to the PCU
  • pcu_tx_rach_ind(): To pass the rach request to the PCU
  • pcu_tx_pag_req() and pcu_tx_pch_data_cnf(): To pass through the paging requests

#3 Updated by dexter 5 months ago

  • % Done changed from 0 to 10

Started to merge pcu_sock.c into openbsc. It now compiles (still throws a few warnings). It also makes first attemts to connect to the PCU and send info. Unfortunately it seems that I start the pcu_sock to early and it fails because there is not bts object in bsc_gsmnet->bts_list.

#4 Updated by dexter 5 months ago

  • % Done changed from 10 to 20

Updating the BTS information inside the PCU now works. Next step is to forward the RACH request

#5 Updated by dexter 5 months ago

  • % Done changed from 20 to 30

Modified the pcu_sock code to accept the bts struct with every operation. On startup, for each BTS a private unix domain socket is opend. The pcu state is held inside the bts struct and by this also private.

#6 Updated by dexter 5 months ago

While preparing the teste for the RACH request I noticed that SI13 is not transmitted at all. The rsl-messagtes to set the SI13 layer 3 SI13 frame is sent to the BTS, but the BTS replies with an error report.

BSC: 0c1101801e2827170106009001d8626fc9e08410ab2b2b2b2b2b2b2b2b2b2b

0c11    Common Channel Management Message Nr.11 = BCCH-Information
0180    Channel number

1e28    System info Type 0x28 (=SI13)

27    Full BCCH Information
17    Length = 23 Byte

Layer 3 message (system info string)

BTS replies with Error report: 101c1a013f1c110180 
(Service or option not available)

Looking at the ericsson traces we have shows that the SI13 is handled differently by ericsson:

BSC: 0c1101801e0c2717010600e0005851efca9281433142cb2b2b2b2b2b2b2b2bf200
BSC: 0c1101801e0c2717010600f0005851efca9281433142cb2b2b2b2b2b2b2b2bf200
BSC: 0c1101801e0c2717010600f0005851efca93e50a198a162b2b2b2b2b2b2b2bf200
BSC: 0c1101801e0c271701060080005851efca93e50a198a162b2b2b2b2b2b2b2bf200

0c11    Common Channel Management Message Nr.11 = BCCH-Information
0180    Channel number

1e0c    System info Type 0x0C = 12
    (should be 0x28 by GSM 08 58, or by Erricsons docs 0x2C)

27    Full BCCH Information
17    Length = 23 Byte

Layer 3 message (system info string)

f200    BCCH-Mapping 0x00 = BCCH Normal

We see that the system info type is different. Ericcson uses 0x0C as tag. By the standard it should have been 0x28. Ericssons BTSM_ERICSSON.chm manual states that it should have been 0x2C. Ericsson also mentiones in BTSM_ERICSSON.chm that the BCCH-Mapping parameter (0xF200 at the end) should be sent with SI13 as we see it in the trace.

Changing the System info type from 0x28 to 0x0C changed the error from "Service or option not available" to "Class: Resource unavailable". I tried changing to both, 0x0C and 0x2C. Attaching the missing 0xF200 yields a protocol error because at least one length fields seems not to match up. Even if I exactly replay the message from the ericsson trace I get "Class: Protocol error"

I suspect that there are either other (OM2000 or RSL) messages that influence GPRS usage or the Layer3 part of the SI13 we are generating is somehow invalid (unlikely). Next I need to get rid of the "Class: Protocol error", when I attach the BCCH-Mapping (0xF200). All length fields in the RSL part of the message seem to be perfectly fine, probably its in the layer above. Probably the LAPD has problems with messages exceeding 23 bytes?

Attached you find the .pcap traces from the experiments I id so far.

#7 Updated by dexter 5 months ago


See attached image: SAPI, TEI and Control field do not match up, should they?

#8 Updated by dexter 5 months ago

It looks like the SI13 problem is solved now:
(I did not confirm SI13 on Um yet, but I am confident that it will be transmitted if the BTS does not reject it)

#9 Updated by dexter 5 months ago

  • % Done changed from 30 to 40
Status update:
  • Rach requests that are for packet channel are now forwarded to the pcu. Since we only get the relative frame number from the rach request (Fn%42432), the pcu has been patched to understand relative frame numbers (Fn%42432) as well.
  • Immidate assingnments (AGCH) are received from the PCU and forwarded to the BTS. (calls rsl_imm_assign_cmd())

#10 Updated by laforge 5 months ago

please make sure to always keep ticket status in sync. This is in progress, and not 0%/new.

#11 Updated by dexter 5 months ago

  • Status changed from New to In Progress

#12 Updated by dexter 2 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 40 to 100

Paging and RACH has been confirmed working.

#13 Updated by laforge about 1 month ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF