WO2011055478A1 - 移動端末及びパケットフィルタ設定方法 - Google Patents

移動端末及びパケットフィルタ設定方法 Download PDF

Info

Publication number
WO2011055478A1
WO2011055478A1 PCT/JP2010/005383 JP2010005383W WO2011055478A1 WO 2011055478 A1 WO2011055478 A1 WO 2011055478A1 JP 2010005383 W JP2010005383 W JP 2010005383W WO 2011055478 A1 WO2011055478 A1 WO 2011055478A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
mobile terminal
packet
ipv4
packet filter
Prior art date
Application number
PCT/JP2010/005383
Other languages
English (en)
French (fr)
Inventor
隆二 杉崎
啓吾 阿相
新吉 池田
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Publication of WO2011055478A1 publication Critical patent/WO2011055478A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H04W80/045—Network layer protocols, e.g. mobile IP [Internet Protocol] involving different protocol versions, e.g. MIPv4 and MIPv6

Definitions

  • the present invention relates to a mobile terminal and a packet filter setting method according to a wireless communication technique for a communication node (mobile terminal) that performs communication using IP (Internet Protocol) through a wireless communication medium.
  • IP Internet Protocol
  • GTP GPRS (General Packet Radio Service) Tunneling Protocol
  • PMIP Proxy Mobile IP
  • DSMIP Dual Stack Mobile
  • 3GPP 3rd Generation Partnership Project
  • 3GPP has established GTP and PMIP as technologies for ensuring mobility on a 3GPP access network (hereinafter referred to as 3G access), and a non-3GPP (non-3GPP) access network (hereinafter referred to as N3G access).
  • 3G access 3GPP access network
  • N3G access non-3GPP (non-3GPP) access network
  • PMIP and DSMIP have been established as technologies for ensuring movement transparency.
  • FIG. 1 illustrates an example of a communication network in a case where a UE performs communication using mobility transparency technology (for example, GTP, PMIP, DSMIP) with 3G access or N3G access.
  • mobility transparency technology for example, GTP, PMIP, DSMIP
  • FIG. 1 shows the mobility management of the UE 10 on the MME (Mobility Management Entity) 20 and 3G access (eg UTRAN) 35 that is responsible for the mobility management of the UE 10 on the UE 10 and 3G access (eg E-UTRAN) 25.
  • MME Mobility Management Entity
  • 3G access eg UTRAN
  • E-UTRAN 3G access
  • SGSN Serving GPRS Support Node 30
  • eNB eNode B
  • SGW Serving Gateway: MAG (also called Mobility Anchor Gateway) 40 in PMIP
  • PGW Packet Gateway: DSMIP HA (Home Agent) or PMIP
  • LMA Local Mobility Mobility Anchor
  • PDN Packet Data Network
  • the UE 10 when the UE 10 communicates with an external network (for example, PDN (Packet Data 70) illustrated in FIG. 1) through 3G access, the UE 10 communicates with the PGW 50 through a PDN connection and an EPS bearer. (Called EPS Bearer, bearer, etc.) must be established.
  • the UE 10 acquires an IP address through the establishment of the PDN connection, and establishes an EPS bearer for communicating with the PDN 70.
  • the IP address acquired by the UE 10 is an IPv4 address (also called IPv4 home address, IPv4 HoA, etc.), an IPv6 prefix (also called IPv6 home prefix (Home Prefix), etc.), or both. Also good.
  • IPv6 home address IPv6 address
  • IETF Internet Engineering Task Task Force
  • an additional EPS bearer can be established in the existing PDN connection.
  • the UE 10 may establish an additional PDN connection with the PGW 50 separately from the existing PDN connection. In this way, the UE 10 can communicate with the PDN 70 by establishing a PDN connection and an EPS bearer with the PGW 50 via the 3G access 25 and 35 (see Non-Patent Document 1 below).
  • the SGW 40 When PMIP is applied in the process of establishing a PDN connection, the SGW 40 notifies the PGW 50 of local information (for example, the address of the SGW 40) using the PBU (Proxy Binding Update) message. By doing so, the PGW 50 associates the notified location information (hereinafter also referred to as location information) of the UE 10 with the previously assigned IPv4 home address or IPv6 home prefix, etc.
  • BCE Biting Cache Entry: binding cache entry
  • the PGW 50 refers to the BCE and compares the destination address (that is, IPv4 home address or IPv6 home address) of the received packet addressed to the UE 10 with the IP address registered in the BCE.
  • the PGW 50 extracts the location information of the UE 10 corresponding to the IP address registered in the BCE, and transfers the packet to the UE 10 via the SGW 40. That is, even if the network to which UE 10 is connected (attached) changes, the SGW 40 notifies the PGW 50 of network information related to the current location of the UE 10, and the PGW 50 registers (updates) the BCE, so that the UE 10 hands over the network. Also, it becomes possible to correctly receive the message addressed to the HoA of the UE 10. Note that the SGW 40 generally transmits a PBU message based on an operator policy for managing the network, or at the time of handover accompanying the movement of the UE 10.
  • the UE 10 can simultaneously have HoAs of different IP versions (that is, different address types) (for example, IPv6 HoA and IPv4 HoA), and the UE 10 can transmit and receive packets using each HoA.
  • the packet transmission / reception using each HoA is performed using one EPS bearer established between the UE 10 and the PGW 50 or a plurality of EPS bearers divided by service unit.
  • the packet sent from the PDN 70 to the UE 10 is transferred using the EPS bearer established between the UE 10 and the PGW 50.
  • the PGW 50 uses packet transfer information (TFT: Traffic® Template) managed by the PGW 50 in order to determine / determine which EPS bearer is used to transfer the packet to the UE 10.
  • TFT uses, for example, information stored in a PBU message sent from the SGW 40 or a message exchanged by “PDN GW initiated bearer modification without bearer QoS update procedure” defined in Non-Patent Document 1. Generated / updated.
  • the TFT stores information such as the IP address and port number of the UE 10 (see Non-Patent Documents 3 to 5 below).
  • the TFT is classified into a UL TFT (UplinkUpTFT) used when the UE 10 transmits a packet and a DL TFT (Downlink TFT) used when the PGW 50 transfers the packet to the UE 10.
  • Each TFT is updated when the UE 10 hands over the network and the IP address is updated, or when the communication environment is to be changed / changed (when the EPS bearer used for communication is to be changed).
  • the TFT can be maintained by a device on the network side (for example, PGW 50) when the UE 10 is handed over, the TFT does not need to be created from scratch.
  • the resources of the EPS bearer established by the UE 10 before the handover at the same time as the TFT is updated are determined based on the EPS bearer information established by the UE 10 before the handover. It is also secured in a network (for example, SGW 40, SGSN 30, RNC (Radio Network Controller) in the case of UTRAN). As a result, the UE 10 can maintain communication with the PDN 70 even after handover of the network, and can receive packets.
  • a network for example, SGW 40, SGSN 30, RNC (Radio Network Controller) in the case of UTRAN.
  • Non-Patent Document 1 includes “E-UTRAN ⁇ ⁇ ⁇ to UTRAN lu mode Inter RAT handover procedure” as a method for maintaining communication with the PDN 70 and continuing to receive packets even when the UE 10 hands over the network. It is disclosed. “E-UTRAN-to-UTRAN-lu mode-Inter-RAT--handover-procedure” disclosed in Non-Patent Document 1 is a conventional technique used when handing over from a 3G access 25 called E-UTRAN to a 3G access 35 called UTRAN. is there.
  • This “E-UTRAN-to-UTRAN-lu-mode-Inter-RAT-handover-procedure” is divided into two phases, “Preparation-phase” and “Execution-phase”. By correctly completing the two phases, the UE 10 can perform E-UTRAN. To UTRAN. Hereinafter, “Preparation phase” and “Execution phase” will be described.
  • FIG. 2 is a sequence diagram for explaining the “Preparation phase” of “E-UTRAN”, “UTRAN,” “lu”, “mode”, “Inter”, “RAT”, “handover”, and “procedure”. Note that FIG. 2 shows an example of a handover process sequence in the system configuration shown in FIG. 1, and only the devices corresponding to the components shown in FIG. Yes.
  • the UE 10 has established a PDN connection for communicating with the PDN 70 in the 3G access (E-UTRAN) 25 and has established a plurality of EPS bearers.
  • the eNB (not shown in FIG. 1) moves the UE 10 from the 3G access (E-UTRAN) 25 to the 3G access (UTRAN) according to the communication status of the UE 10, the load state of the eNB that supports the UE 10, and the like. It decides to hand over to 35 (step S1001: Handover Initiation in FIG. 2).
  • the eNB is a device used in the handover destination network of the UE 10 (for example, the target RNC, the target SGSN 30, and the target SGW 40), and sends a Handover Required message to the source MME 20 to secure resources for the EPS bearer established by the UE 10 before the handover.
  • Step S1003 HandoverHandRequired in FIG. 2.
  • the source MME 20 determines the handover from the parameter (for example, Target RNC Identifier) stored in the Handover Required message received in Step S1003 to the 3G access (UTRAN) 35. Subsequently, the source MME 20 starts a Handover Required resource allocation procedure by transmitting a Forward Relocation Request message to the target SGSN 30 in order to secure the resource of the EPS bearer established by the UE 10 before the handover.
  • the parameter for example, Target RNC Identifier
  • the target SGSN 30 that has received the Forward Relocation Request message overwrites the EPS Bearer Contexts stored in the Forward Relocation Request message with the PDP (Packet Data Protocol) Contexts managed by the target SGSN 30 (step S1005: Forward Relocation Request) in FIG. .
  • PDP Packet Data Protocol
  • the target SGSN 30 determines whether the SGW 40 needs to be reassigned. If the SGW 40 is to be reassigned, the target SGSN 30 selects the target SGW 40 and transmits a Create Session Request message to the SGW 40. In the configuration example illustrated in FIG. 1, the source SGW 40 and the target SGW 40 are the same. Subsequently, the target SGSN 30 establishes EPS Bearer Contexts indicated by the parameters stored in the Forward Relocation Request message received in step S1005. At this time, the target SGSN 30 terminates the use of the corresponding EPS bearer for EPS Bearer Contexts that could not be established due to the network operator policy or the like.
  • This EPS Bearer Contexts is managed by the target SGSN 30 and the UE 10, and terminates the use of EPS BearerUEContexts corresponding to the RAB (Radio Network ⁇ Resources: radio network resource) that was not established by the Session Management Procedure performed by the target SGSN30 later ( Step S1007 of FIG. 2: Create Session Request).
  • RAB Radio Network ⁇ Resources: radio network resource
  • the target SGW 40 that has received the Create Session Request message allocates resources for the UE 10, and transmits a Create Session Request message to the target SGSN 30 (step S1009: Create Session Response in FIG. 2). If the SGW 40 is not reassigned, steps S1007 and 1009 in FIG. 2 can be omitted.
  • the target SGSN 30 transmits a Relocation Request message to the target RNC to establish the RAB. Also, the target SGSN 30 creates RAB to be setup list for each RAB and stores it in the Relocation Request message.
  • the accepted RAB reserves resources for the UE 10 in the target RNC (step S1011: Relocation request in FIG. 2).
  • the target RNC that has received the Relocation Request message allocates resources for the UE 10, stores parameters to be applied for the resources of the UE 10 in the Relocation Request Acknowledgment message, and transmits them to the target SGSN 30. At this time, the target RNC prepares to receive Downlink GTP PDUs sent from the SGW 40 or the target SGSN 30 (when Direct tunnel is not used) for the accepted RAB (step S1013 in FIG. 2: Relocation) Request Acknowledge).
  • Step S1015 in FIG. 2 Create Indirect Data Forwarding Tunnel Requests.
  • this Create Indirect Data Forwarding Tunnel Request message is transmitted to the common SGW 40.
  • the target SGW 40 that has received the Create / Indirect / Data / Forwarding / Tunnel / Request message transmits a Create / Indirect / Data / Forwarding / Tunnel / Response message storing the IP address of the target SGW 40 to the target SGSN 30 (S1017: Create / Indirect / Data / Forwarding / Tunnel / Response in FIG. 2).
  • the target SGSN 30 transmits a Forward Relocation Response message storing parameters indicating that a new SGW 40 has been selected to the source MME 20 (Step S1019 in FIG. 2: Forward Relocation Response).
  • the source MME 20 transmits a Create Indirect Data Forwarding Tunnel Request message to the SGW 40 (step S1021: Create Indirect Data Forwarding Tunnel Request in FIG. 2).
  • the “Indirect Forwarding” may be performed by an SGW 40 different from the SGW 40 used as an anchor point (a node that directly communicates with the PGW 50) for the UE 10.
  • the SGW 40 that has received the Create / Indirect / Data / Forwarding / Tunnel / Request message transmits a Create / Indirect / Data / Forwarding / Tunnel / Response message storing the IP address of the SGW 40 to the source MME 20. If the SGW 40 does not support “Indirect Forwarding”, a Create Indirect Data Forwarding Tunnel Response message is transmitted to the source MME 20 without storing the address of the SGW 40 (step S1023: Create Indirect Data Forwarding in FIG. 2). Tunnel Response).
  • FIG. 3 is a sequence diagram for explaining “Execution phase” of “E-UTRAN”, “UTRAN”, “lu”, “mode”, “Inter”, “RAT”, “handover”, and “procedure”.
  • the source MME 20 completes the “Preparation phase” by sending a Handover command message to the source eNodeB. Further, the source MME 20 stores the parameter necessary for data transfer to the UE 10 received in Step S1019 or Step S1023 of “Preparation phase” in this Handover Command message (Step S1501: Handover Command in FIG. 3). .
  • the source eNB that has received the Handover command message transmits a Handover from E-UTRAN command message to the UE 10 in order to hand over the UE 10 to the handover destination network (also referred to as target access network: Target access network). Also, the source eNB stores a parameter indicating that the target RNC has been set up in the Preparation phase in this Handover from E-UTRAN Command message. Further, the UE 10 that has received the Handover from U E-UTRAN Command message associates the identifier (Identities) of the EPS bearer that the UE 10 has with the information of each RAB stored in the Handover from E-UTRAN Command message (FIG. 3). Step S1503: Handover from E-UTRAN Command).
  • Step S1503 and subsequent steps are not directly related to the present invention, and thus the description thereof is omitted.
  • the TFT is registered based on an EPS bearer that takes into account the conditions of the currently connected network, and changes in network conditions within the same network or changes in network conditions due to differences in network conditions before and after handover.
  • the EPS bearer since the EPS bearer is not established (that is, information is not registered in the TFT), communication may be delayed due to a process for re-establishing the EPS bearer.
  • a UE that supports IPv4 and IPv6 has established an EPS bearer in a network before handover (for example, E-UTRAN), and is registered in the TFT,
  • the handover process for example, the steps of FIG. 2
  • End of use of EPS Bearer Contexts makes it impossible to use the EPS bearer established before the handover, and until the processing such as newly re-establishing EPS bearer is completed, packets from the communication partner are completed. There is a problem that it becomes impossible to receive.
  • the EPS bearer is established again and registered in the TFT so as to correspond to the IPv4 address, so that the UE communicates again.
  • communication with the other party becomes possible, there arises a problem that it is necessary to wait for the completion of the handover process.
  • the present invention provides a mobile terminal capable of performing communication using IP through a wireless communication medium, for example, a plurality of address types (or addresses such as IPv4 address type and IPv6 address type). Version), even if the address type provided by a change in the network environment changes (for example, when handing over to a network that provides only a single address type) It is an object to be able to maintain a communication connection before a change (for example, before a handover).
  • the present invention considers handover by a mobile terminal as a change in the network environment, and the EPS bearer established by the mobile terminal supporting IPv4 and IPv6 is associated with only an IPv6 address on the TFT. Even when the mobile terminal is handed over to a network that supports only IPv4, the object is to enable handover without interrupting communication between the mobile terminal and its communication partner.
  • the mobile terminal of the present invention is a mobile terminal capable of performing communication using IP addresses of a plurality of different address types, A network connection unit for connecting to a network in order to communicate with a predetermined communication partner; Packets that set packet filters corresponding to a plurality of different address types for the packet flow with the predetermined communication partner regardless of the address types available on the network to which the network connection unit is connected Filter setting means Have.
  • a mobile terminal capable of performing communication using IP through a wireless communication medium performs communication using a plurality of address types (or address versions) such as an IPv4 address type and an IPv6 address type. Even if the address type provided by the change in the network environment changes in the environment (for example, when handing over to a network that provides only a single address type), before the change of the network environment (for example, before the handover) The communication connection can be maintained.
  • a packet filter setting method of the present invention is a packet filter setting method in a mobile terminal capable of performing communication using IP addresses of a plurality of different address types. Regardless of the address type that can be used in the network that the mobile terminal is connected to communicate with a predetermined communication partner, a plurality of different address types can be used for the packet flow with the predetermined communication partner. Packet filter setting step to set the corresponding packet filter, Have. Accordingly, an environment in which a mobile terminal capable of performing communication using IP through a wireless communication medium performs communication using a plurality of address types (or address versions) such as an IPv4 address type and an IPv6 address type, for example. Even when the address type provided by the change of the network environment changes (for example, when handover is performed to a network that provides only a single address type), the network environment changes before the change (for example, before the handover). Communication connection can be maintained.
  • the UE when the IP address type that can be used in the network changes while the UE is communicating with an external network using a plurality of IP addresses of different IP versions (for example, only one IP address) Even if the IP address type in the network has changed (eg, before handover), the UE may have multiple IP versions (eg, IPv4 and By updating the packet transfer information (TFT) so as to associate the IP addresses of both versions of IPv6, communication can be maintained even after the IP address type is changed in the network (for example, after handover). it can.
  • TFT packet transfer information
  • the time for waiting for the re-establishment of the communication path can be reduced compared to the handover process in which the communication path is re-established after the conventional handover, Furthermore, the problem that the packet cannot be received can be solved.
  • each device e.g. , UE and PGW
  • the flowchart which shows an example of the processing flow of the mobile terminal (UE) in the 1st Embodiment of this invention
  • the figure which shows an example of a structure of the mobile terminal (UE) in the 2nd Embodiment of this invention.
  • the flowchart which shows an example of the processing flow of the mobile terminal (UE) in the 2nd Embodiment of this invention.
  • FIG. 1 is a diagram showing an example of a system configuration common to the first and second embodiments of the present invention.
  • the communication system illustrated in FIG. 1 is at least on the MME 20, 3G access (eg, UTRAN) 35 responsible for mobility management of the UE 10 on the UE 10, 3G access (eg, E-UTRAN) 25.
  • SGSN 30 in charge of mobility management of UE 10, eNB (not shown in FIG. 1) that transmits data to radio waves to UE 10, SGW 40 that performs user data path control between base stations, user address assignment to UE 10 and users between SGW 40
  • the PGW 50 performs data path control, and has a function of establishing a PDN connection in N3G access, and has an ePDG 60 in charge of packet protection between the UE and the like when transmitting and receiving packets with the UE.
  • the UE 10 has at least one or more communication interfaces, supports IPv4 and IPv6, and uses the 3G access 25, 35, or the N3G access 65, or both accesses by properly using each IP type. Can be connected to the PGW 50.
  • the UE 10 performs handover between the 3G access 25 developed by UTRAN such as E-UTRAN and the 3G access 35 such as UTRAN and GERAN (GSM EDGE Radio Access Network) as established by 3GPP. Suppose you can do it.
  • the UE 10 can also perform a handover between the 3G access 25, 35 and the N3G access 65.
  • the UE 10 is already connected to the PGW 50 via 3G access using GTP or PMIP, and performs packet transmission / reception using IPv4 HoA and IPv6 HoA. It is assumed that the EPS bearer associated with is established. At this time, an example of the TFT of the PGW 50 is in the state illustrated in FIG. 5A, for example.
  • FIG. 5A is a diagram showing an example of a TFT (before processing) in the first and second embodiments of the present invention.
  • FIG. 5A shows an example of a TFT held by the PGW 50 when the UE 10 establishes an EPS bearer by using E-UTRAN using IPv4 HoA and IPv6 HoA.
  • the HoA held by the UE 10 and the bearer ID (Bearer ID) for identifying each EPS bearer are registered.
  • One stage of the set of HoA and bearer ID is sometimes called a packet filter.
  • parameters other than the bearer ID may be used as long as the relationship between the HoA held by the UE 10 and the EPS bearer is known. For example, “Single destination port type”, “Destination port range type”, “Single source port type”, “Source port range type” and the like described in Non-Patent Document 3 may be used.
  • the PGW 50 having the TFT of FIG. 5A receives a packet sent from the communication partner of the UE 10 to the IPv4 HoA that is one of the addresses managed by the UE 10, the PGW 50 refers to the TFT to the IPv4 HoA.
  • the received packet is transferred to the UE 10 using the associated bearer ID 1 (or “Single destination port type” not shown).
  • FIG. 4 is a sequence diagram for explaining an example of system operation (handover case from 3G access (E-UTRAN) 25 to 3G access (UTRAN) 35) in the first embodiment of the present invention.
  • E-UTRAN 3G access
  • UTRAN 3G access
  • FIG. 4 shows an example of a handover process sequence in the system configuration shown in FIG. 1, and only the devices corresponding to the components shown in FIG. Yes.
  • FIG. 4 At least UE10, source eNB used in E-UTRAN already attached by UE10, source MME20, SGW40, PGW50, HSS, target RNC, target SGSN30, and target SGW40 used in handover destination UTRAN An example of a processing sequence is illustrated.
  • the UE 10 has already been attached to the 3G access 25 of E-UTRAN, and communicates with the PDN 70 using the PDN connection and EPS bearer established between the UE 10 and the PGW 50.
  • each device for example, UE 10 and PGW 50
  • the UE 10 When the UE 10 is communicating with the PDN 70, the UE 10 is likely to exceed the packet forwarding area covered by the 3G access 25 of the E-UTRAN, or when a different network is allocated to the UE 10 based on the operator policy.
  • the eNB to which the UE 10 is connected starts the handover process for the handover destination access network (see Non-Patent Document 1 above).
  • the UTRAN (3G access 35) that is the handover destination of the UE 10 may be restricted depending on the operator policy of the UTRAN (handover destination network) or the IP version restriction based on the registration information of the communication partner of the UE 10 (for each PDN to be used). Therefore, the network can use only IPv4.
  • the UE 10 attaches to the E-UTRAN (3G access 25) and acquires IPv4 HoA and IPv6 HoA. Subsequently, the UE 10 establishes a PDN connection and an EPS bearer for communication with the PDN 70 using each HoA with the PGW 50. At this time, the UE 10 and the PGW 50 hold the TFT in FIG. 5A (step S101 in FIG. 4: Uplink and Downlink User Plane PDUs).
  • the UE 10 confirms the IP version supported by the UE 10 itself (for example, confirmation of the held IP address). For example, when the UE 10 is compatible with IPv4 and IPv6 and holds only IPv6 HoA, the UE 10 acquires IPv4 HoA (step S103 in FIG. 4: IP address confirmation).
  • the UE 10 When the UE 10 itself holds IPv4 HoA and IPv6 HoA, the UE 10 is an EPS bearer (for example, bearer ID 2 shown in FIG. 5A) that is supported by only the IPv6 HoA in the TFT (UL TFT) held by the UE 10 itself. (Such as EPS bearer) exists.
  • EPS bearer for example, bearer ID 2 shown in FIG. 5A
  • all EPS bearers registered in the TFT are associated with both IPv4 HoA and IPv6 HoA addresses of UE 10
  • all EPS bearers are maintained even after handover to UTRAN (3G access 35) that can only use IPv4 Therefore, the solution technique in the first embodiment of the present invention is terminated (step S105 in FIG. 4: TFT confirmation).
  • the UE 10 determines whether the application used in the EPS bearer is an IPv6-only application (or supports IPv4). Check if it is an application. If the application is dedicated to IPv6, the EPS bearer maintenance process using IPv4 HoA (for example, adding IPv4 HoA to the application or using IPv4 HoA as an alternative to IPv6 HoA) is not possible. The solution in the form is terminated (step S107 in FIG. 4: application confirmation).
  • the UE 10 further confirms the IP version supported by the communication partner. This confirmation can be executed, for example, by confirming whether the IPv4 address of the communication partner is registered in DNS (Domain (Name Server: domain name server) or by directly inquiring the communication partner. If it is confirmed that the communication partner of UE10 does not support IPv4, EPS bearer maintenance processing using IPv4 HoA (for example, adding IPv4 HoA to the application or using IPv4 HoA as an alternative to IPv6 HoA) Therefore, the solution technique in the first embodiment of the present invention is terminated (step S109 in FIG. 4: confirmation of corresponding IP version of communication partner).
  • DNS Domain (Name Server: domain name server)
  • 3GPP SA2 is defined in order to update the TFT of each device (for example, the UE 10 and the PGW 50).
  • PGW initiated bearer modification without bearer QoS update procedure is performed to update the TFT in FIG. 5B (step S111 in FIG. 4: TFT update).
  • steps S103 to S111 IP address confirmation to TFT update
  • all EPS bearers can be maintained even after handing over to UTRAN (3G access 35) that can only use IPv4. Ready to continue receiving.
  • the steps S103 to S111 are not necessarily steps that must be performed, and any one or a plurality of steps may be omitted.
  • the UE 10 already knows the corresponding IP version of the communication partner, it is not necessary to check the corresponding IP version of the communication partner in step S109.
  • the order of the steps is not limited to the order described above, and the order of the steps may be changed as long as the same result can be obtained.
  • the UE 10 After updating the TFT in step S111, the UE 10 performs a general “E-UTRAN UTRAN lu mode Inter RAT handover procedure” by the eNB.
  • the processing in steps S113 and S115 in FIG. 4 is the same as the processing in steps S1001 and S1003 in FIG.
  • step S117 Forward Relocation Request
  • a Forward Relocation Request message is transmitted from the source MME 20 to the target SGSN 30.
  • the processing in step S117 in FIG. 4 and the parameters stored in the Forward-Relocation-Request message are the same as those in step S1005 in FIG. 2 showing the conventional technique, but are one of the parameters stored in the Forward-Relocation-Request message.
  • a TFT which is one of the contents of the MM Context, has been updated from FIG. 5A to FIG. 5B by the processing in steps S103 to S111 in FIG.
  • the TFT shown in FIG. 5B is characterized in that it further has a packet filter indicating the relationship between IPv4 HoA and bearer ID 2 when compared with the TFT shown in FIG. 5A.
  • a packet filter indicating the relationship between IPv4 HoA and bearer ID 2 when compared with the TFT shown in FIG. 5A.
  • the PGW 50 receives a packet sent to the IPv6 HoA corresponding to the bearer ID2, it uses the IP address (IPv4 HoA) associated with the bearer ID2 based on this packet filter. By determining the destination, the received packet can be transferred to the UE 10.
  • IPv4 HoA IP address
  • the updated TFT shown in FIG. 5B is sent from the source MME 20 to the target SGSN 30, so that the target SGSN 30 used in the 3G access (UTRAN) 35 that is only available for IPv4 is that all EPS bearers are IPv4 (and It can be confirmed that it is compatible with IPv6), and a process of securing resources for all EPS bearers is performed. Thereafter, a general “E-UTRAN-to-UTRAN-lu mode-Inter-RAT-handover” is performed.
  • the UE 10 can confirm that the EPS bearer associated only with IPv6 HoA is not compatible with IPv4 in step S107 (application confirmation step) and step S109 (communication counterpart IP version confirmation step) in FIG.
  • the UE 10 determines whether to maintain / release (release) the EPS bearer associated with only the IPv6 HoA or used in the application capable of using only the IPv6 after the handover to the network that can use only the IPv4.
  • the TFTs may be updated as shown in FIG. 5C using the parameters (for example, “DELETE”, “CHANGE”, “PRESETVE”). In FIG. 5C, only “DELETE” is illustrated as this parameter.
  • “DELETE” is information that explicitly indicates that a packet flow is to be deleted.
  • the packet flow storing “DELETE” is surely deleted.
  • the EPS bearer associated only with IPv6 HoA is released during the handover process, but it is ensured by explicitly indicating “DELETE”. Can be deleted.
  • CHANGE is information that explicitly indicates that the destination address of the packet is to be converted.
  • the PGW 50 may check the TFT (DL TFT) held by the PGW itself, and may convert the packet sent to the IPv6 HoA to the IPv4 HoA. Or it can be determined that the PGW 50 may transfer the packet to the IPv4 HoA.
  • PRESERVE is information that explicitly indicates that a packet flow is secured.
  • the packet flow associated only with IPv6 HoA is released during the handover process.
  • the UE 10 is reserved for use again when handing over to a network where the IPv6 HoA can be used and the IPv6 HoA can be used continuously.
  • the parameters for determining the maintenance / release (release) of these TFTs may be parameters other than those described here. Further, in FIG. 5C, these parameters are stored at the location where the IP address is stored. However, these parameters may be stored other than the location where the IP address is stored as long as these parameters can be confirmed.
  • FIG. 6 is a diagram illustrating an example of the configuration of the UE 10 in the first embodiment of the present invention.
  • the UE 10 is connected to an access network (3G access 25, 35, 65, etc.) and performs communication processing in a lower layer, and performs packet communication processing such as IP on the upper side of the wireless communication unit 131.
  • the radio communication unit 131 is connected to the E-UTRAN (3G access 25) before the handover, and the radio communication unit 131 is connected to the UTRAN (3G access 35) after the handover. It is described as being connected.
  • the processing flow of the UE having the configuration illustrated in FIG. 6 will be described in detail with reference to FIG. 7, focusing on processing related to the connection control unit that performs characteristic processing in the present invention. It is assumed that the UE 10 has already been connected to the 3G access (E-UTRAN) 25 via the wireless communication unit 131 and can transmit and receive packets using IPv4 HoA and IPv6 HoA. Further, in this state, the UE 10 performs handover to the 3G access (UTRAN) 35 that can use only IPv4.
  • E-UTRAN 3G access
  • UTRAN 3G access
  • FIG. 7 is a flowchart showing an example of a processing flow of the UE 10 in the first embodiment of the present invention.
  • the UE 10 acquires an IP address (for example, IPv4 HoA, IPv6 HoA) by the connection control unit 133 from the wireless communication unit 131 via the packet processing unit 132 in order to communicate with the PDN 70 by 3G access (E-UTRAN) 25.
  • the PDN connection and the EPS bearer are established with the PGW 50 (step S141 in FIG. 7).
  • the UE 10 transfers the received packet from the connection control unit 133 to the IP address determination unit 134, and confirms the IP address assigned by the 3G access (E-UTRAN) 25 (step S142 in FIG. 7).
  • the UE 10 that supports IPv4 and IPv6 can generally acquire IPv4 HoA and IPv6 HoA.
  • the IPv4 HoA acquisition is determined by the connection control unit 133, and the packet processing unit 132 and the wireless communication unit 131 are used. Acquire IPv4 HoA. If the UE 10 supports only IPv6 and holds only IPv6 HoA, the process ends (step S143 in FIG. 7).
  • the UE 10 instructs the TFT determination unit 135 from the connection control unit 133 to check the TFT held by the UE 10 itself (step S144 in FIG. 7). It is confirmed whether there is an EPS bearer (state in FIG. 5A) associated with only IPv6 HoA in the contents registered in (step S145 in FIG. 7).
  • the UE 10 instructs the application determination unit 136 from the connection control unit 133 to confirm the IP version corresponding to the application using the EPS bearer (FIG. 7).
  • step S146 it is determined whether this application is compatible with IPv4 as well as IPv6 (step S147 in FIG. 7).
  • the UE 10 sends a communication partner communicating with the corresponding IP version confirmation processing unit 137 of the communication partner from the connection control unit.
  • An instruction is given to confirm the corresponding IP version using, for example, DNS (step S148 in FIG. 7), and it is determined whether the communication partner is compatible with both IPv4 and IPv6 (step S149 in FIG. 7). .
  • the UE 10 When the communication partner of the UE 10 supports both IPv4 and IPv6, the UE 10 also associates the IPv4 HoA with the EPS bearer associated with only the IPv6 HoA from the connection control unit 133 to the TFT update processing unit 138.
  • the TFT is updated (step S150 in FIG. 7) by instructing to perform (that is, the state shown in FIG. 5B). Thereafter, the UE 10 performs a handover process from the 3G access (E-UTRAN) 25 to the 3G access (UTRAN) 35 (step S151 in FIG. 7).
  • the UE 10 before the UE 10 is handed over to a network that can use only IPv4 (for example, after attaching to the PGW 50 (after establishing the PDN connection and EPS bearer)),
  • IPv4 for example, after attaching to the PGW 50 (after establishing the PDN connection and EPS bearer)
  • IPv4 for example, after attaching to the PGW 50 (after establishing the PDN connection and EPS bearer)
  • IP version supported by the UE 10 and the communication partner and the corresponding IP version of the application being used By checking the IP version supported by the UE 10 and the communication partner and the corresponding IP version of the application being used, and reflecting it on the TFT, it does not depend on the IP version supported by the handover destination network.
  • packets can be continuously received from the communication partner, and it is not necessary to newly establish an EPS bearer.
  • FIG. 8 is a sequence diagram for explaining an example of the system operation according to the second embodiment of the present invention.
  • the sequence illustrated in FIG. 8 is an operation performed when the UE connects to the E-UTRAN.
  • the correspondence with the configuration illustrated in FIG. 1 is that the UE 10 connects to the 3G access (E-UTRAN) 25. It is the operation when doing.
  • E-UTRAN 3G access
  • FIG. 8 shows at least UE10, eNB that directly transmits and receives packets with UE10, MME in charge of mobility management of UE10 (new MME (New MME) 20 and old MME / SGSN (Old MME / SGSN)), UE10 EIR (Equipment Identity ⁇ Register) that confirms the identity (Identity), SGW 40 that supervises the eNB, plays a role of gateway to the PDN 70, manages PGW 50 that manages the location information of the UE 10, charging control of the UE 10, etc.
  • An example of the processing sequence by the HSS that holds and manages the PCRF, the subscription information of the UE 10 and the like is illustrated.
  • the component which can bear each function instead you may use them.
  • FIG. 8 is a conventional technique “AttachcProcedure” described in Non-Patent Document 1.
  • the second embodiment of the present invention is a technique in which the parameters of messages exchanged by “Attach Procedure” of the prior art are improved so that the EPS bearer before handover can be maintained even after handover.
  • the UE 10 establishes a PDN connection and an EPS bearer between the UE 10 and the PGW 50 in order to communicate with the PDN 70 in E-UTRAN (3G access 25).
  • the UE 10 transmits an Attach Request message to the eNB in order to establish this PDN connection and EPS bearer.
  • the UE 10 is always IPv4 HoA except for the case where only one address type (for example, only IPv6) is assigned due to the limitation of the operator policy of the network to which the UE 10 is to connect.
  • IPv6 HoA (precisely, IPv6 HoA is generated after obtaining the IPv6 prefix) and associated with the established EPS bearer (step S201: Attach Request in FIG. 8).
  • the new MME 20 checks whether information that the UE 10 has previously connected to the 3G access remains, checks the identifier (Identity) of the UE 10, and further the network connection information of the UE 10 If it remains, a process for deleting it is performed (for details, refer to Non-Patent Document 1).
  • the new MME 20 acquires a TFT related to the UE 10 (for example, inquires of the HSS). Subsequently, the new MME 20 transmits a parameter (PDN address) in which the IP address of the UE 10 is stored to the SGW 40 (step S205 in FIG. 8: Create Session Request).
  • PDN address the parameter in which the IP address of the UE 10 is stored to the SGW 40
  • the SGW 40 creates a TFT (EPS bearer table) using the IP address of the UE 10 or the like. Subsequently, the SGW 40 transmits parameters (for example, PDN address) received from the new MME to the PGW 50 (Step S207: Create Session Request in FIG. 8).
  • parameters for example, PDN address
  • the PGW 50 creates a TFT (EPS bearer context table) using the IP address of the UE 10 sent from the SGW 40 (step S209 in FIG. 8: Create Session Response). Thereafter, a general Attach Procedure is performed to establish a PDN connection and EPS bearer between the UE 10 and the PGW 50. Note that the order of steps in which the MME 20, SGW 40, and PGW 50 acquire / create TFTs is not limited to this, and the SGW 40, PGW 50 may create TFTs first, and then the MME 20 may acquire / create them.
  • TFT EPS bearer context table
  • UE10 may not be able to obtain an IP address during Attach Procedure. In such a case, it is not instructed to register all addresses to which the UE 10 is allocated in Step S201 (Attach request), but after the Attach Procedure is completed, the UE 10 can change the IPv4 HoA from the 3G access (E-UTRAN) 25.
  • the IPv6 HoA is assigned, the UE 10 performs, for example, “PGW initiated bearer modification without bearer QoS update procedure" (see Non-Patent Document 1) as shown in the first embodiment of the present invention. You may update to TFT like FIG. 5B from 5A.
  • the UE 10 maintains the TFT corresponding to the EPS bearer being used when the UE 10 supports only IPv6 in step S172 of FIG. 10 described later.
  • the TFT may be updated using parameters for determining / release (release) (for example, “DELETE”, “CHANGE”, “PRESERVE”). Since the description of these parameters is the same as that of the first embodiment of the present invention, the description thereof is omitted here.
  • FIG. 9 is a diagram illustrating an example of the configuration of the UE 10 according to the second embodiment of the present invention.
  • the UE 10 is connected to the access network (3G access 25, 35, N3G access 65) and performs communication processing in a lower layer, and performs packet communication processing such as IP on the upper layer of the wireless communication unit 161.
  • At least an address determination unit 164 is included.
  • the radio communication unit 161 is connected to the E-UTRAN (3G access 25) before the handover, as in the first embodiment of the present invention. It is assumed that the communication unit 161 is connected to UTRAN (3G access 35).
  • the processing flow of the UE 20 having the configuration shown in FIG. 9 will be described in detail with reference to FIG. 10, focusing on the processing related to the connection control unit that performs the characteristic processing in the present invention.
  • the UE has already been connected to the 3G access (E-UTRAN) 25 via the wireless communication unit, and can transmit and receive packets using IPv4 HoA and IPv6 HoA. Suppose that it is possible. Furthermore, it is assumed that handover is performed to the 3G access (UTRAN) 35 that can use only IPv4 in this state.
  • FIG. 10 is a flowchart showing an example of the processing flow of the UE 20 in the second embodiment of the present invention.
  • the UE 10 instructs the IP address determination unit 164 to confirm the IP version supported by the UE 10 itself in order to establish a PDN connection and an EPS bearer with the PGW 50 (Step S10). S171). Subsequently, the UE 10 determines whether the UE 10 itself supports IPv4 and IPv6 by the IP address determination unit 164 (step S172).
  • E-UTRAN In the case of supporting IPv4 and IPv6, even when the UE 10 is handed over from a 3G access (E-UTRAN) 25 to a network that can use only IPv4 (for example, 3G access (UTRAN) 35), E-UTRAN) Decided to obtain IPv4 HoA and IPv6 HoA (to be precise, IPv6 HoA is generated after obtaining IPv6 prefix) in connection control unit 162 so that the EPS bearer established in 25) can be maintained (Step S173).
  • E-UTRAN Decided to obtain IPv4 HoA and IPv6 HoA (to be precise, IPv6 HoA is generated after obtaining IPv6 prefix) in connection control unit 162 so that the EPS bearer established in 25) can be maintained (Step S173).
  • the UE 10 stores parameters indicating that IPv4 and IPv6 addresses are acquired from the connection control unit 163 via the packet processing unit 162 and the wireless communication unit 161 (for example, designated as PDN type IPv4 / IPv6).
  • a Request message is transmitted (step S174).
  • the UE 10 performs a general Attach procedure in the same manner as the Attach procedure in the conventional technique (step S175).
  • the UE 10 can perform IPv4 and Attach request (for example, step S201 in FIG. 8) regardless of whether it is required in the network to be attached.
  • the IPv4 HoA and the IPv6 HoA are associated with the EPS bearer registered in the TFT of each device (for example, the UE 10 or the PGW 50).
  • the UE 10 can maintain the EPS bearer necessary in the handover destination network even when the UE 10 is handed over from the 3G access (E-UTRAN) 25 to the 3G access (UTRAN) 35 that can use only IPv4 at the next handover. It is possible to continue receiving packets from the communication partner.
  • the present invention can be applied to all cases where the address type provided by the change in the network environment changes. For example, in the network to which the UE 10 is attached, even if the available address type is changed for some reason (for example, reasons such as security maintenance and load distribution), according to the present invention, the UE 10 The communication connection with the PDN 70 can be maintained.
  • each functional block used in the above description of the embodiment of the present invention is typically realized as an LSI (Large Scale Integration) which is an integrated circuit. These may be individually made into one chip, or may be made into one chip so as to include a part or all of them.
  • LSI Large Scale Integration
  • IC Integrated Circuit
  • system LSI super LSI
  • ultra LSI ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • the present invention has an effect that communication can be maintained even after the network state is changed (for example, network state change by handover) and the IP address type is changed in the network.
  • An effect that a mobile terminal using IP addresses of different IP versions at the same time can avoid unintentional release (release) of an EPS bearer when handed over to a network that can use only one IP version.
  • the present invention is applicable to a technology related to a mobile terminal that performs communication using one or more communication interfaces using IP addresses of a plurality of IP versions.
  • the IP addresses of a plurality of IP versions are assigned to one or more communication interfaces.
  • the present invention can be applied to a technique used when a mobile terminal that has established a plurality of communication paths using the network moves through a network and performs a handover.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

