Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  18.4.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…

 

5.4.4  Bearer deactivationp. 255

5.4.4.1  PDN-GW initiated bearer deactivationp. 255

The bearer deactivation procedure for a GTP based S5/S8 is depicted in Figure 5.4.4.1-1. This procedure can be used to deactivate a dedicated bearer or deactivate all bearers belonging to a PDN address. If the default bearer belonging to a PDN connection is deactivated, the PDN-GW deactivates all bearers belonging to the PDN connection.
When the last bearer belonging to the last PDN connection of a given APN is released, the PGW may forward to the MME the APN Rate Control Status for storing it in the MM context according to clause 4.7.7.3.
Reproduction of 3GPP TS 23.401, Fig. 5.4.4.1-1: PDN-GW Initiated Bearer Deactivation
Up
Step 1.
If dynamic PCC is not deployed, the PDN-GW is triggered to initiate the Bearer Deactivation procedure due either a QoS policy or on request from the MME (as outlined in clause 5.4.4.2) or on intra-node signalling request from the HeNB to release the LIPA PDN Connection. Optionally, the PCRF sends QoS policy to the PDN-GW. This corresponds to the initial steps of the PCRF-initiated IP-CAN Session Modification procedure or the response to the PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203, up to the point that the PDN-GW requests IP-CAN Bearer Signalling. The PCC decision provision message may indicate that User Location Information and/or UE Time Zone Information is to be provided to the PCRF as defined in TS 23.203. If dynamic PCC is not deployed, the PDN-GW may apply local QoS policy. The PDN-GW initiated Bearer deactivation is also performed when handovers occur from 3GPP to non-3GPP, in which case, the default bearer and all the dedicated bearers associated with the PDN address are released, but the PDN address is kept in the PDN-GW.
For an emergency PDN connection the PDN-GW initiates the deactivation of all bearers of that emergency PDN connection when the PDN connection is inactive (i.e. not transferring any packets) for a configured period of time or when triggered by dynamic PCC.
For an PDN connection established towards the APN dedicated for Restricted Local Operator Services, the PDN-GW initiates the deactivation of all bearers of the PDN connection per local operator policy e.g. when the duration of such PDN connection reaches a pre-configured period of time.
Step 2.
The PDN-GW sends a Delete Bearer Request (PTI, EPS Bearer Identity, Causes and, optionally, APN Rate Control Status according to clause 4.7.7.3) message to the Serving-GW. The Procedure Transaction Id (PTI) parameter in this step and in the following steps is only used when the procedure was initiated by a UE Requested Bearer Resource Modification Procedure - see clause 5.4.5. This message can include an indication that all bearers belonging to that PDN connection shall be released. The PDN-GW includes 'Cause' IE in the Delete Bearer Request message and sets the IE to 'RAT changed from 3GPP to Non-3GPP' if the Delete Bearer Request message is caused by a handover from 3GPP to non-3GPP.
Step 3a.
The Serving-GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause and, optionally, APN Rate Control Status) message to the MME. This message can include an indication that all bearers belonging to that PDN connection shall be released.
Step 3b.
If ISR is activated, the Serving-GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause) message to the SGSN. This message can include an indication that all bearers belonging to that PDN connection shall be released, and the SGSN releases all bearer resources of the PDN connection.
If ISR is activated, upon receiving Delete Bearer Request from SGW for the last PDN connection for a given UE, MME shall locally de-activate ISR.
If received, the MME stores the APN Rate Control Status in the MM context.
Steps 4 to 7 are not performed if at least one of the following three conditions is fulfilled:
    (i) The UE is in ECM-IDLE and the last PDN connection of the UE is not being deleted and the Delete Bearer Request received from the Serving-GW does not contain the cause "reactivation requested", which has been sent from the PDN-GW;
    (ii) UE is in ECM-IDLE and the last PDN connection is deleted due to ISR deactivation;
    (iii) UE is in ECM-IDLE and the last PDN connection is deleted in 3GPP due to handover to non-3GPP access.
