HK1171317B - Accommodating hybrid ipv4v6 network support - Google Patents

Abstract

A user equipment (UE) is provided. The UE comprises at least one component that is configured to detect an event of one of the UE changing routing area and the UE changing radio access technology from a long-term evolution (LTE) network to a global system for mobile communications enhanced data rates for GSM evolution radio access network (GERAN) or to a universal mobile telecommunication system terrestrial radio access network (UTRAN) and, responsive to detecting the event, to deactivate one of a packet data protocol (PDP) context and an evolved packet system (EPS) bearer.

Description

Accommodating hybrid IPV4V6 network support

Technical Field

Background

As used herein, the terms "user equipment" and "UE" may refer in some cases to mobile devices such as mobile phones, personal digital assistants, handheld or laptop computers, and similar devices having communication capabilities. Such a UE may include a UE and its associated removable storage module, such as, but not limited to, a Universal Integrated Circuit Card (UICC) that includes a Subscriber Identity Module (SIM) application, a Universal Subscriber Identity Module (USIM) application, or a removable user identity module (R-UIM) application. Alternatively, a UA may comprise the device itself without such a module. In other cases, the term "UE" may refer to a device that has similar capabilities but is not readily portable, such as a desktop computer, a set-top box, or a network device. The term "UE" may also refer to any hardware or software component that may terminate a communication session for a user. Herein, the terms "user equipment", "UE", "user agent", "UA", "user device", and "user node" may be used synonymously.

As communication technology has evolved, more advanced network access devices have been introduced that can provide services that were previously unavailable. Such a network access device may include: as an improved system and apparatus for an equivalent device in a conventional wireless communication system. Such advanced or next generation devices may be included in evolved wireless communication standards, such as long term evolution LTE and LTE-advanced (LTE-a). For example, an LTE or LTE-a system may include an evolved universal terrestrial radio access network (E-UTRAN) evolved NodeB (or eNB), a wireless access point, or similar components rather than a traditional base station. As used herein, the term "access node" refers to any component of a wireless network, such as a legacy base station, wireless access point, or LTE-a node B or eNB, that creates a geographic area of reception and reception coverage allowing a UA or relay node to access other components in a communication system. In this document, the terms "access node" and "access device" may be used interchangeably, but it should be understood that an access node may comprise a plurality of hardware and software.

The signals that transmit data between the UE and the access node may have frequency, time, and coding parameters, as well as other characteristics that may be specified by the network node. A connection between any of these units having such a particular set of characteristics may be referred to as a resource. The connection may be established over a single radio link, such as in the case of E-UTRAN, or over one or more radio links, such as in the case of universal mobile telecommunications system terrestrial radio access network (UTRAN). The network node typically establishes different resources for each UE or other network node with which it communicates at any particular time.

Disclosure of Invention

Drawings

For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

Fig. 1 is an illustrative diagram of a communication network in accordance with an embodiment of the present disclosure.

Fig. 2 is an explanatory diagram of an information unit according to an embodiment of the present disclosure.

Fig. 3 illustrates a method according to an embodiment of the present disclosure.

Fig. 4 illustrates a method according to an embodiment of the present disclosure.

Fig. 5 illustrates a method according to an embodiment of the present disclosure.

Fig. 6 illustrates a method according to an embodiment of the present disclosure.

Fig. 7 illustrates a method according to an embodiment of the present disclosure.

FIG. 8 illustrates a processor and related components suitable for implementing several embodiments of the present disclosure.

Detailed Description

It should be understood at the outset that although an illustrative implementation of one or more embodiments of the present disclosure are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the implementation designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

Turning to fig. 1, a communication system 100 is now described. The system 100 includes a first wireless coverage area 102, a second wireless coverage area 104, and a network 106 coupled for communication between the coverage areas 102, 104. The first access node 110 serves a first wireless coverage area 102 and provides a wireless link to a first User Equipment (UE)120 and a second UE 122. The second access node 126 serves the second wireless coverage area 104 and provides wireless links to a third UE128 and a fourth UE 130. The second access node 126 is also shown to provide a wireless link to the first UE120, for example, after the UE120 has handed over from the first coverage area 102 to the second coverage area 104. Alternatively, the UE120 may have handed over from the second coverage area 104 to the first coverage area 102. Although the description hereinafter primarily refers to the first UE120, it should be understood that the description of the interaction of the first UE120 with the system 100 may equally apply to other UEs, such as to UEs 122, 128, 130.

In an embodiment, the communication system 100 may be provided based on a single wireless communication protocol or multiple wireless communication protocols. In an embodiment, communication system 100 may include a Long Term Evolution (LTE) Radio Access Network (RAN), GSMEDGERAN(GERAN), or a UMTS terrestrial RAN (utran). Alternatively, communication system 100 may include a mix of different RAN technologies. For example, in an embodiment, the first coverage area 102 may be associated with an lte ran, while the second coverage area 104 may be associated with a GERAN. In other embodiments, the first coverage area 102 may be associated with the lte ran and the second coverage area 104 may be associated with the UTRAN. In another embodiment, the first coverage area 102 may be associated with GERAN and the second coverage area 104 may be associated with UTRAN. In another embodiment, the first coverage area 102 may be associated with a first routing area and the second coverage area 104 may be associated with a second routing area.

A shared network or equivalent Public Land Mobile Network (PLMN) may also be used, for example in an embodiment the first coverage area 102 may be associated with a GERAN from a first PLMN and the second coverage area 104 may be associated with a GERAN from another PLMN. In another embodiment, the first coverage area 102 may be associated with a lte ran from a first PLMN, while the second coverage area 104 may be associated with a UTRAN from another PLMN. It should be noted that the number of coverage areas is not limited to two. For example, a first coverage area may be associated with GERAN from a first PLMN, while a second coverage area may be associated with UTRAN from the same first PLMN, while a third coverage area may be associated with lte ran from the same first PLMN, while a fourth coverage area may be associated with a wireless LAN (e.g., IEEE802.11) from the same first PLMN, while a fifth coverage area may be associated with UTRAN from another PLMN.

As the UE moves in the system 100, such as the first UE120 under different conditions, such as (but not by way of any limitation) changing radio or propagation conditions experienced by the UE: network congestion, network decision, or a combination thereof, the context associated with the UE may be switched, e.g., the serving access node is switched from the first access node 110 to the second access node 126. Problems with internet protocol addressing used by the UE and the access node and/or the network may arise when the two access nodes use different radio access technologies and/or are in different routing areas. For example, in an embodiment, the first UE120, when served by the first access node 110, establishes an Evolved Packet System (EPS) bearer using hybrid internet protocol version 4, version 6(IPv4v6) addressing to attach to the LTE network. Thereafter, the first UE120 is handed over to the second access node 126, the second access node 126 is associated with GERAN, and the EPS bearer is converted to a PDP context. If the serving general packet radio service support node (SGSN) coupled to the second access node 126 does not support hybrid IPv4v6 addressing, the data session for the first UE120 will not be able to send or receive data for applications that depend on the unsupported addressing type. In some cases, mobility within the same routing area (e.g., a handover from first access node 110 to second access node 126, where first access node 110 and second access node 126 are within the same routing area and have the same radio access technology) may result in first UE120 experiencing an incompatibility between the IP addressing type of the PDP context of the application established when served by first access node 110 and the IP addressing type supported by second access node 126.

