Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   4.2.2…   4.3…   4.3.6…   4.3.8…   4.3.12…   4.3.16…   4.3.20…   4.3.25…   4.4…   4.6…   4.7…   5…   5.1.2…   5.3…   5.3.2…   5.3.3…   5.3.3.2   5.3.3.3…   5.3.4…   5.3.4B…   5.3.5…   5.3.8…   5.3.9…   5.4…   5.4.4…   5.5…   5.5.1.2…   5.5.2…   5.5.2.2…   5.5.2.3…   5.5.2.4…   5.6…   5.7.3…   5.7A…   5.10   5.11…   5.19…   D…   D.3…   D.3.4   D.3.5   D.3.6   D.3.7…   D.3.8…   E   F…   J…   K…   L…   M…

 

4.3.12  IMS Emergency Session Support |R9|p. 54

4.3.12.1  Introductionp. 54

Clause 4.3.12 IMS Emergency Session provides an overview about functionality for emergency bearer services in a single clause. This overview applies to eCall Over IMS unless stated otherwise. The specific functionality is described in the affected procedures and functions of this specification. For discrepancies between this overview clause and the detailed procedure and function descriptions the latter take precedence.
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 services. Emergency bearer services are provided to normal attached or emergency attached UEs and depending on local regulation, to UEs that are in limited service state. Receiving emergency services in limited service state does not require a subscription. Depending on local regulation and an operator's policy, the MME may allow or reject an emergency attach request for UEs in limited service state. Four different behaviours of emergency bearer support have been identified as follows:
  1. Valid UEs only: No limited service state UEs are supported in the network. Only UEs that have a valid subscription, are authenticated and authorized for PS service in the attached location are allowed. UEs should be attached to the network and then perform a PDN Connection Request when an IMS emergency session is detected by the UE.
  2. Only UEs that are authenticated are allowed: These UEs must have a valid IMSI. These UEs are authenticated and may be in limited service state due to being in a location that they are restricted from service. A UE that can not be authenticated will be rejected.
  3. IMSI required, authentication optional: These UEs must have an IMSI. If authentication fails, the UE is granted access and the unauthenticated IMSI retained in the network for recording purposes. The IMEI is used in the network as the UE identifier. IMEI only UEs will be rejected (e.g., UICCless UEs).
  4. All UEs are allowed: Along with authenticated UEs, this includes UEs with an IMSI that can not be authenticated and UEs with only an IMEI. If an unauthenticated IMSI is provided by the UE, the unauthenticated IMSI is retained in the network for recording purposes. The IMEI is used in the network to identify the UE.
