5 Wireless LAN control plane protocol Procedures

24.2443GPPRelease 17Stage 3TSWireless LAN control plane protocol for trusted WLAN access to EPC

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 General

5.1.1 Overview

This clause describes principles and procedures used for Wireless LAN control plane protocol for PDN connectivity handling in the UE and in the TWAG.

Re-transmission of WLCP messages for ensuring reliability of WLCP procedures is supervised by timers.

5.1.2 Services provided by lower layers

Unless explicitly stated otherwise, WLCP procedures can be performed only if the UE has been authenticated and has successfully negotiated the multi-connection mode for trusted WLAN access as specified in 3GPP TS 24.302 [3].

5.1.3 Principles of address handling for WLCP procedures

WLCP procedures use the PTI as address parameter in the WLCP message header. When the UE or the TWAG initiates a WLCP procedure, it shall include a valid PTI value in the message header (see subclause 8.3).

In the response message, the sending entity shall include the PTI value received with the request message.

Figure 5.1.3.1: Procedure initiated by the UE

Figure 5.1.3.2: Procedure initiated by the TWAG

5.1.4 Abnormal cases in the UE

No abnormal cases have been identified.

5.1.5 Abnormal cases in the TWAG

The following abnormal cases can be identified:

a) Failure of EAP-AKA’ re-authentication:

When the TWAG receives a failure indication of the re-authentication procedure, the TWAG shall initiate TWAG-initiated PDN disconnection procedure.

5.1.6 Handling of APN based congestion control

As specified in subclause 5.2.4, TWAG can reject PDN connection request for an APN from a UE and provide a Tw1 timer value to the UE.

5.2 PDN connectivity establishment procedure

5.2.1 General

The purpose of the PDN connectivity establishment procedure is to establish PDN connectivity between the UE and the EPC. The procedure is used either to establish the first PDN connection or to establish subsequent PDN connections. When multiple bearer PDN connectivity model is used, the default WLCP bearer is also established. The procedure can be initiated only after successful EAP authentication and authorization has been completed and multi-connection mode of operation has been negotiated, as specified in 3GPP TS 24.302 [3].

The UE and the TWAG may include a Protocol configuration options IE in PDN connectivity establishment procedure if they wish to exchange (protocol) data (e.g. configuration parameters, error codes or messages/events).

If there is already a PDN connection for emergency bearer services established, the UE shall not request another PDN connection for emergency services.

If the UE attached for emergency services, i.e.received an MCM_RESPONSE with the AT_NOTIFICATION attribute indicating success for an MCM_REQUEST with ATTACHMENT_TYPE item set to "emergency attach" or "emergency handover" as specified in 3GPP TS 24.302 [3]:

– the UE shall establish the first PDN connection for emergency services or perform handover of an emergency PDN connection from 3GPP access; and

– the UE shall not request any additional non-emergency PDN connections so long as the UE is attached for emergency services.

5.2.2 PDN connectivity establishment procedure initiation

The UE requests PDN connectivity establishment by sending a PDN CONNECTIVITY REQUEST message to the TWAG.

In order to request connectivity to a PDN using the default APN, the UE includes the Access point name IE in the PDN CONNECTIVITY REQUEST message according to the following conditions:

– if use of a PDN using the default APN requires PAP/CHAP, then the UE should include the Access point name IE; and

– in all other conditions, the UE need not include the Access point name IE.

In order to request connectivity to a non-default APN or to an additional PDN, the UE shall send a PDN CONNECTIVITY REQUEST message to the TWAG including the requested APN.

After sending the PDN CONNECTIVITY REQUEST message the UE shall start timer T3582 and enter the state PROCEDURE TRANSACTION PENDING (see example in figure 5.2.2.1).

Figure 5.2.2.1: PDN connectivity establishment procedure

The UE shall set the PDN type IE in the PDN CONNECTIVITY REQUEST message to IPv4 if:

– the UE is only IPv4 capable;

– the UE is both IPv4 and IPv6 capable, has been allocated an IPv6 address for this APN and received the ESM cause #52 "single address bearers only allowed" and the request type is "initial request" or "emergency"; or

– the UE is both IPv4 and IPv6 capable, has been allocated an IPv4 address for this APN, received the ESM cause #52 "single address bearers only allowed" and the request type is "handover" or "handover of emergency bearer services", and has not been allocated an IPv6 address for this APN.

The UE shall set the PDN type IE in the PDN CONNECTIVITY REQUEST message to IPv6 if:

– the UE is only IPv6 capable;

– the UE is both IPv4 and IPv6 capable, has been allocated an IPv4 address for this APN and received the ESM cause #52 "single address bearers only allowed" and the request type is "initial request" or "emergency"; or

– the UE is both IPv4 and IPv6 capable, has been allocated an IPv6 address for this APN, received the ESM cause #52 "single address bearers only allowed" and the request type is "handover" or "handover of emergency bearer services", and has not been allocated an IPv4 address for this APN.

The UE shall set the PDN type IE in the PDN CONNECTIVITY REQUEST message to IPv4v6 if:

– the UE is both IPv4 and IPv6 capable and has not been allocated an IP address for this APN and the request type is "initial request" or "emergency";

– the UE capability is unknown in the UE (as in the case when the MT and TE are separated and the capability of the TE is not known in the MT); or

– the UE is both IPv4 and IPv6 capable, has been allocated both IPv4 address and an IPv6 address for this APN and the request type is "handover" or "handover of emergency bearer services".

The UE shall not set the PDN type IE to PDN type value other than IPv4, IPv6 and IPv4v6.

The UE shall set the request type to "initial request" when the UE is establishing a new PDN connectivity. The UE shall set the request type to "handover" when the connectivity to a PDN is to be transferred from a 3GPP access network to the trusted WLAN access network. The UE shall set the request type to "emergency" when the UE is requesting a new PDN connection for emergency bearer services. The UE shall set the request type to "handover of emergency bearer services" when a PDN connection for emergency bearer services is to be transferred from a 3GPP access network to the trusted WLAN access network.

If the UE supports multiple WLCP bearers as specified in 3GPP TS 23.402 [2], the UE shall set the multiple bearer capability indicator bit to "Multiple WLCP bearers supported" in the UE N3G capability IE in the PDN CONNECTIVITY REQUEST message.