Similar problems may arise for other technology mixes and/or when changing routing areas (e.g., in some cases where the SGSN coupled to the second access node 126 does not support the type of internet protocol addressing set up when the first UE120 establishes a data session via the first access node 110). If the initial context established via the first access node 110 specifies hybrid IPv4v6 addressing, but the SGSN associated with the second access node 126 does not support hybrid IPv4v6 addressing, then a problem may arise with respect to applications executing on the first UE120 that depend on the unsupported addressing type. This problem may arise if the initial context established via the first access node 110 specifies IPv4 addressing, but the SGSN associated with the second access node 126 supports only IPv6 addressing. This problem may arise if the initial context established via the first access node 110 specifies IPv6 addressing, but the SGSN associated with the second access node 126 supports only IPv4 addressing. Thus, embodiments provide a handling scenario when the IP support of the network remains unchanged over time when an EPS bearer (or PDP context) is activated.

The present disclosure teaches several solutions to the problem of handover management of data sessions between access nodes supporting different IP addressing types. The particular solution alternative or alternatives may be selected based on particular operating conditions, configuration of network 100, and/or final standard deployment. In an embodiment, first UE120 may deactivate a PDP context or an Evolved Packet System (EPS) bearer, for example, when second access point 126 and/or a network coupled to second access point 126 does not support IP addressing associated with the PDP context. The first UE120 may deactivate the PDP context either implicitly or explicitly. Explicitly deactivating the PDP context means that the first UE120 sends a message explicitly informing the network 106 of the deactivation of the PDP context; implicitly deactivating the PDP context means that the first UE120 deactivates the PDP context but does not send any message to the network 106 informing of the deactivation. In an embodiment, the first UE120 may reactivate the PDP context or EPS bearer after the explicit PDP context or EPS bearer deactivation. For example, if a PDP context or EPS bearer was previously set up using hybrid IPv4v6 addressing, the first UE120 may activate PDP contexts for IPv4 and/or IPv6, respectively, based on the needs of one or more applications executing on the first UE 120.

After determining that an excessive amount of time has elapsed since the application associated with the PDP context successfully sent and/or received the data, or using other time triggers, first UE120 may determine the incompatibility of the IP addressing types by inference. In an embodiment, this may only be performed when it is effectively assumed that the associated application sends/receives data (e.g. an application during file transfer) to avoid unnecessarily deactivating/reactivating PDP contexts or EPS bearers. In some cases, the first UE120 may have multiple applications executing and associated with different PDP contexts and/or EPS bearers, and may draw inferences about the IP addressing types supported by the second access node 126 based on the different behaviors of the applications. For example, if after a transfer from the first access node 110 to the second access node 126, a first application configured to use IPv4 addressing experiences a data transfer timeout while a second application configured to use IPv6 addressing continues the data transfer, the first UE120 may conclude that the second access node 126 supports IPv6 addressing but not IPv4 addressing. In other cases, different inferences may be drawn. In an embodiment, first UE120 may deactivate the PDP context and/or EPS bearer after expiration of the timer and may reactivate the PDP context and/or EPS bearer based on an attempt to use a single IP addressing type. If the considered application data transfer timer expires again, the first UE120 may reactivate the PDP context and/or EPS bearer and reactivate the PDP context and/or EPS bearer based on attempting to use yet another different IP addressing type until the data transfer is successful or does not time out.

In another embodiment, the second access node 126 may send a mobility message to the first UE120 that includes an indication of the IP addressing types supported by the second access node 126 and the SGSN associated with the second access node 126. In another embodiment, the second access node 126 may indicate the IP addressing types that it supports in the system information message broadcast by the second access node 126. PDP contexts associated with applications on the first UE120 that are compatible with the IP addressing types supported by the second access node 126 may be implicitly or explicitly deactivated or separately reactivated for IPv4 and IPv6 as needed.

In an embodiment, the first UE120 may detect that no data is being received and/or transmitted over the data connection via the wireless link with the second access node 126, e.g., after the first UE120 is handed off from the first access node 110 to the second access node 126. The first access point 110 may support LTE while the second access point 126 may support GERAN or UTRAN. Alternatively, the first access point 110 may be associated with a first routing area within GERAN or UTRAN and the second access point 126 may be associated with a second routing area within GERAN or UTRAN.

This detection may be implemented on a per application basis using a timer. After the timer expires, the first UE120 may deactivate a given PDP context or EPS bearer when no data has been sent or received, e.g., for the PDP context or the EPS bearer. In an embodiment, the deactivation of a PDP context or EPS bearer may be based on first determining that an application is expecting to transmit and/or receive data (e.g., an application during a file transfer) before deactivating the PDP context to avoid unnecessarily deactivating the PDP context when the application has no data to transmit or receive. In an embodiment, first UE120 may reactivate a PDP context or EPS bearer corresponding to an application linked to a previously deactivated PDP context or EPS bearer. For example, if the previous IP addressing type for a given PDP context or EPS bearer is hybrid IPv4v6, the first UE120 may activate the PDP context or EPS bearer for IPv4 or IPv6 individually as required by the application.

In an embodiment, during handover of UE120 from first access node 110 to second access point 126, second access point 126 may send one or more mobility messages to UE120 that contain an internet protocol version field (IP version field) that defines the IP addressing types supported by second access point 126 and/or the SGSN associated with second access point 126. The internet protocol version may identify the IP addressing type as one of: IPv4 addressing type, IPv6 addressing type, hybrid IPv4v6 dual addressing type, hybrid IPv4v6 single addressing type. A network supporting the hybrid IPv4v6 dual addressing type allows the first UE120 to request and receive both IPv4 and IPv6 addresses in a single message interaction. A network supporting the hybrid IPv4v6 single addressing type requires the first UE120 to request and receive an IPv4 address in a first message interaction and an IPv6 address in a separate second message interaction, for example via two separate PDP context activation procedures, using two different PDP contexts. A wide variety of specific embodiments for encapsulating the IP version field in the mobility message are contemplated, some of which are shown more fully elsewhere herein.

If the first UE120 is configured for hybrid IPv4v6 type addressing, the first UE120 may resume data transfer via the second access point 126 using the IP addressing type indicated by the IP version field in the mobility message (assuming that the IP addressing type is compatible with the IP addressing type and/or IP version required by the relevant application for the PDP context). For example, if the IP version field in the mobility message sent by the second access point 126 indicates that the second access node 126 is configured to support IPv4 addressing, the first UE120 may resume data transfer using IPv4 addressing for related applications compatible with IPv4 addressing. Alternatively, if the IP version field indicates that the second access node 126 is configured to support IPv6 addressing, assuming the relevant application is compatible with IPv6 addressing, the first UE120 may resume data transfer using IPv6 addressing.

If the IP version field in the mobility message sent by the second access point 126 indicates that the second access node 126 is configured to support hybrid single IPv4v6 type addressing, the first UE120 may deactivate the PDP context or EPS bearer previously activated with IPv4v6 and reactivate the PDP context or EPS bearer separately for IPv4 and/or IPv6 without attempting to determine whether data has been received. This may result in saving network resources, UE processing resources, and/or UE battery power.

If the first UE120 is configured by the first access point 110 as IPv6 addressing and the IP version field in the mobility message sent by the second access point 126 indicates that the second access point 126 is configured to support IPv4 addressing, the first UE120 may deactivate the PDP context or EPS bearer without attempting to evaluate whether no data is received. This may result in saving network resources, UE processing resources, and/or UE battery power conservation. If the first UE120 is configured by the first access point 110 as IPv4 addressing and the IP version field in the mobility message sent by the second access point 126 indicates that the second access point 126 is configured to support IPv6 addressing, the first UE120 may deactivate the PDP context or EPS bearer without attempting to evaluate whether no data is received. This may result in saving network resources, UE processing resources, and/or UE battery power conservation.