To provide emergency bearer services, the MME is configured with MME Emergency Configuration Data that are applied to all emergency bearer services that are established by an MME on UE request. The MME Emergency Configuration Data contain the Emergency APN which is used to derive a PDN-GW, or the MME Emergency Configuration Data may also contain the statically configured PDN-GW for the Emergency APN.
For Cellular IoT over satellite access, if a UE in limited service state is aware of its location within certain country, the UE should select a PLMN that serves the country where the UE is located as specified in clause 4.13.2. The network may be configured to verify the location of a UE that is registering for emergency services as specified in clause 4.13.4.
UEs that are in limited service state, as specified in TS 23.122, initiate the Attach procedure with indicating that the attach is to receive emergency services. Also UEs that had attached for normal services and do not have emergency bearers established and are camped on a cell in limited service state (e.g. because of restricted Tracking Area or not allowed CSG) shall initiate this Attach procedure, indicating that the attach is to receive emergency services. The network supporting emergency services for UEs in limited service state provides emergency bearer services to these UE, regardless whether the UE can be authenticated, has roaming or mobility restrictions or a valid subscription, depending on local regulation. For emergency services other than eCall, the UEs in limited service state determine that the cell supports emergency services over E-UTRAN from a broadcast indicator in AS. Emergency calls for eCall Over IMS are only performed if the UE has a UICC.
A serving network shall provide an Access Stratum broadcast indication to UEs as to whether eCall Over IMS is supported.
A UE in limited service state determines that the cell supports eCall Over IMS using both the broadcast indicator for support of emergency services over E-UTRAN and the broadcast indicator for eCall over IMS.
For a UE that is Emergency Attached, if it is unauthenticated the EPS security context is not set up on UE.
UEs that camp normally on a cell, i.e. without any conditions that result in limited service state, initiate the normal initial attach procedure if not already attached. Normal attached UEs initiate the UE Requested PDN Connectivity procedure to receive emergency bearer services. The UEs that camp normally on a cell are informed that the PLMN supports emergency bearer services over E-UTRAN from the Emergency Service Support indicator in the Attach and TAU procedures. MME may be configured to indicate Emergency Service Support indicator on a per-HPLMN basis. UEs that camp normally on a cell may also use the emergency attach procedure under conditions specified in TS 24.301, e.g. when the MM back-off timer is running.
For a UE that is Emergency Attached, normal PLMN selection principles apply after the end of the IMS emergency session.
For emergency bearer services any EPC functions, procedures and capabilities are provided according to clause 4 except when specified differently in the following clauses.
For emergency bearer services, there is a risk of service disruption due to failed inter PLMN mobility attempts.
For emergency bearer services, handover from non-3GPP access to E-UTRAN access is supported as specified in clause 4.5.7.2.10 of TS 23.402.
The UE shall set the RRC establishment cause or RRC resume cause to emergency as defined in TS 36.331 when it requests an RRC connection in relation to an emergency session. Specific situations that require setting the RRC establishment cause or RRC resume cause to emergency are described in TS 24.301.
Support for emergency bearer services is not available when the UE is using NB-IoT, i.e. the MME shall not indicate support for emergency bearer services using the Emergency Service Support indicator in the Attach and TAU procedures to a UE that accesses the network using a RAT Type equal to NB-IoT, and an NB-IoT cell shall not indicate support for emergency services in any broadcast information in AS.
When a PLMN supports IMS and emergency bearer services, all MMEs 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 additional emergency numbers/types received via WLAN from trusted sources may be used for detecting emergency calls.
Up

4.3.12.2  Architecture Reference Model for Emergency Servicesp. 56

According to clause 4.2, the non-roaming architectures (Figure 4.2.1-1 and Figure 4.2.1-2) and roaming architecture with the visited operator's application function (Figure 4.2.2-3) apply for emergency services. The other roaming architectures with services provided by the home network do not apply for emergency services.
Up

4.3.12.3  Mobility and Access Restrictions for Emergency Servicesp. 56

When Emergency Services are supported and local regulation requires Emergency Sessions to be provided regardless of mobility or access restrictions, the Mobility Restrictions in clause 4.3.5.7, should not be applied to UEs receiving emergency services. When the E-RABs for emergency bearers are established, the ARP value for emergency bearer services indicates the usage for emergency services to the E-UTRAN.
During handovers, the source E-UTRAN and source MME ignore any UE related restrictions during handover evaluation when there are active emergency bearers. E-UTRAN shall not initiate handover to GERAN PS domain. During handover to a CSG cell, if the UE is not a CSG member of target CSG cell and has emergency bearer services, the target eNodeB only accepts the emergency bearers and the target MME releases the non-emergency PDN connections that were not accepted by the target eNodeB as specified in clause 5.10.3. Such UEs behave as emergency attached.
During Tracking Area Update procedures, including a TAU as part of a handover, the target MME ignores any mobility or access restrictions for UE with emergency bearer services where required by local regulation. Any non-emergency bearer services are deactivated, according to clause 5.10.3, by the target MME when not allowed by the subscription for the target location. Such UEs behave as emergency attached. To allow the emergency attached UE 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 UE as a forbidden area, the UE may explicitly detach and reattach to normal services without waiting for the emergency PDN connection deactivation by the PDN-GW.
This functionality applies to all mobility procedures.
Up

4.3.12.3a  Reachability Management for UE in ECM-IDLE statep. 57

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

4.3.12.4  PDN-GW selection function (3GPP accesses) for Emergency Servicesp. 57

