BSC-side PCU socket interface for paging and RACH
- 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...
#2 Updated by dexter over 1 year 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 over 1 year 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.
#6 Updated by dexter over 1 year ago
- File system_info_type_13_as_0x0C.pcap system_info_type_13_as_0x0C.pcap added
- File system_info_type_13_as_0x0C_2.pcap system_info_type_13_as_0x0C_2.pcap added
- File system_info_type_13_as_0x0C_and_f200_extended.pcap system_info_type_13_as_0x0C_and_f200_extended.pcap added
- File system_info_type_13_as_0x2C.pcap system_info_type_13_as_0x2C.pcap added
- File system_info_type_13_as_0x28.pcap system_info_type_13_as_0x28.pcap added
- File system_info_type_13_ericsson_msg_replay.pcap system_info_type_13_ericsson_msg_replay.pcap added
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.
#7 Updated by dexter over 1 year ago
- File difference_between__openbsc_lapd_and_ericsson_hdlc.png difference_between__openbsc_lapd_and_ericsson_hdlc.png added
See attached image: SAPI, TEI and Control field do not match up, should they?
#9 Updated by dexter over 1 year ago
- % Done changed from 30 to 40
- 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())