The solution described above is also useful when the first UE120 is powered on. For example, if first UE120 reads from a system information message sent by access points 110, 126 that the access node on which first UE120 camps does not support a particular IP version type and/or IP addressing type, first UE120 may not attempt to activate a PDP context for which an application executing on first UE120 prefers or requires a particular unsupported IP addressing type. For example, if the IP version field of the system information message indicates that the access node 110, 126 supports IPv4, the first UE120 will not activate the PDP context or EPS bearer associated with the application requiring IPv6 type addressing. In another embodiment, if the IP version field of the system information message indicates that the access node 110, 126 supports the hybrid IPv4v6 single addressing type, the first UE120 will not attempt to activate a PDP context or EPS bearer utilizing IPv4v6, but will activate a PDP context or EPS bearer separately for IPv4 and/or IPv6 (e.g., using a separate PDP context or EPS bearer).

The mobility message that may contain the IP version field includes: a mobility fromareutralimand message, a physical channel reconfiguration message, an inter-RAT cell change command message, a PS handover command message, a cell change command message, a routing area update accept message, a tracking area update accept message, and an attach accept message. One or more of these messages may be extended to add new codepoints or values in an already existing information element or in a new information element containing an IP version field. This MobilityFromEUTRACommand message may be used in the context of mobility from E-UTRA procedures to move the first UE120 in RRC _ CONNECTED state in LTE to a cell or other system using another radio access technology (e.g., GERAN, UTRAN, CDMA-2000), for example, to complete handover of the first UE120, or to complete a cell change command. The physical channel reconfiguration message may be used in the context of a physical channel reconfiguration procedure within the UTRAN to establish, reconfigure, and release a physical channel. The inter-RAT cell change order message may be used in the context of an inter-RAT cell change order procedure to transition the connection between the first UE120 and the UTRAN to another radio access technology under control of the network 106.

The PS handover command message may be used to support PS handover from GERAN to UTRAN or to LTE within GERAN. The cell change command message may be sent by network 106 in GERAN to first UE120 on the PCCCH or PACCH to command first UE120 to leave the current cell and change to a new cell. The routing area update accept message may be used in GERAN or UTRAN. The tracking area update accept message may be used in LTE. The attach accept message can be in GERAN, UTRAN₁And any of LTE.

In an embodiment, the IP version field may include an enumerated value. For example, in an embodiment, the IP version field may include two bits, a value of 00 corresponding to IPv4 addressing, a value of 01 corresponding to IPv6 addressing, a value of 10 corresponding to hybrid IPv4v6 dual addressing, and a value of 11 corresponding to hybrid IPv4v6 single addressing. The hybrid IPv4v6 addressing codepoint represents an "IPv 4v6 dual addressing PDP type" and indicates that both IPv4 and IPv6 addresses can be assigned within the same PDP context. For example, code points 10 may be allocated for this purpose. In another embodiment, different correspondences between bit values and IP addressing types may be used. Optionally, in other embodiments, the IP version field may encode an IP addressing type for each of a plurality of Access Point Names (APNs) associated with the first UE 120.

In another embodiment, the new codepoint may have the following meaning: "(for the same APN) IPv4 and IPv6 are supported in different PDP contexts", i.e. "IPv 4v6 single addressing PDP type". This may trigger the first UE120 to request activation of different PDP contexts for IPv4 and IPv6 addresses. This may be achieved by the first UE requesting a single address bearer in the PDP context activation request message. For example, code points 11 may be allocated for this purpose.

In another embodiment, the first UE120 may infer the type of IP addressing used by the access nodes 110, 126 based on other version information provided in the broadcast system information and/or mobility messages. In an embodiment, the SGSN version field may be provided in one or more mobility messages and/or system information messages. The SGSN version field may include three bits and use the following coding: 000 indicates that the SGSN is release 8 3GPP with Gn/Gp interface; 001 indicates SGSN is release 8 3GPP with S4 interface; 010 indicates that the SGSN is Release 9 3 GPP; and the remaining bit code words are unassigned and/or reserved for future encoding of SGSN versions. When the SGSN version field is encoded with one of a value of 001 and a value of 010, the first UE120 can conclude that the access node 110, 126 and/or SGSN support the hybrid IPv4v6 addressing type. However, in other embodiments, other inferences may be associated with the SGSN version field.

In another embodiment, the SGSN version field and the Core Network Interface (CNI) type field may be provided in one or more mobility messages and/or system information messages. The SGSN version field may include three bits and use the following coding: 000 indicates that the SGSN is version 98 or older; 001 indicates SGSN release 99 to release 8; 010 indicates that the SGSN is release 9 or newer; and the remaining bit code words are unassigned and/or reserved for future encoding of SGSN versions. The CNI field may include 1 bit and may utilize the following coding: 0 indicates that the interface is Gn/Gp, and 1 indicates that the interface is S3/S4. The first UE120 may conclude that the SGSN, version 9 or later, supports hybrid IPv4v6 addressing. The first UE120 may conclude that the combination of the SGSN version fields encoded as release 99 through release 8 and the CNI type field encoded as S3/S4 also indicate support for hybrid IPv4v6 addressing. The first UE120 may conclude that the combination of the SGSN version fields encoded as release 99 through release 8 and the CNI type field encoded as Gn/Gp indicates that hybrid IPv4v6 addressing is not supported. However, in other embodiments, other interfaces may be associated with the SGSN version field and/or the CNI type field.

UE triggered PDP context re-establishment

In an embodiment, when a UE changes Routing Area (RA) within 2G/3G or changes RAT from LTE to 2G/3G, it may deactivate and re-establish the relevant PDP context in case it evaluates that the data transfer was interrupted for some PDP contexts while the radio connection was maintained. This may be achieved by application dependent reactivation of the PDP context. For example, a timer may be used at the UE side to evaluate this. The timer may be one timer per application and is started when there is no user data activity. Upon expiration of the timer, the PDP context for a given application will be reactivated.

In addition, as a possible supplement, embodiments may be as follows: to avoid erroneously deactivating and re-establishing a PDP context that has no data to transmit because the application does not require a data transmission at that time, the UE may additionally use the trigger from the application to ensure that the delay of the data transmission is anomalous ('data expected' trigger or state). Thus, the timer-based function from the above-described embodiments may be activated only in "data expected" conditions for the relevant PDP context. This means that this embodiment will act as a 'suppression' function for the previous embodiment. If no data is expected for an application (because, for example, there is no user action for some applications, or, for example, the end of data is reached for some applications), then based on the absence of a user data timer, reactivation of the PDP context will not be enabled.

This function may involve deactivation and reactivation of the UE triggered PDP context and thus becomes detectable (by detecting the corresponding message sent to the SGSN triggered by the UE). This embodiment may not affect the standard or add any signaling in the standard. However, the criteria may still be updated to emphasize this possibility for the UE.

Providing information from a network to a UE in a "mobility message

Another embodiment (or set of embodiments) may indicate to the UE the configuration options of the target core network in terms of IP support. To achieve this, the content of the message sent by the network to the UE may be enhanced to add this target SGSN configuration when the RAT from LTE to 2G/3G or RA within 2G/3G changes. This may indicate to the UE that the target SGSN supports only IPv4, only IPv6, or IPv4v 6.

If the UE evaluates that the new target configuration is IPv4 or IPv6 and the initial configuration is IPv4v6, the UE can immediately resume data transfer by using the new appropriate addressing. If the UE evaluates that the new target configuration is IPv4 and the initial configuration is IPv6, the UE can immediately reactivate the PDP context. If the UE evaluates that the new target configuration is IPv6 and the initial configuration is IPv4, the UE can immediately reactivate the PDP context. Messages that may provide this type of information to the UE are listed below.

Mobilityfrom eutra command message

Mobility from E-UTRA procedures may be used to move a UE in an RRC _ CONNECTED state in LTE to a cell using another Radio Access Technology (RAT), such as GERAN, UTRAN, CDMA-2000 systems. Mobility from the E-UTRA procedure includes two handovers, namely the MobilityFromEUTRACommand message includes radio resources that have been allocated for the UE in the target cell; and a cell change command. Thus, the MobilityFromEUTRACommand message may include information, such as system information, that facilitates access to the target cell and/or connection establishment in the target cell. The cell change command may be applicable to GERAN only.