When a PDN GW is selected for IMS emergency services support, the PDN GW selection function described in clause 4.3.8.1 for normal bearer services is applied to the Emergency APN or the MME selects the PDN GW directly from the MME Emergency Configuration Data. If the PDN GW selection function described in clause 4.3.8.1 is used it shall always derive a PDN GW in the visited PLMN, which guarantees that also the IP address is allocated by the visited PLMN. In networks that support handover between E-UTRAN and HRPD accesses, the MME selects a PDN GW that is statically configured in the MME Emergency Configuration Data. In networks that support handover between E-UTRAN and WLAN accesses, when the UE has been authorized but has not been authenticated, the MME selects the PDN GW that is statically configured in the MME Emergency Configuration Data. The PDN GW selection does not depend on subscriber information in the HSS since emergency service support is a local, not subscribed service. The MME Emergency Configuration Data contains the Emergency APN which is used to derive a PDN GW, or the MME Emergency Configuration Data may also contain the statically configured PDN GW for the Emergency APN. In the case of GateWay Core Network sharing, the MME shall support separate MME Emergency Configuration Data for each of the sharing PLMNs. In the case of GateWay Core Network sharing and PDN GW selection for the Emergency APN, the MME shall be able to take the selected PLMN ID into account to derive a PDN GW.
This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases when establishing emergency bearer services.
Up

4.3.12.5  QoS for Emergency Servicesp. 57

Where local regulation require supporting calls from an unauthorised caller, the MME may not have subscription data. Additionally, the local network may want to provide IMS emergency services support differently than what is allowed by a UE subscription. Therefore, the initial QoS values used for establishing emergency bearer services are configured in the MME in the MME Emergency Configuration Data.
This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases when establishing emergency bearer services.
Up

4.3.12.6  PCC for Emergency Servicesp. 57

Dynamic PCC is used for UEs establishing emergency service, the procedures are as described in TS 23.203. When establishing emergency bearer services with a PDN-GW, according to clause 4.7.5, the PCRF provides the PDN-GW with the QoS parameters, including an ARP value reserved for the emergency bearers to prioritize the bearers when performing admission control. Dynamic PCC shall be used to manage IMS emergency sessions when an operator allows IMS emergency sessions.
The PCRF ensures that the emergency PDN connection is used only for IMS emergency sessions. The PCRF rejects an IMS session established via the emergency PDN connection if the AF (i.e. P-CSCF) does not provide an emergency indication to the PCRF.
Up

4.3.12.7  Load re-balancing between MMEs for Emergency Servicesp. 58

As per load re-balancing procedures in clause 4.3.7.3, the MME is allowed to off-load ECM-CONNECTED mode UEs by initiating S1 Release procedures. When a UE is in ECM-CONNECTED mode with an active emergency bearer service, the MME should not release the UE for load re-balancing. The MME should wait until the UE initiates a TAU or becomes inactive. The MME may release the UE under critical conditions such as the need to perform an MME node restart.
Up

4.3.12.8  IP Address Allocationp. 58

Emergency bearer service is provided by the serving PLMN. The UE and PLMN must have compatible IP address versions in order for the UE to obtain a local emergency PDN connection. IP address allocation in the serving PLMN is provided per clause 5.3.1 with the exception that the PDN-GW associated with the emergency APN shall support PDN type IPv4 and PDN type IPv6.

4.3.12.9  Handling of PDN Connections for Emergency Bearer Servicesp. 58

The default and dedicated EPS bearers 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 bearer contexts shall not be changed to non-emergency bearer contexts and vice versa. The PDN-GW 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-GW connection, the UE shall not request another emergency PDN Connection. The MME shall reject any additional emergency PDN Connection requests. The UE shall not request any bearer resource modification for the emergency PDN connection. The PDN-GW shall reject any UE requested bearer resource modification that is for the emergency PDN Connection. The ARP reserved for emergency bearer service shall only be assigned to EPS bearers associated with an emergency PDN Connection.
Up

4.3.12.10  ISR function for Emergency Bearer Servicesp. 58

When UE has only emergency bearer service, ISR does not apply.

4.3.12.11  Support of eCall Only Mode |R14|p. 58

