CRs to R99 and older releases on Work Item GPRS

Transcription

1 3GPP TSG CN Plenry Meeting #10, Bngkok, Thilnd 6 th 8 th December 2000 Tdoc NP Source: TSG CN WG 1 Title: Agend item: 7.13 Document for: CRs to R99 nd older releses on Work Item GPRS APPROVAL Introduction: This document contins 23 CRs on R99 nd older releses Work Item GPRS, tht hve been greed by TSG CN WG1, nd re forwrded to TSG CN Plenry meeting #10 for pprovl. Spec CR Rev Doc-2nd-Level Phse Subject Ct Ver_C N R99 APN used for detection of duplicted PDP context F N Rel-4 APN used for detection of duplicted PDP context A N R99 Clrifiction of RAB re-estblishment F N Rel-4 Clrifiction of RAB re-estblishment A N R99 Clrifiction of response hndling of Service F N Rel-4 Clrifiction of response hndling of Service A N R99 Clrifiction to the network initited GPRS detch F N Rel-4 Clrifiction to the network initited GPRS detch A A145 N R99 Correction in TOM protocol heder F A146 N R97 Correction of IOV-UI negotition F A147 N R98 Correction of IOV-UI negotition A A148 N R99 Correction of IOV-UI negotition A N R99 Correction of PDP context dupliction hndling F N Rel-4 Correction of PDP context dupliction hndling A A105 N R97 Correction of updte sttus on Authentiction F A105 N R98 Correction of updte sttus on Authentiction A N R99 Correction of updte sttus on Authentiction A N Rel-4 Correction of updte sttus on Authentiction A N R99 DRX prmeter rnge correction F N Rel-4 DRX prmeter rnge correction A N R99 RABMAS-SAP nd RABMSM-SAP dpttion F N R99 Unsynchronized PDP contexts hndling - MS less F N Rel-4 Unsynchronized PDP contexts hndling - MS less A 4.0.0

2 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR A145 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Correction in TOM protocol heder Motorol Work item code: GPRS Dte: Sep. 26, 2000 Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: Fig. B.1 is not consistent with sections B.1.1, B.1.2. Summry of chnge: Fig. B.1 is revised. Consequences if not pproved: Cluses ffected: B.1 Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

3 2 3G.bbb Version x.y.z (YYYY-MM) B.1 TOM Protocol Envelope structure All TOM protocol peer-to-peer exchnges shll be in TOM Protocol Envelopes conforming to the formt shown in Figure B.1. The TOM Protocol Heder shll consist of the TOM Protocol Discrimintor, Remining Length of TOM Protocol Heder, nd Remining Octets of TOM Protocol Heder fields, nd is minimum of 1 octet nd mximum of 15 octets long TOM Protocol Discrimintor Remining Length of TOM Protocol Heder Remining Length of TOM Protocol Heder TOM Protocol Discrimintor Remining Octets of TOM Protocol Heder (vrible length, mx. 14 octets) Messge Cpsule (vrible length, mx. 220 octets) Figure B.1: TOM Protocol Envelope formt B.1.1 TOM Protocol Discrimintor TOM Protocol Discrimintor indictes the specific technology using TOM, nd is coded s follows: bits Not specified TIA/EIA-136 [22] Reserved for extension All other vlues re reserved If ny other vlue thn is received, then the TOM Protocol Envelope shll be discrded with no further ction. B.1.2 Remining Length of TOM Protocol Heder Remining Length of TOM Protocol Heder indictes the number of octets remining in the TOM-protocol-heder prt of the TOM Protocol Envelope, nd is coded s follows: bits octets remining in TOM protocol heder octet remining in TOM protocol heder octets remining in TOM protocol heder Reserved for extension If the vlue is received, then the TOM Protocol Envelope shll be discrded with no further ction. CR pge 2

4 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR A146 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Correction of IOV-UI negotition Motorol Work item code: GPRS Dte: Sep. 26, 2000 Ctegory: F Relese: R97 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The current version of does not permit the negotition of IOV-UI prmeter fter ciphering is enbled. However, ccording to the discussion in document N , IOV-UI negotition must be permitted fter ciphering hs been enbled. Otherwise, the two LLC peers will never mnge to negotite new IOV-UI vlue nd will lwys use the defult IOV-UI. Summry of chnge: The CR proposes to remove the condition stting tht the IOV-UI negotition is llowed only before ciphering is enbled. Consequences if not pproved: In ddition, the CR elimintes the need to specify the (missing) exception cse where n ttempt is mde to negotite IOV-UI fter ciphering is enbled. Cluses ffected: Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: Relted to Tdoc N

5 2 3G.bbb Version x.y.z (YYYY-MM) Exchnge Identifiction (XID) commnd/response This frme shll be used to negotite nd re-negotite LLC lyer prmeters nd lyer-3 prmeters. XID frmes cn be trnsmitted in ADM nd ABM. The negotition procedure is one-step, i.e., one side shll strt the process by sending n XID commnd, offering certin set of prmeters from the pplicble prmeter repertoire (see Tble 1) the sending entity wnts to negotite, proposing vlues within the llowed rnge. In return, the other side shll send n XID response, either confirming these prmeter vlues by returning the requested vlues, or offering higher or lower ones in their plce. As n optimistion, prmeters confirming the requested vlues my be omitted from the XID response. See Tble 1 for sense of negotition. This shll end the negotition process. Prmeters tht re not included in neither the XID commnd nor in the XID response, shll retin their current vlues. The responding side my respond with prmeters tht were not included in the XID commnd. A prmeter tht ws not included in the XID commnd shll in this cse be treted s if the current vlue of the prmeter ws included in the XID commnd. The responding side shll include such prmeter in every XID response until the prmeter hs been explicitly negotited, either by responding to n XID commnd tht included the prmeter, or by explicitly including the prmeter the next time n XID commnd is trnsmitted. Both entities shll support the negotited vlues, however under certin conditions one or more prmeters my need to be re-negotited (e.g., in the cse of chnge in SGSN). XID frmes shll lwys be used with the P/F bit set to 1. Without ny prior XID exchnge, defult vlues shll pply. Negotited XID prmeters shll pply to the LLE identified by the DLCI of the XID frmes used, except Version, Reset, nd IOV-UI tht pplies to n LLME (i.e., TLLI), nd except Lyer-3 Prmeters tht pply to the lyer 3 bove the LLE. Tble 1 lists the negotible LLC lyer prmeters. Figure 1 shows the formt of the XID prmeter field. Bit XL Type Length Length X X High-order octet Low-order octet Octet or 3 n Figure 1: XID prmeter field formt A prmeter item consists of one or two type/length octets followed by the vlue of tht prmeter. The XID Length (XL) bit indictes whether the Length field is 2 bits or 8 bits long. If XL is set to 0, then Length consists of 2 bits nd type/length occupies one octet. If XL is set to 1 then Length consists of 8 bits nd type/length occupies two octets. The length indictor gives the number of octets tht the vlue ctully occupies. Length shll be set to the vlue in Tble 1 for XID prmeters tht do not hve vrible length. The prmeter items cn be rrnged in rbitrry order. The prmeter items shll begin in the first octet of the XID informtion field nd follow on contiguously.

6 3 3G.bbb Version x.y.z (YYYY-MM) Tble 1: LLC lyer prmeter negotition Prmeter Nme Type Length Formt ( ) Version (LLC version number) IOV-UI (ciphering Input offset vlue for UI frmes), common for ll SAPIs of TLLI IOV-I (ciphering Input offset vlue for I frmes), for the SAPI under negotition T200 (retrnsmission time-out) N200 (mximum number of retrnsmissions) N201-U (mximum informtion field length for U nd UI frmes) N201-I (mximum informtion field length for I frmes) md (I frme buffer size in the downlink direction) mu (I frme buffer size in the uplink direction) bbbb 0 through bbbbbbbb 0 through bbbbbbbb bbbbbbbb bbbbbbbb 2 4 bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb Rnge Units Sense of Negotition - down 0 through bbbb bbbbbbbb 1 through bbbb 1 through bbb 140 bbbbbbbb through bbb bbbbbbbb 7 2 0bbbbbbb bbbbbbbb 8 2 0bbbbbbb bbbbbbbb through , 9 through , 9 through seconds up - up octets octets down down 16 octets down 16 octets down kd (window size in the 9 1 bbbbbbbb 1 through frmes down downlink direction) 255 ku (window size in the 10 1 bbbbbbbb 1 through frmes down uplink direction) 255 Lyer-3 Prmeters 11 Vrible See GSM Reset The Rnge for N201-U for SAPI 1 is 400 through octets, nd for SAPI through octets. - All other Types nd Rnges re reserved for future versions of the present document. - The length for Lyer-3 Prmeters shll be set equl to the number of octets received from lyer 3. If n empty XID block is received from lyer 3, the LLE shll include zero-length Lyer-3 Prmeters XID prmeter in the XID prmeter field to llow the receiving LLE to distinguish between LLC nd lyer-3 initited procedures. Version shll not be negotited while in ABM. Reset shll only be negotited with n XID frme, nd only be trnsmitted in the downlink direction. If Reset is present in n XID frme, then it shll be the first XID prmeter in the XID informtion field. IOV-UI shll only be negotited in ADM., nd only before ciphering is enbled. IOV-I shll only be negotited with SABM nd UA frmes. IOV-UI nd IOV-I shll only be trnsmitted in the downlink direction. T200, N200, nd N201-U cn be negotited in ADM nd ABM. The new vlues of T200 shll only pply to timers set fter the negotition hs been completed. If N201-U is negotited to lower vlue thn previously used, then ny queued or new U nd UI frmes tht violtes the new vlue of N201-U should be discrded nd not trnsmitted. N201-I, md, mu, kd, nd ku cn be negotited to ny vlue in Rnge in ADM. In ABM, N201-I, md, mu, kd, nd ku cn only be negotited to the sme or higher vlue s previously used.

7 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR A147 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Correction of IOV-UI negotition Motorol Work item code: GPRS Dte: Sep. 26, 2000 Ctegory: A Relese: R98 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The current version of does not permit the negotition of IOV-UI prmeter fter ciphering is enbled. However, ccording to the discussion in document N , IOV-UI negotition must be permitted fter ciphering hs been enbled. Otherwise, the two LLC peers will never mnge to negotite new IOV-UI vlue nd will lwys use the defult IOV-UI. Summry of chnge: The CR proposes to remove the condition stting tht the IOV-UI negotition is llowed only before ciphering is enbled. Consequences if not pproved: In ddition, the CR elimintes the need to specify the (missing) exception cse where n ttempt is mde to negotite IOV-UI fter ciphering is enbled. Cluses ffected: Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: Relted to Tdoc N

10 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR A148 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Correction of IOV-UI negotition Motorol Work item code: GPRS Dte: Sep. 26, 2000 Ctegory: A Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The current version of does not permit the negotition of IOV-UI prmeter fter ciphering is enbled. However, ccording to the discussion in document N , IOV-UI negotition must be permitted fter ciphering hs been enbled. Otherwise, the two LLC peers will never mnge to negotite new IOV-UI vlue nd will lwys use the defult IOV-UI. Summry of chnge: The CR proposes to remove the condition stting tht the IOV-UI negotition is llowed only before ciphering is enbled. Consequences if not pproved: In ddition, the CR elimintes the need to specify the (missing) exception cse where n ttempt is mde to negotite IOV-UI fter ciphering is enbled. Cluses ffected: Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: Relted to Tdoc N

