to solve or specify what happens to the eNodeB and the SGW prefixes after the inter- technology handover. The prefixes learned from the eNodeB and the SGW are simply lost in all cases known by the existing 3GPP specifications. The network needs to clean up the possible evolved bearer state from the MME and the SGW after a handover but that is again the expected behavior. During the handovers the MME is responsible for the creation of a new S1-U tunnel for the SGW terminated/breakout traffic. The target eNodeB learns whether such a tunnel was already in place from the S1-MME signaling. We will discuss the required S1-MME enhancements for this purpose in Section 6.2.3. Backward Compatibility with EPS The evolved bearer proposal relies on a specific PDCP behavior and maintaining the existing 3GPP EPS Bearer as a base to guarantee backward compatibility. The evolved bearer does not define its own PDN Type. There are two cases to take a closer look at: what happens when a UE does not support the evolved bearer and what happens when the network does not support evolved bearer? It could make sense to reserve a bit evolved capability, for example, in the UE network capability information element in the Attach Request NAS signaling message [22] where a mobile host could explicitly state that it supports the evolved bearer. Based on the new evolved capability bit the network may entirely skip the preparations for the evolved bearer and conserve signaling and resources. There is no need for an error cause code to the UE direction stating that evolved bearer is not supported. If the network has no support it has no means to respond anything meaningful. If a UE does not support/implement the evolved bearer, it never expects to receive or send any PDCP PDU types other than those that are already specified in the existing PDCP specification [13]. The PDCP specification states that unknown PDCP PDU types are simply discarded. Where a network does not support the evolved bearer the default EPS Bearer gets activated as specified i