For service requirements for eCall only mode, refer to TS 22.101.
A UE configured for eCall Only Mode shall remain in EMM-DEREGISTERED state, shall camp on a network cell when available but shall refrain from any Mobility Management or other signalling with the network. The UE may instigate Mobility Management and Connection Management procedures in order to establish, maintain and release an eCall Over IMS session or a session to any non-emergency MSISDN(s) or URI(s) configured in the UICC for test and/or terminal reconfiguration services. Following the release of either session, the UE starts a timer whose value depends on the type of session (i.e. whether eCall or a session to a non-emergency MSISDN or URI for test/reconfiguration). While the timer is running, the UE shall perform normal Mobility Management procedures and is permitted to respond to paging to accept and establish an incoming session (e.g. from an emergency centre, PSAP or HPLMN operator). When the timer expires, the UE shall perform a UE-initiated detach procedure if still attached and enter EMM-DEREGISTERED state.
When attaching to EPS for E-UTRAN access, a UE configured for eCall Only Mode may indicate support for radio capabilities for IRAT Handover (for UTRAN) or SRVCC Handover (for GERAN), but shall not indicate support for IMS Voice over RATs other than E-UTRAN.
Up

4.3.12a  Support of Restricted Local Operator Service |R16|p. 59

4.3.12a.1  Introductionp. 59

Restricted Local Operator Services is an optional feature supported in certain countries. Service requirements of Restricted Local Operator Services is defined in TS 22.101 and the architectural requirements are defined in TS 23.221.
Access to Restricted Local Operator Services may be allowed for UEs in limited service state by the serving network depending on local regulation and operator policies. UEs may enter limited service state as specified in clause 4.3.12.1.
RLOS is requested by the UE, based on explicit request from the user. When attaching to the network to access RLOS, the UE shall send a NAS RLOS indication to the MME, which proceeds with the RLOS attach procedure described in clause 5.3.2.1 A specific RLOS-APN, unique for the PLMN, is configured in the MME.
Allowing access to RLOS is completely under the local operator's control, e.g. EPC access for RLOS does not depend on whether the UE is authenticated or not, nor on whether authentication succeeds or fails.
To provide access to Restricted Local Operator Services, the MME is configured with MME RLOS Configuration Data that are applied to RLOS PDN connection that is established by an MME upon UE request. The MME RLOS Configuration Data contain the RLOS APN which is used to derive a PDN-GW, or the MME RLOS Configuration Data may contain the statically configured PDN-GW for the RLOS APN.
UEs in limited service state intending to access Restricted Local Operator Services determines that the cell supports RLOS services over E-UTRAN via a broadcast indicator in AS and subsequently initiates the Attach procedure with an indication that the attach is to access RLOS. The Networks supporting Restricted Local Operator Services provides access to these UEs, regardless whether authentication for the UEs is performed or not, and regardless of the authentication result if authentication is performed. If the PLMN does not advertise its support of RLOS, the UE shall block the origination attempt for RLOS.
Restricted Local Operator Services is applicable to WB-E-UTRAN only. Restricted Local Operator Services does not support UE requested PDN connectivity, inter-RAT mobility and Network triggered Service Request. Handover between 3GPP and non-3GPP accesses are not supported for UEs attached for RLOS. Location service does not apply to Restricted Local Operator Services.
On-line charging is not activated for RLOS APN. For off-line charging, an RLOS APN indication as well as IMEI, if available, is added to charging records.
Up

4.3.12a.2  Architecture Reference Model for Restricted Local Operator Servicesp. 59

The same architecture as for emergency service specified in clause 4.3.12.2 applies.

4.3.12a.3  Mobility and Access Restrictionsp. 59

When access to Restricted Local Operator Services is supported, the Mobility Restrictions in clause 4.3.5.7 should not be applied to UEs receiving Restricted Local Operator Services. However, for a RLOS attached UE, the MME shall restrict mobility to GERAN and UTRAN, and include GERAN and UTRAN in the Handover Restriction List.

4.3.12a.4  PDN-GW selection function for Restricted Local Operator Servicesp. 59