13 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 267 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Clrifiction to the network initited GPRS detch procedure (IMSI detch) Siemens AG Work item code: GPRS Dte: 07 November 00 Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: According to the stndrd, MS in opertion mode A or B in network opertion mode I which ws detched by the network with detch type IMSI detch shll perform combined routing re updting procedure to re-ttch for non-gprs services. Summry of chnge: See reson for chnge. Consequences if not pproved: Cluses ffected: It is clrified tht to this purpose the MS shll use the usul combined routing re updting procedure specified in section nd shll set the MM updte sttus to U2 NOT UPDATED. This prevents the MS from performing MM connection mngement procedures vi the A/Iu interfce while the combined routing re updting is running. A possible collision in the MSC/VLR between MM connection mngement procedure (performed vi the A/Iu interfce) nd MM specific procedure (Loction Updte vi the Gs interfce) could result in the rejection of cll. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

14 Network initited GPRS detch procedure Network initited GPRS detch procedure initition The network initites the GPRS detch procedure by sending DETACH REQUEST messge to the MS. The DETACH REQUEST messge shll include detch type IE. In ddition, the network my include cuse IE to specify the reson for the detch request. The network shll strt timer T3322. If the detch type IE indictes "re-ttch not required" or "re-ttch required", the network shll dectivte the PDP contexts nd dectivte the logicl link(s), if ny, nd shll chnge to stte GMM-DEREGISTERED-INITIATED Network initited GPRS detch procedure completion by the MS When receiving the DETACH REQUEST messge nd the detch type IE indictes "re-ttch not required" or "rettch required", the MS shll dectivte the PDP contexts nd dectivte the logicl link(s), if ny. The MS shll then send DETACH ACCEPT messge to the network nd shll chnge stte to GMM-DEREGISTERED. The MS shll, fter the completion of the GPRS detch procedure, initite GPRS ttch procedure if indicted by the network in the detch type IE. A GPRS MS operting in MS opertion mode A or B in network opertion mode I, which receives n DETACH REQUEST messge with detch type indicting "re-ttch required" or "re-ttch not required" nd no cuse code, is only detched for GPRS services in the network. When receiving the DETACH REQUEST messge nd the detch type IE indictes "IMSI detch", the MS shll not dectivte the PDP contexts. The MS shll set the MM updte sttus to U2 NOT UPDATED. A MS in opertion mode A or B in network opertion mode I my send DETACH ACCEPT messge to the network, nd shll re-ttch to non- GPRS service by performing the combined routing re updting procedure ccording to section , sending ROUTING AREA UPDATE REQUEST messge with Updte type IE indicting "combined RA/LA updting with IMSI ttch". A MS in opertion mode C, or in MS opertion mode A or B in network opertion mode II or III, shll send DETACH ACCEPT messge to the network. If the detch type IE indictes "IMSI detch", or "re-ttch required" then the MS shll ignore the cuse code if received. If the detch type informtion element vlue indictes "re-ttch required" or "re-ttch not required" nd the MS is ttched for GPRS nd non-gprs services nd the network opertes in network opertion mode I, then if in the MS the timer T3212 is not lredy running, the timer T3212 shll be set to its initil vlue nd restrted. If the detch type IE indictes "re-ttch required", the MS shll perform new ttch procedure. The MS should lso ctivte PDP context(s) to replce ny previously ctive PDP contexts. NOTE: In some cses, user interction my be required nd then the MS cnnot ctivte the PDP context(s) utomticlly. If the detch type IE indictes "re-ttch not required", then, depending on the received cuse code, the MS shll ct s follows: # 2 (IMSI unknown in HLR) The MS shll set the updte sttus to U3 ROAMING NOT ALLOWED nd shll delete ny TMSI, LAI nd ciphering key sequence number. The new MM stte is MM IDLE. The SIM shll be considered s invlid for non-gprs services until switching off or the SIM is removed. A GPRS MS operting in MS opertion mode A or B in network opertion mode I, is still IMSI ttched for GPRS services in the network. # 3 (Illegl MS); or # 6 (Illegl ME) The MS shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED (nd shll store it ccording to section ) nd shll delete ny P-TMSI, P-TMSI signture, RAI nd GPRS ciphering key sequence CR pge 2

15 number. The new GMM stte is GMM-DEREGISTERED. The SIM shll be considered s invlid for GPRS services until switching off or the SIM is removed. A GPRS MS operting in MS opertion mode A or B shll in ddition set the updte sttus to U3 ROAMING NOT ALLOWED, shll delete ny TMSI, LAI nd ciphering key sequence number. The new MM stte is MM idle. The SIM shll be considered s invlid lso for non-gprs services until switching off or the SIM is removed. # 7 (GPRS services not llowed) The MS shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED (nd shll store it ccording to section ) nd shll delete ny P-TMSI, P-TMSI signture, RAI nd GPRS ciphering key sequence number. The SIM shll be considered s invlid for GPRS services until switching off or the SIM is removed. The new stte is GMM-DEREGISTERED. A GPRS MS operting in MS opertion mode A or B in network opertion mode I, is still IMSI ttched for CS services in the network. # 8 (GPRS services nd non-gprs services not llowed) The MS shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED nd the updte sttus to U3 ROAMING NOT ALLOWED (nd shll store it ccording to section ). Furthermore, it shll delete ny P- TMSI, P-TMSI signture, TMSI, RAI, LAI, ciphering key sequence number nd GPRS ciphering key sequence number nd shll consider the SIM s invlid for GPRS nd non-gprs services until switching off or the SIM is removed. # 11 (PLMN not llowed); # 12 (Loction re not llowed); or # 13 (Roming not llowed in this loction re) The MS shll delete ny RAI or LAI, P-TMSI, P-TMSI signture nd GPRS ciphering key sequence number, shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED (nd shll store it ccording to section ). A GPRS MS operting in MS opertion mode A or B shll in ddition set the updte sttus to U3 ROAMING NOT ALLOWED nd shll delete ny TMSI, LAI nd ciphering key sequence number. The new MM stte is MM IDLE. The MS shll store the LAI or the PLMN identity in the pproprite forbidden list, i.e. in the "forbidden PLMN list" for cuse #11, in the list of "forbidden loction res for regionl provision of service" for cuse #12 or in the list of "forbidden loction res for roming" for cuse #13. If #11or #13 ws received, the MS shll perform PLMN selection insted of cell selection. Other cuse vlues shll not impct the updte sttus. Further ctions of the MS re implementtion dependent. CR pge 3

16 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 268 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Clrifiction to the network initited GPRS detch procedure (IMSI detch) Siemens AG Work item code: GPRS Dte: 07 November 00 Ctegory: A Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: According to the stndrd, MS in opertion mode A or B in network opertion mode I which ws detched by the network with detch type IMSI detch shll perform combined routing re updting procedure to re-ttch for non-gprs services. Summry of chnge: See reson for chnge. Consequences if not pproved: Cluses ffected: It is clrified tht to this purpose the MS shll use the usul combined routing re updting procedure specified in section nd shll set the MM updte sttus to U2 NOT UPDATED. This prevents the MS from performing MM connection mngement procedures vi the A/Iu interfce while the combined routing re updting is running. A possible collision in the MSC/VLR between MM connection mngement procedure (performed vi the A/Iu interfce) nd MM specific procedure (Loction Updte vi the Gs interfce) could result in the rejection of cll. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

17 Network initited GPRS detch procedure Network initited GPRS detch procedure initition The network initites the GPRS detch procedure by sending DETACH REQUEST messge to the MS. The DETACH REQUEST messge shll include detch type IE. In ddition, the network my include cuse IE to specify the reson for the detch request. The network shll strt timer T3322. If the detch type IE indictes "re-ttch not required" or "re-ttch required", the network shll dectivte the PDP contexts nd dectivte the logicl link(s), if ny, nd shll chnge to stte GMM-DEREGISTERED-INITIATED Network initited GPRS detch procedure completion by the MS When receiving the DETACH REQUEST messge nd the detch type IE indictes "re-ttch not required" or "rettch required", the MS shll dectivte the PDP contexts nd dectivte the logicl link(s), if ny. The MS shll then send DETACH ACCEPT messge to the network nd shll chnge stte to GMM-DEREGISTERED. The MS shll, fter the completion of the GPRS detch procedure, initite GPRS ttch procedure if indicted by the network in the detch type IE. A GPRS MS operting in MS opertion mode A or B in network opertion mode I, which receives n DETACH REQUEST messge with detch type indicting "re-ttch required" or "re-ttch not required" nd no cuse code, is only detched for GPRS services in the network. When receiving the DETACH REQUEST messge nd the detch type IE indictes "IMSI detch", the MS shll not dectivte the PDP contexts. The MS shll set the MM updte sttus to U2 NOT UPDATED. A MS in opertion mode A or B in network opertion mode I my send DETACH ACCEPT messge to the network, nd shll re-ttch to non- GPRS service by performing the combined routing re updting procedure ccording to section , sending ROUTING AREA UPDATE REQUEST messge with Updte type IE indicting "combined RA/LA updting with IMSI ttch". A MS in opertion mode C, or in MS opertion mode A or B in network opertion mode II or III, shll send DETACH ACCEPT messge to the network. If the detch type IE indictes "IMSI detch", or "re-ttch required" then the MS shll ignore the cuse code if received. If the detch type informtion element vlue indictes "re-ttch required" or "re-ttch not required" nd the MS is ttched for GPRS nd non-gprs services nd the network opertes in network opertion mode I, then if in the MS the timer T3212 is not lredy running, the timer T3212 shll be set to its initil vlue nd restrted. If the detch type IE indictes "re-ttch required", the MS shll perform new ttch procedure. The MS should lso ctivte PDP context(s) to replce ny previously ctive PDP contexts. NOTE: In some cses, user interction my be required nd then the MS cnnot ctivte the PDP context(s) utomticlly. If the detch type IE indictes "re-ttch not required", then, depending on the received cuse code, the MS shll ct s follows: # 2 (IMSI unknown in HLR) The MS shll set the updte sttus to U3 ROAMING NOT ALLOWED nd shll delete ny TMSI, LAI nd ciphering key sequence number. The new MM stte is MM IDLE. The SIM shll be considered s invlid for non-gprs services until switching off or the SIM is removed. A GPRS MS operting in MS opertion mode A or B in network opertion mode I, is still IMSI ttched for GPRS services in the network. # 3 (Illegl MS); or # 6 (Illegl ME) The MS shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED (nd shll store it ccording to section ) nd shll delete ny P-TMSI, P-TMSI signture, RAI nd GPRS ciphering key sequence CR pge 2