The encoding of the possible new IP version fields may be as follows:

4.2.2 physical channel Reconfiguration message in UTRAN

The physical channel reconfiguration procedure may be used to establish, reconfigure, and release physical channels. For example, the procedure may be used to perform hard handover and/or HS-SDCH cell change and/or serving E-DCH cell change. Within the tabular description of the physical channel reconfiguration message, the IP version field may be included at the end of the table, or immediately below the CN information element field. In asn.1 of a message, the IP version field may be at the end of the message for backward compatibility reasons.

Another embodiment may be to add the IP version field in the "NAS system information (GSM-MAP)" so it will be included in the CN info ie in a backward compatible way. This "NAS system information (GSM-MAP)" may be encoded in TS24.008 (under the name "core network system information", a length field is utilized), and then included in the CN information info ie. In turn, one component of the "core network system information" may be "PS domain specific system information" which may be enhanced to add IP version bits. It should be noted that the CN information info ie may also be included in the following messages (all downlink messages): ACTIVISEETUPDATE, CELLUPDATECONFIRM, RADIOBERRECONFIBRATION, RADIOBERERELEASE, RADIOBERSETUP, TRANSPORTCHANENERECONGURATION, URAUPDATECONFIRM, and UTANMOBILITY FORMATION. Hence, updating the PS domain specific system information element and hence the CN information info ie may also provide IP version information in these messages.

In addition, "NAS system information (GSM-MAP)" may also be included in the following UTRAN message or information element: a system information block type 1(SIB1) message, a CN domain system information element, included in system information block type 13(SIB13) and system information block type 1(SIB1) messages, a CN information infofull information element, included in a UTRAN mobility information message, and a SRNS relocation information message. Thus, enhancing the "NAS system information (GSM-MAP)" in TS24.008 by adding IP version information would also allow this to be available in the above listed messages.

(inter-RAT) cell Change Command from UTRAN messages

The purpose of the (inter-RAT) cell change command procedure is to transfer the connection between the UE and the UTRAN to another radio access technology (e.g. GSM) under control of the network. This procedure can be used in CELL _ DCH and CELL _ FACH states. This procedure may be used when no RABs are established, or when the established RABs are from the PS domain only. This procedure is not used when there is no PS signaling connection.

In another embodiment, a new IE may be inserted into 'cellcell change order from UTRAN)'. Wherein the new IP version field is defined as follows:

IP version (2 bit field)

"PS Handover Command" within GERAN or from GERAN to UTRAN/LTE "

In GERAN packet transfer mode, a mobile station supporting PS handover may receive PSHANDOVERCOMMAND (PS Handover Command) message from BSS The information indicates the resources to be used in the new cell.<psHANDOVERCOMMAND message Content providing method and apparatus>Examples of (c) may be:

cell change command in GERAN or from GERAN to UTRAN/LTE

This message may be sent by the network in GERAN to the mobile station on the PCCCH or PACCH to command the mobile station to leave the current cell and change to a new cell. For a 3G multi-RAT mobile station, the new cell may be a 3G cell. For an E-UTRAN multi-RAT mobile station, the new cell may be an E-UTRAN cell.

Providing information from a network to a UE in a system information message of a GERAN/UTRAN

The system information message broadcast by the GERAN/UTRAN cell may be enhanced to add information regarding the configuration of the target core network in terms of IP version.

UTRAN system information

The following is an example of a UTRANSIB1 message.

The encoding of the IP version field itself (2-bit field) may be the same as defined above. In the asn.1 definition, new fields may appear at the end of a message for backward compatibility reasons. It should be noted that the above tabular description does not necessarily reflect the field order in the message encoding.

Alternatively, it should be noted that the information element "NAS system information" in the SIB1 above refers to the core network system information in 3gpp ts 24.008. One component of this is PS domain specific system information that can be enhanced to add IP version bits. Thus, by enhancing the core network system information (or more specifically, PS domain specific system information) in the 3gpp ts24.008, this may provide IP version information in the SIB1 message (as well as in other messages).

Possible enhancements: providing IP version information at APN level

Enhancements to the above-described embodiments of providing information from the network to the UE may be: in the information added to those messages, it may be desirable to provide supported IP versions for each APN (since each PDN may be on a different version) rather than requiring SGSN level support. Thus, the encoding in the above message may be modified such that IP version information for each APN is provided. However, the encoding of the APN string may be rather long. Thus, NSAPI can be used to identify the relevant PDP contexts, thereby avoiding the need to encode the APN itself. For example, it is possible to re-encode for IP version IEs, reusing NSAPI numbers (as shown in fig. 2).

IP version (2 bit field)

The new IE (which will include a length field for backward compatibility) may be shortened so that the IP version is sent only for the activated PDP contexts (aligned by 8-bit byte boundaries, of course). The IE may alternatively be inserted in a routing area accept message or a tracking area accept message, for example.

Another embodiment may be to enhance the (already existing) PDP context state information element sent in the routing area accept or tracking area accept message. The IE may be of variable length such that the IP version is sent only for the activated PDP contexts (aligned by 8-bit byte boundaries, of course). The IE may alternatively be inserted in a routing area accept or tracking area accept message.

It should be noted that the PDP context state information element may also be included in the routing area update request, service request and service accept (UMTS only) messages. Therefore, no extension on the IP version information (8-bit bytes 5 to 8) is added for these messages, or it can be specified that the receiver should ignore it.

Possible enhancements: reusing IP version information for UE cell reselection

As an enhancement, (e.g., if an application supports only IPv6), the UE may prefer a cell supporting IPv6 configuration when reselecting. Alternatively, it may prefer a cell supporting IPv4v6 configuration. For example, if another cell that is not the best cell is good enough and/or not too bad (for a given threshold) in terms of channel quality (RSCP, RSSI, Ec/NO, Rxqual, Rxlev) compared to the best cell, the UE may select that other cell. The cell reselection criteria to support this may be standardized or left to the UE implementation decision. In the first case, the value of the threshold may be indicated from the network to the UE.

Network accepted normal and periodic routing area update procedure

As used herein, the term "should" may also include "may" in some embodiments. Thus, the term "should" is not necessarily a stated requirement, but may in some embodiments be. Similarly, the terms "is" and "is" may also include "may" in some embodiments.

If the network has accepted the routing area update request, a routing area update accept message should be sent to the MS. The network may assign a new P-TMSI and/or a new P-TMSI signature for the MS. If the MS has been assigned a new P-TMSI and/or a new P-TMSI signature, it/they should be included in the routing area identity together with the routing area identity in the routing area accept message. In a shared network, the network should indicate the PLMN identity of the CN operator that has accepted the routing area update request in the RAI contained in the routing area update message (see 3gpp ts23.251[109 ]).

If the new DRX parameter is included in a routing area update request (routingareapdaterequest) message, the network should store the new DRX parameter and use it for downlink transmission of signaling and user data.

If the MS has indicated in the routingareaupdateqest message that it supports an inter-PSRAT handover to UTRANIu mode, the network may include a request to provide an inter-RAT information container in the ROUTINGAREAUPDATEACCEPT message.

If the MS has included either the MS network capability IE or the UE network capability IE, or both, in the ROUTINGAREAUPDATEREQUEST message, the network should store all 8-bit bytes accepted from MS1 up to the maximum length defined in the respective information element. In case the UE network capability IE indicates new information to the network, the MS should set the TIN to "P-TMSI".

Note that: this information is forwarded to the new SGSN during an inter-SGSN handover or to the new MME during an inter-system handover to S1 mode.

