Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.060  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   5…   5.3.8…   5.4…   5.4.2…   5.4.9…   5.6…   5.6.2   5.6.3…   5.6.3.7…   5.7…   6…   6.3…   6.5   6.6…   6.8…   6.9…   6.9.1.3   6.9.2…   6.9.2.2…   6.9.2.2.2   6.9.2.2.3…   6.9.2.2.5…   6.9.3…   6.10…   6.12…   6.13…   6.13.1.2…   6.13.2…   6.13.2.2   6.14…   8…   8.2…   9…   9.2.2…   9.2.2.2   9.2.2.3…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.4.2…   9.2.5…   12…   12.5   12.6   12.7…   12.8…   13…   14…   15…   15.3…   16…   16.2…   A…

 

5.7  Functionality Needed for Mobile IPv4

To support the optional Mobile IP services, see TS 23.121, efficiently by GPRS, Foreign Agent (FA) functionality needs to be provided in the GGSN. The interface between the GGSN and FA, including the mapping between the care of IP address and the GTP tunnel in the PLMN is not standardized as the GGSN and the FA are considered to be one integrated node.
Mobile IP service needs a Home Agent (HA) to anchor the IP session. The HA is a router that tunnels datagrams to/from an FA. The FA tunnels/de-tunnels the datagrams between the MS and the HA. In this case, the FA functionality resides in the GGSN. The location of the HA is outside the scope of the 3GPP specifications.
The FA and HA functionality is specified in RFC 3344 [46].
The Mobile IPv4 mobility management capabilities described in this clause are in addition to and distinct from the Mobile IP capabilities defined in TS 23.402. Support of Mobile IPv4 defined for the GGSN is retained in this specification for support of legacy terminals. Interworking between Mobile IPv4 support in the GGSN and MIPv4 as defined in TS 23.402 is not defined for this release.
Up

5.8  Functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes |R5|

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes overcomes the strict hierarchy that restricts the connection of a RAN node to just one CN node, and hence also to one SGSN. This implies that a RAN node must be able to determine which of the SGSNs, covering the area where an MS is located, should receive the signalling and user traffic sent from an MS. To avoid unnecessary signalling in the core network, an MS that has attached to one SGSN, should generally continue to be served by this SGSN as long as the MS is in the radio coverage of the pool area, to which the SGSN is associated. The concept of pool area is a RAN based definition that comprises one or more RA(s) that, from a RAN perspective, are served by a certain group of CN nodes. This does not exclude that one or more of the SGSNs in this group serve RAs outside the pool area. This group of SGSNs is also referred to as an SGSN pool.
To enable the RAN node to determine which SGSN to select when forwarding messages from an MS, Intra Domain Connection of RAN Nodes to Multiple CN Nodes defines a routing mechanism (and other related functionality). Another routing mechanism (and other related functionality) is defined for the SGSNs that support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes. The routing mechanism is required to find the correct old SGSN (from the multiple SGSNs that are associated with a pool area). When an MS roams out of the pool area and into the area of one or more SGSNs that do not know about the internal structure of the pool area where the MS roamed from, the new SGSN will send the Identification Request message or the SGSN Context Request message to an SGSN that is believed to be the old SGSN. This SGSN, which is associated with the same pool area as the actual old SGSN, resolves the ambiguity of multiple SGSNs in the pool area and determines the correct old SGSN from the P-TMSI (or the TLLI). The received message is then relayed to the correct old SGSN (unless it is itself the correct old SGSN). The routing mechanism in both the SGSNs and the RAN nodes utilises the fact that every SGSN that serves a pool area must have its own unique value range of the P-TMSI parameter within the pool area.
The requirements on, and the detailed functionality needed to support, the Intra Domain Connection of RAN Nodes to Multiple CN Nodes are defined in TS 23.236 and additional functionality and requirements related to interworking with E UTRAN are specified in TS 23.401.
Up

5.9  Functionality for network sharing |R6|Word‑p. 72
Network sharing allows multiple network operators to share a radio access network. In a shared network, an MS that supports network sharing selects one of the operators and indicates it to the network. This allows the network to provide services from the selected operator. For an MS that does not support network sharing, the network may select the network operator that provides the services.
The functionality needed to support network sharing is defined in TS 23.251.
Up