18 number. The new GMM stte is GMM-DEREGISTERED. The SIM shll be considered s invlid for GPRS services until switching off or the SIM is removed. A GPRS MS operting in MS opertion mode A or B shll in ddition set the updte sttus to U3 ROAMING NOT ALLOWED, shll delete ny TMSI, LAI nd ciphering key sequence number. The new MM stte is MM idle. The SIM shll be considered s invlid lso for non-gprs services until switching off or the SIM is removed. # 7 (GPRS services not llowed) The MS shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED (nd shll store it ccording to section ) nd shll delete ny P-TMSI, P-TMSI signture, RAI nd GPRS ciphering key sequence number. The SIM shll be considered s invlid for GPRS services until switching off or the SIM is removed. The new stte is GMM-DEREGISTERED. A GPRS MS operting in MS opertion mode A or B in network opertion mode I, is still IMSI ttched for CS services in the network. # 8 (GPRS services nd non-gprs services not llowed) The MS shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED nd the updte sttus to U3 ROAMING NOT ALLOWED (nd shll store it ccording to section ). Furthermore, it shll delete ny P- TMSI, P-TMSI signture, TMSI, RAI, LAI, ciphering key sequence number nd GPRS ciphering key sequence number nd shll consider the SIM s invlid for GPRS nd non-gprs services until switching off or the SIM is removed. # 11 (PLMN not llowed); # 12 (Loction re not llowed); or # 13 (Roming not llowed in this loction re) The MS shll delete ny RAI or LAI, P-TMSI, P-TMSI signture nd GPRS ciphering key sequence number, shll set the GPRS updte sttus to GU3 ROAMING NOT ALLOWED (nd shll store it ccording to section ). A GPRS MS operting in MS opertion mode A or B shll in ddition set the updte sttus to U3 ROAMING NOT ALLOWED nd shll delete ny TMSI, LAI nd ciphering key sequence number. The new MM stte is MM IDLE. The MS shll store the LAI or the PLMN identity in the pproprite forbidden list, i.e. in the "forbidden PLMN list" for cuse #11, in the list of "forbidden loction res for regionl provision of service" for cuse #12 or in the list of "forbidden loction res for roming" for cuse #13. If #11or #13 ws received, the MS shll perform PLMN selection insted of cell selection. Other cuse vlues shll not impct the updte sttus. Further ctions of the MS re implementtion dependent. CR pge 3

19 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles, November 2000 CHANGE REQUEST CR A1051 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM X ME/UE X Rdio Access Network Core Network X Title: Source: Correction of updte sttus on Authentiction Reject Noki Work item code: GPRS Dte: 10-Nov-00 Ctegory: F Relese: R97 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: It is stted tht upon receipt of n AUTHENTICATION REJECT messge, MS shll set updte sttus in the SIM to U2 ROAMING NOT ALLOWED. This is incorrect. As specified in cluse of the sme specifiction, updte sttuses U2 NOT UPDATED nd U3 ROAMING NOT ALLOWED exist, but U2 ROAMING NOT ALLOWED doesn't. Summry of chnge: Chnge 'U2 ROAMING NOT ALLOWED' to 'U3 ROAMING NOT ALLOWED' in cluse Consequences if not pproved: Cluses ffected: The required updte sttus in MS fter AUTHENTICATION REJECT messge remins mbiguous. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings.

20 3) With "trck chnges" disbled, pste the entire CR form (use CTRL-A to select it) into the specifiction just in front of the cluse contining the first piece of chnged text. Delete those prts of the specifiction which re not relevnt to the chnge request.

21 (Relese 1997) 3GPP TS V Unsuccessful uthentiction If uthentiction fils, i.e. if the response is not vlid, the network my distinguish between the two different wys of identifiction used by the mobile sttion: - the TMSI ws used; - the IMSI ws used. If the TMSI hs been used, the network my decide to initite the identifiction procedure. If the IMSI given by the mobile sttion then differs from the one the network hd ssocited with the TMSI, the uthentiction should be restrted with the correct prmeters. If the IMSI provided by the MS is the expected one (i.e. uthentiction hs relly filed), the network should proceed s described below. If the IMSI hs been used, or the network decides not to try the identifiction procedure, n AUTHENTICATION REJECT messge should be trnsferred to the mobile sttion. After hving sent this messge, ll MM connections in progress (if ny) re relesed nd the network should initite the RR connection relese procedure described in section 3.5. Upon receipt of n AUTHENTICATION REJECT messge, the mobile sttion shll set the updte sttus in the SIM to U2 U3 ROAMING NOT ALLOWED, delete from the SIM the stored TMSI, LAI nd ciphering key sequence number. The SIM shll be considered s invlid until switching off or the SIM is removed. If the AUTHENTICATION REJECT messge is received in the stte IMSI DETACH INITIATED the mobile sttion shll follow section If the AUTHENTICATION REJECT messge is received in ny other stte the mobile sttion shll bort ny MM specific, MM connection estblishment or cll re-estblishment procedure, stop ny of the timers T3210 or T3230 (if running), relese ll MM connections (if ny), strt timer T3240 nd enter the stte WAIT FOR NETWORK COMMAND, expecting the relese of the RR connection. If the RR connection is not relesed within given time controlled by the timer T3240, the mobile sttion shll bort the RR connection. In both cses, either fter RR connection relese triggered from the network side or fter RR connection bort requested by the MS-side, the MS enters stte MM IDLE, substte NO IMSI. CR pge 3

22 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles, November 2000 CHANGE REQUEST CR A1053 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM X ME/UE X Rdio Access Network Core Network X Title: Source: Correction of updte sttus on Authentiction Reject Noki Work item code: GPRS Dte: 10-Nov-00 Ctegory: A Relese: R98 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: It is stted tht upon receipt of n AUTHENTICATION REJECT messge, MS shll set updte sttus in the SIM to U2 ROAMING NOT ALLOWED. This is incorrect. As specified in cluse of the sme specifiction, updte sttuses U2 NOT UPDATED nd U3 ROAMING NOT ALLOWED exist, but U2 ROAMING NOT ALLOWED doesn't. Summry of chnge: Chnge 'U2 ROAMING NOT ALLOWED' to 'U3 ROAMING NOT ALLOWED' in cluse Consequences if not pproved: Cluses ffected: The required updte sttus in MS fter AUTHENTICATION REJECT messge remins mbiguous. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings.

24 (Relese 1998) 3GPP TS V7.9.1( ) Unsuccessful uthentiction If uthentiction fils, i.e. if the response is not vlid, the network my distinguish between the two different wys of identifiction used by the mobile sttion: - the TMSI ws used; - the IMSI ws used. If the TMSI hs been used, the network my decide to initite the identifiction procedure. If the IMSI given by the mobile sttion then differs from the one the network hd ssocited with the TMSI, the uthentiction should be restrted with the correct prmeters. If the IMSI provided by the MS is the expected one (i.e. uthentiction hs relly filed), the network should proceed s described below. If the IMSI hs been used, or the network decides not to try the identifiction procedure, n AUTHENTICATION REJECT messge should be trnsferred to the mobile sttion. After hving sent this messge, ll MM connections in progress (if ny) re relesed nd the network should initite the RR connection relese procedure described in section 3.5. Upon receipt of n AUTHENTICATION REJECT messge, the mobile sttion shll set the updte sttus in the SIM to U2 U3 ROAMING NOT ALLOWED, delete from the SIM the stored TMSI, LAI nd ciphering key sequence number. The SIM shll be considered s invlid until switching off or the SIM is removed. If the AUTHENTICATION REJECT messge is received in the stte IMSI DETACH INITIATED the mobile sttion shll follow section If the AUTHENTICATION REJECT messge is received in ny other stte the mobile sttion shll bort ny MM specific, MM connection estblishment or cll re-estblishment procedure, stop ny of the timers T3210 or T3230 (if running), relese ll MM connections (if ny), strt timer T3240 nd enter the stte WAIT FOR NETWORK COMMAND, expecting the relese of the RR connection. If the RR connection is not relesed within given time controlled by the timer T3240, the mobile sttion shll bort the RR connection. In both cses, either fter RR connection relese triggered from the network side or fter RR connection bort requested by the MS-side, the MS enters stte MM IDLE, substte NO IMSI. CR pge 3

25 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles, November 2000 CHANGE REQUEST CR 277 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM X ME/UE X Rdio Access Network Core Network X Title: Source: Correction of updte sttus on Authentiction Reject Noki Work item code: GPRS Dte: 10-Nov-00 Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: It is stted tht upon receipt of n AUTHENTICATION REJECT messge, MS shll set updte sttus in the SIM to U2 ROAMING NOT ALLOWED. This is incorrect. As specified in cluse of the sme specifiction, updte sttuses U2 NOT UPDATED nd U3 ROAMING NOT ALLOWED exist, but U2 ROAMING NOT ALLOWED doesn't. Summry of chnge: Chnge 'U2 ROAMING NOT ALLOWED' to 'U3 ROAMING NOT ALLOWED' in cluse Consequences if not pproved: Cluses ffected: The required updte sttus in MS fter AUTHENTICATION REJECT messge remins mbiguous. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings.

27 3GPP TS v3.5.0 ( ) CR pge Authentiction not ccepted by the network If uthentiction fils, i.e. if the response is not vlid, the network my distinguish between the two different wys of identifiction used by the mobile sttion: - the TMSI ws used; - the IMSI ws used. If the TMSI hs been used, the network my decide to initite the identifiction procedure. If the IMSI given by the mobile sttion then differs from the one the network hd ssocited with the TMSI, the uthentiction should be restrted with the correct prmeters. If the IMSI provided by the MS is the expected one (i.e. uthentiction hs relly filed), the network should proceed s described below. If the IMSI hs been used, or the network decides not to try the identifiction procedure, n AUTHENTICATION REJECT messge should be trnsferred to the mobile sttion. After hving sent this messge, ll MM connections in progress (if ny) re relesed nd the network should initite the RR connection relese procedure described in section 3.5.of (GSM) or in TS (UMTS). Upon receipt of n AUTHENTICATION REJECT messge, the mobile sttion shll set the updte sttus in the SIM to U2 U3 ROAMING NOT ALLOWED, delete from the SIM the stored TMSI, LAI nd ciphering key sequence number. The SIM shll be considered s invlid until switching off or the SIM is removed. If the AUTHENTICATION REJECT messge is received in the stte IMSI DETACH INITIATED the mobile sttion shll follow section If the AUTHENTICATION REJECT messge is received in ny other stte the mobile sttion shll bort ny MM specific, MM connection estblishment or cll re-estblishment procedure, stop ny of the timers T3210 or T3230 (if running), relese ll MM connections (if ny), strt timer T3240 nd enter the stte WAIT FOR NETWORK COMMAND, expecting the relese of the RR connection. If the RR connection is not relesed within given time controlled by the timer T3240, the mobile sttion shll bort the RR connection. In both cses, either fter RR connection relese triggered from the network side or fter RR connection bort requested by the MS-side, the MS enters stte MM IDLE, substte NO IMSI. If the MS hs seprte ongoing RR connection to different core network node, it shll consider this seprte connection s still being good. CR pge 3

28 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles, November 2000 CHANGE REQUEST CR 278 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM X ME/UE X Rdio Access Network Core Network X Title: Source: Correction of updte sttus on Authentiction Reject Noki Work item code: GPRS Dte: 10-Nov-00 Ctegory: F Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: It is stted tht upon receipt of n AUTHENTICATION REJECT messge, MS shll set updte sttus in the SIM to U2 ROAMING NOT ALLOWED. This is incorrect. As specified in cluse of the sme specifiction, updte sttuses U2 NOT UPDATED nd U3 ROAMING NOT ALLOWED exist, but U2 ROAMING NOT ALLOWED doesn't. Summry of chnge: Chnge 'U2 ROAMING NOT ALLOWED' to 'U3 ROAMING NOT ALLOWED' in cluse Consequences if not pproved: Cluses ffected: The required updte sttus in MS fter AUTHENTICATION REJECT messge remins mbiguous. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings.