5.2.3 PDN connectivity establishment procedure accepted by the TWAG

Upon receipt of the PDN CONNECTIVITY REQUEST message, the TWAG checks if connectivity with the requested PDN can be established. If no requested APN is included in the PDN CONNECTIVITY REQUEST message and the request type is different from "emergency" and from "handover of emergency bearer services", the TWAG shall use the default APN as the requested APN. If the request type is "emergency" or "handover of emergency bearer services", the TWAG uses the APN configured for emergency bearer services or selects the statically configured PDN GW for unauthenticated UEs, if applicable.

If the requested PDN connection can be established, the TWAG shall send a PDN CONNECTIVITY ACCEPT message towards the UE. The TWAG shall retrieve the PTI from the PDN CONNECTIVITY REQUEST message and include it in the PDN CONNECTIVITY ACCEPT message. If the request type is different from "emergency" and from "handover of emergency bearer services", both the network identifier part and the operator identifier part shall be included in the Access Point Name IE. Additionally, the TWAG shall include:

– PDN connection ID to identify the PDN connection between the UE and the TWAG;

– MAC address of the TWAG to the UE. This MAC address is used by the UE and the TWAG to send the user plane packets for this PDN connection; and

– Default WLCP bearer identity if multiple WLCP bearers are used. This default WLCP bearer identity shall be allocated by the TWAG and associated with the default bearer of the PDN connection.

If connectivity with the requested PDN is accepted, but with a restriction of IP version (i.e. both an IPv4 address and an IPv6 prefix is requested, but only one particular IP version, or only single IP version bearers are supported/allowed by the network), cause #50 "PDN type IPv4 only allowed", #51 "PDN type IPv6 only allowed" ", or #52 "single address bearers only allowed", respectively, shall be included in the PDN CONNECTIVITY ACCEPT message. Upon sending the message the TWAG shall enter the state PDN CONNECTIVITY PENDING and PROCEDURE TRANSACTION PENDING and start the timer T3585.

If the UE requested PDN type IPv4v6, but the PDN GW configuration or UE subscription dictates the use of IPv4 only or IPv6 only for this APN, the network shall override the PDN type requested by the UE to limit it to a single address PDN type (IPv4 or IPv6). In the PDN CONNECTIVITY ACCEPT message the TWAG shall set the PDN type IE to either "IPv4" or "IPv6" and the ESM cause value to #50 "PDN type IPv4 only allowed", or #51 "PDN type IPv6 only allowed", respectively. The UE shall not subsequently initiate another UE requested PDN connectivity procedure to the same APN to obtain a PDN type different from the one allowed by the network until:

– a new EAP Authentication procedure is performed (e.g. a new WLAN is selected);

– the PDN type which is used to access to the APN is changed;

– the UE is switched off; or

– the USIM is removed.

If the UE requested PDN type IPv4v6, but the operator uses single addressing per bearer, e.g. due to interworking with nodes of earlier releases, the network shall override the PDN type requested by the UE to a single IP version only. In the PDN CONNECTIVITY ACCEPT message sent to the UE, the TWAG shall set the PDN type IE to either "IPv4" or "IPv6" and the ESM cause value to #52 "single address bearers only allowed". The UE should subsequently request another PDN connection for the other IP version using the PDN connectivity establishment procedure to the same APN with a single address PDN type (IPv4 or IPv6) other than the one already activated.

The TWAG shall set the value of the IP Address IE in the PDN CONNECTIVITY ACCEPT message as follows:

– If the PDN type IE in the PDN CONNECTIVITY ACCEPT message is set to IPv4 or IPv4v6, the PDN Address IE shall contain an IPv4 address for the UE; and

– If the PDN type IE in the PDN CONNECTIVITY ACCEPT message is set to IPv6 or IPv4v6, the PDN Address IE shall contain an IPv6 interface identifier.

Upon receipt of the PDN CONNECTIVITY ACCEPT message, the UE shall check the PTI to identify the UE requested PDN connectivity, stop timer T3582 and enter the state PROCEDURE TRANSACTION INACTIVE. The UE should ensure that the PTI assigned to this procedure is not released immediately. The way to achieve this is implementation dependent. While the PTI value is not released, the UE regards any received PDN CONNECTIVITY ACCEPT message with the same PTI value as a network retransmission.

If the UE receives an IPv6 interface identifier in the PDN CONNECTIVITY ACCEPT message, the UE may wait for the Router Advertisement from the network with the IPv6 prefix information or it may send a Router Solicitation if necessary.

5.2.3.1 PDN connectivity establishment accepted by the UE

If the UE accepts the PDN connection the UE shall send a PDN CONNECTIVITY COMPLETE message and enter the state PDN CONNECTION ESTABLISHED.

Upon receipt of the PDN CONNECTIVITY COMPLETE message, the TWAG shall enter the state PDN CONNECTION ESTABLISHED and stop the timer T3585, if the timer is running (see example in figure 5.2.2.1).

5.2.3.2 PDN connectivity establishment not accepted by the UE

If the UE does not accept the PDN connection the UE shall send a PDN CONNECTIVITY REJECT message and enter the state PDN CONNECTIVITY NOT ESTABLISHED.

The PDN CONNECTIVITY REJECT message contains a cause that typically indicates one of the following cause values:

#31: request rejected, unspecified; or

#95 – 111: protocol errors.

Upon receipt of the PDN CONNECTIVITY REJECT message, the TWAG shall enter the state PDN CONNECTIVITY NOT ESTABLISHED and PROCEDURE TRANSACTION INACTIVE and stop the timer T3585, if the timer is running (see example in figure 5.2.2.1).

5.2.4 PDN connectivity procedure not accepted by the TWAG

If connectivity with the requested PDN cannot be accepted by the network, the TWAG shall send a PDN CONNECTIVITY REJECT message to the UE (see example in figure 5.2.4.1). The message shall contain the PTI and a cause value indicating the reason for rejecting the UE-requested PDN connectivity.

Figure 5.2.4.1: PDN connectivity establishment procedure not accepted by TWAG

The cause IE typically indicates one of the following cause values:

#8: operator determined barring;

#26: insufficient resources;

#27: missing or unknown APN;

#28: unknown PDN type;

#29: user authentication failed;

#30: request rejected by PDN GW;