Same mechanism as for emergency service specified in clause 4.3.12.4 applies with the following difference:
For Restricted Local Operator Services, RLOS Configuration Data containing RLOS APN is needed in MME. However, HRPD or WLAN handovers don't apply.

4.3.12a.5  QoS for Restricted Local Operator Servicesp. 60

The initial QoS values used for establishing RLOS PDN connection during RLOS attach are obtained from the MME RLOS Configuration Data.

4.3.12a.6  PCC for Restricted Local Operator Servicesp. 60

Dynamic PCC based on the procedures described in TS 23.203 may be used for UEs accessing Restricted Local Operator Services which involve voice services. When establishing PDN connection towards the RLOS APN with a PDN-GW, according to clause 4.7.5, the PCRF provides the PDN-GW with the QoS parameters, based on operator policy, including an ARP value reserved for the Restricted Local Operator Services where RLOS has a lower priority in terms of admission control than regular PDN connections
The PCRF ensures that the RLOS PDN connection is used only for Restricted Local Operator Services. The PCRF rejects an IMS session established via the RLOS PDN connection if the AF (i.e. P-CSCF) does not provide an RLOS indication to the PCRF.
Up

4.3.12a.7  IP Address Allocationp. 60

RLOS is provided by the serving PLMN. The UE and PLMN must have compatible IP address versions in order for the UE to obtain a RLOS PDN connection. IP address allocation in the serving PLMN is provided according to clause 5.3.1 with the exception that the PDN-GW associated with the RLOS APN shall support PDN type IPv4 and PDN type IPv6.

4.3.12a.8  Emergency service for RLOS attached UEp. 60

For an RLOS attached UE initiating emergency service, the UE shall first perform a local detach prior to initiating an emergency attach as described in TS 24.301.

4.3.13  Closed Subscriber Group functions |R9|p. 60

Closed Subscriber Group identifies a group of subscribers who are permitted to access one or more CSG cells of the PLMN as a member of the CSG for a HeNB. The following CSG related functions are defined:
  • CSG subscription handling function stores and updates the user's CSG subscription data at the UE and the network.
  • For closed mode, CSG access control function ensures a UE has valid subscription at a CSG where it performs an access.
  • Admission and rate control function is used to provide different admission and rate control for CSG and non-CSG members for a hybrid CSG cell.
  • CSG charging function enables per CSG charging for a subscriber consuming network services via a CSG cell or a hybrid cell.
  • CSG Paging Optimisation function is optionally used to filter paging messages as described in clause 5.3.4.3.
  • VPLMN Autonomous CSG roaming function is optionally supported whereby a VPLMN, if allowed by the HPLMN, stores and manages VPLMN specific CSG subscription information for roaming UEs without interaction with the HSS.
  • CSG membership verification without updating the User CSG Information in the Core Network in the case of Dual Connectivity when the Secondary eNodeB is a hybrid access eNodeB.
Up

4.3.14  Location Service functions |R9|p. 60

LCS procedures are described in the LCS stage 2 specification, see TS 23.271.
In addition, in the Detach and Bearer Deactivation procedures, the MME shall inform the S-GW of the last known location of the UE, and shall provide information to enable the determination of the time at which the UE was in that location. The S-GW shall (if necessary taking into account information from the SGSN) inform the PDN-GW of the last known location of the UE, and shall provide information to enable the determination of the time at which the UE was in that location. If requested by the PCRF the PDN-GW shall indicate this information to the PCRF as defined in TS 23.203. The information can also be made available on the SGi interface as specified in TS 29.061 and on the CDRs at network elements such as the S-GW and PDN-GW as specified in TS 32.251.
Up

4.3.15  Selected IP Traffic Offload (SIPTO) function |R10|p. 61