　移動端末が、ＩＰｖ４及びＩＰｖ６アドレスタイプのＩＰアドレスを用いて通信を行う環境において、ネットワーク環境の変化によって提供されるアドレスタイプが変わった場合（例えば、ハンドオーバした際）であっても通信コネクションを維持できるようにする技術が開示され、その技術によれば異なるＩＰバージョンに対応する移動端末（ＵＥ１０）が１つのＩＰバージョンのみ利用可能なネットワーク（ＵＴＲＡＮ）にハンドオーバした場合でも通信コネクションが維持されるよう、移動端末が保持する異なるＩＰバージョンのＩＰアドレスに関連付けられたパケットフィルタ（パケット転送情報）を作成する。また、移動端末が保持するＩＰアドレス、アプリケーションや通信相手の対応ＩＰバージョンなどを参照して、必要なパケットフィルタを限定することも可能である。さらに、ハンドオーバ後のパケットフィルタの取り扱いを明示する情報を追加することも可能である。

Description

移動端末及びパケットフィルタ設定方法
　本発明は、無線通信媒体を通じてＩＰ（Internet Protocol：インターネットプロトコル）を用いた通信を行う通信ノード（移動端末）が行うための無線通信技術に係る移動端末及びパケットフィルタ設定方法に関する。
　ＩＰネットワークにおける移動端末（User Equipment、以降、ＵＥと呼ぶ）の移動透過性を確保する技術として、ＧＴＰ（GPRS (General Packet Radio Service) Tunneling Protocol）やＰＭＩＰ（Proxy Mobile IP）、ＤＳＭＩＰ（Dual Stack Mobile IP）が一般的に知られている（下記の非特許文献１、２を参照）。このＧＴＰやＰＭＩＰ、ＤＳＭＩＰは、次世代ＵＥに用いられる技術を標準化する団体である３ＧＰＰ（3rd Generation Partnership Project）の規格技術として制定されている。３ＧＰＰは、ＵＥが３ＧＰＰアクセスネットワーク（以降、３Ｇアクセスと呼ぶ）上で移動透過性を確保する技術として、ＧＴＰとＰＭＩＰを制定しており、Ｎｏｎ－３ＧＰＰ（非３ＧＰＰ）アクセスネットワーク（以降、Ｎ３Ｇアクセスと呼ぶ）上で移動透過性を確保する技術として、ＰＭＩＰとＤＳＭＩＰを制定している。ＵＥが３Ｇアクセス、又は、Ｎ３Ｇアクセスで移動透過性技術（例えば、ＧＴＰ、ＰＭＩＰ、ＤＳＭＩＰ）を使用して通信を行う場合の通信ネットワークの一例を図１に図示する。
　図１には、ＵＥ１０、３Ｇアクセス（例えば、Ｅ－ＵＴＲＡＮ）２５上でＵＥ１０の移動管理を担当するＭＭＥ（Mobility Management Entity）２０、３Ｇアクセス（例えば、ＵＴＲＡＮ）３５上でＵＥ１０の移動管理を担当するＳＧＳＮ（Serving GPRS Support Node）３０、ＵＥ１０にデータを電波で送信する基地局（以降、ｅＮＢ（eNode B）と呼ぶ：不図示）、基地局間のユーザデータ経路制御を行うＳＧＷ（Serving Gateway：ＰＭＩＰにおけるＭＡＧ（Mobility Anchor Gateway：モビリティアンカポイント）などとも呼ばれる）４０、ＵＥ１０へのアドレス付与やＳＧＷ４０間のユーザデータ経路制御を行うＰＧＷ（Packet Gateway：ＤＳＭＩＰにおけるＨＡ（Home Agent：ホームエージェント）やＰＭＩＰにおけるＬＭＡ（Local Mobility Anchor：ローカルモビリティアンカ）などとも呼ばれる）５０、Ｎ３Ｇアクセス６５においてＰＤＮ（Packet Data Network：パケットデータネットワーク）コネクションを確立する機能を持ち、ＵＥ１０とパケットの送受信をする際にＵＥ１０との間のパケット保護などを担当するｅＰＤＧ（evolved Packet Data Gateway）６０で構成されるネットワーク構成の一例が図示されている。
　図１において、ＵＥ１０が３Ｇアクセスを通り、外部のネットワーク（例えば、図１に図示されているＰＤＮ（Packet Data Network）７０）と通信を行う際、ＵＥ１０はＰＧＷ５０との間でＰＤＮコネクション及びＥＰＳベアラ（EPS Bearer、ベアラなどと呼ばれる）を確立しなければならない。ＵＥ１０は、このＰＤＮコネクションの確立を通じてＩＰアドレスを取得し、ＰＤＮ７０と通信するためのＥＰＳベアラを確立する。なお、ＵＥ１０が取得するＩＰアドレスは、ＩＰｖ４アドレス（ＩＰｖ４ホームアドレス、ＩＰｖ４　ＨｏＡなどとも呼ばれる）、又は、ＩＰｖ６プレフィックス（ＩＰｖ６ホームプレフィックス（Home Prefix）などとも呼ばれる）であり、若しくは、これら両方であってもよい。例えば、ＰＧＷ５０からＩＰｖ６プレフィックスを割り当てられた場合には、ＵＥ１０は割り当てられたＩＰｖ６プレフィックスからＩＥＴＦ（Internet Engineering Task Force）で規定される手順、すなわちＩＰアドレス自動生成手順などを用いてＩＰｖ６アドレス（ＩＰｖ６ホームアドレスや、ＩＰｖ６　ＨｏＡなどと呼ばれる）を生成する。
　また、ＵＥ１０が既に確立した既存のＥＰＳベアラを使用せずにＰＤＮ７０と通信を行う際は、既存のＰＤＮコネクション内に追加のＥＰＳベアラを確立することができる。また、ＵＥ１０は既存のＰＤＮコネクションとは別に、ＰＧＷ５０と追加のＰＤＮコネクションを確立してもよい。このようにＵＥ１０は、３Ｇアクセス２５、３５を経由して、ＰＧＷ５０とＰＤＮコネクション及びＥＰＳベアラを確立することによって、ＰＤＮ７０と通信することが可能である（下記の非特許文献１を参照）。
　ＰＤＮコネクションの確立過程において、ＰＭＩＰが適用される場合は、ＳＧＷ４０がＰＢＵ（Proxy Binding Update：プロキシバインディングアップデート）メッセージを用いて、ＵＥ１０が在圏する局所情報（例えばＳＧＷ４０のアドレスなど）をＰＧＷ５０に通知することで、ＰＧＷ５０は通知されたＵＥ１０の在圏情報（以降、位置情報とも呼ぶ）と先に割り当てたＩＰｖ４ホームアドレス、又はＩＰｖ６ホームプレフィクスなどを関連付けたＢＣＥ（Binding Cache Entry：バインディングキャッシュエントリ）を作成し、ＢＣ（Binding Cache：バインディングキャッシュ）に保持する。ＰＧＷ５０は、ＢＣＥを参照して、受信したＵＥ１０あてパケットのあて先アドレス（すなわちＩＰｖ４ホームアドレスあるいはＩＰｖ６ホームアドレス）とＢＣＥに登録されているＩＰアドレスを照らし合わせる。その結果、一致するＢＣＥが存在する場合には、ＰＧＷ５０はＢＣＥに登録されているＩＰアドレスに対応するＵＥ１０の位置情報を取り出し、ＳＧＷ４０経由でＵＥ１０へパケットを転送する。つまり、ＵＥ１０の接続（アタッチ）するネットワークが変わっても、ＳＧＷ４０がＵＥ１０の現在位置に関するネットワーク情報などをＰＧＷ５０に通知し、ＰＧＷ５０がＢＣＥを登録（更新）することで、ＵＥ１０はネットワークをハンドオーバしてもＵＥ１０のＨｏＡあてのメッセージを正しく受信することが可能となる。なお、ＳＧＷ４０は、一般的にネットワークを管理するオペレータ方針に基づいて定期的に、又は、ＵＥ１０の移動に伴ったハンドオーバ時に、ＰＢＵメッセージを送信する。
　また、ＵＥ１０は異なるＩＰバージョン（すなわち、異なるアドレスタイプ）のＨｏＡを同時に持つことが可能（例えば、ＩＰｖ６　ＨｏＡとＩＰｖ４　ＨｏＡ）であり、ＵＥ１０は各ＨｏＡを用いてパケットの送受信を行うことができる。この各ＨｏＡを用いたパケットの送受信は、ＵＥ１０とＰＧＷ５０との間で確立した１つのＥＰＳベアラ、若しくはサービス単位などで分けられた複数のＥＰＳベアラを用いて行われる。
　上述したようにＰＤＮ７０からＵＥ１０あてに送られてきたパケットは、ＵＥ１０とＰＧＷ５０との間に確立したＥＰＳベアラを用いて転送される。このとき、ＰＧＷ５０はどのＥＰＳベアラを用いてＵＥ１０にパケットを転送するか決定／判断するために、ＰＧＷ５０が管理しているパケット転送情報（ＴＦＴ：Traffic Flow Template）を用いる。このＴＦＴは、例えば、ＳＧＷ４０から送られてくるＰＢＵメッセージや、非特許文献１で定義されている“PDN GW initiated bearer modification without bearer QoS update procedure”で交換されるメッセージに格納されている情報を用いて生成／更新される。このＴＦＴには、ＵＥ１０のＩＰアドレス、ポート番号などの情報が格納されている（下記の非特許文献３～５を参照）。また、ＴＦＴは、ＵＥ１０がパケットを送信する際に用いるＵＬ　ＴＦＴ（Uplink TFT）と、ＰＧＷ５０がＵＥ１０にパケットを転送する際に用いるＤＬ　ＴＦＴ（Downlink TFT）に分類されている。各ＴＦＴは、ＵＥ１０がネットワークをハンドオーバしてＩＰアドレスが更新されたときや、通信環境を変更したい／変更したとき（通信に用いるＥＰＳベアラを変更したいとき）などに更新される。なお、ＵＥ１０がハンドオーバした際にネットワーク側の装置（例えば、ＰＧＷ５０）によってＴＦＴを維持できる場合には、ＴＦＴは一から作成される必要はない。
　また、ＵＥ１０がネットワークをハンドオーバするとき、ＴＦＴが更新されると同時にハンドオーバ前にＵＥ１０が確立していたＥＰＳベアラのリソースが、ハンドオーバ前にＵＥ１０が確立したＥＰＳベアラ情報などに基づいて、ハンドオーバ先のネットワーク（例えば、ＵＴＲＡＮであればＳＧＷ４０、ＳＧＳＮ３０、ＲＮＣ（Radio Network Controller）など）においても確保される。これにより、ＵＥ１０はネットワークのハンドオーバ後も、ＰＤＮ７０との通信を維持することができ、パケットを受信することが可能になる。
　このように、ＵＥ１０がネットワークをハンドオーバしてもＰＤＮ７０との通信を維持し、パケットを受信し続ける方法として、非特許文献１には、“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”などが開示されている。非特許文献１に開示されている“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”は、Ｅ－ＵＴＲＡＮと呼ばれる３Ｇアクセス２５からＵＴＲＡＮと呼ばれる３Ｇアクセス３５にハンドオーバする際に用いられる従来の技術である。この“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”は、“Preparation phase”と“Execution phase”の２つのフェーズに分けられており、２つのフェーズを正しく完了することで、ＵＥ１０はＥ－ＵＴＲＡＮからＵＴＲＡＮにハンドオーバすることができる。以下、“Preparation phase”と“Execution phase”について説明する。
　最初に“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”の“Preparation phase”の詳細な動作について、図２を参照しながら説明する。図２は、従来の技術である“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”の“Preparation phase”を説明するためのシーケンス図である。なお、図２には、図１に図示されているシステム構成におけるハンドオーバ処理のシーケンスの一例が示されており、図１に図示されている構成要素に対応する装置にのみ参照符号を付している。また、ＵＥが現在接続しているネットワークで使用している装置で、かつ、“E-UTRAN to UTRAN lu mode Inter RAT handover”を実施することで変更する装置には、装置名の前にソース（Source）という文言を付しており（例えば、ソースＭＭＥ）、ＵＥがハンドオーバ後のネットワークで使用する予定の装置には、装置名の前にターゲット（Target）という文言を付している（例えば、ターゲットＳＧＳＮ）。
　まず前提として、ＵＥ１０は、３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５内でＰＤＮ７０と通信するためのＰＤＮコネクションを確立しており、ＥＰＳベアラを複数確立しているとする。ここで、ｅＮＢ（図１には不図示）が、ＵＥ１０の通信状況やＵＥ１０をサポートしているｅＮＢの負荷状態などに応じて、ＵＥ１０を３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５から３Ｇアクセス（ＵＴＲＡＮ）３５へハンドオーバさせることを決める（図２のステップＳ１００１：Handover Initiation）。
　ｅＮＢは、ＵＥ１０のハンドオーバ先ネットワークで使用される装置（例えば、ターゲットＲＮＣ、ターゲットＳＧＳＮ３０、ターゲットＳＧＷ４０）で、ハンドオーバ前にＵＥ１０が確立したＥＰＳベアラ分のリソースを確保するためにソースＭＭＥ２０にHandover Requiredメッセージを送信する（図２のステップＳ１００３：Handover Required）。
　ソースＭＭＥ２０は、ステップＳ１００３で受信したHandover Requiredメッセージに格納されているパラメータ（例えば、Target RNC Identifier）から３Ｇアクセス（ＵＴＲＡＮ）３５へのハンドオーバを決定する。続いて、ソースＭＭＥ２０は、ＵＥ１０がハンドオーバ前に確立したＥＰＳベアラのリソース確保を行うためにForward Relocation RequestメッセージをターゲットＳＧＳＮ３０に送信することでHandover Required resource allocation procedureを開始する。
　Forward Relocation Requestメッセージを受信したターゲットＳＧＳＮ３０は、Forward Relocation Requestメッセージに格納されているEPS Bearer ContextsをターゲットＳＧＳＮ３０が管理するPDP（Packet Data Protocol） Contextsに上書きする（図２のステップＳ１００５：Forward Relocation Request）。
　ターゲットＳＧＳＮ３０は、ＳＧＷ４０の再割り当てが必要であるか決定する。もし、ＳＧＷ４０の再割り当てを行う場合は、ターゲットＳＧＳＮ３０はターゲットＳＧＷ４０を選択し、Create Session RequestメッセージをＳＧＷ４０に送信する。なお、図１に図示されている構成例では、ソースＳＧＷ４０とターゲットＳＧＷ４０は同一である。続いてターゲットＳＧＳＮ３０は、ステップＳ１００５で受信したForward Relocation Requestメッセージに格納されたパラメータで示されたEPS Bearer Contextsを確立する。このとき、ターゲットＳＧＳＮ３０はネットワークのオペレータポリシなどによって確立できなかったEPS Bearer Contextsに関しては、対応するＥＰＳベアラの使用を終了する。このEPS Bearer Contextsは、ターゲットＳＧＳＮ３０とＵＥ１０で管理され、後にターゲットＳＧＳＮ３０が実施するSession Management Procedureによって確立されなかったＲＡＢ（Radio Network Resources：無線ネットワークリソース）に対応するEPS Bearer Contextsの使用を終了させる（図２のステップＳ１００７：Create Session Request）。
　Create Session Requestメッセージを受信したターゲットＳＧＷ４０は、ＵＥ１０のためのリソースを割り当てて、Create Session RequestメッセージをターゲットＳＧＳＮ３０に送信する（図２のステップＳ１００９：Create Session Response）。なお、ＳＧＷ４０の再割り当てが行われない場合は、図２ステップＳ１００７、１００９を省略することができる。
　続いて、ターゲットＳＧＳＮ３０は、ＲＡＢを確立するためにRelocation RequestメッセージをターゲットＲＮＣに送信する。また、ターゲットＳＧＳＮ３０は、各ＲＡＢのためにRAB to be setup listを作成して、Relocation Requestメッセージに格納する。受け入れられたＲＡＢは、ターゲットＲＮＣにおけるＵＥ１０のためのリソースが確保される（図２のステップＳ１０１１：Relocation Request）。
　Relocation Requestメッセージを受信したターゲットＲＮＣは、ＵＥ１０のためにリソースを割り当て、ＵＥ１０のリソースのために適用するパラメータをRelocation Request Acknowledgementメッセージに格納してターゲットＳＧＳＮ３０に送信する。このとき、ターゲットＲＮＣは、受け入れたＲＡＢのためにＳＧＷ４０、若しくはターゲットＳＧＳＮ３０（Direct tunnelが使用されない場合）から送られてくるDownlink GTP PDUsを受信するための準備をする（図２のステップＳ１０１３：Relocation Request Acknowledge）。
　“Indirect Forwarding”でＳＧＷ４０の再割り当てが適用される場合、若しくは、“Indirect Forwarding”で直接のトンネル（Direct Tunnel）が使用されない場合には、ターゲットＳＧＳＮ３０は、Create Indirect Data Forwarding Tunnel RequestメッセージをターゲットＳＧＷ４０に送信する（図２のステップＳ１０１５：Create Indirect Data Forwarding Tunnel Requests）。なおＳＧＷ４０の再割り当てが実施されない場合は、このCreate Indirect Data Forwarding Tunnel Requestメッセージが、共通のＳＧＷ４０に送信される。Create Indirect Data Forwarding Tunnel Requestメッセージを受信したターゲットＳＧＷ４０は、ターゲットＳＧＷ４０のＩＰアドレスなどを格納したCreate Indirect Data Forwarding Tunnel ResponseメッセージをターゲットＳＧＳＮ３０へ送信する（図２のＳ１０１７：Create Indirect Data Forwarding Tunnel Response）。
　続いて、ターゲットＳＧＳＮ３０は、新しいＳＧＷ４０が選択されたことを示すパラメータなどを格納したForward Relocation ResponseメッセージをソースＭＭＥ２０に送信する（図２のステップＳ１０１９：Forward Relocation Response）。
　“Indirect Forwarding”が適用される場合、ソースＭＭＥ２０はそのＳＧＷ４０にCreate Indirect Data Forwarding Tunnel Requestメッセージを送信する（図２のステップＳ１０２１：Create Indirect Data Forwarding Tunnel Request）。なお、この“Indirect Forwarding”は、ＵＥ１０のためのアンカポイント（ＰＧＷ５０と直接通信するノード）として使用されるＳＧＷ４０とは異なるＳＧＷ４０によって実施されてもよい。
　Create Indirect Data Forwarding Tunnel Requestメッセージを受信したＳＧＷ４０は、ＳＧＷ４０のＩＰアドレスなどを格納したCreate Indirect Data Forwarding Tunnel ResponseメッセージをソースＭＭＥ２０に送信する。なお、ＳＧＷ４０が“Indirect Forwarding”をサポートしていなかった場合は、ＳＧＷ４０のアドレスなどを格納せずにCreate Indirect Data Forwarding Tunnel ResponseメッセージをソースＭＭＥ２０に送信する（図２のステップＳ１０２３：Create Indirect Data Forwarding Tunnel Response）。
　次に、“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”の“Execution phase”の詳細な動作について、図３を参照しながら説明する。図３は、従来の技術である“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”の“Execution phase”を説明するためのシーケンス図である。
　“Execution phase”の最初に、ソースＭＭＥ２０はHandover CommandメッセージをソースｅＮｏｄｅＢに送信することによって“Preparation phase”を完了させる。また、ソースＭＭＥ２０は、このHandover Commandメッセージに“Preparation phase”のステップＳ１０１９、若しくはステップＳ１０２３で受信した、ＵＥ１０へデータ転送する際に必要となるパラメータを格納する（図３のステップＳ１５０１：Handover Command）。
　Handover Commandメッセージを受信したソースｅＮＢは、ハンドオーバ先のネットワーク（ターゲットアクセスネットワーク：Target Access Networkとも呼ばれる）にＵＥ１０をハンドオーバさせるためにHandover from E-UTRAN CommandメッセージをＵＥ１０に送信する。また、ソースｅＮＢは、このHandover from E-UTRAN Commandメッセージに、Preparation phaseでターゲットＲＮＣをセットアップしたことを示すパラメータを格納する。また、Handover from E-UTRAN Commandメッセージを受信したＵＥ１０は、ＵＥ１０が持つＥＰＳベアラの識別子（Identities）と、Handover from E-UTRAN Commandメッセージに格納されている各ＲＡＢｓの情報とを関連付ける（図３のステップＳ１５０３：Handover from E-UTRAN Command）。
　このステップ以降、ＵＥ１０は一般的な“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”を実施して、３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５から３Ｇアクセス（ＵＴＲＡＮ）３５にハンドオーバする。なお、ステップＳ１５０３以降は、本発明と直接的に関係がないため説明を省略する。
　これら２つに分けられた“Preparation phase”と“Execution phase”を正確に実施することによって、“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”が完了し、ＵＥ１０は、３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５から３Ｇアクセス（ＵＴＲＡＮ）３５にハンドオーバすることが可能となる。
3GPP TS 23.401 V9.1.0，June 2009 3GPP TS 23.402 V9.1.0，June 2009 3GPP TS 29.061 V9.0.0，September 2009 3GPP TS 24.008 V8.6.0，June 2009 3GPP TS 24.229 V9.1.0，September 2009
　しかしながら、ＴＦＴには、現在接続されているネットワークの条件を考慮したＥＰＳベアラに基づいて登録されており、同一ネットワーク内におけるネットワーク条件の変化や、ハンドオーバ前後で異なるネットワーク条件の差異によるネットワーク条件の変化などによっては、ＥＰＳベアラが確立されていないため（すなわち、ＴＦＴに情報が登録されていないため）、新たにＥＰＳベアラを再確立するための処理などによって通信に遅延が生じる可能性がある。
　例えば、上述した従来の技術において、ＩＰｖ４とＩＰｖ６に対応しているＵＥがハンドオーバ前のネットワーク（例えば、Ｅ－ＵＴＲＡＮ）でＥＰＳベアラを確立しており、かつ、ＴＦＴに登録されている情報で、ＵＥの確立したＥＰＳベアラと対応しているアドレスがＩＰｖ６アドレスのみであり、かつ、ＵＥが、ＩＰｖ４のみサポートしているネットワーク（例えば、ＵＴＲＡＮ）にハンドオーバした場合、ハンドオーバ処理（例えば、図２のステップＳ１００７：Create Session Request）のEPS Bearer Contextsの使用終了によって、ハンドオーバ前に確立していたＥＰＳベアラを使用できなくなり、新たにＥＰＳベアラを再確立するなどの処理が完了するまで、通信相手からパケットを受信できなくなってしまうという問題がある。
　また、ＵＥ１０とＵＥ１０の通信相手が共にＩＰｖ４にも対応している場合、ハンドオーバ処理終了後、再度ＥＰＳベアラを確立して、ＩＰｖ４アドレスと対応するようにＴＦＴに登録することで、ＵＥは再度通信相手と通信可能になるが、ハンドオーバ処理の完了を待たなければならないといった問題が生じる。
　上記の問題を解決するため、本発明は、無線通信媒体を通じてＩＰを用いた通信を行うことが可能な移動端末が、例えば、ＩＰｖ４アドレスタイプとＩＰｖ６アドレスタイプなどの複数のアドレスタイプ（あるいは、アドレスバージョン）を用いて通信を行う環境において、ネットワーク環境の変化によって提供されるアドレスタイプが変わった場合（例えば、単一のアドレスタイプしか提供されないネットワークにハンドオーバしたとき）であっても、ネットワーク環境の変化前（例えば、ハンドオーバ前）の通信コネクションを維持できるようにすることを目的とする。
　また、特に、本発明は、ネットワーク環境の変化として移動端末によるハンドオーバを考慮し、ＩＰｖ４とＩＰｖ６に対応している移動端末の確立したＥＰＳベアラが、ＴＦＴ上でＩＰｖ６アドレスしか関連付けられていない状態から、移動端末がＩＰｖ４のみしかサポートしていないネットワークにハンドオーバした場合であっても、移動端末とその通信相手との通信を途切れさせることなく、ハンドオーバを可能とすることを目的とする。
　上記目的を達成するため、本発明の移動端末は、複数の異なるアドレスタイプのＩＰアドレスを用いて通信を行うことが可能な移動端末であって、
　所定の通信相手と通信を行うためにネットワークに接続するネットワーク接続部と、
　前記ネットワーク接続部が接続している前記ネットワークで利用可能なアドレスタイプによらず、前記所定の通信相手との間におけるパケットフローに対して、複数の異なるアドレスタイプに対応するパケットフィルタを設定するパケットフィルタ設定手段とを、
　有する。
　この構成により、無線通信媒体を通じてＩＰを用いた通信を行うことが可能な移動端末が、例えば、ＩＰｖ４アドレスタイプとＩＰｖ６アドレスタイプなどの複数のアドレスタイプ（あるいは、アドレスバージョン）を用いて通信を行う環境において、ネットワーク環境の変化によって提供されるアドレスタイプが変わった場合（例えば、単一のアドレスタイプしか提供されないネットワークにハンドオーバしたとき）であっても、ネットワーク環境の変化前（例えば、ハンドオーバ前）の通信コネクションを維持できるようになる。
　また、上記目的を達成するため、本発明のパケットフィルタ設定方法は、複数の異なるアドレスタイプのＩＰアドレスを用いて通信を行うことが可能な移動端末におけるパケットフィルタ設定方法であって、
　前記移動端末が所定の通信相手と通信を行うために接続しているネットワークで利用可能なアドレスタイプによらず、前記所定の通信相手との間におけるパケットフローに対して、複数の異なるアドレスタイプに対応するパケットフィルタを設定するパケットフィルタ設定ステップを、
　有する。
　これにより、無線通信媒体を通じてＩＰを用いた通信を行うことが可能な移動端末が、例えば、ＩＰｖ４アドレスタイプとＩＰｖ６アドレスタイプなどの複数のアドレスタイプ（あるいは、アドレスバージョン）を用いて通信を行う環境において、ネットワーク環境の変化によって提供されるアドレスタイプが変わった場合（例えば、単一のアドレスタイプしか提供されないネットワークにハンドオーバしたとき）であっても、ネットワーク環境の変化前（例えば、ハンドオーバ前）の通信コネクションを維持できるようになる。
　本発明によれば、ＵＥが異なるＩＰバージョンのＩＰアドレスを複数用いて、外部のネットワークと通信している状態で、ネットワークで利用可能なＩＰアドレスタイプが変わった場合（例えば、１つのＩＰアドレスのみ利用可能なネットワークにハンドオーバした場合）であっても、ネットワークにおけるＩＰアドレスタイプが変更されてしまう前に（例えば、ハンドオーバ前に）、ＵＥが、ＵＥの保持する複数のＩＰバージョン（例えば、ＩＰｖ４及びＩＰｖ６の両バージョン）のＩＰアドレスを関連付けるようにパケット転送情報（ＴＦＴ）を更新することで、ネットワークにおいてＩＰアドレスタイプが変更された後（例えば、ハンドオーバ後）であっても通信を維持することができる。
　特に本発明によれば、ＵＥがハンドオーバ前にＴＦＴの更新処理を行うことによって、従来のハンドオーバ後に通信経路を確立し直していたハンドオーバ処理と比べ、通信経路の再確立を待つ時間が削減でき、さらにパケットを受信できなくなる課題も解決できる。
　また、本発明によれば、ＴＦＴを解放（リリース）したい場合、ＴＦＴの転送アドレスバージョンを変更したい場合、ＴＦＴを維持したい場合に、ＴＦＴに明示的に動作を登録することで、各装置（例えば、ＵＥやＰＧＷ）は確実にＴＦＴに対して所定の動作を行うことができ、無駄なメモリ消費時間を削減することができる。
本発明の第１及び第２の実施の形態並びに従来の技術に共通する通信システムの構成の一例を示す図 従来のInter RAT handover (Preparation phase) 技術における動作の一例を説明するためのシーケンスチャート 従来のInter RAT handover (Execution phase) 技術における動作の一例を説明するためのシーケンスチャート 本発明の第１の実施の形態におけるＥＰＳベアラの維持／解放処理を含むハンドオーバ方法における動作の一例を説明するためのシーケンスチャート 本発明の第１及び第２の実施の形態におけるＴＦＴ（処理前）の一例を示す図 本発明の第１及び第２の実施の形態におけるＴＦＴ（処理後）の一例を示す図 本発明の第１及び第２の実施の形態におけるＴＦＴ（処理後）の別の一例を示す図 本発明の第１の実施の形態における移動端末（ＵＥ）の構成の一例を示す図 本発明の第１の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第２の実施の形態におけるＥＰＳベアラの維持／解放処理を含むハンドオーバ方法における動作の一例を説明するためのシーケンスチャート 本発明の第２の実施の形態における移動端末（ＵＥ）の構成の一例を示す図 本発明の第２の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート
　以下、図面を参照しながら、本発明の第１及び第２の実施の形態について説明する。
　まず、図１を参照しながら、本発明の第１及び第２の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１及び第２の実施の形態に共通するシステム構成の一例を示す図である。
　上述のように、図１に図示されている通信システムは、少なくとも、ＵＥ１０、３Ｇアクセス（例えば、Ｅ－ＵＴＲＡＮ）２５上でＵＥ１０の移動管理を担当するＭＭＥ２０、３Ｇアクセス（例えば、ＵＴＲＡＮ）３５上でＵＥ１０の移動管理を担当するＳＧＳＮ３０、ＵＥ１０にデータを電波で送信するｅＮＢ（図１には不図示）、基地局間のユーザデータ経路制御を行うＳＧＷ４０、ＵＥ１０へのアドレス付与やＳＧＷ４０間のユーザデータ経路制御を行うＰＧＷ５０、Ｎ３ＧアクセスにおいてＰＤＮコネクションを確立する機能を持ち、ＵＥとパケットの送受信をする際、ＵＥとの間のパケット保護などを担当するｅＰＤＧ６０を有している。
　ここで、ＵＥ１０は、少なくとも１つ以上の通信インタフェースを持ち、ＩＰｖ４とＩＰｖ６に対応しており、各ＩＰのタイプを使い分けて、３Ｇアクセス２５、３５、又はＮ３Ｇアクセス６５、あるいは、両アクセスを介してＰＧＷ５０に接続することができるとする。また、ＵＥ１０は３ＧＰＰが制定しているようにＥ－ＵＴＲＡＮのようなＵＴＲＡＮを発展させた３Ｇアクセス２５と、ＵＴＲＡＮやＧＥＲＡＮ（GSM EDGE Radio Access Network）のような３Ｇアクセス３５との間のハンドオーバを行うことができるとする。また、ＵＥ１０は、３Ｇアクセス２５、３５とＮ３Ｇアクセス６５との間のハンドオーバも実施可能である。
　上記の構成を有する通信システムにおいて、ＵＥ１０は、ＧＴＰ若しくはＰＭＩＰを用いて３Ｇアクセスを介してＰＧＷ５０と接続済みであり、ＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを用いてパケットの送受信を行っているものとし、各ＨｏＡと関連付けられているＥＰＳベアラを確立しているものとする。このとき、ＰＧＷ５０が持つＴＦＴの一例は、例えば図５Ａに図示されている状態となる。
　図５Ａは、本発明の第１及び第２の実施の形態におけるＴＦＴ（処理前）の一例を示す図である。なお、図５Ａには、ＵＥ１０がＥ－ＵＴＲＡＮでＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを用いてＥＰＳベアラを確立したとき、ＰＧＷ５０が保持するＴＦＴの一例が図示されている。
　図５Ａに示されているＴＦＴは、ＵＥ１０が保持するＨｏＡと、各ＥＰＳベアラを識別するためのベアラＩＤ（Bearer ID）などが登録されている。このＨｏＡとベアラＩＤとのセットの１段は、パケットフィルタ（Packet Filter）と呼ばれることもある。なお、ＵＥ１０が保持するＨｏＡとＥＰＳベアラの関係性が分かるのであれば、ベアラＩＤ以外のパラメータが用いられてもよい。例えば、非特許文献３に記載されているような“Single destination port type”、“Destination port range type”、“Single source port type”、“Source port range type”などが用いられてもよい。
　例えば、図５ＡのＴＦＴを持つＰＧＷ５０が、ＵＥ１０の通信相手からＵＥ１０の管理するアドレスの１つであるＩＰｖ４　ＨｏＡあてに送られたパケットを受信した場合、ＰＧＷ５０はＴＦＴを参照して、ＩＰｖ４　ＨｏＡに関連付けられているベアラＩＤ１（若しくは、不図示の“Single destination port type”など）を用いて、受信したパケットをＵＥ１０へ転送する。なお、ＰＧＷ５０が、ＵＥ１０の通信相手からＵＥ１０の管理するアドレスの１つであるＩＰｖ６　ＨｏＡあてのパケットを受信した場合は、アドレス以外のパラメータ（例えば、ＵＥ１０の通信相手のＩＰアドレスやポートタイプ（不図示））を用いて、どのＥＰＳベアラを用いて転送するか（すなわち、ベアラＩＤ１又はベアラＤ２のどちらか）を判断してもよい。
　＜第１の実施の形態＞
　以下、本発明の第１の実施の形態におけるシステム動作の一例について、図４を用いて詳しく説明する。図４は、本発明の第１の実施の形態におけるシステム動作の一例（３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５から３Ｇアクセス（ＵＴＲＡＮ）３５へのハンドオーバケース）を説明するためのシーケンス図である。なお、図４には、図１に図示されているシステム構成におけるハンドオーバ処理のシーケンスの一例が示されており、図１に図示されている構成要素に対応する装置にのみ参照符号を付している。また、ＵＥが現在接続しているネットワークで使用している装置で、かつ、“E-UTRAN to UTRAN lu mode Inter RAT handover”を実施することで変更する装置には、装置名の前にソース（Source）という文言を付しており（例えば、ソースＭＭＥ）、ＵＥがハンドオーバ後のネットワークで使用する予定の装置には、装置名の前にターゲット（Target）という文言を付している（例えば、ターゲットＳＧＳＮ）。
　図４には、少なくともＵＥ１０、ＵＥ１０が既にアタッチ済みのＥ－ＵＴＲＡＮで使用しているソースｅＮＢ、ソースＭＭＥ２０、ＳＧＷ４０、ＰＧＷ５０、ＨＳＳ、ハンドオーバ先のＵＴＲＡＮで使用するターゲットＲＮＣ、ターゲットＳＧＳＮ３０、ターゲットＳＧＷ４０による処理シーケンスの一例が図示されている。
　図４では、ＵＥ１０は、既にＥ－ＵＴＲＡＮの３Ｇアクセス２５にアタッチ済みであり、ＵＥ１０とＰＧＷ５０との間で確立したＰＤＮコネクション及びＥＰＳベアラを用いてＰＤＮ７０と通信している。このとき、各装置（例えば、ＵＥ１０とＰＧＷ５０）は図５ＡのＴＦＴを持ち、ＵＥ１０はＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを使用してＰＤＮ７０と通信しているとする。
　ＵＥ１０がＰＤＮ７０と通信している際、ＵＥ１０がＥ－ＵＴＲＡＮの３Ｇアクセス２５のカバーするパケット転送エリアから超えそうになる、又は、オペレータ方針に基づいて異なるネットワークをＵＥ１０に割り当てる場合などには、現在ＵＥ１０が接続されているｅＮＢが、ハンドオーバ先のアクセスネットワークに対してハンドオーバ処理を開始する（上記の非特許文献１を参照）。
　また、ＵＥ１０のハンドオーバ先であるＵＴＲＡＮ（３Ｇアクセス３５）は、ＵＴＲＡＮ（ハンドオーバ先ネットワーク）のオペレータ方針や、ＵＥ１０の通信相手の登録情報によるＩＰバージョン制限など（使用するＰＤＮ毎に制限される場合がある）により、ＩＰｖ４のみ利用可能なネットワークとする。
　また、図５ＡのＴＦＴを持つＵＥ１０が、ＩＰｖ４のみ利用可能なＵＴＲＡＮ（３Ｇアクセス３５）にハンドオーバした場合には、使用できないＩＰｖ６　ＨｏＡのみ登録しているベアラＩＤ２のＥＰＳベアラが使用不可能になるか、若しくは、ベアラリリース（解放）され、ＵＥ１０は通信相手からパケットを受信できなくなることが想定される。
　以下、図４に図示されている各シーケンスについて説明する。ＵＥ１０は、Ｅ－ＵＴＲＡＮ（３Ｇアクセス２５）にアタッチし、ＩＰｖ４　ＨｏＡ及びＩＰｖ６　ＨｏＡを取得する。続いて、ＵＥ１０は、各ＨｏＡを用いてＰＤＮ７０との通信を目的としたＰＤＮコネクション及びＥＰＳベアラを、ＰＧＷ５０との間で確立する。このとき、ＵＥ１０とＰＧＷ５０は図５ＡのＴＦＴを保持する（図４のステップＳ１０１：Uplink and Downlink User Plane PDUs）。
　続いて、ＵＥ１０は次のネットワークにハンドオーバする前に、ＵＥ１０自身が対応しているＩＰバージョンを確認する（例えば、保持しているＩＰアドレスの確認）。例えば、ＵＥ１０がＩＰｖ４とＩＰｖ６に対応しており、ＩＰｖ６　ＨｏＡのみしか保持していなかった場合、ＵＥ１０はＩＰｖ４　ＨｏＡを取得する（図４のステップＳ１０３：ＩＰアドレス確認）。
　ＵＥ１０自身がＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを保持している場合、ＵＥ１０はＵＥ１０自身が保持しているＴＦＴ（ＵＬ　ＴＦＴ）でＩＰｖ６　ＨｏＡのみが対応しているＥＰＳベアラ（例えば、図５Ａに示すベアラＩＤ２のようなＥＰＳベアラ）が存在するかどうかを確認する。ＴＦＴに登録されている全ＥＰＳベアラが、ＵＥ１０のＩＰｖ４　ＨｏＡ及びＩＰｖ６　ＨｏＡの両アドレスと関連付けられている場合は、ＩＰｖ４のみ利用可能なＵＴＲＡＮ（３Ｇアクセス３５）にハンドオーバした後でも全ＥＰＳベアラが維持されるので、本発明の第１の実施の形態における解決手法を終了する（図４のステップＳ１０５：ＴＦＴ確認）。
　ＵＥ１０自身が保持するＴＦＴでＩＰｖ６のみが対応しているＥＰＳベアラがある場合、ＵＥ１０は、そのＥＰＳベアラで使用しているアプリケーションがＩＰｖ６専用アプリケーションであるかどうか（あるいは、ＩＰｖ４にも対応しているアプリケーションであるかどうか）を更に確認する。ＩＰｖ６専用アプリケーションである場合は、ＩＰｖ４　ＨｏＡを用いたＥＰＳベアラ維持処理（例えば、アプリケーションにＩＰｖ４　ＨｏＡの追加や、ＩＰｖ４　ＨｏＡをＩＰｖ６　ＨｏＡの代替として使用）ができないため、本発明の第１の実施の形態における解決手法を終了する（図４のステップＳ１０７：アプリケーション確認）。
　ＩＰｖ４にも対応しているアプリケーションである場合には、ＵＥ１０は、通信相手の対応しているＩＰバージョンを更に確認する。この確認は、例えば、通信相手のＩＰｖ４アドレスがＤＮＳ（Domain Name Server:ドメインネームサーバ）に登録されているかどうかを確認したり、通信相手に直接問い合わせたりすることで実行可能である。ＵＥ１０の通信相手がＩＰｖ４に対応していないことが確認された場合は、ＩＰｖ４　ＨｏＡを用いたＥＰＳベアラ維持処理（例えば、アプリケーションにＩＰｖ４　ＨｏＡを追加したり、ＩＰｖ４　ＨｏＡをＩＰｖ６　ＨｏＡの代替として使用したりする処理）ができないため、本発明の第１の実施の形態における解決手法を終了する（図４のステップＳ１０９：通信相手の対応ＩＰバージョン確認）。
　ＵＥ１０は、ＵＥ１０自身と通信相手が共にＩＰｖ４に対応していることを確認できた場合には、各装置（例えば、ＵＥ１０とＰＧＷ５０）が持つＴＦＴを更新するために、例えば、３ＧＰＰのＳＡ２が定義している“PGW initiated bearer modification without bearer QoS update procedure”（非特許文献１を参照）を実施して、図５ＢのＴＦＴに更新する（図４のステップＳ１１１：ＴＦＴ更新）。
　上記のステップＳ１０３～ステップＳ１１１（ＩＰアドレス確認からＴＦＴ更新）を正しく実施することで、ＩＰｖ４のみ利用可能なＵＴＲＡＮ（３Ｇアクセス３５）にハンドオーバした後も、全ＥＰＳベアラを維持でき、通信相手からパケットを受信し続けることができるための準備が整う。なお、ステップＳ１０３～ステップＳ１１１の各ステップは、必ずしも実施しなくてはならないステップではなく、いずれか１つ又は複数のステップを省略することも可能である。例えば、ＵＥ１０が既に通信相手の対応ＩＰバージョンを知っている場合には、ステップＳ１０９における通信相手の対応ＩＰバージョン確認は実施される必要はない。また、各ステップの順番は、上述の順番に限ったものではなく、同じ成果が得られるのであれば、各ステップの順番を入れ替えてもよい。
　ステップＳ１１１におけるＴＦＴの更新後、ＵＥ１０は、ｅＮＢによって一般的な“E-UTRAN to UTRAN lu mode Inter RAT handover procedure”を実施される。図４のステップＳ１１３、Ｓ１１５の処理は、従来の技術を示す図２のステップＳ１００１、Ｓ１００３の処理と同じなので、ここでは説明を省略する。
　続いて、図４のステップＳ１１７（Forward Relocation Request）では、ソースＭＭＥ２０からターゲットＳＧＳＮ３０にForward Relocation Requestメッセージが送信される。図４のステップＳ１１７の処理や、Forward Relocation Requestメッセージに格納されるパラメータは、従来の技術を示す図２のステップＳ１００５と同じであるが、Forward Relocation Requestメッセージに格納されるパラメータの１つであるMM Contextの中身の１つであるＴＦＴが、図４のステップＳ１０３～Ｓ１１１の処理によって図５Ａから図５Ｂに更新されている。
　図５Ｂに図示されているＴＦＴは、図５Ａに図示されているＴＦＴと比較した場合、ＩＰｖ４　ＨｏＡとベアラＩＤ２との関係を示すパケットフィルタを更に有しているという特徴がある。例えばＵＥ１０が、ＩＰｖ４のみをサポートしている３Ｇアクセス（ＵＴＲＡＮ）３５へハンドオーバした場合、ＴＦＴのベアラＩＤ２に関する登録情報にはＵＥ１０の保持するＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡが登録されているため、ベアラＩＤ２に対応するＥＰＳベアラの使用不可能、若しくは、ベアラリリース（解放）を回避することができ、ＵＥ１０と通信相手の通信経路を維持することが可能となる。また、ＰＧＷ５０は、ベアラＩＤ２に対応するＩＰｖ６　ＨｏＡあてに送られたパケットを受信した場合であっても、このパケットフィルタに基づいてベアラＩＤ２に関連付けられているＩＰアドレス（ＩＰｖ４　ＨｏＡ）を用いて転送先を決定することで、受信したパケットをＵＥ１０へ転送することが可能となる。
　図５Ｂに図示されている更新されたＴＦＴは、ソースＭＭＥ２０からターゲットＳＧＳＮ３０に送られることによって、ＩＰｖ４のみ利用可能な３Ｇアクセス（ＵＴＲＡＮ）３５で使用されるターゲットＳＧＳＮ３０は、全ＥＰＳベアラがＩＰｖ４（及びＩＰｖ６）に対応していることを確認でき、全ＥＰＳベアラのためのリソースを確保する処理を実施する。以降は、一般的な“E-UTRAN to UTRAN lu mode Inter RAT handover”が実施される。
　なお、ＵＥ１０は、図４のステップＳ１０７（アプリケーション確認ステップ）やステップＳ１０９（通信相手の対応ＩＰバージョン確認ステップ）などで、ＩＰｖ６　ＨｏＡのみ関連付けられているＥＰＳベアラがＩＰｖ４にも対応できないことを確認できた場合、ＵＥ１０はＩＰｖ４のみ利用可能なネットワークにハンドオーバした後に、ＩＰｖ６　ＨｏＡのみ関連付けられている、又は、ＩＰｖ６のみ使用可能なアプリケーションで用いられているＥＰＳベアラの維持／解放（リリース）を決定するためのパラメータ（例えば“ＤＥＬＥＴＥ”、“ＣＨＡＮＧＥ”、“ＰＲＥＳＥＲＶＥ”）を用いて、図５ＣのようにＴＦＴを更新してもよい。なお、図５Ｃでは、このパラメータとして“ＤＥＬＥＴＥ”のみが例示されている。
　例えば、“ＤＥＬＥＴＥ”は、パケットフローを削除することを明示的に示す情報である。“ＤＥＬＥＴＥ”を用いてＴＦＴを更新する場合は、“ＤＥＬＥＴＥ”が格納されているパケットフローは確実に削除する。本発明の第１の実施の形態における上述の動作の場合には、ＩＰｖ６　ＨｏＡのみ関連付けられているＥＰＳベアラは、ハンドオーバ処理中にリリースされるが、明示的に“ＤＥＬＥＴＥ”と示すことで、確実に削除することができる。
　また、“ＣＨＡＮＧＥ”は、パケットのあて先アドレスを変換することを明示的に示す情報である。“ＣＨＡＮＧＥ”を用いてＴＦＴを更新する場合は、例えばＰＧＷ５０が、ＰＧＷ自身で保持するＴＦＴ（ＤＬ　ＴＦＴ）を確認し、ＩＰｖ６　ＨｏＡあてに送られてきたパケットをＩＰｖ４　ＨｏＡあてに変換してもよいこと、若しくは、ＰＧＷ５０がＩＰｖ４　ＨｏＡあてに転送してもよいことが判別できるようになる。
　また、“ＰＲＥＳＥＲＶＥ”は、パケットフローを確保しておくことを明示的に示す情報である。“ＰＲＥＳＥＲＶＥ”を用いてＴＦＴを更新する場合は、ＵＥ１０がＩＰｖ４のみ利用可能なネットワークにハンドオーバした際、従来であればＩＰｖ６　ＨｏＡのみ関連付けられているパケットフローは、ハンドオーバ処理中にリリースされるが、再度ＵＥ１０がＩＰｖ６　ＨｏＡの利用可能なネットワークで、かつ、そのＩＰｖ６　ＨｏＡを継続的に使用できるネットワークにハンドオーバするときに活用するために確保しておく。
　なお、これらＴＦＴの維持／解放（リリース）を決定するためのパラメータは、ここで説明した以外のパラメータでもよい。また、図５ＣではＩＰアドレスを格納する場所にこれらのパラメータが格納されているが、これらのパラメータが確認できるのであれば、ＩＰアドレスを格納する場所以外にこれらのパラメータが格納されてもよい。
　次に、本発明の第１の実施の形態における移動端末（ＵＥ１０）の構成について説明する。以下、図６を参照しながら、本発明の第１の実施の形態におけるＵＥ１０の構成について説明する。図６は、本発明の第１の実施の形態におけるＵＥ１０の構成の一例を示す図である。
　図６において、ＵＥ１０はアクセスネットワーク（３Ｇアクセス２５、３５、６５など）と接続して下位レイヤにおける通信処理を行う無線通信部１３１、無線通信部１３１の上位でＩＰなどのパケット通信処理を実施するパケット処理部１３２、ＵＥ１０とＰＧＷ５０との間の通信経路の確立（ＰＤＮコネクション及びＥＰＳベアラの確立）を実施する接続制御部１３３、ＵＥ１０とＰＧＷ５０との間の通信経路確立後に実施するＵＥ１０自身のＩＰアドレス判断部１３４、ＵＥ１０自身のＴＦＴを確認するＴＦＴ判断部１３５、ＥＰＳベアラで使用しているアプリケーションが対応しているＩＰバージョンを確認するアプリケーション判断部１３６、ＵＥ１０の通信相手の対応しているＩＰバージョンを確認する通信相手の対応ＩＰバージョン確認処理部１３７、ＴＦＴを更新するためのＴＦＴ更新処理部１３８を少なくとも有する。なお、本発明の第１の実施の形態においては、ハンドオーバ前に無線通信部１３１はＥ－ＵＴＲＡＮ（３Ｇアクセス２５）に接続しており、ハンドオーバ後に無線通信部１３１がＵＴＲＡＮ（３Ｇアクセス３５）に接続するものとして説明している。
　次に、図６に図示されている構成を有するＵＥの処理フローについて、本発明における特徴的な処理を実施する接続制御部に係る処理を中心に、図７を用いて詳しく説明する。なお、ＵＥ１０は、既に無線通信部１３１を介して３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５に接続済みであり、ＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを用いてパケットの送受信が可能な状態であるとする。さらに、その状態で、ＵＥ１０は、ＩＰｖ４のみ利用可能な３Ｇアクセス（ＵＴＲＡＮ）３５にハンドオーバを行うとする。
　図７は、本発明の第１の実施の形態におけるＵＥ１０の処理フローの一例を示すフロー図である。最初にＵＥ１０は、３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５でＰＤＮ７０と通信するために無線通信部１３１からパケット処理部１３２を介して、接続制御部１３３でＩＰアドレス（例えばＩＰｖ４　ＨｏＡ、ＩＰｖ６　ＨｏＡ）を取得して、ＰＤＮコネクション及びＥＰＳベアラをＰＧＷ５０との間で確立する（図７のステップＳ１４１）。
　続いて、ＵＥ１０は、受信したパケットを接続制御部１３３からＩＰアドレス判断部１３４に転送し、３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５から割り当てられたＩＰアドレスを確認する（図７のステップＳ１４２）。ＩＰｖ４とＩＰｖ６に対応しているＵＥ１０は、一般的にＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを取得することができる。ここで、ＵＥ１０がＩＰｖ４とＩＰｖ６に対応している状態で、ＩＰｖ６　ＨｏＡのみ保持していた場合は、接続制御部１３３でＩＰｖ４　ＨｏＡ取得を決定し、パケット処理部１３２、無線通信部１３１を介してＩＰｖ４　ＨｏＡも取得する。なお、ＵＥ１０がＩＰｖ６のみに対応している状態で、ＩＰｖ６　ＨｏＡのみ保持している場合は、処理を終了する（図７のステップＳ１４３）。
　ＵＥ１０がＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを保持している場合、ＵＥ１０は接続制御部１３３からＴＦＴ判断部１３５にＵＥ１０自身が保持しているＴＦＴを確認するように指示し（図７のステップＳ１４４）、ＴＦＴに登録されている内容で、ＩＰｖ６　ＨｏＡのみに関連付けられているＥＰＳベアラ（図５Ａの状態）が存在するかどうかを確認する（図７のステップＳ１４５）。
　ＩＰｖ６　ＨｏＡのみに関連付けられているＥＰＳベアラが存在する場合、ＵＥ１０は接続制御部１３３からアプリケーション判断部１３６に、そのＥＰＳベアラを用いているアプリケーションが対応するＩＰバージョンの確認を指示し（図７のステップＳ１４６）、このアプリケーションが、ＩＰｖ６のみでなくＩＰｖ４にも対応しているかどうかを判断する（図７のステップＳ１４７）。
　このアプリケーションが、ＩＰｖ４とＩＰｖ６の両方に対応していることを確認した場合、ＵＥ１０は接続制御部から通信相手の対応ＩＰバージョン確認処理部１３７に、そのアプリケーションを用いて通信していた通信相手の対応しているＩＰバージョンを、例えばＤＮＳを用いて確認するように指示し（図７のステップＳ１４８）、通信相手がＩＰｖ４とＩＰｖ６の両方に対応しているかどうか判別する（図７のステップＳ１４９）。
　ＵＥ１０の通信相手がＩＰｖ４とＩＰｖ６の両方に対応している場合、ＵＥ１０は接続制御部１３３からＴＦＴ更新処理部１３８に、ＩＰｖ６　ＨｏＡのみに関連付けられているＥＰＳベアラに対して、ＩＰｖ４　ＨｏＡの関連付けも行うよう（すなわち、図５Ｂに図示されている状態となるよう）指示して、ＴＦＴを更新する（図７のステップＳ１５０）。その後、ＵＥ１０は、３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５から３Ｇアクセス（ＵＴＲＡＮ）３５へのハンドオーバ処理を実施する（図７のステップＳ１５１）。
　以上のように、本発明の第１の実施の形態によれば、ＵＥ１０がＩＰｖ４のみ利用可能なネットワークにハンドオーバする前に（例えば、ＰＧＷ５０とアタッチした後（ＰＤＮコネクション及びＥＰＳベアラ確立後））、ＵＥ１０自身及び通信相手の対応しているＩＰバージョンや使用しているアプリケーションの対応ＩＰバージョンなどを確認し、ＴＦＴに反映させることで、ハンドオーバ先のネットワークが対応しているＩＰバージョンに依存せずに、通信相手からパケットを継続的に受信することができ、新たにＥＰＳベアラを確立する必要もなくなる。
　＜第２の実施の形態＞
　次に、本発明の第２の実施の形態におけるシステム動作の一例について、図８を用いて詳しく説明する。図８は、本発明の第２の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。なお、図８に図示されているシーケンスは、ＵＥがＥ－ＵＴＲＡＮに接続する際に行われる動作であり、図１に示す構成との対応は、ＵＥ１０が３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５に接続する際の動作である。図８には、図１に図示されているシステム構成の構成要素に対応する装置にのみ参照符号を付している。
　図８は、少なくともＵＥ１０、ＵＥ１０と直接的にパケットの送受信を行うｅＮＢ、ＵＥ１０の移動管理を担当するＭＭＥ（新ＭＭＥ（Ｎｅｗ　ＭＭＥ）２０と旧ＭＭＥ／ＳＧＳＮ（Ｏｌｄ　ＭＭＥ／ＳＧＳＮ））、ＵＥ１０の識別子（Identity）を確認するＥＩＲ（Equipment Identity Register）、ｅＮＢを統括するＳＧＷ４０、ＳＧＷ４０を統括しＰＤＮ７０へのゲートウェイの役割を担い、ＵＥ１０の位置情報を管理するＰＧＷ５０、ＵＥ１０の課金コントロールなどを管理しているＰＣＲＦ、ＵＥ１０のサブスクリプション情報などを保持管理するＨＳＳによる処理シーケンスの一例が図示されている。なお、各機能を代わりに担うことができる構成要素が存在する場合には、それらを用いてもよい。
　また、図８は非特許文献１で説明される従来の技術の“Attach Procedure”である。本発明の第２の実施の形態は、従来の技術の“Attach Procedure”で交換されるメッセージのパラメータを改良して、ハンドオーバ前のＥＰＳベアラをハンドオーバ後でも維持できるようにした手法である。
　以下、従来技術の“Attach Procedure”と比較しながら図８に図示されている本発明の第２の実施の形態におけるシステム動作の一例について説明する。なお、従来の技術の“Attach Procedure”で、本発明の第２の実施の形態と直接関係のないステップの詳細な説明は省略する。
　ＵＥ１０は、Ｅ－ＵＴＲＡＮ（３Ｇアクセス２５）においてＰＤＮ７０と通信するために、ＵＥ１０とＰＧＷ５０との間のＰＤＮコネクション及びＥＰＳベアラを確立する。ＵＥ１０は、このＰＤＮコネクション及びＥＰＳベアラを確立するためにAttach RequestメッセージをｅＮＢに送信する。また、本発明の第２の実施の形態では、ＵＥ１０が接続しようとしているネットワークのオペレータ方針などの制限によって１つのアドレスタイプのみ（例えば、ＩＰｖ６のみ）割り当てられる場合を除いて、ＵＥ１０は必ずＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡ（正確には、ＩＰｖ６プレフィックスを取得した後にＩＰｖ６　ＨｏＡを生成）の両方を取得し、確立するＥＰＳベアラと関連付けるようにする（図８のステップＳ２０１：Attach Request）。
　ｅＮＢは、使用するＭＭＥを選択し（新ＭＭＥの選択）、受信したAttach Requestメッセージを選択した新ＭＭＥ２０に転送する（図８のステップＳ２０３：Attach Request）。続いて、従来の技術と同様に、新ＭＭＥ２０は、ＵＥ１０が以前３Ｇアクセスに接続していた情報が残っているか確認し、ＵＥ１０の識別子（Identity）をチェックし、さらにはＵＥ１０のネットワーク接続情報が残っていた場合は削除する処理などが実施される（詳しくは、非特許文献１を参照）。
　その後、新ＭＭＥ２０はＵＥ１０に関するＴＦＴを取得する（例えば、ＨＳＳに問い合わせる）。続いて、新ＭＭＥ２０はＳＧＷ４０にＵＥ１０のＩＰアドレスが格納されたパラメータ（ＰＤＮアドレス）などを送信する（図８のステップＳ２０５：Create Session Request）。
　次に、ＳＧＷ４０は、ＵＥ１０のＩＰアドレスなどを用いてＴＦＴ（ＥＰＳベアラテーブル）を作成する。続いて、ＳＧＷ４０は新ＭＭＥから受信したパラメータ（例えば、ＰＤＮアドレス）などをＰＧＷ５０に送信する（図８のステップＳ２０７：Create Session Request）。
　次に、ＰＧＷ５０はＳＧＷ４０から送られてきたＵＥ１０のＩＰアドレスなどを用いてＴＦＴ（ＥＰＳベアラコンテキストテーブル）を作成する（図８のステップＳ２０９：Create Session Response）。以降、一般的なAttach Procedureを実施して、ＵＥ１０とＰＧＷ５０との間のＰＤＮコネクション及びＥＰＳベアラを確立する。なお、ＭＭＥ２０、ＳＧＷ４０、ＰＧＷ５０がＴＦＴを取得／作成するステップの順番は、これに限ったわけではなく、ＳＧＷ４０、ＰＧＷ５０が先にＴＦＴを作成し、その後にＭＭＥ２０が取得／作成してもよい。
　また、Attach Procedure中にＵＥ１０がＩＰアドレスを取得できない場合がある。そのような場合は、ステップＳ２０１（Attach request）でＵＥ１０が割り当てられる全アドレスを登録するよう指示するのではなく、Attach Procedure完了後、かつ、ＵＥ１０が３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５からＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを割り当てられたときに、本発明の第１の実施の形態のようにＵＥ１０が、例えば“PGW initiated bearer modification without bearer QoS update procedure”（非特許文献１を参照）を実施して、図５Ａから図５ＢのようなＴＦＴに更新してもよい。
　なお、本発明の第１の実施の形態と同様に、ＵＥ１０は、後述の図１０のステップＳ１７２で、ＵＥ１０がＩＰｖ６のみに対応している場合、使用しているＥＰＳベアラに対応するＴＦＴの維持／解放（リリース）を決定するためのパラメータ（例えば、“ＤＥＬＥＴＥ”、“ＣＨＡＮＧＥ”、“ＰＲＥＳＥＲＶＥ”）を用いてＴＦＴを更新してもよい。これらのパラメータの説明は、本発明の第１の実施の形態と同じであるため、ここでは説明を省略する。
　次に、本発明の実施するための移動端末（ＵＥ１０）の構成について説明する。以下、図９を参照しながら、本発明の第２の実施の形態におけるＵＥ１０の構成について説明する。図９は、本発明の第２の実施の形態におけるＵＥ１０の構成の一例を示す図である。
　図９において、ＵＥ１０はアクセスネットワーク（３Ｇアクセス２５、３５、Ｎ３Ｇアクセス６５）と接続して下位レイヤにおける通信処理を行う無線通信部１６１、無線通信部１６１の上位でＩＰなどのパケット通信処理を実施するパケット処理部１６２、ＵＥ１０とＰＧＷ５０との間の通信経路の確立（ＰＤＮコネクション及びＥＰＳベアラの確立）を実施する接続制御部１６３、ＵＥ１０とＰＧＷ５０と間の通信経路確立後に実施するＵＥ１０自身のＩＰアドレス判断部１６４を少なくとも有する。なお、本発明の第２の実施の形態は、本発明の第１の実施の形態と同様、ハンドオーバ前に無線通信部１６１はＥ－ＵＴＲＡＮ（３Ｇアクセス２５）に接続しており、ハンドオーバ後に無線通信部１６１がＵＴＲＡＮ（３Ｇアクセス３５）に接続するものとして説明している。
　次に、図９に図示されている構成を有するＵＥ２０の処理フローについて、本発明における特徴的な処理を実施する接続制御部に係る処理を中心に、図１０を用いて詳しく説明する。なお、ＵＥは、本発明の第１の実施の形態と同様、既に無線通信部を介して３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５に接続済みであり、ＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡを用いてパケットの送受信が可能な状態であるとする。さらに、その状態でＩＰｖ４のみ利用可能な３Ｇアクセス（ＵＴＲＡＮ）３５にハンドオーバを行うとする。
　図１０は、本発明の第２の実施の形態におけるＵＥ２０の処理フローの一例を示すフロー図である。最初にＵＥ１０は、ＰＤＮコネクション及びＥＰＳベアラをＰＧＷ５０との間で確立するために接続制御部１６１からＩＰアドレス判断部１６４に、ＵＥ１０自身が対応しているＩＰバージョンを確認するよう指示をする（ステップＳ１７１）。続いて、ＵＥ１０はＩＰアドレス判断部１６４でＵＥ１０自身がＩＰｖ４とＩＰｖ６に対応しているか判断する（ステップＳ１７２）。
　ＩＰｖ４とＩＰｖ６に対応している場合は、ＵＥ１０は３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５からＩＰｖ４のみ利用可能なネットワーク（例えば、３Ｇアクセス（ＵＴＲＡＮ）３５）にハンドオーバした際でも、ハンドオーバ前（３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５）で確立したＥＰＳベアラを維持できるように、接続制御部１６２でＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡ（正確には、ＩＰｖ６プレフィックスを取得後、ＩＰｖ６　ＨｏＡを生成する）を取得することを決定する（ステップＳ１７３）。
　続いて、ＵＥ１０は接続制御部１６３からパケット処理部１６２、無線通信部１６１を介して、ＩＰｖ４とＩＰｖ６アドレスを取得することを示すパラメータ（例えば、ＰＤＮタイプでＩＰｖ４／ＩＰｖ６と指定）を格納したAttach Requestメッセージを送信する（ステップＳ１７４）。以降、ＵＥ１０は、従来の技術のAttach procedureと同様に一般的なAttach procedureの処理を実施する（ステップＳ１７５）。
　以上のように、本発明の第２の実施の形態によれば、ＵＥ１０が、Attach request（例えば、図８のステップＳ２０１）で、アタッチするネットワークで必要となるか否かによらずにＩＰｖ４とＩＰｖ６の両方のアドレスを取得するよう指示することで、各装置（例えば、ＵＥ１０やＰＧＷ５０）のＴＦＴに登録されているＥＰＳベアラでは、ＩＰｖ４　ＨｏＡとＩＰｖ６　ＨｏＡが関連付けられる。これにより、ＵＥ１０は、次回ハンドオーバ時に３Ｇアクセス（Ｅ－ＵＴＲＡＮ）２５からＩＰｖ４のみ利用可能な３Ｇアクセス（ＵＴＲＡＮ）３５にハンドオーバした際でも、ハンドオーバ先のネットワークで必要となるＥＰＳベアラを維持することができており、通信相手からのパケットを受信し続けることができるようになる。
　なお、上述した本発明の第１及び第２の実施の形態では、主にハンドオーバによって提供されるアドレスタイプが変わった場合（例えば、単一のアドレスタイプしか提供されないネットワークにハンドオーバしたとき）について説明したが、ネットワーク環境の変化によって提供されるアドレスタイプが変わった場合全般に関して、本発明の適用が可能である。例えば、ＵＥ１０がアタッチしているネットワークにおいて、何らかの理由（例えば、セキュリティ保全や負荷分散などの理由）によって、利用可能なアドレスタイプが変更された場合であっても、本発明によれば、ＵＥ１０は、ＰＤＮ７０との間における通信コネクションを維持することが可能となる。
　なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
　本発明は、ネットワークの状態が変更され（例えば、ハンドオーバによるネットワークの状態変更）、ネットワークにおいてＩＰアドレスタイプが変更された後であっても、通信を維持することができるという効果を有し、特に、異なるＩＰバージョンのＩＰアドレスを同時に使用している移動端末が、１つのＩＰバージョンのみ利用可能なネットワークにハンドオーバした際に不本意なＥＰＳベアラの解放（リリース）を回避できるようになるという効果を有している。従って、１つ以上の通信インタフェースで複数のＩＰバージョンのＩＰアドレスを用いて通信を行う移動端末にかかる技術に適用可能であり、特に、１つ以上の通信インタフェースで複数のＩＰバージョンのＩＰアドレスを用いて複数の通信経路を確立している移動端末が、ネットワークを移動してハンドオーバを行う際に用いられる技術に適用可能である。