If the DRX parameters are included in the DRX parameter IE in the ROUTINGAREAUPDATEREQUEST message, the network should replace any stored DRX parameters with the received parameters and use them for downlink transmission of signaling and user data.

In the a/Gb mode, a cell notification information element should be included in the routing area update address message in order to indicate the network's capability to support cell notification.

The network should change to the state GMM-COMMON-PROCEDURE-INITIATED and the supervision timer T3350 should be started, as described in subclause 4.7.6.

If the LAI or PLMN identity contained in the routingareaupdataccespt message is a member of any "forbidden" list, any such entry should be deleted.

In Iu mode, the network should extend the PS signaling connection if the mobile station has indicated in the ROUTINGAREAUPDATEREQUEST that a request to continue is pending. The network may also extend the PS signaling connection without any indication from the mobile terminal.

If the PDP context state information element is included in the ROUTINGAREAUPDATEREQUEST message, the network should locally deactivate all those PDP contexts (no peer-to-peer signaling between the MS and the network) that are not in the SM state PDP-INACTIVE on the network side, but are being in the state PDP-INACTIVE as indicated by the MS.

If the MBMS context status information element is included in the ROUTINGAREAUPDATEREQUEST message, the network should locally deactivate all those MBMS contexts (no peer-to-peer signaling between the MS and the network) that are not in the SM state PDP-activate on the network side, but are indicated by the MS to be in the state PDP-activate. If no MBMS context status information element is included, the network should locally deactivate all MBMS contexts that are not in SM state PDP-activate on the network side.

Upon receiving the routingareaupdataaccept message, the MS stores the received routing area identification, stops the timer T3330, resets the routing area update attempt counter, and sets the GPRS update status to GU1 updated. If the message contains a P-TMSI, the MS should use the P-TMSI as a new temporary identity for GPRS services and should store the new P-TMSI. If the network does not include any P-TMSI in the routing update data accept message, the old P-TMSI will be maintained. In addition, if the MS receives a P-TMSI signature in a ROUTINGAREAUPDATEACEPT message, the MS will store the P-TMSI signature. If no P-TMSI signature is included in the message, the old P-TMSI signature, if any, will be deleted.

If a ROUTINGAREAUPDATEREQUEST message with a new DRX parameter IE is used to update the network, the MS should start using the new DRX parameter when receiving the routingareaupdataccespt message and should set TIN to "P-TMSI".

If the PDP context state information element is included in the routing area update data accept message, the MS should locally deactivate all those PDP contexts (no peer-to-peer signaling between the MS and the network) that are not in the SM state PDP-ACTIVE in the MS but are being in the state PDP-ACTIVE as indicated by the network.

If the MBMS context state information element is included in the routingareaupdataccespt message, the MS should locally deactivate all those MBMS contexts (no peer-to-peer signaling between the MS and the network) that are not in the SM state PDP-activate in the MS, but are in the state PDP-activate as indicated by the network. If no MBMS context state information element is included, the MS should locally deactivate all MBMS contexts that are not in SM state PDP-activate in the MS.

In the A/Gb mode, if the routing area update procedure message contains a cell notification information element, the MS should start performing a cell update using an LLC null frame.

If the MS supporting manual update of the CSG allowed list by the CSG receives the routingareaupdataccespt message, the MS should check whether the CSGID of the cell in which the MS has sent the routingareaupdatequest message is included in the allowed CSG list. If not, the MS should add the CSGID to the allowed CSG list.

The network may also send a list of "equivalent PLMNs" in a routingareaupdataaccept message. Each entry of the list contains a PLMN code (MCC + MNC). The mobile station should store the network-provided list, except that any PLMN code that is already in the "forbidden PLMN" list should be removed from the "equivalent PLMN" before the list is stored by the mobile station. In addition, the mobile station should add the PLMN code of the registered PLMN which transmitted the list to the stored list. All PLMNs in the stored list should be considered as equivalent to each other for PLMN selection, cell selection/reselection and handover. The list stored in the mobile station should be replaced each time a routingareaupdataccespt message occurs. If the list is not contained in the message, the list stored in the mobile station should be deleted. This list should be stored in the mobile station when switched off so that it can be used for PLMN selection when switched on.

If the PDP type IE in the ROUTINGAREAUPDATEACCEPT message indicates "single IPv4V 6", the MS should deactivate PDP contexts previously activated with "IPv 4V 6" and reactivate them independently (with V4PDP type, and V6PDP type in different PDP contexts).

If the PDP type IE in the ROUTINGAREAUPDATEACEPT message indicates "IPv 4" or "IPv 6", the MS should not request PDP contexts for other PDP types.

If the routing area update address message contains any of the following: P-TMSI, receiving N-PDU numbers (see 3gpp ts44.065[78] and 3gpp ts25.322[19b ]), or a request to provide inter-RAT handover information or E-UTRANRAT handover information or both, a routing area update complete message should be returned to the network.

If a received N-PDU number is included, the value of the received N-PDU number valid in the MS should be included in the routing _ GAREAUPDATECOMPLETE message.

If the network has requested to provide inter-RAT handover information or E-UTRA inter-RAT handover information or both, the MS should return a ROUTINGAREAUPDATECOMPLETE message including an inter-RAT handover information IE or an E-UTRA inter-RAT handover information IE or both.

Note 1: in Iu mode, after the routing area update procedure, if the network has released resources, the mobile station may initiate a service request procedure to request resource reservation for the activated PDP context, or send an upper layer message (e.g., activate PDP context request) to the network via the existing PS signaling connection.

In Iu mode, if the network wishes to extend the PS signaling connection (e.g., if the mobile station has indicated "continue request pending" in the routineeareadaterequest message), the network should indicate "proceed" in the routineeareadateaccecept message. If the network wishes to release the PS signaling connection, the network should indicate "do not proceed" in the routingareaupdataccespt message.

After that, in Iu mode, the mobile station should act according to the proceed flag included in the update result information element in the routingareaupdataccespt message (see subclause 4.7.13).

The network may also send a list of local emergency numbers in the routing area update address by including an emergency number list IE. The mobile device should store the network provided list, only any emergency numbers already stored in the SIM/USIM should be removed from the list before the list is stored by the mobile device. If no emergency numbers are stored on the SIM/USIM, the mobile device should remove from the list any emergency numbers permanently stored in the ME for use in this case (see 3gpp ts22.101[8]) before storing the received list. This list stored in the mobile device should be replaced each time a new emergency number list IE is received.

The emergency number received in the emergency number list IE is valid only in networks having MCCs that are the same as the MCC in the cell on which the IE is received. If the list is not included in the routing area update address message, the list stored in the mobile device should be maintained unless the mobile device has successfully registered with a PLMN having an MCC different from the MCC of the last registered PLMN.

In addition to the emergency numbers stored on the SIM/USIM or ME, the mobile device should also use a stored list of emergency numbers received from the network to detect that the dialed number is an emergency number.

Note 2: the mobile device may use the emergency number list to help the end user determine whether the dialed number is intended for emergency services or for another destination (e.g., local directory service). The possible exchanges with the end user differ from implementation to implementation.

The list of emergency numbers should be deleted when the SIM/USIM is turned off and removed. The mobile device should be able to store up to ten local emergency numbers received from the network.

To indicate to the MS that the GUTI and TAI lists assigned to the MS are still registered to the network and valid in the MS, the network should indicate in the update result IE in the routingareaupdataaccept message that the ISR is activated.

If the routing area update address message contains: i) an indication that no ISR is activated; or ii) an indication that ISR is activated, then in case i) the MS supporting S1 mode should set TIN to "P-TMSI", or in case ii) the MS should consider the available GUTI and TAf lists as valid and register to the network. If the TIN currently indicates "GUTI", the MS should set the TIN to "RAT dependent TMSI".

