gbproxy2: Route BSSGP-STATUS based on "Erroneous PDU IE"
- PTP downlink: Simply route by NS-BVCI
- PTP uplink: route based on "Erroneous PDU IE"
- SIG downlink + uplink:
- don't route (but locally terminate) if optional BVCI IE, as that one only occurs for BVCI blocked / BVCI unknown whihc is a gbproxy problem, not one with a remote peer
- route messages without BVCI IE but with "PDU in error" IE based on the latter
- the contained BSSGP PDU might be truncated, and hence our TLV parser might not be playing well along
- we should look for TLLI + TMSI (and route based on NRI)
- if we cannot find any routing informatoin, we treat it like NULL NRI?
- fast path for single-SGSN case: simply route to "the" SGSN?
#2 Updated by laforge about 1 month ago
There are now TTCN3 tests for both uplink and downlink direction in https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/22257
#5 Updated by laforge about 1 month ago
On Mon, Jan 25, 2021 at 10:42:07AM +0000, daniel [REDMINE] wrote:
The tests seem to be for BSSGP-STATUS PDUs while this ticket is about NS-STATUS PDUs
thanks for catching that. I'm not sure what I was thinking 2 months ago exactly,
but I think I may have been thinking about BSSGP even back then.
In terms of NS-STATUS: I'm currently not entirely sure if we should route them
at all, or not. After all, we really do terminate the NS layer completely
in gb-proxy. The NS-VCI / NSEI are going to be different on both sides.
Hence, I think it's best to rename the ticket to BSSGP.