#31: request rejected, unspecified;

#32: service option not supported;

#33: requested service option not subscribed;

#34: service option temporarily out of order;

#35: PTI already in use;

#38: network failure;

#50: PDN type IPv4 only allowed;

#51: PDN type IPv6 only allowed;

#52: single address bearers only allowed;

#54: PDN connection does not exist;

#55: multiple PDN connections for a given APN not allowed;

#95 – 111: protocol errors;

#113: Multiple accesses to a PDN connection not allowed;

If the PDN type IE in the PDN CONNECTIVITY REQUEST message is set to a PDN type value other than IPv4, IPv6 and IPv4v6, the TWAG shall set the cause IE to #95 "semantically incorrect message".

If the cause value is #26 "insufficient resources", and the request type is different from "emergency" and from "handover of emergency bearer services", the network may include a value for timer Tw1 in the PDN CONNECTIVITY REJECT message. If the request type is "emergency" or "handover of emergency bearer services", the network shall not include the timer Tw1 in the PDN CONNECTIVITY REJECT message.

Upon receipt of the PDN CONNECTIVITY REJECT message, the UE shall stop timer T3582 and enter the state PROCEDURE TRANSACTION INACTIVE.

If the cause value is #26 "insufficient resources" and the Tw1 value IE is included, the UE shall take different actions depending on the timer value received for timer Tw1:

i) if the timer value indicates neither zero nor deactivated, the UE shall stop timer Tw1 associated with the corresponding APN, if it is running. The UE shall start timer Tw1 with the value provided in the Tw1 value IE and not send another PDN CONNECTIVITY REQUEST message for the same APN until timer Tw1 expires, the timer Tw1 is stopped or the USIM is removed;

ii) if the timer value indicates that this timer is deactivated, the UE shall not send another PDN CONNECTIVITY REQUEST message for the same APN until the UE is switched off or the USIM is removed; and

iii) if the timer value indicates zero, the UE may send another PDN CONNECTIVITY REQUEST message for the same APN;

iv) if the WLAN radio is disabled when the timer Tw1 is running and if the USIM in the UE remains the same when the WLAN radio is enabled, the UE shall behave as follows when the WLAN radio is enabled:

– let t1 be the time remaining for Tw1 timeout when the WLAN radio was disabled and let t be the time elapsed since the WLAN radio was disabled until the WLAN radio was enabled. If t1 is greater than t, then the timer shall be restarted with the value t1 – t. If t1 is equal to or less than t, then the timer need not be restarted. If the UE is not capable of determining t, then the UE shall restart the timer with the value t1.

If the cause value is #26 "insufficient resources" and the Tw1 IE is not included, the UE may send a PDN CONNECTIVITY REQUEST message for the same APN.

5.2.5 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiry of timer T3582:

– On the first expiry of the timer T3582, the UE shall resend the PDN CONNECTIVITY REQUEST and shall reset and restart timer T3582. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3582, the UE shall abort the procedure, release the PTI allocated for this invocation and enter the state PROCEDURE TRANSACTION INACTIVE;

5.2.6 Abnormal cases on the network side

The following abnormal cases can be identified:

a) UE initiated PDN connectivity request for an already existing PDN connection:

If the network receives a PDN CONNECTIVITY REQUEST message with the same combination of APN and PDN type as an already existing PDN connection:

– if the information elements in the PDN CONNECTIVITY REQUEST message do not differ from the ones received within the previous PDN CONNECTIVITY REQUEST message, and the TWAG has not received the PDN CONNECTIVITY COMPLETE message from UE, the TWAG shall re-send the PDN CONNECTIVITY ACCEPT message and continue the previous procedure; and

– if one or more information elements in the PDN CONNECTIVITY REQUEST message differ from the ones received within the previous PDN CONNECTIVITY REQUEST message, and multiple PDN connections for a given APN are not allowed, the network may release the existing PDN connection locally without notification to the UE and proceed with the requested PDN connectivity procedure or may reject this PDN connectivity procedure including the cause #55 "multiple PDN connections for a given APN not allowed", in the PDN CONNECTIVITY REJECT message; and

If the network receives a PDN CONNECTIVITY REQUEST message with request type "emergency" and the TWAG has not received the PDN CONNECTIVITY COMPLETE message from UE for the previous PDN connectivity request for emergency bearer services, the network shall resend the PDN CONNECTIVITY ACCEPT message and continue the previous procedure. If there is already a PDN connection for emergency bearer services existing, the TWAG shall reject the request with ESM cause #55 "multiple PDN connections for a given APN not allowed" or deactivate the existing PDN connection for emergency bearer services locally without notification to the UE and proceed with the requested PDN connectivity procedure.

b) UE initiated PDN connectivity request with request type "handover" for a PDN connection that does not exist:

If the network receives a PDN CONNECTIVITY REQUEST message for either a default APN or a specific APN with request type set to "handover" and the TWAG does not have any information about that PDN connection, then TWAG shall reject the PDN connectivity request procedure including the cause #54 "PDN connection does not exist", in the PDN CONNECTIVITY REJECT message.

c) Expiry of timer T3585:

On the first expiry of the timer T3585, the TWAG shall resend the PDN CONNECTIVITY ACCEPT message, reset and restart timer T3585. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3585, the TWAG shall release possibly allocated resources for this activation and shall abort the procedure.

d) A PDN CONNECTIVITY REQUEST message with request type "handover of emergency bearer services" is received from a UE and the TWAG does not have any information about a P-GW currently providing emergency bearer services for the UE or the TWAG is not configured with an address of a P-GW in the TWAG emergency configuration data:

TWAG shall reject the PDN connectivity request procedure including the ESM cause #54 "PDN connection does not exist", in the PDN CONNECTIVITY REJECT message.

5.3 TWAG initiated PDN disconnection procedure

5.3.1 General

The purpose of the PDN disconnection procedure is to disconnect the UE from a PDN. With this procedure, all resources associated with this PDN connection are released.

5.3.2 Procedure description

The TWAG shall initiate the PDN disconnection procedure by sending a PDN DISCONNECT REQUEST message to the UE, start the timer T3595, and enter the state PDN DISCONNECT PENDING and PROCEDURE TRANSACTION PENDING (see example in figure 5.3.2.1). The PDN DISCONNECT REQUEST message contains a cause typically indicating one of the following:

#8: operator determined barring;

#36: regular deactivation;

#38: network failure; or

#39: reactivation requested.

The TWAG may include a PCO IE in the PDN DISCONNECT REQUEST message (e.g. configuration parameters, error codes or messages/events).

If the UE is not authenticated when the TWAG initiates the PDN disconnection procedure, the TWAG shall locally disconnect the PDN connection towards the UE without any WLCP signalling between the TWAG and the UE.

Figure 5.3.2.1: PDN disconnect procedure

Upon receipt of the PDN DISCONNECT REQUEST message, the UE shall release all the resources associated with the PDN connection and respond to the TWAG with the PDN DISCONNECT ACCEPT.

Upon sending the PDN DISCONNECT ACCEPT message, the UE shall enter the state PDN CONNECTIVITY NOT ESTABLISHED.

If the PDN DISCONNECT REQUEST message includes cause #39 "reactivation requested" the UE should stop timer Tw1 if it is running for the APN associated with the PDN connection and re-initiate the PDN connectivity procedure for the same APN as the disconnected PDN.

NOTE: User interaction may be necessary in some cases when the UE cannot re-activate the PDN connection automatically.

Upon receipt of the PDN DISCONNECT ACCEPT message, the TWAG shall enter the states PDN CONNECTIVITY NOT ESTABLISHED and PROCEDURE TRANSACTION INACTIVE and stop the timer T3595.

5.3.3 Abnormal cases in the UE

Apart from the case described in subclause 5.1.3, no abnormal cases have been identified.

5.3.4 Abnormal cases in the TWAG

The following abnormal cases can be identified:

a) Expiry of timer T3595:

On the first expiry of the timer T3595, the TWAG shall resend the PDN DISCONNECT REQUEST message and shall reset and restart timer T3595. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3595, the TWAG shall abort the procedure and deactivate the PDN connection locally without any peer-to-peer WLCP signalling between the TWAG and the UE; and

b) Collision of UE-initiated and TWAG-initiated PDN disconnection procedure:

When the TWAG receives a PDN DISCONNECT REQUEST message during the TWAG-initiated PDN disconnection procedure the TWAG shall proceed with the PDN disconnection procedure.

5.4 UE requested PDN disconnection procedure

5.4.1 General

The purpose of the UE requested PDN disconnection procedure is for a UE to request disconnection from one PDN. With this procedure, all resources associated with this PDN connection are released.

5.4.2 Procedure description

In order to request PDN disconnection from a PDN, the UE shall send a PDN DISCONNECT REQUEST message to the TWAG, start the timer T3592 and enter the state PROCEDURE TRANSACTION PENDING (see example in figure 5.4.2.1).

Figure 5.4.2.1: UE requested PDN disconnection procedure

Upon receipt of the PDN DISCONNECT REQUEST message, the TWAG shall release all the resources associated with the PDN connection and respond to the UE with the PDN DISCONNECT ACCEPT message.

Upon receipt of the PDN DISCONNECT ACCEPT message, the UE shall stop the timer T3592, deactivate all resources associated with this PDN connection and enter the states PROCEDURE TRANSACTION INACTIVE and PDN CONNECTIVITY NOT ESTABLISHED.

If the PDN DISCONNECT REQUEST message is not accepted by the network, the TWAG shall send a PDN DISCONNECT REJECT message to the UE. The PDN DISCONNECT REJECT message shall contain the PTI and a cause IE that typically indicates one of the following cause values:

#35: PTI already in use; and

#95 – 111: protocol errors.

Upon receipt of the PDN DISCONNECT REJECT message, the UE shall stop the timer T3592, enter the state PROCEDURE TRANSACTION INACTIVE and abort the PDN disconnection procedure. Additionally, the UE shall deactivate all resources associated with this PDN connection locally without peer-to-peer signalling between the UE and the TWAG and enter the state PDN CONNECTIVITY NOT ESTABLISHED.

5.4.3 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiry of timer T3592:

On the first expiry of the timer T3592, the UE shall resend the PDN DISCONNECT REQUEST and shall reset and restart timer T3592. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3592, the UE shall abort the procedure, release all resources associated with this PDN connection locally without peer-to-peer signalling between the UE and the TWAG, release the PTI allocated for this invocation and enter the state PROCEDURE TRANSACTION INACTIVE.

5.4.4 Abnormal cases in the TWAG

The following abnormal cases can be identified:

a) No PDN connection with the same PTI:

If the PTI included in the PDN DISCONNECT REQUEST message does not belong to an established PDN connection, the TWAG shall reply with a PDN DISCONNECT REJECT message with cause #54 "PDN connection does not exist";

5.5 STATUS message

The purpose of the sending of the STATUS message is to report at any time certain error conditions detected upon receipt of WLCP protocol data. The STATUS message can be sent by both the TWAG and the UE (see example in figure 5.5.1).

If the WLCP entity of the UE receives a STATUS message the UE shall take different actions depending on the received cause value:

#81 (Invalid PTI value);

The UE shall abort any ongoing WLCP procedure related to the received PTI value and stop any related timer.

#97 (Message type non-existent or not implemented);

The UE shall abort any ongoing WLCP procedure related to the PTI and stop any related timer.

On receipt of a STATUS message with any other cause value no state transition and no specific action shall be taken as seen from the WLAN radio interface, i.e. local actions are possible.

If the WLCP entity of the TWAG receives a STATUS message the TWAG shall take different actions depending on the received cause value:

#81 (Invalid PTI value);

The TWAG shall abort any ongoing WLCP procedure related to the received PTI value and stop any related timer.

#97 (Message type non-existent or not implemented);

The TWAG shall abort any ongoing WLCP procedure related to the PTI and stop any related timer.

The local actions to be taken by the TWAG on receipt of an STATUS message with any other cause value are implementation dependent.

Figure 5.5.1: STATUS message

5.6 TWAG initiated PDN connectivity modification procedure

5.6.1 General

The purpose of the TWAG initiated PDN connectivity modification procedure is for the network to modify the protocol data of the PDN connection (e.g. PCO, routing rule). If this procedure was initiated by a UE requested PDN connectivity modification procedure (see subclause 5.7), the PDN MODIFICATION REQUEST shall contain the procedure transaction identity (PTI) value received by the TWAG in the PDN MODIFICATION INDICATION message.

