CS-PAGING not implemented
BSSGP PAGING CS is used to deliver a circuit-switched paging request to a MS while it is engaged in transferring GPRS data. The related paging request is not sent via Broadcast/PCH, but via PACCH to that MS.
#5 Updated by laforge about 1 year ago
- Assignee changed from lynxis to osmith
Please note this is mostly relevant with other core networks than osmocom. In osmcoom, the MSC pages the BSC and the BSC pages the BTS, which then passes it to the PCU for transmission. This works.
However, when using a non-osmocom core with Gs interface between MSC and SGSN for paging coordination, the SGSN will likely send us CS-PAGING and we have to implement it in the PCU for interoperability.
While developing some TTCN3 PCU tests (#3927) I also tried to understand better this scenario. Some references I could fine:
TS 23.060 sec 6.3.3 CS Paging (A/Gb mode)
TS 48-008 sec 3.1.10 Paging
TS 24.008 sec 4.7.9 Paging procedure
TS 44.018 sec 188.8.131.52 paging
TS 48.018 sec 5.2.4, 7.1
PAGING-PS: TS 48.018 10.3.1
PAGING-CS: TS 48.018 10.3.2
Specially important are the last 2, where the SGSN->PCU PDUs requesting the paging are described.
As far as I understand, we already implement paging (not sure if correctly) in the SGSN: it uses libosmocore's bssgp_tx_paging().
In libosmocore, we also have a symbol which afaiu we should use in osmo-pcu and which I think is not yet use by anybody:
gprs_bssgp_bss.c: /* Parse a single GMM-PAGING.req to a given NSEI/NS-BVCI */ int bssgp_rx_paging(struct bssgp_paging_info *pinfo, struct msgb *msg)
It seems PS-PAGING is already supported by osmo-pcu, while CS-PAGING is not:
case BSSGP_PDUT_PAGING_PS: gprs_bssgp_pcu_rx_paging_ps(msg, tp); ... case BSSGP_PDUT_PAGING_CS: case BSSGP_PDUT_FLUSH_LL: case BSSGP_PDUT_SGSN_INVOKE_TRACE: LOGP(DBSSGP, LOGL_INFO, "Rx BSSGP BVCI=%d (SIGN) PDU type %s not implemented\n", bvci, bssgp_pdu_str(pdu_type)); break;
If I understand correctly, what's missing here is to do something similar to what we do when PCU receives a struct gsm_pcu_if_pag_req with type PCU_IF_MSG_PAG_REQ on pcu_rx_pag_req() from BTS. That path is already covered by PCU_Tests_RAW.TC_paging_cs_from_bts, where a DL_PACKET_PAGING_REQUEST is sent over PACCH. The only difference in this scenario is that the PAGING_REQUEST must be retriggered on reception of the CS-PAGING message from SGSN in gprs_bssgp_pcu.cpp.
So mainly calling libosmocore's bssgp_rx_paging() and then calling similar to what pcu_rx_pag_req() does:
return BTS::main_bts()->add_paging(pag_req->chan_needed, pag_req->identity_lv);
- Status changed from In Progress to Feedback
- % Done changed from 0 to 90
- Assignee changed from osmith to pespin
Testing is done here:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16528 pcu: Introduce tests for CS and PS paging from SGSN/Gb
- Status changed from Resolved to Feedback
BTW, there is BSS_PAGING_COORDINATION in SI13 / GPRS Cell Options IE (see 3GPP TS 44.060, table 12.24.2):
This field indicates the network support of CS paging co-ordination in packet transfer mode during network mode of operation II and III. [...] It is coded as follows: 0 The cell does not support Circuit-Switched paging coordination 1 The cell supports Circuit-Switched paging coordination
OsmoBSC currently hard-codes this option to 0. Should we make it configurable?
As per section 6.1.3 "Paging initiation using PACCH", "if such indication is received, a mobile station in packet transfer mode shall expect the paging messages to be received on the PACCH". So does it mean that otherwise (if BSS_PAGING_COORDINATION is set to 0) the MS would ignore our paging messages?
- Status changed from Feedback to In Progress
- Assignee changed from pespin to laforge
- Status changed from In Progress to Resolved