Project

General

Profile

Actions

Feature #4485

closed

osmo-bsc: We should be announcing NMO I instead of NMO II

Added by pespin almost 4 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/06/2020
Due date:
% Done:

0%

Spec Reference:

Description

<fixeria> pespin: are you aware of BSS_PAGING_COORDINATION?
<fixeria> pespin: https://osmocom.org/issues/2406#note-13
<pespin> fixeria, never heard of it, good you find it. Are we using mode II or III? I don't recall which is which now
fixeria> pespin: GPRS_NMO_II as far as I can see from the code
<fixeria> pespin: DTM: found it in 44.018: "Dual transfer mode" section 3.1.2.7
<pespin> fixeria, osmo-bsc/src/osmo-bsc/system_information.c:1147 -> .nmo            = GPRS_NMO_II,
...
LaF0rge> fixeria: pespin: We should be using NMO I!
<LaF0rge> pespin: NMO_II requires the MS to monitor the CCCH while in active TBF
<LaF0rge> pespin: NMO_I is where CS paging gets delivered over PACCH while in active TBF
<LaF0rge> NMO_III would probably also work (as we don't have a PCCCH).
<LaF0rge> We would use NMO_II only if we didn't pass CS paging from BTS via the PCU socket into the PCU
<LaF0rge> pespin: NMO_II would mean that the MS has to continouusly interrupt packet transfer mode and switch to CCCH to see if there's a CS paging.  This will degrade throughput significantly.
<LaF0rge> pespin: as we transmit paging both on CCCH and on PACCH (the PCU socket just gets a copy of the paging), NMO_II should work - but it's far suboptimal compared to NMO_I
<LaF0rge> pespin: and I think DTM is more or less a theoretical option.  I always thought there are no such modems, or if they exist, they're very rare.  So I never bothered about it
<whytek> Wow, really, I looked at all this NMO last week, and checked the SI, noted that we had NMO II and assumed that the pcu and bts should behave accordingly.
<whytek> but this is wrong????
<LaF0rge> whytek: well, as I just statead, it should work, too - but is suboptimal to NMO_I
<whytek> LaF0rge, yep.. There were some things that i remember reading in the spec (can't remember now, i ran out of threads in my brain) that made me pose questions about mode I or II
pespin> osmo-bsc.git 858491821f72af4dcb63d8af66d45b7aa7b231e1    it seems there we moved from III to II

Files


Related issues

Related to OsmoPCU - Bug #2406: CS-PAGING not implementedResolvedlaforge07/29/2017

Actions
Related to OsmoMSC - Feature #1599: Gs interface (BSSMAP+) between SGSN and MSC/VLRNew02/23/2016

Actions
Related to OsmoSGSN - Feature #1583: Gs interface (BSSMAP+) between SGSN and MSC/VLRNew02/23/2016

Actions
Actions #1

Updated by pespin almost 4 years ago

  • Subject changed from We should be announcing NMO I instead of NMO II to osmo-bsc: We should be announcing NMO I instead of NMO II
Actions #2

Updated by fixeria almost 4 years ago

  • Related to Bug #2406: CS-PAGING not implemented added
Actions #3

Updated by fixeria almost 4 years ago

I am wondering whether NMO I would imply that the MS is allowed to do combined Attach on PS (and thus omit CS Location Update)?
Also, wouldn't the lack of PACKET_SERVING_CELL_DATA (see #2400) on PDCH cause any problems in NMO I?

Actions #4

Updated by fixeria almost 4 years ago

I am wondering whether NMO I would imply that the MS is allowed to do combined Attach on PS (and thus omit CS Location Update)?

I did a quick test, and the answer is YES. The phone requested combined GPRS/IMSI Attach. Even when the SGSN responded with Attach Accept (Result of Attach: GPRS only attached), it took the phone a few minutes to realize that and send Location Updating Request on SDCCH.

Actions #5

Updated by fixeria almost 4 years ago

it took the phone a few minutes to realize that and send Location Updating Request on SDCCH.

During those few minutes (~5) the CS service was unavailable (a small 'limited-service' icon in the status bar). As it turns out, the phone continuously tries to perform combined RA/LA Update procedure, but the SGSN rejects it with GMM cause 'Protocol error, unspecified'. Here is what I see in my terminal (repeated pattern):

DLLC NOTICE gprs_llc.c:1056 LLME(ffffffff/d898abeb){UNASSIGNED} LLGM Assign pre (d898abeb => ffffffff)  
DLLC NOTICE gprs_llc.c:1102 LLME(00000000/00000000){UNASSIGNED} LLGM Assign post (d898abeb => ffffffff)               
DLLC NOTICE gprs_llc.c:535 LLME(ffffffff/d898abeb){UNASSIGNED} LLC RX: unknown TLLI 0xd898abeb, creating LLME on the fly
DMM NOTICE gprs_gmm.c:1586 MM(---/ffffffff) Update type 2 unsupported in Mode III, is your SI13 corrupt?
DMM NOTICE gprs_gmm.c:1734 MM(---/ffffffff) Rejecting RA Update Request with cause 'Protocol error, unspecified' (111)
DMM NOTICE gprs_gmm.c:1476 <- ROUTING AREA UPDATE REJECT

This assumption (NMO III) seems to be hard-coded in SGSN, and needs to be fixed. Even though, I don't think osmo-sgsn is able to handle combined Attach / RA Update requests. Please see the attached capture.

Actions #6

Updated by laforge over 3 years ago

  • Related to Feature #1599: Gs interface (BSSMAP+) between SGSN and MSC/VLR added
Actions #7

Updated by laforge over 3 years ago

  • Related to Feature #1583: Gs interface (BSSMAP+) between SGSN and MSC/VLR added
Actions #8

Updated by laforge over 3 years ago

  • Status changed from New to Rejected

fixeria wrote:

I am wondering whether NMO I would imply that the MS is allowed to do combined Attach on PS (and thus omit CS Location Update)?

I did a quick test, and the answer is YES. The phone requested combined GPRS/IMSI Attach.

Ok, so the result is clear: We must stay in NMO_II until we imlpement the Gs interface between MSC and SGSN. As that is discussed ion #1583, we can reject this issue as invalid.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)