5.6.2 Procedure description

The TWAG shall initiate the PDN connectivity modification procedure by sending a PDN MODIFICATION REQUEST message to the UE, starting the timer T3586 and enter the state PROCEDURE TRANSACTION PENDING (see example in figure 5.6.2.1).

Figure 5.6.2.1: TWAG-initiated PDN connectivity modification procedure

5.6.3 PDN connectivity modification procedure accepted by the UE

Upon receipt of the PDN MODIFICATION REQUEST message, the UE may accept the request from the TWAG by sending a PDN MODIFICATION ACCEPT message to the TWAG. Upon receipt of the PDN MODIFICATION ACCEPT message, the TWAG shall stop the timer T3586.

5.6.4 PDN connectivity modification procedure not accepted by the UE

Upon receipt of the PDN MODIFICATION REQUEST message, the UE may reject the request from the TWAG by sending a PDN MODIFICATION REJECT message to the TWAG.

The PDN MODIFICATION REJECT message contains a cause that typically indicates one of the following cause values:

#31: request rejected, unspecified; or

#95 – 111: protocol errors.

5.6.5 Abnormal cases in the UE

Apart from the case described in subclause 5.1.3, no abnormal cases have been identified.

5.6.6 Abnormal cases in the TWAG

The following abnormal cases can be identified:

a) Expiry of timer T3586:

On the first expiry of the timer T3586, the TWAG shall resend the PDN MODIFICATION REQUEST and shall reset and restart timer T3586. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3586, the TWAG shall abort the procedure and enter the state PDN CONNECTION ESTABLISHED.

The TWAG may continue to use the previous configuration of the PDN connectivity or initiate PDN disconnection procedure.

b) Collision of TWAG initiated PDN connectivity modification procedure and UE requested PDN disconnection procedure:

When the TWAG receives a PDN DISCONNECT REQUEST message during a TWAG initiated PDN connectivity modification procedure, the TWAG shall terminate the PDN connectivity modification procedure locally and proceed with the PDN disconnect procedure.

5.7 UE requested PDN connectivity modification procedure

5.7.1 General

The purpose of the UE requested PDN connectivity modification procedure is for the UE to request the network to modify the protocol data of the PDN connection (e.g. PCO, routing rule). If accepted by the network, this procedure invokes a TWAG initiated PDN connectivity modification procedure (see subclause 5.6).

5.7.2 Procedure description

In order to request the network to initiate PDN connectivity modification procedure, the UE shall send a PDN MODIFICATION INDICATION message to the TWAG, start timer T3586 and enter the state PDN MODIFICATION PENDING (see example in figure 5.7.2.1).

Figure 5.7.2.1: UErequested PDN connectivity modification procedure

5.7.3 PDN connectivity modification procedure accepted by the network

Upon receipt of the PDN MODIFICATION REQUEST message, the UE shall stop the timer T3586.

5.7.4 PDN connectivity modification procedure not accepted by the network

Upon receipt of the PDN MODIFICATION INDICATION message, the network may reject the request from the UE by sending a PDN MODIFICATION REJECT message to the UE.

The PDN MODIFICATION REJECT message contains a cause that typically indicates one of the following cause values:

#31: request rejected, unspecified; or

#95 – 111: protocol errors.

5.7.5 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiry of timer T3586:

On the first expiry of the timer T3586, the UE shall resend the PDN MODIFICATION INDICATION and shall reset and restart timer T3586. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3586, the UE shall abort the procedure, release the PTI allocated for this activation and enter the state PROCEDURE TRANSACTION INACTIVE.

b) Unknown PDN connection ID

Upon receipt of the PDN MODIFICATION REJECT message including ESM cause #43 "invalid EPS bearer identity", the UE shall release the existing PDN connection locally without peer-to-peer signalling between the UE and the TWAG.

c) Collision of a UE requested PDN connectivity modification procedure and a TWAG initiated PDN disconnection procedure.

When the UE receives a PDN DISCONNECT REQUEST message during the PDN connectivity modification procedure, and the PDN connection ID indicated in the PDN DISCONNECT REQUEST message is the PDN connection ID the UE indicated in the UE requested PDN connectivity modification procedure, then the UE shall abort the UE requested PDN connectivity modification procedure and proceed with the PDN disconnection procedure.

5.7.6 Abnormal cases in the TWAG

Apart from the case described in subclause 5.1.3, no abnormal cases have been identified.

5.8 PGW initiated local PDN disconnection in the TWAG

5.8.1 General

A PDN connection over trusted WLAN can be released locally in the TWAG, i.e. without any peer-to-peer signalling between the TWAG and the UE, based on the trigger from the PGW. This can happen, for example, during the P-CSCF restoration procedure for NBIFOM PDN connections (see 3GPP TS 23.380 [11]).

5.8.2 Procedure description

Upon receiving a request from PGW to release a PDN connection with cause "local release" (see 3GPP TS 29.274 [12]) the TWAG shall:

– release all resources associated with this PDN connection over WLAN; and

– not initiate any peer-to-peer WLCP signalling to the UE.

5.9 Local PDN disconnection in the UE initiated from 3GPP access

5.9.1 General

A PDN connection over trusted WLAN can be released locally in the UE, i.e. without any peer-to-peer signalling between the TWAG and the UE, based on the trigger received via 3GPP access. This can happen, for example, during the P-CSCF restoration procedure for NBIFOM PDN connections (see 3GPP TS 23.380 [11]).

5.9.2 Procedure description

Upon receiving over the 3GPP access:

– a DEACTIVATE EPS BEARER CONTEXT REQUEST message with the EPS bearer context of a default EPS bearer context and ESM cause #39 "reactivation requested" (see 3GPP TS 24.301 [8]); or

– a DETACH REQUEST message with the detach type "re-attach required" (see 3GPP TS 24.301 [8])

to release the resources for a PDN connection over the 3GPP access, the UE shall:

– release all resources associated with this PDN connection over WLAN; and

– not initiate any peer-to-peer WLCP signalling to the TWAG.

5.10 WLCP bearer setup procedure

5.10.1 General

The purpose of the WLCP bearer setup procedure is to establish a dedicated WLCP bearer with specific bearer level QoS and TFT between the UE and the TWAN. The WLCP bearer setup procedure is initiated by the TWAG if:

– the UE is connected to a trusted WLAN using the multi-connection mode (MCM);

– the TWAG receives from the PDN GW a Create Bearer Request message that includes TFT and S2a bearer level QoS parameters; and

– both the UE and TWAG support multiple bearer PDN connectivity and default WLCP bearer identity has been assigned during PDN connection establishment.

5.10.2 Procedure description

5.10.2.1 WLCP bearer setup procedure initiated by the TWAG

The TWAG shall initiate the WLCP bearer setup procedure by sending a WLCP BEARER SETUP REQUEST message to the UE, start the timer T3587, and enter the state WLCP BEARER CONTEXT ACTIVE PENDING (see figure 5.10.2.1.1).

In the WLCP BEARER SETUP REQUEST message, the TWAG shall include:

– WLCP bearer identity to identify the WLCP bearer to be created;

– PDN connection ID to indicate the associated PDN connection for which the WLCP bearer is to be created;

– MAC address of the TWAG to the UE associated with the WLCP bearer to be created. This MAC address is used by the UE and the TWAG to send the user plane packets to the corresponding WLCP bearer; and

– Bearer level QoS and TFT.

Figure 5.10.2.1.1: WLCP bearer setup procedure

5.10.2.2 WLCP bearer setup procedure accepted by the UE

Upon receipt of the WLCP BEARER SETUP REQUEST message, the UE shall check the received TFT before taking it into use, send a WLCP BEARER SETUP ACCEPT message and enter the state WLCP BEARER CONTEXT ACTIVE. The WLCP BEARER SETUP ACCEPT message shall include the WLCP bearer identity. The UE shall use the received TFT to apply mapping of uplink traffic flows to the WLCP bearer and shall treat any packet filter without explicit direction as being bi-directional.

Upon receipt of the WLCP BEARER SETUP ACCEPT message, the TWAG shall stop the timer T3587 and enter the state WLCP BEARER CONTEXT ACTIVE.

5.10.2.3 WLCP bearer setup procedure not accepted by the UE

Upon receipt of the WLCP BEARER SETUP REQUEST message, the UE may reject the request from the TWAG by sending a WLCP BEARER SETUP REJECT message. The UE shall include the WLCP bearer identity and a cause IE indicating the reason for rejection in the WLCP BEARER SETUP REJECT message.

The cause typically indicates one of the following cause values:

#26: insufficient resources;

#31: request rejected, unspecified;

#41: semantic error in the TFT operation;

#42: syntactical error in the TFT operation;

#43: invalid EPS bearer identity;

#44: semantic error(s) in packet filter(s);

#45: syntactical error(s) in packet filter(s); or

#95 – 111: protocol errors.

The UE shall check the TFT in the WLCP BEARER SETUP REQUEST request message for different types of TFT IE errors as follows:

a) Semantic errors in TFT operations:

1) When the TFT operation is an operation other than "Create a new TFT"

The UE shall reject the request with cause #41 "semantic error in the TFT operation".

b) Syntactical errors in TFT operations:

1) When the TFT operation = "Create a new TFT" and the packet filter list in the TFT IE is empty.

2) When there are other types of syntactical errors in the coding of the TFT IE, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list.

The UE shall reject the request with cause #42 "syntactical error in the TFT operation".

c) Semantic errors in packet filters:

1) When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the UE determines a semantic error in a packet filter is outside the scope of the present document.

2) When the resulting TFT does not contain any packet filter for the uplink direction.

The UE shall reject the request with cause #44 "semantic errors in packet filter(s)".

d) Syntactical errors in packet filters:

1) When the TFT operation = "Create a new TFT" and two or more packet filters in the resultant TFT would have identical packet filter identifiers.

2) When the TFT operation = "Create a new TFT" and two or more packet filters in all TFTs associated with this WLCP connection would have identical packet filter precedence values.

3) When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.

In cases 1 and 3 the UE shall reject the request with cause #45 "syntactical errors in packet filter(s)".

In case 2, if the old packet filters do not belong to the default WLCP bearer context, the UE shall not diagnose an error, shall further process the request and, if it was processed successfully, shall delete the old packet filters which have identical filter precedence values.

In case 2, if one or more old packet filters belong to the default WLCP bearer context, the UE shall release the relevant WLCP connection.

Upon receipt of the WLCP BEARER SETUP REJECT message in state WLCP BEARER CONTEXT ACTIVE PENDING, the TWAG shall abort the WLCP bearer setup procedure, stop the timer T3587, if the timer is running, and enter the state WLCP BEARER CONTEXT INACTIVE.

5.10.3 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Requested PDN connection ID non-existent

If the requested PDN connection ID included in the WLCP BEARER SETUP REQUEST message is non-existent, the UE shall reply with a WLCP BEARER SETUP REJECT message with cause #54 "PDN connection does not exist".

b) WLCP bearer setup request for an already activated default WLCP bearer

If the UE receives a WLCP BEARER SETUP REQUEST message with a WLCP bearer identity identical to the WLCP bearer identity of an already activated default WLCP bearer, the UE shall delete the existing default WLCP bearer and all the associated dedicated WLCP bearers, if any, and proceed with the requested dedicated WLCP bearer setup

c) WLCP bearer setup request for an already activated dedicated WLCP bearer

If the UE receives a WLCP BEARER SETUP REQUEST message with a WLCP bearer identity identical to the WLCP bearer identity of an already activated dedicated WLCP bearer, the UE shall locally release the existing dedicated WLCP bearer context and proceed with the requested dedicated WLCP bearer setup.

5.10.4 Abnormal cases in the TWAG

The following abnormal cases can be identified:

a) Expiry of timer T3587:

On the first expiry of the timer T3587, the TWAG shall resend the WLCP BEARER SETUP REQUEST and shall reset and restart timer T3587. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3587, the TWAG shall abort the procedure, release any resources allocated for this activation and enter the state WLCP BEARER CONTEXT INACTIVE.

b) Collision of UE requested PDN disconnection procedure and WLCP bearer setup procedure:

When the TWAG receives a PDN DISCONNECT REQUEST message during the WLCP bearer setup procedure, and the WLCP bearer to be setup belongs to the PDN connection the UE wants to disconnect, the TWAG shall terminate the WLCP bearer setup procedure locally, release any resources related to this procedure and proceed with the PDN disconnection procedure.