Claims (14)

  1. 　複数の異なるアドレスタイプのＩＰアドレスを用いて通信を行うことが可能な移動端末であって、
    　所定の通信相手と通信を行うためにネットワークに接続するネットワーク接続部と、
    　前記ネットワーク接続部が接続している前記ネットワークで利用可能なアドレスタイプによらず、前記所定の通信相手との間におけるパケットフローに対して、複数の異なるアドレスタイプに対応するパケットフィルタを設定するパケットフィルタ設定手段とを、
    　有する移動端末。
  2. 　前記複数の異なるアドレスタイプのすべてのタイプに係る前記ＩＰアドレスを取得する手段を有し、
    　前記パケットフィルタ設定手段が、前記複数の異なるアドレスタイプのすべてのタイプに係る前記ＩＰアドレスに対応するパケットフィルタを設定するよう構成されている請求項１に記載の移動端末。
  3. 　前記移動端末自身が保持している前記ＩＰアドレスのアドレスタイプを確認する手段を有し、
    　前記移動端末がＩＰｖ４及びＩＰｖ６の両方のアドレスタイプのＩＰアドレスを保持している場合に、前記パケットフィルタ設定手段が、前記ＩＰｖ４及びＩＰｖ６の両方のアドレスタイプに係る前記ＩＰアドレスに対応するパケットフィルタを設定するよう構成されている請求項１に記載の移動端末。
  4. 　前記移動端末自身が保持している前記ＩＰアドレスのアドレスタイプを確認する手段と、
    　前記移動端末がＩＰｖ４及びＩＰｖ６の両方のアドレスタイプのＩＰアドレスを保持している場合に、前記所定の通信相手との間におけるパケットフローに対して、前記ＩＰｖ４及びＩＰｖ６の両方のアドレスタイプに係る前記ＩＰアドレスが関連付けられているか否かを確認する手段とを、
    　有し、
    　前記パケットフィルタ設定手段が、前記ＩＰｖ４及びＩＰｖ６のいずれか一方のアドレスタイプに係る前記ＩＰアドレスしか関連付けられていないパケットフローに関して、前記ＩＰｖ４及びＩＰｖ６の両方のアドレスタイプの前記ＩＰアドレスが関連付けられるように前記パケットフィルタを更新するよう構成されている請求項１に記載の移動端末。
  5. 　所定のパケットフローを利用している前記移動端末自身のアプリケーションが対応するアドレスタイプを確認する手段を有し、
    　前記パケットフィルタ設定手段が、前記所定のパケットフローに対して、前記アプリケーションが対応可能なすべてのアドレスタイプに対応するパケットフィルタを設定するよう構成されている請求項１に記載の移動端末。
  6. 　前記通信相手が対応するアドレスタイプを確認する手段を有し、
    　前記パケットフィルタ設定手段が、前記所定の通信相手との間における前記パケットフローに対して、前記通信相手が対応可能なすべてのアドレスタイプに対応するパケットフィルタを設定するよう構成されている請求項１に記載の移動端末。
  7. 　所定のパケットフローに対して、前記ネットワーク条件が変更された場合に前記パケットフィルタを維持又は解放することを明示する情報を付加する手段を有する請求項１に記載の移動端末。
  8. 　複数の異なるアドレスタイプのＩＰアドレスを用いて通信を行うことが可能な移動端末におけるパケットフィルタ設定方法であって、
    　前記移動端末が所定の通信相手と通信を行うために接続しているネットワークで利用可能なアドレスタイプによらず、前記所定の通信相手との間におけるパケットフローに対して、複数の異なるアドレスタイプに対応するパケットフィルタを設定するパケットフィルタ設定ステップを、
    　有するパケットフィルタ設定方法。
  9. 　前記複数の異なるアドレスタイプのすべてのタイプに係る前記ＩＰアドレスを取得するステップを有し、
    　前記パケットフィルタ設定ステップにおいて、前記複数の異なるアドレスタイプのすべてのタイプに係る前記ＩＰアドレスに対応するパケットフィルタを設定する請求項８に記載のパケットフィルタ設定方法。
  10. 　前記移動端末自身が保持している前記ＩＰアドレスのアドレスタイプを確認するステップを有し、
    　前記移動端末がＩＰｖ４及びＩＰｖ６の両方のアドレスタイプのＩＰアドレスを保持している場合に、前記パケットフィルタ設定ステップにおいて、前記ＩＰｖ４及びＩＰｖ６の両方のアドレスタイプに係る前記ＩＰアドレスに対応するパケットフィルタを設定する請求項８に記載のパケットフィルタ設定方法。
  11. 　前記移動端末自身が保持している前記ＩＰアドレスのアドレスタイプを確認するステップと、
    　前記移動端末がＩＰｖ４及びＩＰｖ６の両方のアドレスタイプのＩＰアドレスを保持している場合に、前記所定の通信相手との間におけるパケットフローに対して、前記ＩＰｖ４及びＩＰｖ６の両方のアドレスタイプに係る前記ＩＰアドレスが関連付けられているか否かを確認するステップとを、
    　有し、
    　前記パケットフィルタ設定ステップにおいて、前記ＩＰｖ４及びＩＰｖ６のいずれか一方のアドレスタイプに係る前記ＩＰアドレスしか関連付けられていないパケットフローに関して、前記ＩＰｖ４及びＩＰｖ６の両方のアドレスタイプの前記ＩＰアドレスが関連付けられるように前記パケットフィルタを更新する請求項８に記載のパケットフィルタ設定方法。
  12. 　所定のパケットフローを利用している前記移動端末自身のアプリケーションが対応するアドレスタイプを確認するステップを有し、
    　前記パケットフィルタ設定ステップにおいて、前記所定のパケットフローに対して、前記アプリケーションが対応可能なすべてのアドレスタイプに対応するパケットフィルタを設定する請求項８に記載のパケットフィルタ設定方法。
  13. 　前記通信相手が対応するアドレスタイプを確認するステップを有し、
    　前記パケットフィルタ設定ステップにおいて、前記所定の通信相手との間における前記パケットフローに対して、前記通信相手が対応可能なすべてのアドレスタイプに対応するパケットフィルタを設定する請求項８に記載のパケットフィルタ設定方法。
  14. 　所定のパケットフローに対して、前記ネットワーク条件が変更された場合に前記パケットフィルタを維持又は解放することを明示する情報を付加するステップを有する請求項８に記載のパケットフィルタ設定方法。
