Intra-domain connection of OsmoPCU to multiple SGSNs (pooling)
SGSN pooling is based on splitting the P-TMSI into two parts: A few bits that identify the SGSN in the pool (the so called NRI), and the remainder, which identifies the subscriber within the SGSN.
At time of first contact (random/foreign TLLI), there is a node selection function which chooses the SGSN to use for this request. All follow-up messages are then handled via this SGSN.
This feature would have to be implemented in OsmoPCU, alongside with corresponding test suite in TTCN-3.
Each PCU then has multiple Gb links; at least one to each of the SGSNs in the pool.
- per-BVC FSM for RESET/BLOCK/UNBLOCK
- ability to configure multiple SGSN-side NSE in gbproxy
- TTCN3 test case for RESET/BLOCK/UNBLOCK with two SGSNs in pool
- NRI configuration in VTY
- uplink message routing based on NRI extracted from TLLI
- BVC FLOW CONTROL
On Sun, Mar 29, 2020 at 07:15:37PM +0000, ipse [REDMINE] wrote:
It would be really nice if this feature could be implemented both in OsmoPCU and OsmoGbProxy at the same time - OsmoGbProxy is very helpful in practical installations.
I understand that, and obviously I want that more than anyone else.
The problem with pretty much all 'feature' tickets here is: Who is going to contribute related code /
developer time or funds :) It's not like we're seeing a lot of resources thrown at Osmocom...
#6 Updated by laforge about 1 month ago
It has become clear that this feature will be implemented in a generic nature so it can be used from both osmo-pcu and osmo-gbproxy.What we need to make this work is:
- NAS Node Selection Function inside BSSGP code on BSS side
- multiple NSE inside the BSS (one for each SGSN), each with it's own set of NS-VCs
- signaling BVC from each SGSN
- separate PTP BVC from each cell to each SGSN
This diagram from TS 48.016 serves as a good illustration:
- Status changed from New to In Progress
- Assignee set to laforge
WE could implement this "only" in OsmoPCU, but we also need it in osmo-gbproxy. Unfortuantely the proxy as a "MITM" has quite some different implementation requirements as the PCU, so there would be relatively separate implementation in both PCU and gbproxy, using some common library/infrastructure.
The easier approach is probably to focus on gbproxy for now. If somebody needs this for a single osmo-pcu, they can always run osmo-gbproxy in front in order to get the pooling feature. And for people running multiple omso-pcu, they will want osmo-gbproxy anyway for aggregation needs.
I did an analysis for osmo-gbproxy in terms of what kind of processing we need to introduce at each BSSGP message.The general assumption is that we will have
- multiple PCU/BSS side Gb interfaces, each
- with one NSE/NS-VCG
- one or multiple NS-VC
- one or multiple PTP BVC
- no support for pooling in the PCU required or enabled
- multiple SSN side Gb interfaces, each
- with one NSE/NS-VCG
- one or multiple NS-VC
- support for pooling in the SGSN enabled
For each PTP BVC, we need to "duplicate" it, i.e. establish one per-SGSN BVC for each BSS side BVC. This is achieved by "terminating" the BVC-RESET locally in the Gbproxy on both sides, and having related interconnects, i.e. a BVC-RESET for a PTP BVC on the BSS side will trigger Nx BVC-RESET on the SGSN side, one for each SGSN/NSE.
As for the individual messages:
Downlink-Only messages with no routing requirements¶
Downlink-only messages are accepted from any SGSN and routed baesd on BVCI, just like it is done prior to this feature.
Messages routed by NRI extracted from TLLI¶
- if TLLI or P-TMSI are included, route based on NRI
- if IMSI is included, route to "randomly distributed" SGSN in pool
BVC flow control¶
The capacity advertised by the BSS/PCU side has to be split between all SGSNs. Separate BVC flow control instances need to be operated in gbproxy for each BVC, with coordination between them. Probably implemented by osmo_fsm.
The STATUS message doesn't really tell us where it belongs to, unless the contained PDU would have TLLI or P-TMSI information. We could consider broadcasting it?
Those have to be terminated for each BVC inside osmo-gbproxy: One each on the BSS/PCU side, and one per-SGSN-per-BVC on the SGSN side. Coordination must happen between them. Probably implemented by osmo_fsm.
This downlink-only message must be broadcast to all BSS, like it is done in the non-pooling case.
This downlink-only message must be broadcast to all BSS
It is assumed any SGSN can route RIM messages to any other PCU, so we can simply chose any of them. In the case of responses it might be a good idea to use the same thorugh which the request was received.
The ENQUIRY is in uplink direction and contains no TlLI but only IMSI. We can route it to any SGSN. The ENQUIRY-RESPONSE is in downlink direction and must be sent back to whichever PCU/NSE requesting it. We therefore need to track some state here.
- Checklist item per-BVC FSM for RESET/BLOCK/UNBLOCK added
- Checklist item ability to configure multiple SGSN-side NSE in gbproxy added
- Checklist item TTCN3 test case for RESET/BLOCK/UNBLOCK with two SGSNs in pool added
- Checklist item NRI configuration in VTY added
- Checklist item uplink message routing based on NRI extracted from TLLI added
- Checklist item RADIO-STATUS added
- Checklist item BVC FLOW CONTROL added
- Checklist item RIM added
- Checklist item MS-REGISTRATION-ENQUIRY added
I've started with implementing the slightly contrived BVC-RESET handling, as this will be the logical first step we need in order to bring up a GbProxy with a pool of several SGSNs.
There will be a per-BVC osmo_fsm that takes care of reset/block/unblock. This FSM can behave in either SGSN or BSSGP role, and gb-proxy will use this FSM both towards each BSS and towards each SGSN.
state-change notification call-backs and reset-indication-callbacks will be used by gbproxy to "stitch" those FSMs together. So for example, if there's a reset-indication from a BSS-side FSM, then that will trigger "reset request FSM events" on each SGSNs BVC-FSM for the same BVCI, which iwll then in turn trigger BVC-RESET procedures towards each of those SGSNs.
The plan is to get this implemented together with a minimal "bring up all BVCs with two SGSN" TTCN3 testcase, and then hand it over to daniel for implementation of the handling of various PDU types as outlined here in this ticket.