Project

General

Profile

Bug #2976

octphy: no response to assignment command on RSL level

Added by dexter over 1 year ago. Updated 10 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
osmo-bts-octphy
Target version:
-
Start date:
02/21/2018
Due date:
% Done:

0%

Spec Reference:

Description

osmo-bts-octphy seems not to work with pmaier/fsm3. I narrowed the cause down to a missing assignment complete on RSL level. We use the assignment complete response as input for the GSCON FSM (see bsc_api.c:handle_ass_compl()).

Attached one finds a trace that illustrates the expected behavior (normal_call_example.pcapng). After the Assignment Request on the A-Interface a channel activation happens and then we can see Assignment Command and shortly after Assignment Complete. In assignment_complete_missing.pcapng we again see the Assignment Request on the A-Interface. The channel activation on RSL and then the Assignment Command, but no Assignmnet complete. What then happins is that T10 times out and the assignment fails.

Actually the Assignment Command von the RSL side is a Data-Request. When I get the things right this message is not touched by the BTS. It goes straight to the mobile and the assignment complete comes from the mobile and passes straight into the BSC.

History

#1 Updated by laforge over 1 year ago

during our lunch discussion we were considering the L3 sequence numbers (2bit) might be related. However, they only exists in MM/CC/SMS/SS - there are no L3 sequence number in RR messages. So that can be excluded.

#2 Updated by dexter over 1 year ago

laforge: I noticed that, I guess RR has no sequence number because those messages never leave the BSS domain (unlike the others).

I have done some more tests on that issue. I was fearing that the problem could be a regression in osmo-bts. I checked the problem against osmo-bts-trx and there everything functions normally - so it seems to be ineed an octphy specific problem. There is more research to be done on this. However on our testphones I can see that the ASSIGNMENT COMMAND is received an an ASSIGNMENT COMPLETE is sent out. I wonder why it never arrived (Wrong channel?).

#3 Updated by dexter over 1 year ago

I have tried the experiment again. This time I have included the gsmtap output from osmo-bts-octphy in the capture. The trace only contains one MO call. One can see the assignment command at frame 2091 on RSL level. Then it appears again on frame 2264 in GSMTAP. A few frames later at 3064 An Assignment Failure is visible in the GSMTAP. An Establish Indication is not visible in the trace. I wonder why the Assignment Failure is not visible in the RSL data. Shouldn't it be forwarded to the BSC?.

I have done the test with a K800i (external mncc, call to test number), the results contradict with the test I did last time with the trace mobile.

#4 Updated by dexter over 1 year ago

I have retried the experiment with the trace mobile. The result is different. At Frame 2453 we can see the incoming assignment command. At Frame 2644 we see the Assignment command re-appearing in the GSMTAP data. After that there is not Assigment Complete and no Assignment Fail visible. Also no Establish Indication is visible.

On the trace mobile the result is somewhat weird. The Assignment command seems to be responded with an Assignment complete, but shortly after that, an Assignment Failure is send out. However, I do not see any of those messages in the trace.

#6 Updated by laforge over 1 year ago

On Fri, Apr 13, 2018 at 10:15:15AM +0000, dexter [REDMINE] wrote:

I have tried the experiment again. This time I have included the gsmtap output from osmo-bts-octphy in the capture. The trace only contains one MO call. One can see the assignment command at frame 2091 on RSL level. Then it appears again on frame 2264 in GSMTAP. A few frames later at 3064 An Assignment Failure is visible in the GSMTAP. An Establish Indication is not visible in the trace.

ok, so the phone is not able to establish the dedicated channel it is being assigned.

I wonder why the Assignment Failure is not visible in the RSL data. Shouldn't it be forwarded to the BSC?.

Yes, it should become an assignment failure on the BSSAP level. Might be good to make sure
BSC_Tests.ttcn contains a related test.

I have done the test with a K800i (external mncc, call to test number), the results contradict with the test I did last time with the trace mobile.

where is the contradiction? Didn't it fail both then just like it failed now?

#7 Updated by laforge over 1 year ago

dexter wrote:

On the trace mobile the result is somewhat weird. The Assignment command seems to be responded with an Assignment complete, but shortly after that, an Assignment Failure is send out.

Why is that weird? That's exactly the behaviour you would see in any situation where the MS attempts to establish the new radio channel but fails to do so, and then switches back to the old channel to send the assignment failure.

#8 Updated by laforge over 1 year ago

On Fri, Apr 13, 2018 at 10:15:15AM +0000, dexter [REDMINE] wrote:

File assignment_fail.pcapng added

why is the RR ASSIGNMENT command assigning a SDCCH from an already-establishedSDCCH?

If this is a voice call, then the assignment must be from SDDCH to a TCH.
If this is SMS or some other signaling-only service, no RR ASSIGNMENT should happen

#9 Updated by laforge over 1 year ago

disregard my last comment, I was looking at the wrong packets.

But to my surprise and contrary to our last conversation on the subject
(where I asked you whether encryption was enabled, which you denied),
this trace is using encryption!

RR CIPH MOD CMD is enabling A5/1 before the assignment.

So as a result, the problem is likely with a RSL CHAN ACT that already has
encryption parameters present (see frame 2408) which fails, as opposed to
RSL CHAN ACT without encryption (see frame 1489) and later enabling encryption
by means of RSL ENCR CMD (frame 2017).

My expectation is that if you disable encryption, it will start working. If that's
the case, you need to check why the encryption parameters are not used during
RSL CHAN ACT.

#10 Updated by dexter over 1 year ago

3065
3066

(I am sorry, I confused the configuration when we were talking about the problem last time)

It looks just like that you are right. I tested it again with encryption disabled and it indeed works now.

#11 Updated by laforge about 1 year ago

  • Category set to osmo-bts-octphy

#12 Updated by dexter 10 months ago

  • Status changed from New to Rejected

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)