5.11 WLCP bearer modify procedure

5.11.1 General

The purpose of the WLCP bearer modify procedure is to modify a dedicated WLCP bearer context between the UE and the TWAN. The WLCP bearer modify procedure is initiated by the TWAG if:

– the UE is connected to a trusted WLAN using the multi-connection mode (MCM);

– the TWAG receives from the PDN GW a Update Bearer Request message that includes TFT and updated S2a bearer level QoS parameters; and

– both the UE and TWAG support multiple bearer PDN connectivity and default WLCP bearer identity has been assigned during PDN connection establishment.

5.11.2 Procedure description

5.11.2.1 WLCP bearer modify procedure initiated by the TWAG

The TWAG shall initiate the WLCP bearer modify procedure by sending a WLCP BEARER MODIFY REQUEST message to the UE, start the timer T3588, and enter the state WLCP BEARER CONTEXT MODIFY PENDING (see figure 5.11.2.1.1).

The TWAG shall include the WLCP bearer identity and its associated PDN connection ID in the WLCP BEARER MODIFY REQUEST message to identify the WLCP bearer context to be modified.

Figure 5.11.2.1.1: WLCP bearer modify procedure

5.11.2.2 WLCP bearer modify procedure accepted by the UE

Upon receipt of the WLCP BEARER MODIFY REQUEST message, the UE shall check the received TFT before taking it into use, send a WLCP BEARER MODIFY ACCEPT message and enter the state WLCP BEARER CONTEXT ACTIVE. The WLCP BEARER MODIFY ACCEPT message shall include the WLCP bearer identity. The UE shall use the received TFT to apply mapping of uplink traffic flows to the WLCP bearer and shall treat any packet filter without explicit direction as being bi-directional.

The UE shall use the received TFT to apply mapping of uplink traffic flows to the WLCP bearer if the TFT contains packet filters for the uplink direction.

Upon receipt of the WLCP BEARER MODIFY ACCEPT message, the TWAG shall stop the timer T3588 and enter the state WLCP BEARER CONTEXT ACTIVE.

5.11.2.3 WLCP bearer modify procedure not accepted by the UE

Upon receipt of the WLCP BEARER MODIFY REQUEST message, the UE may reject the request from the TWAG by sending a WLCP BEARER MODIFY REJECT message. The UE shall include the WLCP bearer identity and a cause IE indicating the reason for rejection in the WLCP BEARER MODIFY REJECT message.

The cause typically indicates one of the following cause values:

#26: insufficient resources;

#31: request rejected, unspecified;

#41: semantic error in the TFT operation;

#42: syntactical error in the TFT operation;

#43: invalid WLCP bearer identity;

#44: semantic error(s) in packet filter(s);

#45: syntactical error(s) in packet filter(s); or

#95 – 111: protocol errors.

The UE shall check the TFT in the WLCP BEARER MODIFY REQUEST message for different types of TFT IE errors as follows:

a) Semantic errors in TFT operations:

1) TFT operation = "Create a new TFT" when there is already an existing TFT for the WLCP bearer.

2) When the TFT operation is an operation other than "Create a new TFT" and there is no TFT for the WLCP bearer.

3) TFT operation = "Delete packet filters from existing TFT" when it would render the TFT empty.

4) TFT operation = "Delete existing TFT" for a dedicated WLCP bearer.

In case 4 the UE shall reject the WLCP bearer modify request with cause #41 "semantic error in the TFT operation".

In the other cases the UE shall not diagnose an error and perform the following actions to resolve the inconsistency:

In case 1 the UE shall further process the request and, if it was processed successfully, delete the old TFT.

In case 2 the UE shall:

– process the request and if the TFT operation is "Delete existing TFT" or "Delete packet filters from existing TFT", and if no error according to items b, c, and d was detected, consider the TFT as successfully deleted;

– process the request as an activation request, if the TFT operation is "Add packet filters in existing TFT" or "Replace packet filters in existing TFT".

In case 3, if the packet filters belong to a dedicated WLCP bearer and if no error according to items b, c, and d was detected, the UE shall reject the request with cause #41 "semantic error in the TFT operation".

In case 3, if the packet filters belong to the default WLCP bearer and if no error according to items b, c, and d was detected, the UE shall delete the existing TFT.

b) Syntactical errors in TFT operations:

1) When the TFT operation = "Create a new TFT", "Add packet filters in existing TFT", "Replace packet filters in existing TFT" or "Delete packet filters from existing TFT" and the packet filter list in the TFT IE is empty.

2) TFT operation = "Delete existing TFT" or "No TFT operation" with a non-empty packet filter list in the TFT IE.

3) TFT operation = "Replace packet filters in existing TFT" when the packet filter to be replaced does not exist in the original TFT.

4) TFT operation = "Delete packet filters from existing TFT" when the packet filter to be deleted does not exist in the original TFT.

5) TFT operation = "Delete packet filters from existing TFT" with a packet filter list also including packet filters in addition to the packet filter identifiers.

6) When there are other types of syntactical errors in the coding of the TFT IE, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list.

In case 3 the UE shall not diagnose an error, further process the replace request and, if no error according to items c and d was detected, include the packet filters received to the existing TFT.

In case 4 the UE shall not diagnose an error, further process the deletion request and, if no error according to items c and d was detected, consider the respective packet filter as successfully deleted.

Otherwise the UE shall reject the modification request with ESM cause #42 "syntactical error in the TFT operation".

c) Semantic errors in packet filters:

2) When the resulting TFT, which is assigned to a dedicated WLCP bearer context, does not contain any packet filter applicable for the uplink direction among the packet filters created on request from the network.

The UE shall reject the request with cause #44 "semantic errors in packet filter(s)".

d) Syntactical errors in packet filters:

1) When the TFT operation = "Create a new TFT", "Add packet filters to existing TFT", and two or more packet filters in the resultant TFT would have identical packet filter identifiers.

2) When the TFT operation = "Create a new TFT", "Add packet filters to existing TFT" or "Replace packet filters in existing TFT", and two or more packet filters among all TFTs associated with this PDN connection would have identical packet filter precedence values.

3) When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.

