Actions
Bug #5852
openosmo-sgsn: Keep TLLI<->NSEI+BVCI relation knowledge in BSSGP layer
Status:
New
Priority:
Normal
Assignee:
-
Category:
Gb interface
Target version:
-
Start date:
01/11/2023
Due date:
% Done:
0%
Spec Reference:
Description
Related specs:
BSSGP = 3GPP TS 48.018
LLC = 3GPP TS 44.064
SNDCP = 3GPP TS 44.065
Right now we are passing BVCI and NSEI knowledge BSSGP<->LLC<->SNDCP<->processing, and updating the relation TLLI<->{NSEI,BVCI} really high in the stack (mmctx.gb.bvci/nsei).
According to specs, it seems the knowledge of the relation of an MS and its current NSEI+BVCI should be kept in the SGSN before reaching the LLC layer processing.
<pespin> I'm trying to understand better how the BVCI/NSEI are supposed to be tracked by the SGSN.
<pespin> Right now we are passing BVCI and NSEI in msgb_bvci() and msgb_nsei() up to the GMM layer, but that looks wrong from what I read on the specs
<pespin> since I don't see anywhere that BVCI and NSEI should even be passed to LLC layer
<pespin> so my understanding is that the good thing to do would be to track BVCI and NSEI based on TLLI in the BSSGP layer itself? As in a hashmap of TLLI->{NSEI,BVCI} which is updated everytime we receive a BSSGP pdu and looked up every time we need to send a message to a given TLLI on downlink
<pespin> TS 48.018 6.2 "he SGSN shall obtain the BVCI, the NSEI, and in the case of an IP sub-network may obtain
<pespin> the LSP and the NS Change IP endpoint, from the underlying network service; the BVCI and the NSEI are not visible in
<pespin> the UL-UNITDATA PDU."
<pespin> in BSSGP spec the equivalent primitives (BSSGP-{U,D}L-UNITDATA contain BVCI and NSEI, but there's a note in TS 48.018 5.3:
<pespin> "NOTE: The parameters in the BSSGP-DL-UNITDATA and BSSGP-UL-UNITDATA primitives that are not
<pespin> included in the corresponding primitives in 3GPP TS 44.064 are provided or extracted by some
<pespin> intermediate function out of the scope of the present document."
<pespin> so sounds like we need to cache the BVCI and NSEI in between BSSGP and LLC as I suggested?
Updated by pespin over 1 year ago
asdfuser> <pespin> "so sounds like we need to..." <- I don't read it that way. 48.016 Table 5.2.1 lists BVCI, NSEI, ... as parameters for the SAP between NS and BSSGP and in 48.018 Table 5.3 lists those parameters as well. So while they are not part of the actual PDU passed to the layer they are instead passed as parameters.
<asdfuser> pespin: I think you're talking about the LLC service layer primitives (44.064 4.7.0) which would be completely inside the SGSN on top of the BSSGP layer.
<pespin> asdfuser, yeah they are passed NS<->BSSGP afaiu, and provided to the app processing (SGSN) in BSSGP-UL-UNITDATA, but they are never passed to the related LLC primitive
<pespin> asdfuser, the problem is that right now we are passing NSEI+BVCI even upper than SNDCP, and assigning the current NSEI+BVCI at something around MM layer (everything is blurry regarding layers in osmo-sgsn)
<pespin> asdfuser, see mmctx->gb.bvci
<pespin> which means we kind of need to create an MMCTX which is layera above in order to track something several layers below
<pespin> asdfuser, I just created https://osmocom.org/issues/5852 to track this further too
<pespin> asdfuser, see LLC spec TS 44.064 (https://www.etsi.org/deliver/etsi_ts/144000_144099/144064/16.00.00_60/ts_144064v160000p.pdf) Table 7
<pespin> LLE ↔ BSSGP BSSGP-UL-UNITDATA contains no BVCI nor NSEI
<pespin> and the whole spec contains no reference to BVCI nor NSEI
<pespin> same goes for the SNDCP layer (TS 44.065)
<pespin> so to be it's becoming obvious that we should track those relations in osmo-sgsn code but only in code interacting between BSSGP and LLC (and not using mmctx to store that info)
<pespin> now the question is how to know when to free/release the relation TLLI<->{NSEI,BVCI}
<asdfuser> Yeah, for sure when NS/BSSGP reports a reset. In LLC you'll need to keep track of tlli changes as well.
<pespin> asdfuser, that sounds like NM-BVC-RESET primitive in 3GPP TS 48.018 Table 5.2 ?
<pespin> asdfuser, however we seem to be handling nothing for SAP_BSSGP_NM in sgsn_bssgp_rx_prim in osmo-sgsn.git nowadays
<pespin> we seem to be generating PRIM_NM_BVC_RESET.PRIM_OP_INDICATION in bssgp_rx_bvc_reset() in libosmogb though
<asdfuser> pespin: Yeah, NM-BVC-RESET looks good.
<asdfuser> pespin: We have bssgp2 in libosmocore which osmo-sgsn does not yet use iirc
So In summary, we seem to need some sort of structure "bssgp_nm_subscr" which possibly contains {IMSI, TLLI, NSEI, BVCI} per MS, and have some sort of hashmap/list of them.
- Upon NM-BVC-RESET.ind/req/resp/cnf we release all subscribers related to a given NSEI+BVCI
- Upon receive new data on a BVCI, we lookup (and create if not exists) a "bssgp_nm_subscr" and update the NSEI and BVCI from the received IMSI/TLLI.
- Upon transmitting for a given MS (TLLI), we lookup and use the found NSEI+BVCI to pass the LLC data to lower layers.
Actions