When steps 4 to 7 are not performed, the EPS bearer state is synchronized between the UE and the network at the next ECM-IDLE to ECM-CONNECTED transition (e.g. Service Request or TAU procedure).
Step 4a.
If the last PDN connection of a UE that does not support "Attach without PDN connectivity" is being released and the bearer deletion is neither due to ISR deactivation nor due to handover to non-3GPP accesses, the MME explicitly detaches the UE by sending a Detach Request message to the UE. If the UE is in ECM-IDLE state the MME initiates paging via Network Triggered Service Request procedure in clause 5.3.4.3 from step 3a onwards in order to inform UE of the request. Steps 4b to 7b are skipped in this case, and the procedure continues from step 7c.
Step 4b.
If the UE is in ECM-IDLE state and the reason for releasing PDN connection is "reactivation requested", the MME initiates paging via Network Triggered Service Request procedure in clause 5.3.4.3 from step 3a onwards in order to inform UE of the request and step 4c is performed after completion of the paging.
Step 4c.
If the release of the bearer in E-UTRAN has already been signalled to the MME, steps 4c to 7 are omitted. Otherwise, if this is not the last PDN connection for the UE which is being released, the MME sends the S1-AP Deactivate Bearer Request (EPS Bearer Identity) message to the eNodeB. The MME builds a NAS Deactivate EPS Bearer Context Request message including the EPS Bearer Identity and a WLAN offloadability indication, and includes it in the S1-AP Deactivate Bearer Request message. When the bearer deactivation procedure was originally triggered by a UE request, the NAS Deactivate EPS Bearer Context Request message includes the PTI.
The MME may include an indication whether the traffic of this PDN Connection is allowed to be offloaded to WLAN as described in clause 4.3.23 if the PDN connection is not released.
Step 5.
The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to release and the NAS Deactivate EPS Bearer Context Request message to the UE.
Step 6a.
The UE RRC releases the radio bearers indicated in the RRC message in step 5, and indicates the radio bearer status to the UE NAS. Then the UE NAS removes the UL TFTs and EPS Bearer Identity according to the radio bearer status indication from the UE RRC. The UE responds to the RRC Connection Reconfiguration Complete message to the eNodeB.
Step 6b.
The eNodeB acknowledges the bearer deactivation to the MME with a Deactivate Bearer Response (EPS Bearer Identity, ECGI, TAI, PSCell ID, Secondary RAT usage data) message. If the PLMN has configured secondary RAT usage reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is included.
The PSCell ID is included if Dual Connectivity is active for the UE in the RAN.
The MME shall be prepared to receive this message either before or after the Session Management Response message sent in step 7b, and before or after, any Detach Request message sent in step 7c.
Step 7a.
The UE NAS layer builds a Deactivate EPS Bearer Context Accept message including EPS Bearer Identity. The UE then sends a Direct Transfer (Deactivate EPS Bearer Context Accept) message to the eNodeB.
Step 7b.
The eNodeB sends an Uplink NAS Transport (Deactivate EPS Bearer Context Accept) message to the MME.
Step 7c.
If the UE receives the Detach Request message from the MME in the step 4a, the UE sends a Detach Accept message to the MME any time after step 4a. The eNodeB forwards this NAS message to the MME along with the TAI+ECGI of the cell which the UE is using.
Step 7a,b,c.
If Dual Connectivity is active for the UE, the PSCell ID shall be included in the Uplink NAS Transport sent by the eNodeB.
Step 8a.
After reception of both the Deactivate Bearer Response message in step 6b and the Deactivate EPS Bearer Context Accept message in step 7b, the MME deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the Serving-GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location Information (ECGI), RAN/NAS Release Cause, Secondary RAT usage data, PSCell ID) message. If the MME received Secondary RAT usage data in step 6b, the MME shall include it in this message. If the MME received PSCell ID in step 6b, the MME shall include it in this message. If extended idle mode DRX is enabled, then the MME acknowledges the bearer deactivation to the Serving-GW and at the same time the MME initiates the deactivation towards the UE. If the S1 connection had already been released by the eNodeB due to radio link failure and the MME receives a Delete Bearer Request while it is still deferring the sending of the S1 release (see clause 5.3.5), the MME shall include in the Delete Bearer Response the RAN/NAS Cause received in the S1 Release due to radio link failure procedure.
Step 8b.
The SGSN deletes PDP Context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the Serving-GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location Information (CGI/SAI)) message. If extended idle mode DRX is enabled, then the SGSN acknowledges the bearer deactivation to the Serving-GW and at the same time the SGSN initiates the deactivation towards the UE.
Step 9.
If ISR is activated, after receiving the two Delete Bearer Response messages from the MME and the SGSN, or if ISR is not activated, after receiving the Delete Bearer Response messages from the MME, the Serving-GW deletes the bearer context related to the deactivated EPS bearer acknowledges the bearer deactivation to the PDN-GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location Information (ECGI or CGI/SAI), Secondary RAT usage data) message. If the MME and/or SGSN sent UE's Location Information and/or UE Time Zone in step 8a and/or step 8b, the Serving-GW includes the User Location Information and/or UE Time Zone Information with the least age in this message. The Serving-GW includes the Secondary RAT usage data if it was received in step 8a and if PGW secondary RAT usage data reporting is active.
Step 10.
The PDN-GW deletes the bearer context related to the deactivated EPS bearer. If the dedicated bearer deactivation procedure was triggered by receiving a PCC decision message from the PCRF, the PDN-GW indicates to the PCRF whether the requested PCC decision was successfully enforced by completing the PCRF-initiated IP-CAN Session Modification procedure or the PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203, proceeding after the completion of IP-CAN bearer signalling. If requested by the PCRF the PDN-GW indicates User Location Information and/or UE Time Zone Information to the PCRF as defined in TS 23.203. If available, the PDN-GW shall send RAN/NAS Release Cause to the PCRF as defined in TS 23.203.
Step 11.
If the UE is being explicitly detached, the MME releases the S1-MME signalling connection for the UE by sending an S1 Release Command (Cause) message to the eNodeB. The details of this step are covered in the "S1 Release Procedure", as described in clause 5.3.5 by step 4 to step 6.
If all the bearers belonging to a UE that does not support "Attach without PDN connectivity" are released, the MME shall change the MM state of the UE to EMM-DEREGISTERED and the MME sends the S1 Release Command to the eNodeB, which initiates the release of the RRC connection for the given UE if it is not released yet, and returns an S1 Release Complete message to the MME.
If all bearers of an emergency attached or RLOS attached UE are deactivated the MME may initiate the explicit MME-Initiated Detach procedure. Regardless of the outcome of any explicit Detach procedure the MME changes the EMM state of the UE to EMM-DEREGISTERED and the MME sends the S1 Release Command to the eNodeB if it is not yet released.
If the default bearer belonging to a PDN connection is deactivated, the MME determines the Maximum APN Restriction for the remaining PDN connections and stores this new value for the Maximum APN Restriction. In addition if ISR is activated the SGSN determines the Maximum APN Restriction for the remaining bearer contexts and stores this new value for the Maximum APN Restriction.
Up

