Cellular Network Infrastructure » cni-legacy » OpenBSC

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

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.

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

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.

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)
0106009001d8626fc9e08410ab2b2b2b2b2b2b2b2b2b2b

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)
010600e0005851efca9281433142cb2b2b2b2b2b2b2b2b

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.

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

It looks like the SI13 problem is solved now:
https://gerrit.osmocom.org/#/c/1183/
(I did not confirm SI13 on Um yet, but I am confident that it will be transmitted if the BTS does not reject it)

• 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())

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

Paging and RACH has been confirmed working.