Feature #4485
closedosmo-bsc: We should be announcing NMO I instead of NMO II
0%
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
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
Updated by fixeria almost 4 years ago
- Related to Bug #2406: CS-PAGING not implemented added
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?
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.
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.
Updated by laforge almost 4 years ago
- Related to Feature #1599: Gs interface (BSSMAP+) between SGSN and MSC/VLR added
Updated by laforge almost 4 years ago
- Related to Feature #1583: Gs interface (BSSMAP+) between SGSN and MSC/VLR added
Updated by laforge almost 4 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.