PCT/JP2010/005383 2009-11-06 2010-09-01 移動端末及びパケットフィルタ設定方法 WO2011055478A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-255104 2009-11-06
JP2009255104 2009-11-06

Publications (1)

Publication Number Publication Date
WO2011055478A1 true WO2011055478A1 (ja) 2011-05-12

Family

ID=43969721

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/005383 WO2011055478A1 (ja) 2009-11-06 2010-09-01 移動端末及びパケットフィルタ設定方法

Country Status (1)

Country Link
WO (1) WO2011055478A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015159502A (ja) * 2014-02-25 2015-09-03 シャープ株式会社 移動局装置、無線通信システム、無線通信方法およびプログラム
WO2019095110A1 (zh) * 2017-11-14 2019-05-23 Oppo广东移动通信有限公司 一种切换处理方法、网络设备及计算机存储介质
CN114268583A (zh) * 2021-11-26 2022-04-01 网络通信与安全紫金山实验室 基于sdn的双栈骨干网管理方法、装置、及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP TS 23.401 V9.2.0, September 2009 (2009-09-01), pages 133 - 139, Retrieved from the Internet <URL:http://www. 3gpp.org/ftp/Specs/archive/23_series/23.401/ 23401-920.zip> [retrieved on 20101119] *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015159502A (ja) * 2014-02-25 2015-09-03 シャープ株式会社 移動局装置、無線通信システム、無線通信方法およびプログラム
WO2019095110A1 (zh) * 2017-11-14 2019-05-23 Oppo广东移动通信有限公司 一种切换处理方法、网络设备及计算机存储介质
CN114268583A (zh) * 2021-11-26 2022-04-01 网络通信与安全紫金山实验室 基于sdn的双栈骨干网管理方法、装置、及电子设备
CN114268583B (zh) * 2021-11-26 2024-01-23 网络通信与安全紫金山实验室 基于sdn的双栈骨干网管理方法、装置、及电子设备

