Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.060  Word version:  18.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…   B…

 

9.2.2  Activation Proceduresp. 231

9.2.2.1  PDP Context Activation Procedurep. 231

The PDP Context Activation procedure is illustrated in Figure 63 and Figure 64.
Reproduction of 3GPP TS 23.060, Fig. 63: PDP Context Activation Procedure for A/Gb mode
Up
Reproduction of 3GPP TS 23.060, Fig. 64: PDP Context Activation Procedure for Iu mode
Up
If Emergency Service is required and an emergency PDP Context is not already active the MS shall request a PDP Context for emergency services via emergency indication in the Activate PDP Context Request message when initiating the PDP Context Request Procedure. An emergency attached MS shall initiate the PDP Context Request procedure directly after the Attach procedure is completed. Any additional emergency PDP Context Activation by an MS shall be rejected by the SGSN if there is already an emergency PDP context activated.
Step 1.
The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, Protocol Configuration Options, Request Type) message to the SGSN. In this version of the protocol, the MS shall leave PDP Address empty. The MS may use Access Point Name to select a reference point to a certain packet data network and/or to select a service. Access Point Name is a logical name referring to the packet data network and/or to a service that the subscriber wishes to connect to. QoS Requested indicates the desired QoS profile. For an E-UTRAN capable UE, the QoS requested shall indicate subscribed, interactive or background traffic class in this message. If the UE is not E-UTRAN capable, in this release the QoS requested should indicate subscribed, interactive or background traffic class in this message. If the request is as a result of a Network-Requested PDP context activation procedure, the MS shall not set the PDP Type to IPv4v6, but to the value received in the Request PDP Context Activation message: see clause 9.2.2.2.1.
Protocol Configuration Options is used to transfer the NRSU, ETFTU, Address Allocation Preference and 3GPP PS Data Off status to the GGSN and may be used to transfer the BCM as well as optional PDP parameters and/or request to the GGSN (see TS 29.060 and TS 24.229). Protocol Configuration Options is sent transparently through the SGSN. NRSU indicates MS support of the network requested bearer control. ETFTU indicates MS support of the extended TFT filter format. The Protocol Configuration Options may include the Address Allocation Preference indicating that the MS prefers to obtain an IPv4 address only after the PDP Context Accept by means of DHCPv4 as defined in RFC 2131. 3GPP PS Data Off status indicates whether 3GPP PS Data Off is activated or deactivated in the MS.
If the SGSN has stored a value for the Maximum APN restriction and the value indicates the most restrictive type, then the SGSN shall reject any Activate PDP Context requests to a different APN, using the PDP Context Activation Reject message including an appropriate error cause.
If the SGSN decides to establish Direct Tunnel between RNC and GGSN, the SGSN provides to the RNC the Direct Tunnel specific parameters in step 5 "RAB Assignment Procedure" and shall initiate PDP Context Update procedure in step 8 to update IP Address and TEID for Downlink data.
Request Type indicates "Handover" when the MS has already an activated PDN-GW/HA due to mobility with non-3GPP accesses, and is only interpreted by SGSNs using S4.
The PDP context activation for emergency services shall be exempted from the Maximum APN restriction control. 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 message is being sent via a HNB which has a collocated L-GW, it includes the L-GW address in the Direct Transfer message to the SGSN.
Step 2.
In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function".
Step 3.
In A/Gb mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, OMC Identity) message to the BSS. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC.
Step 4.
The SGSN validates the Activate PDP Context Request using PDP Type (optional), PDP Address (optional), and Access Point Name (optional) provided by the MS and the PDP context subscription records. The SGSN shall use the CSG Subscription Data to authorize the LIPA connection to the APN provided by the MS. A PDP Address may only be sent by an MS implemented according to an earlier protocol release. The validation criteria, the APN selection criteria, and the mapping from APN to a GGSN are described in Annex A.
For an emergency PDP Context Activation the SGSN applies the parameters from SGSN Emergency Configuration Data for the emergency bearer establishment performed in this step and any potentially stored IMSI related subscription data are ignored by the SGSN.
If no GGSN address can be derived or if the SGSN has determined that the Activate PDP Context Request is not valid according to the rules described in Annex A, the SGSN rejects the PDP context activation request.
If a GGSN address can be derived, the SGSN creates a TEID for the requested PDP context. If the MS requests a dynamic address, the SGSN lets a GGSN allocate the dynamic address. The SGSN may restrict the requested QoS attributes given its capabilities and the current load, and it shall restrict the requested QoS attributes according to the subscribed QoS profile. If the UE requests the subscribed MBR and the subscribed MBR is larger than 16 Mbps, the SGSN should restrict the requested MBR to 16 Mbps or lower, if the "Higher bitrates than 16 Mbps flag" in the MM Context is set to "not allowed".
If the subscription context does not indicate that the APN is for a connection to an SCEF the SGSN sends a Create PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS Negotiated, Negotiated Evolved ARP, TEID, NSAPI, MSISDN, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Protocol Configuration Options, serving network identity, CN Operator Selection Entity, Maximum APN Restriction IMEISV, CGI/SAI, User CSG Information, RAT type, S-CDR CAMEL information, MS Info Change Reporting support indication, NRSN, Dual Address Bearer Flag, APN-AMBR) message to the affected GGSN. MSISDN is included if available in the stored UE context otherwise IMSI is included. The Negotiated Evolved ARP IE shall contain the Subscribed Evolved ARP value. If the SGSN did not receive a Subscribed Evolved ARP value in subscription data from the HLR the SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated according to Annex E in TS 23.401. The inclusion of the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. The SGSN shall send the serving network identity serving network identity and the CN Operator Selection Entity to the GGSN. The CN Operator Selection Entity indicates whether the Serving Network has been selected by the UE or by the network. Access Point Name shall be the APN Network Identifier of the APN selected according to the procedure described in Annex A. PDP Address shall be empty if a dynamic address is requested. The GGSN may use Access Point Name to find a packet data network and optionally to activate a service for this APN. Selection Mode indicates whether a subscribed APN was selected, or whether a non-subscribed APN sent by an MS or a non-subscribed APN chosen by the SGSN was selected. Selection Mode is set according to Annex A. The GGSN may use Selection Mode when deciding whether to accept or reject the PDP context activation. For example, if an APN requires subscription, the GGSN is configured to accept only the PDP context activation that requests a subscribed APN as indicated by the SGSN with Selection Mode. Charging Characteristics indicates which kind of charging the PDP context is liable for. The charging characteristics on the subscription and individually subscribed APNs as well as the way the SGSN handles Charging Characteristics and chooses to send them or not to the GGSN is defined in TS 32.251. The SGSN shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if GGSN trace is activated. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC. The Maximum APN Restriction denotes the most stringent restriction as required by any already active PDP contexts. If there are no already active PDP contexts, this value is set to the least restrictive type (see clause 15.4). If the GGSN receives the Maximum APN Restriction, then the GGSN shall check if the Maximum APN Restriction value does not conflict with the APN Restriction value associated with this PDP context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with the SGSN sending a PDP Context Activation Reject Message to the MS including an appropriate error cause. NRSN indicates SGSN support of the network requested bearer control. The Dual Address Bearer Flag shall be set when the MS requests PDN type IPv4v6 and all SGSNs, which the MS may be handed over to, are Release 8 or above supporting dual addressing, which is determined based on node pre configuration by the operator. For PDN type "non-IP", if the APN subscription data indicate a SCEF connection needs to be used, the SGSN establishes a T6b connection as specified in TS 23.682 using the SCEF address indicated in subscription data. Steps 4 and 8 are not further executed, but the rest of the interactions with the MS apply as specified below.
For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is included and marked as unauthenticated.
The GGSN creates a new entry in its PDP context table and generates a Charging Id. The new entry allows the GGSN to route PDP PDUs between the SGSN and the packet data network, and to start charging. The way the GGSN handles Charging Characteristics that it may have received from the SGSN is defined in TS 32.251. The GGSN may restrict QoS Negotiated given its capabilities and the current load or increase the QoS Negotiated based on any external input (e.g. policy control). The GGSN then returns a Create PDP Context Response (TEID, PDP Type, PDP Address, Protocol Configuration Options, QoS Negotiated, Negotiated Evolved ARP, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, BCM, APN-AMBR, Delay Tolerant Connection) message to the SGSN. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401, Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. If the MS has requested PDP type IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing is possible in the PDN, the GGSN selects a single IP version (either IPv4 or IPv6). If the MS has requested PDP type IPv4 or IPv6, the GGSN uses the PDP type supplied by the MS in case it is supported in the PDN, otherwise an appropriate error cause will be returned. The GGSN allocates a PDP Address according to the selected PDP type. For PDP Type Non-IP the GGSN performs IPv6 address allocation only if point-to-point tunnelling using UDP/IP encapsulation is used. If no IP address is allocated, no PDP address (or a dummy address) is returned If the GGSN has selected a PDN type different from the one sent by the MS, the GGSN indicates, together with the PDP type IE, a reason cause to the MS why the PDP type has been modified as described in clause 9.2.1. PDP Address is included if the GGSN allocated a PDP address. If the GGSN has been configured by the operator to use External PDN Address Allocation for the requested APN, PDP Address shall be set to 0.0.0.0, indicating that the PDP address shall be negotiated by the MS with the external PDN after completion of the PDP Context Activation procedure. The GGSN shall relay, modify and monitor these negotiations as long as the PDP context is in ACTIVE state, and use the GGSN-Initiated PDP Context Modification procedure to transfer the currently used PDP address to the SGSN and the MS. However, the MS cannot rely on always getting a session management level update of the IP address, which it has negotiated with the external PDN. This is because the P-GW does not update the IP address within the EPS bearer modification procedure, see clause 9.2.3.2A. Protocol Configuration Options contains the BCM, ETFTN as well as optional PDP parameters that the GGSN may transfer to the MS. BCM shall also be sent as a separate IE to the SGSN. The GGSN includes a Delay Tolerant Connection indication if the GGSN supports receiving a rejection cause indicating that the MS is temporarily not reachable due to power saving and holding the mobile terminated procedures, until the GGSN receives a message indicating that the MS is available for end to end signalling. These optional PDP parameters may be requested by the MS in the Activate PDP Context Request message, or may be sent unsolicited by the GGSN. Protocol Configuration Options is sent transparently through the SGSN. The Create PDP Context messages are sent over the backbone network. The BCM is used by the SGSN to handle unexpected session management signalling.
If QoS Negotiated received from the SGSN is incompatible with the PDP context being activated, the GGSN rejects the Create PDP Context Request message. The GGSN operator configures the compatible QoS profiles.
If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the PDP Context and the SGSN shall check this received value with the stored value for the Maximum APN Restriction to ensure there are no conflicts between values. If the consequence of this check results in the PDP context being rejected, the SGSN shall initiate a PDP Context Deactivation and return an appropriate error cause. If the PDP Context is accepted, it shall determine a (new) value for the Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the received APN Restriction.
The emergency PDP context activation shall be exempted from the Maximum APN restriction control.
If the MS Info Change Reporting Action and/or the CSG Information Reporting Action are received from the GGSN for this PDP context, then the SGSN shall store this for the PDP context and the SGSN shall report to that GGSN whenever a CGI/SAI/RAI or user CSG information change occurs that meets the GGSN request, as described in clause 15.1.1a.
The GGSN derives the BCM based on NRSU, NRSN and operator policy if previously received in the Create PDP Context Request message. The derived BCM is sent to the MS indicating the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair.
The GGSN derives the ETFTN based on ETFTU and operator policy if ETFTU was previously received in the Create PDP Context Request message. The derived ETFTN is sent to the MS indicating that the extended TFT filter format can be used on all PDP Contexts within the activated PDP Address/APN pair.
The SGSN shall re-verify and may restrict the QoS Negotiated received in the response from the GGSN against the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. The SGSN shall use this updated QoS Negotiated for the subsequent steps.
The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP.
The SGSN determines the UE AMBR to be used by the RAN based on the subscribed UE-AMBR and the APN AMBR for active APNs, see clause 15.2.2.
If the 3GPP PS Data Off UE Status was present in the Create PDP Context Request PCO, the GGSN shall include the 3GPP PS Data Off Support Indication in the Create PDP Context Response PCO if it supports the 3GPP PS Data Off feature.
If the GGSN detects that the 3GPP PS Data Off UE Status is active, the GGSN shall indicate this to the charging system for offline and online charging.
Step 5.
In Iu mode, RAB setup is done by the RAB Assignment procedure, see clause "RAB Assignment Procedure".
Step 6.
In Iu mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC.
Step 7.
In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".
Step 8.
In case the QoS attributes, used as input to step 5 for Iu mode or step 7 for A/Gb mode, have been downgraded during those steps, the SGSN may inform the GGSN about the downgraded QoS attributes by sending an Update PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS attributes. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN shall accept the provided QoS attributes without negotiation. The GGSN confirms the new QoS attributes by sending an Update PDP Context Response to the SGSN. If the SGSN established Direct Tunnel in step 5 it shall send Update PDP Context Request and include the RNC's Address for User Plane, TEID for downlink data, No QoS negotiation indication and the DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. If the No QoS negotiation indication is not set, e.g. by a pre-Rel-7 SGSN and the GGSN includes a PCO in the Update PDP Context Response, it shall contain same information as the Protocol Configuration Options IE sent in the Create PDP Context Response in step 4 above.
If the SGSN does not receive PCO in this step and it has received PCO in step 4, then the SGSN shall forward the PCO received in step 4 to the UE.
Step 9.
The SGSN inserts the NSAPI along with the GGSN address in its PDP context. The PDP address received from the GGSN or from HSS subscription records is inserted in the PDP context. The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options, WLAN offloadability indication) message to the MS. If the MS indicated in the MS Network Capability it does not support BSS packet flow procedures, then the SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall take into account the Aggregate BSS QoS Profile, if any, returned from the BSS. Protocol Configuration Options are used to transfer the BCM and ETFTN to the UE and may be used to transfer optional PDP parameters to the UE (see TS 29.060 and TS 24.229). Protocol Configuration Options is sent transparently through the SGSN. The BCM indicates the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair. If the BCM parameter is not included in the message then the MS shall set the Bearer Control Mode to 'MS_Only' for the PDP Address/APN pair (see clause 9.2). If the ETFTN is included in the message then the MS may use the extended TFT filter format in subsequent MS requests. The SGSN is now able to route PDP PDUs between the GGSN and the MS, and to start charging.
If the MS is incapable of accepting the new QoS Negotiated, the MS should initiate application level signalling to lower the QoS requirements for the concerned application(s). If this is not possible then the MS shall instead de-activate the PDP context with the PDP Context Deactivation Initiated by the MS procedure.
The SGSN may include an indication whether the traffic of this PDP context is allowed to be offloaded to WLAN as described in clause 5.3.21.
For each PDP Context a different quality of service (QoS) profile may be requested. For example, some PDP contexts may be associated with E mail that can tolerate lengthy response times. Other applications cannot tolerate delay and demand a very high level of throughput, interactive applications being one example. These different requirements are reflected in the QoS profile. The QoS profile is defined in clause "Quality of Service Profile". If a QoS requirement is beyond the capabilities of a PLMN, the PLMN negotiates the QoS profile as close as possible to the requested QoS profile. The MS either accepts the negotiated QoS profile, or deactivates the PDP context.
After an SGSN has successfully updated the GGSN, the PDP contexts associated with an MS is distributed as shown in clause "Information Storage".
If the PDP Context Activation Procedure fails or if the SGSN returns an Activate PDP Context Reject (Cause, Protocol Configuration Options) message, the MS may attempt another activation to the same APN up to a maximum number of attempts.
If the MS requested for a dual address PDP type (IPv4v6) to a given APN and was granted a single address PDP type (IPv4 or IPv6) by the network with a reason cause 'single address bearers only', the MS should request for the activation of a parallel PDP Context to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already activated.
If the MS requested for a PDP type IPv4v6 to a given APN and was granted PDP type IPv4 with no reason cause indicating that only the assigned PDP type is allowed, the MS should request for the activation of a parallel PDP Context to the same APN with PDP type IPv6.
If the MS receives no reason cause in response to an IPv4v6 PDP type and it receives an IPv6 prefix and Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDP Address field, it considers that the request for a dual address PDP was successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.
The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078:
  • C1) CAMEL_GPRS_PDP_Context_Establishment.
