Section: 14.3.2 Exceptional scenarios
Content: 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.