Turning now to fig. 2, an information element 200 is depicted. The IP version information element identification 202 may include the first 8 bits (8-bit byte 1). The IP version information element length field 204 may include the second 8 bits (8-bit byte 2). The encoding 206 of the IP version associated with each APN may each be encoded with 8 bits (8-bit bytes 3 to 8-bit bytes 6). The NSAPI number referenced in this information element field points to a specific PDP context and thus to a specific APN. In an embodiment, the restriction of the information element 200 to 11 PDP contexts may be established to comply with the maximum number of PDP contexts of the existing 3 GPP. In an embodiment, only those APNs associated with an activated PDP context may be encoded and the information element 200 may be shortened when fewer APNs are in use.

Turning again to fig. 1, in an embodiment, when the first access point 110 is a GERAN access point, the first access point 110 may broadcast a system information message that includes information indicating the IP addressing types supported by the first access point 110. Similarly, when the first access point 110 is a UTRAN access point, the first access point 110 may broadcast a system information message that includes information indicating the IP addressing types supported by the first access point 110. For example, the IP version field may appear at the end of system information block type 1(SIB 1). Optionally, the PS domain specific system information in the NAS system information portion of SIB1 may be enhanced to add an IP version field. As described further above with reference to fig. 2, in either the GERAN, UTRAN, or LTE cases, the IP version field in the broadcasted system information message may encode the IP addressing type for the access point. In an embodiment, the first UE120 may know and/or identify the neighboring access point 110/126 and/or other neighboring access points by reading the system information broadcast by each of the access points 110, 126.

In an embodiment, where first UE120 identifies multiple suitable serving access points, first UE120 may reselect to an access point that supports an IP addressing type preferred by first UE120 (e.g., required by one or more applications executed by first UE 120). For example, when the first UE120 is configured for IPv6 addressing, the first UE120 may select to an access point that also supports IPv6 addressing, rather than another access point that only supports IPv4 addressing. Alternatively, when the first UE120 is configured for IPv4 addressing, the first UE120 may select to an access point that also supports IPv4 addressing, rather than another access point that only supports IPv6 addressing. Alternatively, when the first UE120 is configured for IPv4v6 addressing, the first UE120 may select to an access point that also supports IPv4v6 addressing, rather than other access points that support only IPv6 addressing or only IPv4 addressing. In an embodiment, the first UE120 may select other access points that are different from the best access point (e.g., the access point that provides the best coverage, the access point that is least overloaded, and/or the best access point according to other criteria) if the access point does not differ from the best access point by a given value, e.g., the difference between the channel qualities of the best cell and the candidate cell does not exceed a particular value (e.g., RSCP, RSSI, Ec/NO, Rxqual, Rxlev, or any combination thereof). In an embodiment, if another access point than the best access point is good enough or exceeds a standard threshold, such as a minimum channel quality (e.g., RSCP, RSSI1, Ec/NO, Rxqual, Rxlev, or any combination thereof), the first UE120 may select the other access point than the best access point (e.g., the access point providing the best coverage, the access point least overloaded, and/or the best access point according to other criteria).

Turning now to fig. 3, a method 300 of wireless communication is described. In step 302, the first UE120 detects one of the following events: the first UE120 changes routing area and the first UE120 changes radio access technology from the LTE network to the GERAN/UTRAN network. In step 304, based on the detection in step 302, the first UE120 sends a message deactivating the PDP context or EPS bearer.

Turning now to fig. 4, a method 320 of wireless communication is described. In step 320, the second access node 136 sends a mobility message that includes an IP version field that identifies the type of IP addressing supported by the second access node 136.

Turning now to FIG. 5, a method 340 is depicted. In step 340, the second access node 126 broadcasts a system information message that includes an IP version field that identifies the type of IP addressing supported by the access node.

Turning now to FIG. 6, a method 350 is depicted. In step 352, the first UE120 identifies a plurality of access points, e.g., access nodes 110, 126, that may provide suitable coverage to the first UE 120. In some contexts, the plurality of access nodes may be referred to as candidate access nodes. Based on the system information broadcast by the access nodes 110, 126, including the IP version field, the first UE120 determines that the second access node 126 supports the IP addressing type most appropriate for the application on the first UE120 and selects to the second access node 126.

Turning now to FIG. 7, a method 360 is depicted. In step 362, the first UE120 powers up and reads system information broadcast by the first access node 110 on which the first UE120 camps. In step 364, the first UE120 determines from the system information broadcast by the first access node 110 (e.g., by reading an IP version information element of the system information) that the first access node 110 does not support the particular IP addressing version. In step 366, first UE120 does not attempt to activate a PDP context associated with an application of first UE120 that utilizes a particular IP addressing version not supported by first access node 110.

The UE120 and other components described above may include processing components capable of executing instructions related to the actions described above. Fig. 8 illustrates an example of a system 1300, the system 1300 including a processing component 1310 suitable for implementing one or more embodiments disclosed herein. In addition to the processor 1310, which may be referred to as a central processing unit or CPU, the system 1300 may include a network connectivity devices 1320, a Random Access Memory (RAM)1330, a Read Only Memory (ROM)1340, secondary storage 1350, and input/output (I/O) devices 1360. These components may communicate with each other via a bus 1370. In some cases, some of these components may not be present, or may be combined in various combinations with each other or with other components not shown in the figures. These components may be located in a single physical entity or may be located in more than one physical entity. Any actions described herein as being performed by the processor 1310 may be performed by the processor 1310 alone, or by the processor 1310 in conjunction with one or more components (e.g., a Digital Signal Processor (DSP)1302) that are shown or not shown in the figures. Although the DSP502 is shown as a separate component, the DSP502 could be incorporated into the processor 1310.

The processor 1310 executes instructions, codes, computer programs, or scripts that it may access from the network connectivity devices 1320, RAM1330, ROM1340, or secondary storage 1350 (which may include various disk-based systems, such as hard disk, floppy disk, or optical disk). Although only one CPU1310 is shown, multiple processors may be present. Thus, although instructions may be discussed as being executed by a processor, instructions may be executed simultaneously, serially, or otherwise by one or more processors. The processor 1310 may be implemented as one or more CPU chips.

The network connectivity devices 1320 may take the form of: modems, modem banks, ethernet devices, Universal Serial Bus (USB) interface devices, serial interfaces, token ring devices, Fiber Distributed Data Interface (FDDI) devices, Wireless Local Area Network (WLAN) devices, radio frequency transceiver devices (e.g., Code Division Multiple Access (CDMA) devices such as UTRA, LTE, or CDMA2000), global system for mobile communications (GSM) wireless transceiver devices, Worldwide Interoperability for Microwave Access (WiMAX) devices, and/or other well-known devices for connecting networks. These network connectivity devices 1320 may enable the processor 1310 to communicate with the internet or one or more telecommunications networks, or other networks from which the processor 1310 may receive information or to which the processor 1310 may output information. The network connectivity devices 1320 may also include one or more transceiver components 1325, the transceiver components 1325 capable of wirelessly transmitting and/or receiving data.

The RAM1330 may be used to store volatile data and perhaps to store instructions that are executed by the processor 1310. The ROM1340 is a non-volatile memory device that typically has a smaller memory capacity than the memory capacity of the secondary storage 1350. ROM1340 may be used to store instructions and to store data that may be read during execution of the instructions. Access to both RAM1330 and ROM1340 is typically faster than to secondary storage 1350. The secondary storage 1350 is typically comprised of one or more disk drives or tape drives and may be used for non-volatile storage of data or as an over-flow data storage device if RAM1330 is not large enough to hold all working data. Secondary storage 1350 may be used to store programs that are loaded into RAM1330 when such programs are selected for execution.

