14 Handling of Bearer Contexts Mismatch

29.2743GPP3GPP Evolved Packet System (EPS)Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)Release 18Stage 3TS

14.1 General

Bearer Contexts mismatch among different EPC entities, e.g. MME/SGW/PGW, can happen due to various reasons, e.g. transport network delay, signalling overload.

14.2 Detection of Bearer Context Mismatch

Bearer Context mismatch can be detected by a receiving GTP-C entity in the following cases:

– when at least one dedicated bearer context in the request message is unknown; or

– when at least one dedicated bearer context is missing in the request message in comparison to the bearer contexts stored; or

– when receiving a response message indicating that one of the dedicated bearer context(s) was unknown, by using the cause code "Context not found" at the Bearer Context level. See also clause 8.4.

The Modify Bearer Request/Response and the Modify Access Bearer Request/Response in particular enables an easy detection of bearer contexts mismatch since all the bearer contexts, either of the PDN connection for a Modify Bearer Request/Response or of all the UE’s PDN connections for a Modify Access Bearer Request/Response, need to be included in the messages.

14.3 Handling of Bearer Context Mismatch

14.3.1 General

The following requirements should apply:

1) When an EPC entity receives a response message, where one or more dedicated bearer context(s) is associated with the Cause code "Context Not Found" while the PDN connection is known by the peer, the EPC entity shall delete the corresponding bearer context(s);

2) When an SGW receives a Modify Bearer Request, where one or more dedicated bearer context(s) is missing in the request message in comparison to the Bearer Context(s) stored for the UE’s PDN connection, the SGW shall accept the Modify Bearer Request message and delete the corresponding bearer context(s) locally. The PGW shall apply the same behavior if the Modify Bearer Request received at the PGW includes the Bearer Contexts to be modified IE;

3) When a SGW receives a Modify Bearer Request, where only one or more dedicated bearer context(s) is unknown, the SGW shall accept the Modify Bearer Request message partially and set the cause code "Context Not Found" for those unknown bearer context(s) at Bearer Context level. The PGW shall apply the same behavior if the Modify Bearer Request received at the PGW includes the Bearer Contexts to be modified IE;

4) When a SGW receives a Modify Access Bearer Request, where one or more dedicated bearer context(s) is missing in the request message in comparison to the Bearer Context(s) stored for all the UE’s PDN connections, the SGW shall delete the corresponding bearer context(s) locally;

5) When a SGW receives a Modify Access Bearer Request, where only one or more dedicated bearer context(s) is unknown, the SGW shall accept the Modify Access Bearer Request message partially and set the cause code "Context Not Found" for those unknown bearer context(s) at Bearer Context level.

NOTE: It is assumed the PGW can at least use a subsequent Modify Bearer Request to resolve Bearer Context mismatch, so that the SGW need not send explicit message to delete unknown Bearer Context.

14.3.2 Exceptional scenarios

During a dedicated bearer creation procedure, temporary Bearer Context mismatch may occur at the SGW, e.g. due to the collision between Create Bearer Request and Modify (Access) Bearer Request messages. Applying the general requirements of clause 14.3.1 may in such case lead to unnecessary signalling and cause extra latency. The SGW should handle such Bearer Context mismatch in an implementation specific way, but in such a way to accept the Modify (Access) Bearer Request message and to not locally delete the missing Bearer Context.

During a Network Triggered Service Request procedure, which is triggered by a dedicated bearer creation procedure towards a UE in Idle mode, the MME shall include only the existing Bearer Contexts (not the new Bearer Contexts just created) in the corresponding Modify (Access) Bearer Request message. The same principle shall apply when piggybacking is used, i.e. when the Modify Bearer Request is piggybacked in the Create Bearer Response message, the MME shall include only the existing Bearer Contexts (not the new Bearer Contexts just created) in the corresponding Modify (Access) Bearer Request message.

NOTE: During a Network Triggered Service Request procedure, which is triggered by a dedicated bearer creation procedure towards a UE in Idle mode, bearer mismatches can be avoided by the MME sending the Create Bearer Response only after it receives the Modify Bearer Response message, however in some rare cases, the signalling can be delayed for the UE, e.g. if the Modify Bearer Response is lost.

Annex A (Informative):
Backward Compatibility Guidelines for Information Elements

In order to preserve backward compatibility, the following rules should apply when adding or modifying information elements for existing messages.

– No new mandatory (M) information elements should be added.

– No new conditional (C) information elements should be added.

– Any new IEs should be either:

optional (O), having no conditions on their presence, or

conditional-optional (CO), having conditions that should apply only to the sender and not to the receiver.

Such conditions should be worded generally as follows: "This IE shall be sent over the xxx interface <condition>. The receiving entity need not check the IE’s presence."

– If any new conditions are added to a previously specified conditional (C) information element, these new conditions should apply only to the sender and not to the receiver.

Such additional conditions should be worded generally as follows: "This IE shall be sent over the xxx interface <condition>. For this optional condition, the receiving entity need not check the IE’s presence."

Existing conditions for such conditional (C) IEs should be treated as before, and the presence of the IEs should remain conditional (C).

Annex B (Informative):
Transparent copying of RANAP/S1AP/NGAP IEs into GTP IEs