Project

General

Profile

Feature #4200

Work around nano3G-S16 requiring RAB ID to be below 16

Added by efistokl about 1 month ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/12/2019
Due date:
% Done:

0%

Resolution:
Tags:
3G

Description

Hardware: ip.access nano3g S16.

Tested against osmo-msc version branches 35c3 and cccamp19 (with Message Class and RAT GSUP IEs stripped out). Reproduced 3 times.

In the trace there are 17 incoming SIP calls. The last 2 failed (around packet 36826 and 37625). In the RAB-AssignmentResponse's for them I see "radioNetwork: failure-in-the-radio-interface-procedure (14)".

If I restart the osmo-msc, I can make another 15 calls.

IPs:
10.0.2.247 - nano3g S16
10.0.2.244 - RNC:
- 10.0.2.244:5060 osmo-sip-connector
- 10.0.2.244:5064 local PBX (kamailio)
172.48.2.1 - Remote PBX (kamailio)
172.48.1.5 - GSUP server

Note:
Apart from the osmocom software there is Kamailio and rtpengine installed alongside osmo-sip-connector to allow for transcoding. I've set it in a way so that it "sleeps" for 3 seconds before passing SIP INVITE to osmo-sip-connector. (If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD))

msc.log.txt msc.log.txt 2.86 MB Debug output from osmo-msc efistokl, 09/12/2019 01:48 PM
rnc.pcap rnc.pcap 7.38 MB Trace captured at 10.0.2.244 efistokl, 09/12/2019 01:49 PM

History

#1 Updated by laforge about 1 month ago

  • Status changed from New to Feedback
  • Assignee set to efistokl

I suspect this is some constraint of the nano3G-S16 and not neccessarily a bug by OsmoMSC.

3GPP TS 25.413 defines the RAB ID in Section 9.2.1.2. At no point does it state that RAB IDs must be recycled and stay below the maximum count of concurrent RAB supported by the RNC/NodeB, and that they cannot use any arbitray (unique) value from 0...255. So IMHO, OsmoMSC is well within its right to choose whatever RAB ID it wants.

To me it looks a bit like the nano3G S16 may support 16 concurrent UE and hence RABs, and that it only permits RAB ID 0..16 for that. You can confirm this theory by making the RAB ID start with 17 in the first call (you have to patch the OsmoMSC side), and see if that first call already fails.

#2 Updated by lynxis about 1 month ago

(If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD)

The paging problem might be fixed by https://gerrit.osmocom.org/c/osmo-msc/+/15494

#3 Updated by efistokl about 1 month ago

laforge wrote:

To me it looks a bit like the nano3G S16 may support 16 concurrent UE and hence RABs, and that it only permits RAB ID 0..16 for that. You can confirm this theory by making the RAB ID start with 17 in the first call (you have to patch the OsmoMSC side), and see if that first call already fails.

Genau! The theory has been confirmed. Thanks.
Also, what is interesting. When I reached the rab ID 21, instead of replying the femtocell did Deregister:)

I guess I will try to mask the RAB ID to be in the range 1..16 and see what the femtocell has to say...

#4 Updated by efistokl about 1 month ago

  • Status changed from Feedback to Resolved

efistokl wrote:

I guess I will try to mask the RAB ID to be in the range 1..16 and see what the femtocell has to say...

Double confirmed. I used the range 1..15 (I guess it is also acceptable to be 0 but I haven't checked) and all is fine. Closing this. Thanks, Harald!

lynxis wrote:

(If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD)

The paging problem might be fixed by https://gerrit.osmocom.org/c/osmo-msc/+/15494

Thank you and excuse me for being so slow to test this. I am still fixing some call problems (unrelated to osmocom software). I will test it when I am free from the urgent stuff...

#5 Updated by laforge about 1 month ago

On Fri, Sep 13, 2019 at 12:41:46PM +0000, efistokl [REDMINE] wrote:

Double confirmed. I used the range 1..15 (I guess it is also acceptable to be 0 but I haven't checked) and all is fine. Closing this. Thanks, Harald!

well, not sure it should be closed. We still might want to have a workaround in the codebase.

Maybe rather rename the issue subject to "work around nano3G-S16 requiring RAB ID to be below 16"
or so?

OsmoMSC (and SGSN?) could use a RAB-ID allocation algoritmh that would always choose the lowest
available free number, rather than using a monotonically incrementing counter. Doing just modulo
arithmetic won't cut it, as RAB-ID 0 could be particularly long-lasting, and at the time we wrap,
0 can very well still be in use.

#6 Updated by efistokl about 1 month ago

  • Tracker changed from Bug to Feature
  • Subject changed from Getting "radioNetwork: failure-in-the-radio-interface-procedure (14)" in RAB-AssignmentResponse after 15 calls. to Work around nano3G-S16 requiring RAB ID to be below 16
  • Status changed from Resolved to In Progress

#7 Updated by efistokl about 1 month ago

laforge wrote:

You can confirm this theory by making the RAB ID start with 17 in the first call (you have to patch the OsmoMSC side), and see if that first call already fails.

Performed the same test with ip.access nano3g S8 (though you said before that it behaved totally fine on ccc events, but we have different software versions on them). S8 is totally fine. S16 is quite weird in this sense as it should be more advanced than S8 (well, it is at least in terms of coverage)... I think I need to ask ip.access whether they have a software update targeting this. Sounds very much like a bug in S16 software...

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)