The I/O devices 1360 may include Liquid Crystal Displays (LCDs), touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, printers, video monitors, or other well-known input devices. Likewise, the transceiver 1325 may be considered a component of the I/O device 1360, not a component of the network connectivity devices 1320, or a component of the network connectivity devices 1320 as well.

Various combinations of components of system 1300, including memory, hardware, firmware, software, or others, may be referred to herein as "components.

The following specifications are incorporated herein by reference for all purposes: 3gpp ts23.060, 3gpp ts23.401, 3gpp ts24.008, 3gpp ts24.301, 3gpp ts25.331, 3gpp ts36.331, 3gpp ts44.018, and 3gpp ts 44.060.

In an embodiment, a User Equipment (UE) is disclosed. The UE includes at least one component configured to detect one of the following events: detecting a change in routing area by the UE and a change in radio access technology by the UE from a Long Term Evolution (LTE) network to a Global System for Mobile communications, GSM, evolved enhanced data rates radio Access network (GERAN) or Universal Mobile Telecommunications System terrestrial radio Access network (UTRAN); and in response to detecting the event, deactivating one of a first Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer.

In an embodiment, an access node is disclosed. The access node comprises at least one component configured to: sending a mobility message to a User Equipment (UE), the mobility message including an Internet Protocol (IP) version field identifying a supported Internet protocol addressing type.

In an embodiment, a User Equipment (UE) is disclosed. The UE includes a component configured to: decoding an internet protocol version field in the mobility message, and adapting a data communication function of the UE based on the Internet Protocol (IP) version field.

In an embodiment, an access node is disclosed. The access node comprises a component configured to: broadcasting a system information message that includes an Internet Protocol (IP) version field that identifies a type of internet protocol addressing supported by a core network associated with the access node.

In an embodiment, a method of wireless communication is disclosed. The method comprises the following steps: a User Equipment (UE) detects one of the following events: the UE changes routing area and the UE changes radio access technology from a Long Term Evolution (LTE) network to a global system for mobile communications, GSM, evolved enhanced data rates radio access network (GERAN) or universal mobile telecommunications system terrestrial radio access network (UTRAN). Further comprising the UE sending a message to deactivate one of a first Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer based on detecting the event.

In an embodiment, a method of wireless communication is disclosed. The method includes an access node sending a mobility message containing an Internet Protocol (IP) version field identifying a type of internet protocol addressing supported by the access node.

In an embodiment, a method of wireless communication is disclosed. The method includes the access node broadcasting a system information message including an internet protocol version field identifying an internet protocol addressing type supported by the access node

In an embodiment, a method of wireless communication is disclosed. The method comprises the following steps: a User Equipment (UE) identifies a plurality of access points that are candidates for serving the UE, and the UE selects one of the access points based on a type of internet protocol addressing supported by the selected access point.

In an embodiment, a method of wireless communication is disclosed. The method includes a User Equipment (UE) powering on and reading system information broadcast by an access node on which the UE is camped, the UE determining that the access node does not support a particular internet protocol addressing type, and the UE not activating a Packet Data Protocol (PDP) context of an Evolved Packet System (EPS) bearer associated with an application utilizing the particular internet protocol addressing type that is not supported by the access node.

In an embodiment, a user equipment is disclosed. The user equipment comprises at least one component configured to: the method includes determining an internet protocol addressing version of the access node, and deactivating one of a Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer in response to determining the internet protocol addressing version of the access node.

In an embodiment, a user equipment is disclosed. The user equipment comprises at least one component configured to: a timeout of a data transfer of an application is detected. In response to detecting a timeout for data transfer of the application, the component is further configured to deactivate one of a first Packet Data Protocol (PDP) context based on the first internet protocol addressing version and an Evolved Packet System (EPS) bearer based on the first internet protocol addressing version, wherein the one of the PDP context and the EPS bearer is associated with the application. The component is further configured to reactivate the one of the PDP context and the EPS bearer based on the second internet protocol addressing version.

Embodiments also provide a User Equipment (UE) comprising a processor configured to: receiving a message; and in response to the message indicating the first Internet Protocol (IP) version type, deactivating at least one of a Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer associated with the second IP version type, wherein the at least one of a Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer has been previously activated by the UE.

Embodiments also provide an access node comprising at least one component configured to: one of a mobility message or a system information message is sent to a User Equipment (UE), wherein the mobility message or the system information message includes an Internet Protocol (IP) version field identifying a supported internet protocol addressing type.

Embodiments also provide a User Equipment (UE) comprising a processor configured to: decoding an Internet Protocol (IP) version field in the mobility message, and adapting a data communication function of the UE based on the IP version field.

Embodiments also provide a User Equipment (UE) comprising at least one component configured to: the method includes determining an internet protocol addressing version of the access node, and deactivating one of a Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer in response to determining the internet protocol addressing version of the access node.

Embodiments also provide a User Equipment (UE) comprising at least one component configured to: detecting a timeout of a data transfer of an application; and in response to detecting a timeout for data transfer of the application, deactivating one of a first Packet Data Protocol (PDP) context based on the first internet protocol addressing version and an Evolved Packet System (EPS) bearer based on the first internet protocol addressing version, wherein the one of the PDP context and the EPS bearer is associated with the application; and reactivate one of the PDP context and EPS bearer based on a second internet protocol addressing version.

Embodiments also provide a method implemented in a User Equipment (UE), the method comprising: receiving a message; and in response to the message indicating the first Internet Protocol (IP) version type, deactivating at least one of a Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer associated with the second IP version type, wherein the at least one of a Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer has been previously activated by the UE.

Embodiments also provide a method implemented in a User Equipment (UE), the method comprising: determining an internet protocol addressing version of an access node; and deactivating one of a Packet Data Protocol (PDP) context and an Evolved Packet System (EPS) bearer in response to determining the internet protocol addressing version of the access node.

Embodiments also provide a method implemented in a User Equipment (UE), the method comprising: detecting a timeout of a data transfer of an application; in response to detecting a timeout for data transfer of an application, deactivating one of a Packet Data Protocol (PDP) context based on a first Internet protocol addressing version and an Evolved Packet System (EPS) bearer based on the first Internet protocol addressing version, wherein the one of the PDP context and the EPS bearer is associated with the application; and reactivate one of the PDP context and EPS bearer based on a second internet protocol addressing version.

Several embodiments have been provided in the present disclosure, and it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein. For example, various elements or components may be combined or incorporated in other systems, or certain features may be omitted, or not implemented.

Moreover, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the spirit or scope of the present disclosure. Other items shown and discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other changes, substitutions, and alterations are also contemplated by and may be made by those having ordinary skill in the art without departing from the spirit and scope of the description herein.

Claims (38)

1. An apparatus to be implemented in a User Equipment (UE), the apparatus comprising:

means for activating, via a first access node, one of a packet data protocol "PDP" context and an evolved packet System "EPS" bearer using a first Internet protocol "IP" version type;

means for receiving a message from a second access node during a handover from the first access node to the second access node; and

means for deactivating said one of said PDP context and said EPS bearer associated with said first IP version type in response to said message indicating a second IP version type.

2. The apparatus of claim 1, further comprising:

means for receiving a message with a second IP version type of IPv 6; and

means for deactivating a PDP context for a first IP version type IPv4v 6.

3. The apparatus of claim 2, further comprising:

means for reactivating the PDP context of the second IP version type IPv 6.

4. The apparatus of claim 1, further comprising:

means for receiving a message with a second IP version type of IPv 4; and

means for deactivating a PDP context for a first IP version type IPv4v 6.

5. The apparatus of claim 4, further comprising:

means for reactivating the PDP context of the second IP version type IPv 4.

6. The apparatus of claim 1, further comprising:

means for receiving a message with a second IP version type of single IPv4v 6; and