5.4.4.2  MME Initiated Dedicated Bearer Deactivationp. 259

MME initiated Dedicated Bearer Deactivation is depicted in Figure 5.4.4.2-1 below. This procedure deactivates dedicated bearers. Default bearers are not affected. To initiate the release of the full PDN connection including the default bearer, the MME uses the UE or MME requested PDN disconnection procedure defined in clause 5.10.3.
Reproduction of 3GPP TS 23.401, Fig. 5.4.4.2-1: MME initiated Dedicated Bearer Deactivation
Up
Step 0.
Radio bearers for the UE in the ECM-CONNECTED state may be released due to local reasons (e.g. abnormal resource limitation or radio conditions do not allow the eNodeB to maintain all the allocated GBR bearers: it is not expected that non-GBR bearers are released by the eNodeB unless caused by error situations). The UE deletes the bearer contexts related to the released radio bearers.
Step 1.
When the eNodeB releases radio bearers in step 0, it sends an indication of bearer release to the MME. This indication may be e.g. the Bearer Release Request (EPS Bearer Identity) message to the MME, or alternatively Initial Context Setup Complete, Handover Request Ack and UE Context Response, Path Switch Request may also indicate the release of a bearer.
The eNodeB includes the ECGI and TAI in the indication sent to the MME. The eNodeB also includes the PSCell ID if Dual Connectivity is active for the UE in the RAN.
If the PLMN has configured secondary RAT reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is included.
Step 2.
The MME sends the Delete Bearer Command (EPS Bearer Identity, User Location Information, UE Time Zone, RAN/NAS Release Cause if available, Secondary RAT usage data, PSCell ID) message per PDN connection to the Serving-GW to deactivate the selected dedicated bearer. RAN/NAS Release Cause indicates the RAN release cause and/or the NAS release cause. RAN/NAS Release Cause is only sent by the MME to the PDN-GW if this is permitted according to MME operator's policy. If the MME received Secondary RAT usage data in step 1, the MME shall include it in this message. If MME received PSCell ID in step 1, the MME shall include it in this message.
Step 3.
The Serving-GW sends the Delete Bearer Command (EPS Bearer Identity, User Location Information, UE Time Zone, RAN/NAS Release Cause, Secondary RAT usage data) message per PDN connection to the PDN-GW. The Serving-GW includes the Secondary RAT usage data it in this message if it was received in the previous message and if PGW secondary RAT usage data reporting is active.
Step 4.
If PCC infrastructure is deployed, the PDN-GW informs the PCRF about the loss of resources by means of a PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203 and provides the User Location Information, UE Time Zone and RAN/NAS Release cause (if available) received in the Delete Bearer Command from the S-GW if requested by the PCRF as defined in TS 23.203. The PCRF sends an updated PCC decision to the PDN-GW.
Step 5.
The PDN-GW sends a Delete Bearer Request (EPS Bearer Identity) message to the Serving-GW.
Step 6.
The Serving-GW sends the Delete Bearer Request (EPS Bearer Identity) message to the MME.
Step 7.
Steps between steps 4 and 7, as described in clause 5.4.4.1, are invoked. This is omitted if the bearer deactivation was triggered by the eNodeB in step 0 and step 1.
This is also omitted if the MME initiated bearer release due to failed bearer set up during handover, the UE and the MME deactivate the failed contexts locally without peer-to peer ESM signalling.
Step 8.
The MME deletes the bearer contexts related to the deactivated EPS bearer and acknowledges the bearer deactivation to the Serving-GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location Information (ECGI), Secondary RAT usage data) message. The MME includes the Secondary RAT usage data if it received this in step 7 from the eNodeB.
Step 9.
The Serving-GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the PDN-GW by sending a Delete Bearer Response (EPS Bearer Identity, Secondary RAT usage data) message. The Serving-GW includes the Secondary RAT usage data if it was received in step 8 and if PGW secondary RAT usage data reporting is active.
Up