30 Relese 4 CR pge Authentiction not ccepted by the network If uthentiction fils, i.e. if the response is not vlid, the network my distinguish between the two different wys of identifiction used by the mobile sttion: - the TMSI ws used; - the IMSI ws used. If the TMSI hs been used, the network my decide to initite the identifiction procedure. If the IMSI given by the mobile sttion then differs from the one the network hd ssocited with the TMSI, the uthentiction should be restrted with the correct prmeters. If the IMSI provided by the MS is the expected one (i.e. uthentiction hs relly filed), the network should proceed s described below. If the IMSI hs been used, or the network decides not to try the identifiction procedure, n AUTHENTICATION REJECT messge should be trnsferred to the mobile sttion. After hving sent this messge, ll MM connections in progress (if ny) re relesed nd the network should initite the RR connection relese procedure described in section 3.5.of (GSM) or in TS (UMTS). Upon receipt of n AUTHENTICATION REJECT messge, the mobile sttion shll set the updte sttus in the SIM to U2 U3 ROAMING NOT ALLOWED, delete from the SIM the stored TMSI, LAI nd ciphering key sequence number. The SIM shll be considered s invlid until switching off or the SIM is removed. If the AUTHENTICATION REJECT messge is received in the stte IMSI DETACH INITIATED the mobile sttion shll follow section If the AUTHENTICATION REJECT messge is received in ny other stte the mobile sttion shll bort ny MM specific, MM connection estblishment or cll re-estblishment procedure, stop ny of the timers T3210 or T3230 (if running), relese ll MM connections (if ny), strt timer T3240 nd enter the stte WAIT FOR NETWORK COMMAND, expecting the relese of the RR connection. If the RR connection is not relesed within given time controlled by the timer T3240, the mobile sttion shll bort the RR connection. In both cses, either fter RR connection relese triggered from the network side or fter RR connection bort requested by the MS-side, the MS enters stte MM IDLE, substte NO IMSI. If the MS hs seprte ongoing RR connection to different core network node, it shll consider this seprte connection s still being good. CR pge 3

31 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 025 rev r1 Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: RABMAS-SAP nd RABMSM-SAP dpttion for hndling of unsynchronized PDP contexts Siemens AG Work item code: GPRS Dte: Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The MS nd the core network my hve different view on wht PDP contexts re in stte PDP-ACTIVE. This problem is likely to hppen due to brek in rdio connection nd should be solved during re-estblishment. Summry of chnge: Sections 6.5.3, Consequences if not pproved: Cluses ffected: Plese see document N for complete description of the sitution nd the proposl to solve the problem. MS nd core network cn hve different view on PDP contexts in stte PDP- ACTIVE which results in loss of dt trnsmitted over ir interfce but dropped on the MS side or to buffer overflow in UL-direction on MS side. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

32 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge Session Mngement Services for RABMSM-SAP (UMTS only) Tble 6.5.3: Service primitives nd prmeters t RABMSM-SAP - MS side PRIMITIVE PARAMETER Reference (messge, info elements of messge, other prmeters) RABMSM-ACTIVATE-IND NSAPI, QoS RABMSM-ACTIVATE-RSP NSAPI RABMSM-DEACTIVATE-IND NSAPIs RABMSM-DEACTIVATE-RSP NSAPIs RABMSM-DEACTIVATE-REQ NSAPI RABMSM-MODIFY-IND NSAPI, QoS RABMSM-MODIFY-RSP RABMSM-STATUS-REQ - Cuse RABMSM-ACTIVATE-IND Indiction used by the SM entity to inform the RABM entity tht n NSAPI hs been ctivted for dt trnsfer (e.g. n ctivte PDP Context request hs been sent to the network). It lso informs the RABM entity bout the requested QoS profile for this NSAPI. The indiction is sent by SM towrds RABM during n ongoing PDP context ctivtion procedure RABMSM-ACTIVATE-RSP Response used by the RABM entity to inform the SM entity tht the indicted NSAPI is now in use nd tht RAB for the indicted NSAPI is estblished RABMSM-DEACTIVATE-IND Indiction used by the SM entity to inform the RABM entity tht n NSAPIs hs been de-llocted nd cnnot be used by the RABM entity nymore. The request is sent by SM towrds RABM during n ongoing MS initited s well s network initited PDP context de-ctivtion procedure or during locl de-ctivtion of PDP context RABMSM-DEACTIVATE-RSP This messge is the rresponse to RABMSM-DEACTIVATE-IND used by the RABM entity to inform the SM entity tht the NSAPI indicted is no longer in use. It is either sent immeditely when there is no corresponding berer ctive or it is sent fter reception nd processing of RABMAS-RAB-RELEASE-IND from ccess strtum RABMSM-DEACTIVATE-REQ This primitive is used by the RABM entity to inform the SM entity tht the RAB for n NSAPI hs been relesed. This primitive is only sent for berer with RT-QoS clsses RABMSM-MODIFY-IND Indiction used by the SM entity to indicte the chnge of the QoS for n NSAPI. The indiction is sent by SM towrds RABM during n ongoing PDP context modifiction procedure RABMSM-MODIFY-RSP Response used by the RABM entity to inform the SM entity tht the indicted NSAPI nd QoS profile re now in use nd the RAB for the NSAPI is estblished nd/or relesed, if necessry. CR pge 2

33 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge RABMSM-STATUS-REQ This primitive is used by the RABM entity to inform the SM entity tht RABM cnnot continue its opertion due to errors t the lower lyer (i.e. Access Strtum) or t the RABM lyer. The Cuse prmeter indictes the cuse of the error. ************* Next chnge *************** Service primitives for RABMAS-SAP (UMTS only) Tble 9.3.3: Primitives nd prmeters t RABMAS-SAP PRIMITIVE PARAMETER REFERENCE (messge, info elements of messge, other prmeters) RABMAS-RAB-ESTABLISH-IND RAB IDs list RABMAS-RAB-ESTABLISH-RES RABMAS-RAB-ESTABLISH-REJ RAB-ID lists, Cuse RABMAS-RAB-RELEASE-IND RAB ID list RABMAS-RAB-RELEASE-RES RABMAS-STATUS-IND Cuse RABMAS-RAB-ESTABLISH-IND Indiction from the Access Strtum lyer tht rdio ccess berer setup for the indicted list of RAB IDs (contins NSAPI) hs commenced RABMAS-RAB-ESTABLISH-RES Response (to RABMAS-RAB-ESTABLISH-IND) used by the RABM entity to inform the Access Strtum sublyer tht the indicted NSAPI (in RAB ID) is currently or hs been ctivted by the SM-lyer nd it is ok to set up the rdio ccess berer RABMAS-RAB-ESTABLISH-REJ Response (to RABMAS-RAB-ESTABLISH-IND) used by the RABM entity to inform the Access Strtum sublyer tht ll or some of the indicted NSAPIs, (in indicted by RAB ID list in the received RABMAS-RAB-ESTABLISH-IND), hves not been ctivted by the SM-lyer nd the ttempt to setup the rdio ccess berers shll be rejected. The prmeter RAB-ID list contins those RAB-IDs for which corresponding ctive PDP context(nsapi) exits on the MS side. The prmeter cuse hs to be set to 'unsynchronouspdp' RABMAS-RAB-RELEASE-IND Indiction from the Access Strtum lyer tht rdio ccess berer for the indicted NSAPI hs been relesed RABMAS-RAB-RELEASE-RES Response used by the RABM entity to inform the Access Strtum sublyer tht the indicted RAB ID hs been relesed in the RABM RABMAS-STATUS-IND Indiction used by the AS sublyer to trnsfer filures to the RABM. CR pge 3

34 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 306 rev r1 Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Clrifiction of response hndling of Service Request Siemens AG Work item code: GPRS Dte: Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The decision ws tken tht security mode control procedure is the only vlid positive response on SERVICE REQUEST in PMM-IDLE nd SERVICE ACCEPT is the only vlid positive response in mode PMM-CONNECTED. Summry of chnge: Consequences if not pproved: The description for MS is clrified s fr s the ction is concerned which hs to be tken fter receiving response. Cluses ffected: Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

35 Service Request procedure (UMTS only) Service request procedure ccepted by the network If the SERVICE REQUEST messge ws sent in PMM-IDLE mode, Anthe indiction from the lower lyers tht the security mode control procedure is completed or reception of SERVICE ACCEPT messge, shll be treted s successful completion of the procedure. The timer T3317 shll be stopped, nd the MS enters GMM-REGISTERED stte nd PMM-CONNECTED mode. If the SERVICE REQUEST messge ws sent in PMM-CONNECTED mode, then the reception of the SERVICE ACCEPT messge shll be treted s successful completion of the procedure. The timer T3317 shll be stopped nd the MS remins in PMM-CONNECTED mode. CR pge 2

36 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 271 rev r1 Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: APN used for detection of duplicted PDP context ctivtion Siemens AG Work item code: GPRS Dte: Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The combintion of APN nd PDP ddress is compred during PDP context ctivtion ginst ll lredy ctivted PDP contexts. If there is mtch between the requested PDP context nd n lredy ctive PDP context then this is n indiction, tht the MS hs the lredy ctive PDP context forgotten. However, the APN s well s the PDP ddress run through selection procedure in SGSN. This procedure is defined in nnex A.2. It is necessry to stte which APN nd PDP ddress is used to find out if there is forgotten PDP context. There re two possibilities to compre the combintions: 1.) before the conversions ccording the selection rule is done (mens the network hs to store the input of ll previously ctivted PDP contexts 2.) fter the conversion It must be mde cler tht it is not possible to compre the conversion result of the previously ctivted PDP context with the prmeter provided in the ctul ACTIVATE PDP CONTEXT REQUEST. Summry of chnge: Use APN before ppliction of selection rules for error detection Consequences if not pproved: Cluses ffected: Different interprettion of the stndrd would possibly result in different behviour during PDP context ctivtion. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions CR pge 1

37 Other comments: CR pge 2

38 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge Unsuccessful PDP context ctivtion requested by the network Upon receipt of the REQUEST PDP CONTEXT ACTIVATION messge, the MS my reject the network requested PDP context ctivtion by sending the REQUEST PDP CONTEXT ACTIVATION REJECT messge to the network. The messge contins the sme TI s included in the REQUEST PDP CONTEXT ACTIVATION nd n dditionl cuse code tht typiclly indictes one of the following cuses: # 26: insufficient resources; # 31: ctivtion rejected, unspecified; # 40: feture not supported; or # : protocol errors. The network shll stop timer T3385 nd enter stte PDP-INACTIVE Abnorml cses The following bnorml cses cn be identified: ) Expiry of timers In the mobile sttion: On the first expiry of the timer T3380, the MS shll resend the ACTIVATE PDP CONTEXT REQUEST nd shll reset nd restrt timer T3380. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3380, the MS shll relese ll resources possibly llocted for this invoction nd shll bort the procedure; no utomtic PDP context ctivtion re-ttempt shll be performed. On the network side: On the first expiry of the timer T3385, the network shll resend the messge REQUEST PDP CONTEXT ACTIVATION nd shll reset nd restrt timer T3385. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3385, the network shll relese possibly llocted resources for this ctivtion nd shll bort the procedure. b) Collision of MS initited nd network requested PDP context ctivtion Dynmic PDP ddress collision cse: If the MS uses dynmic PDP ddressing tht turns out to collide with the network requested PDP ddress, then there is no detection of collision specified but left for network implementtion. Sttic PDP ddress collision detected within the mobile sttion: A collision of n MS initited nd network requested PDP context ctivtion procedure is identified by the MS if REQUEST PDP CONTEXT ACTIVATION messge is received from the network fter the MS hs sent n ACTIVATE PDP CONTEXT REQUEST messge, nd the MS hs not yet received n ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT messge. NOTE: In generl, the MS is unble to test if the PDP type, PDP ddress nd APN in the REQUEST PDP CONTEXT ACTIVATION messge re the sme s those for the PDN to which it is ttempting to ctivte context. This is becuse the MS my hve omitted one or more of the prmeters in the ACTIVATE PDP CONTEXT REQUEST messge, since it is relying on defult vlues to be provided by the network. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. If the MS is ble to compre the PDP type, PDP ddress nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge nd these prmeters re equl, then the MS shll discrd the REQUEST PDP CONTEXT ACTIVATION messge nd shll wit for the network response to its ACTIVATE PDP CONTEXT REQUEST messge. If the MS is not ble to compre the PDP type, PDP ddress, nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge, then the MS shll send REQUEST PDP CR pge 3