Similar Documents

Publication Publication Date Title
KR101726604B1 (ko) 동적 호스트 구성 프로토콜 ＩＰｖ4 어드레스 해제 요청을 처리하기 위한 방법 및 시스템
US8964697B2 (en) Connection management method, connection management system, mobile terminal, packet data gateway and mobile management gateway
US10104541B2 (en) Method and apparatus for establishing user plane bearer
EP2908566B1 (en) Method and system for realizing mobility management of evolved packet core network
US20110096660A1 (en) Handover processing method, and mobile terminal used in the method
US8824430B2 (en) Wireless mobility gateway
RU2484603C2 (ru) Посреднический мобильный протокол internet (pmip) в среде связи с множеством интерфейсов
JP5452631B2 (ja) 複数のパケットデータネットワーク接続のためのハンドオフの実現
US9113455B2 (en) Method and device relating to replay technique
EP1560378A2 (en) Wireless mobility gateway
JP2013503553A (ja) モビリティアンカーの移転
US20190364467A1 (en) Method and communication entity for proving a communication connection
EP3836625A1 (en) Network switching method, and amf apparatus and sgsn apparatus
KR20120052223A (ko) 메시지 송신 방법 및 범용 무선 패킷 서비스 지원 노드
JP2010523016A (ja) 通信システムにおけるｉｐベアラコネクションを解放する方法、システム及び装置
US8761119B2 (en) Handover method, and mobile terminal and home agent used in the method
US9148826B2 (en) Handover method and mobile terminal and home agent used in the method
US20110255511A1 (en) Handover method and mobile terminal and home agent utilized in said method
WO2011055478A1 (ja) 移動端末及びパケットフィルタ設定方法
US8503306B2 (en) Technique for route optimization in a communication network
WO2010146815A1 (ja) 移動管理プロトコル選択方法、移動管理プロトコル選択システム、モバイルノード、ホームエージェント及び代理ノード
WO2013038588A1 (ja) 通信制御方法及び通信端末並びにネットワーク装置
WO2016074468A1 (zh) 支持多pdn连接的优化切换的方法、网络节点及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10828041

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10828041

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP