Feature #4485
closed
osmo-bsc: We should be announcing NMO I instead of NMO II
Added by pespin about 4 years ago.
Updated almost 4 years ago.
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
- 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
- Related to Bug #2406: CS-PAGING not implemented added
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?
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.
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.
- Related to Feature #1599: Gs interface (BSSMAP+) between SGSN and MSC/VLR added
- Related to Feature #1583: Gs interface (BSSMAP+) between SGSN and MSC/VLR added
- 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.
Also available in: Atom
PDF