39 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge 4 CONTEXT ACTIVATION REJECT messge with the cuse 'insufficient resources' to the network, nd wit for n ACTIVATE PDP CONTEXT ACCEPT messge. Sttic PDP ddress collision detected on the network side: A collision is detected by the network in the cse where the PDP ddress, PDP type nd APN derived (ccording to nnex A) from the ACTIVATE PDP CONTEXT REQUEST messge received from the MS mtch those in the REQUEST PDP CONTEXT ACTIVATION messge sent to the MS. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. The network shll terminte the network requested PDP context ctivtion procedure, nd proceed with the MS initited PDP context ctivtion procedure c) MS initited PDP context ctivtion request for n lredy ctivted PDP context (on the network side) i) If the network receives ACTIVATE PDP CONTEXT REQUEST messge with the sme combintion of APN, PDP type nd PDP ddress s n lredy ctivted PDP context, the network shll dectivte the existing PDP context nd, if ny, ll the linked PDP contexts (mtching the combintion of APN, PDP type nd PDP ddress), loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. Note: If PDP ddress of existing PDP context is dynmic nd estblishment of PDP context using dynmic PDP ddress is requested for the sme APN, it shll be recognised s PDP context dupliction since one APN llows only one dynmic PDP ddress for PDP Type. ii) Alterntively (different combintion of APN, PDP type nd PDP ddress), if the NSAPI mtches tht of n lredy ctivted PDP context, then the network shll dectivte only the existing PDP context loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. It is n implementtion option if the prmeters used for comprison described in cluse i) nd ii) re the prmeters provided in the (current nd previous) ACTIVATE PDP CONTEXT REQUESTs or the prmeters which re the result of the ppliction of the selection rules defined in TS Annex A.2. The prmeter provided in the current ACTIVATE PDP CONTEXT REQUEST cn not be compred to the ctully used prmeters (result of ppliction of selection rules defined in TS Annex A.2) of the previously ctivted PDP contexts. CR pge 4

40 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 309 rev 1 Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Correction of PDP context dupliction hndling Fujitsu Work item code: GPRS Dte: 23/Nov/2000 Ctegory: F Criticl correction Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: According to the , templte of PDP context using dynmic PDP ddress llows to estblish more thn one PDP context bsed on the templte. But current text in does not llow the cse becuse the network recognizes the cse s n illegl cse. The mismtch shll be corrected updting to be in line with Summry of chnge: The duppliction check shll be skipped with regrd to the dynmic PDP ddress. Consequences if not pproved: Cluses ffected: More thn one PDP context to n APN using dynmic PDP ddress is not llowed. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings. CR pge 1

41 3) With "trck chnges" disbled, pste the entire CR form (use CTRL-A to select it) into the specifiction just in front of the cluse contining the first piece of chnged text. Delete those prts of the specifiction which re not relevnt to the chnge request. CR pge 2

42 Abnorml cses The following bnorml cses cn be identified: ) Expiry of timers In the mobile sttion: On the first expiry of the timer T3380, the MS shll resend the ACTIVATE PDP CONTEXT REQUEST nd shll reset nd restrt timer T3380. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3380, the MS shll relese ll resources possibly llocted for this invoction nd shll bort the procedure; no utomtic PDP context ctivtion re-ttempt shll be performed. On the network side: On the first expiry of the timer T3385, the network shll resend the messge REQUEST PDP CONTEXT ACTIVATION nd shll reset nd restrt timer T3385. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3385, the network shll relese possibly llocted resources for this ctivtion nd shll bort the procedure. b) Collision of MS initited nd network requested PDP context ctivtion Dynmic PDP ddress collision cse: If the MS uses dynmic PDP ddressing tht turns out to collide with the network requested PDP ddress, then there is no detection of collision specified but left for network implementtion. Sttic PDP ddress collision detected within the mobile sttion: A collision of n MS initited nd network requested PDP context ctivtion procedure is identified by the MS if REQUEST PDP CONTEXT ACTIVATION messge is received from the network fter the MS hs sent n ACTIVATE PDP CONTEXT REQUEST messge, nd the MS hs not yet received n ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT messge. NOTE: In generl, the MS is unble to test if the PDP type, PDP ddress nd APN in the REQUEST PDP CONTEXT ACTIVATION messge re the sme s those for the PDN to which it is ttempting to ctivte context. This is becuse the MS my hve omitted one or more of the prmeters in the ACTIVATE PDP CONTEXT REQUEST messge, since it is relying on defult vlues to be provided by the network. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. If the MS is ble to compre the PDP type, PDP ddress nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge nd these prmeters re equl, then the MS shll discrd the REQUEST PDP CONTEXT ACTIVATION messge nd shll wit for the network response to its ACTIVATE PDP CONTEXT REQUEST messge. If the MS is not ble to compre the PDP type, PDP ddress, nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge, then the MS shll send REQUEST PDP CONTEXT ACTIVATION REJECT messge with the cuse 'insufficient resources' to the network, nd wit for n ACTIVATE PDP CONTEXT ACCEPT messge. Sttic PDP ddress collision detected on the network side: A collision is detected by the network in the cse where the PDP ddress, PDP type nd APN derived (ccording to nnex A) from the ACTIVATE PDP CONTEXT REQUEST messge received from the MS mtch those in the REQUEST PDP CONTEXT ACTIVATION messge sent to the MS. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. The network shll terminte the network requested PDP context ctivtion procedure, nd proceed with the MS initited PDP context ctivtion procedure c) MS initited PDP context ctivtion request for n lredy ctivted PDP context (on the network side) i) If the network receives ACTIVATE PDP CONTEXT REQUEST messge with the sme combintion of APN, PDP type nd PDP ddress s n lredy ctivted PDP context, the network shll dectivte the CR pge 3

43 existing PDP context nd, if ny, ll the linked PDP contexts (mtching the combintion of APN, PDP type nd PDP ddress), loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. Note: If PDP ddress of existing PDP context is dynmic nd estblishment of PDP context using dynmic PDP ddress is requested for the sme APN, it shll be recognised s PDP context dupliction since one APN llows only one dynmic PDP ddress for PDP Type. ii) Alterntively (different combintion of APN, PDP type nd PDP ddress), if the NSAPI mtches tht of n lredy ctivted PDP context, then the network shll dectivte only the existing PDP context loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. d) Network initited PDP context ctivtion request for n lredy ctivted PDP context (on the mobile sttion side) If the MS receives REQUEST PDP CONTEXT ACTIVATION messge with the sme combintion of APN, PDP type nd PDP ddress s n lredy ctivted PDP context, the MS shll dectivte the existing PDP context nd, if ny, ll the linked PDP contexts (mtching the combintion of APN, PDP type nd PDP ddress) loclly without notifiction to the network nd proceed with the requested PDP context ctivtion. CR pge 4

44 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 307 rev r2 Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Clrifiction of RAB re-estblishment Siemens AG Work item code: GPRS Dte: Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The network initited estblishment of ps-signlling connection vi pging nd the resulting SERVICE REQUEST with Service Type "PgingResponse" does not necessrily men tht the berer for ctivted PDP contexts (if there re ny) hve to be re-estblished. The re-estblishment is not done when there is only the signlling connection required. This is the cse for MT-SMS nd Network initited PDP context request. The sttes in section Service Request Initited by Network Procedure: "At this point, the SGSN my perform the uthentiction procedure. The SGSN knows whether the downlink pcket requires RAB estblishment (e.g., downlink PDU) or not (e.g., Request PDP Context Activtion or MT SMS)." Note: All berer will be re-estblished in cse of Request PDP Context Activtion when the berer for this new context is ssigned. This hndling hs impct lter on when the MS or the network need to trnsmit user dt in PMM-CONNECTED mode if there re ctive PDP contexts for which the berer hs been relesed. If the network hs pending user dt for n ctive PDP context without rdio ccess berer in PMM-CONNECTED mode then the network will setup rdio ccess berer for ech ctive PDP context. Summry of chnge: Consequences if not pproved: Not regrding of situtions which cn hppen when is correct implemented. This prevent re-estblishment of berer t lest for downlink user dt. Cluses ffected: Other specs Other core specifictions CR pge 1

45 ffected: Test specifictions O&M Specifictions Other comments: CR pge 2

46 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge Service Request procedure (UMTS only) The purpose of this procedure is to trnsfer the PMM mode from PMM-IDLE to PMM-CONNECTED mode, nd/or to ssign rdio ccess berer in cse of PDP contexts re ctivted without rdio ccess berer ssigned. In ltter cse, the PMM mode my be PMM-IDLE mode or my lterntively be the PMM-CONNECTED mode if the MS requires rdio ccess berer re-estblishment. This procedure is used for; - the initition of CM lyer service (e.g. SM or SMS) procedure from the MS in PMM-IDLE mode. - the network to trnsfer down link signlling, - uplink (in PMM-IDLE or PMM CONNECTED) nd downlink (only in PMM-IDLE) user pcketdt. For downlink trnsfer of signlling or user pcket dt in PMM-IDLE mode, the trigger is given from the network by the pging request procedure, which is out of scope of this specifiction. For pending downlink user dt in PMM-CONNECTED mode, the re-estblishment of rdio ccess berers for ll ctive PDP contexts is done without pging. Service type cn tke either of the following vlues, "signlling", "dt" or "pging response". Ech of the vlues shll be selected ccording to the criteri to initite the Service request procedure. The criteri to invoke the Service request procedure re when; ) the MS hs ny signlling messge (e.g. for SM or SMS), tht requires security protection, to be sent to the network in PMM-IDLE mode (i.e., no secure PS signlling connection hs been estblished). In this cse, the service type shll be set to "signlling". b) the MS, either in PMM-IDLE ndor PMM-CONNECTED mode, hs pending user pcket dt to be sent nd no rdio ccess berer is estblished for the corresponding PDP context. The procedure is initited by n indiction from the lower lyers (see TS ). In this cse, the service type shll be set to "dt". c) the MS receives pging request for PS domin from the network in PMM-IDLE mode. In this cse, the service type shll be set to "pging response". After completion of Service request procedure, the pending service is resumed nd uses then the connection estblished by the procedure. If the service type is indicting "dt", then the rdio ccess berers for ll ctive PDP contexts re re-estblished. The selective re-ssignment cpbility is not supported for the simplicity of the function. CR pge 3