The SIPTO function enables an operator to offload certain types of traffic at a network node close to that UE's point of attachment to the access network. The SIPTO function specified in this TS applies to IP PDN Types and Ethernet and Non-IP PDN Types.
SIPTO above RAN can be achieved by selecting a set of GWs (S-GW and P-GW) that is geographically/topologically close to a UE's point of attachment.
SIPTO above RAN corresponds to a traffic offload through a P-GW located in the mobile operator's core network.
SIPTO applies to both the non-roaming case and, provided appropriate roaming agreements are in place between the operators, to the roaming case.
Offload of traffic for a UE is available for UTRAN and E-UTRAN accesses only. When the UE enters to UTRAN/E-UTRAN from another type of access network (e.g., from GERAN), it is the responsibility of the new SGSN/MME to decide whether to perform deactivation with reactivation request for a given PDN connection, depending on SIPTO permissions for the relevant APN.
Realization for SIPTO above RAN relies on the same architecture models and principles as for local breakout described in clause 4.2.
In order to select a set of appropriate GW (S-GW and P-GW) based on geographical/topological proximity to UE, the GW selection function specified in TS 29.303 uses the UE's current location information.
In order for the operator to allow/prohibit SIPTO on per user and per APN basis, subscription data in the HSS is configured to indicate to the MME if offload is allowed or prohibited. If the SIPTO permissions information from the HSS conflicts with MME's configuration for that UE, then SIPTO is not used.
If HSS indicates VPLMN address not allowed, then VPLMN (i.e. MME) shall not provide SIPTO.
In the absence of any SIPTO permissions indication from the HSS the VPLMN (i.e MME) shall not provide SIPTO.
The MME may be configured on a per APN basis as to whether or not to use SIPTO (e.g. to handle the case where the HSS is not configured with SIPTO information for the UE).
For SIPTO above RAN, as a result of UE mobility (e.g. detected by the MME at TAU or SGSN at RAU or movement from GERAN), the target MME may wish to redirect a PDN connection towards a different GW that is more appropriate for the UE's current location, e.g. MME may know whether the UE's new location is served by the same GW as the old one. When the MME decides upon the need for GW relocation, the MME deactivates the impacted PDN connections indicating "reactivation requested" as specified in clause 5.10.3. If all of the PDN connections for the UE need to be relocated, the MME may initiate the "explicit detach with reattach required" procedure as specified in clause 5.3.8.3.
Up

4.3.15a  Selected IP Traffic Offload (SIPTO) at the Local Network |R12|p. 61

4.3.15a.1  Generalp. 61

The SIPTO at the Local Network function enables an IP capable UE connected via a (H)eNB to access a defined IP network (e.g. the Internet) without the user plane traversing the mobile operator's network.
The subscription data in the HSS are configured per user and per APN to indicate to the MME if offload at the local network is allowed or not.
SIPTO at the Local Network can be achieved by selecting a L-GW function collocated with the (H)eNB or selecting stand-alone GWs (with S-GW and L-GW collocated) residing in the Local Network. In both cases the selected IP traffic is offloaded via the Local Network.
Specific to the HeNB subsystem, the applicability of SIPTO at the Local Network does not depend on CSG membership and the feature can be applied to any UE, as long as the UE is allowed to access the cell.
For this release of the specification, no interface between the L-GW and the PCRF is specified and there is no support for dedicated bearers on the PDN connection used for SIPTO at the Local Network. The Local GW (L-GW) shall reject any UE requested bearer resource modification.
For this release of the specification, SIPTO at the Local Network is intended for offloading Internet traffic only, thus the L-GW does not provide APN specific connectivity. Therefore if the subscription data in the HSS indicate that offload at the Local Network is allowed, this implies that the related APN is typically used for providing Internet connectivity.
If the MME detects a change in SIPTO permissions in the subscription data for a given subscriber for a given APN and the subscriber has already established a SIPTO at the local network PDN connection to that APN, the MME shall release the SIPTO at the Local Network PDN connection for that APN with "reactivation requested" cause as specified in clause 5.10.3.
Up

4.3.15a.2  SIPTO at the Local Network with stand-alone GW (with S-GW and L-GW collocated) functionp. 62