In Figure 63 and Figure 64, procedures return as result "Continue".
  • C2) CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement.
In Figure 63 and Figure 64, procedures return as result "Continue".
Up

9.2.2.1A  PDP Context Activation Procedure using S4 |R8|p. 236

The procedures described in figures 64a and 64b show only the steps, due to use of S4, which are different from the Gn/Gp variant of the procedure given by clause 9.2.2.1.
Reproduction of 3GPP TS 23.060, Fig. 64a: PDP Context Activation Procedure steps (A) using S4
Up
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.
A)
The SGSN shall use the HSS provided default APN if no APN is provided by the UE. If the PDN subscription context contains no PDN-GW identity for this APN, or the APN has a LIPA permission of "LIPA Only" or "LIPA Conditional", the SGSN selects a PDN-GW as described in clause PDN-GW selection function. If the PDN subscription context profile contains a dynamically allocated PDN-GW identity and the Request Type does not indicate "Handover" the SGSN may select a new PDN-GW as described in clause PDN-GW selection function, e.g. to allocate a PDN-GW that allows for more efficient routing. If a Serving GW is not yet selected for this MS, the SGSN selects a Serving GW as described in clause Serving GW selection function. The SGSN sets the EPS Bearer Identity to an equivalent value as the NSAPI for the Bearer associated with the MS. Then the SGSN shall send a Create Session Request (IMSI, MSISDN, SGSN Control Plane TEID, PDN-GW address, APN, RAT type, Default Bearer QoS, PDN Type, APN-AMBR, PDN Address, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information, serving network identity, CN Operator Selection Entity, SGSN User Plane TEID, Dual Address Bearer Flag, Protocol Type over S5/S8, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restrictions, CGI/SAI, User CSG Information, MS Info Change Reporting support indication, DTI) message to the selected Serving GW. MSISDN is included if available in the stored UE context. The RAT type is provided in this message for the later PCC decision. The SGSN may change the requested PDP type according to the subscription data for this APN as described in clause 9.2.1. The Dual Address Bearer Flag shall be set when the MS requests PDN type IPv4v6 and all SGSNs, which the MS may be handed over to, are release 8 or above supporting dual addressing, which is determined based on node pre configuration by the operator. SGSN User Plane TEID shall not be sent if the SGSN decides to establish the Direct Tunnel between RNC and Serving GW. DTI is used to instruct the Serving GW that the Direct Tunnel shall be established between RNC and Serving GW.
For an emergency PDP Context Activation the SGSN applies the parameters from SGSN Emergency Configuration Data for the emergency bearer establishment performed in this step and any potentially stored IMSI related subscription data are ignored by the SGSN. For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is included and marked as unauthenticated.
The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. Handover Indication is included if the Request type indicates handover. Selection Mode indicates whether a subscribed APN was selected, or whether a non subscribed APN chosen by the SGSN was selected. Selection Mode is set according to Annex A. The P-GW may use Selection Mode when deciding whether to accept or reject the default bearer activation. For example, if an APN requires subscription, the P-GW is configured to accept only the default bearer activation that requests a subscribed APN as indicated by Selection Mode. Charging Characteristics indicates which kind of charging the bearer context is liable for. If there is an EPS subscription context available for the MS, the SGSN shall ignore the QoS requested parameter sent by the MS, and use the EPS subscribed QoS profile as received from the HSS. For MSs, for which the S4-SGSN has not received an EPS subscribed QoS profile, the S4-SGSN treats MS originated QoS requests the same as the Gn/Gp SGSN, i.e. the requested QoS is used when deriving the Default Bearer QoS and the APN-AMBR from the QoS requested parameter sent by the MS. If the "Higher bitrates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed", the S4-SGSN shall restrict the APN-AMBR in the EPS QoS profile to within 16 Mbps.
The ARP of the PDP context activated with this procedure should be set appropriately to minimize the risk of unnecessary release.
The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251. The SGSN shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace is activated. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC.
The Maximum APN Restriction parameter is used as described for the equivalent step in clause 9.2.2.1.
B)
The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, MSISDN, APN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW TEID of the control plane, RAT type, Default Bearer QoS, PDN Type, PDN Address, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information, serving network identity, CN Operator Selection Entity, Dual Address Bearer Flag, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, CGI/SAI, User CSG Information, MS Info Change Reporting support indication) message to the PDN-GW indicated by the PDN-GW address received in the previous step. MSISDN is included if available in the stored UE context. The PDN-GW may interact with PCRF (refer to TS 23.203).
For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is included and marked as unauthenticated.
C)
The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The way the P-GW handles Charging Characteristics that it may have received is defined in TS 32.251.
The PDN-GW may restrict or increase Default Bearer QoS based on external input e.g. PCRF.
The PDN-GW returns a Create Session Response (PDN-GW Address for the user plane, PDN-GW TEID of the user plane, PDN-GW Address for the control plane, PDN-GW TEID of the control plane, PDN Type, PDN Address, APN-AMBR, EPS Bearer Identity, EPS Bearer QoS, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, Presence Reporting Area Action, Delay Tolerant Connection) message to the Serving GW. The PDN-GW takes into account the PDN type sent by the MS, the Dual Address Bearer Flag and the policies of operator when the PDN-GW selects the PDN type to be used as follows. If the MS has requested PDN type IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing is possible in the PDN, the PDN-GW selects a single IP version (either IPv4 or IPv6). If the MS has requested PDN type IPv4 or IPv6, the PDN-GW uses the PDN type supplied by the MS in case it is supported in the PDN, otherwise an appropriate error cause will be returned. The PDN-GW allocates a PDN Address according to the selected PDN type. In case the PDN-GW has selected a PDN type different from the one sent by the MS, the PDN-GW indicates together with the PDN type IE a reason cause to the MS why the PDN type has been modified as described in clause 9.2.1. PDN Address is included if the P-GW allocated a PDN Address. If the PDN has been configured by the operator so that the PDN addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the PDN-GW allows the MS to use DHCPv4 for address allocation according to the Address Allocation Preference received from the MS, the PDN Address shall be set to 0.0.0.0, indicating that the IPv4 PDN address shall be negotiated by the MS with DHCPv4 after completion of the PDP Context Activation procedure. In case of external PDN addressing for IPv6, the PDN-GW obtains the IPv6 prefix from the external PDN using either RADIUS or Diameter client function. In the PDN Address field of the Create Session Response, the PDN-GW includes the Interface Identifier and IPv6 prefix. The PDN-GW sends Router Advertisement to the UE after default bearer establishment with the IPv6 prefix information for all cases. The IP address allocation details are described in the clause "Static and Dynamic PDP Addresses". The PDN-GW includes a Delay Tolerant Connection indication if the PDN-GW supports receiving a rejection cause from the SGW indicating that the MS is temporarily not reachable due to power saving and holding mobile terminated procedures, until the PDN-GW receives a message indicating that the MS is available for end to end signalling.
When the MS negotiates the IPv4 address with DHCPv4, the PDN-GW shall relay, modify and monitor these negotiations. However, in contrast to the GGSN procedures, the PDN-GW shall not update the IPv4 address to the SGSN nor to the MS.
The P-GW derives the BCM based on NRSU and operator policy if previously received in the Create Default Bearer Request message. The derived BCM is sent to the MS indicating the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair.
The P-GW derives the ETFTN based on ETFTU, if received in the Create PDP Context Request message, and operator policy. The derived ETFTN is sent to the MS indicating whether the extended TFT filter format can be used on all PDP Contexts within the activated PDP Address/APN pair.
Protocol Configuration Options contains the BCM, ETFTN as well as optional PDN parameters that the P-GW may transfer to the MS. These optional PDN parameters may be requested by the MS, or may be sent unsolicited by the P-GW. Protocol Configuration Options are sent transparently through the S-GW and SGSN.
When the Handover Indication is present, the PDN-GW does not yet send downlink packets to the SGW; the downlink path is to be switched at step A1 of Figure 64b.
If the 3GPP PS Data Off status is present in PCO, PDN-GW behaviour is as specified in TS 23.401.
D)
The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User Plane, Serving GW TEID for User Plane, Serving GW TEID for Control Plane, APN-AMBR, EPS Bearer Identity, EPS Bearer QoS, PDN-GW addresses and TEIDs (GTP based S5/S8) or GRE keys (PMIP based S5/S8) at the PDN-GW(s) for uplink traffic, PDN-GW Address for Control Plane, PDN-GW TEID for Control Plane, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, Presence Reporting Area Action, Delay Tolerant Connection) message to the SGSN. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context.
If an APN Restriction is received from the P-GW for this PDP Context, then the SGSN shall store this value for the PDP Context and the SGSN shall check this received value with the stored value for the Maximum APN Restriction to ensure there are no conflicts between values. If the consequence of this check results in the PDP Context being rejected, the SGSN shall initiate a PDP Context deactivation and return an appropriate error cause. If the PDP Context is accepted, it shall determine a (new) value for the Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the received APN Restriction.
When the PDN-GW has changed Default Bearer QoS the SGSN shall use the new QoS parameter values during establishment of the PDP Context. However, if the "Higher bit rates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed", the S4-SGSN shall, for non-GBR bearers, restrict the MBR sent to the UE to within 16 Mbps.
If the MS Info Change Reporting Action and/or the CSG Information Reporting Action are received for this bearer context, then the SGSN shall store this for the bearer context and the SGSN shall report to that P-GW via the S-GW whenever a CGI/SAI/RAI or user CSG information change occurs that meets the P-GW request, as described in clause 15.1.1a.
If Presence Reporting Area Action is received for this bearer context, the S4-SGSN shall store this for the bearer context and shall report to that P-GW via the S-GW whenever a change of UE presence in Presence Reporting Area is detected, as described in clause 15.1.3.1.
Reproduction of 3GPP TS 23.060, Fig. 64b: PDP Context Activation Procedure steps (B) using S4
Up
A)
In case the QoS attributes, used as input to step 5 for Iu mode or step 7 for A/Gb mode, have been downgraded during those steps, the SGSN rejects the PDP Context Activation and terminates the procedure. If the SGSN established Direct Tunnel in step 5 it shall send Modify Bearer Request and include the RNC's Address for User Plane, TEID for downlink data and DTI. DTI is used to instruct the S-GW to apply Direct Tunnel specific error handling as described in clause 13.8. An Update Bearer Request shall also be sent to the S-GW if the UE has indicated Request type "Handover" in the Activate PDP Context Request message, and in that case the Handover Indicator shall be included in the message. An Update Bearer Request shall also be sent to the S-GW if the SGSN has been requested to report a change of UE presence in Presence Reporting Area, and in that case the message shall include the Presence Reporting Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the area(s). When receiving the request for reporting change of UE presence in Presence Reporting Area, and the S4-SGSN decides not to activate reporting UE presence in one or more of the received Presence Reporting Area(s), the S4-SGSN reports also the inactive Presence Reporting Area(s) in this message.
A1)
If the Handover Indication is included in step A, the Serving GW sends a Modify Bearer Request(Handover Indication) message to the PDN to prompt the PDN-GW to tunnel packets from non 3GPP IP access to 3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated EPS bearers established. If Presence Reporting Area Information is included in step A, the Serving GW sends a Modify Bearer Request (Presence Reporting Area Information) message to the PDN-GW.
A2)
The PDN-GW acknowledges by sending Modify Bearer Response to the Serving GW.
B)
The Serving GW acknowledges by sending Modify Bearer Response to the SGSN. The Serving GW can then send its buffered downlink packets.
C)
After the SGSN receives Modify Bearer Response in step B, if an EPS bearer was established and if the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses and if the SGSN selected a PDN-GW that is different from the PDN-GW identity which was indicated by the HSS in the PDN subscription context, the SGSN shall send an Update Location Request including the PDN-GW identity, the APN and information identifying the PLMN in which the PDN-GW is located to the HSS for mobility with non 3GPP accesses.
If the MS is emergency Attached, SGSN shall not send any Update Location Request to an HSS.
D)
The HSS stores the PDN-GW identity and the associated APN, and sends an Update Location Response to the SGSN.
If the S6d interface is used between an S4-SGSN and HSS, the messages "Update Location Request" and "Update Location Response" shall be replaced with "Notify Request" and "Notify Response".
If the MS requested for a dual address PDP type (IPv4v6) to a given APN and was granted a single address PDP type (IPv4 or IPv6) by the network with a reason cause 'single address bearers only', the MS should request for the activation of a parallel PDP Context to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already activated. If the MS receives no reason cause in response to an IPv4v6 PDP type and it receives an IPv6 prefix and Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDP was successful. The MS shall ignore the IPv6 prefix as described in the step 3 in clause 9.2.1.1. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.
Up
9.2.2.1.1  Secondary PDP Context Activation Procedurep. 240
The Secondary PDP Context Activation procedure may be used to activate a PDP context while reusing the PDP address and other PDP context information from an already active PDP context, but with a different QoS profile. Procedures for APN selection and PDP address negotiation are not executed. A unique TI and a unique NSAPI shall identify each PDP context sharing the same PDP address and APN.
Any emergency secondary PDP context activation procedure shall be initiated by the network. An MS with an active emergency PDP context shall not initiate the Secondary PDP Context Activation procedure for the emergency PDN connection unless triggered by the Network Requested Secondary PDP Context Procedure.
In the Secondary PDP Context Activation procedure the MS shall provide a TFT. The TFT contains attributes that specify an IP header filter that is used to route downlink N-PDUs to the newly activated PDP context (as described in clause 9.3). The TFT may also contain attributes that specify an IP header filter that is used to identify uplink IP flow(s) to apply policy control functionality as described in TS 23.203.
The Secondary PDP Context Activation procedure may only be initiated after a PDP context is already activated for the same PDP address and APN. The procedure is illustrated in Figure 65 and Figure 66.
Reproduction of 3GPP TS 23.060, Fig. 65: Secondary PDP Context Activation Procedure for A/Gb mode
Up
Reproduction of 3GPP TS 23.060, Fig. 66: Secondary PDP Context Activation Procedure for Iu mode
Up
1)
The MS sends an Activate Secondary PDP Context Request (Linked TI, NSAPI, TI, QoS Requested, TFT, Protocol Configuration Options) message to the SGSN. Linked TI indicates the TI value assigned to any one of the already activated PDP contexts for this PDP address and APN. QoS Requested indicates the desired QoS profile. TFT is sent transparently through the SGSN to the GGSN to enable packet classification for downlink data transfer. TI and NSAPI contain values not used by any other activated PDP context. Protocol Configuration Options may be used to transfer optional PDP parameters and/or requests to the GGSN (see TS 29.060 and TS 24.229). Protocol Configuration Options is sent transparently through the SGSN.
If the SGSN decides to establish Direct Tunnel between RNC and GGSN, the SGSN provides to the RNC the Direct Tunnel specific parameters in step 4 "RAB Assignment Procedure" and shall initiate PDP Context Update procedure in step 6 to update IP Address and TEID for Downlink data.
2)
In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function".
3)
The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The same GGSN address is used by the SGSN as for the already-activated PDP context(s) for that TI and PDP address.
The SGSN may restrict the requested QoS attributes given its capabilities and the current load, and it shall restrict the requested QoS attributes according to the subscribed QoS profile, which represents the maximum QoS per PDP context to the associated APN. The GGSN may restrict or increase, and negotiate the requested QoS as specified in clause "PDP Context Activation Procedure". The SGSN sends a Create PDP Context Request (QoS Negotiated, TEID, NSAPI, Primary NSAPI, TFT, Protocol Configuration Options, serving network identity, IMEISV, CGI/SAI, RAT type, S-CDR CAMEL information, CGI/SAI/RAI change support indication, Correlation-ID) message to the affected GGSN. The SGSN shall send the serving network identity to the GGSN. Primary NSAPI indicates the NSAPI value assigned to any one of the already activated PDP contexts for this PDP address and APN. TFT is included only if received in the Activate Secondary PDP Context Request message. Protocol Configuration Options is sent transparently through the SGSN if received in the Activate secondary PDP Context Request message. If the Secondary PDP Context Activation Procedure is performed as part of the Network Requested Secondary PDP Context Activation Procedure (clause 9.2.2.3) and if the GGSN included Negotiated Evolved ARP in the Initiate PDP Context Activation then the SGSN shall include the provided negotiated Evolved ARP in the Create PDP Context Request. The Correlation-ID shall only be included if the Secondary PDP Context Activation is performed as part of the Network Requested Secondary PDP Context Activation Procedure (clause 9.2.2.3), and shall be linked to the TI as described in clause 9.2.2.3.
The GGSN uses the same packet data network as used by the already activated PDP context(s) for that PDP address, generates a new entry in its PDP context table, and stores the TFT. The new entry will allow the GGSN to route PDP PDUs via different GTP tunnels between the SGSN and the packet data network. The GGSN returns a Create PDP Context Response (TEID, QoS Negotiated, Negotiated Evolved ARP, Cause, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, CGI/SAI/RAI change report required) message to the SGSN. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401, Annex E. Protocol Configuration Options may be used to transfer optional PDP parameters to the UE (see TS 29.060 and TS 24.229). The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the PDP Context.
If the CGI/SAI/RAI report required is received from the GGSN for this PDP context, then the SGSN shall store this for the PDP context and the SGSN shall report to that GGSN whenever a CGI/SAI/RAI change occurs that meets the GGSN request.
The SGSN shall re-verify and may restrict the QoS Negotiated received from the GGSN against the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. The SGSN shall use this updated QoS Negotiated for the subsequent steps.
The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP.
The GGSN may interact with PCRF (refer to TS 23.203), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.
4)
In Iu mode, RAB setup is done by the RAB Assignment procedure.
5)
In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".
6)
The SGSN sends an Update PDP Context Request message to the GGSN, including the QoS attributes that have been accepted by the RAN. In case the QoS attributes have been downgraded in step 5 for A/Gb mode or in step 4 for Iu mode, the SGSN may inform the GGSN about the downgraded QoS. The GGSN shall not attempt to renegotiate the QoS attributes. A RAN Procedures Ready flag is included in the Update PDP Context Request. A GGSN that receives an Update PDP Context Request with a RAN Procedures Ready flag set, should start to route downlink PDP PDUs immediately. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN shall accept the provided QoS attributes without negotiation. The GGSN confirms the reception of the message and the potentially downgraded QoS attributes by sending an Update PDP Context Response to the SGSN. If the SGSN established Direct Tunnel in step 4 it shall send Update PDP Context Request and include the RNC's Address for User Plane and downlink TEID for data, the No QoS negotiation indication and DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. If the No QoS negotiation indication is not set, e.g. by a pre-Rel-7 SGSN and the GGSN includes a PCO in the Update PDP Context Response, it shall contain same information as the Protocol Configuration Options IE sent in the Create PDP Context Response in step 3 above.
If the SGSN does not receive PCO in this step and it has received PCO in step 3, then the SGSN shall forward the PCO received in step 3 to the UE.
7)
The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate Secondary PDP Context Accept (TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options, WLAN offloadability indication) message to the MS. If the MS indicated in the MS Network Capability it does not support BSS packet flow procedures, then the SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall take into account the Aggregate BSS QoS Profile, if any, returned from the BSS. Protocol Configuration Options is sent transparently through the SGSN if received in the Create PDP Context Response message. The SGSN is now able to route PDP PDUs between the GGSN and the MS via different GTP tunnels and possibly different LLC links.
If the MS is incapable of accepting the new QoS Negotiated, the MS should initiate application level signalling to lower the QoS requirements for the concerned application(s). If this is not possible then the MS shall instead de-activate the PDP context with the PDP Context Deactivation Initiated by the MS procedure.
The SGSN may include an indication whether the traffic of this PDP context is allowed to be offloaded to WLAN as described in clause 5.3.21.
For each additionally activated PDP context a QoS profile and TFT may be requested.
If the secondary PDP context activation procedure fails or if the SGSN returns an Activate Secondary PDP Context Reject (Cause, Protocol Configuration Options) message, the MS may attempt another activation with a different TFT, depending on the cause.
The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078:
  • C1) CAMEL_GPRS_PDP_Context_Establishment.
In Figure 65 and in Figure 66, procedures return as result "Continue".
  • C2) CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement.
In Figure 65 and in Figure 66, procedures return as result "Continue".
Up
9.2.2.1.1A  Secondary PDP Context Activation Procedure, PDP Creation part, using S4p. 243
The procedure described in Figure 66a shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedure given by clause 9.2.2.1.1.
Reproduction of 3GPP TS 23.060, Fig. 66a: Secondary PDP Context Activation Procedure using S4
Up
A)
The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The same P-GW and S-GW addresses are used by the SGSN as for the already-activated PDP context(s) for that TI and PDP address.
The Procedure Transaction Id, PTI, is dynamically allocated by the SGSN for the Activate Secondary PDP Context procedure when using S4. The SGSN should ensure as far as possible that previously used PTI values are not immediately reused for the same MS. The SGSN shall store the relationship between the assigned PTI and the received Linked TI during the lifetime of the procedure. The PTI is released when the procedure is completed.
The SGSN sends the Bearer Resource Command (LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type, Protocol Configuration Options) message to the selected Serving GW. The same Serving GW is used by the SGSN as for the PDP Context identified by the Linked TI received in the Activate Secondary PDP Context Request message.
B)
The Serving GW sends the Bearer Resource Command (LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type, 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. The PDN-GW derives from the RAT type indicating GERAN or UTRAN and the absence of the EPS Bearer Id that a new EPS Bearer needs to be established. The PDN-GW may interact with PCRF (refer to TS 23.203) and provides to the PCRF the TFT operation add together with the new filter(s) and the QCI and/or GBR, if available. The PDN-GW shall accept packet filter identifiers specified by the MS in the TFT.
C)
If the request is accepted, the Dedicated Bearer Activation Procedure is invoked to establish a new EPS Bearer by the PDN-GW and the PDN-GW sends the Create Bearer Request (PTI, EPS Bearer QoS, TFT, S5/S8-TEID, LBI, Protocol Configuration Options) message to the Serving GW. The PTI allocated by the SGSN is used as a parameter in the invoked Dedicated Bearer Activation Procedure to correlate it to the Activate Secondary PDP Context Procedure. The PDN-GW shall assign packet filter identifiers as specified in the TFT received with the Bearer Resource Command for the corresponding TFT filters. The PDN-GW/PCRF may restrict or increase, and negotiate the requested QoS as specified in clause "PDP Context Activation Procedure". If the PCRF was contacted, the EPS Bearer QoS is updated according to the QoS of the received PCC rules. In addition, the PDN-GW uses the SDF filter(s) in the PCC rule(s) received from the PCRF to generate the TFT. The PDN-GW maintains the relation between the SDF filter identifier in the PCC rule and the packet filter identifier of the TFT.
If the request for a specific QoS is not accepted or the request does not include a TFT, or the PCC rule(s) received from the PCRF include any SDF filter (that is to to be provided to the MS) that was not requested by the MS, the PDN-GW sends a reject indication, which shall be delivered to the MS. A cause indicates the reason why the request was rejected.
D)
The Serving GW sends the Create Bearer Request (PTI, EPS Bearer QoS, TFT, UL TEID, LBI, Protocol Configuration Options) message to the SGSN. If the "Higher bit rates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed", the S4-SGSN shall, for non-GBR bearers, restrict the MBR sent to the UE to within 16 Mbps.
E)
The SGSN acknowledges the bearer activation to the Serving GW by sending a Create Bearer Response (EPS Bearer Identity, DL TEID, User Location Information) message. The SGSN sets the EPS Bearer Identity to the same value as the NSAPI for the Bearer associated with the MS. The DL TEID value can be either the SGSN user plane TEID (2G or non-DT 3G) or the RNC user plane TEID.
F)
The Serving GW acknowledges the bearer activation to the PDN-GW by sending a Create Bearer Response (EPS Bearer Identity, S5/S8-TEID, User Location Information) message. The PDN-GW may interact with PCRF (refer to TS 23.203). The PDN-GW may deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF (refer to TS 23.203).
Up
9.2.2.1.1BVoid

Up   Top   ToC