means for deactivating a PDP context for a first IP version type of dual IPv4v 6.

7. The apparatus of claim 5, further comprising:

means for reactivating the PDP context with IP version type IPv 4.

8. The apparatus of claim 5, further comprising:

means for reactivating the PDP context with IP version type IPv 6.

9. The apparatus of claim 1, further comprising:

means for reactivating at least one of a second PDP context and a second EPS bearer associated with a second IP version type.

10. The apparatus of claim 9, further comprising:

means for reactivating at least one of a third PDP context and a third EPS bearer associated with the second IP version type, wherein the reactivation of the at least one of the third PDP context and the third EPS bearer is performed separately from the reactivation of the at least one of the second PDP context and the second EPS bearer.

11. The apparatus of claim 1, further comprising:

means for reactivating a plurality of PDP contexts, wherein the reactivating of the plurality of PDP contexts is performed separately.

12. The apparatus of claim 1, further comprising:

means for deactivating at least one of a second PDP context and a second EPS bearer associated with the first IP version type, wherein the at least one of the second PDP context and the second EPS bearer has been previously activated by the UE.

13. The apparatus of claim 12, further comprising:

means for reactivating at least one of a third PDP context and a third EPS bearer associated with the second IP version type.

14. The apparatus of claim 1, further comprising:

means for avoiding reactivation of the one of the PDP context and the EPS bearer associated with the first IP version type.

15. An apparatus to be implemented in a User Equipment (UE), the apparatus comprising:

means for activating, via a first access node, one of a packet data protocol "PDP" context and an evolved packet System "EPS" bearer using a first Internet protocol "IP" version type;

means for receiving a mobility message from a second access node during a handover from the first access node to the second access node;

means for decoding an IP version field in the mobility message indicating a second IP version type;

means for deactivating said one of said PDP context and said EPS bearer associated with said first IP version type in response to said mobility message indicating a second IP version type; and

means for adapting data communication functions of the UE based on the second IP version type.

16. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for dual IP version 4 and version 6 "IPv 4v 6" type addressing before the UE receives the mobility message, and further comprising:

means for deactivating a PDP context or an EPS bearer associated with an application of the UE using IP version 6 type addressing when the IP version field indicates IP version 4 type addressing.

17. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for dual IP version 4 and version 6 "IPv 4v 6" type addressing before the UE receives the mobility message, and further comprising:

means for deactivating a PDP context or an EPS bearer associated with an application of the UE using IP version 4 type addressing when the IP version field indicates IP version 6 type addressing.

18. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for IP version 4 "IPv 4" type addressing before the UE receives the mobility message, and the apparatus further comprises:

means for deactivating a PDP context of the UE when the IP version field indicates IP version 6 type addressing.

19. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for IP version 6 "IPv 6" type addressing before the UE receives the mobility message, and the apparatus further comprises:

means for deactivating a PDP context of the UE when the IP version field indicates IP version 4 type addressing.

20. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for dual IP version 4 and version 6 "IPv 4v 6" type addressing before the UE receives the mobility message, and further comprising:

means for deactivating a PDP context or EPS bearer using dual hybrid IPv4 and IPv6 version type addressing when the IP version field indicates IP version 4 and 6 single type addressing "single IPv4v 6".

21. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for dual IP version 4 and version 6 "IPv 4v 6" type addressing before the UE receives the mobility message, and further comprising:

means for activating a PDP context or EPS bearer for IPv4 version type addressing when the IP version field indicates IP version 4 and 6 single type addressing "single IPv4v 6".

22. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for dual IP version 4 and version 6 "IPv 4v 6" type addressing before the UE receives the mobility message, and further comprising:

means for activating a PDP context or EPS bearer for IPv6 version type addressing when the IP version field indicates IP version 4 and 6 single type addressing "single IPv4v 6".

23. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for dual IP version 4 and version 6 "IPv 4v 6" type addressing before the UE receives the mobility message, and further comprising:

means for activating a PDP context or EPS bearer for IPv6 version type addressing when the IP version field indicates IP version 6 type addressing.

24. The apparatus of claim 15, wherein at least one of the UE, the PDP context, and the EPS bearer context is configured for dual IP version 4 and version 6 "IPv 4v 6" type addressing before the UE receives the mobility message, and further comprising:

means for activating a PDP context or EPS bearer for IPv4 version type addressing when the IP version field indicates IP version 4 type addressing.

25. The apparatus of claim 15, wherein the mobility message is one of: a mobility fromareutrali command message, a physical channel reconfiguration message, a cell change command message from UTRAN, a PS handover command message, a cell change command message, a RAU accept message, a tracking area update accept message, and an attach accept message.

26. An apparatus to be implemented in a User Equipment (UE), the apparatus comprising:

means for activating, via a first access node, one of a packet data protocol "PDP" context and an evolved packet System "EPS" bearer using a first Internet protocol "IP" addressing version;

means for receiving a message from a second access node during a handoff from the first access node to the second access node, wherein the message indicates a second IP addressing version of the second access node;

means for determining that a second IP addressing version of the second access node is different from the first IP addressing version; and

means for deactivating said one of said PDP context and said EPS bearer in response to determining that a second IP addressing version of said second access node is different from said first IP addressing version.

27. The apparatus of claim 26, wherein the means for determining determines that the second IP addressing version of the second access node is different from the first IP addressing version by reading an IP version field sent by the second access node in one of a mobility message and a system information message.

28. The apparatus of claim 26, further comprising: means for reactivating the one of the PDP context and the EPS bearer based on a second IP addressing version of the second access node.

29. A method implemented in a User Equipment (UE), the method comprising:

activating, via a first access node, one of a packet data protocol "PDP" context and an evolved packet system "EPS" bearer using a first internet protocol "IP" version type;

receiving a message from a second access node during a handover from the first access node to the second access node; and

deactivating said one of said PDP context and said EPS bearer associated with said first IP version type in response to said message indicating a second IP version type.

30. The method of claim 29, further comprising:

reactivating at least one of a second PDP context and a second EPS bearer associated with the second IP version type.

31. The method of claim 30, further comprising:

reactivating at least one of a third PDP context and a third EPS bearer associated with the second IP version type, wherein the reactivation of the at least one of the third PDP context and the third EPS bearer is performed separately from the reactivation of the at least one of the second PDP context and the second EPS bearer.

32. The method of claim 29, further comprising:

reactivating a plurality of PDP contexts, wherein the reactivating of the plurality of PDP contexts is performed separately.

33. The method of claim 29, further comprising:

deactivating at least one of a second PDP context and a second EPS bearer associated with the first IP version type, wherein the at least one of the second PDP context and the second EPS bearer has been previously activated by the UE.

34. The method of claim 33, further comprising:

reactivating at least one of a third PDP context and a third EPS bearer associated with the second IP version type.

35. The method of claim 29, further comprising:

refraining from reactivating the one of the PDP context and the EPS bearer associated with the first IP version type.

36. A method implemented in a User Equipment (UE), the method comprising:

activating, via the first access node, one of a packet data protocol "PDP" context and an evolved packet system "EPS" bearer using a first internet protocol "IP" addressing version;

receiving a message from a second access node during a handover from the first access node to the second access node, wherein the message indicates a second IP addressing version of the second access node;

determining that a second IP addressing version of the second access node is different from the first IP addressing version; and

deactivating said one of said PDP context and said EPS bearer in response to determining that a second IP addressing version of said second access node is different from said first IP addressing version.

37. The method of claim 36, further comprising:

determining that a second IP addressing version of the second access node is different from the first IP addressing version by reading an IP version field sent by the second access node in one of a mobility message and a system information message.

38. The method of claim 36, further comprising:

reactivating the one of the PDP context and the EPS bearer based on a second IP addressing version of the second access node.