JP5452631B2 - Implementing handoff for multiple packet data network connections - Google Patents

Description

CROSS REFERENCE TO RELATED APPLICATIONS The present invention has the priority of US Provisional Application No. 61 / 428,844, title of invention, “Enabling Handoff for Multiple Packet Data Network Connections” filed December 30, 2010. Insist.

  The entire contents of this provisional application are incorporated by reference as part of the present application.

  The present invention relates to wireless communications, wireless communication devices, wireless communication systems, and related methods.

  A wireless communication system includes one or more wireless devices such as mobile devices, mobile phones, wireless air cards, mobile stations (MS), user equipment (UE), and access terminals (AT). Or it may include a network of one or more base stations in communication with a subscriber station (SS). Each base station can transmit wireless signals carrying data, eg, voice data and other data content, to the wireless device. A base station can also be called an access point (AP) or an access network (AN), and may be included in a part of the access network. Further, the wireless communication system communicates with each other or with a wired communication system via one or more core networks. A wireless device may use one or more different wireless technologies (often simultaneously) for communication. Specific examples of various radio technologies include code division multiple access (CDMA), for example, CDMA2000 1x, HRPD (High Rate Packet Data), GSM (Global System for Mobile communications) technology, LTE ( Long-Term Evolution, orthogonal frequency-division multiplexing (OFDM), WiMAX (Worldwide Interoperability for Microwave Access), and the like are included. In some implementations, a wireless communication system can include multiple networks using different wireless technologies.

  As the use and diversity of UEs (eg, smartphones, phones with multiple network interfaces, etc.) increases, it relates to providing seamless connectivity to UEs when they roam between different networks. Technical challenges are also increasing.

  There is a need for a technique that allows handoff between multiple packet data network connections.

  Here, in particular, a technique for wireless communication is disclosed.

  In one aspect, a handover target that does not support multiple coexisting PDN connections from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections. When roaming to the AN, a step of selecting a single PDN connection from a plurality of active PDN connections for operation within the handover target AN, and exchanging messages within the handover target AN A method for wireless communication comprising: registering a PDN connection of

  In another aspect, an apparatus for wireless communication is disclosed. When a device roams from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections, Means for selecting a single PDN connection from a plurality of active PDN connections for operation within the AN, and means for exchanging messages to register a single PDN connection within the handover target AN. Prepare.

  In yet another aspect, a computer program product comprising a computer readable non-volatile medium is disclosed. When a roaming from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections, Instructions for selecting a single PDN connection from multiple active PDN connections for operation within the AN and access point name (APN) maintained during operation within the handover target AN And a command to pre-register a PDN connection.

  According to another aspect of the wireless communication method disclosed in the present invention, an access is performed by executing a proxy binding update / proxy binding acknowledge (PBU / PBA) procedure in a current access network (AN). User equipment from a current AN that supports multiple coexisting packet data network (PDN) connections to a point name (APN) to a handover target AN that does not support multiple coexisting PDN connections to an APN Providing a network gateway server for assisting roaming. The PBU / PBA procedure includes learning whether a gateway server in the target AN supports multiple PDN connections to the APN and assisting pre-registration of PDN connections in the target AN. .

  In yet another aspect, a system for wireless communication supports multiple coexisting PDN connections from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections. When roaming to no handover target AN, for operation within the handover target AN, a single PDN connection is selected from multiple active PDN connections, messages are exchanged, and within the handover target AN, Perform a proxy binding update / proxy binding response (PBU / PBA) procedure in the current access network (AN) with the user equipment configured to register one PDN connection, and access point name (APN Multiple co-existing packet data networks Providing a network gateway server to assist in roaming user equipment from a current AN supporting work (PDN) connection to a handover target AN not supporting multiple coexisting PDN connections to the APN; A gateway server configured to learn whether the gateway server in the network supports multiple PDN connections to the APN and to assist in the preliminary registration of the PDN connection in the target AN.

  The details of one or more embodiments are set forth in the accompanying documents, drawings and description below. Other features will be apparent from the detailed description, drawings, and claims.

It is a figure which shows the specific example of a radio | wireless communications system. It is a figure which shows the specific example of a radio station architecture. 1 is a block diagram illustrating an example E-UTRAN-eHRPD network architecture. FIG. It is a figure which shows the specific example of the correlation of a bearer and a signaling path | pass regarding the successful handover. FIG. 4 illustrates the addition of a PDN connection in the MUPSAP source access architecture. FIG. 7 illustrates deletion of a PDN connection in a MUPSAP source access architecture. FIG. 6 illustrates exemplary messages exchanged during eHRPD pre-registration via E-UTRAN. FIG. 7 illustrates an example message exchanged during eHRPD pre-registration over E-UTRAN when the HSGW does not support MUPSAP. FIG. 7 illustrates exemplary messages exchanged during an active mode optimized handoff from E-UTRAN to eHRPD. FIG. 6 illustrates exemplary messages exchanged during an active mode optimized handoff from E-UTRAN to eHRPD when the P-GW does not support MUPSAP. FIG. 6 illustrates exemplary messages exchanged during an idle mode optimized handoff from E-UTRAN to eHRPD. FIG. 7 illustrates exemplary messages exchanged during an idle mode optimized handoff from E-UTRAN to eHRPD when the P-GW does not support MUPSAP. FIG. 7 illustrates exemplary messages exchanged during an unoptimized handoff from E-UTRAN to eHRPD assuming a partial HSGW context. FIG. 6 illustrates an example message exchanged during an unoptimized handoff from E-UTRAN to eHRPD assuming a null HSGW context. FIG. 6 illustrates an example message exchanged during an unoptimized handoff from E-UTRAN to eHRPD assuming there is no existing eHRPD session. 2 is a flowchart of a process for wireless communication. It is a block diagram of a part of radio | wireless communication apparatus. 2 is a flowchart of a process for wireless communication. It is a block diagram of a part of radio | wireless communication apparatus.

  Like reference symbols in the various drawings indicate like elements.

  Hereinafter, a technique for assisting wireless communication will be described. The technology disclosed herein is useful in one aspect to enable handoff for multiple packet data network connections.

  FIG. 1 shows a specific example of a wireless communication system. The wireless communication system may include one or more base stations (BS) 105a, 105b, one or more wireless devices 110 and an access network 125. Base stations 105a and 105b can provide wireless services to wireless devices 110 in one or more wireless sectors. In some implementations, the base stations (eg, 105a, 105b) include directional antennas and generate two or more directional beams to provide radio coverage in different sectors.

  The access network 125 can communicate with one or more base stations 105, 105b. In some implementations, one or more base stations 105, 105 b are included in the access network 125. In some implementations, the access network 125 communicates with a core network (not shown in FIG. 1) that provides connectivity with other wireless and wired communication systems. The core network may include one or more service subscription databases that store information related to subscribed wireless devices 110. The first base station 105 can provide a radio service based on the first radio access technology, and the second base station 105 can provide a radio service based on the second radio access technology. The base stations 105 may be installed at the same place or separated in the field according to a deployment scenario. The access network 125 can support a number of different radio access technologies.

  Various examples of wireless communication systems and access networks in which the techniques and systems of the present invention can be implemented include, among others, wireless communication systems based on Code Division Multiple Access (CDMA), such as CDMA2000 1x. , HRPD (High Rate Packet Data), eHRPD (evolved HRPD), UMTS (Universal Mobile Telecommunications System), UTRAN (Universal Terrestrial Radio Access Network), E-UTRAN (Evolved UTRAN), LTE (Long-Term Evolution), WiMAX ( Worldwide Interoperability for Microwave Access). In some implementations, a wireless communication system can include multiple networks using different wireless technologies. A dual-mode or multi-mode wireless device includes two or more wireless technologies that can be used to connect to different wireless networks. In some implementations, the wireless device can support simultaneous voice-data operation (SV-DO).

  FIG. 2 is a block diagram of a part of the wireless station 205. For example, a wireless station 205, which is a base station or a wireless device, can include a processor circuit 210, such as a microprocessor, that implements one or more of the wireless technologies disclosed herein. The wireless station 205 can include a transceiver circuit 215 that transmits and / or receives wireless signals via one or more communication interfaces, such as an antenna 220. The wireless station 205 can include other communication interfaces for transmitting and receiving data. The wireless station 205 can include one or more memories configured to store information such as data and / or instructions. In some implementations, the processor circuit 210 can include at least a portion of the transceiver circuit 215.

  In some implementations, the wireless stations 205 can communicate with each other based on a CDMA air interface. In some implementations, the wireless stations 205 can communicate with each other based on an orthogonal frequency-division multiplexing (OFDM) air interface, which can communicate with the orthogonal frequency division multiple access (Orthogonal). Frequency-Division Multiple Access (OFDMA) air interface can be included. In some implementations, the wireless station 205 may communicate using one or more wireless technologies, such as CDMA such as CDMA2000 1x, HRPD, WiMAX, LTE, and Universal Mobile Telecommunications System (UMTS). it can.

  In an eHRPD (enhanced High Rate Packet Data) network defined by 3GPP2, the UE provides an IP service by attaching to an Evolved Packet System (EPS). EPS is specified by 3GPP TS 23.402 and other related specifications. The HRPD Serving Gateway (HSGW) is a network edge entity that provides a connection between the eHRPD network defined by 3GPP2 and the EPS system specified by the 3GPP standards body. Details of HSGW functions and capabilities are defined by the 3GPP2 TSG-X working group.

  An eHRPD network including User Equipment (UE) and HSGW is configured to assign multiple IPv4 and / or IPv6 addresses to the UE for each application running on different PDNs, thereby allowing multiple packet data networks (Packet Data Network: Provides an IP environment that supports attachment to PDN). The PDN, also called an access point name (APN), resides in the EPS core network detailed in the 3GPP specification. As a specific example of a simultaneous application in a UE homed by a plurality of PDNs, an Internet browsing application that operates on the UE while a peer entity is in the Internet domain can be cited. At the same time, the UE may have an ongoing conference call application anchored to the corporate domain. Such a concept of supporting multiple simultaneous applications in multiple PDNs is supported by 3GPP2 revision 0 “E-UTRAN-eHRPD Connection Specification” (X.S0057-0). In the 3GPP domain, a set of equivalent specifications is called a Release 8 specification.

  Release 9 of the 3GPP specification advances the concept of multiple simultaneous applications on the UE by allowing multiple applications to run in the same PDN domain. This concept is called “Multiple PDN Connections to an APN (MUPSAP)”. For example, MUPSAP allows two or more applications, such as Internet browsing, FTP downloads, and conference calls, to be executed simultaneously within a corporate domain. In this case, an individual IPv4 address and / or IPv6 address is assigned to the UE for each application that is homed on the same company (PDN) domain. The 3GPP2TSG-X working group is developing such MUPSAP capabilities in 3GPP2 revision A “E-UTRAN / eHRPD Connection Specification” (X.S0057-a).

  FIG. 3 shows a specific example of the E-UTRAN-eHRPD interworking architecture.

eHRPD: Enhanced High Rate Packet Data
EPC: Evolved Packet Core
E-UTRAN: Evolved UTRAN (also called LTE)
Interworking between 3GPP E-UTRAN network and 3GPP2 eHRPD network 3GPP TS 23.402 and related specifications, and 3GPP2 X. The protocol specified in the S0057 specification supports interworking between E-UTRAN (LTE) and eHRPD networks. Seamless inter-technology mobility of calls is supported when a UE moves between the coverage area of an E-UTRAN network and the coverage area of an eHRPD RAT (Radio Access Technology / Type) network. The Such inter-technology mobility / handoff is classified as (a) optimized handoff / handover and (b) non-optimized handoff / handover.

  Optimized handoff / handover is from E-UTRAN to eHRPD using signaling tunneled between the source access network and the target access network (ie, S101 signaling via the S101 interface shown in the architecture diagram) , Or vice versa, with UE movement. While in the source access network, the UE tunnels signaling to the target access network through the source access network and performs “pre-register”, ie, both radio and IP context Create on the target system. After pre-registration, the UE performs a radio level handoff / handover to the target technology. Optimized handoff / handover applies to both active and idle (dormant) UEs.

  Non-optimized handoff / handover refers to UE movement from E-UTRAN to eHRPD or vice versa that does not use signaling tunneled between the source and target access networks (ie, S101 signaling). Accompany. The UE exits the radio environment of the source access network and performs a radio level attachment to the target access network (eg, creates an eHRPD session if the UE moves from E-UTRAN to eHRPD), then Perform a handover attach procedure to the packet data network with which the UE was communicating via the source access network. Non-optimized handoff / handover applies to both active and idle (dormant) UEs.

Handover Issues in E-UTRAN and eHRPD As mentioned earlier, 3GPP TS 23.402 and related specifications, as well as 3GPP2 X. The protocol specified in the S0057 specification supports optimized and non-optimized handovers between E-UTRAN radio / access networks and eHRPD radio / access networks. A "Revision 0 / Release 8" UE can support multiple simultaneous applications in multiple packet data domains. Furthermore, a “Revision A / Release 9” UE can support multiple simultaneous applications in each packet data domain (APN). This latter capability is called MUPSAP.

Revision 0 / Release 8 handoff / handover For the optimized handoff / handover case, the UE is in multiple PDN / APNs (referred to as PDN connections, each PDN connection being identified by a PDN-ID). Suppose you have a number of active concurrent applications and are connected to E-UTRAN access. Each packet data flow (bearer connection) for such multiple IP connections is identified by a unique PDN-ID assigned to each PDN connection of the UE. In the E-UTRAN, the PDN-ID is between the IP packet bearer path between the UE and a serving gateway (S-GW), and in the EPS domain, between the S-GW and the P-GW. Provide an association. The PDN-ID is a policy and charging control (PCC) between the S-GW and the packet charging rules function (PCRF) and between the P-GW and the PCRF. Provides an association between signaling paths for S-GW is an edge network entity of E-UTRAN and is similar to HSGW of eHRPD network.

  While connected to E-UTRAN access, the UE can recognize the presence of the eHRPD access network as a potential handover target. Then, the UE informs E-UTRAN of the signal strength and the like related to eHRPD access through a CDMA measurements report. The E-UTRAN network makes a handover decision and performs appropriate signaling to the eHRPD network via the S101 interface to inform that the eHRPD network is a potential handover target. In order to prepare for eHRPD capable handover, the UE signaling for each PDN connection (identified by a unique PDN-ID) with the HSGW in the eHRPD network (VSNCP (Vendor Specific Network Control Protocol) signaling). This performs “pre-registration” of active PDN connections within the eHRPD domain (HSGW). Such pre-registration typically involves setting up a PPP connection between the UE and the HSGW, performing UE authentication and authorization for eHRPD access, and IP connection service via a different PDN / APN to the UE. This is done by informing the eHRPD (HSGW) of the PDN gateway (P-GW) in the EPS domain providing Such pre-registration allows time-consuming connection setup on the eHRPD / HSGW prior to the actual handover to eHRPD access. However, in such preliminary registration, the HSGW in the eHRPD domain and the P-GW in the EPS domain are not connected. Thus, IP packet data flow continues between the UE and the P-GW (in EPS) via the E-UTRAN domain entity.

  Later, when the UE actually moves to eHRPD access, the HSGW in the eHRPD domain and the P-GW in the EPS domain are connected. Such a connection is made by using Proxy Mobile IPv6 (PMIPv6) procedure, and Proxy Binding Update / Proxy Binding Acknowledge (PBU / PBA) between HSGW and P-GW. Performed by exchanging messages. Such a PBU / PBA procedure is performed for each pre-registered PDN connection identified via the PDN-ID in the HSGW. The connection between the E-UTRAN and the eHRPD entity is also enabled by the S103 interface, so that during the UE transition from E-UTRAN access to eHRPD access, data packets are tunneled from E-UTRAN to eHRPD. It becomes possible. Since the time-consuming processes between the UE and the HSGW, PPP setup, authentication / authorization and PDN connection setup are performed by pre-registration, the PBU / PBA procedure can be performed relatively quickly, thus This is referred to as “optimized handover”.

  For non-optimized handoff / handover, there is no connection between E-UTRAN and eHRPD via the S101 interface. Therefore, pre-registration of the PDN connection in the eHRPD cannot be performed while the UE is still in E-UTRAN radio / access. When the UE moves to eHRPD access, the UE and eHRPD network perform PPP session setup and authentication / authorization and PDN connection setup processes between the UE and the HSGW. In addition, a PBU / PBA procedure is also executed between the HSGW and the P-GW, and the IP connection is shifted from E-UTRAN to eHRPD. Such a transition of the IP connection from E-UTRAN access to eHRPD access results in a relatively long delay and the possibility of data packet loss and is therefore referred to as “unoptimized handover”.

Revision A / Release 9 Handoff / Handover All the capabilities of revision 0 / Release 8 optimized and non-optimized handoff / handover are supported by the Revision A / Release 9 system. Furthermore, the revision A / release 9 system also supports handover of MUPSAP PDN connections. If the UE supports MUPSAP and both the E-UTRAN and eHRPD networks support MUPSAP (ie, support Release 9 and Revision A, respectively), at the time of handover, the UE In case of having multiple PDN connections to a given APN within (source access) (MUPSAP), the UE also supports MUPSAP connections in the eHRPD network (target access). As described above, each of the UE's IP connections is uniquely identified by the PDN-ID. In addition, each MUPSAP connection to a given APN is specified by other parameters. Such parameters are called Linked EPS Bearer ID (LBI) in the E-UTRAN domain, called “User Context Identifier” in the eHRPD domain, and “PDN Connection” in the EPS domain. It is called “ID”. For example, if such an identifier exists properly, a successful MUPSAP handover from E-UTRAN to eHRPD will result in an association of “PDN-ID + user context ID” between the UE and HSGW, and between HSGW and P-GW. "PDN-ID + PDN connection ID" association between HSGW and PCRF "PDN-ID + PDN connection ID" association (for PCC) and "PDN-ID + PDN connection between P-GW and PCRF" ID "is associated. Such an association is shown in FIG.

  As an example of MUPSAP handover, a case of handover from Release 9 compatible E-UTRAN to revision 0 compatible eHRPD will be described. Release 9 compliant E-UTRAN implies that the UE and E-UTRAN support MUPSAP. Revision-0 eHRPD implies that an entity in the eHRPD domain does not support MUPSAP. On E-UTRAN access, the UE may have multiple PDN connections to a given APN (with a unique PDN-ID + LBI pair). When a UE prepares for handover to eHRPD, only a single PDN connection to a given APN (identified by a unique PDN-ID) can be handed over.

  One of the problems in this case is which of the MUPSAP connections in the E-UTRAN access is handed over to eHRPD access.

  One policy for selecting a MUPSAP connection during handover from a MUPSAP-enabled source access to a non-MUPSAP-enabled target access is that the UE has a PDN connection corresponding to the most important ongoing application for that APN. Is to choose. For example, if the UE has web browsing, teleconferencing and FTP download application active simultaneously in a corporate network (corporate APN), the most important PDN connection may be a teleconference. In this specific example, when the UE performs a handover from a MUPSAP-compliant E-UTRAN source access to a non-MUPSAP-compliant eHRPD target access, the UE wants to maintain the continuity of the conference call.

  As shown in FIG. 3 above, successful handover requires proper association of bearers and signaling segments at different entities in multiple domains. If the UE randomly selects one of the MUPSAP connections (eg, as described above), proper association of different bearers and signaling components may not be maintained.

  For example, suppose UE and E-UTRAN support MUPSAP, and HSGW in eHRPD domain does not support MUPSAP. Since HSGW does not support MUPSAP, HSGW cannot interpret the “user context identifier” parameter used to identify different PDN connections to a given APN. When the UE performs PDN connection pre-registration in the HSGW while still on E-UTRAN access, the HSGW can only register one PDN connection per APN, but the UE is on E-UTRAN access In some cases, multiple PDN connections to a given APN may be active. Continuing with an example application scenario, the UE activates a web browsing application over E-UTRAN access via the enterprise APN, and such a PDN connection is pre-registered with the HSGW in the eHRPD domain. The Later, the UE activates the conference call application via the corporate APN, still in the pre-registration state within E-UTRAN access. The UE pre-registers the PDN connection corresponding to the conference call application in the HSGW. Since the HSGW can only support a single PDN connection per APN (non-MUPSAP), the previous pre-registration for the web browsing application is overwritten by the pre-registration for the conference call application. After this, the UE is still on E-UTRAN access and initiates the FTP application via the corporate APN. The UE pre-registers this FTP application PDN connection also on the HSGW in the eHRPD domain. In HSGW, FTP application pre-registration overwrites conference call pre-registration. After this, the UE performs a handover to eHRPD access. With the possible requests described above, the UE wishes to maintain a conference call application connection when performing a handover to non-MUPSAP eHRPD access. However, the HSGW has a “last” pre-registration for the enterprise APN PDN connection, ie it has a pre-registration context for FTP applications. Therefore, proper association between bearer components between UE and HSGW is not guaranteed.

  A similar scenario will be described when the UE and E-UTRAN support MUPSAP. Assume that the HSGW in the eHRPD domain also supports MUPSAP. In this case, pre-registration of all active MUPSAP connections while the UE is on E-UTRAN access can be guaranteed at the HSGW. However, in this specific example, the P-GW in the EPS domain does not support MUPSAP. Therefore, the P-GW cannot interpret the “PDN connection ID” parameter. The P-GW context corresponds to the “last” PDN connection for the given APN, in this case the FTP application. Again, the UE has no freedom to randomly select a MUPSAP connection.

  Therefore, some rules need to be defined in order to guarantee a successful handover from a source access that supports MUPSAP to a target access that does not support MUPSAP. Although the exemplary scenario described above describes an E-UTRAN to eHRPD handover only in the case of an optimized handover, such a rule is also necessary for non-optimized handovers. . Such a rule is also necessary for handover from a MUPSAP compliant eHRPD source access to a non-MUPSAP compliant E-UTRAN target access.

Example rules:
The rules for handover from a MUPSAP-compatible source access to a MUPSAP-incompatible target access are shown below.

  The UE performs handover between the source access network and the target access network, the UE has two or more PDN connections to a given APN within the source access, and for target access, multiple to a single APN If multiple PDN connections are not supported, only one PDN connection to a given APN is established for target access.

  When a UE moves to a non-MUPSAP target access, the UE selects a MUPSAP-enabled source so that the network entity selects the same PDN connection from the active PDN connection for a given APN on MUPSAP-enabled source access. From the active PDN connection for a given APN on access, the last activated PDN connection is selected from the latest PDN connection, ie, the active PDN connection for a given APN.

  If a new PDN connection to a given APN is established on a MUPSAP-enabled source access and there is a PDN connection already pre-registered for that APN in the target access, it will be pre-registered with a non-MUPSAP The current PDN connection is no longer the latest PDN connection for that APN. In this case, the PDN connection preliminarily registered in the non-MUPSAP target access is deleted, and the newly established PDN connection is preregistered. FIG. 5 illustrates the addition of a PDN connection in the MUPSAP source access pre-registration of the last PDN connection in a non-MUPSAP target access.

  In the MUPSAP-compatible source access, when the latest pre-registered PDN connection is deleted, the pre-registered information in the target access becomes useless. In this case, the second new PDN connection becomes the latest PDN connection while the UE is still on MUPSAP compatible source access. The PDN connection pre-registered first in the non-MUPSAP target access is deleted and the second new PDN connection is pre-registered in the target access. FIG. 6 shows the deletion of the last PDN connection in the MUPSAP source access and the pre-registration of the second new PDN connection in the non-MUPSAP target access.

3GPP2 TSG-X specific MUPSAP capabilities:
As mentioned above, 3GPP2 TSG-X The release A version of the S0057 specification may define a procedure for supporting MUPSAP. Continuing with the above description of the rules, the following set of rules is proposed for handover from MUPSAP compliant E-UTRAN access to non-MUPSAP compliant eHRPD access:

  7, 8, 9, 10, 11, 12, 13, 14, and 15 are exchanged between optimized and non-optimized handoffs in a wireless network. Various specific examples of messages are shown. Hereinafter, these message exchanges will be described.

  The rules for optimized handover are described below. In this scenario, UE and E-UTRAN support MUPSAP, and HSGW does not support MUPSAP. The rule assumes the use of an S101 interface that tunnels eHRPD signaling between the UE and the eAN / ePCF (within the eHRPD domain).

  If the UE does not know whether the eHRPD system supports MUPSAP, the UE shall include the User Context Identifier configuration option in the VSNCP Configure-Request message Performs pre-registration for PDN connections to a given APN that it wishes to maintain in the eHRPD system. When the UE receives the VSNCP configuration-response message without the user context identifier configuration option, it learns that the eHRPD system does not support MUPSAP.

  If available, the UE may learn that the eHRPD system does not support MUPSAP via the ANDSF function or via the VSNCP signaling procedure. When the UE knows that the HSGW does not support MUPSAP, the UE performs pre-registration of the latest PDN connection to a given APN if it has not previously performed pre-registration within the eHRPD system. . The UE may not include a user context identifier configuration option in the VSNCP configuration-request message.

  When a new PDN connection to the same APN is established in the E-UTRAN system during the pre-registration maintenance period, the eHRPD system deletes the previously pre-registered PDN connection context. Then, a newly established PDN connection to the APN may be preliminarily registered.

  During the pre-registration maintenance period, when a PDN connection to an APN pre-registered in the eHRPD system is released in the E-UTRAN system, the pre-registered PDN connection context is deleted and can be used The previous (second newest) PDN connection to the same APN may be pre-registered with the eHRPD system.

  In the following, rules for the active mode optimized handover will be described. In this scenario, the UE is pre-registered with eHRPD, the PPP inactivity timer is still running, and the HSGW has a full context (except for PMIP binding) for the UE. Also assume that the P-GW does not support multiple PDN connections (MUPSAP) to a single APN.

  If the HSGW supports MUPSAP and it is not known to the HSGW whether the P-GW supports MUPSAP and the HSGW has multiple pre-registered PDN connections to a given APN, the HSGW By performing the PBU / PBA procedure for the PDN connection to a given APN that it wishes to maintain in the eHRPD system by including the PDN connection ID information element. When the HSGW receives the PBA success message without the PDN connection ID information element, it learns that the P-GW does not support MUPSAP.

  The HSGW supports MUPSAP and it is not known to the HSGW whether the P-GW supports MUPSAP and the HSGW has only one pre-registered PDN connection to a given APN If so, the HSGW performs a PBU / PBA procedure for that PDN connection to a given APN with the P-GW by including a PDN connection ID information element in the PBU message. When the HSGW receives the PBA success message without the PDN connection ID information element, it learns that the P-GW does not support MUPSAP.

  If the HSGW learns that the HSGW supports MUPSAP and the P-GW does not support MUPSAP, the HSGW will go to a given APN if it has not yet performed pre-registration as described above. Run the PBU / PBA procedure for the latest pre-registered PDN connection with the P-GW. The HSGW may not include the PDN connection ID information element in the PBU message.

  If the HSGW does not support MUPSAP, the HSGW performs a PBU / PBA procedure for the (only) pre-registered PDN connection to a given APN with the P-GW. The HSGW may not include the PDN connection ID information element in the PBU message.

  The rules for the idle mode optimized handover are described below. In this scenario, the UE has a dormant PPP session in the target HSGW via a pre-registration procedure. Assume that the UE is pre-registered with eHRPD, the PPP inactivity timer is still running, and the HSGW has a full context (excluding PMIP binding) for the UE. Also assume that the P-GW does not support multiple PDN connections (MUPSAP) to a single APN.

  If the HSGW supports MUPSAP and it is not known to the HSGW whether the P-GW supports MUPSAP and the HSGW has multiple pre-registered PDN connections to a given APN, the HSGW The PBU / PBA procedure for PDN connection to a given APN that is desired to be maintained in the eHRPD system is performed with the P-GW by including the PDN connection ID information element in the PBU message. When the HSGW receives the PBA success message without the PDN connection ID information element, it learns that the P-GW does not support MUPSAP.

  The HSGW supports MUPSAP and it is not known to the HSGW whether the P-GW supports MUPSAP and the HSGW has only one pre-registered PDN connection to a given APN If so, the HSGW performs a PBU / PBA procedure for that PDN connection to a given APN with the P-GW by including a PDN connection ID information element in the PBU message. When the HSGW receives the PBA success message without the PDN connection ID information element, it learns that the P-GW does not support MUPSAP.

  If the HSGW learns that the HSGW supports MUPSAP and the P-GW does not support MUPSAP, the HSGW will go to a given APN if it has not yet performed pre-registration as described above. Run the PBU / PBA procedure for the latest pre-registered PDN connection with the P-GW. The HSGW does not include the PDN connection ID information element in the PBU message.

  If the HSGW does not support MUPSAP, the HSGW performs a PBU / PBA procedure for the (only) pre-registered PDN connection to a given APN with the P-GW. The HSGW does not include the PDN connection ID information element in the PBU message.

  In the following, the rules for a non-optimized handover when the UE knows that the UE does not support eHRPD (HSGW) and / or the P-GW supports MUPSAP are described. In this scenario, the following procedure is performed for each APN.

  The UE selects the latest PDN connection to a given APN that it wishes to maintain in the eHRPD system in order to create a PDN connection on the eHRPD system. The procedure may be performed for the selected PDN connection. The UE does not include the user context identifier configuration option in the VSNCP configuration-request message.

  In the following, the rules for a non-optimized handover when the UE is not known to the UE that eHRPD (HSGW) and / or P-GW does not support MUPSAP are described. In this scenario, the following procedure is performed for each APN.

  If the eHRPD system supports MUPSAP is not known to the UE and the UE has multiple PDN connections to a given APN, then the UE will want to maintain the given APN in the eHRPD system And perform such a procedure with the restriction that such a procedure may only be performed for PDN connections to a given given APN. The UE includes a user context identifier configuration option in the VSNCP configuration-request message. When the UE receives the VSNCP configuration-response message without the user context identifier configuration option, it learns that the eHRPD system does not support MUPSAP.

  If the UE does not know whether the eHRPD system supports MUPSAP and the UE has only one PDN connection to a given APN, the UE will have a PDN connection to that given APN Select. The UE includes a user context identifier configuration option in the VSNCP configuration-request message. When the UE receives the VSNCP configuration-response message without the user context identifier configuration option, it learns that the eHRPD system does not support MUPSAP.

  When it becomes known to the UE that the eHRPD system does not support MUPSAP, the UE establishes a PDN connection of the latest PDN connection to the APN if the latest PDN connection is not the PDN connection selected by the above steps. . The UE does not include the user context identifier configuration option in the VSNCP configuration-request message. If the latest PDN connection to the APN is different from the PDN connection selected as described above, the HSGW has already established a GW Control Session associated with the PDN connection selected as described above. If so, the GW control session for such PDN connection is terminated.

  In the following, some exemplary message flows are described.

  As shown in FIG. 7, (1) UE is first attached to E-UTRAN. The UE acquires an IPv4 address and / or an IPv6 prefix. Data is transmitted and received between the UE and the P-GW via the eNodeB and the S-GW. (2) Based on a Radio Layer trigger, the UE decides to initiate a pre-registration procedure with potential target eHRPD access. It is assumed that an S101 signaling relationship exists between MME (Mobility Management Entity) and eAN / ePCF. (3) The UE starts establishing a new session within the eHRPD system via the S101 tunnel.

  (4) When RAN-level authentication is required, the UE establishes an AN-PPP connection with the eAN / ePCF, and performs RAN level authentication using the A12 interface. For details, see A. This is disclosed in S0022-0.

  (5) The eHRPD eAN / ePCF establishes a main A10 connection with the HSGW by exchanging A11-RRQ / RRP (Registration Request / Registration Reply) messages. The A11-Registration Request message includes an instruction that access is performed via the S101 tunnel. For details, see A. This is disclosed in S0022-0. This information is used by the HSGW to postpone interaction with the P-GW in step 7. The UE and HSGW initiate a PPP connection establishment procedure.

  (6a and 6b) The UE performs user authentication and authorization in the eHRPD access system using EAP-AKA '(Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement). The EAP-AKA 'message is transferred between the UE and the HSGW via PPP. The EAP authenticator resides in the HSGW. The 3GPP AAA server authenticates and authorizes the UE for access within the eHRPD system. In this step, the 3GPP AAA server makes an inquiry to a home subscriber server (HSS), and returns the subscriber profile and the APN and P-GW address pair for each PDN connection to the eHRPD system. The 3GPP AAA server also returns a Network Access Identifier (NAI) used to identify the UE in the proxy binding update message.

  (6c) The HSGW stores information received from the 3GPP AAA / HSS server.

  (7) The UE currently exchanges HSGW and VSNCP messages for each PDN connection that has an attachment in E-UTRAN and wants to maintain on eHRPD (steps 8-17 are well known in the art). is there). The UE sets the Attach Type to “Handover” in the VSNCP Configuration-Request message. In addition, the UE includes the IP address acquired via LTE in the VSNCP configuration-request message. If the PDN type is IPv6 or IPv4v6, the UE includes an IPv6 HSGW link local address IID option in the VSNCP configuration-request message and sets all values to zero. The HSGW includes an IPv6 HSGW link local address IID option in the VSNCP configuration-response message and sets the value to the interface ID of the HSGW link local address. Interactions between the HSGW and the PCRF are based on the 3GPP specification (TS 23.402 section 9.3.1). The HSGW exchanges hPCRF with a Gateway Control Session Establishment / Ack message to obtain the QoS policy rules necessary to perform bearer binding updates for all active IP flows. As shown in the diagram for the roaming scenario, the policy interaction between the hPCRF in the HPLMN and the HSGW is relayed via the vPCRF in the VPLMN.

  The HSGW postpones the interaction with the P-GW until the UE arrives at the eHRPD, and at this point of arrival, the PGW is transmitted to the P-GW to complete the PDN connection.

  (8) The network initiates a resource reservation procedure for establishing all bearers. At this point, the UE is registered with the eHRPD access system, which has been authenticated by AAA / HSS. Also at this point, the HRPD context and IP context for the PDN connection that the UE wants to maintain on eHRPD are established. If these contexts need to be changed, step 9 and / or step 10 may be performed to update the contexts.

  (9) It may be necessary to change the eHRPD radio session configuration between the UE and the eAN / ePCF. For example, this may be necessary as a result of migration under the new eAN / ePCF coverage area. This is achieved by an eHRPD signaling exchange between the UE and eAN / ePCF via S101 tunneling.

  (10) If any bearer is added, changed or deleted while the UE is operating on E-UTRAN, similar changes are made in the context between the UE and the HSGW. This is achieved by signaling these changes between the UE and the HSGW via S101 tunneling. Similarly, if any PDN connection is added or deleted while the UE is operating in E-UTRAN, similar changes are made in the HSGW using VSNCP.

  (10a) When the HSGW receives a VSNCP configuration-request for a PDN connection that does not have a P-GW identity, it obtains that information via an AAR / AAA exchange with the HSS / AAA. If the HSGW already has a corresponding P-GW IP address or receives it from the HSS / AAA associated with the VSNCP Configuration-Request message, the HSGW exchanges PBU / PBA messages with the P-GW. The exchange of AAR (Authorize-Authenticate-Request) / AAA messages is not shown in the figure.

  (10b) When the HSGW receives the VSNCP termination-request (VSNCP Terminate-Request) of the PDN connection including the PDN-ID of the PDN connection to be deleted, the HSGW deletes the PDN connection context information and the VSNCP termination-response (VSNCP Terminate-Response). Ack) responds to the UE. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  (11) If the PCRF interaction has not yet been initiated for session maintenance, the PCRF interaction can be initiated by the PCRF or HSGW. The PCRF starts the gateway control and QoS rules provision procedure specified in TS23.203. The HSGW initiates the Gateway Control and QoS Policy Rules Request Procedure specified in TS23.203.

  Hereinafter, specific examples of signals exchanged between various network entities will be described with reference to FIG.

  (1) The UE is first attached to E-UTRAN. The UE acquires an IPv4 address and / or an IPv6 prefix. Data is transmitted and received between the UE and the P-GW via the eNodeB and the S-GW.

  (2) Based on a Radio Layer trigger, the UE decides to initiate a pre-registration procedure with potential target eHRPD access. Assume that an S101 signaling relationship exists between the MME and the eAN / ePCF. The UE performs steps to set up a PPP connection with the selected HSGW and performs UE authentication for eHRPD access. The UE performs steps 3 to 11 for each APN that the UE has attachments in the E-UTRAN system and that the UE wants to maintain in the HRPD system. If it is known to the UE that the HSGW does not support MUPSAP, steps 3 to 6 are not performed.

  (3) The UE sends a VSNCP Configure-Request message for a PDN connection to a given APN that it wishes to maintain in the eHRPD system over the main service connection. The information in the message includes PDN-ID, user context identifier, PDN type, APN, PDN address, protocol configuration option and Attach Type = “handover”. Other configuration options may be included.

  (4) The HSGW may execute a gateway control session setup procedure with the PCRF. In doing this, the HSGW indicates a possible bearer control mode based on the UE capabilities provided in step 3 and its capabilities. The PCRF selects a bearer control mode to be used.

  (5) Since HSGW does not support MUPSAP, it returns a VSNCP Configure-Ack message without a user context identifier configuration option. Thereby, the UE knows that the HSGW does not support MUPSAP. When the PDN connection to the APN selected in Step 3 is the latest PDN connection to the APN, Steps 6 to 9 are not executed for the APN.

  (6) The UE sends a VSNCP Configure-Request message for the latest PDN connection to a given APN via the main service connection. The information in the message includes PDN-ID, PDN type, APN, PDN address, protocol configuration option and Attach Type = “handover”.

  (7) If a GW control session context is set up in step 4, the HSGW performs a GW control session termination / response procedure with the PCRF (GW Control Session Termination / Ack) and is pre-registered first in the HSGW. Delete the GW control context of this PDN connection.

  (8) The HSGW may execute a gateway control session setup procedure with the PCRF. In doing this, the HSGW indicates a possible bearer control mode based on the UE capabilities provided in step 6 and its capabilities. The PCRF selects a bearer control mode to be used.

  (9) The HSGW sends a VSNCP Configure-Ack (PDN-ID, APN, PDN address, PCO, attach type, Address Allocation Cause) message to the UE via the main service connection. Send. Other configuration options may be included.

  Steps 10 and 11 may be executed immediately after step 5. In this case, the information in step 10 executed after step 9 overwrites the information in step 10 executed immediately after step 5.

  (10) The HSGW sends a VSNCP configuration-request message to complete the protocol specified in RFC3772. This message includes a PDN-ID configuration option.

  (11) The UE responds with a VSNCP Configure-Ack message.

  (12) The network starts a resource reservation procedure for establishing all bearers. At this point, the HRPD context and IP context for the PDN connection to the APN are established in the HSGW. If a new PDN connection to the APN is added on the E-UTRAN system or a pre-registered PDN connection to the APN is deleted on the E-UTRAN system, perform steps 13 to 19; The preliminary registration information is updated in the HSGW.

  (13) The UE exchanges the VSNCP message with the HSGW and updates the pre-registration context in the HSGW.

  a. When a PDN connection to an APN is added on the E-UTRAN system, the UE sends a VSNCP configuration-request message containing the PDN-ID of the new PDN connection to this APN and updates the pre-registration context in the HSGW. . The attach type is set to “handover”. Other configuration options as specified in step 6 above are also included.

  b. When the pre-registered PDN connection to the APN is released in the E-UTRAN system, the UE includes the PDN-ID of the previous (second newest) PDN connection to the same APN, if available. Send a VSNCP Configure-Request message to update the pre-registration context in the HSGW. The attach type is set to “handover”. Other configuration options as specified in step 6 above are also included.

  c. If a PDN connection to a new APN is added on E-UTRAN, IP context maintenance procedures are performed at step 21.

  d. If the pre-registered PDN connection to the APN is released in the E-UTRAN system and there are no other PDN connections to this APN, in step 21b, an IP context maintenance procedure is performed.

  (14) In 13 (a) and 13 (b) above, when the GW control session context is set up in Step 4 or Step 8, the HSGW performs GW control session termination / response (GW Control Session Termination) with the PCRF. / Ack) procedure is executed to delete the GW control context of the PDN context previously registered in the HSGW.

  (15) In 13 (a) and 13 (b) above, the HSGW performs a Gateway Control Session setup procedure with the PCRF for the pre-registered context newly identified in the HSGW. May be. In doing this, the HSGW indicates a possible bearer control mode based on the UE capabilities provided in step 13 and its capabilities. The PCRF selects a bearer control mode to be used.

  (16) The HSGW sends a VSNCP Configure-Ack (PDN-ID, APN, PDN address, PCO, attach type, Address Allocation Cause) message to the UE via the main service connection. Send. Other configuration options such as specified in step 9 above may be included.

  (17) The HSGW sends a VSNCP configuration-request message to complete the protocol specified in RFC3772. This message includes a PDN-ID configuration option.

  (18) The UE responds with a VSNCP Configure-Ack message.

  (19) The network starts a resource reservation procedure for establishing all bearers.

  At this point, all HRPD contexts and IP contexts have been established. If these contexts need to be changed, step 20 and / or step 21 may be performed to update the context.

  (20) It may be necessary to change the eHRPD radio session configuration between the UE and the eAN / ePCF. For example, this may be necessary as a result of migration under the new eAN / ePCF coverage area. This is achieved by an eHRPD signaling exchange between the UE and eAN / ePCF via S101 tunneling.

  (21) If any bearer is added, changed or deleted while the UE is operating on E-UTRAN, a similar change is made in the context between the UE and the HSGW. This is achieved by signaling these changes between the UE and the HSGW via S101 tunneling. Similarly, if any PDN connection is added or deleted while the UE is operating in E-UTRAN, similar changes are made in the HSGW using VSNCP.

  a. When the HSGW receives a VSNCP configuration-request for a PDN connection that does not have a P-GW identity, it obtains that information via an AAR / AAA exchange with the HSS / AAA. If the HSGW already has a corresponding P-GW IP address or receives it from the HSS / AAA associated with the VSNCP Configuration-Request message, the HSGW exchanges PBU / PBA messages with the P-GW. The exchange of AAR / AAA messages is not shown in the figure.

  b. When the HSGW receives the VSNCP termination-request (VSNCP Terminate-Request) of the PDN connection including the PDN-ID of the PDN connection to be deleted, the HSGW deletes the PDN connection context information, and responds with the VSNCP termination-response (VSNCP Terminate-Ack). Respond to the UE. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  (22) If the PCRF interaction has not yet been initiated for session maintenance, the PCRF interaction can be initiated by the PCRF or HSGW. The PCRF starts the gateway control and QoS rules provision procedure specified in TS23.203.

  In the following, referring to FIG. 9, a specific example of messages exchanged during an active mode optimized handoff will be described.

  (1a) The E-UTRAN receives the CDMA measurement report from the UE and performs HO (handover / handoff) determination.

  (1b) The UE transmits an HRPD connection request message to the E-UTRAN, and requests an HRPD traffic channel. This request is forwarded to the MME. This detail is described in TS 23.402.

  (1c) The MME transmits the APN and uplink GRE key related to the P-GW address to the eHRPD access node together with the HRPD connection request message via the S101 tunnel.

  Note that the GRE key (one for each PDN connection) sent in step 1c is also sent to the HSGW in step 2a, which, after HO, uses this for uplink traffic to the P-GW. use. The same key is also used between S-GW and P-GW before HO. By using the same key, even if the HSGW decides to send uplink data before receiving the PBA in step 8b, the P-GW ensures that the uplink data is in the correct PDN connection. (Note that the P-GW defined in 23.402 is configured to receive the same GRE key data even before updating the binding).

  (2a) The eHRPD-eAN / ePCF allocates the requested radio resource and sends an A11-RRQ message to the HSGW. The eAN / ePCF has a P-GW address, an associated uplink GRE key for each PDN connection received in step 1c, and an indicator that the UE is communicating through the tunnel (A.S0022 tunnel mode indicator (See Tunnel Mode indicator) in this message.

  (2b) The HSGW responds with an A11-RRP that includes the forward destination address (ie, HSGW IP address, GRE key and associated APN).

  (3) The eHRPD-eAN / ePCF transmits an HRPD Traffic Channel Assignment (TCA) message to the MME in the S101 message in response to the HRPD connection request message received in Step 1c. The S101 message also carries an HSGW IP address, a GRE key for data forwarding, and an associated APN.

  (4a) The MME configures resources for indirect data forwarding and signals the HSGW IP address and GRE key to the S-GW. The S-GW confirms the data forwarding resource.

  (4b) The MME forwards the HRPD TCA message embedded in the S101 message to the E-UTRAN, and the E-UTRAN forwards it to the UE via the air link.

  (5) The E-UTRAN may return a downlink IP packet to be transmitted to the HSGW via the S103 interface to the S-GW. The HSGW performs any necessary processing on the IP packets and forwards them to the eAN / ePCF via the appropriate A10 connection.

  (6a) L2 attach is complete (ie, the UE acquires an eHRPD radio).

  (6b) The UE sends a Traffic Channel Completion (TCC) message to the eHRPD eAN / ePCF.

  (7a) The eHRPD eAN / ePCF sends an A11-RRQ carrying an Active Start air-air link record and an indicator indicating that the UE is currently operating on the eHRPD radio to the HSGW. .

  (7b) The HSGW responds to the eHRPD eAN / ePCF with A11-RRP.

  (8a) The HSGW / MAG is triggered by step 7a to send a PBU and establish a PMIPv6 tunnel for each PDN connection with the P-GW with which the UE is associated. The HSGW identifies the UE using the NAI received in the Mobile-Node-Identifier AVP in response to successful authentication. If MUPSAP is supported in the HSGW, the HSGW includes the PDN connection ID information element in the PBU message.

  (8b) The P-GW processes the PBU and updates the binding cache entry for the UE. The UE is assigned the same IP address or prefix. P-GW / LMA (Local Mobility Anchor) transmits PBA including IP address / prefix assigned to UE to HSGW / MAG. This sets up a PMIPv6 tunnel. When MUPSAP is supported in the P-GW and the PDN connection ID information element is received in the PBU message, the P-GW includes the same PDN connection ID information element in the PBA message.

  (8c) The P-GW needs to be configured to enforce the policy, and the P-GW sends an IP-CAN (IP-CAN connectivity access network) session (Modify IP-CAN session) message to the hPCRF. When the P-GW requests an IP-CAN session change, the hPCRF responds to the P-GW with an IP-CAN session change response (Modify IP-CAN session Ack) message. This message includes the policy and charging rules built into the P-GW.

  Steps 8a-8c are repeated for each PDN connection to be established.

  (8d) The eHRPD eAN / ePCF signals handoff completion to the MME, confirms HO completion, and receives a response.

  (9) L3 attach is complete, which allows the UE to send / receive packets to / from the eHRPD access network.

  (10) The E-UTRAN system including eNodeB, MME, S-GW and P-GW releases resources, which sends PMIPv6 BRI messages from P-GW to S as specified in TS 29.275. -Including sending to the GW. This is also described in TS 23.402.

  (11) If the UE has not completed PDN connection and bearer addition / deletion on E-UTRAN, the UE completes these activities on the eHRPD radio. If any PDN connection is added or deleted while the UE is operating on E-UTRAN, similar changes are made in the HSGW using VSNCP.

  (11a) When the HSGW receives a VSNCP configuration-request for a PDN connection that does not have a P-GW identity, it obtains that information via an AAR / AAA exchange with the HSS / AAA. If the HSGW already has a corresponding P-GW IP address or receives it from the HSS / AAA associated with the VSNCP Configuration-Request message, the HSGW exchanges PBU / PBA messages with the P-GW. The exchange of AAR / AAA messages and PBU / PBA is not shown in the figure.

  (11b) When the HSGW receives the VSNCP termination-request (VSNCP Terminate-Request) of the PDN connection including the PDN-ID of the PDN connection to be deleted, the HSGW deletes the PDN connection context information and the VSNCP termination-response (VSNCP Terminate- Ack) responds to the UE. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  Hereinafter, a specific example of messages exchanged during an active mode optimized handoff from an E-UTRAN to an eHRPD P-GW that does not support MUPSAP will be described with reference to FIG.

  (1) The UE is first attached to E-UTRAN. The UE is performing pre-registration of an active PDN connection in eHRPD.

  (2) E-UTRAN receives the CDMA measurement report from the UE and performs HO determination. The UE sends an HRPD connection request message to the E-UTRAN and requests an HRPD traffic channel. This sets up a traffic channel on eHRPD and the eAN / ePCF sets up an A10 connection with the HSGW.

  If the HSGW supports MUPSAP, the HSGW performs step 3 to step 8 for each APN having a PDN connection pre-registered on the HSGW. If it is known to the HSGW that the P-GW does not support MUPSAP, Steps 3 to 5 are not performed.

  If the HSGW does not support MUPSAP, steps 3 to 5 are not executed.

  (3) The HSGW / MAG sends a PBU message and establishes a PMIPv6 tunnel with the P-GW with which the UE is associated for the APN. If there are multiple PDN connections to the APN pre-registered in the HSGW, the HSGW selects one of the PDN connections to the APN that it wishes to maintain on the eHRPD system. If there is only one pre-registered PDN connection to the APN, that PDN connection is selected. The HSGW identifies the UE using the NAI received in the Mobile-Node-Identifier AVP in response to successful authentication. The HSGW includes a PDN connection ID information element for the selected PDN connection in the PBU message.

  (4) The P-GW processes the PBU and updates the UE's binding cache entry for this APN. Since the P-GW does not support MUPSAP, its binding cache entry includes the IP address or prefix assigned to the latest PDN connection to the APN. The P-GW / LMA sends the PBA including the IP address / prefix assigned to the latest PDN connection to the APN to the HSGW / MAG. This sets up a PMIPv6 tunnel. The P-GW returns a PBA message without the PDN connection ID information element.

  (5) The P-GW needs a configuration to implement the policy, and the P-GW sends an IP-CAN session change (Modify IP-CAN session) message to the hPCRF. When the P-GW requests an IP-CAN session change, the hPCRF responds to the P-GW with an IP-CAN session change response (Modify IP-CAN session Ack) message. This message includes the policy and charging rules built into the P-GW.

  At this stage, the HSGW knows that the P-GW does not support MUPSAP. If there is only one PDN connection to the APN, or if the PDN connection to the APN where the PBU / PBA procedure is performed in step 3 to step 5 is the latest PDN connection to the APN, then steps 6 to 8 are Not executed.

  (6) The HSGW / MAG sends a PBU message and establishes a PMIPv6 tunnel with the P-GW with which the UE is associated for the APN. If there are multiple PDN connections to the APN pre-registered in the HSGW, the HSGW selects the latest PDN connection to the APN. If the HSGW does not support MUPSAP, the only pre-registered PDN connection to the APN is selected. The HSGW identifies the UE using the NAI received in the Mobile-Node-Identifier AVP in response to successful authentication. The HSGW does not include the PDN connection ID information element in the PBU message.

  (7) The P-GW processes the PBU and updates the UE's binding cache entry for this APN. The UE is assigned the same IP address or prefix. The P-GW / LMA sends a PBA including the IP address / prefix assigned to the UE to the HSGW / MAG. This sets up a PMIPv6 tunnel.

  (8) The P-GW needs a configuration to implement the policy, and the P-GW sends an IP-CAN session change (Modify IP-CAN session) message to the hPCRF. When the P-GW requests an IP-CAN session change, the hPCRF responds to the P-GW with an IP-CAN session change response (Modify IP-CAN session Ack) message. This message includes the policy and charging rules built into the P-GW.

  (9) The eHRPD eAN / ePCF signals handoff completion to the MME, confirms HO completion, and receives a response.

  (10) The L3 attach is complete, which allows the UE to send / receive packets to / from the eHRPD access network.

  (11) The E-UTRAN system including eNodeB, MME, S-GW and P-GW releases resources, which sends PMIPv6 BRI message from P-GW to S, as specified in TS 29.275. -Including sending to the GW. This is also described in TS 23.402.

  (12) If the UE has not completed PDN connection and bearer addition / deletion on E-UTRAN, the UE completes these activities on the eHRPD radio. For pre-registration with partial context, when the UE sets up a PDN connection via eHRPD, EPS resources including eNodeB, MME, S-GW are released. If any PDN connection is added or deleted while the UE is operating on E-UTRAN, similar changes are made in the HSGW using VSNCP.

  (12a) When the HSGW receives a VSNCP configuration-request for a PDN connection that does not have a P-GW identity, it obtains that information via an AAR / AAA exchange with the HSS / AAA. If the HSGW already has a corresponding P-GW IP address or receives it from the HSS / AAA associated with the VSNCP Configuration-Request message, the HSGW exchanges PBU / PBA messages with the P-GW. The exchange of AAR / AAA messages and PBU / PBA is not shown in the figure.

  (12b) Upon receiving the VSNCP termination-request (VSNCP Terminate-Request) of the PDN connection including the PDN-ID of the PDN connection to be deleted, the HSGW deletes the PDN connection context information and the VSNCP termination-response (VSNCP Terminate-Request). Ack) responds to the UE. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  (13) If the HSGW supports MUPSAP and has a PDN connection to an APN that is not supported by the P-GW, the HSGW sends a VSNCP End-Request message containing the PDN-ID of the connection to be deleted. , Such PDN connection context information is deleted. The UE deletes the PDN connection context information and responds to the HSGW with a VSNCP termination-response. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  Hereinafter, a specific example of messages exchanged during an idle mode optimized handoff from E-UTRAN to eHRPD will be described with reference to FIG.

  (1) The UE is attached to the E-UTRAN network and is in the ECM_IDLE state. The UE has a dormant eHRPD session in the target eHRPD AN via a pre-registration procedure.

  (2) The UE is in idle mode. Based on some trigger, the idle UE decides to perform cell reselection to the eHRPD AN. Note that cell reselection can be performed at any time when the UE is attached to an E-UTRAN network (including immediately after the UE completes pre-registration).

  (3) The UE performs an inter-technology idle mode mobility event according to the eHRPD procedure and notifies the eAN that it is currently tuned to eHRPD.

  (4) The eAN sends an A11-registration request for all A10. This A11-RRQ includes a “tunneled mode indicator” set to “0” to indicate to the HSGW that the UE is operating on the eHRPD radio. If the Tunnel Mode Indicator is not present, the HSGW assumes that the UE is operating on the eHRPD radio and needs to establish all PMIP bindings for the UE.

  (5) and (6): upon receipt of an A11-registration request message for an eHRPD session whose lifetime timer is not zero and is set to tunnel mode indicator “0” or does not exist The HSGW determines that it does not have a PMIPv6 binding for this UE and exchanges PBU / PBA messages with the appropriate P-GW. If MUPSAP is supported in the HSGW and P-GW, the HSGW and P-GW include the PDN connection ID information element in the PBU / PBA message. The UE address information in PMIPv6PBA returns the IP address assigned to the UE. At this point, the user plane switches the P-GW to the eHRPD access network via the HSGW. The P-GW uses the exchange of AAR / AAA messages to update the HSS / AAA (not shown in the figure).

  (6a) and (6b) The P-GW transmits an IP-CAN Session Modification message indication (Indication) to the PCRF, and the PCRF responds thereto. Since step 6 and step 6a are both triggered by the PBU in step 5, step 6 and step 6a may be performed in parallel.

  For a plurality of PDN connections, Steps 5 to 6 and Steps 6a to 6b are executed for each PDN connection.

  (7) If a new A10 connection is established, the A11-registration request message is validated and the HSGW accepts the A10 connection by returning an A11-registration response message that includes an accept indication. This step can be performed any time after step 4.

  (8) At any time after step 6, the P-GW may perform a resource allocation deactivation procedure in E-UTRAN as defined in sub-clause 5.6.2.2 of TS 23.402. To start.

  (9) UE is attached to eHPRD.

  (10) If the UE has not completed PDN connection and bearer addition / deletion on E-UTRAN, the UE completes these activities on the eHRPD radio. If any PDN connection is added or deleted while the UE is operating on E-UTRAN, similar changes are made in the HSGW using VSNCP.

  (10a) When the HSGW receives a VSNCP configuration-request for a PDN connection that does not have a P-GW identity, it obtains that information via an AAR / AAA exchange with the HSS / AAA. If the HSGW already has a corresponding P-GW IP address or receives it from the HSS / AAA associated with the VSNCP Configuration-Request message, the HSGW exchanges PBU / PBA messages with the P-GW. The exchange of AAR / AAA messages and PBU / PBA is not shown in the figure.

  (10b) When the HSGW receives the VSNCP termination-request (VSNCP Terminate-Request) of the PDN connection including the PDN-ID of the PDN connection to be deleted, the HSGW deletes the PDN connection context information and the VSNCP termination-response (VSNCP Terminate-Response). Ack) responds to the UE. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  Hereinafter, a specific example of messages exchanged during an idle mode optimized handoff from E-UTRAN to eHRPD not supporting MUPSAP will be described with reference to FIG.

  (1) The UE is first attached to E-UTRAN. The UE is performing pre-registration of an active PDN connection in eHRPD. The UE has a dormant eHRPD session in the target eHRPD network via a pre-registration procedure.

  (2) The UE is attached to E-UTRAN and is in the ECM_IDLE state. Based on some trigger, the idle UE decides to perform cell reselection to the eHRPD AN. The UE performs an inter-technology idle mode mobility event according to the eHRPD procedure and notifies the eAN that it is currently tuned to eHRPD.

  (3) The eAN sends an A11-registration request for all A10. This A11-RRQ includes a “tunnel mode mode indicator” set to “0” to indicate to the HSGW that the UE is operating on the eHRPD radio. If the tunnel mode indicator is not present, the HSGW assumes that the UE is operating on the eHRPD radio and needs to establish all PMIP bindings for the UE.

  (4) The HSGW approves eHRPD access by sending an A11-registration response. If a new A10 connection is established, the A11-registration request message is validated and the HSGW accepts the A10 connection by returning an A11-registration response message containing an accept indication.

  If the HSGW supports MUPSAP, the HSGW performs steps 5-10 for each APN with a pre-registered PDN connection. If it is known to the HSGW that the P-GW does not support MUPSAP, Steps 5 to 7 are not performed.

  If the HSGW does not support MUPSAP, steps 5-7 are not executed.

  (5) The HSGW / MAG is triggered by step 3 to send a PBU message and establish a PMIPv6 tunnel for each PDN connection with the P-GW with which the UE is associated for APN. If there are multiple PDN connections to the APN pre-registered in the HSGW, the HSGW selects one of the PDN connections to the APN that it wishes to maintain on the eHRPD system. If there is only one pre-registered PDN connection to the APN, that PDN connection is selected. The HSGW identifies the UE using the NAI received in the Mobile-Node-Identifier AVP in response to successful authentication. The HSGW includes a PDN connection ID information element for the selected PDN connection in the PBU message.

  (6) The P-GW processes the PBU and updates the UE's binding cache entry for this APN. Since the P-GW does not support MUPSAP, its binding cache entry includes the IP address or prefix assigned to the latest PDN connection to the APN. The P-GW / LMA sends the PBA including the IP address / prefix assigned to the latest PDN connection to the APN to the HSGW / MAG. This sets up a PMIPv6 tunnel. The P-GW returns a PBA message without the PDN connection ID information element.

  (7) The P-GW needs a configuration to implement the policy, and the P-GW sends an IP-CAN session change (Modify IP-CAN session) message to the hPCRF. When the P-GW requests an IP-CAN session change, the hPCRF responds to the P-GW with an IP-CAN session change response (Modify IP-CAN session Ack) message. This message includes the policy and charging rules built into the P-GW.

  At this stage, the HSGW knows that the P-GW does not support MUPSAP. If there is only one PDN connection to the APN, or if the PDN connection to the APN where the PBU / PBA procedure is performed in step 5 to step 7 is the latest PDN connection to the APN, then steps 8 to 10 are Not executed.

  (8) The HSGW / MAG sends a PBU message and establishes a PMIPv6 tunnel with the P-GW with which the UE is associated for the APN. If there are multiple PDN connections to the APN pre-registered in the HSGW, the HSGW selects the latest PDN connection to the APN. If the HSGW does not support MUPSAP, the only pre-registered PDN connection to the APN is selected. The HSGW identifies the UE using the NAI received in the Mobile-Node-Identifier AVP in response to successful authentication. The HSGW does not include the PDN connection ID information element in the PBU message.

  (9) The P-GW processes the PBU and updates the binding cache entry of the UE. The UE is assigned the same IP address or prefix. The P-GW / LMA sends a PBA including the IP address / prefix assigned to the UE to the HSGW / MAG. This sets up a PMIPv6 tunnel.

  (10) The P-GW needs a configuration to implement the policy, and the P-GW sends an IP-CAN session change (Modify IP-CAN session) message to the hPCRF. When the P-GW requests an IP-CAN session change, the hPCRF responds to the P-GW with an IP-CAN session change response (Modify IP-CAN session Ack) message. This message includes the policy and charging rules built into the P-GW.

  (11) The P-GW initiates a resource allocation deactivation procedure in E-UTRAN as defined in sub-clause 5.6.2.2 of TS 23.402.

  (12) UE is attached to eHPRD.

  (13) If the UE has not completed PDN connection and bearer addition / deletion on E-UTRAN, the UE completes these activities on the eHRPD radio. If any PDN connection is added or deleted while the UE is operating on E-UTRAN, similar changes are made in the HSGW using VSNCP.

  (13a) When the HSGW receives a VSNCP configuration-request for a PDN connection that does not have a P-GW identity, it obtains its information via an AAR / AAA exchange with the HSS / AAA. If the HSGW already has a corresponding P-GW IP address or receives it from the HSS / AAA associated with the VSNCP Configuration-Request message, the HSGW exchanges PBU / PBA messages with the P-GW. The exchange of AAR / AAA messages and PBU / PBA is not shown in the figure.

  (13b) When the HSGW receives the VSNCP termination-request (VSNCP Terminate-Request) of the PDN connection including the PDN-ID of the PDN connection to be deleted, the HSGW deletes the PDN connection context information and the VSNCP termination-response (VSNCP Terminate- Ack) responds to the UE. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  (14) If the HSGW supports MUPSAP and has a PDN connection to an APN that is not supported by the P-GW, the HSGW sends a VSNCP End-Request message containing the PDN-ID of the connection to be deleted. , Such PDN connection context information is deleted. The UE deletes the PDN connection context information and responds to the HSGW with a VSNCP termination-response. If a GW control session context has been set up for PDN connection, the HSGW performs a GW Control Session Termination / Ack procedure with the PCRF and is pre-registered previously in the HSGW. Delete the GW control context for this PDN connection.

  Hereinafter, a specific example of messages exchanged during an unoptimized handoff from E-UTRAN to eHRPD in a partial HSGW context will be described with reference to FIG.

  (1) The UE and eAN / ePCF reconnect the existing eHRPD session.

  (2) The ePCF recognizes that the A10 session associated with the UE is available and sends an “Active Start” indication in the A11-registration request message to the HSGW.

  (3) The HSGW responds with an A11-Registration Reply message.

  (4) The HSGW obtains the UE context including the IP address of the P-GW currently used by all PDN connections for the UE from the HSS / AAA.

  Steps 5 to 12 are repeated for each PDN connection that the UE re-establishes.

  (5) The UE sends a VSNCP configuration-request message via the main service connection. The information in the message includes PDN-ID, PDN type, APN, PDN address, protocol configuration option and Attach Type = “handover”. Also, if MUPSAP is supported, a user context identifier is also included. If known, the PDN type indicates the UE IP version capability (IPv4, IPv4 / IPv6, IPv6), which is the capability of the IP stack associated with the UE. The protocol configuration option indicates whether the UE supports a network initiated bearer.

  (6) The HSGW executes a gateway control session establishment procedure with the PCRF (see TS 23.203). As part of this step, the PCRF sends QoS rules and events to the HSGW.

  (7) The HSGW sends a PMIP binding update to the P-GW to update the registration (see TS 29.275). If MUPSAP is supported in the HSGW, the HSGW includes the PDN connection ID information element in the PBU message.

  (8) The P-GW executes PCRF interaction and acquires the QoS policy parameter.

  (9) The P-GW responds to the HSGW with PBA (see TS 29.275). When the P-GW supports MUPSAP and the PDN connection ID information element is received in the PBU message, the P-GW includes the same PDN connection ID information element in the PBA message.

  (10) If the HSGW receives the PSN connection ID information element in the VSNCP Configure-Ack (PDN-ID, PBA message) via the main service connection, the user context identifier, the APN, and the PDN address , PCO, attach type) message to the UE. The protocol configuration option parameter may indicate the selected bearer control mode.

  If the dynamic policy is not supported, the selected bearer control mode is “MS-only”.

  (11) The HSGW completes the protocol by sending a VSNCP configuration-request message specified in RFC3772. If an IPv4 address is assigned immediately or later, this message includes a PDN-ID and an IPv4 Default Router Address. If MUPSAP is supported, the message includes a user context identifier configuration option set to the same value as received in the VSNCP configuration-request message received from the UE.

  (12) The UE responds with a VSNCP Configure-Ack message.

  Step 13 is repeated as necessary until all bearers for all PDN connections are re-established.

  (13) The bearer for the PDN connection is re-established on eHRPD based on the selected bearer control mode.

  (13a) If the selected bearer control mode is “MS-only”, the HSGW assumes that the UE re-establishes all bearers. The UE performs bearer resource allocation requested by the UE for all bearers. If there is no change in the QoS information (QoS info), the QoS information and the service connection are retained, so the step is not executed. As part of the re-established bearer, one or more bearers may need to be deleted by the RAN. The UE performs standard HRPD procedures and deletes the corresponding reservation.

  (13b) If the selected bearer control mode is “MS / NW”, the HSGW re-establishes all bearers. The HSGW performs a dedicated bearer setup initiated by the network (NW). If there is no change in the QoS information (QoS info), the QoS information and the service connection are retained, so the step is not executed. As part of the re-established bearer, one or more bearers may need to be deleted.

  Note that when the selected bearer control mode is “MS / NW”, how to delete the old bearer is a research subject.

  How the HSGW informs the UE which IP flow the UE has started in “MS / NW” mode is a research question.

  Hereinafter, a specific example of messages exchanged during a non-optimized handoff in a null HSGW context will be described with reference to FIG.

  (1) Assume that the UE has an existing eHRPD session with the eAN / ePCF, and the HSGW does not have a saved context for the UE. The UE does not use S101 for pre-registration with eHRPD. When the UE reattaches to eHRPD, the UE needs to establish a complete context with the HSGW.

  (2) The UE is in LTE. Based on some trigger, the UE decides to perform cell reselection to the eHRPD AN. Note that cell reselection can be performed at any time when the UE is attached to an E-UTRAN network. An eNB (evolved Node B) may be involved when redirecting the UE to eHRPD.

  (3) The UE establishes a connection with the eAN according to the eHRPD procedure.

  (4) Since the eHRPD session is in this subnet and there is no A10 connection, the eHRPD eAN / ePCF sends an A11-registration request to establish all A10s. This A11-RRQ includes a tunnel mode mode indicator set to “0” to indicate to the HSGW that the UE is operating on the eHRPD radio. If there is no tunnel mode indicator, the HSGW always assumes that the UE is operating on the eHRPD radio.

  (5) The HSGW is triggered by step 4 to send an A11-registration response to acknowledge eHRPD access. The A11-registration request message is verified.

  (6) Since the UE was previously on eHRPD and has not used S101 for pre-registration, the UE sends a VSNCCP configuration-request to the HSGW. It also includes a user context identifier configuration option if MUPSAP is supported. The UE assumes that the HSGW maintains a partial context from the previous time that the UE established a context on eHRPD.

  (7) The HSGW determines that it does not have a saved context for the UE. The HSGW initiates LCP (Link Control Protocol) and other procedures for establishing PPP, authentication, CCP and PDN context for the UE. This step may be performed before sending the VSNCP configuration-request in step 6.

  (8) (Optional Step) If the UE is requesting a deferred IP address allocation, the UE will now (on the behalf of the server) the BE service connection (optionally a rapid commit option) DHCPv4 discovery message (with option) can be issued.

  (9a) The UE may transmit a router solicitation message.

  (9b) When the P-GW transmits the IPv6 prefix to the HSGW, the HSGW transmits a router advertisement message.

  (10) The UE, RAN, HSGW, and PCRF proceed to re-establish a dedicated bearer based on the bearer control mode.

  (10a) When the selected BCM indicates the NW-initiated QoS (NW), the procedure is executed for each dedicated bearer (IP flow) set up on LTE.

  (10b) If the selected BCM indicates UE-initiated QoS initiated by the UE, the procedure for each dedicated bearer (IP flow) set up on LTE that the UE wants to establish Execute.

  Hereinafter, a specific example of messages exchanged to assist in an unoptimized handoff without an existing eHRPD session will be described with reference to FIG.

  (1) Assume that the UE does not have an existing eHRPD session with the eAN / ePCF (and therefore the HSGW does not have a saved context for the UE). The UE does not use S101 for pre-registration with eHRPD. When the UE reattaches to eHRPD, the UE needs to establish a complete eHRPD session and establish a complete context with the HSGW.

  (2) The UE is in LTE. Based on some trigger, the UE decides to perform cell reselection to the eHRPD AN. Note that cell reselection can be performed at any time when the UE is attached to an E-UTRAN network. The eNB may participate when redirecting the UE to eHRPD.

  (3) The UE establishes an eHRPD session and a PPP and authentication session with the HSGW according to steps 1-7b from the call flow.

  Steps 4-11 are repeated for each PDN connection that the UE has migrated from the LTE system.

  (4) The UE sends a VSNCP configuration-request message via the main service connection. The information in the message includes PDN-ID, user context identifier when MUPSAP is supported, PDN type, APN, PDN address, protocol configuration option and Attach Type = “handover”. If known, the PDN type indicates the UE IP version capability (IPv4, IPv4 / IPv6, IPv6), which is the capability of the IP stack associated with the UE. The protocol configuration option indicates whether the UE supports a network initiated bearer.

  (5) The HSGW executes a gateway control session establishment procedure with the PCRF (see TS 23.203). As part of this step, the PCRF sends QoS rules and events to the HSGW.

  (6) The HSGW updates the registration by sending a PMIP binding update to the P-GW (see TS 29.275). If MUPSAP is supported in the HSGW, the HSGW includes the PDN connection ID information element in the PBU message.

  (7) The P-GW executes PCRF interaction and acquires the QoS policy parameter.

  (8) The P-GW responds to the HSGW with the PBA (see TS 29.275). When the P-GW supports MUPSAP and the PDN connection ID information element is received in the PBU message, the P-GW includes the same PDN connection ID information element in the PBA message.

  (9) If the HSGW receives the PSN connection ID information element in the VSNCP Configure-Ack (PDN-ID, PBA message) via the main service connection, the user context identifier, the APN, and the PDN address , PCO, attach type) message to the UE. The protocol configuration option parameter may indicate the selected bearer control mode.

  If the dynamic policy is not supported, the selected bearer control mode is “MS-only”.

  (10) The HSGW completes the protocol by sending a VSNCP configuration-request message specified in RFC3772. If an IPv4 address is assigned immediately or later, this message includes a PDN-ID and an IPv4 Default Router Address. If MUPSAP is supported, the message includes a user context identifier configuration option set to the same value as received in the VSNCP configuration-request message received from the UE.

  (11) The UE responds with a VSNCP Configure-Ack message.

  (12-Optional) If the UE is requesting deferred IP address allocation in step 8, the UE will now (on the option of a rapid commit option (rapid A DHCPv4 discovery message (with DHCP option) can be issued.

  (13a) The UE may transmit a router solicitation message.

  (13b) When the P-GW transmits the IPv6 prefix to the HSGW, the HSGW transmits a router advertisement message.

  Step 14 is repeated as necessary until all bearers for all PDN connections are re-established.

  (14) The bearer for the PDN connection is re-established on eHRPD based on the selected bearer control mode.

  (14a) If the selected bearer control mode is “MS-only”, the HSGW assumes that the UE establishes all bearers. The UE performs bearer resource allocation requested by the UE for all bearers.

  (14b) If the selected bearer control mode is “MS / NW”, the HSGW establishes all bearers. The HSGW performs a dedicated bearer setup initiated by the NW.

  FIG. 16 is a flowchart of a wireless communication process 1600. In 1602, when roaming from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections, the handover target A single PDN connection is selected from a plurality of active PDN connections for operation within the AN. This selection may be performed based on one of the techniques described herein. At 1604, exchange messages and register a single PDN connection in the handover target AN. As described above, in some embodiments, messages are exchanged between the UE and a gateway server such as an HSGW.

  FIG. 17 is a block diagram of a part of the wireless communication apparatus 1700. When a module 1702 roams from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections, A module for selecting a single PDN connection from a plurality of active PDN connections for operation within a target AN. Module 1704 is a module for exchanging messages and registering a single PDN connection in the handover target AN. The apparatus 1700 and modules 1702, 1704 may be further configured to implement one or more techniques disclosed herein.

  FIG. 18 is a flowchart of a process 1800 for wireless communication. At 1802, multiple co-existing packet data network (PDN) connections to an access point name (APN) by performing a proxy binding update / proxy binding response (PBU / PBA) procedure in the current access network (AN) A network gateway server is provided that assists in roaming user equipment from a current AN that supports the user equipment to a handover target AN that does not support multiple coexisting PDN connections to the APN. At 1804, it is learned whether the gateway server in the target AN supports multiple PDN connections to the APN. At 1806, pre-registration of PDN connection in the target AN is assisted.

  FIG. 19 is a block diagram of a part of the wireless communication apparatus 1900. Module 1902 performs a proxy binding update / proxy binding response (PBU / PBA) procedure within the current access network (AN) to provide multiple coexisting packet data networks (PDNs) to the access point name (APN). A module for preparing a network gateway server that assists in roaming user equipment from a current AN that supports connections to a handover target AN that does not support multiple coexisting PDN connections to an APN. The module 1904 is a module for learning whether or not the gateway server in the target AN supports a plurality of PDN connections to the APN. A module 1906 is a module for assisting the preliminary registration of the PDN connection in the target AN. The apparatus 1900 and modules 1902, 1904, 1906 may be further configured to implement one or more techniques disclosed herein.

  Several techniques have been described for enabling handoff of multiple packet data network connections.

  In addition, roaming from a current access network that supports multiple coexisting PDN connections to a handover target AN that does not support multiple coexisting PDN connections (ie, supports only a single PDN connection) In doing so, several techniques have been disclosed for selecting one of a plurality of simultaneous packet data network connections.

  The embodiments disclosed herein and other embodiments, modules, and functional operations may be implemented in digital electronic circuitry, and include the structures disclosed herein and their structural equivalents. It may be realized by software, firmware or hardware, and may be realized by a combination of one or more of these. The disclosed embodiments and other embodiments can be encoded in one or more computer program products, ie, computer readable media, executed by a data processing device, or operations of a data processing device. It can also be implemented as one or more modules of computer program instructions that control The computer readable medium may be a machine readable storage device, a machine readable storage substrate, a memory device, a composition that acts on a machine readable propagation signal, or a combination of one or more thereof. The term “data processing device” encompasses all devices, devices, and machines for processing data, including by way of example a programmable processor, computer, multiple processors or computers. In addition to hardware, the apparatus may include code for creating an execution environment of the computer program, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these. it can. A propagated signal is an artificially generated signal, for example, an electrical signal, an optical signal, or an electromagnetic wave signal generated by a machine to encode information for transmission to a suitable receiving device.

  A computer program (also called a program, software, software application, script or code) may be written in any form of programming language, including a compiler language or an interpreter language, for example as a stand-alone program or as a module, component, subroutine or As other units suitable for use in a computing environment, they may be deployed in any form. A computer program does not necessarily correspond to a file in a file system. The program may be stored in a part of a file containing other programs or data (eg, one or more scripts stored in a markup language document) and stored in a single file dedicated to that program Alternatively, the files may be stored in a plurality of files to be linked (for example, one or more files storing a module, a subprogram, or a part of code). A computer program may be deployed to be executed on a single computer, and may be executed on a plurality of computers provided at one location or distributed across multiple locations and interconnected by a communication network May be deployed as is.

  The processes and logic flows disclosed herein may be implemented by one or more programmable processors that execute one or more computer programs that implement functions by processing input data and generating output. Good. The process and logic flow may be performed by a dedicated logic circuit such as, for example, a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC).

  Processors suitable for the execution of computer programs may include, by way of example, both general and special purpose microprocessors, as well as any one or more processors of any type of digital computer. A processor typically receives instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor that executes instructions and one or more memory devices that store instructions and data. The computer also typically includes one or more mass storage devices for storing data, eg, a magnetic disk, magneto-optical disk or optical disk, or receives data from the mass storage device and stores mass data. It is operatively connected to the mass storage device to transmit data to the device or to perform both operations. However, the computer does not necessarily have such a device. Devices suitable for storage of computer program instructions and data include, by way of example, semiconductor storage devices such as all types of non-volatile memory including EPROM, EEPROM and flash memory devices, magnetic disks such as internal hard disks or removable devices. Discs, magneto-optical discs, CD-ROM discs and DVD-ROM discs are included. The processor and the memory may be supplemented by a dedicated logic circuit or may be incorporated in the dedicated logic circuit.

  This specification includes many details, but these details are not to be construed as limiting the scope of the invention as claimed or claimable. To be construed as a description of particular features of a particular embodiment. In this specification, several features disclosed in the context of separate embodiments may be combined and implemented in a single embodiment. Conversely, various features disclosed in the context of a single embodiment can be embodied separately in multiple embodiments and can be embodied in any suitable subcombination. Furthermore, although the above describes some features as functioning in a certain combination, initially, even if so claimed, from the claimed combination One or more features may be excluded from the combination in some cases, and the claimed combination may be changed to a partial combination or a variation of a partial combination. Similarly, in the drawings, the operations are shown in a particular order, but such operations need not be performed in the particular order or sequential order shown to achieve the desired result, and It is not necessary to perform all the operations shown.

  Only a few specific examples and examples have been disclosed. Based on the content disclosed here, the above-described specific examples, examples, and other examples can be modified, changed, and extended.

Claims (19)

A wireless communication method executed at user equipment in a wireless communication network, comprising:
Roaming from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections using the processor of the user equipment Selecting a single PDN connection from a plurality of active PDN connections for operation within the handover target AN,
Using the processor, by exchanging messages, in the handover target AN, have a, a step of registering the single PDN connection,
The selection of the single PDN connection is based on a set of rules related to the order in which multiple active PDN connections were established;
The single PDN connection corresponds to the latest PDN connection;
If a PDN connection pre-registered for a new PDN connection already exists in the target AN, the new PDN connection is not considered to be the latest PDN connection and the single PDN connection Wireless communication method not selected as .   The method of claim 1, wherein the message exchange operation is based on an operation mode. The method according to claim 2 , wherein the operation mode is one of an active mode, a sleep mode, and an idle mode. When roaming from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections, Means for selecting a single PDN connection from a plurality of active PDN connections for operation at
Exchange messages, within the handover target AN, and means for registering the single PDN connection,
The selection of the single PDN connection is based on a set of rules related to the order in which multiple active PDN connections were established;
The single PDN connection corresponds to the latest PDN connection;
If a PDN connection pre-registered for a new PDN connection already exists in the target AN, the new PDN connection is not considered to be the latest PDN connection and the single PDN connection Wireless communication device not selected as . The apparatus according to claim 4 , wherein the message exchange operation is based on an operation mode. The apparatus according to claim 5 , wherein the operation mode is one of an active mode, a sleep mode, and an idle mode. A computer program comprising a non-volatile medium from which a computer-readable code is stored, the code is
When roaming from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections, Instructions for selecting a single PDN connection from a plurality of active PDN connections for operation at
Instructions and to pre-register the PDN connection to the access point name to be maintained during operation within the handover target AN (APN) seen including,
The selection of the single PDN connection is based on a set of rules related to the order in which multiple active PDN connections were established;
The single PDN connection corresponds to the latest PDN connection;
If a PDN connection pre-registered for a new PDN connection already exists in the target AN, the new PDN connection is not considered to be the latest PDN connection and the single PDN connection not selected computer programs as. Memory to store instructions,
Execute the instruction,
i) when roaming from a current access network (AN) supporting multiple coexisting packet data network (PDN) connections to a handover target AN not supporting multiple coexisting PDN connections, the handover target Select a single PDN connection from multiple active PDN connections for operation within the AN;
ii) the handover target AN is to exchange messages, to learn whether it supports the PDN connection for multiple coexisting includes a processor, a
The selection of the single PDN connection is based on a set of rules related to the order in which multiple active PDN connections were established;
The single PDN connection corresponds to the latest PDN connection;
If a PDN connection pre-registered for a new PDN connection already exists in the target AN, the new PDN connection is not considered to be the latest PDN connection and the single PDN connection Wireless communication device not selected as . A proxy gate update / proxy binding response (PBU / PBA) procedure is performed by a network gate server in the current access network (AN) to create multiple coexisting packet data networks (PDNs) to the access point name (APN) from the current aN that support connections have away step to assist the roaming user equipment to the handover target aN that does not support PDN connection to a plurality of coexistence to APN,
The PBU / PBA procedure is:
Learning whether a gateway server in the target AN supports multiple PDN connections to an APN;
Supporting a preliminary registration of a PDN connection in the target AN. 10. The method of claim 9 , wherein if the gateway server does not support multiple PDN connections, the pre-registration is assisted by sending an update message that does not include a connection identification element. The method of claim 10, wherein the single PDN connection to the APN corresponds to a current PDN connection. Supports multiple co-existing packet data network (PDN) connections to an access point name (APN) by performing proxy binding update / proxy binding response (PBU / PBA) procedures within the current access network (AN) Means for providing a network gateway server to assist in roaming user equipment from a current AN to a handover target AN that does not support multiple coexisting PDN connections to the APN;
Means for learning whether a gateway server in the target AN supports multiple PDN connections to an APN;
Means for assisting pre-registration of PDN connections in the target AN. A Turkish computer program is stored in non-volatile medium as a code readable by a computer, the code, when executed, the computer,
Supports multiple co-existing packet data network (PDN) connections to an access point name (APN) by performing proxy binding update / proxy binding response (PBU / PBA) procedures within the current access network (AN) Providing a network gateway server to assist roaming user equipment from a current AN to a handover target AN that does not support multiple coexisting PDN connections to the APN;
Learning whether the gateway server in the target AN supports multiple PDN connections to the APN;
Assist pre-registration of PDN connection in the target AN;
Computer program which sends a message indicating whether the PDN connection to a plurality of coexistence is supported. In a system for wireless communication,
When roaming from a current access network (AN) that supports multiple coexisting packet data network (PDN) connections to a handover target AN that does not support multiple coexisting PDN connections, within the handover target AN Select a single PDN connection from a plurality of active PDN connections for
User equipment configured to exchange messages and register the single PDN connection in the handover target AN;
Supports multiple co-existing packet data network (PDN) connections to an access point name (APN) by performing proxy binding update / proxy binding response (PBU / PBA) procedures within the current access network (AN) Providing a network gateway server to assist in roaming user equipment from a current AN to a handover target AN that does not support multiple coexisting PDN connections to the APN;
Learning whether the gateway server in the target AN supports multiple PDN connections to the APN;
A gateway server configured to assist pre-registration of PDN connections in the target AN. 13. The apparatus of claim 12, wherein if the gateway server does not support the multiple PDN connections, the pre-registration is assisted by sending an update message that does not include a connection identification element. The apparatus of claim 12, wherein the single PDN connection to the APN corresponds to a current PDN connection. A network gateway server in a current access network (AN),
From the current AN that supports multiple coexisting packet data network (PDN) connections to the access point name (APN) to the APN by performing a proxy binding update / proxy binding response (PBU / PBA) procedure Having a processor to assist roaming user equipment to a handover target AN that does not support multiple coexisting PDN connections;
The PBU / PBA procedure is:
Learning whether a gateway server in the target AN supports multiple PDN connections to an APN;
A network gateway server comprising assisting in pre-registration of PDN connections in the target AN. 13. The apparatus of claim 12, wherein if the gateway server does not support the multiple PDN connections, the pre-registration is assisted by sending an update message that does not include a connection identification element. The apparatus of claim 12, wherein the single PDN connection to the APN corresponds to a current PDN connection.

Images