Feature #5501
openMS-side GPRS Mobility Management (GMM) + Session Management (SM)
Added by laforge about 2 years ago. Updated 7 months ago.
80%
Description
In order to support GPRS from the MS side, we will need a GMM + SM implementation on the mobile side.
The network side is already implemented as part of osmo-sgsn
Related issues
Updated by laforge about 2 years ago
- Related to Feature #5500: MS-Side GPRS RLC/MAC implementation added
Updated by laforge about 2 years ago
- Related to Feature #5502: MS-side LLC implementation added
Updated by pespin about 1 year ago
- Spec Reference changed from 3GPP TS 24.008 to 3GPP TS 24.008, 3GPP TS 44.018
Updated by pespin about 1 year ago
- 3GPP TS 24.008:
- section 4 "Elementary procedures for Mobility Management"
- section 9.4 "GPRS Mobility Management Messages"
- 3GPP TS 24.007:
- section 6.6 "Registration Services for GPRS-Services"
- section 9.4 "Services provided by the LLC entity for GPRS services (GSM only)"
- section 9.5 "Services provided by the GMM for GPRS services"
- gprs_gmm.{c,h}, gprs_gmm_attach.{c,h}, gprs_gmm_fsm.{c,h}
- 3GPP TS 24.008:
- section 6 "Support for packet services"
- section 9.5 "GPRS Session Management Messages"
- 3GPP TS 24.007:
- section 6.5.1 "Session Management Services for SMREG-SAP"
- section 9.5 "Services provided by the GMM for GPRS services"
- osmo-sgsn.git gprs_sm.{c,h}
Updated by pespin about 1 year ago
- Spec Reference changed from 3GPP TS 24.008, 3GPP TS 44.018 to 3GPP TS 24.008
Updated by pespin about 1 year ago
- Spec Reference changed from 3GPP TS 24.008 to 3GPP TS 24.008, 3GPP TS 24.007
Updated by pespin about 1 year ago
- Status changed from New to In Progress
- Assignee set to pespin
- % Done changed from 0 to 20
I can already play with the modem app sending GMM messages and advancing a bit with FSMs in the GPRS Attach procedure with following patches:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32021 gmm: Initial implementation of GPRS Attach
https://gerrit.osmocom.org/c/osmocom-bb/+/32022 layer23: modem: Test GMM layer through VT
Updated by pespin about 1 year ago
- % Done changed from 20 to 40
- I submitted to gerrit patches implementing initial GMM GPRS detach procedure logic in libosmo-gps-gmm.so and layer23/modem app.
- I started writing all the boilerplate code to have libosmo-gprs-sm.so in libosmo-gprs.git.
The implementations are not complete by any means, but it should provide a baseline to test with most of the itnerfaces already in place, and then we can start ant work fixing/improving stuff here and there while testing and going forward.
Updated by fixeria about 1 year ago
After fixing a bug in libosmo-gprs-rlcmac, I am still not able to complete the attach procedure.
Here is some logging (make sure to apply this patch):
https://gerrit.osmocom.org/c/osmocom-bb/+/32060 layer23: add missing log_info_cat[] entry for DGMM [NEW]
DGMM INFO gmm_prim.c:426 Rx from upper layers: GMMREG-ATTACH.request
DGMM INFO fsm.c:456 GMM_MS[0x561735480e30]{Null}: Allocated
DGMM INFO gmm_ms_fsm.c:293 GMM_MS[0x561735480e30]{Null}: Received Event ENABLE_GPRS_MODE
DGMM INFO gmm_ms_fsm.c:40 GMM_MS[0x561735480e30]{Null}: state_chg to Deregistered
DGMM INFO gmm.c:283 GMME(PTMSI-e1c5d364) Tx GMM ATTACH REQUEST (new P-TMSI=0xe1c5d364)
DLLC INFO llc_prim.c:157 Rx from upper layers: LL-UNITDATA.request
DLLC NOTICE llc_ll.c:228 Rx LL-UNITDATA.request: unknown TLLI 0xe1c5d364, creating LLME on the fly
DLLC DEBUG llc.c:144 modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 01 08 01 04 97 07 00 00 01 0a 00 05 f4 e1 c5 d3 64 00 f0 00 00 00 00 00 fd d1 f4 ]
DRR NOTICE grr.c:94 Sending CHANNEL REQUEST (0x7e)
DGMM INFO gmm_prim.c:351 GMM_MS[0x561735480e30]{Deregistered}: Received Event ATTACH_REQUESTED
DGMM INFO gmm_ms_fsm.c:57 GMM_MS[0x561735480e30]{Deregistered}: state_chg to RegisteredInitiated
DRSL NOTICE grr.c:411 Rx RACH.conf (RA=0x7e, T1=23, T3=37, T2=16)
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=1 (GMM), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=9a8ede
DLLC DEBUG llc.c:610 LLE(ffffffff/e1c5d364,GMM){UNASSIGNED} Rx SAPI=1 (GMM), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=9a8ede
DLLC DEBUG llc.c:100 modem_llc_prim_up_cb(): Rx LL-UNITDATA.indication TLLI=0xe1c5d364 SAPI=GMM l3=[08 15 02 ]
DGMM INFO gmm_prim.c:595 Rx from lower layers: LL-UNITDATA.indication
DGMM DEBUG gmm.c:431 GMME(PTMSI-e1c5d364) Rx GMM IDENTITY REQUEST mi_type=IMEI
DGMM INFO gmm.c:215 GMME(PTMSI-e1c5d364) Tx GMM IDENTITY RESPONSE
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
Updated by fixeria about 1 year ago
fixeria wrote in #note-11:
After fixing a bug in libosmo-gprs-rlcmac, I am still not able to complete the attach procedure.
After a bit more testing, I see that the GMM layer does enqueue GMM Identity Response, but the LLC layer does not seem to get it?
Compare these two logging snippets:
DGMM INFO gmm.c:283 GMME(PTMSI-e1c5d364) Tx GMM ATTACH REQUEST (new P-TMSI=0xe1c5d364) DLLC INFO llc_prim.c:157 Rx from upper layers: LL-UNITDATA.request DLLC NOTICE llc_ll.c:228 Rx LL-UNITDATA.request: unknown TLLI 0xe1c5d364, creating LLME on the fly ... DGMM INFO gmm_prim.c:595 Rx from lower layers: LL-UNITDATA.indication DGMM DEBUG gmm.c:431 GMME(PTMSI-e1c5d364) Rx GMM IDENTITY REQUEST mi_type=IMEI DGMM INFO gmm.c:215 GMME(PTMSI-e1c5d364) Tx GMM IDENTITY RESPONSE DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695980 Rx Pkt DL Dummy Ctrl Block DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695984 Rx Pkt DL Dummy Ctrl Block DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695988 Rx Pkt DL Dummy Ctrl Block DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695993 Rx Pkt DL Dummy Ctrl Block DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695997 Rx Pkt DL Dummy Ctrl Block DRLCMAC INFO rlcmac.c:502 TS=7 FN=1696001 Rx Pkt DL Dummy Ctrl Block DRLCMAC INFO rlcmac.c:502 TS=7 FN=1696006 Rx Pkt DL Dummy Ctrl Block DRLCMAC INFO rlcmac.c:502 TS=7 FN=1696010 Rx Pkt DL Dummy Ctrl Block
Note that there is no Rx from upper layers: LL-UNITDATA.request in the second case.
Updated by fixeria about 1 year ago
fixeria wrote in #note-12:
Note that there is no
Rx from upper layers: LL-UNITDATA.requestin the second case.
gdb tells me that gprs_gmm_tx_id_resp() returns early because gprs_gmm_build_identity_resp() returns -22 (-EINVAL).
This is happening because osmo_mobile_identity_encode_msgb() fails, most likely because gmme->imei is not populated.
I believe we should have slightly more verbose logging in the enc/dec functions like this one, otherwise debugging stuff takes longer.
Updated by fixeria about 1 year ago
fixeria wrote in #note-13:
This is happening because
osmo_mobile_identity_encode_msgb()fails, most likely becausegmme->imeiis not populated.
I hard-coded both IMSI and IMEI in gprs_gmm_build_identity_resp(), and saw osmo-sgsn sending GMM ATTACH ACCEPT:
DLLC NOTICE gprs_llc.c:552 LLME(ffffffff/e1c5d364){UNASSIGNED} LLC RX: unknown TLLI 0xe1c5d364, creating LLME on the fly
DMM INFO gprs_gmm.c:1198 MM(---/ffffffff) -> GMM ATTACH REQUEST
DLLC NOTICE gprs_llc.c:1079 LLME(ffffffff/e1c5d364){UNASSIGNED} LLGM Assign pre (e1c5d364 => c91ffe37)
DLLC NOTICE gprs_llc.c:1125 LLME(e1c5d364/c91ffe37){ASSIGNED} LLGM Assign post (e1c5d364 => c91ffe37)
DLGSUP INFO gsup_client.c:266 GSUP ping callback (connected, got PONG)
DMM ERROR gprs_gmm.c:114 MM(/c91ffe37) Stopping MM timer 3370 but 0 is running
DMM ERROR gprs_gmm.c:114 MM(/c91ffe37) Stopping MM timer 3370 but 0 is running
DMM INFO sgsn_auth.c:195 MM(901700000034128/c91ffe37) Missing information, requesting subscriber data
DGPRS INFO gprs_subscriber.c:817 SUBSCR(901700000034128) subscriber data is not available
DGPRS INFO gprs_subscriber.c:210 SUBSCR(901700000034128) Sending GSUP, will send: 04 01 08 09 71 00 00 00 43 21 f8 28 01 01 2a 01 01
DGPRS INFO gprs_subscriber.c:722 SUBSCR(901700000034128) Received GSUP message OSMO_GSUP_MSGT_INSERT_DATA_REQUEST
DGPRS INFO gprs_subscriber.c:367 SUBSCR(901700000034128) Will set PDP info, context id = 1, APN = 01 2a
DMM INFO mmctx.c:430 MM(901700000034128/c91ffe37) Subscriber data update
DMM INFO sgsn_auth.c:246 MM(901700000034128/c91ffe37) Got authorization update: state unknown -> accepted
DMM NOTICE gprs_gmm.c:994 MM(901700000034128/c91ffe37) Authorized, continuing procedure, IMSI=901700000034128
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)
DGPRS INFO gprs_subscriber.c:210 SUBSCR(901700000034128) Sending GSUP, will send: 12 01 08 09 71 00 00 00 43 21 f8 28 01 01
DGPRS INFO gprs_subscriber.c:722 SUBSCR(901700000034128) Received GSUP message OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT
DMM INFO mmctx.c:430 MM(901700000034128/c91ffe37) Subscriber data update
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)
DLNSSIGNAL INFO gprs_ns2_message.c:207 NSE(00101)-NSVC(00101) Tx NS-ALIVE
DLNSSIGNAL INFO gprs_ns2.c:1309 NSE(00101)-NSVC(00101) Rx NS-ALIVE
DLNSSIGNAL INFO gprs_ns2_message.c:207 NSE(00101)-NSVC(00101) Tx NS-ALIVE-ACK
DLNSSIGNAL INFO gprs_ns2.c:1309 NSE(00101)-NSVC(00101) Rx NS-ALIVE-ACK
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)
DLGSUP INFO gsup_client.c:266 GSUP ping callback (connected, got PONG)
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)
However, the modem app crashed:
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=1 (GMM), UI func=UI C/R=0 PM=1 E=0 IP=0 N(U)=3 FCS=9ebca5
DLLC DEBUG llc.c:610 LLE(ffffffff/e1c5d364,GMM){UNASSIGNED} Rx SAPI=1 (GMM), UI func=UI C/R=0 PM=1 E=0 IP=0 N(U)=3 FCS=9ebca5
DLLC DEBUG llc.c:100 modem_llc_prim_up_cb(): Rx LL-UNITDATA.indication TLLI=0xe1c5d364 SAPI=GMM l3=[08 02 01 2a 44 09 f1 07 00 01 00 17 16 18 05 f4 c9 1f fe 37 ]
DGMM INFO gmm_prim.c:595 Rx from lower layers: LL-UNITDATA.indication
DGMM DEBUG gmm.c:354 GMME(PTMSI-e1c5d364) Rx GMM ATTACH ACCEPT
DGMM ERROR gmm.c:58 modem_gmm_prim_up_cb(): Rx GMMREG-ATTACH.confirm UNIMPLEMENTED
DLLC INFO llc_prim.c:157 Rx from upper layers: LLGM-ASSIGN.request
DLLC NOTICE llc_llgmm.c:141 LLME(ffffffff/e1c5d364){UNASSIGNED} LLGM Assign pre (e1c5d364 => c91ffe37)
DLLC NOTICE llc_llgmm.c:185 LLME(e1c5d364/c91ffe37){ASSIGNED} LLGM Assign post (e1c5d364 => c91ffe37)
DGMM ERROR gmm.c:78 modem_gmm_prim_down_cb(): Unexpected Rx GMRR-ASSIGN.request
Assert failed 0 gmm.c:79
Updated by pespin about 1 year ago
fixeria wrote in #note-14:
fixeria wrote in #note-13:
This is happening because
osmo_mobile_identity_encode_msgb()fails, most likely becausegmme->imeiis not populated.I hard-coded both IMSI and IMEI in
gprs_gmm_build_identity_resp(), and saw osmo-sgsn sendingGMM ATTACH ACCEPT:
Yes, that's probably because we are not filing the "imei", "imsi", etc. fields in the GMM-ASSIGN.req primitive in the modem app. I guess we can hardcode those in the modem app for now, and later fill them using some stuff already available in the "mobile" app by moving it to common/
DGMM ERROR gmm.c:78 modem_gmm_prim_down_cb(): Unexpected Rx GMRR-ASSIGN.request
We are missing forwarding GMMRR primitives to rlcmac stack in the modem app.
Updated by pespin about 1 year ago
pespin wrote in #note-15:
fixeria wrote in #note-14:
fixeria wrote in #note-13:
This is happening because
osmo_mobile_identity_encode_msgb()fails, most likely becausegmme->imeiis not populated.I hard-coded both IMSI and IMEI in
gprs_gmm_build_identity_resp(), and saw osmo-sgsn sendingGMM ATTACH ACCEPT:Yes, that's probably because we are not filing the "imei", "imsi", etc. fields in the GMM-ASSIGN.req primitive in the modem app. I guess we can hardcode those in the modem app for now, and later fill them using some stuff already available in the "mobile" app by moving it to common/
https://gerrit.osmocom.org/c/osmocom-bb/+/32081 layer23: modem: fill imsi & imei in vty 'test gmm attach'
DGMM ERROR gmm.c:78 modem_gmm_prim_down_cb(): Unexpected Rx GMRR-ASSIGN.request
We are missing forwarding GMMRR primitives to rlcmac stack in the modem app.
Feel free to give it a try with this one applied:
https://gerrit.osmocom.org/c/osmocom-bb/+/32080 layer23: modem: Forward GMMRR primitives between GMM and RLCMAC layers
Still, I think RLC/MAC may be asswerting when reciving that primitive because it's not yet implemented iirc.
Updated by pespin about 1 year ago
I submitted an initial implementation of SM layer in libosmo-gprs-sm and use it through a VTY command in "modem" app:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32154 Introduce libosmo-gprs-sm
https://gerrit.osmocom.org/c/osmocom-bb/+/32155 modem: initial SM layer support through libosmo-gprs-sm
Updated by pespin about 1 year ago
- % Done changed from 40 to 50
After those are merged, the idea is to run manual tests iteratively and implement/fix stuff to go forward until we reach a point where the tun is set up and we can transmit data from it.
Right now, the major blocker for me to continue forward with upper layers (LLC/SNDCP/GMM/SM) is that lower layers (RLCMAC GRR and L1CTL scheduler) have some problems transmitting data on time and hence they are dropped by trxcon or ignored by osmo-pcu.
Furthermore, I need to find out the best way (API) to go back to MS idle mode when an MS becomes empty of TBFs.
Once those 2 things are solved, we can focus and advance quickly on upper layers using manual testing.
Updated by pespin about 1 year ago
I started implementing some missing bits in the SNSM interface (SM<->SNDCP) which I was skipping so far during PDP Ctx Activiation:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32295 sm: Start using SNSM SAP
https://gerrit.osmocom.org/c/osmocom-bb/+/32296 layer23: modem: Forward SNSM primitives SNDCP<->SM layers
I still need to check whether the SNSM-ACTIVATE.ind/resp are properly implemented in SNDCP (probably they are not).
Updated by pespin 12 months ago
- % Done changed from 50 to 60
At the current state, with all the patches for libosmo-gprs.git and osmocom-bb.git I submitted to gerrit, the "modem" app at startup is already able to do GPRS attach procedure (GMM AttReq+IdReq+IdResp+CiphReq+CiphAcc+AttAcc+AttCompl) plus SM Activate PDP Context (Req+Accept) and set the allocated IP address (IPv4 only) in the APN-related tunnel interface.
Relevant stuff still missing:
- GMM: RAU procedure is still missing (not implemented) (TS 24.008 4.7.5)
- GMM: MS Radio Capabilities still hardcoded or missing.
- GMM: From "modem" app somehow being able to enable/disable GPRS from VTY, hence allowing GPRS detaching
- SM: Deactivating the PDP context when the APN is switched to "shutdown" state
In general the upper layers seem to be working more or less reliably, but I'm still having problems with instabilities due to several bugs spotted in lower layers (rlcmac and below) which make things fail more than succeed.
With virtphy the current situation is a bit better, but in there till maybe I get the entire thing to work 1/10th of the times.
Updated by pespin 11 months ago
libosmo-gprs-gmm periodic RAU support implemented here:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32925
I still need to store received/updated RAI/PTMSI/PTMSI_SIG from RAU into the SIMcard LOCIGPRS file. I probably need to add an extra primitive indication in GMMREG to indicate the updates to the MS.
Updated by pespin 11 months ago
- Related to Feature #5504: GSM/GPRS coordination (RR/GRR) added
Updated by pespin 11 months ago
- Related to Feature #5505: GPRS mobility (cell change) support added
Updated by pespin 11 months ago
I still need to store received/updated RAI/PTMSI/PTMSI_SIG from RAU into the SIMcard LOCIGPRS file. I probably need to add an extra primitive indication in GMMREG to indicate the updates to the MS.
If RAU fails (rx RAU Reject) we also need to indicate somehow to the app/SIM, so that it can erase LOCIGPRS and change GU state, eg "GU3 ROAMING NOT ALLOWED".
We basically need some primitive informing the app about states:
- attach updated (RAI, PTMSI, etc. are updated during RAU ACC)
- attach failed (RAU REJ)
- detach initiated by network (GMMREG-DETACH.ind, this already exists specified, so no problem here).
One solution would to be submit GMMREG-ATTACH.cnf_acc each time there's a RAU ACC, and submit a GMMREG-ATTACH.cnf_rej each time there's a RAU REJ, even if there was no GMMREG-ATTACH.req or it was already answered during ATTACH ACC.
Another solution would be to add a new GMM-ATTACH.ind with also acc/rej similar to GMMREG-ATTACH.cnf.
TS 24.007 6.6.1.6 GMMREG-DETACH-IND says: "A network initiated detach has been performed. Or the detach has been performed locally due to expiration of the
standby timer or a failed routing area update". The registration services provided at the service access point GMMREG-SAP are illustrated in the state machine of
figure 6.6 below. Note, that in state registered the MS may be suspended from GPRS mobility management due to an
ongoing CS connection. The registration procedure Routing Area Updating, which is not provided at the GMMREG-
SAP, is not visible within the diagram."
So the above seems to indicate that:
- attach updated (RAI, PTMSI, etc. are updated during RAU ACC) => Add a new GMMREG-ATTACH.ind(cause?, RAI, PTMSI, PTMSI_SIG) (maybe name it GMMREG-RAU.ind?)
- attach failed (RAU REJ) > GMMREG-DETACH.ind(cause)
- detach initiated by network > GMMREG-DETACH.ind(cause)
Updated by pespin 7 months ago
- Status changed from In Progress to Stalled
- % Done changed from 60 to 80
- attach updated (RAI, PTMSI, etc. are updated during RAU ACC) => Add a new GMMREG-ATTACH.ind(cause?, RAI, PTMSI, PTMSI_SIG) (maybe name it GMMREG-RAU.ind?)
This has been implemented with OSMO_PRIM(OSMO_GPRS_GMM_GMMSM_MODIFY, PRIM_OP_INDICATION) some time ago.
Marking as stalled since this layer is in general doing its job and the focus is right now on the lower layers which are creating most of the instabilities.