5.4.5  UE requested bearer resource modificationp. 260

The UE requested bearer resource modification procedure for an E-UTRAN is depicted in Figure 5.4.5-1. The procedure allows the UE to request for a modification of bearer resources (e.g. allocation or release of resources) for one traffic flow aggregate with a specific QoS demand. Alternatively, the procedure allows the UE to request for the modification of the packet filters used for an active traffic flow aggregate, without changing QoS. If accepted by the network, the request invokes either the Dedicated Bearer Activation Procedure, the Bearer Modification Procedure or a dedicated bearer is deactivated using the PDN-GW Initiated Bearer Deactivation Procedure. The procedure is used by the UE when the UE already has a PDN connection with the PDN-GW. A UE can send a subsequent Request Bearer Resource Modification Message before the previous procedure is completed. The UE requested bearer resource modification procedure is used to indicate the change of 3GPP PS Data Off UE Status to the PDN-GW via the PCO, only if the UE has been previously informed that the PDN-GW supports the 3GPP PS Data Off feature. When a UE supports only Control Plane CIoT EPS Optimisation as defined in clause 5.3.4B the UE need not support the UE requested bearer resource modification procedure in order to modify the traffic flow aggregate, as the UE does not support any DRBs. The UE may need to support UE requested bearer resource modification procedure for other purposes, e.g. header compression negotiation, see TS 24.301.
The UE supporting 15 EPS bearers as defined in clause 4.12 shall not initiate a UE requested bearer resource modification procedure that would trigger the establishment of a new EPS bearer, if it has already 8 EPS bearers established and the UE has not received an Indication for support of 15 EPS bearers per UE or has received cause #65 "maximum number of EPS bearers reached".
In this procedure the UE signals a Traffic Aggregate Description (TAD) which is a partial TFT, together with a Procedure Transaction Identifier (PTI), and an EPS Bearer Identity (when the TAD operation is modify, delete or add to an existing packet filter). When the TAD operation is modify or delete, the packet filter identifiers of the TAD are the same as the TFT packet filter identifiers of the referenced EPS Bearer (as the concatenation of the TFT packet filter identifier and the EPS Bearer identifier represents a unique packet filter identifier within the PDN connection), for which resources are being modified. The TAD is released by the UE after it has received a TFT related to the current PTI from the network.
Reproduction of 3GPP TS 23.401, Fig. 5.4.5-1: UE requested bearer resource modification
Up
If the bearer resource modification procedure is initiated for re-negotiation of header compression configuration for Control Plane CIoT EPS Optimisation, the MME shall not send Bearer Resource Command message to the Serving-GW. In this case, the Bearer Modification Procedures (according to clause 5.4.3) is invoked and only the steps from 4 to 7 are performed.
Step 1.
The UE sends a Request Bearer Resource Modification (LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options) message to the MME. If the UE was in ECM-IDLE mode, this NAS message is preceded by the Service Request procedure.
The TAD indicates one requested operation (add, modify, or delete packet filters). If traffic flows are added, the TAD includes the packet filter(s) (consisting of the packet filter information including packet filter precedence, but without a packet filter identifier) to be added. The UE also sends the QCI requested and GBR, if applicable, for the added traffic flows. If the UE wants to link the new packet filter(s) to an existing packet filter to enable the usage of existing bearer resources for the new packet filter(s), the UE shall provide an existing packet filter identifier together with the new packet filter(s). If the new packet filter(s) are not linked to an existing packet filter the UE shall provide at least one UL packet filter in the TAD. If a downlink only traffic flow(s) is to be added the UE shall provide an UL packet filter that effectively disallows any useful packet flows (see clause 15.3.3.4 of TS 23.060 for an example of such packet filter).
If the UE wants to change the GBR in addition, the UE includes the GBR requirement of the EPS Bearer. The TAD is released when the procedure is completed.
When only requesting for a modification of GBR (i.e. decrease or increase), the TAD shall include the existing packet filter identifier(s) for which the GBR change request applies to. The UE includes the GBR requirement of the EPS Bearer. The TAD is released when the procedure is completed.
When requesting for a modification of packet filter(s) (e.g. change of port number), the TAD shall include packet filter identifier(s) for which the change request applies to together with the changed packet filter information.
If the UE requests for deletion of traffic flows, the TAD includes the packet filter identifier(s) to be deleted. If the packet filters to be deleted were mapped to a GBR Bearer, the UE includes the new GBR requirement of the EPS Bearer.
The UE sends the Linked Bearer Id (LBI) only when the requested operation is add, to indicate to which PDN connection the additional bearer resource is linked to. The EPS Bearer Identity is only sent when the requested operation is modify or delete. The Procedure Transaction Id is dynamically allocated by the UE for this procedure. The UE should ensure as far as possible that previously used PTI values are not immediately reused. The PTI is released when the procedure is completed. Protocol Configuration Options may be used to transfer application level parameters between the UE and the PDN-GW (see TS 23.228), and are sent transparently through the MME and the Serving-GW.
If the PDN-GW indicated support for the 3GPP PS data off feature during PDN connection setup, the UE shall include in the PCO the 3GPP PS Data Off Support Indication, which indicates whether the user has activated or deactivated 3GPP PS Data Off.
Step 2.
The MME sends the Bearer Resource Command (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options) message to the selected Serving-GW. The MME validates the request using the Linked Bearer Id. The same Serving-GW address is used by the MME as for the EPS Bearer identified by the Linked Bearer Id received in the Request Bearer Resource Modification message.
Step 3.
The Serving-GW sends the Bearer Resource Command (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options) message to the PDN-GW. The Serving-GW sends the message to the same PDN-GW as for the EPS Bearer identified by the Linked Bearer Id.
Step 4.
The PDN-GW may either apply a locally configured QoS policy, or it may interact with the PCRF to trigger the appropriate PCC decision, which may take into account subscription information. This corresponds to the beginning of a PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203, up to the point that the PDN-GW requests IP-CAN Bearer Signalling. When interacting with PCRF, the PDN-GW provides to the PCRF the content of the TAD and, if applicable, the GBR change (increase or decrease) associated with the packet filter information contained in the TAD. The GBR change is either calculated from the current Bearer QoS and the requested Bearer QoS from the UE, or set to the requested GBR if the TAD indicates an add operation and no EPS Bearer Identity was received. If the TAD indicates an add operation, the requested QCI is also provided to the PCRF unless an existing packet filter identifier is provided together with the new packet filter.
The PCC decision provision message may indicate that User Location Information and/or UE Time Zone information is to be provided to the PCRF as defined in TS 23.203.
If the TAD operation is modify, delete, a request for changing the GBR, or add with a link to existing packet filter(s), then the PDN-GW provides to the PCRF the SDF filter identifier(s), previously assigned on Gx, that correspond to the received packet filter identifiers of the EPS bearer indicated by the received EPS bearer identity.
If the PDN-GW detects that the 3GPP PS Data Off UE Status has changed, the PDN-GW shall indicate this event to the charging system for offline and online charging.
If the 3GPP PS Data Off UE Status indicates that 3GPP PS Data Off is activated for the UE, the PDN-GW shall enforce the PCC rules for downlink traffic to be applied when 3GPP PS Data Off is activated, as described in TS 23.203.
Step 5.
If the request is accepted, either the Dedicated Bearer Activation Procedure (according to clause 5.4.1), the PDN-GW Initiated Bearer Deactivation Procedure (according to clause 5.4.4.1) or one of the Bearer Modification Procedures (according to clause 5.4.2.1 or 5.4.3) is invoked. The PTI allocated by the UE is used as a parameter in the invoked Dedicated Bearer Activation Procedure, the PDN-GW Initiated Bearer Deactivation Procedure or the Bearer Modification Procedure to correlate it to the UE Requested Bearer Resource Modification Procedure. This provides the UE with the necessary linkage to what EPS Bearer to be used for the new traffic flow aggregate. The PDN-GW shall not modify the QoS parameters requested by the UE.
The PDN-GW inserts, modifies or removes packet filter(s) corresponding to the TAD into the TFT for the EPS bearer. If PCC is in use, the PDN-GW uses the service data flow filters as specified in the resulting PCC rule(s). The PDN-GW validates the state of the TFT settings of the PDN connection as defined in clause 15.3.0 of TS 23.060. If after the execution of all TAD operations the TFT of the dedicated EPS bearer contains only packet filters for the downlink direction, the PDN-GW shall add a packet filter which effectively disallows any useful packet flows in uplink direction (see clause 15.3.3.4 of TS 23.060 for an example of such a packet filter) to the TFT.
When a new packet filter is inserted into a TFT, the PDN-GW assigns a new packet filter identifier which is unique within the TFT. The PDN-GW maintains the relation between the SDF filter identifier in the PCC rule received from the PCRF and the packet filter identifier of the TFT of this EPS bearer. If all of the packet filter(s) for a dedicated EPS bearer have been removed from the TFT, the PDN-GW performs the PDN-GW Initiated Bearer Deactivation Procedure.
If the requested QoS is not granted (i.e. the requested QoS cannot be accepted or resources could not be allocated), or the resulting TFT settings of the PDN connection does not pass the validation, then the PDN-GW sends a Bearer Resource Failure Indication (with a cause indicating the reason why the request failed or was rejected) message, which shall be delivered to the UE.
Step 6.
If the PDN-GW interacted with the PCRF in step 4, the PDN-GW indicates to the PCRF whether the PCC decision could be enforced or not. This corresponds to the completion of the PCEF-initiated IP-CAN session modification procedure as defined in TS 23.203, proceeding after the completion of IP-CAN bearer signalling. If requested by the PCRF the PDN-GW indicates User Location Information and/or UE Time Zone Information to the PCRF as defined in TS 23.203.
Up

