A PS subscription contains the subscription of one or more PDP addresses. Each PDP address is an element of a PDP context. The same PDP address may appear in one or more PDP contexts in the MS, the SGSN, the S-GW, the P-GW and the GGSN. Each PDP context may be associated with a TFT. At most one PDP context associated with the same PDP address may exist at any time with no TFT assigned to it. Every PDP context exists independently in one of two PDP states. The PDP state indicates whether data transfer is enabled for that PDP address and TFT or not. In case all PDP contexts associated with the same PDP address are deactivated, data transfer for that PDP address is disabled. Activation and deactivation are described in clause "PDP Context Activation, Modification, Deactivation, and Preservation Functions". All PDP contexts of a subscriber are associated with the same MM context for the IMSI of that subscriber.
The INACTIVE state characterises the data service for a certain PDP address of the subscriber as not activated. The PDP context contains no routeing or mapping information to process PDP PDUs related to that PDP address. No data can be transferred. A changing location of a subscriber causes no update for the PDP context in INACTIVE state even if the subscriber is GPRS-attached.
Mobile-terminated PDP PDUs received in INACTIVE state by the GGSN may initiate the Network-Requested PDP Context Activation procedure if the GGSN is allowed to initiate the activation of the PDP context for that PDP address. Otherwise, mobile-terminated PDP PDUs received in INACTIVE state invoke error procedures in the P-GW or GGSN relevant to the packet data network protocol, for example, an IP packet is discarded and an ICMP (see RFC 792) packet (error notification) is returned to the source of the received packet. Other error procedures may be introduced on the application level, but this is outside the scope of the present document.
The MS initiates the movement from INACTIVE to ACTIVE state by initiating the PDP Context Activation procedure.
In ACTIVE state, the PDP context for the PDP address in use is activated in the MS, SGSN and GGSN when using Gn/Gp, or in the MS, SGSN, S-GW and P-GW when using S4. The PDP context contains mapping and routeing information for transferring PDP PDUs for that particular PDP address between the MS and the P-GW or GGSN. The PDP state ACTIVE is permitted only when the mobility management state of the subscriber is STANDBY, READY, PMM IDLE, or PMM CONNECTED. The Iu interface radio access bearer may or may not be established for an active PDP context.
An active PDP context for an MS is moved to INACTIVE state when the deactivation procedure is initiated.
All active PDP contexts for an MS are moved to INACTIVE state when the MM state changes to IDLE or PMM DETACHED.
This clause describes the procedures to enable a GPRS-attached MS to initiate the activation, modification, and deactivation functions for a PDP context in the MS, the SGSN, the S-GW and the P-GW or GGSN. In addition procedures to enable a P-GW or GGSN to request the activation, modification and deactivation of a PDP context to a GPRS-attached subscriber are described.
An MS that activates Primary PDP Context(s) of PDP Type Non-IP shall not activate Secondary PDP Contexts for such PDP Context(s).
Upon receiving an Activate PDP Context Request message or an Activate Secondary PDP Context Request message, the SGSN shall initiate procedures to set up PDP contexts. The first procedure includes subscription checking, APN selection, and host configuration, while the latter procedure excludes these functions and reuses PDP context parameters including the PDP address but except the QoS parameters. Once activated, all PDP contexts that share the same PDP address and APN shall be managed equally. At least one PDP context shall be activated for a PDP address before a Secondary PDP Context Activation procedure may be initiated. When the MS performs an RA update procedure to change from a release 99 to a release 97 or 98 system, only one active PDP context per PDP address and APN shall be preserved. This PDP context is selected taking the QoS profile and NSAPI value into account.
When the SGSN is using the S4 interface to an S-GW for a PDP Context, EPS Bearer procedures will be used.
The EPS subscription context includes a mandatory EPS subscribed QoS profile for the default bearer of each subscribed APN. If the S4-SGSN has received an EPS subscribed QoS profile and the first PDP context to a given APN is activated, the S4-SGSN disregards the QoS requested by the MS and sends the EPS subscribed QoS profile for this APN to the S-GW. For MSs, for which the S4-SGSN has not received an EPS subscribed QoS profile per APN, the S4-SGSN treats MS originated QoS requests the same as the Gn/Gp SGSN. For MSs, for which the S4-SGSN has not received a subscribed APN-AMBR per APN, the S4-SGSN provides APN-AMBR to the Serving GW and PDN-GW. Details on mapping MBR to APN-AMBR are specified in Annex E of TS 23.401.
The E-UTRAN capable MS shall not deactivate the PDP context created by the PDP Context Activation Procedure unless all PDP contexts for the same PDN connection are to be deactivated. The MS shall not modify the QoS of the PDP context created by the PDP Context Activation Procedure.
When the E-UTRAN capable MS is activating the first PDP context with the PDP Context Activation Procedure, the MS shall request for the subscribed QoS profile, but the MS may request for subscribed, interactive or background traffic class. If the EPS subscribed QoS profile information is available to the PDN-GW (e.g. if PCC is deployed) and the PDN-GW is connected to an Gn/Gp SGSN, the PDN-GW shall modify the requested QoS according to the EPS subscribed QoS profile during the PDP Context Activation Procedure.
The non E-UTRAN capable MS should not deactivate the PDP context created by the PDP Context Activation Procedure unless all PDP contexts for the same PDN connection are to be deactivated. The MS should not modify the QoS of the PDP context created by the PDP Context Activation Procedure as long as the MS can achieve the same result using a different PDP context than the PDP context created by the PDP Context Activation Procedure.
During the PDP Context Activation Procedure the bearer control mode, applicable to all PDP Contexts within the activated PDP Address/APN pair, is negotiated. The Bearer Control Mode (BCM) is one of 'MS_only' or 'MS/NW':
When 'MS_only' the MS shall request any additional PDP contexts for the PDP Address/APN pair through the Secondary PDP Context Activation Procedure. Session Management procedures described in 9.2 apply with the following restrictions:
The P-GW or GGSN shall not initiate any Network Requested Secondary PDP Context Activation.
The P-GW or GGSN shall not initiate any TFT operation.
The P-GW shall reject any MS request for a secondary PDP context activation that is received without a TFT.
For a TFT, when the MS uses the direction attribute, the MS shall ensure that there is at least one packet filter for the uplink direction (unless the TFT is for the PDP context that has been established with the PDP Context Activation Procedure).
When 'MS/NW' both the MS and the P-GW or GGSN may request additional PDP contexts for the PDP Address/APN pair. The MS shall use the Secondary PDP Context Activation Procedure. The P-GW or GGSN shall use the Network Requested Secondary PDP Context Activation Procedure. The MS shall, when modifying the QoS of a PDP context, include a TFT with at least packet filter identifiers to indicate which packet filters in the TFT are associated with the QoS change.
For 'MS/NW' the session Management procedures described in clause 9.2 apply with the following restrictions:
The MS shall not modify the QoS of a PDP context until this PDP context is associated with a TFT containing packet filters set by the MS. If the TFT also contains packet filters set by the P-GW/GGSN, the MS is only allowed to modify the bit rate parameters in the QoS profile of that PDP Context;
The MS shall not initiate any Secondary PDP Context Activation without sending a TFT containing at least one packet filter for the uplink direction;
The P-GW/GGSN shall not initiate any Network Requested Secondary PDP Context Activation without sending a TFT containing at least one packet filter for the uplink direction;
The MS shall not add a TFT to a PDP context that was established without a TFT;
The MS shall not delete the TFT from a PDP context that is associated with a TFT;
The network shall not delete the TFT from a PDP context that is associated with a TFT unless the PDP context was created by the PDP Context Activation Procedure;
Only the entity that sets a packet filter in the TFT (either MS or P-GW/GGSN) is allowed to modify or delete this packet filter;
For each TFT, the MS and the network shall ensure that among the packet filters under own control there is at least one packet filter for the uplink direction, or no own packet filter at all (unless the TFT is for the PDP context that has been established with the PDP Context Activation Procedure);
For each packet filter the MS and the network shall indicate whether it corresponds to uplink, downlink or bi-directional traffic flow(s).
The P-GW/GGSN shall ensure that for all PDP contexts of the same APN/PDP address pair a valid state for the TFT settings (as defined in clause 15.3.0) is maintained.
The MS indicates support of the network requested bearer control through the Network Request Support UE (NRSU) parameter, which is applicable to all PDP contexts within the same PDP address / APN pair. The SGSN indicates support of the network requested bearer control through the Network Request Support Network (NRSN) parameter.
If the NRSN is not included in the Update PDP Context Request message from the SGSN, or the SGSN does not indicate support of the network requested bearer control, the GGSN or P-GW shall, following a SGSN-Initiated PDP Context Modification (triggered by SGSN change), perform a GGSN or P-GW-Initiated PDP Context Modification to change the BCM to 'MS-Only' for all PDP-Address/APN-pairs for which the current BCM is 'MS/NW'.
An S4-based SGSN shall apply the BCM 'MS/NW' whenever the S4 is selected for a certain MS.
The MS indicates support of the extended TFT filter format through the Extended TFT Support UE (ETFTU) parameter, which is applicable to all PDP contexts within the same PDP address / APN pair. The network indicates the support of the extended TFT filter format for all PDP contexts within the same PDP address / APN pair through the Extended TFT Support Network (ETFTN) parameter.
Upon receiving a Deactivate PDP Context Request message, the SGSN shall initiate procedures to deactivate the PDP context. When the last PDP context associated with a PDP address is deactivated, N PDU transfer for this PDP address is disabled.
An MS does not have to receive the (De ) Activate PDP Context Accept message before issuing another (De-)Activate PDP Context Request. However, only one request can be outstanding for every TI.
By sending a RAB Release Request or Iu Release Request message to the SGSN, the RAN initiates the release of one or more RABs. The preservation function allows the active PDP contexts associated with the released RABs to be preserved in the CN, and the RABs can then be re-established at a later stage.
An S4-based SGSN shall for all active PDN Connections for a certain MS use either S4 or Gn/Gp. This is achieved by the SGSN rejecting a PDP Context activation violating this:
If an MS is sending an Activate PDP Context Request for an APN using Gn, the activation will be rejected by the SGSN if a PDP Context using S4 already exists for this MS;
If an MS is sending an Activate PDP Context Request for an APN using S4, the activation will be rejected by the SGSN if a PDP Context using Gn already exists for this MS.
The list of QoS parameters that the PCEF may change, e.g. ARP or APN-AMBR or both, either based on local policy or based on PCRF interactions is described in clause 9.2.3.
In a roaming scenario, based on local configuration, the S4-SGSN may downgrade the ARP or APN-AMBR and/or remap QCI parameter values received from HSS to the value locally configured in S4-SGSN (e.g. when the values received from HSS do not comply with services provided by the visited PLMN). The PCEF may change the QoS parameter values received from the S4-SGSN based on interaction with the PCRF or based on local configuration. Alternatively, the PCEF may reject the bearer establishment.
If case S4 is selected for a certain MS the SGSN shall not modify the EPS bearer level QoS parameters received from the PDN-GW during establishment or modification of a default or dedicated bearer (except when the conditions described in NOTE 14 apply). Based on local configuration, the SGSN may reject the establishment or modification of a default or dedicated bearer only in the case of roaming when the bearer level QoS parameter values do not comply with a roaming agreement.
The following text describes the general principles used by an SGSN using S4 when mapping between PDP Contexts and EPS Bearers.
The MS is using PDP Context Activation, Modification and Deactivation functions, and PDP Contexts are therefore used between MS and SGSN. An SGSN using Gn/Gp only will use these procedures towards GGSNs as well. An SGSN using S4 will for a specific PDP Context towards an MS map these procedures into equivalent procedures using EPS Bearer towards S-GW and P-GW. EPS Bearer procedures will not be used between MS and SGSN.
The following principles are to be used:
1:1 mapping between one PDP context and one EPS Bearer;
1:1 mapping between NSAPI and EPS Bearer ID;
The P-GW treats an MS-initiated request, e.g. a Secondary PDP Context Activation Request, according to the UE requested bearer resource modification procedures in TS 23.401;
PDN-GW and Serving GW need to be RAT aware to allow for 2G/3G specific handling of EPS bearers, e.g. MS initiated secondary PDP Context activation must make the P-GW to activate a new EPS bearer.
The QoS profiles of the PDP context and EPS bearer are mapped as specified in TS 23.401.
If the S4-SGSN receives the EPS subscribed QoS profile per subscribed APN from the HSS, the S4-SGSN enforces this QoS for the first PDP context which is activated to the given APN. Otherwise the S4-SGSN restricts requested QoS according to the QoS Profile Subscribed which defines the maximum QoS per subscribed APN.
PDP addresses can be allocated to an MS in four different ways:
the HPLMN operator assigns a PDP address permanently to the MS (static PDP address);
the HPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic HPLMN PDP address);
the VPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic VPLMN PDP address); or
the PDN operator or administrator assigns a permanent or dynamic PDP address to the MS (External PDN Address Allocation).
It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN or VPLMN PDP address can be used. The HPLMN operator may assign a static PDP address in the PDP context subscription record. An MS implemented according to this version of the protocol does not support static PDP addresses, which are permanently configured in the MS and sent by the MS within the PDP context activation request. The handling of static addresses, which are sent by the MS, is retained in the SGSN in order to ensure backwards compatibility for MSs implemented according to earlier protocol releases.
For every IMSI, zero, one, or more dynamic PDP addresses per PDP type can be assigned. For every IMSI, zero, one, or more static PDP addresses per PDP type can be subscribed to.
When dynamic addressing from the HPLMN or the VPLMN is used, it is the responsibility of the GGSN or P-GW to allocate and release the dynamic PDP address.
When External PDN Address Allocation is used, the following applies for GGSN:
the PLMN may obtain a PDP address from the PDN and provide it to the MS during PDP context activation, or the MS may directly negotiate a PDP address with the PDN after the PDP context activation procedure is executed. If the PLMN provides the address during PDP context activation in case of External PDN Address Allocation, then it is the responsibility of the GGSN and PDN to allocate, renew and release the dynamic PDP address by means of protocols such as DHCP or RADIUS. If DHCPv4/v6 is used, the GGSN provides the function of a DHCPv4/v6 Client. If RADIUS is used, the GGSN provides the function of a RADIUS Client. If the MS negotiates a PDP address with the PDN after PDP context activation in case of External PDN Address Allocation, it is the responsibility of the MS and the PDN to allocate and release the PDP address by means of protocols such as DHCP or MIP. In case of DHCPv4, the GGSN provides the function of a DHCP Relay Agent as defined in RFC 2131 and RFC 1542. In case of MIP, the GGSN provides the function of a Foreign Agent as defined in RFC 3344.
External PDN Address Allocation (including DHCP functionality) in P-GW is specified in TS 23.401.
Only static PDP addressing is applicable in the network-requested PDP context activation case.
PDP types IPv4, IPv6 and IPv4v6 are supported. A PDP Context of PDP type IPv4v6 may be associated with one IPv6 prefix only or with both one IPv4 address and one IPv6 prefix. PDP types IPv4 and IPv6 are utilised in case the MS and/or the GGSN or P-GW support IPv4 addressing only or IPv6 addressing only; or operator preferences dictate the use of a single IP version type only, or the subscription is limited to IPv4 only or IPv6 only. In addition, PDP types IPv4 and IPv6 are utilised for interworking with nodes of earlier releases.
The way that the MS sets the requested PDP type may be pre-configured in the device per APN. Unless otherwise configured (including when the MS does not send any APN), PDP types are set by the MS as follows:
An MS, which supports Non-IP data and wants to use Non-IP data, shall request for PDP type Non-IP.
An MS, which is IPv6 and IPv4 capable, shall request for PDP type IPv4v6.
An MS, which supports IPv4 addressing only, shall request for PDP type IPv4.
An MS, which supports IPv6 addressing, shall request for PDP type IPv6.
When the IP addressing capability of the MS is not known in the MS (as in the case when the MT and TE are separated and the capability of the TE is not known in the MT), the MS shall request for PDP type IPv4v6.
During the PDP Context Activation procedure the SGSN compares the requested PDP type to the PDP type in the subscription records for the given APN and sets the PDP type as follows:
If the requested PDP type is allowed by subscription, the S4-SGSN sets the PDP type as requested.
If the requested PDP type is allowed by subscription and if the requested PDP type is IPv4v6, the Gn/Gp SGSN sets the PDP type as requested if the GGSN supports PDP type IPv4v6. Otherwise, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is based on the result of the check.
If the requested PDP type is IPv4v6 and subscription data only allows PDP type IPv4 or only allows PDP type IPv6, the SGSN sets the PDP type according to the subscribed value. A reason cause shall be returned to the UE indicating that only the assigned PDP type is allowed. In this case the UE shall not request for another PDP context to the same APN for the other IP version during the existence of the PDP context.
If the requested PDP type is IPv4 or IPv6, and either the requested PDP type or PDP type IPv4v6 are subscribed, the SGSN sets the PDP type as requested. Otherwise the PDP context activation request is rejected.
If the requested PDP type is IPv4v6, and both IPv4 and IPv6 PDP types are allowed by subscription but not IPv4v6, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is implementation specific. The MS should then initiate another PDP Context Activation procedure to this APN in order to activate a second PDP context with the other single address PDP type which was not allocated by the network.
The GGSN / PDN-GW may restrict the usage of PDP type IPv4v6 as follows:
If the MS requests PDP type IPv4v6, but the operator preferences dictate the use of a single IP version only, the PDP type shall be changed to a single address PDP type (IPv4 or IPv6) and a reason cause shall be returned to the MS indicating that only the assigned PDP type is allowed. In this case, the MS shall not request another PDP context for the other PDP type during the existence of the PDP context.
If the MS requests PDP type IPv4v6, but the operator uses single addressing per PDP context due to interworking with nodes of earlier releases, the PDP type shall be changed to a single address PDP type and a reason cause of "single address bearers only" shall be returned to the MS. In this case the MS should request another PDP context for the other PDP type to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already activated.
An MS of this release may request for PDP type IPv4v6 from a SGSN which does not support this PDP type. The SGSN treats a request for PDP type IPv4v6 as if it were a request for PDP type IPv4. To enable dual-stack connectivity for this case, the MS should request another PDP context for PDP type IPv6 to the same APN.
The mechanism used to allocate an IPv4 address to an MS depends on the MS and the network capabilities. The MS may indicate to the network within the Protocol Configuration Options element that the MS wants to obtain the IPv4 address with DHCPv4 as defined in RFC 2131:
the MS may indicate that it prefers to obtain an IPv4 address as part of the PDP context activation procedure. In such a case, the MS relies on the network to provide an IPv4 address to the MS as part of the PDP context activation procedure.
the MS may indicate that it prefers to obtain the IPv4 address after the PDP Context Activation by DHCPv4. That is, the network does not provide the IPv4 address for the MS as part of the PDP context activation procedures but sets the PDP address as 0.0.0.0. After the PDP Context establishment procedure is completed, the MS initiates the IPv4 address allocation by using DHCPv4 (see details in TS 29.061 and RFC 2131).
If the MS does not send such an indication of address allocation preference, the network selects the IPv4 address allocation method based on per APN configuration.
Both the network elements and MS may support:
IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to RFC 2131 and RFC 4039;
IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736.
IPv6 address configuration is somewhat different from the IPv4 address configuration procedure. The address of an IPv6 node is allocated by stateless autoconfiguration.
The GGSN informs the MS that it shall perform stateless address autoconfiguration by means of the Router Advertisements, as defined in RFC 4861. For this purpose, the GGSN shall automatically and periodically send Router Advertisement messages towards the MS after a PDP context of type IPv4v6 or IPv6 is activated.
In order to support the standard IPv6 stateless address autoconfiguration mechanism, as defined by the IETF, within the particular context of UMTS (point-to-point connections, radio resource efficiency, etc.), the GGSN shall assign a prefix that is unique within its scope to each PDP context applying IPv6 stateless address autoconfiguration. The size of the prefix is according to the maximum prefix length for a global IPv6 address. This avoids the necessity to perform duplicate address detection at the network level for every address built by the MS. The GGSN shall not use the prefix advertised to the MS to configure an address on any of its interfaces.
To ensure that the link-local address generated by the MS does not collide with the link-local address of the GGSN, the GGSN shall provide an interface identifier (see RFC 4862) to the MS and the MS shall use this interface identifier to configure its link-local address. For stateless address autoconfiguration however, the MS can choose any interface identifier to generate addresses other than link-local, without involving the network. However, the UE shall not use any identifiers defined in TS 23.003 as the basis for generating the interface identifier. For privacy, the UE may change the interface identifier used to generate full IPv6 address as defined in TS 23.221, without involving the network. In particular, the SGSN and the GGSN are not updated with the actual address used by the MS, as the prefix alone identifies the PDP context.
Figure 62 illustrates the IPv6 stateless autoconfiguration procedure The Figure and its description show only the messages and actions specific to the IPv6 stateless address autoconfiguration procedure. For a complete description of the PDP Context Activation Procedure, refer to the corresponding clause.
Upon reception of the Create PDP Context Request, the GGSN creates an IPv6 address composed of the prefix allocated to the PDP context and an interface identifier generated by the GGSN. This address is then returned in the PDP Address information element in the Create PDP Context Response message. The processing of the Create PDP Context Request and Create PDP Context Response, in both the SGSN and the GGSN, is otherwise as specified in clause "PDP Context Activation Procedure".
The MS receives the IPv6 address produced by the GGSN in the Activate PDP Context Accept. The MS extracts the interface identifier from the address received and stores it. The MS shall use this interface identifier to build its link-local address and may also use it for building its full IPv6 address, as describe in step 5. The MS shall ignore the prefix contained in the address received in the Activate PDP Context Accept. The processing of the Activate PDP Context Accept is otherwise as specified in clause "PDP Context Activation Procedure".
The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain the same prefix as the one provided in step 2. A given prefix shall not be advertised on more than one PDP context on a given APN, or set of APNs, within the same addressing scope. The GGSN shall be configured to advertise only one prefix per PDP context.
After the MS has received the Router Advertisement message, it constructs its full IPv6 address by concatenating the interface identifier received in step 3, or a locally generated interface identifier, and the prefix received in the Router Advertisement. If the Router Advertisement contains more than one prefix option, the MS shall only consider the first one and silently discard the others.
Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the prefix (i.e. site-local or global), there is no need for the MS to perform Duplicate Address Detection for this IPv6 address. Therefore, the GGSN shall silently discard Neighbor Solicitation messages that the MS may send to perform Duplicate Address Detection. It is possible for the MS to perform Neighbor Unreachability Detection towards the GGSN, as defined in RFC 4861; therefore if the GGSN receives a Neighbor Solicitation as part of this procedure, the GGSN shall provide a Neighbor Advertisement as described in RFC 4862.
Optionally, a single network prefix shorter than the default /64 prefix may be assigned to a PDN connection. In this case, the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining address space from the network prefix can be delegated to the PDN connection using prefix delegation after the PDP context activation and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in clause 220.127.116.11. When PLMN based parameter configuration is used, the GGSN provides the requested IPv6 prefix from a locally provisioned pool. When external PDN based IPv6 prefix allocation is used, the GGSN obtains the prefix from the external PDN.
The address space provided is maintained as an IPv6 address space pool available to the PDN connection for DHCPv6 IPv6 prefix requests with the exclusion of the IPv6 prefix that is allocated to the PDP context during PDP context activation as defined in clause 18.104.22.168. The total IPv6 address space available for the PDP connection (the /64 default prefix and the remaining IPv6 address space pool) shall be possible to aggregate into one IPv6 prefix that will represent all IPv6 addresses that the MS may use. If the MS had indicated that it supports prefix exclusion and the prefix to be delegated to the UE includes the /64 prefix that was allocated to the PDN Connection, the GGSN shall utilise the prefix exclusion feature as specified for DHCPv6 Prefix Delegation in RFC 6603.
The MS uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the GGSN after completing stateless IPv6 address autoconfiguration procedures. The MS acts as a "Requesting Router" as described in RFC 3633 and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent from the MS to the GGSN. The GGSN acts as the DHCP server and fulfils the role of a "Delegating Router" according to RFC 3633. The MS optionally includes the RAPID_COMMIT option in the DHCPv6 Solicit message to trigger two-message DHCPv6 procedure instead of the four-message DHCPv6 procedure. The MS shall include OPTION_PD_EXCLUDE option code in an OPTION_ORO option to indicate support for prefix exclusion. In response to the DHCPv6 Solicit message, the MS receives a DHCPv6 Reply message with one or more IA_PD prefix(es) for every IA_PD option that it sent in the DHCPv6 Solicit message. The GGSN delegates a prefix excluding the default prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow RFC 6603.