SIPTO at the Local Network is achieved using a stand-alone GW (with S-GW and L-GW collocated) residing in the Local Network.
A (H)eNB supporting SIPTO at the Local Network with the stand-alone GW includes the Local Home Network ID to the MME in every INITIAL UE MESSAGE, every UPLINK NAS TRANSPORT control message, HANDOVER NOTIFY and PATH SWITCH REQUEST messages.
If a SIPTO PDN connection is initiated as an additional subsequent PDN connection, the MME should check if the S-GW is optimal for the user's current location. If it is not, and if the network supports S-GW relocation without being triggered by a mobility event, the MME may decide to perform an MME triggered Serving-GW relocation according to clause 5.10.4, when possible (e.g. no other restrictions apply).
For SIPTO at the Local Network with a stand-alone GW, the location of the Serving-GW may be determined based on the operator policy and user's profile regarding support of SIPTO at Local Network so that:
  • At attachment to the (H)eNB, a local S-GW can always be selected independent of whether a SIPTO at the Local Network PDN connection is established or not. If mobility is performed to the macro network without having a SIPTO connection, a S-GW relocation can be performed as specified via existing mobility procedures with S-GW relocation.
  • At attachment to a (H)eNB, a macro S-GW may be allocated for PDN connection in the operator's network. If a new PDN connection is requested by the UE that requires that a local S-GW is selected to provide for SIPTO at the Local Network, S-GW relocation from the macro S-GW to the local S-GW shall be performed as specified in clause 5.10.4.
As IP data session continuity for SIPTO at the Local Network PDN connection is not supported in this release of the specification, subsequent to handover completion the (target) MME should disconnect the SIPTO at the Local Network PDN connection with "reactivation requested" cause as specified in clause 5.10.3, unless the Local Home Network ID is not changed. The IP data session should be maintained if the Local Home Network ID is not changed. If the UE has no other PDN connection and the Local Home Network ID is changed, the (target) MME initiates "explicit detach with reattach required" procedure according to clause 5.3.8.3.
Upon completion of Tracking Area Update procedure, the (new) MME shall trigger the re-establishment of the SIPTO at the Local Network PDN connection when it detects that the UE has moved away from the (H)eNB and to a (H)eNB with different Local Home Network ID, as specified in clause 5.3.3 and clause 5.3.4.
Up

4.3.15a.3  SIPTO at the Local Network with L-GW function collocated with the (H)eNBp. 63

SIPTO at the Local Network is achieved using a Local GW (L-GW) function collocated with the (H)eNB and using the same procedures as described in clause 4.3.15, with the following additions:
  • The (H)eNB supporting the SIPTO at the Local Network function includes the Local GW address to the MME in every INITIAL UE MESSAGE and every UPLINK NAS TRANSPORT control message specified in TS 36.413.
  • The PDN-GW selection function uses the L-GW address proposed by (H)eNB in the S1-AP message, instead of DNS interrogation.
  • Specific to the HeNB subsystem, the Local GW information for SIPTO at the Local Network is signalled on S1 separately from the Local GW information for LIPA. The L-GW shall be able to discriminate between PDN connection for SIPTO at the Local Network and for LIPA.
The direct user plane path between the (H)eNB and the collocated L-GW is enabled with a SIPTO Correlation ID parameter that is associated with the default EPS bearer on the PDN connection used for SIPTO at the Local Network. Upon establishment of the default EPS bearer the MME sets the SIPTO Correlation ID equal to the PDN-GW TEID (GTP-based S5) or the PDN-GW GRE key (PMIP-based S5). The SIPTO Correlation ID is then signalled by the MME to the (H)eNB as part of E-RAB establishment and is stored in the E-RAB context in the (H)eNB. The SIPTO Correlation ID is used in the (H)eNB for matching the radio bearers with the direct user plane path connections from the collocated L-GW for SIPTO at local network PDN connection.
As IP data session continuity for the SIPTO at the Local Network PDN connection is not supported in this release of the specification, the SIPTO at the Local Network PDN connection shall be re-established when the UE moves away from (H)eNB. During the handover procedure, when the source (H)eNB releases its resources related to the UE, the (H)eNB shall request using intra-node signalling the collocated L-GW to re-establish the SIPTO at the Local Network PDN connection. The L-GW starts a timer. When the timer expires, the L-GW shall initiate the release of the SIPTO at the Local Network PDN connection using the PDN-GW initiated bearer deactivation procedure according to clause 5.4.4.1 with the "reactivation requested" cause value.
Up

Up   Top   ToC