In case 1, if two or more packet filters with identical packet filter identifiers are contained in the new request, the UE shall reject the request with cause #45 "syntactical errors in packet filter(s)". Otherwise, the UE shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have the identical packet filter identifiers.

In case 2, if the old packet filters do not belong to the default WLCP bearer, the UE shall not diagnose an error, shall further process the new request and, if it was processed successfully, delete the old packet filters which have identical filter precedence values.

In case 2, if one or more old packet filters belong to the default WLCP bearer, the UE shall release the relevant PDN connection. If the relevant PDN connection is the last one that the UE has, the UE shall initiate PDN connectivity establishment procedure to re-establish the PDN connectivity to the network.

Otherwise the UE shall reject the request with cause #45 "syntactical errors in packet filter(s)".

Upon receipt of the WLCP BEARER MODIFY REJECT message with cause value other than #43 "invalid WLCP bearer identity" in state BEARER CONTEXT MODIFY PENDING, the TWAG shall abort the WLCP bearer modify procedure, stop the timer T3588, if the timer is running, and enter the state WLCP BEARER CONTEXT ACTIVE. If the TWAG receives the WLCP BEARER MODIFY REJECT message with cause #43 "invalid WLCP bearer identity", the TWAG locally deactivates the WLCP bearer without peer-to-peer signalling.

5.11.3 Abnormal cases in the UE

No abnormal cases have been identified.

5.11.4 Abnormal cases in the TWAG

The following abnormal cases can be identified:

a) Expiry of timer T3588:

On the first expiry of the timer T3588, the TWAG shall resend the WLCP BEARER MODIFY REQUEST and shall reset and restart timer T3588. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3486, the TWAG shall abort the procedure and enter the state WLCP BEARER CONTEXT ACTIVE.

The TWAG may continue to use the previous WLCP bearer context or initiate a WLCP bearer release procedure.

b) Collision of UE requested PDN disconnection procedure and WLCP bearer modify procedure

When the TWAG receives a PDN DISCONNECT REQUEST message during an WLCP bearer modify procedure, and the WLCP bearer to be modified belongs to the PDN connection the UE wants to disconnect, the TWAG shall terminate the WLCP bearer modify procedure locally, release any resources related to this procedure and proceed with the PDN disconnection procedure.

5.12 WLCP bearer release procedure

5.12.1 General

The purpose of the WLCP bearer release procedure is to release a dedicated WLCP bearer between the UE and the TWAN. The WLCP bearer release procedure is initiated by the TWAG if:

– the UE is connected to a trusted WLAN using the multi-connection mode (MCM);

– both the UE and TWAG support multiple bearer PDN connectivity and default WLCP bearer identity has been assigned during PDN connection establishment; and

– the TWAG receives from the PDN GW a Delete Bearer Request message that a WLCP bearer is to be released and the WLCP bearer to be released is not default WLCP bearer.

NOTE: if the WLCP bearer to be release is default WLCP bearer, the TWAG invokes PDN disconnect procedure to disconnect the PDN connection and release all associated WLCP bearers (see subclause 5.3).

5.12.2 Procedure description

5.12.2.1 WLCP bearer release procedure initiated by the TWAG

The TWAG shall initiate the WLCP bearer release procedure by sending a WLCP BEARER RELEASE REQUEST message to the UE, start the timer T3597, and enter the state WLCP BEARER CONTEXT INACTIVE PENDING (see figure 5.12.2.1.1).

Figure 5.12.2.1.1: WLCP bearer release procedure

The WLCP BEARER RELEASE REQUEST message contains a cause typically indicating one of the following:

#8: operator determined barring;

#26: insufficient resources;

#36: regular deactivation;

#38: network failure.

5.12.2.2 WLCP bearer release procedure accepted by the UE

Upon receipt of the WLCP BEARER RELEASE REQUEST message, the UE shall delete the WLCP bearer identified by the WLCP bearer identity, send a WLCP BEARER RELEASE ACCEPT message and enter the state WLCP BEARER CONTEXT INACTIVE. The WLCP BEARER RELEASE ACCEPT message shall include the WLCP bearer identity.

Upon receipt of the WLCP BEARER RELEASE ACCEPT message, the TWAG shall stop the timer T3597 and enter the state WLCP BEARER CONTEXT INACTIVE.

5.12.2.3 WLCP bearer release procedure not accepted by the UE

Upon receipt of the WLCP BEARER RELEASE REQUEST message, the UE may reject the request from the TWAG by sending a WLCP BEARER RELEASE REJECT message. The UE shall include the WLCP bearer identity and a cause IE indicating the reason for rejection in the WLCP BEARER RELEASE REJECT message.

The cause typically indicates one of the following cause values:

#31: request rejected, unspecified;

#43: invalid WLCP bearer identity;

#95 – 111: protocol errors.

Upon receipt of the WLCP BEARER RELEASE REJECT message in state WLCP BEARER CONTEXT INACTIVE PENDING, the TWAG shall abort the WLCP bearer release procedure, stop the timer T3597, if the timer is running, and enter the state WLCP BEARER CONTEXT INACTIVE.

5.12.3 Abnormal cases in the UE

The following abnormal case can be identified:

a) UE is requested to deactivate a default WLCP bearer context

If the UE determines that the WLCP bearer indicated in the WLCP BEARER RELEASE REQUEST message is the default WLCP bearer, then the UE shall respond by performing a UE requested PDN disconnection procedure.

5.12.4 Abnormal cases in the TWAG

The following abnormal cases can be identified:

a) Expiry of timer T3589

On the first expiry of the timer T3589, the TWAG shall resend the WLCP BEARER RELEASE REQUEST and shall reset and restart timer T3589. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3589, the TWAG shall abort the procedure and deactivate the WLCP bearer context locally.

b) Collision of UE requested PDN disconnection procedure and WLCP bearer release

When the TWAG receives a PDN DISCONNECT REQUEST message during the WLCPbearer release procedure, and the WLCP bearer indicated in the WLCP BEARER RELEASE REQUEST message is a dedicated WLCP bearer belonging to the PDN connection the UE wants to disconnect, the TWAG shall proceed with both procedures. If the WLCP bearer indicated in the WLCP BEARER RELEASE REQUEST message is the default WLCP bearer, the TWAG shall proceed with the WLCP bearer release procedure.