5.10  IMS Emergency Session Support |R9|

5.10.1  Introduction

Emergency bearer services are provided to support IMS emergency sessions. Emergency bearer services are functionalities provided by the serving network when the network is configured to support emergency bearer services. Emergency bearer services are provided to normal attached UEs and to UEs that are in limited service state. Receiving emergency services in limited service state does not require a subscription. To provide emergency bearer services as a local service, node configuration parameters may be used to set service values that would otherwise be obtained from subscription data.
When a PLMN supports IMS and emergency bearer services in UTRAN, all SGSNs in that PLMN shall have the same capability to support emergency bearer services.
For emergency services other than eCall, a UE that is not in in limited service state, as specified in TS 23.122 determines from a NAS indicator whether that additional emergency numbers/types received via WLAN from trusted sources may be used for detecting emergency calls.
Up

5.10.2  PS Domain Functions for IMS Emergency Session SupportWord‑p. 73

5.10.2.1  General

IMS emergency sessions over emergency access via packet core are supported for UTRAN access as well as inter-RAT handover between UTRAN and E-UTRAN. Support for Packet Core (GPRS and EPS) emergency bearer services over GERAN networks is not included in this Release and thus PS handover to GERAN access should not be performed when IMS emergency sessions over EPS or GPRS using emergency bearer services are active.
The MS shall signal a cause specific for emergency as defined in TS 25.331 when it requests an RRC connection in relation to an emergency session. Specific situations that require setting the RRC establishment cause to emergency are described in TS 24.008.
Up

5.10.2.2  Reachability Management for Emergency Attached MS in PMM-IDLE state

An emergency attached MS when its periodic RA update timer expires shall not initiate a periodic RAU procedure but enter PMM- DETACHED state. The SGSN assigns the periodic RAU timer value to emergency attached MS. This timer keeps the MS emergency attached after change to PMM-IDLE state to allow for a subsequent emergency service without a need to emergency attach again. For emergency attached MS the SGSN runs a mobile reachable timer with a similar value to the MS's periodic RAU timer. Any time after expiry of this timer the SGSN may change the PMM state of an emergency attached MS to PMM- DETACHED.
Up

5.10.2.3  Mobility and Access Restrictions for Emergency Services

When Emergency Services are supported and local regulation requires Emergency Sessions to be provided regardless of mobility or access restrictions, regional subscription restrictions or access restrictions (see TS 23.221 and TS 23.008) e.g. CSG restrictions, should not be applied to MSs receiving emergency services. When the RABs for emergency bearers are established, the ARP value for emergency bearer services indicates the usage for emergency services to the UTRAN.
During handover, the source UTRAN and source SGSN ignore any MS related restrictions during handover evaluation when there are active emergency bearers. UTRAN shall not initiate handover to GERAN PS domain. During handover to a CSG cell, if the UE is not a CSG member of the target CSG cell and has emergency bearer services, the target RNC only accepts the emergency bearers and the target SGSN releases the non-emergency bearers that were not accepted by the target RNC according to clause 9.2.4.2. Such UEs behave as emergency attached.
During Routing Area Update procedures, including a RAU as part of a handover, the target SGSN ignores any mobility or access restrictions for MS with emergency bearer services where required by local regulation. Any non emergency bearer services are deactivated, according to clause 9.2.4.2, by the target SGSN when not allowed by the subscription for the target location. Such MSs behave as emergency attached. To allow the emergency attached MS to get access to normal services after the emergency session has ended and when it has moved to a new area that is not stored by the MS as a forbidden area, the MS may explicitly detach and reattach to normal services without waiting for the emergency PDN connection deactivation by the PDN GW or GGSN.
This functionality applies to all mobility procedures.
Up

5.10.3  Attach handling