5.4.6Void

5.4.7  E-UTRAN initiated E-RAB modification procedure |R12|p. 263

When SCG bearer option is applied to support dual connectivity operation, this procedure is used to transfer bearer contexts to and from Secondary eNodeB (see TS 36.300) or Secondary gNodeB (see TS 37.340). During this procedure, both the MME and Serving-GW are never relocated. The presence of IP connectivity between the Serving-GW and the Master eNodeB (see TS 36.300 or TS 37.340 for Master eNodeB definition), as well as between the Serving-GW and the Secondary RAN node is assumed.
Reproduction of 3GPP TS 23.401, Fig. 5.4.7-1: E-UTRAN initiated E-RAB modification procedure
Up
Step 1.
The Master eNodeB sends a E-RAB Modification Indication message (eNodeB address(es) and TEIDs for downlink user plane for all the EPS bearers, CSG Membership Information, Secondary RAT usage data) to the MME. The Master eNodeB indicates for each bearer whether it is modified or not. If the PLMN has configured secondary RAT usage reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is included. The eNodeB shall include the ECGI and, if Dual Connectivity is activated for the UE, the PSCell ID, in the E-RAB Modification Indication message.
If the Secondary eNodeB is a hybrid access eNodeB, the Master eNodeB includes the CSG Membership Information for the SCG bearer(s) in the E-RAB Modification Indication message. The MME determines the CSG membership based on the CSG Membership Information as specified in TS 36.300, but does not update the User CSG Information in the Core Network. A failure of the CSG Membership Information verification does not impact the E-UTRAN initiated E-RAB modification procedure.
Step 2.
The MME sends a Modify Bearer Request (eNodeB address(es) and TEIDs for downlink user plane for all the EPS bearers, ISR Activated, User Location Information, PSCell ID, Secondary RAT usage data and indication to send it to PDN-GW) message per PDN connection to the Serving-GW, only for the affected PDN connections. If ISR was activated before this procedure, MME should maintain ISR. The UE is informed about the ISR status in the Tracking Area Update procedure. If the Serving-GW supports Modify Access Bearers Request procedure and if there is no need for the SGW to send the signalling to the PDN-GW, the MME may send a Modify Access Bearers Request (eNodeB address(es) and TEIDs for downlink user plane for all the EPS bearers, ISR Activated) to the Serving-GW to optimise the signalling. If the MME received Secondary RAT usage data in step 1, the MME shall include it in this message. If the MME received PSCell ID in step 1, the MME shall include it in this message.
If Secondary RAT usage data was included and if PGW secondary RAT usage data reporting is active, the Serving-GW shall send Modify Bearer Request (Secondary RAT usage data) message to the PDN-GW for each PDN connection. The PDN-GW responds with Modify Bearer Response message to the Serving-GW.
Step 3.
The Serving-GW returns a Modify Bearer Response (Serving-GW address and TEID for uplink traffic) message to the MME as a response to a Modify Bearer Request message, or a Modify Access Bearers Response (Serving-GW address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message.
The Serving-GW starts sending downlink packets to the eNodeB using the newly received address and TEID.
Step 4.
In order to assist the reordering function in the Master eNodeB and/or Secondary RAN nodes, for the bearers that are switched between Master eNodeB and Secondary RAN nodes, the Serving-GW shall send one or more "end marker" packets on the old path immediately after switching the path as defined in clause 10.1.2.2 of TS 36.300.
Step 5.
The MME confirms the E-RAB modification with the E-RAB Modification Confirm (CSG Membership Status) message. The MME indicates for each bearer whether it was successfully modified, kept unmodified or already released by the EPC as defined in TS 36.413. For the EPS bearers that have not been switched successfully in the core network, it is the MME decision whether to maintain or release the corresponding EPS bearers. The eNodeB uses the CSG Membership Status to decide on further actions, as specified in TS 36.300.
Up

5.4.8  E-UTRAN initiated UE Context Modification procedure |R13|p. 265

When split bearer option is applied to support dual connectivity operation, this procedure is used is by the eNodeB to request the modifications on the established UE Context. In the current version of the specification, this procedure is only used for membership verification, as described in TS 36.300.
Reproduction of 3GPP TS 23.401, Fig. 5.4.8-1: E-UTRAN initiated UE context modification procedure
Up
Step 1.
The addition of an hybrid HeNB as the SeNodeB is triggered, providing the CSG-ID and the CSG Membership Information to the MeNodeB.
Step 2.
The Master eNodeB sends UE Context Modification Indication message to the MME, which includes the CSG Membership Information of the SeNodeB.
Step 3.
The MME verifies the CSG membership based on the provided CSG Membership Information as specified in TS 36.300, but does not update the User CSG Information in the Core Network. A failure of the CSG Membership Information verification does not impact the E-UTRAN UE Context Modification procedure.
Step 4.
The MME confirms the UE Context Modification Indication with the UE Context Modification Confirm (CSG Membership Status) message. If CSG Membership Information was not present in the UE Context Modification Indication message, the MME can not perform CSG Membership Information verification and does not provide CSG Membership Status in the UE Context Modification Confirm message.
Step 5.
If the CSG Membership Status returned by the MME is different from what was reported by the UE, the eNodeB may decide on further actions.
Up

Up   Top   ToC