Osmocom Libraries » libosmocore

• for FR transport layer, TS 48.016 specifies very clearly what is the alive/dead state of a NS-VC in the context of block/unblock/reset procedures
• for IP transport with IP-SNS, it doesn't make any similar specifications
• our current assumption is that after SNS-CONFIG, we create all NS-VCs as dead, start the test/alive procedure, and mark them as alive once we see a NS-ALIVE-ACK.

Furthermore, TS 48.016 specifies that each side can start the alive/test procedure at any time, independent of each other. However, it does not specify if the ALIVE/DEAD state should be kept separately on each side, or if that state is presumed to be global.

This leads to problems in our TTCN3 tests:

• SNS-CONFIG completes
• gbproxy sends NS-ALIVE to SGSN
  • SGSN responds with NS-ALIVE-ACK
  • NS-VC now assumed as ALIVE on gbproxy side
• gbproxy sends NS-UNITDATA) to SGSN
• SGSN considers the NS-VC still as dead, as it did not yet (start or) complete the NS-ALIVE procedure
• SGSN returns NS-STATUS

In the above example "SGSN" is a simulated SGSN in our TTCN-3 test suite, but this could just as well happen with a real SGSN.

We have the following options:

1. consider receiving a NS-ALIVE from a peer as an indication that the link must be ALIVE, irrespective of what our own alive/test procedures say
   • that's a bit of a hack, IMHO
2. consider all NS-VC after SNS-CONFIG to be ALIVE, and only mark them DEAD after the test procedure fails for NS-ALIVE-RETRIES number of times
   • this seems to be one possible reading of TS 48.016, as it doesn't specify if NS-VC are considered ALIVE or DEAD when SNS-CONFIG completes
3. always have some delay after SNS-CONFIG in the SGSN
   • doesn't solve the problem if a third party SGSN as no such delay
4. don't wait only for a locally-originated NS-ALIVE procedure to succeed, but also wait until a first NS-ALIVE from the peer has been received, before considering a NS-VC as ALIVE

To me, option 2 seems most attractive so far.