47 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 312 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Clrifiction of response hndling of Service Request Siemens AG Work item code: GPRS Dte: Ctegory: A Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The decision ws tken tht security mode control procedure is the only vlid positive response on SERVICE REQUEST in PMM-IDLE nd SERVICE ACCEPT is the only vlid positive response in mode PMM-CONNECTED. Summry of chnge: Consequences if not pproved: The description for MS is clrified s fr s the ction is concerned which hs to be tken fter receiving response. Cluses ffected: Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

48 Service Request procedure (UMTS only) Service request procedure ccepted by the network If the SERVICE REQUEST messge ws sent in PMM-IDLE mode, Anthe indiction from the lower lyers tht the security mode control procedure is completed or reception of SERVICE ACCEPT messge, shll be treted s successful completion of the procedure. The timer T3317 shll be stopped, nd the MS enters GMM-REGISTERED stte nd PMM-CONNECTED mode. If the SERVICE REQUEST messge ws sent in PMM-CONNECTED mode, then the reception of the SERVICE ACCEPT messge shll be treted s successful completion of the procedure. The timer T3317 shll be stopped nd the MS remins in PMM-CONNECTED mode. CR pge 2

49 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 313 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Clrifiction of RAB re-estblishment Siemens AG Work item code: GPRS Dte: Ctegory: A Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The network initited estblishment of ps-signlling connection vi pging nd the resulting SERVICE REQUEST with Service Type "PgingResponse" does not necessrily men tht the berer for ctivted PDP contexts (if there re ny) hve to be re-estblished. The re-estblishment is not done when there is only the signlling connection required. This is the cse for MT-SMS nd Network initited PDP context request. The sttes in section Service Request Initited by Network Procedure: "At this point, the SGSN my perform the uthentiction procedure. The SGSN knows whether the downlink pcket requires RAB estblishment (e.g., downlink PDU) or not (e.g., Request PDP Context Activtion or MT SMS)." Note: All berer will be re-estblished in cse of Request PDP Context Activtion when the berer for this new context is ssigned. This hndling hs impct lter on when the MS or the network need to trnsmit user dt in PMM-CONNECTED mode if there re ctive PDP contexts for which the berer hs been relesed. If the network hs pending user dt for n ctive PDP context without rdio ccess berer in PMM-CONNECTED mode then the network will setup rdio ccess berer for ech ctive PDP context. Summry of chnge: Consequences if not pproved: Not regrding of situtions which cn hppen when is correct implemented. This prevent re-estblishment of berer t lest for downlink user dt. Cluses ffected: Other specs Other core specifictions CR pge 1

50 ffected: Test specifictions O&M Specifictions Other comments: CR pge 2

51 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge Service Request procedure (UMTS only) The purpose of this procedure is to trnsfer the PMM mode from PMM-IDLE to PMM-CONNECTED mode, nd/or to ssign rdio ccess berer in cse of PDP contexts re ctivted without rdio ccess berer ssigned. In ltter cse, the PMM mode my be PMM-IDLE mode or my lterntively be the PMM-CONNECTED mode if the MS requires rdio ccess berer re-estblishment. This procedure is used for; - the initition of CM lyer service (e.g. SM or SMS) procedure from the MS in PMM-IDLE mode. - the network to trnsfer down link signlling, - uplink (in PMM-IDLE or PMM CONNECTED) nd downlink (only in PMM-IDLE) user pcketdt. For downlink trnsfer of signlling or user pcket dt in PMM-IDLE mode, the trigger is given from the network by the pging request procedure, which is out of scope of this specifiction. For pending downlink user dt in PMM-CONNECTED mode, the re-estblishment of rdio ccess berers for ll ctive PDP contexts is done without pging. Service type cn tke either of the following vlues, "signlling", "dt" or "pging response". Ech of the vlues shll be selected ccording to the criteri to initite the Service request procedure. The criteri to invoke the Service request procedure re when; ) the MS hs ny signlling messge (e.g. for SM or SMS), tht requires security protection, to be sent to the network in PMM-IDLE mode (i.e., no secure PS signlling connection hs been estblished). In this cse, the service type shll be set to "signlling". b) the MS, either in PMM-IDLE ndor PMM-CONNECTED mode, hs pending user pcket dt to be sent nd no rdio ccess berer is estblished for the corresponding PDP context. The procedure is initited by n indiction from the lower lyers (see TS ). In this cse, the service type shll be set to "dt". c) the MS receives pging request for PS domin from the network in PMM-IDLE mode. In this cse, the service type shll be set to "pging response". After completion of Service request procedure, the pending service is resumed nd uses then the connection estblished by the procedure. If the service type is indicting "dt", then the rdio ccess berers for ll ctive PDP contexts re re-estblished. The selective re-ssignment cpbility is not supported for the simplicity of the function. CR pge 3

52 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 314 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: APN used for detection of duplicted PDP context ctivtion Siemens AG Work item code: GPRS Dte: Ctegory: A Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The combintion of APN nd PDP ddress is compred during PDP context ctivtion ginst ll lredy ctivted PDP contexts. If there is mtch between the requested PDP context nd n lredy ctive PDP context then this is n indiction, tht the MS hs the lredy ctive PDP context forgotten. However, the APN s well s the PDP ddress run through selection procedure in SGSN. This procedure is defined in nnex A.2. It is necessry to stte which APN nd PDP ddress is used to find out if there is forgotten PDP context. It is proposed to use the APN provided in the ACTIVATE PDP CONTEXT REQUEST since it is ssumed tht the selection rules in nnex A.2 prevent the ssignment of the sme PDP-ddress/APN combintion when the input re different PDP-type, PDPddress nd APN combintions. Summry of chnge: Use APN before ppliction of selection rules for error detection Consequences if not pproved: Cluses ffected: Different interprettion of the stndrd would possibly result in different behviour during PDP context ctivtion. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

53 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge Unsuccessful PDP context ctivtion requested by the network Upon receipt of the REQUEST PDP CONTEXT ACTIVATION messge, the MS my reject the network requested PDP context ctivtion by sending the REQUEST PDP CONTEXT ACTIVATION REJECT messge to the network. The messge contins the sme TI s included in the REQUEST PDP CONTEXT ACTIVATION nd n dditionl cuse code tht typiclly indictes one of the following cuses: # 26: insufficient resources; # 31: ctivtion rejected, unspecified; # 40: feture not supported; or # : protocol errors. The network shll stop timer T3385 nd enter stte PDP-INACTIVE Abnorml cses The following bnorml cses cn be identified: ) Expiry of timers In the mobile sttion: On the first expiry of the timer T3380, the MS shll resend the ACTIVATE PDP CONTEXT REQUEST nd shll reset nd restrt timer T3380. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3380, the MS shll relese ll resources possibly llocted for this invoction nd shll bort the procedure; no utomtic PDP context ctivtion re-ttempt shll be performed. On the network side: On the first expiry of the timer T3385, the network shll resend the messge REQUEST PDP CONTEXT ACTIVATION nd shll reset nd restrt timer T3385. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3385, the network shll relese possibly llocted resources for this ctivtion nd shll bort the procedure. b) Collision of MS initited nd network requested PDP context ctivtion Dynmic PDP ddress collision cse: If the MS uses dynmic PDP ddressing tht turns out to collide with the network requested PDP ddress, then there is no detection of collision specified but left for network implementtion. Sttic PDP ddress collision detected within the mobile sttion: A collision of n MS initited nd network requested PDP context ctivtion procedure is identified by the MS if REQUEST PDP CONTEXT ACTIVATION messge is received from the network fter the MS hs sent n ACTIVATE PDP CONTEXT REQUEST messge, nd the MS hs not yet received n ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT messge. NOTE: In generl, the MS is unble to test if the PDP type, PDP ddress nd APN in the REQUEST PDP CONTEXT ACTIVATION messge re the sme s those for the PDN to which it is ttempting to ctivte context. This is becuse the MS my hve omitted one or more of the prmeters in the ACTIVATE PDP CONTEXT REQUEST messge, since it is relying on defult vlues to be provided by the network. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. If the MS is ble to compre the PDP type, PDP ddress nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge nd these prmeters re equl, then the MS shll discrd the REQUEST PDP CONTEXT ACTIVATION messge nd shll wit for the network response to its ACTIVATE PDP CONTEXT REQUEST messge. If the MS is not ble to compre the PDP type, PDP ddress, nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge, then the MS shll send REQUEST PDP CR pge 2

54 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge 3 CONTEXT ACTIVATION REJECT messge with the cuse 'insufficient resources' to the network, nd wit for n ACTIVATE PDP CONTEXT ACCEPT messge. Sttic PDP ddress collision detected on the network side: A collision is detected by the network in the cse where the PDP ddress, PDP type nd APN derived (ccording to nnex A) from the ACTIVATE PDP CONTEXT REQUEST messge received from the MS mtch those in the REQUEST PDP CONTEXT ACTIVATION messge sent to the MS. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. The network shll terminte the network requested PDP context ctivtion procedure, nd proceed with the MS initited PDP context ctivtion procedure c) MS initited PDP context ctivtion request for n lredy ctivted PDP context (on the network side) i) If the network receives ACTIVATE PDP CONTEXT REQUEST messge with the sme combintion of APN, PDP type nd PDP ddress s n lredy ctivted PDP context, the network shll dectivte the existing PDP context nd, if ny, ll the linked PDP contexts (mtching the combintion of APN, PDP type nd PDP ddress), loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. Note: If PDP ddress of existing PDP context is dynmic nd estblishment of PDP context using dynmic PDP ddress is requested for the sme APN, it shll be recognised s PDP context dupliction since one APN llows only one dynmic PDP ddress for PDP Type. ii) Alterntively (different combintion of APN, PDP type nd PDP ddress), if the NSAPI mtches tht of n lredy ctivted PDP context, then the network shll dectivte only the existing PDP context loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. It is n implementtion option if the prmeters used for comprison described in cluse i) nd ii) re the prmeters provided in the (current nd previous) ACTIVATE PDP CONTEXT REQUESTs or the prmeters which re the result of the ppliction of the selection rules defined in TS Annex A.2. The prmeter provided in the current ACTIVATE PDP CONTEXT REQUEST cn not be compred to the ctully used prmeters (result of ppliction of selection rules defined in TS Annex A.2) of the previously ctivted PDP contexts. CR pge 3

55 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 319 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Correction of PDP context dupliction hndling Fujitsu Work item code: GPRS Dte: 23/Nov/2000 Ctegory: A Criticl correction Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: According to the , templte of PDP context using dynmic PDP ddress llows to estblish more thn one PDP context bsed on the templte. But current text in does not llow the cse becuse the network recognizes the cse s n illegl cse. The mismtch shll be corrected updting to be in line with Summry of chnge: The duppliction check shll be skipped with regrd to the dynmic PDP ddress. Consequences if not pproved: Cluses ffected: More thn one PDP context to n APN using dynmic PDP ddress is not llowed. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings. CR pge 1

56 3) With "trck chnges" disbled, pste the entire CR form (use CTRL-A to select it) into the specifiction just in front of the cluse contining the first piece of chnged text. Delete those prts of the specifiction which re not relevnt to the chnge request. CR pge 2