An MS in limited service state, as specified in TS 23.122, initiates the GPRS Attach procedure by indicating that the attach procedure is for emergency services. The Attach Request message for emergency attach purpose is indicated as Attach Type "GPRS Emergency Attach". Also MSs that had attached for normal service and do not have emergency bearers established and are camped on a cell, where the MS is in limited service state (e.g. because of change to a restricted Tracking Area or not allowed CSG), shall initiate this Attach procedure, indicating that the attach is to receive emergency services. The network which support emergency services for an MS in limited service state provides emergency attach service to this MS, according to regulatory requirements. The UEs in limited service state determine that the cell supports emergency bearer services for IMS based emergency services over UTRAN from a broadcast indicator in AS.
TS 23.401 describes in clause "IMS Emergency Session Support" how the network provides emergency services according to different local regulations. Roaming or mobility restrictions are not applied when the network supports emergency services. Emergency Attach is supported only in UTRAN access.
An MS that camps normally on a cell, i.e. without any conditions that result in limited service state, initiates the normal GPRS attach procedure if not already attached. A normal attached IMS enabled MS is assumed to have a non-emergency PDN connection. A normal attached MS initiates the GPRS PDP Context Activation procedure by indicating emergency service to receive emergency bearer services. The UEs that camp normally on a cell are informed that the PLMN supports emergency bearer services for IMS based emergency services over UTRAN from the Emergency Service Support indicator in the Attach and RAU procedures. UEs that camp normally on a cell may also use the emergency attach procedure under conditions specified in TS 24.008, e.g. when the MM back-off timer is running.
The details for Emergency Attach are included in the Combined GPRS/IMSI Attach procedure, see clause 6.5.3.
Up

5.10.4  PDP Context Activation for emergency bearer servicesWord‑p. 74
The procedure is executed after the MS has successfully performed a GPRS attach and is valid for both normal and limited service state. The MS shall always activate a new PDP Context when emergency bearer services are invoked. When the MS detects a request for emergency service and it is required to establish a PDP context within the same network as the SGSN, the MS performs a PDP context activation with an indication of emergency usage so that emergency bearer services handling can be provided by the local network per configuration without subscription limitations. The request for emergency bearer services is indicated as Request Type "emergency" in the PDP Context Activation message.
MS request for emergency PDP context activation is added into the PDP Context Activation Procedure in clause 9.2.2.1.
The enhancements to support MS request for emergency PDP context activation are:
  1. The PDP Context Activation Request includes an indication of emergency usage.
  2. Configuration parameters in the network are used to override subscription limitations such as bearer QoS.
The PDN GW/GGSN selection function in the SGSN shall derive a PDN GW/GGSN identity in the visited PLMN by using the Emergency APN. The PDN GW/GGSN address is derived from the PDN GW/GGSN identity by using the Domain Name Service function. If the Domain Name Service function provides a list of PDN GW/GGSN addresses, one PDN GW/GGSN address is selected from this list. If the selected PDN GW/GGSN cannot be used, e.g. due to an error, then another PDN GW/GGSN is selected from the list. The specific interaction between the SGSN and the Domain Name Service function may include functionality to allow for the retrieval or provision of additional information regarding the PDN GW capabilities (e.g. whether the PDN GW supports PMIP based or GTP-based S5/S8, or both).
If there is already an emergency bearer activated, the SGSN shall reject any PDP context activation request for normal services if the mobility and access restrictions do not allow the MS to access normal services.
If the PDN GW/GGSN identity is statically configured in the SGSN, then it may be a FQDN or an IP Address[es].
Up

5.10.5  Handling of PDN Connections for Emergency Bearer Services

The PDP contexts (described in clause 5.10.4) of a PDN Connection associated with the emergency APN shall be dedicated for IMS emergency sessions and shall not allow any other type of traffic. The Emergency PDP contexts shall not be changed to normal PDP contexts and vice versa.
The PDN GW/GGSN shall block any traffic that is not from or to addresses of network entities (e.g. P-CSCF) providing IMS emergency service. Dynamic PCC shall be deployed in order to support IMS emergency sessions, the procedures are as described in TS 23.203. If there is already an emergency PDN connection, the MS shall not request another emergency PDN Connection. The SGSN shall reject any additional emergency PDN Connection requests. The MS shall not initiate any Secondary PDP Context Activation Procedure or any PDP Context Modification Procedure for the emergency PDN connection. The PDN GW/GGSN shall reject any MS initiated Secondary PDP Context Activation Procedure or any PDP Context Modification Procedure that is for the emergency PDN Connection.
The ARP reserved for emergency bearer service shall only be assigned to bearers associated with an emergency PDN Connection.
For emergency attached MS, SGSN initiates an implicit detach based on an inactivity timeout specific to emergency.
Up

Up   Top   ToC