Feature #4200
openWork around nano3G-S16 requiring RAB ID to be below 16
0%
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))
Files
Updated by laforge over 3 years 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.
Updated by lynxis over 3 years 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
Updated by efistokl over 3 years 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...
Updated by efistokl over 3 years 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...
Updated by laforge over 3 years 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.
Updated by efistokl over 3 years 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
Updated by efistokl over 3 years 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...