57 Abnorml cses The following bnorml cses cn be identified: ) Expiry of timers In the mobile sttion: On the first expiry of the timer T3380, the MS shll resend the ACTIVATE PDP CONTEXT REQUEST nd shll reset nd restrt timer T3380. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3380, the MS shll relese ll resources possibly llocted for this invoction nd shll bort the procedure; no utomtic PDP context ctivtion re-ttempt shll be performed. On the network side: On the first expiry of the timer T3385, the network shll resend the messge REQUEST PDP CONTEXT ACTIVATION nd shll reset nd restrt timer T3385. This retrnsmission is repeted four times, i.e. on the fifth expiry of timer T3385, the network shll relese possibly llocted resources for this ctivtion nd shll bort the procedure. b) Collision of MS initited nd network requested PDP context ctivtion Dynmic PDP ddress collision cse: If the MS uses dynmic PDP ddressing tht turns out to collide with the network requested PDP ddress, then there is no detection of collision specified but left for network implementtion. Sttic PDP ddress collision detected within the mobile sttion: A collision of n MS initited nd network requested PDP context ctivtion procedure is identified by the MS if REQUEST PDP CONTEXT ACTIVATION messge is received from the network fter the MS hs sent n ACTIVATE PDP CONTEXT REQUEST messge, nd the MS hs not yet received n ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE PDP CONTEXT REJECT messge. NOTE: In generl, the MS is unble to test if the PDP type, PDP ddress nd APN in the REQUEST PDP CONTEXT ACTIVATION messge re the sme s those for the PDN to which it is ttempting to ctivte context. This is becuse the MS my hve omitted one or more of the prmeters in the ACTIVATE PDP CONTEXT REQUEST messge, since it is relying on defult vlues to be provided by the network. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. If the MS is ble to compre the PDP type, PDP ddress nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge nd these prmeters re equl, then the MS shll discrd the REQUEST PDP CONTEXT ACTIVATION messge nd shll wit for the network response to its ACTIVATE PDP CONTEXT REQUEST messge. If the MS is not ble to compre the PDP type, PDP ddress, nd APN requested in the ACTIVATE PDP CONTEXT REQUEST messge with those requested in the REQUEST PDP CONTEXT ACTIVATION messge, then the MS shll send REQUEST PDP CONTEXT ACTIVATION REJECT messge with the cuse 'insufficient resources' to the network, nd wit for n ACTIVATE PDP CONTEXT ACCEPT messge. Sttic PDP ddress collision detected on the network side: A collision is detected by the network in the cse where the PDP ddress, PDP type nd APN derived (ccording to nnex A) from the ACTIVATE PDP CONTEXT REQUEST messge received from the MS mtch those in the REQUEST PDP CONTEXT ACTIVATION messge sent to the MS. - In the cse of such collision, the MS initited PDP context ctivtion shll tke precedence over the network requested PDP context ctivtion. The network shll terminte the network requested PDP context ctivtion procedure, nd proceed with the MS initited PDP context ctivtion procedure c) MS initited PDP context ctivtion request for n lredy ctivted PDP context (on the network side) i) If the network receives ACTIVATE PDP CONTEXT REQUEST messge with the sme combintion of APN, PDP type nd PDP ddress s n lredy ctivted PDP context, the network shll dectivte the CR pge 3

58 existing PDP context nd, if ny, ll the linked PDP contexts (mtching the combintion of APN, PDP type nd PDP ddress), loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. Note: If PDP ddress of existing PDP context is dynmic nd estblishment of PDP context using dynmic PDP ddress is requested for the sme APN, it shll be recognised s PDP context dupliction since one APN llows only one dynmic PDP ddress for PDP Type. ii) Alterntively (different combintion of APN, PDP type nd PDP ddress), if the NSAPI mtches tht of n lredy ctivted PDP context, then the network shll dectivte only the existing PDP context loclly without notifiction to the MS nd proceed with the requested PDP context ctivtion. d) Network initited PDP context ctivtion request for n lredy ctivted PDP context (on the mobile sttion side) If the MS receives REQUEST PDP CONTEXT ACTIVATION messge with the sme combintion of APN, PDP type nd PDP ddress s n lredy ctivted PDP context, the MS shll dectivte the existing PDP context nd, if ny, ll the linked PDP contexts (mtching the combintion of APN, PDP type nd PDP ddress) loclly without notifiction to the network nd proceed with the requested PDP context ctivtion. CR pge 4

59 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 320 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: DRX prmeter rnge correction Fujitsu Work item code: GPRS Dte: 23/Nov/2000 Ctegory: F Criticl correction Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The rnge of CN specific DRX cycle length is updted from 2 12 to 6 9 in nd This CR is for the linment of the specifictions. Summry of chnge: CN specific DRX cycle length is updted from 2 12 to 6 9. Consequences if not pproved: Cluses ffected: An MS migtht indicte the DRX cycle length vlue tht my not be supported by UTRAN, nd the network cnnot pge the MS correctly. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings. 3) With "trck chnges" disbled, pste the entire CR form (use CTRL-A to select it) into the specifiction just in front of the cluse contining the first piece of chnged text. Delete those prts of the specifiction which re not relevnt to the chnge request. CR pge 1

60 DRX prmeter The purpose of the DRX prmeter informtion element is to indicte whether the MS uses DRX mode or not. The DRX prmeter is type 3 informtion element with length of 3 octets. The vlue prt of DRX prmeter informtion element is coded s shown in tble /TS DRX prmeter IEI octet 1 SPLIT PG CYCLE CODE octet 2 CN Specific DRX cycle length coefficient SPLIT on CCCH non-drx timer octet 3 Figure /TS : DRX prmeter informtion element Tble /TS : DRX prmeter informtion element SPLIT PG CYCLE CODE, octet 2 The octet contins the binry coded vlue of the SPLIT PG CYCLE CODE. The SPLIT PG CYCLE vlue is derived from the SPLIT PG CYCLE CODE s follows: (equivlent to no DRX) 1 to 64 1 to 64, respectively CR pge 2

61 All other vlues re reserved nd shll be interpreted s 1 by this version of the protocol. SPLIT on CCCH, octet 3 (bit 4) 0 Split pg cycle on CCCH is not supported by the mobile sttion 1 Split pg cycle on CCCH is supported by the mobile sttion non-drx timer, octet 3 bit no non-drx mode fter trnsfer stte mx. 1 sec non-drx mode fter trnsfer stte mx. 2 sec non-drx mode fter trnsfer stte mx. 4 sec non-drx mode fter trnsfer stte mx. 8 sec non-drx mode fter trnsfer stte mx. 16 sec non-drx mode fter trnsfer stte mx. 32 sec non-drx mode fter trnsfer stte mx. 64 sec non-drx mode fter trnsfer stte CN Specific DRX cycle length coefficient, octet 3 bit UMTS specific CN Specific DRX cycle length coefficient not specified by the MS, ie. the system informtion vlue 'CN domin specific DRX cycle length' is used. (Ref TS ) CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient 12 All other vlues shll be interpreted s "CN Specific DRX cycle length coefficient not specified by the MS " by this version of the protocol. Note: In UMTS this field (octet 3 bits 8 to 5) is used, but ws spre in erlier versions of this protocol. CR pge 3

62 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 CHANGE REQUEST CR 321 rev - Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: DRX prmeter rnge correction Fujitsu Work item code: GPRS Dte: 23/Nov/2000 Ctegory: A Criticl correction Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The rnge of CN specific DRX cycle length is updted from 2 12 to 6 9 in nd This CR is for the linment of the specifictions. Summry of chnge: CN specific DRX cycle length is updted from 2 12 to 6 9. Consequences if not pproved: Cluses ffected: An MS migtht indicte the DRX cycle length vlue tht my not be supported by UTRAN, nd the network cnnot pge the MS correctly. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: How to crete CRs using this form: Comprehensive informtion nd tips bout how to crete CRs cn be found t: Below is brief summry: 1) Fill out the bove form. The symbols bove mrked contin pop-up help informtion bout the field tht they re closest to. 2) Obtin the ltest version for the relese of the specifiction to which the chnge is proposed. Use the MS Word "revision mrks" feture (lso known s "trck chnges") when mking the chnges. All 3GPP specifictions cn be downloded from the 3GPP server under ftp:// For the ltest version, look for the directory nme with the ltest dte e.g contins the specifictions resulting from the September 2000 TSG meetings. 3) With "trck chnges" disbled, pste the entire CR form (use CTRL-A to select it) into the specifiction just in front of the cluse contining the first piece of chnged text. Delete those prts of the specifiction which re not relevnt to the chnge request. CR pge 1

63 DRX prmeter The purpose of the DRX prmeter informtion element is to indicte whether the MS uses DRX mode or not. The DRX prmeter is type 3 informtion element with length of 3 octets. The vlue prt of DRX prmeter informtion element is coded s shown in tble /TS DRX prmeter IEI octet 1 SPLIT PG CYCLE CODE octet 2 CN Specific DRX cycle length coefficient SPLIT on CCCH non-drx timer octet 3 Figure /TS : DRX prmeter informtion element Tble /TS : DRX prmeter informtion element SPLIT PG CYCLE CODE, octet 2 The octet contins the binry coded vlue of the SPLIT PG CYCLE CODE. The SPLIT PG CYCLE vlue is derived from the SPLIT PG CYCLE CODE s follows: (equivlent to no DRX) 1 to 64 1 to 64, respectively CR pge 2

64 All other vlues re reserved nd shll be interpreted s 1 by this version of the protocol. SPLIT on CCCH, octet 3 (bit 4) 0 Split pg cycle on CCCH is not supported by the mobile sttion 1 Split pg cycle on CCCH is supported by the mobile sttion non-drx timer, octet 3 bit no non-drx mode fter trnsfer stte mx. 1 sec non-drx mode fter trnsfer stte mx. 2 sec non-drx mode fter trnsfer stte mx. 4 sec non-drx mode fter trnsfer stte mx. 8 sec non-drx mode fter trnsfer stte mx. 16 sec non-drx mode fter trnsfer stte mx. 32 sec non-drx mode fter trnsfer stte mx. 64 sec non-drx mode fter trnsfer stte CN Specific DRX cycle length coefficient, octet 3 bit UMTS specific CN Specific DRX cycle length coefficient not specified by the MS, ie. the system informtion vlue 'CN domin specific DRX cycle length' is used. (Ref TS ) CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient CN Specific DRX cycle length coefficient 12 All other vlues shll be interpreted s "CN Specific DRX cycle length coefficient not specified by the MS " by this version of the protocol. Note: In UMTS this field (octet 3 bits 8 to 5) is used, but ws spre in erlier versions of this protocol. CR pge 3

65 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 (former N ) CHANGE REQUEST CR 269 rev r2 Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Unsynchronized PDP contexts hndling MS less Siemens AG Work item code: GPRS Dte: Ctegory: F Relese: R99 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The MS nd the core network my hve different view on wht PDP contexts re in stte PDP-ACTIVE. This problem is likely to hppen due to brek in rdio connection nd should be solved during re-estblishment. Plese see document N for complete description of the sitution nd the proposl to solve the problem. Summry of chnge: Section nd Consequences if not pproved: Cluses ffected: The MS hs less ctive PDP contexts then the network which leds to the sitution tht the network sends dt towrds the MS (over n existing rdio berer) which then discrded on MS side. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

