Section: J.6 Handling of special situations
Content: Situations may occur that cause unsynchronized state information in the UE, MME and SGSN. Such situations are: - Modification of any EPS bearer context or PDP context which was activated before the ISR is activated in the UE; - At the time when the UE moves from E-UTRAN to GERAN/UTRAN or moves from GERAN/UTRAN to E-UTRAN, if any EPS bearer context or PDP context activated after the ISR was activated in the UE exists; - Missing periodic TA or RA updates, e.g. because the coverage of a RAT is lost or the RAT is no more selected by the UE (this may result also in implicit detach by SGSN or MME); - CN node change resulting in context transfer between the same type of CN nodes (SGSN to SGSN or MME to MME); - Serving GW change (both with and without UE mobility); - Change of the UE specific DRX parameters; - Change of the UE Core Network Capabilities; - E-UTRAN selection by a UTRAN-connected UE (e.g. when in URA_PCH to release Iu on UTRAN side); E-UTRAN selection from GERAN READY state; - GERAN selection by an E-UTRAN-connected UE via Cell Change Order that is not for CS fallback. There are no ISR specific procedures to handle such situations to avoid additional complexity and error cases. All special situations that cause context in the UE, MME and SGSN to become asynchronous are handled by ISR deactivation. The normal RAU/TAU procedures synchronize contexts in MME and SGSN and activate ISR again when wanted by the network. Some specific handling is defined to enable combined MME/SGSN. For this the UE signals at UTRAN RRC level always an Intra Domain NAS Node Selector (IDNNS) derived from the ID signalled as P-TMSI (also when mapped from GUTI). At E-UTRAN RRC level the UE indicates the GUMMEI derived from the GUTI that is signalled in the TAU Request message (also when derived from P-TMSI). This handling is performed by the UE independent from the network configuration. It is not visible to the UE whether MME and SGSN are combined. Given the IP-based architecture of EPS and the IP-based applications such establishment and deactivation of the EPS bearer or PDP context can happen frequently before the UE changes the RAT e.g. a UE asking for delivery of an SMS (over IP) or starting a VoIP over IMS, an entirely new EPS bearer or PDP context may be established for that purpose. Then, after the application/service is finished, the newly established EPS bearer or PDP context gets deactivated. In such particular situation the deactivation of the ISR at the UE and hence performing a RAU or TAU update when the UE changes the RAT is not needed. Preventing the UE from deactivating the ISR in this case ensures an efficient usage of the UE's battery power and reduces the unnecessary signalling load that is seen as the key objective to be achieved by introducing the ISR feature. Thus, UE only locally deactivates ISR when bearer existed at the time of ISR is activated, or when UE changes RAT with bearers which are created after ISR is activated.