66 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge Service Request procedure (UMTS only) The purpose of this procedure is to trnsfer the PMM mode from PMM-IDLE to PMM-CONNECTED mode, nd/or to ssign rdio ccess berer in cse of PDP contexts re ctivted without rdio ccess berer ssigned. In ltter cse, the PMM mode my be PMM-IDLE or PMM-CONNECTED mode. This procedure is used for; - the initition of CM lyer service (e.g. SM or SMS) procedure from the MS in PMM-IDLE mode. - the network to trnsfer down link signlling, - uplink nd downlink user pcket. For downlink trnsfer of signlling or user pcket, the trigger is given from the network by the pging request procedure, which is out of scope of this specifiction. Service type cn tke either of the following vlues, "signlling", "dt" or "pging response". Ech of the vlues shll be selected ccording to the criteri to initite the Service request procedure. The criteri to invoke the Service request procedure re when; ) the MS hs ny signlling messge, tht requires security protection, to be sent to the network in PMM-IDLE mode (i.e., no secure PS signlling connection hs been estblished). In this cse, the service type shll be set to "signlling". b) the MS, either in PMM-IDLE nd PMM-CONNECTED mode, hs pending user pcket to be sent nd no rdio ccess berer is estblished for the PDP context. The procedure is initited by n indiction from the lower lyers (see TS ). In this cse, the service type shll be set to "dt". c) the MS receives pging request for PS domin from the network in PMM-IDLE mode. In this cse, the service type shll be set to "pging response". After completion of Service request procedure, the pending service is resumed nd uses then the connection estblished by the procedure. If the service type is indicting "dt", then the rdio ccess berers for ll the ctivted PDP contexts re re-estblished. The selective re-ssignment cpbility is not supported for the simplicity of the function. If the network tries to re-estblish rdio ccess berers for which no ctive PDP contexts exists, then the MS shll requestdvice the lower lyer to reject the setup of ll rdio ccess berers. The reject messge hs to include the indiction of which of the PDP contexts re still ctive (NSAPI in SM corresponds to RAB-ID in RRC) nd the reject cuse hs to indicte "unsynchronouspdp. The network shll retry the re-estblishment of those rdio ccess berers for which corresponding ctive PDP context exists when the MS did reject the previous re-estblishment with the cuse indicting "unsynchronouspdp. The indiction of which PDP contexts re still ctive is delivered by the MS in the reject messge. Th network shll dectivte ll those PDP contexts loclly, which hve not been indicted s still ctive by the MS during the procedure described in the two prgrphs bove. ************* Next chnge *************** Abnorml cses on the network side The following bnorml cses cn be identified: ) Lower lyer filure If low lyer filure occurs before the security mode control procedure is completed, SERVICE ACCEPT or SERVICE REJECT messge hs been sent to the MS, the network enters/stys in PMM-IDLE. b) Protocol error If the SERVICE REQUEST messge is received with protocol error, the network shll return SERVICE REJECT messge with one of the following reject cuses: CR pge 2

67 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge 3 #96: Mndtory informtion element error; #99: Informtion element non-existent or not implemented; #100: Conditionl IE error; #111: Protocol error, unspecified. The network stys in PMM-IDLE mode. c.) More thn one SERVICE REQUEST received nd the procedure hs not been completed (i.e., the security mode control procedure hs not been completed or SERVICE ACCEPT, SERVICE REJECT messge hs not been sent), - If one or more of the informtion elements in the SERVICE REQUEST messge differs from the ones received within the previous SERVICE REQUEST messge, the previously initited Service request procedure shll be borted nd the new Service request procedure shll be progressed ; - If the informtion elements do not differ, then the network shll continue with the previous Service request procedure nd shll not tret ny further this SERVICE REQUEST messge. d) ATTACH REQUEST received before the security mode control procedure hs been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs been sent. If n ATTACH REQUEST messge is received nd the security mode control procedure hs not been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs not been sent, the network my initite the GMM common procedures, e.g. the GMM uthentiction nd ciphering procedure. The network my e.g. fter succesful GMM uthentiction nd ciphering procedure execution, bort the Service request procedure, the GMM context nd PDP contexts, if ny, re deleted nd the new ATTACH REQUEST is progressed. e) ROUTING AREA UPDATE REQUEST messge received before the security mode control procedure hs been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs been sent If n ROUTING AREA UPDATE REQUEST messge is received nd the security mode control procedure hs not been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs not been sent, the network my initite the GMM common procedures, e.g. the GMM uthentiction nd ciphering procedure. The network my e.g. fter successful GMM uthentiction nd ciphering procedure execution, bort the Service request procedure nd progress the routing re updte procedure. f) If the Service Type indictes dt nd the network fils to re-estblish some or ll RAB(s) then the SGSN my determines if PDP Context Modifiction or PDP Context Dectivtion should be initited. The pproprite ction depends on the QoS profile of the PDP Context nd is n opertor choice. g) If the Service Type indictes dt nd the network fils to re-estblish some or ll rdio ccess berers then the network (initited by SGSN) shll dectivte ll those PDP contexts loclly for which the cuse is indicting "unsynchronouspdp. CR pge 3

68 3GPP TSG-CN1 Meeting #14 Tdoc N Crdiff, Wles November, 2000 (former N ) CHANGE REQUEST CR 315 rev r1 Current version: CR-Form-v3 For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE X Rdio Access Network Core Network X Title: Source: Unsynchronized PDP contexts hndling MS less Siemens AG Work item code: GPRS Dte: Ctegory: A Relese: REL-4 Use one of the following ctegories: F (essentil correction) A (corresponds to correction in n erlier relese) B (Addition of feture), C (Functionl modifiction of feture) D (Editoril modifiction) Detiled explntions of the bove ctegories cn be found in 3GPP TR Use one of the following releses: 2 (GSM Phse 2) R96 (Relese 1996) R97 (Relese 1997) R98 (Relese 1998) R99 (Relese 1999) REL-4 (Relese 4) REL-5 (Relese 5) Reson for chnge: The MS nd the core network my hve different view on wht PDP contexts re in stte PDP-ACTIVE. This problem is likely to hppen due to brek in rdio connection nd should be solved during re-estblishment. Plese see document N for complete description of the sitution nd the proposl to solve the problem. Summry of chnge: Section nd Consequences if not pproved: Cluses ffected: The MS hs less ctive PDP contexts then the network which leds to the sitution tht the network sends dt towrds the MS (over n existing rdio berer) which then discrded on MS side. Other specs Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: CR pge 1

69 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge Service Request procedure (UMTS only) The purpose of this procedure is to trnsfer the PMM mode from PMM-IDLE to PMM-CONNECTED mode, nd/or to ssign rdio ccess berer in cse of PDP contexts re ctivted without rdio ccess berer ssigned. In ltter cse, the PMM mode my be PMM-IDLE or PMM-CONNECTED mode. This procedure is used for; - the initition of CM lyer service (e.g. SM or SMS) procedure from the MS in PMM-IDLE mode. - the network to trnsfer down link signlling, - uplink nd downlink user pcket. For downlink trnsfer of signlling or user pcket, the trigger is given from the network by the pging request procedure, which is out of scope of this specifiction. Service type cn tke either of the following vlues, "signlling", "dt" or "pging response". Ech of the vlues shll be selected ccording to the criteri to initite the Service request procedure. The criteri to invoke the Service request procedure re when; ) the MS hs ny signlling messge, tht requires security protection, to be sent to the network in PMM-IDLE mode (i.e., no secure PS signlling connection hs been estblished). In this cse, the service type shll be set to "signlling". b) the MS, either in PMM-IDLE nd PMM-CONNECTED mode, hs pending user pcket to be sent nd no rdio ccess berer is estblished for the PDP context. The procedure is initited by n indiction from the lower lyers (see TS ). In this cse, the service type shll be set to "dt". c) the MS receives pging request for PS domin from the network in PMM-IDLE mode. In this cse, the service type shll be set to "pging response". After completion of Service request procedure, the pending service is resumed nd uses then the connection estblished by the procedure. If the service type is indicting "dt", then the rdio ccess berers for ll the ctivted PDP contexts re re-estblished. The selective re-ssignment cpbility is not supported for the simplicity of the function. If the network tries to re-estblish rdio ccess berers for which no ctive PDP contexts exists, then the MS shll requestdvice the lower lyer to reject the setup of ll rdio ccess berers. The reject messge hs to include the indiction of which of the PDP contexts re still ctive (NSAPI in SM corresponds to RAB-ID in RRC) nd the reject cuse hs to indicte "unsynchronouspdp. The network shll retry the re-estblishment of those rdio ccess berers for which corresponding ctive PDP context exists when the MS did reject the previous re-estblishment with the cuse indicting "unsynchronouspdp. The indiction of which PDP contexts re still ctive is delivered by the MS in the reject messge. Th network shll dectivte ll those PDP contexts loclly, which hve not been indicted s still ctive by the MS during the procedure described in the two prgrphs bove. ************* Next chnge *************** Abnorml cses on the network side The following bnorml cses cn be identified: ) Lower lyer filure If low lyer filure occurs before the security mode control procedure is completed, SERVICE ACCEPT or SERVICE REJECT messge hs been sent to the MS, the network enters/stys in PMM-IDLE. b) Protocol error If the SERVICE REQUEST messge is received with protocol error, the network shll return SERVICE REJECT messge with one of the following reject cuses: CR pge 2

70 3GPP TS.bbb vx.y.z (YYYY-MM) CR pge 3 #96: Mndtory informtion element error; #99: Informtion element non-existent or not implemented; #100: Conditionl IE error; #111: Protocol error, unspecified. The network stys in PMM-IDLE mode. c.) More thn one SERVICE REQUEST received nd the procedure hs not been completed (i.e., the security mode control procedure hs not been completed or SERVICE ACCEPT, SERVICE REJECT messge hs not been sent), - If one or more of the informtion elements in the SERVICE REQUEST messge differs from the ones received within the previous SERVICE REQUEST messge, the previously initited Service request procedure shll be borted nd the new Service request procedure shll be progressed ; - If the informtion elements do not differ, then the network shll continue with the previous Service request procedure nd shll not tret ny further this SERVICE REQUEST messge. d) ATTACH REQUEST received before the security mode control procedure hs been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs been sent. If n ATTACH REQUEST messge is received nd the security mode control procedure hs not been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs not been sent, the network my initite the GMM common procedures, e.g. the GMM uthentiction nd ciphering procedure. The network my e.g. fter succesful GMM uthentiction nd ciphering procedure execution, bort the Service request procedure, the GMM context nd PDP contexts, if ny, re deleted nd the new ATTACH REQUEST is progressed. e) ROUTING AREA UPDATE REQUEST messge received before the security mode control procedure hs been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs been sent If n ROUTING AREA UPDATE REQUEST messge is received nd the security mode control procedure hs not been completed or n SERVICE ACCEPT or n SERVICE REJECT messge hs not been sent, the network my initite the GMM common procedures, e.g. the GMM uthentiction nd ciphering procedure. The network my e.g. fter successful GMM uthentiction nd ciphering procedure execution, bort the Service request procedure nd progress the routing re updte procedure. f) If the Service Type indictes dt nd the network fils to re-estblish some or ll RAB(s) then the SGSN my determines if PDP Context Modifiction or PDP Context Dectivtion should be initited. The pproprite ction depends on the QoS profile of the PDP Context nd is n opertor choice. g) If the Service Type indictes dt nd the network fils to re-estblish some or ll rdio ccess berers then the network (initited by SGSN) shll dectivte ll those PDP contexts loclly for which the cuse is indicting "unsynchronouspdp. CR pge 3