[go: up one dir, main page]

WO2017130495A1 - 中継装置、端末装置、通信制御装置及び方法 - Google Patents

中継装置、端末装置、通信制御装置及び方法 Download PDF

Info

Publication number
WO2017130495A1
WO2017130495A1 PCT/JP2016/081953 JP2016081953W WO2017130495A1 WO 2017130495 A1 WO2017130495 A1 WO 2017130495A1 JP 2016081953 W JP2016081953 W JP 2016081953W WO 2017130495 A1 WO2017130495 A1 WO 2017130495A1
Authority
WO
WIPO (PCT)
Prior art keywords
urn
address
urn2a
denb
transmits
Prior art date
Application number
PCT/JP2016/081953
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 ソニー株式会社
Priority to CA3010773A priority Critical patent/CA3010773A1/en
Priority to EP16888080.5A priority patent/EP3410755B1/en
Priority to US16/071,752 priority patent/US10694396B2/en
Publication of WO2017130495A1 publication Critical patent/WO2017130495A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/26—Cell enhancers or enhancement, e.g. for tunnels, building shadow
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/668—Internet protocol [IP] address subnets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Definitions

  • the present disclosure relates to a relay device, a terminal device, a communication control device, and a method.
  • a relay device In a cellular network, a relay device called a relay node has been devised.
  • the relay node is located between the base station and the user terminal and has a function of relaying the wireless communication.
  • a standard related to a relay node is studied in Non-Patent Document 1 below.
  • Non-Patent Document 1 it is assumed that the relay node is fixed, and the standard is not assumed to move. Therefore, it is desirable to provide a mechanism related to the relay node in consideration of movement.
  • a relay unit that relays a radio signal between a first device to be connected and one or more second devices under its control, and a prefix portion in each of the one or more second devices
  • a control unit that assigns a network layer IP address at least a part of which is shared.
  • communication with the relay device is performed using a first network layer IP address in which at least a part of a prefix portion allocated to one or more terminal devices connected to the same relay device is common.
  • a terminal device including a processing unit is provided.
  • a wireless signal is relayed between the first device to be connected and one or more second devices under its control, and each of the one or more second devices has a prefix portion.
  • a communication control device includes a processing unit that notifies a relay device that assigns at least a part of a common network layer IP address to the common part of the prefix part.
  • a wireless signal is relayed between the first device to be connected and one or more second devices under its control, and a prefix is provided to each of the one or more second devices.
  • a controller that assigns, by a processor, a network layer IP address at least a portion of which is common.
  • communication with the relay device is performed using a first network layer IP address in which at least a part of a prefix portion allocated to one or more terminal devices connected to the same relay device is common.
  • a method comprising: performing by a processor.
  • a wireless signal is relayed between the first device to be connected and one or more second devices under its control, and each of the one or more second devices has a prefix portion.
  • a method comprising: notifying a relay device that assigns a network layer IP address that is at least partly common, by a processor, of a common part of the prefix part.
  • 1 is a diagram illustrating an example of a schematic configuration of a system according to an embodiment of the present disclosure. It is a figure which shows an example of the protocol stack
  • FIG. It is a figure for demonstrating the technical feature of 1st Embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment. It is a figure for demonstrating the technical feature of the embodiment.
  • elements having substantially the same functional configuration may be distinguished by adding different alphabets after the same reference numerals.
  • a plurality of elements having substantially the same functional configuration are distinguished as necessary, such as the terminal devices 100A, 100B, and 100C.
  • the terminal devices 100A, 100B, and 100C are simply referred to as the terminal device 100 when it is not necessary to distinguish them.
  • Fig. 1 shows an E-UTRAN (Evolved Universal Terrestrial Radio Access Network) architecture that supports relay nodes.
  • An RN Relay Node
  • An RN is an entity that relays wireless communication by a user terminal (UE: User Equipment).
  • DeNB donor eNB
  • DeNB is an eNB connected to a relay node.
  • an S1 interface is set between the eNB and the MME / S-GW.
  • an S1 interface and an S11 interface are set between the DeNB and the MME / S-GW.
  • an X2 interface is set between the eNB and the DeNB.
  • an S1 interface, an X2 interface, and a Uu interface are set between the DeNB and the RN (Relay Node).
  • FIG. 2 shows the protocol stack of the S1 user plane.
  • FIG. 3 is a diagram illustrating a protocol stack of the X2 user plane.
  • FIG. 4 is a diagram illustrating a protocol stack of the S1 control plane.
  • FIG. 5 is a diagram illustrating a protocol stack of the X2 control plane.
  • IP in FIGS. 2 to 5 is all IP in the transport layer. That is, no IP in the network layer is assumed for the relay node.
  • the mobility of relay nodes was not considered. Therefore, although the relay node has a transport layer IP address, transparency associated with movement related to the IP is not ensured. The same problem occurs even if the relay node has a network layer IP address.
  • This disclosure provides an example of a new protocol that solves the above four technical problems.
  • International Publication No. 2012/114527 discloses a technique for assigning a plurality of IP addresses to a relay node. More specifically, the DeNB assigns a plurality of IP addresses to the subordinate relay node, and other relay nodes connected to the relay node are assigned an IP address from among the plurality of IP addresses. Is disclosed.
  • the prior art is a technique used when connecting relay nodes in a so-called daisy chain, and does not relate to an IP address assigned to a terminal group under the relay node as shown in the technical problem.
  • Mobility support protocols can be classified from two viewpoints.
  • the first point of view is whether the protocol is a node mobility (Node Mobility) protocol or a node cluster (network) protocol (Network Mobility: NEMO) protocol.
  • the second point of view is that the mobile node (or mobile router) is involved in signaling for mobility management and the movement range is the entire Internet (Host-Based Global Mobility) protocol, or the mobile node (or mobile router)
  • the proposed protocol according to the present embodiment is a protocol in which the NEMO and the mobile node are not limited to signaling for mobility management and are only in a limited range.
  • FIG. 6 is a diagram illustrating an example of a schematic configuration of a system according to an embodiment of the present disclosure.
  • the system according to the present embodiment includes UE1, URN2, DeNB3, eNB4, S-GW5, P-GW6, MME7, and HSS8.
  • a solid line connecting each indicates a user plane, and a broken line indicates a control plane.
  • UEs indicate a plurality of UE1s.
  • the proposed protocol can operate using, for example, a cellular phone network as a domain (network range). Of course, the domain may have other network configurations.
  • UE1 is a terminal device.
  • a URN (User-Relay-Node) 2 is a relay apparatus that can operate as a UE or an RN.
  • DeNB3 is a base station to which a relay node is connected.
  • eNB4 is a base station.
  • An S-GW (Serving Gateway) 5 is a gateway for transmitting user data.
  • the P-GW 6 is a gateway serving as a contact point between the core network and an external PDN (Packet Data Network), and is a communication control device that assigns IP addresses and the like.
  • An MME (mobility management entity) 7 performs UE 1 mobility management, authentication, setting of a user data transfer path, and the like.
  • An HSS (Home Subscriber Server) 8 manages user information.
  • the system according to the present embodiment may include entities such as a policy and charging rules function (PCRF) that determine policy control and charging control rules such as QoS applied in the S-GW 5 and the P-GW 6.
  • PCRF
  • FIG. 7 is a diagram illustrating an example of the protocol stack of URN2 according to the present embodiment.
  • URN2 has a network layer IP address (used by applications on UE1 or URN2) in addition to the EPC transport layer IP address.
  • FIG. 8 is a diagram showing an example of a protocol stack in communication between the UE 1 via the URN 2 and the server on the PDN according to the present embodiment.
  • the URN 2 is connected to the DeNB 3 and communicates with the application server on the PDN via the EPC (S-GW 5 and P-GW 6).
  • URN2 relays radio
  • FIG. 9 is a block diagram illustrating an example of the configuration of the UE 1 according to the present embodiment.
  • UE1 includes an antenna unit 110, a radio communication unit 120, a storage unit 130, and a processing unit 140.
  • Antenna unit 110 The antenna unit 110 radiates a signal output from the wireless communication unit 120 to the space as a radio wave. Further, the antenna unit 110 converts radio waves in space into a signal and outputs the signal to the wireless communication unit 120.
  • the wireless communication unit 120 transmits and receives signals.
  • the radio communication unit 120 receives a downlink signal from URN2 or eNB4, and transmits an uplink signal to URN2 or eNB4.
  • Storage unit 230 The storage unit 130 temporarily or permanently stores programs and various data for the operation of the UE1.
  • the processing unit 140 provides various functions of the UE1.
  • the processing unit 140 includes a communication control unit 141.
  • the processing unit 140 may further include other components than this component. In other words, the processing unit 140 can perform operations other than the operation of this component.
  • the communication control unit 141 has a function of controlling communication with the URN2.
  • FIG. 10 is a block diagram illustrating an example of the configuration of the URN 2 according to the present embodiment.
  • URN 2 includes an antenna unit 210, a wireless communication unit 220, a storage unit 230, and a processing unit 240.
  • Antenna unit 210 The antenna unit 210 radiates the signal output from the wireless communication unit 220 to the space as a radio wave. Further, the antenna unit 210 converts a radio wave in the space into a signal and outputs the signal to the wireless communication unit 220.
  • the wireless communication unit 220 transmits and receives signals.
  • the radio communication unit 220 receives a downlink signal from the connection-destination DeNB3 or the connection-destination URN2, and transmits an uplink signal to the connection-destination DeNB3 or the connection-destination URN2. Further, for example, the radio communication unit 220 receives an uplink signal from the UE1 and transmits a downlink signal to the UE1.
  • Storage unit 230 The storage unit 230 temporarily or permanently stores a program for the operation of the URN 2 and various data.
  • the processing unit 240 provides various functions of the URN2.
  • the processing unit 240 includes a relay unit 241 and a communication control unit 243.
  • the processing unit 240 may further include other components than this component. In other words, the processing unit 240 can perform operations other than the operation of this component.
  • the relay unit 241 has a function of relaying a radio signal between the connected DeNB3 (that is, the first device) and one or more UE1 or one or more URN2 (that is, the second device) under the control.
  • the communication control unit 243 has a function of controlling communication with the UE 1 and performing connection processing or handover processing with the connection-destination DeNB 3 or the connection-destination URN 2.
  • FIG. 11 is a block diagram showing an example of the configuration of the P-GW 6 according to this embodiment.
  • the P-GW 6 includes a network communication unit 610, a storage unit 620, and a processing unit 630.
  • the network communication unit 610 is an interface for performing communication with other devices.
  • the P-GW 6 communicates with other EPC entities in the core network or a server on the PDN.
  • Storage unit 620 The storage unit 620 temporarily or permanently stores a program for operating the P-GW 6 and various data.
  • Processing unit 630 provides various functions of the P-GW 6.
  • the processing unit 630 includes a communication control unit 631. Note that the processing unit 630 may further include other components than this component. In other words, the processing unit 630 can perform operations other than the operation of this component.
  • the communication control unit 631 has a function of performing various processes related to the process of connecting the UE 1 or URN 2 to the network.
  • FIG. 12 is a diagram for explaining the initial assignment of IP addresses.
  • the initial IP address assignment will be described on the premise of the network configuration shown in FIG.
  • UE1A and URN2B are connected to URN2A
  • UE1B and URN2C are connected to URN2B
  • UE1C is connected to URN2C.
  • the mobile network formed by each URN 2 is also referred to as a moving cell or a virtual cell.
  • the virtual cell is indicated by a broken-line rectangle.
  • a structure in which another virtual cell is connected to the virtual cell such as a virtual cell formed by the URN 2B and a virtual cell formed by the URN 2C, is also referred to as a nested structure.
  • a virtual cell formed by the URN 2B is also referred to as a nested virtual cell.
  • the UE 1 is assigned an IP address (Static IP) registered in advance in the HSS 8 or an IP address (Dynamic IP) reserved in advance in the P-GW 6 in the attach procedure.
  • Static IP IP address registered in advance in the HSS 8
  • Dynamic IP IP address reserved in advance in the P-GW 6 in the attach procedure.
  • the URN 2 acquires an IP address by an attach procedure, and then an IP address is assigned to the UE 1 under its control.
  • URN2 can also operate as UE1, it is desirable to assign an IP address to URN2. Therefore, URN2, like UE1, transmits an attach request message to MME7, performs an IP address assignment process, receives an IP address assignment, and assigns an IP address to itself.
  • the S-GW 5 and the P-GW 6 may be realized as functional entities for relay nodes provided inside the DeNB 3.
  • a virtualization function based on NFV Network Functions Virtualization
  • IP address corresponding to the identification information (ID: identification) of URN2 is registered in HSS8, the IP address may be included in the attach accept message and notified to URN2. .
  • a PCO Protocol Configuration Options
  • NAS Non-Access Stratum
  • the P-GW 6 generates and notifies an ID (for example, an interface identifier (64 bits) in IPv6) assigned to the request source URN 2. This notification may be included in an attach approval message, for example. Further, the P-GW 6 generates and stores an association between the globally unique terminal ID of the URN 2 (for example, IMSI (International Mobile Subscriber Identity)) and the prefix part of the IP address (for example, IPv6 Prefix / 64). .
  • IMSI International Mobile Subscriber Identity
  • URN2 generates a link local address using a given ID (for example, IPv6 interface identifier), and sends an RS message (Router Advertisement Message), which is a so-called IP protocol, to P-GW6.
  • the prefix part of the IP address (for example, IPv6 Prefix / 64) may be acquired.
  • the prefix part of the IP address may be included in the RA message (Router Advertisement Message) transmitted by the P-GW 6.
  • URN2 may produce
  • the URN 2 may generate an IPv6 address by generating an interface identifier different from the interface identifier generated by the P-GW 6.
  • URN2 may acquire an IP address from a DHCP server using the DHCPv6 protocol instead of an RS message and an RA message. In this way, the URN 2 can allocate its own IP address.
  • FIG. 15 is a sequence diagram illustrating an example of a flow of an IP address assignment process to the URN 2 according to the present embodiment. This sequence involves URN2, DeNB3, S-GW5, P-GW6, MME7 and HSS8, and PCRF9.
  • the URN 2A transmits an attach request (Attach Request (PCO IP Address Request)) to the MME 7 (step S102).
  • the URN 2A performs identification, authentication, encryption, and the like (Identification / Authentication / Ciphered option etc.) with the DeNB 3, MME 7, and HSS 8 (step S104).
  • the MME 7 transmits a location request (Location Request) to the HSS 8 (step S106).
  • the HSS 8 transmits a location request response (Location Request Response) to the MME 7 (step S108).
  • the MME 7 transmits a bearer request to the S-GW 5 (step S110).
  • the S-GW 5 performs bearer establishment procedures with the PCRF 9 and the P-GW 6 (step S112).
  • the S-GW 5 transmits a bearer request response to the MME 7 (step S114).
  • the MME 7 transmits to the DeNB 3 a radio bearer request including the attachment approval (Attach Accepted) and the interface ID (URN-Interface ID) of the URN 2A (Step S116).
  • the DeNB 3 transmits a radio bearer request (Radio Bearer Request) including an attach approval (Attach Accepted) and an interface ID (URN-Interface ID) of the URN 2A to the URN 2A (step S118).
  • the URN 2A acquires its own interface identifier (URN Interface ID) (step S120).
  • the URN 2A transmits a radio bearer response (Radio Bearer Response) to the DeNB 3 (step S122).
  • DeNB 3 transmits a radio bearer response (Radio Bearer Response) to MME 7 (step S124).
  • the URN 2A transmits an attach complete (Attach Complete) to the MME 7 (step S126).
  • the URN 2A can transmit the uplink user plane traffic data to the PDN 10 via the DeNB 3, S-GW 5, and P-GW 6 (step S128).
  • the MME 7 transmits a bearer update request to the S-GW 5 (step S130).
  • the S-GW 5 performs a bearer update procedure with the PCRF 9 and the P-GW 6 (step S132).
  • the S-GW 5 transmits a bearer update response (Bearer Update Response) to the MME 7 (step S134).
  • the downlink user plane traffic data can be transmitted from the PDN 10 to the URN 2A via the P-GW 6, the S-GW 5, and the DeNB 3 (step S136).
  • the URN 2A transmits an RS message (Router Solicitation Message) to the P-GW 6 (step S138).
  • the P-GW 6 transmits an RA message (Router Advertisement Message) including prefix / 64 to the URN 2A (Step S140).
  • the URN 2A generates its own IPv6 address (URN IPv6 Address) composed of the prefix / 64 and the interface identifier (step S142).
  • the UE1 can also be assigned an IP address in the same manner as URN2 described above.
  • the URN 2 assigns an IP address in which at least a part of the prefix portion is common (ie, the same) to each of the one or more subordinate UEs 1 or one or more subordinate URNs 2.
  • an IP address having at least a part of the prefix portion is assigned to one or more UE1 or URN2 connected to the same URN2.
  • the subordinate UE1 or URN2 communicates with the URN2 and its upper network (P-GW6 or the like) using the assigned IP address.
  • This prefix part may be a subnet prefix in IPv6.
  • the subnet prefix may be the upper 64 bits of the IPv6 128 bits, and the upper 56 bits (hereinafter also referred to as “Prefix / 56”) may be the common part.
  • the URN 2 uses the DHCP-PD (Prefix delegation) protocol to acquire the prefix portion that is commonly allocated to the subordinate UE 1 from the P-GW 6 or the DHCP server. Therefore, the P-GW 6 notifies the URN 2 of the common part (IPv6 Prefix / 56) of the prefix part.
  • URN2 may create and allocate Prefix / 64 specifying the lower bits of “0000 0000” to Prefix / 56, for example.
  • DHCP-PD is described in detail in “O. Troan and R. Droms. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6, December 2003. RFC 3633.”.
  • the UE 1 generates a link local address using an ID (for example, an IPv6 interface identifier) assigned in a normal procedure. And UE1 may acquire the prefix part (Prefix / 64) of the IP address produced
  • an ID for example, an IPv6 interface identifier
  • the DHCP server can create Prefix / 64 in which the lower bits of “0000 0000” are specified in Prefix / 56 acquired by DHCP-PD by URN2 to which UE1 is connected and notify UE1. .
  • the UE 1 can acquire the connection information of the DNS server or the DHCP server and the IP address of the connection destination URN 2 using PCO or the like. In this way, UE1 can assign an IP address to itself.
  • a mapping table for generating a bearer on each entity (P-GW6, S-GW5, DeNB3, etc.) can be created and stored in each entity.
  • this mapping table is created when instructed by the MME 7.
  • the MME 7 instructs to update the bearer from the source to the target entity (for example, DeNB3 or S-GW5), and the mapping table is updated accordingly.
  • the URN 2 acquires, for example, Prefix / 56 using DHCP-PD for the UE 1 group connected to the URN 2.
  • the P-GW 6 to which the Prefix / 56 is assigned may notify the S-GW 5 and the DeNB 3 of information for the association. This message is also referred to as route setup below.
  • the route setup and mapping table will be described in detail later.
  • 16 and 17 are sequence diagrams illustrating an example of a flow of an IP address assignment process to the UE 1A according to the present embodiment.
  • UE1A, URN2A, DeNB3, S-GW5, P-GW6, MME7 and HSS8, and PCRF9 are involved.
  • the URN 2A has completed the connection to the network and has acquired the IP address, for example, by the procedure described above with reference to FIG. 15 (step S202).
  • the URN 2A transmits a DHCP-PD request (DHCP_PD Request) requesting the prefix part (Prefix / 56) of the IP address of the UE 1A to the P-GW 6 (step S204).
  • the P-GW 6 transmits a DHCP-PD response (DHCP_PD Response) including the prefix part (Prefix / 56) of the IP address of the UE 1A to the URN 2A (step S206).
  • URN2A acquires the prefix part (Prefix / 56) of IP address of UE1A (step S208).
  • the P-GW 6 transmits a route setup (Route Setup) for associating the identification information (URN_ID) of the URN 2A with the prefix part (Prefix / 56) to the S-GW 5 (step S210).
  • the S-GW 5 transfers this route setup to the MME 7 (step S212).
  • the MME 7 transfers this route setup to the DeNB 3 (step S214).
  • the UE 1A transmits an attach request (Attach Request (PCO IP Address Request)) to the MME 7 (step S216).
  • the UE 1A performs identification, authentication, encryption, etc.
  • the MME 7 transmits a location request (Location Request) to the HSS 8 (step S220).
  • the HSS 8 transmits a location request response (Location Request Response) to the MME 7 (step S222).
  • the MME 7 transmits a bearer request to the S-GW 5 (step S224).
  • the S-GW 5 performs bearer establishment procedures with the PCRF 9 and the P-GW 6 (step S226).
  • the S-GW 5 transmits a bearer request response to the MME 7 (step S228).
  • the MME 7 transmits a radio bearer request (Radio Bearer Request) including an attach approval (Attach Accepted) and an interface ID (UE-Interface ID) of the UE 1A to the DeNB 3 (step S230).
  • the DeNB 3 transmits a radio bearer request (Radio Bearer Request) including an attachment approval (Attach Accepted) and an interface ID (UE-Interface ID) of the UE 1A to the URN 2A (Step S232).
  • the URN 2A transmits a radio bearer request (Radio Bearer Request) including an attachment approval (Attach Accepted) and an interface ID (UE-Interface ID) of the UE 1A to the UE 1A (step S234).
  • the UE 1A acquires its own interface identifier (UE Interface ID) (step S236).
  • UE1A transmits a radio bearer response (Radio Bearer Response) to URN2A (step S238).
  • the URN 2A transmits a radio bearer response to the DeNB 3 (step S240).
  • the DeNB 3 transmits a radio bearer response (Radio Bearer Response) to the MME 7 (step S242).
  • the UE 1A transmits an attachment complete (Attach Complete) to the MME 7 (step S244).
  • UE1A can transmit uplink user plane traffic data to PDN10 via URN2A, DeNB3, S-GW5, and P-GW6 (step S246).
  • the MME 7 transmits a bearer update request to the S-GW 5 (step S248).
  • the S-GW 5 performs a bearer update procedure with the PCRF 9 and the P-GW 6 (step S250).
  • the S-GW 5 transmits a bearer update response to the MME 7 (step S252).
  • the downlink user plane traffic data can be transmitted from the PDN 10 to the UE 1A via the P-GW 6, S-GW 5, DeNB 3, and URN 2A (step S254).
  • the UE 1A transmits an RS message (Router Solicitation Message) to the URN 2A (step S256).
  • URN 2A transmits an RA message (Router Advertisement Message) including prefix / 64 to UE 1A (step S258).
  • the UE 1A generates its own IPv6 address (UE IPv6 Address) composed of the prefix / 64 and the interface identifier (step S260).
  • IP Address Assignment for Nested URN Next, IP address assignment for nested URN2 will be described.
  • FIG. 18 to FIG. 21 are sequence diagrams showing an example of the flow of IP address assignment processing to the URN 2B connected to the URN 2A and the UE 1B connected to the URN 2B according to the present embodiment.
  • This sequence involves UE1B, URN2B, URN2A, DeNB3, S-GW5, P-GW6, MME7 and HSS8, and PCRF9.
  • the URN 2A completes connection to the network and has acquired an IP address, for example, by the procedure described above with reference to FIG. 15 (step S302).
  • the URN 2A transmits a DHCP-PD request (DHCP_PD Request) requesting the prefix part (Prefix / 56) of the IP address of the URN 2B to the P-GW 6 (step S304).
  • the P-GW 6 transmits a DHCP-PD response (DHCP_PD Response) including the prefix part (Prefix / 56) of the IP address of the URN 2B to the URN 2A (Step S306).
  • the URN 2A acquires the prefix part (Prefix / 56) of the IP address of the URN 2B (Step S308).
  • the P-GW 6 transmits a route setup (Route Setup) for associating the identification information (URN_ID) of the URN 2B with the prefix part (Prefix / 56) to the S-GW 5 (step S310).
  • the S-GW 5 transfers this route setup to the MME 7 (step S312).
  • the MME 7 transfers this route setup to the DeNB 3 (step S314).
  • the URN 2B transmits an attach request (Attach Request (PCO IP Address Request)) to the MME 7 (step S316).
  • the URN 2B performs identification, authentication, encryption, etc. (Identification / Authentication / Ciphered option etc.) with the URN 2A, DeNB 3, MME 7, and HSS 8 (step S318).
  • the MME 7 transmits a location request (Location Request) to the HSS 8 (step S320).
  • the HSS 8 transmits a location request response (Location Request Response) to the MME 7 (step S322).
  • the MME 7 transmits a bearer request to the S-GW 5 (step S324).
  • the S-GW 5 performs bearer establishment procedures with the PCRF 9 and the P-GW 6 (step S326).
  • the S-GW 5 transmits a bearer request response (Bearer Request Response) to the MME 7 (step S328).
  • the MME 7 transmits a radio bearer request (Radio Bearer Request) including an attach approval (Attach Accepted) and an interface ID (URN Interface ID) of the URN 2B to the DeNB 3 (step S330).
  • the DeNB 3 transmits a radio bearer request (Radio Bearer Request) including an attach approval (Attach Accepted) and an interface ID (URN Interface ID) of the URN 2B to the URN 2A (step S332).
  • the URN 2A transmits a radio bearer request (Radio Bearer Request) including an attachment approval (Attach Accepted) and an interface ID (URN Interface ID) of the URN 2B to the URN 2B (Step S334).
  • the URN 2B acquires its own interface identifier (URN Interface ID) (step S336).
  • the URN 2B transmits a radio bearer response (Radio Bearer Response) to the URN 2A (step S338).
  • the URN 2A transmits a radio bearer response to the DeNB 3 (step S340).
  • the DeNB 3 transmits a radio bearer response (Radio Bearer Response) to the MME 7 (step S342).
  • the URN 2B transmits attach complete (Attach Complete) to the MME 7 (step S344).
  • the URN 2B can transmit uplink user plane traffic data to the PDN 10 via the URN 2A, DeNB 3, S-GW 5, and P-GW 6 (step S346).
  • the MME 7 transmits a bearer update request to the S-GW 5 (step S348).
  • the S-GW 5 performs a bearer update procedure with the PCRF 9 and the P-GW 6 (step S350).
  • the S-GW 5 transmits a bearer update response to the MME 7 (step S352). This enables downlink user plane traffic data to be transmitted from the PDN 10 to the URN 2B via the P-GW 6, S-GW 5, DeNB 3, and URN 2A (step S354).
  • the URN 2B transmits an RS message (Router Solicitation Message) to the URN 2A (step S356).
  • the URN 2A transmits an RA message (Router Advertisement Message) including the prefix / 64 to the URN 2B (Step S358).
  • the URN 2B generates its own IPv6 address (URN IPv6 Address) composed of the prefix / 64 and the interface identifier (step S360).
  • the UE 1B transmits an attach request (Attach Request (PCO IP Address Request)) to the MME 7 (step S402).
  • the UE 1B performs identification, authentication, encryption, and the like (Identification / Authentication / Ciphered option etc.) with the URN 2B, URN 2A, DeNB 3, MME 7, and HSS 8 (step S404).
  • the MME 7 transmits a location request (Location Request) to the HSS 8 (step S406).
  • the HSS 8 transmits a location request response (Location Request Response) to the MME 7 (step S408).
  • the MME 7 transmits a bearer request to the S-GW 5 (step S410).
  • the S-GW 5 performs bearer establishment procedures with the PCRF 9 and the P-GW 6 (step S412).
  • the S-GW 5 transmits a bearer request response to the MME 7 (step S414).
  • the MME 7 transmits a radio bearer request (Radio Bearer Request) including an attach approval (Attach Accepted) and an interface ID (UE Interface ID) of the UE 1B to the DeNB 3 (step S416).
  • the DeNB 3 transmits a radio bearer request (Radio Bearer Request) including an attachment approval (Attach Accepted) and an interface ID (UE Interface ID) of the UE 1B to the URN 2A (Step S418).
  • the URN 2A transmits a radio bearer request (Radio Bearer Request) including an attachment approval (Attach Accepted) and an interface ID (UE Interface ID) of the UE 1B to the URN 2B (Step S420).
  • the URN 2B transmits a radio bearer request (Radio Bearer Request) including an attachment approval (Attach Accepted) and an interface ID (UE Interface ID) of the UE 1B to the UE 1B (step S422).
  • the UE 1B acquires its own interface identifier (UE Interface ID) (step S424).
  • the UE 1B transmits a radio bearer response (Radio Bearer Response) to the URN 2B (step S426).
  • the URN 2B transmits a radio bearer response (Radio Bearer Response) to the URN 2A (step S428).
  • the URN 2A transmits a radio bearer response to the DeNB 3 (step S430).
  • the DeNB 3 transmits a radio bearer response (Radio Bearer Response) to the MME 7 (step S432).
  • the UE 1B transmits an attach completion (Attach Complete) to the MME 7 (step S434).
  • the UE 1B can now transmit the uplink user plane traffic data to the PDN 10 via the URN 2B, URN 2A, DeNB 3, S-GW 5, and P-GW 6 (step S436).
  • the MME 7 transmits a bearer update request to the S-GW 5 (step S438).
  • the S-GW 5 performs a bearer update procedure with the PCRF 9 and the P-GW 6 (step S440).
  • the S-GW 5 transmits a bearer update response (Bearer Update Response) to the MME 7 (step S442).
  • the PDN 10 can now transmit the downlink user plane traffic data to the UE 1B via the P-GW 6, S-GW 5, DeNB 3, URN 2A, and URN 2B (step S444).
  • the UE 1B transmits an RS message (Router Solicitation Message) to the URN 2A (step S446).
  • URN 2A transmits an RA message (Router Advertisement Message) including prefix / 64 to UE 1B (step S448).
  • the UE 1B generates its own IPv6 address (UE IPv6 Address) including the prefix / 64 and the interface identifier (step S450).
  • the prefix part may be hierarchized corresponding to a nested network.
  • the hierarchization of the prefix portion will be described.
  • FIG. 22 is a diagram for explaining hierarchization of the IPv6 prefix part according to the present embodiment.
  • the IPv6 IP address has 128 bits.
  • the upper bits are also referred to as a prefix portion, and the remaining lower bits are also referred to as an interface identifier.
  • Each length is arbitrary, but in this specification, it is assumed that both are 64 bits.
  • each of a plurality of virtual cells formed by the URN 2 or another URN 2 may be identified by a portion that is not common among the prefix portions of the 64-bit IP address.
  • the upper part 101 (56 bits in the example shown in FIG. 22) is an area to be prefix delegated by the highest URN2.
  • the middle portion 102 (2 bits in the example shown in FIG. 22) is an area for identifying a virtual network.
  • the virtual network is a nested network including a plurality of virtual cells.
  • the lower part 103 (6 bits in the example shown in FIG. 22) is an area for identifying a virtual cell in each virtual network.
  • FIG. 23 is a diagram illustrating an example of a nested network. As shown in FIG. 23, a plurality of virtual networks are connected to DeNB3.
  • the virtual network “0” is a set of virtual cells with URN2A-0 as the highest level.
  • the virtual network “1” is a set of virtual cells with URN2A-1 as the highest level.
  • the virtual network “3” is a set of virtual cells with URN2A-3 as the highest level.
  • Each of these virtual networks is identified by the middle portion 102.
  • the virtual network contains multiple virtual cells.
  • a virtual cell formed by URN2B-01 and a virtual cell formed by URN2B-02 are connected to the virtual cell formed by URN2A-0. These virtual cells may also be referred to as one-stage nested virtual cells.
  • a virtual cell formed by URN2C-0 is connected to a virtual cell formed by URN2B-02. This virtual cell may also be referred to as a two-stage nested virtual cell. Although not shown, there may be three or more nested virtual cells. These virtual cells included in one virtual network are identified by the lower part 103. The same explanation holds for other virtual networks.
  • mapping table routing table
  • FIGS. 18 to 21 In order to realize such hierarchization, among the sequences shown in FIGS. 18 to 21, the broken-line rectangle “A” part is shown in FIG. 24, and the broken-line rectangle “C” part is shown in FIG. Each of the sequences shown is replaced. 24 and 25 are sequence diagrams illustrating an example of a flow of an IP address assignment process to the URN 2B connected to the URN 2A and the UE 1B connected to the URN 2B according to the present embodiment.
  • the URN 2B transmits a DHCP-PD request (DHCP_PD Request) requesting the prefix part (Prefix / 60) of its own IP address to the URN 2A (step S356A).
  • the URN 2A transmits a DHCP-PD response (DHCP_PD Response) including the prefix part (Prefix / 60) of the IP address of the URN 2B to the URN 2B (Step S358A).
  • the URN 2B creates a Prefix / 64 by specifying, for example, a lower bit of “0000” in the obtained prefix part (Prefix / 60), and creates its own IPv6 address (prefix / 64 and interface identifier) ( URN IPv6 Address is generated (step S360A).
  • the URN2B uses the lower 4 bits of the prefix part (Prefix / 60) of the IP address acquired in step S358A to layer the subordinate URN2C and the like. For example, when the URN 2B allocates different lower 4 bits for each subordinate virtual cell and receives a DHCP_PD request message from the subordinate URN 2C or the like, the prefix part (Prefix / 64 ) Is returned. For this reason, the UE 1 receives the designation of the prefix part (Prefix / 64) of the IP address from the URN 2 to which it is connected, not the highest URN 2 in the virtual network. The sequence in this case is as shown in FIG.
  • UE1B transmits RS message (Router Solicitation Message) to URN2B (step S446A).
  • the URN 2B transmits an RA message (Router Advertisement Message) including the hierarchical prefix / 64 to the UE 1B (step S448A).
  • the UE 1B generates its own IPv6 address (UE IPv6 Address) including the prefix / 64 and the interface identifier (step S450A).
  • FIG. 26 is a diagram illustrating an example of a bearer and a TFT (Traffic Flow Template) set between UE1 and P-GW6.
  • TFT Traffic Flow Template
  • the transmission line set between the URN2 and the P-GW6 is in the section between the URN2 and the P-GW6. It may be diverted.
  • the transmission path may be a bearer, or may be an IP flow if it is a bearerless network.
  • the bearer from the P-GW 6 established by the broken rectangle “B-2” to the UE 1B is the P-GW 6 established by the broken rectangle “B-1”.
  • To URN2A may be used.
  • the bearers of the UE1 group connected to the URN2, that is, the UE1 group having a common prefix portion of the IP address can be aggregated, and the signaling amount associated with the bearer establishment can be greatly reduced.
  • the bearer configuration of such a virtual cell will be described with reference to FIG.
  • FIG. 27 is a diagram illustrating an example of a bearer configuration of a virtual cell.
  • a default bearer and a dedicated bearer are established between URN2 and UE1.
  • an individual default bearer and dedicated bearer for each UE 1 are not established between the UE 1 and the P-GW 6.
  • a default bearer and a dedicated bearer established between URN2 and UE1 are mapped to a dedicated bearer established between URN2 and P-GW6.
  • UE1 can use the dedicated bearer established by URN2 of the connection destination with P-GW6 without individually establishing bearers from URN2 to P-GW6.
  • one dedicated bearer established between URN 2 and P-GW 6 may be diverted (that is, shared) by a plurality of UEs 1 under its control, or may be diverted individually by one UE 1.
  • each of the default bearer of UE1 group and the dedicated bearer of “Policy-1” is mapped to one dedicated bearer established between URN2 and P-GW6.
  • each of the default bearers “# 1” and “#m” of the UE1 group is mapped to a different dedicated bearer established between the URN 2 and the P-GW 6.
  • the URN2 uses its own default bearer individually.
  • the URN 2 may establish and secure a plurality of dedicated bearers for each policy, such as a band or QoS, for the subordinate UE 1 or the subordinate URN 2.
  • the UE 1 may establish a bearer with the P-GW 6 without diverting the bearer established between the URN 2 and the P-GW 6.
  • the proposed protocol can also be applied to the next generation network architecture that does not conform to the existing 3GPP EPC. Such an architecture will be described with reference to FIGS.
  • FIG. 28 and 29 are diagrams illustrating an example of the architecture of the next generation network.
  • FIG. 28 shows a bearerless network architecture realized by a so-called pure IP network. In this case, the IP flow plays the role of the bearer. Also in this architecture, by sharing the prefix part, it is possible to realize the IP transparency of the UE1 group connected to the URN2 without a mechanism such as mobile IP.
  • FIG. 29 illustrates an architecture in which the control plane and the user plane are separated using the cloud.
  • FIG. 30 is a diagram for explaining the handling of an IP address at the time of handover.
  • UE1 is first connected to eNB4.
  • the handover indicated by reference numeral 111 is a handover of UE1.
  • the handover indicated by reference numerals 112 to 114 is a URN2A handover.
  • the procedure for the handover of the relay node is not clearly defined in 3GPP.
  • (1) Handover indicated by reference numeral 111 The UE1 hands over from the eNB4 to the URN2A.
  • UE1 has already acquired an IP address by the attach procedure performed at the time of connection to eNB4. Therefore, UE1 continues to use the IP address acquired before the handover after the handover according to the 3GPP handover framework. Therefore, the UE 1 uses an IP address different from the IP address having a common prefix part (Prefix / 56) assigned to the UE that is first connected to the virtual cell of the URN 2A after the handover.
  • Prefix / 56 a common prefix part assigned to the UE that is first connected to the virtual cell of the URN 2A after the handover. Note that the EPS bearer up to P-GW 6 is updated by the attach procedure.
  • the UE 1 stores the time when the attach procedure to the URN 2A is completed. . Then, the UE 1 uses the IP address newly assigned after the handover (that is, the first network layer IP address) for the socket opened after the time when the stored attachment procedure to the URN 2A is completed. On the other hand, the UE 1 continuously uses the IP address assigned before the handover (that is, the second network layer IP address) to the socket opened before the time when the attachment procedure to the stored URN 2 is completed. Use. Therefore, if the socket opened before the stored time is closed, the use of the IP address acquired before the handover is ended.
  • the UE 1 can use a new IP address as time elapses after the handover, and can enjoy merits such as sharing of bearers and use of a mapping table described later.
  • the UE 1 may notify the connected URN 2A of information indicating that the socket using the IP address assigned before the handover is closed, that is, that the use of the IP address assigned before the handover is finished. Good.
  • the amount of information in a mapping table, which will be described later can be reduced, and the hierarchy of routing within the virtual cell is realized.
  • the URN 2A positioned at the top of the virtual cell uses a bearer that has been established and secured in advance for the UE 1 group in the virtual cell by the attach procedure.
  • the bearer is updated in the MME 7 by the attach procedure, and a dedicated EPS bearer is established for each UE1 and each URN2.
  • Each bearer is established by mapping with GID (GPRS (General Packet Radio Service) Tunneling Protocol) TEID (Tunnel Endpoint Identifier) and radio bearer ID.
  • GID General Packet Radio Service
  • TEID Tunneling Protocol
  • radio bearer ID the mapping table managed by P-GW 6, S-GW 5, DeNB 3 and URN 2 will be described in detail later.
  • the URN 2A performs handover from the DeNB 3A to the DeNB 3B.
  • This handover is a handover using a logical path (X2 Interface) between the DeNBs 3 without switching the S-GW 5.
  • URN2A behaves as UE1, and inter-base station handover from DeNB3A to DeNB3B is performed.
  • the URN2A continues to use the IP address assigned before the handover even after the handover according to the 3GPP handover framework. Accordingly, the UE1 group under the control of the URN 2A also continues to use the IP address assigned before the handover even after the handover of the URN 2A.
  • the URN 2 may notify the subordinate UE 1 group of information indicating that the URN 2 itself starts handover (or is trying) (for example, step S514 in FIG. 31). Further, the URN 2 may notify the subordinate UE 1 group of information indicating that the URN 2 itself has completed the handover (for example, step S544 in FIG. 32).
  • the subordinate apparatus can be prevented from shifting to the handover to another URN 2 during the handover of the URN 2A. For example, when UE1 is notified that the connected URN2A will perform handover, UE1 starts a handover timer and the like, and suppresses the procedure for attaching to another network for a predetermined period after URN2 starts handover. Also good. Thereby, signaling related to unnecessary handover procedures can be suppressed. After the handover is completed, there is no need for each UE1 group in the virtual cell to try the attach procedure.
  • 31 and 32 are sequence diagrams showing an example of the flow of handover processing by URN 2 according to the present embodiment.
  • UE1 group, URN2A, DeNB3A, DeNB3B, MME7, S-GW5 and P-GW6 are involved.
  • UE1 group and URN2A form the virtual cell.
  • DeNB3A is the source DeNB and DeNB3B is the target DeNB.
  • UE1 group, URN2A, DeNB3A, S-GW5A and P-GW6 are in a state of transmitting and receiving uplink and downlink user plane traffic data (step S502).
  • the URN 2A transmits a measurement report (RCC-URN: Measurement Report) to the DeNB 3A (step S504).
  • the DeNB 3A performs a handover decision (Step S506).
  • the DeNB 3A transmits a handover request (X2-AP: Handover Request) to the DeNB 3B (step S508).
  • the DeNB 3B transmits a handover request ACK (X2-AP: Handover Request Ack) to the DeNB 3A (step S510).
  • the DeNB 3A transmits a handover command (RCC-URN: Handover Command) to the URN 2A (step S512).
  • the URN 2A transmits a handover notification (RCC-UEs: Handover Notification) to the subordinate UE 1 group (step S514).
  • RRC-UEs Handover Notification
  • the UE1 group starts the handover timer, holds the state (UEs State Hold / HO-Timer Start), and suppresses handover to another URN2 (step S516).
  • the DeNB 3A performs data transfer (Forwarding of data) to the DeNB 3B for handover execution (Handover Execution) (step S518).
  • the DeNB 3B transmits downlink data to the URN 2A in order to complete handover (Handover Completion) (step S520).
  • the URN 2A can transmit the uplink user plane traffic data to the P-GW 6 via the DeNB 3B and the S-GW 5A (Step S522).
  • the DeNB 3B transmits a path switch request to the MME 7 (step S524).
  • the MME 7 transmits a modify bearer request to the S-GW 5A (step S526).
  • the S-GW 5A performs a modify bearer procedure with the P-GW 6 (step S528).
  • the S-GW 5A transmits a bearer change response (Modify Bearer Response) to the MME 7 (step S530).
  • the P-GW 6 can transmit the downlink user plane traffic data to the URN 2A via the S-GW 5A and the DeNB 3B (step S532).
  • the S-GW 5A transmits an end marker (End Marker) to the DeNB 3A (step S534).
  • the DeNB 3A transmits an end marker (End Marker) to the DeNB 3B (step S536).
  • the MME 7 transmits a path switch request ACK (Path Switch Request Ack) to the DeNB 3B (step S538).
  • the DeNB 3B transmits a release resource (Release Resource) to the DeNB 3A (step S540).
  • the URN 2A performs a tracking and address update procedure (Tracking / Address / etc. Update Procedures) with the DeNB 3B and the MME 7 (step S542).
  • the URN 2A transmits handover completion (RCC-UEs: Handover Completion) to the subordinate UE 1 group (step S544).
  • the UE1 group stops the handover timer and releases the state (UEs State Release / HO-Timer Stop) (step S546).
  • the UE1 group, URN2A, DeNB3B, S-GW5A, and P-GW6 transmit and receive uplink and downlink user plane traffic data (step S548).
  • Handover indicated by reference numeral 113 The URN 2A performs handover from the DeNB 3A to the URN 2B.
  • the handover here can be performed by the same procedure as the handover indicated by reference numeral 112 described above with reference to FIGS. 31 and 32.
  • URN2A continues to use the IP address assigned before the handover after the handover according to the 3GPP handover framework. Accordingly, the UE1 group under the control of the URN 2A also continues to use the IP address assigned before the handover even after the handover of the URN 2A.
  • the URN 2A may notify the subordinate UE 1 group that it is attempting handover and a handover completion report.
  • the operation of the subordinate UE1 group is also as described above.
  • the URN 2A performs handover from the URN 2B to the DeNB 3C.
  • This handover is a handover using a logical path (X2 Interface) between the DeNBs 3 including a change from the S-GW 5A to the S-GW 5B.
  • URN2A behaves as UE1, and handover between base stations from URN2B to DeNB3C is performed.
  • the 3GPP mechanism is applied with URN2B as the source DeNB and DeNB3C as the target DeNB. That is, the handover here can also be performed by the same procedure as each handover described above.
  • URN2A continues to use the IP address assigned before the handover after the handover according to the 3GPP handover framework. Accordingly, the UE1 group under the control of the URN 2A also continues to use the IP address assigned before the handover even after the handover of the URN 2A.
  • the URN 2A may notify the subordinate UE 1 group that it is attempting handover and a handover completion report.
  • the operation of the subordinate UE1 group is also as described above.
  • FIG. 33 and 34 are sequence diagrams showing an example of the flow of handover processing by the URN 2 according to the present embodiment.
  • UE1 group, URN2A, URN2B, DeNB3C, MME7, S-GW5A, S-GW5B and P-GW6 are involved.
  • UE1 group and URN2A form the virtual cell.
  • URN2B is a source DeNB and DeNB3C is a target DeNB.
  • S-GW 5A is a source S-GW
  • S-GW 5B is a target S-GW.
  • UE1 group, URN2A, URN2B, S-GW5A and P-GW6 are set in an initial state in which uplink and downlink user plane traffic data can be transmitted and received (step S602).
  • the URN 2A transmits a measurement report (RCC-URN: Measurement Report) to the URN 2B (step S604).
  • the URN 2B performs a handover decision (Handover Decision) (step S606).
  • the URN 2B transmits a handover request (X2-AP: Handover Request) to the DeNB 3C (step S608).
  • the DeNB 3C transmits a handover request ACK (X2-AP: Handover Request Ack) to the URN 2B (step S610).
  • the URN 2B transmits a handover command (RCC-URN: Handover Command) to the URN 2A (step S612).
  • the URN 2A transmits a handover notification (RCC-UEs: Handover Notification) to the subordinate UE 1 group (step S614).
  • the UE1 group starts the handover timer, holds the state (UEs State Hold / HO-Timer Start), and suppresses handover to another URN2 (step S616).
  • the URN 2B performs data transfer (Forwarding of data) to the DeNB 3C in order to execute handover (Handover Execution) (Step S618).
  • the DeNB 3C transmits downlink data to the URN 2A in order to complete handover (Handover Completion) (step S620).
  • the URN 2A can transmit the uplink user plane traffic data to the P-GW 6 via the DeNB 3C and the S-GW 5A (step S622).
  • the DeNB 3C transmits a path switch request to the MME 7 (step S624).
  • the MME 7 transmits a session creation request (Create Session Request) to the S-GW 5B (step S626).
  • the S-GW 5B performs a modify bearer procedure with the P-GW 6 (step S628).
  • the S-GW 5B transmits a session creation response (Create Session Response) to the MME 7 (step S630).
  • the P-GW 6 transmits downlink user plane traffic data to the URN 2A via the S-GW 5B and the DeNB 3C (step S632).
  • the MME 7 transmits a path switch request ACK (Path Switch Request Ack) to the DeNB 3C (step S634).
  • URN 2A transmits uplink user plane traffic data to P-GW 6 via DeNB 3C and S-GW 5B (step S636).
  • the DeNB 3C transmits a release resource (Release Resource) to the URN 2B (step S638).
  • the MME 7 transmits a delete session request (Delete Session Request) to the S-GW 5A (S640).
  • the S-GW 5A transmits a delete session response (Delete Session Response) to the MME 7 (S642).
  • the URN 2A performs a tracking and address update procedure (Tracking / Address / etc. Update Procedures) with the DeNB 3C and the MME 7 (step S644).
  • the URN 2A transmits handover completion (RCC-UEs: Handover Completion) to the subordinate UE 1 group (step S646).
  • the UE1 group stops the handover timer and releases the state (UEs State Release / HO-Timer Stop) (step S648).
  • the UE1 group, URN2A, DeNB3C, S-GW5B and P-GW6 can transmit and receive uplink and downlink user plane traffic data (step S650).
  • the handover procedure using the X2 interface has been described above. Needless to say, the handover procedure using the S1 interface may be used. As an example, processing when the handover indicated by reference numeral 114 is performed using the S1 interface will be described with reference to FIGS.
  • 35 and 36 are sequence diagrams showing an example of the flow of the handover process by the URN 2 according to the present embodiment.
  • UE1 group, URN2A, URN2B, DeNB3C, MME7A, MME7B, S-GW5A, S-GW5B and P-GW6 are involved.
  • UE1 group and URN2A form the virtual cell.
  • URN2B is a source DeNB and DeNB3C is a target DeNB.
  • S-GW 5A is a source S-GW
  • S-GW 5B is a target S-GW.
  • MME7A is a source MME and MME7B is a target MME.
  • UE1 group, URN2A, URN2B, S-GW5A and P-GW6 are set in an initial state in which uplink and downlink user plane traffic data can be transmitted and received (step S702).
  • the URN 2A transmits a measurement report (RCC-URN: Measurement Report) to the URN 2B (step S704).
  • the URN 2B performs handover determination (Handover Decision via S1) using the S1 interface (step S706).
  • the URN 2B transmits a handover request (S1-AP: Handover Required) to the MME 7A (step S708).
  • the MME 7A transmits a forward relocation request to the MME 7B (step S710).
  • the MME 7B transmits a session creation request (Create Session Request) to the S-GW 5B (step S712).
  • the S-GW 5B transmits a session creation response (Create Session Response) to the MME 7B (step S714).
  • the MME 7B transmits a handover request (Handover Request) to the DeNB 3C (step S716).
  • the DeNB 3C transmits a handover request ACK (Handover Request Ack) to the MME 7B (step S718).
  • the MME 7B transmits an indirect data transfer tunnel generation request (Create Indirect Data Forwarding Tunnel Request) to the S-GW 5B (step S720).
  • the S-GW 5B transmits an indirect data transfer tunnel generation response (Create Indirect Data Forwarding Tunnel Response) to the MME 7B (step S722).
  • the MME 7B transmits a forward relocation response (Forward Relocation Response) to the MME 7A (step S724).
  • the MME 7A transmits an indirect data transfer tunnel generation request (Create Indirect Data Forwarding Tunnel Request) to the S-GW 5A (step S726).
  • the S-GW 5A transmits an indirect data transfer tunnel generation response (Create Indirect Data Forwarding Tunnel Response) to the MME 7A (step S728).
  • the MME 7A transmits a handover command to the URN 2B (Step S730).
  • the URN 2B transmits a handover command (RCC-URN: Handover Command) to the URN 2A (step S732).
  • the URN 2A transmits a handover notification (RCC-UEs: Handover Notification) to the subordinate UE 1 group (step S734).
  • the UE1 group starts a handover timer, holds the state (UEs State Hold / HO-Timer Start), and suppresses handover to another URN2 (step S736).
  • the URN 2B transmits a base station status transfer (eNB Status Transfer) to the MME 7A (step S738).
  • eNB Status Transfer base station status transfer
  • the MME 7A transmits a forward access context notification (Forward Access Context Notification) to the MME 7B (step S740).
  • the MME 7B transmits a forward access context acknowledgment (Forward Access Context Acknowledge) to the MME 7A (step S742).
  • MME7B transmits base station status transfer (eNB Status Transfer) to DeNB3C (step S744).
  • the URN 2B transmits only the direct forwarding data (Only for Direct forwarding of data) to the DeNB 3C (step S746).
  • URN 2B transmits (Only for Indirect forwarding of data) to DeNB 3C via S-GW 5A and S-GW 5B (step S748).
  • URN2A performs detachment from an old cell and synchronization to a new cell (Detach from old cell and synchronize to new cell) with URN2B, DeNB3C, MME7A, and MME7B ( Step S750).
  • the URN 2A transmits a handover confirmation (Handover Confirm) to the DeNB 3C (step S752).
  • the DeNB 3C transmits downlink data to the URN 2A (Step S754).
  • the URN 2A can transmit the uplink user plane traffic data to the P-GW 6 via the DeNB 3c and the S-GW 5B (step S756).
  • the DeNB 3C transmits a handover notification (Handover Notify) to the MME 7B (step S758).
  • the MME 7B transmits a forward relocation completion notification (Forward Relocation Complete Notification) to the MME 7A (step S760).
  • the MME 7A transmits a forward relocation completion confirmation (Forward Relocation Complete Acknowledge) to the MME 7B (step S762).
  • the MME 7B transmits a modify bearer request (Modify Bearer Request) to the S-GW 5B (step S764).
  • the S-GW 5B performs a modify bearer procedure with the P-GW 6 (step S766).
  • the S-GW 5B transmits a bearer change response (Modify Bearer Response) to the MME 7B (step S768).
  • the P-GW 6 can transmit the downlink user plane traffic data to the URN 2A via the S-GW 5B and the DeNB 3C (step S770).
  • the URN 2A performs a tracking and address update procedure (Tracking / Address / etc. Update Procedures) with the URN 2B, DeNB 3C, MME 7A, and MME 7B (step S772).
  • the URN 2A transmits handover completion (RCC-UEs: Handover Completion) to the subordinate UE 1 group (step S774).
  • RRCC-UEs Handover Completion
  • the UE1 group stops the handover timer and releases the state (UEs State Release / HO-Timer Stop) (step S776).
  • the MME 7A transmits a URN context release command (URN Context Release Command) to the URN 2B (step S778).
  • the URN 2B transmits a URN context release completion (URN Context Release Complete) to the MME 7A (step S780).
  • the MME 7A transmits a delete session request (Delete Session Request) to the S-GW 5A (step S782).
  • the S-GW 5A transmits a delete session response (Delete Session Response) to the MME 7A (step S784).
  • the MME 7A transmits an Indirect Data Transfer Tunnel Delete Request (Delete Indirect Data Forwarding Tunnel Request) to the S-GW 5A (Step S786).
  • the S-GW 5A transmits an indirect data transfer tunnel deletion response (Delete Indirect Data forwarding Tunnel Response) to the MME 7A (step S788).
  • the MME 7B transmits an indirect data transfer tunnel deletion request (Delete Indirect Data forwarding Tunnel Request) to the S-GW 5B (step S790).
  • the S-GW 5B transmits an indirect data transfer tunnel deletion response (Delete Indirect Data forwarding Tunnel Response) to the MME 7B (step S792).
  • the network device is usually given an EPC transport layer IP address.
  • the mobility of network devices has not been considered. Assuming that URN2 behaves as UE1, it may be difficult to assign a transport layer IP address to URN2 in advance. Therefore, a mechanism such as a so-called auto configuration in which a transport layer IP address is automatically assigned at the time of network connection is conceivable. As described above, in consideration of autoconfiguration and mobility of URN2, it is assumed that the transport layer IP address is changed after the movement.
  • the ID that identifies itself (for example, the eNB ID assigned to the IMSI or the URN 2) is set as the IPv6 interface identifier.
  • URN2 acquires Prefix / 64 by RS message and RA message with connected DeNB3 using an IPv6 link local address. Then, the URN 2 may generate its own transport layer IP address by combining the set IPv6 interface identifier and the acquired Prefix / 64.
  • the URN 2 may continue to use the transport layer IP address generated in this way even after handover. Moreover, URN2 may generate a new transport layer IP address by the same method at every handover.
  • the handover here may mean that the connection-destination DeNB 3 changes or the connection-destination URN 2 changes.
  • step S806 in FIG. 38, which will be described later, and step S1106 in FIG. 41 are examples of the above-described autoconfiguration.
  • a network layer IP address is assigned to URN2. Therefore, IP mobility is realized. Moreover, URN2 can use the IP application in the same manner as UE1. Furthermore, D2D communication using the network layer IP address between UE1-UE1, UE1-URN2, or URN2-URN2 is easily realized.
  • a transport layer IP address can be dynamically assigned to URN 2 that is used by an end user each time URN 2 is connected to the network or at every handover. Therefore, even when the URN 2 moves, network maintenance, bearer establishment by the MME 7 and the like can be performed in the same manner as other EPC devices, as in the fixed RN.
  • UE1 connected to URN2 can omit the connection process again even when URN2 is handed over. Therefore, the UE 1 can receive paging and use a push application without performing location registration update (Tracking Area Update). Thereby, the amount of signaling (for example, tracking area update message) from UE1 under URN2 can be greatly reduced. Thereby, reduction of the signaling message accompanying movement from the wearable device group connected to the virtual cell or the UE1 connected to the virtual cell formed in the moving vehicle is realized.
  • location registration update Tracking Area Update
  • URN2 can capture UE1 and URN2 having addresses other than the common Prefix / 56 used in the subordinate virtual cell into the virtual cell. Therefore, a terminal that is already connected to the network can be taken into the virtual cell.
  • Second Embodiment >> In the present embodiment, the first embodiment will be described in detail from the viewpoint of mapping table generation and update.
  • FIG. 37 is a diagram showing a network configuration example according to the present embodiment.
  • the present system includes a virtual cell formed by P-GW 6, S-GW 5A, S-GW 5B, MME 7, DeNB 3A, DeNB 3B, and URN 2A.
  • the virtual cell formed by URN2A includes URN2B that forms a nested virtual cell to which UE1A and UE1B and UE1C connect, URN2C that forms a nested virtual cell to which UE1D connects, and a nested virtual cell to which UE1E connects.
  • the URN 2D to be formed can be connected.
  • IP D PGW The IPv6 address of the interface downstream of the P-GW is represented as IP D PGW .
  • the IPv6 addresses of the upstream and downstream interfaces of the S-GW are represented as IP U SGW and IP D SGW , respectively.
  • IP U SGW and IP D SGW The IPv6 address of the upstream or downstream interface of the DeNB.
  • IP U DeNB The IPv6 address of the upstream or downstream interface of the DeNB is expressed as IP U DeNB and IP D DeNB , respectively.
  • URN2 operates as eNB, indicating the IPv6 address for connecting to the upstream DeNB and IP U U URN in S1-U interface.
  • URN2 operates as a UE, and an IPv6 address used by an application on the URN is represented as IP UE URN .
  • An IPv6 address used when URN2 operates as a mobile router and communicates with a device in a downstream virtual cell is represented as IP D URN .
  • FIG. 38 is a sequence diagram illustrating an example of a flow of connection processing to the DeNB 3A by the URN 2A according to the present embodiment. This sequence involves URN 2A, DeNB 3A, MME 7, S-GW 5A, and P-GW 6.
  • the URN 2A establishes a radio channel with the DeNB 3A (step S802).
  • the URN 2A transmits an RS (Router Solicitation) to the link local all-routers multicast address (step S804).
  • the source address of this RS is the link local IPv6 address of URN2A.
  • the DeNB 3A receives this RS and transmits an RA (Router Advertisement) addressed to the link local IPv6 address of the URN 2A (step S806).
  • This RA includes the upper 64 bits (prefix) of the IP D DeNB 3A .
  • the URN 2A receives this RA and generates an IPv6 address IP U URN 2A (step S808).
  • IP U URN2A is used when URN2A establishes a GTP tunnel with DeNB3A.
  • the URN 2A transmits an attach request to the DeNB 3A (step S810).
  • This attach request includes the identifier ID URN2A of URN2A and IP U URN2A .
  • the DeNB 3A transfers it to the MME 7 (step S812).
  • the MME 7 transmits a default bearer generation request (Create Default Bearer Request) to the S-GW 5A (step S814).
  • the default bearer generation request includes ID URN2A and IP U URN2A .
  • the S-GW 5A transfers it to the P-GW 6 (step S816).
  • IP UE URN2A is an IPv6 address used by an application when URN2A operates as a UE.
  • the P-GW 6 forms a GTP tunnel with the S-GW 5A, and associates the transfer destination of the IP UE URN 2A with this GTP tunnel. This association is stored as a mapping table.
  • the end points of this GTP tunnel are IP D PGW 6 and IP U SGW 5A .
  • the P-GW 6 transmits a default bearer response (Create Default Bearer Response) to the S-GW 5A (step S820).
  • This default bearer generation response includes ID URN2A , IP UE URN2A, and IP D PGW6 .
  • the S-GW 5A transfers it to the MME 7 (step S822).
  • the S-GW 5A forms a GTP tunnel with the P-GW 6.
  • the end points of this GTP tunnel are IP U SGW 5A and IP D PGW 6 .
  • the S-GW 5A forms a GTP tunnel with the DeNB 3A , and associates the IP UE URN 2A with this GTP tunnel. This association is stored as a mapping table.
  • the end points of this GTP tunnel are IP D SGW 5A and IP U DeNB 3A .
  • the MME 7 transmits an attach accept to the DeNB 3A (step S824).
  • the attach accept includes ID URN2A , lower 64 bits (if-id: interface identifier) of IP UE URN2A , and IP D PGW6 .
  • the DeNB 3A transfers it to the URN 2A (step S826).
  • the DeNB 3A configures a GTP tunnel with the S-GW 5A.
  • the end points of this GTP tunnel are IP U DeNB 3A and IP D SGW 5A .
  • the DeNB 3A forms a GTP tunnel with the URN 2A , and associates the transfer destination of the IP UE URN 2A with this GTP tunnel. This association is stored as a mapping table.
  • the end points of this GTP tunnel are IP D DeNB 3A and IP U URN 2A .
  • the URN 2A receives this attach accept and obtains the lower 64 bits (if-id) of the IP UE URN 2A .
  • GTP tunnels are generated between P-GW 6 and S-GW 5A, between S-GW 5A and DeNB 3A, and between DeNB 3A and URN 2A (step S828).
  • the URN 2A transmits an RS to the P-GW 6 in accordance with the IPv6 regulations in order to obtain an IPv6 address IP UE URN2A for operating as a UE (step S830).
  • the P-GW 6 receives this RS and returns an RA to the URN 2A (step S832).
  • This RA includes the upper 64 bits (prefix) of IP UE URN2A .
  • the URN 2A then receives this RA and obtains the upper 64 bits (prefix) of the IP UE URN 2A . And URN2A produces
  • the URN 2A executes DHCP-PD (Prefix Delegation) with the P-GW 6 (step S836).
  • the URN 2A obtains an IPv6 address prefix Pref URN2A (for example, an IPv6 address space of / 60) (step S838).
  • the P-GW 6 associates the forwarding destination of the Pref URN 2A with the GTP tunnel to the S-GW 5A. This association is stored by a mapping table.
  • the URN 2A selects the IPv6 address IP D URN 2A from the space of the Pref URN 2A .
  • IP D URN2A is assigned to an interface downstream of URN2A.
  • This route setup message is information for associating the prefixes Pref URN2A and URN2A of the IPv6 address, and is notified to devices (for example, S-GW 5A, DeNB3A, etc.) that relay communication between URN2A and P-GW6.
  • the Specifically, this route setup message includes information for associating the forwarding destination of Pref URN2A with IP UE URN2A .
  • the S-GW 5A associates the forwarding destination of the Pref URN 2A with the IP UE URN 2A (step S842). Then, the S-GW 5A relays the route setup message to the MME 7.
  • the MME 7 transfers the message to the DeNB 3A (step S844).
  • the DeNB 3A associates the transfer destination of the Pref URN 2A with the IP UE URN 2A .
  • the P-GW 6, S-GW 5A, and DeNB 3A store the mapping tables shown in Table 2, Table 3, and Table 4, respectively.
  • the mapping table will be described. For example, according to the first line of entries in Table 2, a packet of IP UE URN2A addressed, is described in the destination field of the entry end point IPv6 addresses and IP UE URN2A "GTP SGW5A" (i.e., SGW5A Destination GTP tunnel). As a result, the packet is transferred to the S-GW 5A. Then, according to the first line of entries in Table 3, a packet of IP UE URN2A addressed, is described in the destination field of the entry end point IPv6 addresses and IP UE URN2A "GTP DeNB3A" (i.e., the DeNB3A addressed GTP tunnel). Thereby, the packet is transferred to the DeNB 3A.
  • GTP SGW5A i.e., SGW5A Destination GTP tunnel
  • a packet whose destination IP address has a prefix part Pref URN2A has an end point IPv6 address based on “refer to IP UE URN2A ” described in the forwarding destination column. It is transferred to “GTP SGW5A ”, which is the transfer destination of the entry in the first row as IP UE URN2A . As a result, the packet is transferred to the S-GW 5A. Further, according to the entry in the second row of Table 3, a packet whose destination IP address has a prefix part Pref URN2A has an end point IPv6 address based on “refer to IP UE URN2A ” described in the forwarding destination column.
  • GTP DeNB3A which is the transfer destination of the entry in the first row as IP UE URN2A .
  • the packet is transferred to the DeNB 3A.
  • a packet whose destination IP address has a prefix part Pref URN2A has an end point IPv6 address based on “refer to IP UE URN2A ” described in the forwarding destination column.
  • It is transferred to “GTP URN2A ”, which is the transfer destination of the entry in the first row as IP UE URN2A .
  • the packet is transferred to the URN 2A. In this way, each entity can refer to the stored mapping table and appropriately forward the packet to reach the destination.
  • each entity (P-GW6, S-GW5, DeNB3, etc.) associates and stores the prefix portion assigned to the terminal (UE1 or URN2) connected to URN2 and URN2. By referring to this association, each entity can transmit a packet for a terminal under URN2 to URN2, and finally reach each terminal.
  • FIG. 39 is a sequence diagram showing an example of a flow of connection processing to the URN 2A by the UE 1A according to the present embodiment.
  • UE1A, URN2A, DeNB3A, MME7, S-GW5A, and P-GW6 are involved.
  • the UE 1A establishes a radio channel with the URN 2A (step S902).
  • UE1A transmits an attach request to URN2A.
  • This attach request includes the identifier ID UE1A of the UE1A (step S904).
  • the URN 2A transmits an attach accept to the UE 1A (Step S906).
  • This attach accept includes lower 64 bits (if-id) for the UE 1A to configure the IP UE 1A and the IP D URN 2A .
  • UE1A receives this attach accept and obtains the lower 64 bits of IP UE1A .
  • UE1A transmits RS to URN2A (step S908).
  • the URN 2A transmits an RA including the upper 64 bits (prefix) of the IP D URN 2A to the UE 1A (step S910).
  • the UE 1A receives the RA and generates an IP UE 1A (step S912).
  • the URN 2A waits for a certain amount of time (for example, 1 second), and during that time, attach requests related to the UE 1 connected downstream of the URN 2A are collectively transmitted to the DeNB 3A (step S914). That is, the URN 2A can avoid sending an attach request every time the UE 1 is connected downstream of the URN 2A by sending attach requests for a plurality of UEs 1 at a time.
  • the attach request includes an identifier (for example, ID UE1A ) and an IPv6 address (for example, IP UE1A ) of the UE 1A connected to the URN 2A , and information indicating a UE connection to the virtual cell.
  • the DeNB 3A transfers it to the MME 7 (step S916).
  • the MME 7 transmits an attach accept to the DeNB 3A (step S918).
  • the DeNB 3A transfers it to the URN 2A (step S920).
  • the amount of information stored in the P-GW 6, S-GW 5A, and DeNB 3A does not depend on the number of UEs 1 that are powered on in the virtual cell provided by the URN 2.
  • FIG. 40 is a sequence diagram showing an example of a flow of connection processing to the URN 2A by the UE 1B according to the present embodiment.
  • UE1B, URN2A, DeNB3A, MME7, S-GW5A, and P-GW6 are involved.
  • the UE 1B establishes a radio channel with the URN 2A (step S1002).
  • the UE 1B transmits an attach request to the URN 2A (step S1004).
  • This attach request includes the identifier ID UE1B and the IP UE1B of the UE1B .
  • the URN 2A transmits an attach accept including the lower 64 bits (if-id) of the IP UE 1B to the UE 1B (step S1006).
  • the URN 2A generates an IPv6 address IP D2 URN 2A and assigns it to the downstream interface (step S1008). At this time, the URN 2A makes the upper 64 bits (prefix) of the IP D2 URN 2A equal to the upper 64 bits (prefix) of the IP UE 1B .
  • the UE 1B transmits an RS to the URN 2A according to the IPv6 rule (step S1010).
  • the URN 2A transmits an RA including the upper 64 bits (prefix) of the IP UE 1B and the upper 64 bits (prefix) of the IP D URN 2A to the UE 1B (step S1012).
  • UE1B receives RA and confirms that IP UE1B is usable (step S1014). Further, UE1B uses the upper 64 bits of the IP D URN2A (prefix), it generates an IPv6 address IP URN2A UE1B. IP UE1B does not belong to Pref URN2A , but IP URN2A UE1B belongs to Pref URN2A . The application that communicated before UE1B connected to URN2A continues to use IP UE1B , and the application that started communication after UE1B connected to URN2A uses IP URN2A UE1B . By doing so, the IP UE 1B is not used eventually.
  • the fact that the IP UE 1B is no longer used in the UE 1B can be detected by the following method. For example, UE1B records the time when it connected to URN2A. UE1B uses IP URN2A UE1B for sockets opened after this time. If all sockets opened before this time are closed, the IP UE 1B is not used. UE1B detects this and notifies URN2A.
  • the URN 2A waits for a certain amount of time (for example, 1 second), and during that time, attach requests relating to the UE 1 connected downstream of the URN 2A are collectively transmitted to the DeNB 3A (step S1016). That is, the URN 2A can avoid sending an attach request every time the UE 1 is connected downstream of the URN 2A by sending attach requests for a plurality of UEs 1 at a time.
  • the attach request includes an identifier (for example, ID UE1B ) and an IPv6 address (for example, IP UE1B ) of the UE1B connected to the URN2A, IP UE URN2A , ID URN2A , and information indicating a UE connection to the virtual cell.
  • the DeNB 3A transfers it to the MME 7 (step S1018).
  • the MME 7 transmits a default bearer generation request to the S-GW 5A (step S1020).
  • This default bearer generation request includes ID UE1B , IP UE1B , IP UE URN2A, and ID URN2A .
  • the S-GW 5A transfers it to the P-GW 6 (step S1022).
  • P-GW6 receives this Create Default Bearer Request, associate destination IP UE1B the IP UE URN2A, sends a Create Default Bearer Response to the S-GW5A (step S1024).
  • This default bearer generation response includes ID UE1B , IP UE1B , IP UE URN2A, and ID URN2A .
  • S-GW5A receives this Create Default Bearer Response, associate destination IP UE1B the IP UE URN2A, sends a Create Default Bearer Response to MME7 (step S1026).
  • the MME 7 transmits an attach accept to the DeNB 3A (step S1028).
  • This attach accept includes ID UE1B , IP UE1B , IP UE URN2A and ID URN2A .
  • DeNB3A receives this attach accept, associate destination IP UE1B the IP UE URN2A, it forwards the attach accept to URN2A (step S1030).
  • the P-GW 6, S-GW 5A, and DeNB 3A store the mapping tables shown in Tables 5, 6, and 7, respectively.
  • mapping table will be described.
  • an entry on the third line is newly added.
  • the packet addressed to IP UE1B is based on the “refer to IP UE URN2A ” described in the transfer destination column, and the transfer destination of the entry on the first line with the end point IPv6 address as IP UE URN2A
  • the packet is transferred to “GTP SGW5A ” by P-GW6, transferred to “GTP DeNB3A ” by S-GW5A according to Table 6, and transferred to “GTP URN2A ” by DeNB3A according to Table 7. Transferred.
  • the packet is transferred to the URN 2A.
  • the packet is transferred from URN 2A to UE 1B.
  • FIG. 41 is a sequence diagram illustrating an example of a flow of connection processing to the URN 2A by the URN 2B according to the present embodiment.
  • URN 2B, URN 2A, DeNB 3A, MME 7, S-GW 5A, and P-GW 6 are involved.
  • URN 2B establishes a radio line with URN 2A (step S1102).
  • the URN 2B transmits the RS to the link local all-routers multicast address (step S1104).
  • the source address of this RS is the link local address of URN2B.
  • URN 2A transmits RA to the link local address of URN 2B (step S1106).
  • This RA includes the upper 64 bits (prefix) of IP D URN2A and information indicating that URN2A exists in the virtual cell.
  • the URN 2B receives this RA and generates the IPv6 address IP U URN 2B (step S1108 ). Moreover, URN2B makes IP UE URN2B the same value as IP U URN2B .
  • the URN 2B transmits an attach request to the URN 2A (Step S1110).
  • This attach request includes the identifier ID URN2B and IP U URN2B of URN2B .
  • the URN 2A transmits an attach accept to the URN 2B (Step S1112).
  • This attach accept includes the lower 64 bits (if-id) of IP D URN 2A and IP U URN 2B .
  • URN2B transmits RS to URN2A (step S1114).
  • the URN 2A transmits an RA to the URN 2B (step S1116).
  • This RA includes the upper 64 bits (prefix) of IP D URN2A .
  • the URN 2B upon receiving this RA, the URN 2B generates an IP UE URN 2B (Step S1118). As a result, IP U URN2B and IP UE URN2B are equal.
  • the URN 2B executes DHCP-PD with the URN 2A (step S1120).
  • URN2A cuts out Pref URN2B a prefix eg / 64 from the Pref URN2A, assigns it to URN2B (step S1122).
  • the URN 2B generates an IPv6 address IP D URN 2B from the Pref URN 2B and uses it for communication in the downstream nested virtual cell.
  • the URN 2A sets the transfer destination of the Pref URN 2B to the IP U URN 2B .
  • the URN 2A waits for a certain amount of time (for example, 1 second), and during that time, attach requests regarding the URN 2 connected downstream of the URN 2A are collectively transmitted to the DeNB 3A (step S1124). That is, the URN 2A can avoid sending an attach request every time the URN 2 is connected downstream of the URN 2A by sending attach requests for a plurality of URN 2 at a time.
  • the attach request includes an identifier (for example, ID URN2B ) and an IPv6 address (for example, IP U URN2B ) of the URN 2B connected to the URN 2A , ID URN 2A, and information indicating an RN connection to the virtual cell.
  • the DeNB 3A transfers it to the MME 7 (step S1126).
  • the MME 7 transmits an attach accept to the DeNB 3A (step S1128).
  • the DeNB 3A transfers it to the URN 2A (step S1130).
  • the amount of information stored in the P-GW 6, S-GW 5A, and DeNB 3A does not depend on the number of URNs 2 that are powered on in the virtual cell provided by the URN 2A.
  • FIG. 42 is a sequence diagram illustrating an example of a flow of connection processing to the URN 2A by the URN 2C according to the present embodiment. This sequence involves URN2C, URN2A, DeNB3A, MME7, S-GW5A, and P-GW6.
  • the URN 2C establishes a radio line with the URN 2A (step S1202).
  • the URN 2C transmits the RS to the link local all-routers multicast address (step S1204).
  • the source address of this RS is the link local address of URN2C.
  • the URN 2A transmits an RA to the link local address of the URN 2C (Step S1206).
  • the RA includes prefix belonging / 64 Pref URN2A, e.g. Pref URN2A URN2C.
  • the URN 2C receives this RA and generates an IP U URN 2C (step S1208).
  • URN2C transmits an attach request to URN2A (step S1210).
  • This attach request includes the URN2C identifier ID URN2C , IP UE URN2C, and Pref URN2C .
  • the URN 2A transfers the request to the DeNB 3A (step S1212). At that time, the URN 2A adds the IP UE URN 2A and the ID URN 2A to the attach request.
  • the DeNB 3A transfers it to the MME 7 (step S1214).
  • the MME 7 transmits a default bearer generation request to the S-GW 5A (step S1216).
  • This default bearer generation request includes ID URN2A , ID URN2C , IP UE URN2A , IP UE URN2C, and Pref URN2C .
  • the S-GW 5A transfers it to the P-GW 6 (step S1218).
  • P-GW6 associates destination IP UE URN2C and Pref URN2C the IP UE URN2A. Then, the P-GW 6 transmits a default bearer generation response to the S-GW 5A (step S1220).
  • the default bearer generation response includes ID URN2A , IP UE URN2A , IP UE URN2C, and Pref URN2C .
  • S-GW5A receives this Create Default Bearer Response, associate destination IP UE URN2C and Pref URN2C the IP UE URN2A. Then, the S-GW 5A transmits this default bearer generation response to the MME 7 (step S1222).
  • the MME 7 transmits an attach accept to the DeNB 3A (step S1224).
  • This attach accept includes ID URN2A , IP UE URN2A , IP UE URN2C and Pref URN2C .
  • DeNB3A receives this attach accept, associate destination IP UE URN2C and Pref URN2C the IP UE URN2A. Then, the DeNB 3A transmits this default bearer generation response to the URN 2A (step S1226).
  • the URN 2A When the URN 2A receives this attach accept, it forms a GTP tunnel with the URN 2C. Endpoint of the GTP tunnel is IP D URN2A and IP U URN2C.
  • URN2A associates the forwarding destinations of IP UE URN2C and Pref URN2C with this GTP tunnel. Then, URN2A transmits an attach accept to URN2C (step S1228).
  • This attach accept include low-order 64 bits of the IP UE URN2C and (if-id) the IP UE URN2A.
  • URN2C obtains the lower 64 bits (if-id) of IP UE URN2C . Then, the URN 2C forms a GTP tunnel with the URN 2A (step S1230). The end points of this GTP tunnel are IP U URN2C and IP D URN2A .
  • URN2C transmits RS to URN2A (IP UE URN2A ) (step S1232).
  • This RA includes the upper 64 bits (prefix) of the IP UE URN2C .
  • the URN 2C confirms that the IP UE URN 2C is usable (step S1236).
  • the P-GW 6, S-GW 5A, and DeNB 3A store the mapping tables shown in Tables 8, 9, and 10, respectively.
  • mapping table will be described.
  • entries in the fourth and fifth lines are newly added.
  • the packet addressed to the IP UE URN2C is transferred to the entry on the 1st line with the end point IPv6 address as IP UE URN2A based on “Refer to the IP UE URN2A ” described in the forwarding destination column Forwarded.
  • the packet is forwarded to “GTP SGW5A ” by P-GW6 according to Table 8
  • GTP DeNB3A by S-GW5A according to Table 9
  • the packet is transferred to the URN 2A.
  • the packet is transferred from URN 2A to URN 2C.
  • a packet whose destination IP address has a prefix portion of Pref URN2C has the destination IPv6 address as IP UE URN2A based on “refer to IP UE URN2A ” described in the forwarding destination column. It is transferred to the transfer destination of the entry on the first line.
  • the packet is forwarded to “GTP SGW5A ” by P-GW6 according to Table 8, is forwarded to “GTP DeNB3A ” by S-GW5A according to Table 9, and is transferred to “GTP URN2A ” by DeNB3A according to Table 10. Transferred.
  • the packet is transferred to the URN 2A.
  • the packet is transferred from URN 2A to URN 2C.
  • FIG. 43 is a sequence diagram illustrating an example of a flow of connection processing to the URN 2A by the URN 2D according to the present embodiment. This sequence involves URN2D, URN2A, DeNB3A, MME7, S-GW5A, and P-GW6.
  • the URN 2D establishes a radio line with the URN 2A (step S1302).
  • the URN 2D transmits the RS to the link local all-routers multicast address (step S1304).
  • the source address of this RS is the link local address of URN2D.
  • the URN 2A receives this RS and transmits the RA to the link local address of the URN 2D (step S1306).
  • the RA includes prefix belonging / 64 Pref URN2A, e.g. Pref URN2A URN2D.
  • the URN 2D receives this RA and generates an IP U URN 2D (step S1308).
  • the URN 2D transmits an attach request to the URN 2A (Step S1310).
  • This attach request includes the identifier ID URN2D of URN2D , IP UE URN2D , Pref URN2D, and IP UE1E .
  • the URN 2A transfers the request to the DeNB 3A (step S1312). At that time, the URN 2A adds the IP UE URN 2A and the ID URN 2A to the attach request.
  • the DeNB 3A transfers it to the MME 7 (step S1314).
  • This default bearer generation request includes ID URN2A , ID URN2D , IP UE URN2A , IP UE URN2D , Pref URN2D, and IP UE1E .
  • the S-GW 5A transfers it to the P-GW 6 (step S1318).
  • P-GW6 associates destination IP UE URN2D and Pref URN2D the IP UE URN2A. Also, the P-GW 6 associates the transfer destination of the UE 1E with the Pref URN 2D . Then, the P-GW 6 transmits a default bearer generation response to the S-GW 5A (step S1320).
  • This default bearer generation response includes ID URN2A , IP UE URN2A , IP UE URN2D , Pref URN2D, and IP UE1E .
  • S-GW5A receives this Create Default Bearer Response, associate destination IP UE URN2D and Pref URN2D the IP UE URN2A. Further, the S-GW 5A associates the transfer destination of the UE 1E with the Pref URN 2D . Then, the S-GW 5A transmits this default bearer generation response to the MME 7 (step S1322).
  • the MME 7 transmits an attach accept to the DeNB 3A (step S1324).
  • This attach accept includes ID URN2A , IP UE URN2A , IP UE URN2D , Pref URN2D and IP UE1E .
  • DeNB3A receives this attach accept, associate destination IP UE URN2D and Pref URN2D the IP UE URN2A. In addition, the DeNB 3A associates the transfer destination of the UE 1E with the Pref URN 2D . And DeNB3A transmits this default bearer production
  • the URN 2A When the URN 2A receives this attach accept, it forms a GTP tunnel with the URN 2D. The end points of this GTP tunnel are IP D URN 2A and IP U URN 2D .
  • URN2A associates the forwarding destinations of IP UE URN2D and Pref URN2D with this GTP tunnel. Then, URN2A transmits an attach accept to URN2D (step S1328).
  • This attach accept include low-order 64 bits of the IP UE URN2D and (if-id) the IP UE URN2A.
  • URN2D upon receiving this attach accept, URN2D obtains the lower 64 bits (if-id) of IP UE URN2D . And URN2D comprises a GTP tunnel between URN2A (step S1330). The end points of this GTP tunnel are IP U URN2D and IP D URN2A .
  • URN2D transmits RS to URN2A (IP UE URN2A ) (step S1332 ).
  • URN 2A transmits RA to URN 2D (step S1334).
  • This RA includes the upper 64 bits (prefix) of the IP UE URN2D .
  • the URN 2D confirms that the IP UE URN 2D is usable (step S1336).
  • the P-GW 6, S-GW 5A, and DeNB 3A store the mapping tables shown in Tables 11, 12, and 13, respectively.
  • the mapping table will be described. Entries in the sixth to eighth lines are newly added to the mapping table.
  • the packet addressed to the IP UE URN2D is transferred based on “Refer to the IP UE URN2A ” described in the transfer destination column and the entry on the 1st line with the end point IPv6 address as IP UE URN2A. Forwarded.
  • the packet according to Table 11 is transferred by the P-GW6 to "GTP SGW5A", by SGW5A according to Table 12 is transferred to the "GTP DeNB3A", by DeNB3A according to Table 13 to "GTP URN2A" Transferred.
  • the packet is transferred to the URN 2A.
  • the packet is transferred from URN 2A to URN 2D.
  • a packet whose destination IP address has a prefix of Pref URN2D has the destination IPv6 address as IP UE URN2A based on “refer to IP UE URN2A ” described in the forwarding destination column. It is transferred to the transfer destination of the entry on the first line.
  • the packet according to Table 11 is transferred by the P-GW6 to "GTP SGW5A", by SGW5A according to Table 12 is transferred to the "GTP DeNB3A”, by DeNB3A according to Table 13 to "GTP URN2A” Transferred.
  • the packet is transferred to the URN 2A.
  • the packet is transferred from URN 2A to URN 2D.
  • the packet addressed to the IP UE 1E is based on the “refer to Pref URN2D ” described in the transfer destination field, and the transfer destination field of the 7th line with the destination IPv6 address as Pref URN2D Is transferred to the transfer destination of the entry in the first row with the end point IPv6 address as the IP UE URN2A , based on “Refer to IP UE URN2A ”.
  • the packet according to Table 11 is transferred by the P-GW6 to "GTP SGW5A", by SGW5A according to Table 12 is transferred to the "GTP DeNB3A", by DeNB3A according to Table 13 to "GTP URN2A" Transferred.
  • the packet is transferred to the URN 2A.
  • the packet is transferred from URN 2A to URN 2D and subsequently from URN 2D to UE 1E.
  • UE1A, UE1B, URN2B and UE1C, URN2C and UE1D, URN2D and UE1E are connected downstream of URN2A, and URN2A is connected to DeNB3A.
  • the flow of processing when handing over from DeNB3B to will be described.
  • FIG. 44 is a sequence diagram illustrating an example of a flow of a handover process from the URN 2A to the DeNB 3B according to the present embodiment.
  • URN 2A, DeNB 3A, DeNB 3B, MME 7, S-GW 5A, and P-GW 6 are involved.
  • the DeNB 3A determines the handover execution of the URN 2A to the DeNB 3B (step S1402).
  • the DeNB 3A transmits a handover request to the DeNB 3B (step S1404).
  • This handover request includes ID URN2A .
  • the DeNB 3B transmits a handover request ACK to the DeNB 3A (step S1406).
  • This handover request ACK includes ID URN2A .
  • URN 2A establishes a radio channel with DeNB 3B (step S1408).
  • the URN 2A transmits an RS to the link local all-routers multicast address (step S1410).
  • the source address of this RS is the link local address of URN2A.
  • the DeNB 3B receives this RS and transmits the RA to the link local address of the URN 2A (step S1412).
  • This RA includes the upper 64 bits (prefix) of IP D DeNB3B .
  • the URN 2A receives this RA and generates an IPv6 address IP2 U URN2A (step S1414).
  • IP2 U URN2A is used when URN2A establishes a GTP tunnel with DeNB3B.
  • the URN 2A transmits an attach request to the DeNB 3B (step S1416).
  • This attach request includes the identifier ID URN2A , IP2 U URN2A and IP UE URN2A of URN2A .
  • the DeNB 3B transmits a path switch request to the MME 7 (step S1418).
  • This path switch request includes ID URN2A , IP2 U URN2A, and IP UE URN2A .
  • the MME 7 transmits a bearer change request to the S-GW 5A (step S1420).
  • This bearer change request includes ID URN2A , IP2 U URN2A and IP UE URN2A .
  • the S-GW 5A detects that the URN 2A has handed over between the DeNBs 3 downstream of the S-GW 5A, and releases the GTP tunnel established between the S-GW 5A and the DeNB 3A.
  • a GTP tunnel is configured between the S-GW 5A and the DeNB 3B.
  • the end points of this GTP tunnel are IP D SGW 5A and IP U DeNB 3B .
  • the S-GW 5A associates the transfer destination of the IP UE URN 2A with this GTP tunnel.
  • the S-GW 5A transmits a bearer change response to the MME 7 (step S1422).
  • the bearer modification response, ID URN2A, IP2 U URN2A, route URN of IP UE URN2A and mapping table including an entry is URN2A.
  • the MME 7 transmits a path switch request ACK to the DeNB 3B (step S1424).
  • the path switch request ACK is, ID URN2A, IP2 U URN2A, route URN of mapping table IP UE URN2A and S-GW5A contains entries is URN2A.
  • the DeNB 3B configures a GTP tunnel between the DeNB 3B and the S-GW 5A.
  • the end points of this GTP tunnel are IP U DeNB 3B and IP D SGW 5A .
  • the DeNB 3B configures a GTP tunnel with the URN 2A.
  • the end points of this GTP tunnel are IP D DeNB 3B and IP U URN 2A .
  • the DeNB 3B registers the mapping table entry included in the attach accept in its own mapping table. Further, the DeNB 3B associates the transfer destination of the IP UE URN 2A with the GTP tunnel to the URN 2A.
  • the DeNB 3B transmits an attach accept to the URN 2A (step S1426). This attach accept includes the lower 64 bits (if-id) of IP UE URN2A .
  • a GTP tunnel is established between URN 2A, DeNB 3B, and S-GW 5A (step S1428). Further, the GTP tunnel between the S-GW 5A and the P-GW 6 is maintained.
  • URN 2A transmits an RS to P-GW 6 in order to obtain an IPv6 address when operating as a UE (step S1430).
  • the P-GW 6 transmits an RA to the URN 2A (step S1432).
  • This RA includes the upper 64 bits (prefix) of IP UE URN2A .
  • the URN 2A receives this RA and confirms that the IP UE URN 2A is available (step S1434).
  • the P-GW 6, S-GW 5A, and DeNB 3B store the mapping tables shown in Tables 14, 15, and 16, respectively.
  • mapping table will be described. Comparing Table 11 and Table 14, they are the same and have not changed due to handover. Comparing Table 12 and Table 15, the destination of the first line entry has changed from the "GTP DeNB3A" to "GTP DeNB3B". That is, at the time of handover within the S-GW 5A, the S-GW 5A only needs to update the entry in the first row of the mapping table. Comparing Table 13 and Table 16, they are identical. The entry in the first row in the mapping table shown in Table 16 is registered by the DeNB 3B. On the other hand, in the mapping table shown in Table 16, the entry whose root URN column is “ID URN2A ”, that is, all the entries in the second and lower rows are inherited by the handover.
  • the DeNB 3B can partially omit the mapping table generation process by taking over the mapping table. In this way, at the time of handover, the reestablishment of the transfer destination is completed by updating or taking over a very small part of the mapping table, so that signaling for location registration of UE1 under URN2 can be greatly reduced It becomes.
  • FIG. 45 is a sequence diagram illustrating an example of a flow of a handover process from the URN 2A to the DeNB 3C according to the present embodiment.
  • URN 2A, DeNB 3A, DeNB 3C, MME 7, S-GW 5A, S-GW 5B and P-GW 6 are involved.
  • the DeNB 3A determines the handover execution of the URN 2A to the DeNB 3C (step S1502).
  • the DeNB 3A transmits a handover request to the DeNB 3C (step S1504).
  • This handover request includes ID URN2A .
  • the DeNB 3C transmits a handover request ACK to the DeNB 3A (step S1506).
  • This handover request ACK includes ID URN2A .
  • the URN 2A establishes a radio channel with the DeNB 3C (step S1508).
  • the URN 2A transmits an RS to all link local router multicast addresses (step S1510).
  • the source address of this RS is the link local address of URN2A.
  • the DeNB 3C transmits an RA to the link local address of the URN 2A (step S1512).
  • This RA includes the upper 64 bits (prefix) of IP D DeNB3C .
  • the URN 2A receives this RA and generates the IPv6 address IP3 U URN 2A (step S1514).
  • IP3 U URN2A is used when URN2A establishes a GTP tunnel with DeNB3C.
  • the URN 2A transmits an attach request to the DeNB 3C (step S1516).
  • This attach request includes the identifier ID URN2A , IP3 U URN2A and IP UE URN2A of URN2A .
  • the DeNB 3C transmits a path switch request to the MME 7 (step S1518).
  • This path switch request includes ID URN2A , IP3 U URN2A, and IP UE URN2A .
  • This bearer change request includes ID URN2A , IP3 U URN2A and IP UE URN2A .
  • the S-GW 5B transfers it to the P-GW 6 (step S1522).
  • P-GW 6 detects that URN 2A has handed over between S-GW 5A and S-GW 5B, releases the GTP tunnel established between P-GW 6 and S-GW 5A, and A GTP tunnel is configured between the P-GW 6 and the S-GW 5B.
  • the end points of this GTP tunnel are IP D PGW 6 and IP U SGW 5B .
  • the P-GW 6 associates the transfer destination of the IP UE URN 2A with this GTP tunnel.
  • the P-GW 6 transmits a bearer change response to the S-GW 5B (step S1524).
  • This bearer change response includes an entry whose root URN is URN2A among ID URN2A , IP3 U URN2A , IP UE URN2A and the mapping table.
  • the S-GW 5B configures a GTP tunnel between the P-GW 6 and the S-GW 5B.
  • the end points of this GTP tunnel are IP U SGW 5B and IP D PGW 6 .
  • the S-GW 5B forms a GTP tunnel with the DeNB 3C.
  • the end points of this GTP tunnel are IP D SGW 5B and IP U DeNB 3C .
  • the S-GW 5B registers the mapping table entry included in the bearer change response in its own mapping table. Further, the S-GW 5B associates the transfer destination of the IP UE URN 2A with the GTP tunnel to the DeNB 3C.
  • the S-GW 5B transfers the bearer change response to the MME 7 (step S1526).
  • the bearer modification response, ID URN2A, IP3 U URN2A, IP UE URN2A, route URN among the lower 64 bits (if-id) and mapping table IP UE URN2A contains entries is URN2A.
  • the MME 7 transmits a path switch request ACK to the DeNB 3C (step S1528).
  • the path switch request ACK is, ID URN2A, IP3 U URN2A, IP UE URN2A, route URN of IP UE lower 64 bits of URN2A (if-id) and S-GW5B mapping table includes an entry is URN2A.
  • the DeNB 3C configures a GTP tunnel between the DeNB 3C and the S-GW 5B.
  • the end points of this GTP tunnel are IP U DeNB 3C and IP D SGW 5B .
  • the DeNB 3C configures a GTP tunnel with the URN 2A.
  • the end points of this GTP tunnel are IP D DeNB 3C and IP U URN 2A .
  • the DeNB 3C registers the mapping table entry included in the path switch request ACK in its own mapping table. Further, the DeNB 3C associates the transfer destination of the IP UE URN 2A with the GTP tunnel to the URN 2A.
  • the DeNB 3C transfers the attach accept to the URN 2A (step S1530). This attach accept includes the lower 64 bits (if-id) of IP UE URN2A .
  • a GTP tunnel is established among the URN 2A, DeNB 3C, S-GW 5B, and P-GW 6 (step S1532).
  • URN 2A transmits an RS to P-GW 6 in order to obtain an IPv6 address when operating as a UE (step S1534).
  • the P-GW 6 transmits an RA to the URN 2A (step S1536).
  • This RA includes the upper 64 bits (prefix) of IP UE URN2A .
  • the URN 2A receives this RA and confirms that the IP UE URN 2A is available (step S1538).
  • the P-GW 6, S-GW 5B, and DeNB 3C store the mapping tables shown in Tables 17, 18, and 19, respectively.
  • mapping table will be described. Comparing Table 14 and Table 17, the destination of the first line entry has changed from the "GTP SGW5A" to "GTP SGW5B". That is, at the time of handover across the S-GW 5, the P-GW 6 only needs to update the entry in the first row of the mapping table. Comparing Table 15 and Table 18, the destination of the first line entry has changed from the "GTP DeNB3B" to "GTP DeNB3C”. The entry in the first row of the mapping table shown in Table 18 is registered by the S-GW 5B. On the other hand, in the mapping table shown in Table 18, the entry whose root URN column is “ID URN2A ”, that is, all the entries in the second and lower rows are inherited by the handover.
  • the S-GW 5B can partially omit the mapping table generation process by taking over the mapping table. Comparing Table 16 and Table 19, they are identical.
  • the entry in the first row of the mapping table shown in Table 19 is registered by the DeNB 3C.
  • the entry whose root URN column is “ID URN2A ”, that is, all the entries in the second and lower rows are inherited by the handover. That is, at the time of handover, the DeNB 3C can omit part of the mapping table generation process by taking over the mapping table. In this way, since the resetting of the transfer destination is completed by updating or taking over a part of the mapping table even during handover across the S-GW 5, signaling for location registration of the UE 1 under the URN 2, etc. Can be greatly reduced.
  • the above-described protocol is a protocol compatible with the 3GPP architecture.
  • the functional sharing of P-GW, S-GW, MME, eNB, DeNB, RN, and UE is maintained.
  • an interface defined between these devices is maintained.
  • a message sequence defined between these devices is maintained.
  • the UE 1 that has already acquired the IPv6 address can continue communication even after connecting to the virtual cell.
  • DHCP-PD is used. Thereby, a nested virtual cell can be realized.
  • the amount of information to be stored by P-GW6, S-GW5, or DeNB3 does not depend on the number of UEs 1 or URNs 2 that have obtained IPv6 addresses in the virtual cell.
  • a mapping table is used. This reduces the items to be updated when the virtual cell is handed over. Moreover, when URN2 hands over between DeNB3, only URN2 performs signaling. Thereby, it is avoided that UE1 etc. under URN2 performs signaling individually at the time of handover, and the amount of signaling is suppressed.
  • the URN2 when registering UE or URN2 connected to the virtual cell in the MME 7, the URN2 can perform a plurality of units collectively instead of one by one. Thereby, the number of signaling packets can be suppressed.
  • the communication route when UE1 and URN2 perform in the 3GPP network is optimal without any detour.
  • tunneling is not used other than tunneling specified by 3GPP. Therefore, when this protocol is introduced, the header overhead does not increase.
  • URN2 when URN2 is mounted on a public vehicle such as a bus or a train, URN2 provides local content from a server connected to URN2 to UE1 of the passenger. The discontinuity of access associated with movement can be resolved. Also, mobility is realized for services from the DeNB 3 to which the URN 2 is connected or a server connected to an entity on the core network. In particular, a server connected to URN 2 is effective for services that require a low delay time.
  • a nested virtual cell formed by a passenger's URN2 is connected to a URN2 mounted on a public vehicle, only the passenger's URN2 performs connection processing, and the connectivity of the nested virtual cell to the network continues. Is done. This avoids a situation where all the UEs 1 perform the connection process to the network when boarding, thereby improving the wireless utilization efficiency.
  • a cognitive radio system is a system that provides an access network using the frequency by using a frequency database that manages an available frequency for each region.
  • a function as an access point (that is, a base station) of the cognitive radio system is implemented in URN2.
  • URN2 can specify a frequency that can be used at the current position from the frequency database using location information (such as GPS information or radio base station information), and can provide a virtual cell using the frequency. It becomes. It is also possible to provide a network access service via URN2, or a D2D (Device to Device) communication service between UE1 and UE1, or between URN2 and UE1.
  • a drone that functions as URN2 is also referred to below as a king drone.
  • the king drone may have a function as a cognitive radio system, and may specify an available frequency in a region in flight through communication with a frequency database.
  • the device group connected to the virtual cell may be, for example, a sensor device. For example, regarding agriculture, a geological, temperature, humidity, or maturity sensor or the like may be arranged in a field where crops are grown, and a king drone may fly over the field and assign a network layer IP address to the sensor device group.
  • the king drone may acquire sensor information from the sensor device group every time it flies in the area and relay it to a server on the cloud. Also, for areas where people gather for a limited time such as event venues or beaches, King drones fly over and assign network layer IP addresses to LTE devices in the area to provide services linked to applications on the terminal May be. The king drone may invalidate (that is, collect) the distributed network layer IP address after the period of the event or the like ends.
  • in-vehicle sensor system By mounting the function as URN2 in the vehicle, sensor information acquired by various sensors (road surface sensor or radar, etc.) for in-vehicle or out-of-vehicle monitoring is collected, stored and analyzed in the vehicle It becomes possible to do.
  • the URN 2 may connect to a server on the cloud as necessary, and perform more advanced analysis processing in cooperation with big data or the like. By realizing the movement permeability of the virtual cell, it is possible to feed back the analysis service to the car, the URN 2 or the sensor even when moving by car.
  • the P-GW 6 may be realized as any type of server such as a tower server, a rack server, or a blade server. Further, at least a part of the components of the P-GW 6 is realized in a module (for example, an integrated circuit module configured by one die or a card or a blade inserted in a blade server slot) mounted on a server. May be.
  • a module for example, an integrated circuit module configured by one die or a card or a blade inserted in a blade server slot mounted on a server. May be.
  • the UE 1 or the URN 2 is a smartphone, a tablet PC (Personal Computer), a notebook PC, a portable game terminal, a mobile terminal such as a portable / dongle type mobile router or a digital camera, or an in-vehicle terminal such as a car navigation device. It may be realized as. Further, the UE 1 or the URN 2 may be realized as a terminal (also referred to as an MTC (Machine Type Communication) terminal) that performs M2M (Machine To Machine) communication. Furthermore, at least some of the components of UE1 or URN2 may be realized in a module (for example, an integrated circuit module configured by one die) mounted on these terminals.
  • a module for example, an integrated circuit module configured by one die
  • FIG. 46 is a block diagram illustrating an example of a schematic configuration of a server 700 to which the technology according to the present disclosure may be applied.
  • the server 700 includes a processor 701, a memory 702, a storage 703, a network interface 704, and a bus 706.
  • the processor 701 may be a CPU (Central Processing Unit) or a DSP (Digital Signal Processor), for example, and controls various functions of the server 700.
  • the memory 702 includes a RAM (Random Access Memory) and a ROM (Read Only Memory), and stores programs and data executed by the processor 701.
  • the storage 703 may include a storage medium such as a semiconductor memory or a hard disk.
  • the network interface 704 is a wired communication interface for connecting the server 700 to the wired communication network 705.
  • the wired communication network 705 may be a core network such as EPC (Evolved Packet Core) or a PDN (Packet Data Network) such as the Internet.
  • EPC Evolved Packet Core
  • PDN Packet Data Network
  • the bus 706 connects the processor 701, the memory 702, the storage 703, and the network interface 704 to each other.
  • the bus 706 may include two or more buses with different speeds (eg, a high speed bus and a low speed bus).
  • one or more components included in the P-GW 6 described with reference to FIG.
  • a program for causing a processor to function as the one or more components is installed in the server 700, and the processor 701 is The program may be executed.
  • the server 700 may include a module including the processor 701 and the memory 702, and the one or more components may be mounted in the module. In this case, the module may store a program for causing the processor to function as the one or more components in the memory 702 and execute the program by the processor 701.
  • the server 700 or the module may be provided as an apparatus including the one or more components, and the program for causing a processor to function as the one or more components may be provided. .
  • a readable recording medium in which the program is recorded may be provided.
  • the network communication unit 610 described with reference to FIG. 11 may be implemented in the network interface 704.
  • the storage unit 620 may be implemented in the memory 702 and / or the storage 703.
  • FIG. 47 is a block diagram illustrating an example of a schematic configuration of a smartphone 900 to which the technology according to the present disclosure may be applied.
  • the smartphone 900 includes a processor 901, a memory 902, a storage 903, an external connection interface 904, a camera 906, a sensor 907, a microphone 908, an input device 909, a display device 910, a speaker 911, a wireless communication interface 912, one or more antenna switches 915.
  • One or more antennas 916, a bus 917, a battery 918 and an auxiliary controller 919 are provided.
  • the processor 901 may be, for example, a CPU or a SoC (System on Chip), and controls the functions of the application layer and other layers of the smartphone 900.
  • the memory 902 includes a RAM and a ROM, and stores programs executed by the processor 901 and data.
  • the storage 903 can include a storage medium such as a semiconductor memory or a hard disk.
  • the external connection interface 904 is an interface for connecting an external device such as a memory card or a USB (Universal Serial Bus) device to the smartphone 900.
  • the camera 906 includes, for example, an image sensor such as a CCD (Charge Coupled Device) or a CMOS (Complementary Metal Oxide Semiconductor), and generates a captured image.
  • the sensor 907 may include a sensor group such as a positioning sensor, a gyro sensor, a geomagnetic sensor, and an acceleration sensor.
  • the microphone 908 converts sound input to the smartphone 900 into an audio signal.
  • the input device 909 includes, for example, a touch sensor that detects a touch on the screen of the display device 910, a keypad, a keyboard, a button, or a switch, and receives an operation or information input from a user.
  • the display device 910 has a screen such as a liquid crystal display (LCD) or an organic light emitting diode (OLED) display, and displays an output image of the smartphone 900.
  • the speaker 911 converts an audio signal output from the smartphone 900 into audio.
  • the wireless communication interface 912 supports any cellular communication method such as LTE or LTE-Advanced, and performs wireless communication.
  • the wireless communication interface 912 may typically include a BB processor 913, an RF circuit 914, and the like.
  • the BB processor 913 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and performs various signal processing for wireless communication.
  • the RF circuit 914 may include a mixer, a filter, an amplifier, and the like, and transmits and receives radio signals via the antenna 916.
  • the wireless communication interface 912 may be a one-chip module in which the BB processor 913 and the RF circuit 914 are integrated.
  • the wireless communication interface 912 may include a plurality of BB processors 913 and a plurality of RF circuits 914 as shown in FIG. 47 shows an example in which the wireless communication interface 912 includes a plurality of BB processors 913 and a plurality of RF circuits 914, the wireless communication interface 912 includes a single BB processor 913 or a single RF circuit 914. But you can.
  • the wireless communication interface 912 may support other types of wireless communication methods such as a short-range wireless communication method, a proximity wireless communication method, or a wireless LAN (Local Area Network) method in addition to the cellular communication method.
  • a BB processor 913 and an RF circuit 914 for each wireless communication method may be included.
  • Each of the antenna switches 915 switches the connection destination of the antenna 916 among a plurality of circuits (for example, circuits for different wireless communication systems) included in the wireless communication interface 912.
  • Each of the antennas 916 includes a single or a plurality of antenna elements (for example, a plurality of antenna elements constituting a MIMO antenna), and is used for transmission / reception of a radio signal by the radio communication interface 912.
  • the smartphone 900 may include a plurality of antennas 916 as illustrated in FIG. Note that FIG. 47 illustrates an example in which the smartphone 900 includes a plurality of antennas 916, but the smartphone 900 may include a single antenna 916.
  • the smartphone 900 may include an antenna 916 for each wireless communication method.
  • the antenna switch 915 may be omitted from the configuration of the smartphone 900.
  • the bus 917 connects the processor 901, the memory 902, the storage 903, the external connection interface 904, the camera 906, the sensor 907, the microphone 908, the input device 909, the display device 910, the speaker 911, the wireless communication interface 912, and the auxiliary controller 919 to each other.
  • the battery 918 supplies power to each block of the smartphone 900 shown in FIG. 47 via a power supply line partially shown by a broken line in the drawing.
  • the auxiliary controller 919 operates the minimum necessary functions of the smartphone 900 in the sleep mode.
  • one or more constituent elements may be implemented in the wireless communication interface 912.
  • the smartphone 900 includes a module including a part (for example, the BB processor 913) or the whole of the wireless communication interface 912, the processor 901, and / or the auxiliary controller 919, and the one or more components in the module. May be implemented.
  • the module stores a program for causing the processor to function as the one or more components (in other words, a program for causing the processor to execute the operation of the one or more components).
  • the program may be executed.
  • a program for causing a processor to function as the one or more components is installed in the smartphone 900, and the wireless communication interface 912 (eg, the BB processor 913), the processor 901, and / or the auxiliary controller 919 is The program may be executed.
  • the smartphone 900 or the module may be provided as a device including the one or more components, and a program for causing a processor to function as the one or more components may be provided.
  • a readable recording medium in which the program is recorded may be provided.
  • the wireless communication unit 120 described with reference to FIG. 9 or the wireless communication unit 220 described with reference to FIG. 10 includes a wireless communication interface 912 (for example, an RF circuit 914). ). Further, the antenna unit 110 or the antenna unit 210 may be mounted on the antenna 916. Further, the storage unit 130 or the storage unit 230 may be mounted in the memory 902.
  • FIG. 48 is a block diagram illustrating an example of a schematic configuration of a car navigation device 920 to which the technology according to the present disclosure can be applied.
  • the car navigation device 920 includes a processor 921, a memory 922, a GPS (Global Positioning System) module 924, a sensor 925, a data interface 926, a content player 927, a storage medium interface 928, an input device 929, a display device 930, a speaker 931, and wireless communication.
  • the interface 933 includes one or more antenna switches 936, one or more antennas 937, and a battery 938.
  • the processor 921 may be a CPU or SoC, for example, and controls the navigation function and other functions of the car navigation device 920.
  • the memory 922 includes RAM and ROM, and stores programs and data executed by the processor 921.
  • the GPS module 924 measures the position (for example, latitude, longitude, and altitude) of the car navigation device 920 using GPS signals received from GPS satellites.
  • the sensor 925 may include a sensor group such as a gyro sensor, a geomagnetic sensor, and an atmospheric pressure sensor.
  • the data interface 926 is connected to the in-vehicle network 941 through a terminal (not shown), for example, and acquires data generated on the vehicle side such as vehicle speed data.
  • the content player 927 reproduces content stored in a storage medium (for example, CD or DVD) inserted into the storage medium interface 928.
  • the input device 929 includes, for example, a touch sensor, a button, or a switch that detects a touch on the screen of the display device 930, and receives an operation or information input from the user.
  • the display device 930 has a screen such as an LCD or an OLED display, and displays a navigation function or an image of content to be reproduced.
  • the speaker 931 outputs the navigation function or the audio of the content to be played back.
  • the wireless communication interface 933 supports any cellular communication method such as LTE or LTE-Advanced, and performs wireless communication.
  • the wireless communication interface 933 may typically include a BB processor 934, an RF circuit 935, and the like.
  • the BB processor 934 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and performs various signal processing for wireless communication.
  • the RF circuit 935 may include a mixer, a filter, an amplifier, and the like, and transmits and receives a radio signal via the antenna 937.
  • the wireless communication interface 933 may be a one-chip module in which the BB processor 934 and the RF circuit 935 are integrated.
  • the wireless communication interface 933 may include a plurality of BB processors 934 and a plurality of RF circuits 935 as shown in FIG. 48 shows an example in which the wireless communication interface 933 includes a plurality of BB processors 934 and a plurality of RF circuits 935, the wireless communication interface 933 includes a single BB processor 934 or a single RF circuit 935. But you can.
  • the wireless communication interface 933 may support other types of wireless communication methods such as a short-range wireless communication method, a proximity wireless communication method, or a wireless LAN method in addition to the cellular communication method.
  • a BB processor 934 and an RF circuit 935 may be included for each communication method.
  • Each of the antenna switches 936 switches the connection destination of the antenna 937 among a plurality of circuits included in the wireless communication interface 933 (for example, circuits for different wireless communication systems).
  • Each of the antennas 937 has a single or a plurality of antenna elements (for example, a plurality of antenna elements constituting a MIMO antenna), and is used for transmission / reception of a radio signal by the radio communication interface 933.
  • the car navigation device 920 may include a plurality of antennas 937 as shown in FIG. FIG. 48 shows an example in which the car navigation device 920 includes a plurality of antennas 937, but the car navigation device 920 may include a single antenna 937.
  • the car navigation device 920 may include an antenna 937 for each wireless communication method.
  • the antenna switch 936 may be omitted from the configuration of the car navigation device 920.
  • the battery 938 supplies power to each block of the car navigation device 920 shown in FIG. 48 via a power supply line partially shown by a broken line in the drawing. Further, the battery 938 stores electric power supplied from the vehicle side.
  • one or more components may be implemented in the wireless communication interface 933.
  • one or more components may be implemented in the processor 921.
  • the car navigation apparatus 920 includes a module including a part (for example, the BB processor 934) or the whole of the wireless communication interface 933 and / or the processor 921, and the one or more components are mounted in the module. May be.
  • the module stores a program for causing the processor to function as the one or more components (in other words, a program for causing the processor to execute the operation of the one or more components).
  • the program may be executed.
  • a program for causing a processor to function as the one or more components is installed in the car navigation device 920, and the wireless communication interface 933 (eg, the BB processor 934) and / or the processor 921 executes the program. May be.
  • the car navigation apparatus 920 or the module may be provided as an apparatus including the one or more components, and a program for causing a processor to function as the one or more components may be provided. Good.
  • a readable recording medium in which the program is recorded may be provided.
  • the antenna unit 110 or the antenna unit 210 may be mounted on the antenna 937.
  • the storage unit 130 or the storage unit 230 may be mounted in the memory 922.
  • the technology according to the present disclosure may be realized as an in-vehicle system (or vehicle) 940 including one or more blocks of the car navigation device 920 described above, an in-vehicle network 941, and a vehicle side module 942. That is, the in-vehicle system (or vehicle) 940 may be provided as a device including the communication control unit 141 or the relay unit 241 and the communication control unit 243.
  • the vehicle-side module 942 generates vehicle-side data such as vehicle speed, engine speed, or failure information, and outputs the generated data to the in-vehicle network 941.
  • the URN 2 relays a radio signal between the first device to which the connection is made and one or more second devices under its control, while the one or more second devices.
  • a network layer IP address having a common at least part of the prefix portion is assigned to each.
  • a relay unit that relays a radio signal between the first device connected to and one or more second devices under its control;
  • a controller that assigns a network layer IP address that has at least a portion of a prefix portion common to each of the one or more second devices;
  • a relay device comprising: (2) Between the relay device and the P-GW in a section between the relay device and the P-GW in a transmission path set up between the second device and a P-GW (Packet Data Network Gateway).
  • the relay device according to (1) wherein the transmission path set in (1) is diverted.
  • the relay apparatus according to (2), wherein the transmission path is a bearer.
  • a processing unit that communicates with the relay device using a first network layer IP address in which at least a part of a prefix portion assigned to one or more terminal devices connected to the same relay device is common;
  • a terminal device comprising: (11) The terminal device according to (10), wherein the processing unit suppresses an attachment procedure to another network for a predetermined period after the relay device starts handover. (12) The terminal device according to (10) or (11), further including a storage unit that stores a time at which an attachment procedure to the relay device is completed. (13) The processing unit uses the first network layer IP address for a socket that is opened after the time when the attachment procedure to the relay device is completed, and before the time when the attachment procedure to the relay device is completed.
  • the terminal device wherein the second network layer IP address assigned before the handover is continuously used for the opened socket.
  • the processing unit notifies the relay device of information indicating that a socket using the second network layer IP address is closed.
  • a network layer that relays a radio signal between a first device connected to and one or more second devices under control, and at least a part of a prefix portion is common to each of the one or more second devices.
  • a processing unit for notifying a relay apparatus that allocates an IP address of a common part of the prefix part;
  • a communication control device comprising: (16) The communication control device according to (15), further including a storage unit that stores the prefix portion and the relay device in association with each other.
  • the processing unit notifies the information for associating the prefix portion with the relay device to a device that relays communication between the relay device and the communication control device, according to (15) or (16).
  • Communication control device (18) Relaying a radio signal between a first device connected to and one or more second devices under its control; A controller that assigns, by a processor, a network layer IP address that has at least a portion of a prefix portion common to each of the one or more second devices; Including methods. (19) Communicating with the relay device by a processor using a first network layer IP address in which at least a part of a prefix assigned to one or more terminal devices connected to the same relay device is common; Including methods.

Landscapes

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

Abstract

【課題】移動を考慮したリレーノードに関する仕組みを提供する。 【解決手段】接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継する中継部と、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる制御部と、を備える中継装置。

Description

中継装置、端末装置、通信制御装置及び方法
　本開示は、中継装置、端末装置、通信制御装置及び方法に関する。
　セルラーネットワークにおいて、リレーノードと呼ばれる中継装置が考案されている。リレーノードは、基地局とユーザ端末との間に位置して、その無線通信をリレーする機能を有する。例えば、３ＧＰＰにおいては、下記非特許文献１においてリレーノードに関する規格が検討されている。
3GPP　TS　36.300　Release　12　V12.8.0　（2016-01）Evolved　Universal　Terrestrial　Radio　Access　（E-UTRA）　and　Evolved　Universal　Terrestrial　Radio　Access　Network　（E-UTRAN）；　Overall　description；　Stage　2
　しかしながら、上記非特許文献１では、リレーノードは固定されていることが前提とされており、移動することが想定された規格にはなっていなかった。そのため、移動を考慮したリレーノードに関する仕組みが提供されることが望ましい。
　本開示によれば、接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継する中継部と、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる制御部と、を備える中継装置が提供される。
　また、本開示によれば、同一の中継装置に接続するひとつ以上の端末装置に割り当てられるプレフィクス部分の少なくとも一部が共通する第１のネットワーク層ＩＰアドレスを用いて前記中継装置との通信を行う処理部、を備える端末装置が提供される。
　また、本開示によれば、接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継し、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる中継装置に、前記プレフィクス部分のうち共通する部分を通知する処理部、を備える通信制御装置が提供される。
　また、本開示によれば、接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継することと、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスをプロセッサにより割り当てる制御部と、を含む方法が提供される。
　また、本開示によれば、同一の中継装置に接続するひとつ以上の端末装置に割り当てられるプレフィクス部分の少なくとも一部が共通する第１のネットワーク層ＩＰアドレスを用いて前記中継装置との通信をプロセッサにより行うこと、を含む方法が提供される。
　また、本開示によれば、接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継し、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる中継装置に、前記プレフィクス部分のうち共通する部分をプロセッサにより通知すること、を含む方法が提供される。
　以上説明したように本開示によれば、移動を考慮したリレーノードに関する仕組みが提供される。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
リレーノードをサポートするＥ－ＵＴＲＡＮアーキテクチャである。 Ｓ１ユーザプレーンのプロトコルスタックを示す図である。 Ｘ２ユーザプレーンのプロトコルスタックを示す図である。 Ｓ１制御プレーンのプロトコルスタックを示す図である。 Ｘ２制御プレーンのプロトコルスタックを示す図である。 本開示の一実施形態に係るシステムの概略的な構成の一例を示す図である。 同実施形態に係るＵＲＮのプロトコルスタックの一例を示す図である。 同実施形態に係るＵＲＮを経由するＵＥとＰＤＮ上のサーバとの通信におけるプロトコルスタックの一例を示す図である。 同実施形態に係るＵＥの構成の一例を示すブロック図である。 同実施形態に係るＵＲＮの構成の一例を示すブロック図である。 同実施形態に係るＰ－ＧＷの構成の一例を示すブロック図である。 第１の実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 第２の実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 サーバの概略的な構成の一例を示すブロック図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。
　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
　また、本明細書及び図面において、実質的に同一の機能構成を有する要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の要素を、必要に応じて端末装置１００Ａ、１００Ｂ及び１００Ｃのように区別する。ただし、実質的に同一の機能構成を有する複数の要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、端末装置１００Ａ、１００Ｂ及び１００Ｃを特に区別する必要が無い場合には、単に端末装置１００と称する。
　なお、説明は以下の順序で行うものとする。
　　１．はじめに
　　　１．１．リレーノード
　　　１．２．技術的課題
　　２．構成例
　　　２．１．システムの構成例
　　　２．２．ＵＥの構成例
　　　２．３．ＵＲＮの構成例
　　　２．４．Ｐ－ＧＷの構成例
　　３．第１の実施形態
　　　３．１．ネットワーク層ＩＰアドレスの初回割り当て
　　　３．２．ハンドオーバ時のネットワーク層ＩＰアドレスの取り扱い
　　　３．３．ハンドオーバ時のトランスポート層ＩＰアドレスの取り扱い
　　　３．４．効果
　　４．第２の実施形態
　　　４．１．はじめに
　　　４．２．処理の流れ
　　　４．３．効果
　　５．ユースケース
　　６．応用例
　　７．まとめ
　＜＜１．はじめに＞＞
　　＜１．１．リレーノード＞
　まず、図１～図５を参照して、リレーノードについて説明する。
　図１は、リレーノードをサポートするＥ－ＵＴＲＡＮ（Evolved　Universal　Terrestrial　Radio　Access　Network）アーキテクチャである。ＲＮ（Relay　Node）は、ユーザ端末（ＵＥ：User　Equipment）による無線通信をリレーするエンティティである。ＤｅＮＢ（donor　eNB）は、リレーノードと接続するｅＮＢである。図１に示すように、ｅＮＢとＭＭＥ／Ｓ－ＧＷとの間には、Ｓ１インタフェースが設定される。また、ＤｅＮＢとＭＭＥ／Ｓ－ＧＷとの間には、Ｓ１インタフェース及びＳ１１インタフェースが設定される。また、ｅＮＢとＤｅＮＢとの間には、Ｘ２インタフェースが設定される。また、ＤｅＮＢとＲＮ（Ｒｅｌａｙ　Ｎｏｄｅ）との間には、Ｓ１インタフェース、Ｘ２インタフェース、及びＵｕインタフェースが設定される。
　図２は、Ｓ１ユーザプレーンのプロトコルスタックを示す図である。図３は、Ｘ２ユーザプレーンのプロトコルスタックを示す図である。図４は、Ｓ１制御プレーンのプロトコルスタックを示す図である。図５は、Ｘ２制御プレーンのプロトコルスタックを示す図である。ここで、図２～図５における「ＩＰ」とは、すべてトランスポート層のＩＰである。即ち、リレーノードには、ネットワーク層のＩＰは想定されていなかった。
　　＜１．２．技術的課題＞
　　（１）課題
　第１に、リレーノードは、ネットワーク層ＩＰアドレスを有していないので、ＵＥとして振る舞う際に、ＩＰアプリケーションを利用することが困難であった。
　第２に、リレーノードの移動性が考慮されていなかった。そのため、リレーノードはトランスポート層ＩＰアドレスを有するものの、当該ＩＰに関する移動に伴う透過性は担保されていない。リレーノードが仮にネットワーク層ＩＰアドレスを有することとなっても、同様の課題が生じる。
　第３に、リレーノードに接続されるＵＥ等の端末群が、リレーノードの移動の都度、自らアタッチ手続き（Attachment　Procedure）を行ってＭＭＥへの位置登録を行い個別のベアラを確立する場合、シグナリングが沢山必要となる。
　第４に、端末群が頻繁に移動すると、ＭＭＥへの位置登録が頻繁に行われることとなり、その分シグナリングが沢山必要となる。さもないと、端末群は、ページングのようなプッシュアプリケーションを受信することが困難となる。
　本開示では、上記４つの技術的課題を解決する、新たなプロトコルの一例を提供する。
　　（２）先行技術
　ＩＰアドレスの移動透過性を実現するための技術の一例として、例えばＩＥＴＦ（Internet　Engineering　Task　Force）で規定されているＭｏｂｉｌｅ　ＩＰ　（ＲＦＣ３７７５）、Ｐｒｏｘｙ　Ｍｏｂｉｌｅ　ＩＰ　（ＲＦＣ５２１３）、Ｎｅｔｗｏｒｋ　Ｍｏｂｉｌｉｔｙ　（ＲＦＣ３９６３）がある。しかし、これらの技術では、リレーノードにリレーノードが接続され階層的にモバイルネットワークが形成されるケース、及びモバイルネットワーク間でハンドオーバが行われるケース等において、ユーザ端末のＩＰ移動透過性を担保することが困難であった。
　また、上記技術的課題に関連する技術の一例として、国際公開２０１２／１１４５２７号（ＰＣＴ／ＪＰ２０１１／０５４４０１）において、リレーノードに対して複数のＩＰアドレスを付与する技術が開示されている。さらに詳しくは、ＤｅＮＢが配下のリレーノードに対して複数のＩＰアドレスを付与し、リレーノードに接続される他のリレーノードに対しては当該複数のＩＰアドレスの中からＩＰアドレスが付与されることが開示されている。上記先行技術は、リレーノードをいわば数珠つなぎにする際に用いられる技術であって、上記技術的課題に示すようにリレーノードの配下の端末群に対して付与されるＩＰアドレスに関するものではない。
　また、表１に、既存のモビリティサポートプロトコルをまとめた表を示す。モビリティサポートプロトコルは２つの視点で分類可能である。１つ目の視点は、ノード単体の移動を実現する（Node　Mobility）プロトコルか、あるいはノードの集合(ネットワーク)の移動を実現する（Network　Mobility：ＮＥＭＯ）プロトコルかという視点である。２つ目の視点は、移動ノード（または移動ルータ）が移動管理のためのシグナリングに関わり、かつ移動範囲がインターネット全体である（Host-Based　Global　Mobility）プロトコルか、あるいは移動ノード（または移動ルータ）は移動管理のためのシグナリングに関わらず、かつ移動範囲が限定された範囲のみ（Network－Based　Localized　Mobility）のプロトコルかという視点である。
　本実施形態に係る提案プロトコルは、ＮＥＭＯ且つ移動ノードは移動管理のためのシグナリングに関わらず、かつ移動範囲が限定された範囲のみであるプロトコルである。
Figure JPOXMLDOC01-appb-T000001
　なお、表１における各プロトコルは、それぞれ下記の文献に詳細に説明されている。
　［１］　C.　Perkins.　IP　Mobility　Support　for　IPv4,　Revised,　November　2010.　RFC　5944.
　［２］　V.　Devarapalli,　R.　Wakikawa,　A.　Petrescu,　and　P.　Thubert.　Network　Mobility　(NEMO)　Basic　Support　Protocol,　January　2005.　RFC　3963.
　［３］　C.　Perkins,　D.　Johnson,　and　J.　Arkko.　Mobility　Support　in　IPv6,　July　2011.　RFC　6275.
　［４］　K.　Lueng,　G.　Dommety,　V.　Narayanan,　and　A.　Petrescu.　Network　Mobility　(NEMO)　Extensions　for　Mobile　IPv4,　April　2008.　RFC　5177.
　［５］　S.　Gundavelli,　K.　Lueng,　V.　Devarapalli,　K.　Chowdhury,　and　B.　Patil.　Proxy　Mobile　IPv6,　August　2008.　RFC　5213.
　［６］　I.　Soto,　C.J.　Bernardos,　M.　Calderon,　A.　Banchs,　and　A.　Azcorra.　Nemo-Enabled　Localized　Mobility　Support　for　Internet　Access　in　Automotive　Scenarios.　IEEE　Communications　Magazine,　Vol.　47,　No.　5,　pp.　152-159,　2009.
　［７］　K.　Lueng,　G.　Dommety,　P.　Yegani,　and　K.　Chowdhury.　WiMAX　Forum　/　3GPP2　Proxy　Mobile　IPv4,　February　2010.　RFC　5563.
　［８］　Z.　Yan,　S.　Zhang,　H.　Zhou,　H.　Zhang,　and　I.　You.　Network　Mobility　Support　in　PMIPv6　Network.　In　Proceedings　of　3rd　International　Conference　on　Ubiquitous　and　Future　Networks　(ICUFN2011),　2011.
　［９］　R.　Wakikawa　and　S.　Gundavelli.　IPv4　Support　for　Proxy　Mobile　IPv6,　May　2010.　RFC　5844.
　［１０］　J.　H.　Lee,　T.　Ernst,　and　N.　Chilamlurti.　Performance　Analysis　of　PMIPv6-Based　NEtwork　MObility　for　Intelligent　Transportation　Systems.　IEEE　Transactions　on　Vehicular　Technology,　Vol.　61,　No.　1,　January　2012.
　［１１］　T.　Arita　and　F.　Teraoka.　PNEMO:　A　Network-Based　Localized　Mobility　Management　Protocol　for　Mobile　Networks.　Journal　of　Information　Processing,　Vol.　20,　No.　2,　February　2012.
　［１２］　X.　Zhou,　J.　Korhonen,　C.　Williams,　S.　Gundavelli,　and　CJ.　Bernardos.　Prefix　Delegation　Support　for　Proxy　Mobile　IPv6,　March　2014.　RFC　7148.
　＜＜２．構成例＞＞
　　＜２．１．システムの構成例＞
　図６は、本開示の一実施形態に係るシステムの概略的な構成の一例を示す図である。図６に示すように、本実施形態に係るシステムは、ＵＥ１、ＵＲＮ２、ＤｅＮＢ３、ｅＮＢ４、Ｓ－ＧＷ５、Ｐ－ＧＷ６、ＭＭＥ７、及びＨＳＳ８を含む。各々を結ぶ実線はユーザプレーンを示し、破線は制御プレーンを示す。またＵＥｓとは、複数のＵＥ１を示す。提案プロトコルは、図６に示すように、例えば携帯電話網をドメイン（ネットワークの範囲）として動作し得る。もちろん、ドメインは他のネットワーク構成であってもよい。
　ＵＥ１は、端末装置である。ＵＲＮ（User-Relay-Node）２は、ＵＥ又はＲＮとして動作し得る中継装置である。ＤｅＮＢ３は、リレーノードが接続される基地局である。ｅＮＢ４は、基地局である。Ｓ－ＧＷ（Serving　Gateway）５は、ユーザデータの伝送を行うゲートウェイである。Ｐ－ＧＷ６は、コアネットワークと外部のＰＤＮ（Packet　Data　Network）との接点となるゲートウェイであり、ＩＰアドレスの割り当て等を行う通信制御装置である。ＭＭＥ（mobility　management　entity）７は、ＵＥ１の移動管理、認証、及びユーザデータの転送経路の設定等を行う。ＨＳＳ（Home　Subscriber　Server）８は、ユーザ情報を管理する。その他、本実施形態に係るシステムは、Ｓ－ＧＷ５及びＰ－ＧＷ６において適用される、ＱｏＳ等のポリシー制御及び課金制御ルールを決定するＰＣＲＦ（policy　and　charging　rules　function）等のエンティティを含み得る。
　図７は、本実施形態に係るＵＲＮ２のプロトコルスタックの一例を示す図である。図７に示すように、ＵＲＮ２は、ＥＰＣトランスポート層ＩＰアドレスに加えて、ネットワーク層ＩＰアドレス（ＵＥ１又はＵＲＮ２上のアプリケーションにより利用される）を有する。
　図８は、本実施形態に係るＵＲＮ２を経由するＵＥ１とＰＤＮ上のサーバとの通信におけるプロトコルスタックの一例を示す図である。図８に示すように、ＵＲＮ２は、ＤｅＮＢ３に接続されて、ＥＰＣ（Ｓ－ＧＷ５及びＰ－ＧＷ６）を経由してＰＤＮ上のアプリケーションサーバと通信を行う。また、ＵＲＮ２は、配下のＵＥ１と接続先のＤｅＮＢ３との無線通信を中継する。
　　＜２．２．ＵＥの構成例＞
　続いて、図９を参照して、本実施形態に係るＵＥ１の構成の一例を説明する。図９は、本実施形態に係るＵＥ１の構成の一例を示すブロック図である。図９を参照すると、ＵＥ１は、アンテナ部１１０、無線通信部１２０、記憶部１３０及び処理部１４０を備える。
　（１）アンテナ部１１０
　アンテナ部１１０は、無線通信部１２０により出力される信号を電波として空間に放射する。また、アンテナ部１１０は、空間の電波を信号に変換し、当該信号を無線通信部１２０へ出力する。
　（２）無線通信部１２０
　無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、ＵＲＮ２又はｅＮＢ４からのダウンリンク信号を受信し、ＵＲＮ２又はｅＮＢ４へのアップリンク信号を送信する。
　（３）記憶部２３０
　記憶部１３０は、ＵＥ１の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　（４）処理部１４０
　処理部１４０は、ＵＥ１の様々な機能を提供する。処理部１４０は、通信制御部１４１を含む。なお、処理部１４０は、この構成要素以外の他の構成要素をさらに含み得る。即ち、処理部１４０は、この構成要素の動作以外の動作も行い得る。通信制御部１４１は、ＵＲＮ２との通信を制御する機能を有する。
　　＜２．３．ＵＲＮの構成例＞
　続いて、図１０を参照して、本実施形態に係るＵＲＮ２の構成の一例を説明する。図１０は、本実施形態に係るＵＲＮ２の構成の一例を示すブロック図である。図１０を参照すると、ＵＲＮ２は、アンテナ部２１０、無線通信部２２０、記憶部２３０及び処理部２４０を備える。
　（１）アンテナ部２１０
　アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。
　（２）無線通信部２２０
　無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、接続先のＤｅＮＢ３又は接続先のＵＲＮ２からのダウンリンク信号を受信し、接続先のＤｅＮＢ３又は接続先のＵＲＮ２へのアップリンク信号を送信する。また、例えば無線通信部２２０は、ＵＥ１からのアップリンク信号を受信し、ＵＥ１へのダウンリンク信号を送信する。
　（３）記憶部２３０
　記憶部２３０は、ＵＲＮ２の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　（４）処理部２４０
　処理部２４０は、ＵＲＮ２の様々な機能を提供する。処理部２４０は、中継部２４１、及び通信制御部２４３を含む。なお、処理部２４０は、この構成要素以外の他の構成要素をさらに含み得る。即ち、処理部２４０は、この構成要素の動作以外の動作も行い得る。
　中継部２４１は、接続先のＤｅＮＢ３（即ち、第１の装置）と配下のひとつ以上のＵＥ１又は配下のひとつ以上のＵＲＮ２（即ち、第２の装置）との間で無線信号を中継する機能を有する。通信制御部２４３は、ＵＥ１との通信を制御したり、接続先のＤｅＮＢ３又は接続先のＵＲＮ２との接続処理又はハンドオーバ処理等を行ったりする機能を有する。
　　＜２．４．Ｐ－ＧＷの構成例＞
　続いて、図１１を参照して、本実施形態に係るＰ－ＧＷ６の構成の一例を説明する。図１１は、本実施形態に係るＰ－ＧＷ６の構成の一例を示すブロック図である。図１１を参照すると、Ｐ－ＧＷ６は、ネットワーク通信部６１０、記憶部６２０、及び処理部６３０を備える。
　　（１）ネットワーク通信部６１０
　ネットワーク通信部６１０は、他の装置との間で通信を行うためのインタフェースである。例えば、Ｐ－ＧＷ６は、コアネットワーク内の他のＥＰＣエンティティ、又はＰＤＮ上のサーバ等との間で通信を行う。
　　（２）記憶部６２０
　記憶部６２０は、Ｐ－ＧＷ６の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　　（３）処理部６３０
　処理部６３０は、Ｐ－ＧＷ６の様々な機能を提供する。処理部６３０は、通信制御部６３１を含む。なお、処理部６３０は、この構成要素以外の他の構成要素をさらに含み得る。即ち、処理部６３０は、この構成要素の動作以外の動作も行い得る。
　通信制御部６３１は、ＵＥ１又はＵＲＮ２のネットワークへの接続処理に関する各種処理を行う機能を有する。
　＜＜３．第１の実施形態＞＞
　　＜３．１．ネットワーク層ＩＰアドレスの初回割り当て＞
　以下、図１２～図２９を参照して、ネットワーク層ＩＰアドレスの初回割り当てについて説明する。本節では、ネットワーク層ＩＰアドレスのことを、単にＩＰアドレスとも称する。
　図１２は、ＩＰアドレスの初回割り当てを説明するための図である。本節では、図１２に示したネットワーク構成を前提に、ＩＰアドレスの初回割り当てを説明する。図１２に示すように、本ネットワーク構成においては、ＵＲＮ２ＡにＵＥ１Ａ及びＵＲＮ２Ｂが接続され、ＵＲＮ２ＢにＵＥ１Ｂ及びＵＲＮ２Ｃが接続され、ＵＲＮ２ＣにＵＥ１Ｃが接続されている。各ＵＲＮ２が形成するモバイルネットワークを、以下ではムービングセル又は仮想セルとも称する。図１２においては、仮想セルは破線の矩形で示されている。ここで、ＵＲＮ２Ｂにより形成される仮想セル及びＵＲＮ２Ｃにより形成される仮想セルのように、仮想セルに他の仮想セルが接続する構造を、入れ子構造とも称する。そして、例えばＵＲＮ２Ｂにより形成される仮想セルを、入れ子の仮想セルとも称する。
　３ＧＰＰの枠組みにおいては、ＵＥ１は、アタッチ手続きにおいて、ＨＳＳ８に予め登録されたＩＰアドレス（Static　IP）、又はＰ－ＧＷ６に予め確保されているＩＰアドレス（Dynamic　IP）が割り当てられる。本実施形態では、まず、ＵＲＮ２がアタッチ手続きによりＩＰアドレスを取得して、その後配下のＵＥ１にＩＰアドレスが割り当てられる。
　　（１）ＵＲＮへのＩＰアドレスの割り当て
　ＵＲＮ２がＵＥ１としても動作し得ることを考慮すれば、ＵＲＮ２にもＩＰアドレスが割り当てられることが望ましい。そこで、ＵＲＮ２は、ＵＥ１と同様に、ＭＭＥ７へアタッチリクエストメッセージを送信することで、ＩＰアドレスの割り当てプロセスを行ってＩＰアドレスの割り当てを受け、自身にＩＰアドレスを割り当てる。
　なお、Ｓ－ＧＷ５及びＰ－ＧＷ６は、ＤｅＮＢ３の内部に設けられるリレーノード用の機能エンティティとして実現されてもよい。例えば、ＮＦＶ（Network　Functions　Virtualization）による仮想化機能により、このような構成が実現され得る。
　　（１－１）Ｓｔａｔｉｃ　ＩＰの場合
　ＵＲＮ２の識別情報（ＩＤ：identification）に対応するＩＰアドレスがＨＳＳ８に登録されている場合、アタッチアクセプトメッセージに当該ＩＰアドレスが含まれてＵＲＮ２へ通知されてもよい。その場合、手段の一例として、ＮＡＳ（Non-Access　Stratum）プロトコルで定義されているＰＣＯ（Protocol　Configuration　Options）フィールドが利用されてもよい。図１３及び図１４は、ＰＣＯフォーマットを示す図である。このような手続きにより、ＵＲＮ２にＩＰアドレスが割り当てられる。
　　（１－２）Ｄｙｎａｍｉｃ　ＩＰの場合
　ＵＲＮ２のアタッチリクエストにおいて、ＩＰアドレスの割り当て要求がＭＭＥ７へ送信される。しかし、ＨＳＳ８に事前に登録されたＩＰアドレスが無い場合、Ｐ－ＧＷ６に対して、ＵＲＮ２へのＩＰアドレスの割り当て要求が行われる。
　Ｐ－ＧＷ６は、要求元のＵＲＮ２へ付与するＩＤ（例えば、ＩＰｖ６におけるインタフェース識別子（６４ビット））を生成して通知する。この通知は、例えばアタッチ承認メッセージに含まれてもよい。また、Ｐ－ＧＷ６は、ＵＲＮ２のグローバルユニークな端末ＩＤ（例えば、ＩＭＳＩ（International　Mobile　Subscriber　Identity））とＩＰアドレスのプレフィクス部分（例えば、ＩＰｖ６のＰｒｅｆｉｘ／６４）との関連付けを生成して記憶する。
　例えば、ＵＲＮ２は、付与されたＩＤ（例えば、ＩＰｖ６のインタフェース識別子）を利用してリンクローカルアドレス（Link　Local　Address）を生成し、いわゆるＩＰプロトコルであるＲＳメッセージ（Router　Advertisement　Message）をＰ－ＧＷ６へ送信して、ＩＰアドレスのプレフィクス部分（例えば、ＩＰｖ６のＰｒｅｆｉｘ／６４）を取得してもよい。例えば、Ｐ－ＧＷ６が送信するＲＡメッセージ（Router　Advertisement　Message）に、ＩＰアドレスのプレフィクス部分が含まれていてもよい。そして、ＵＲＮ２は、入手したプレフィクス部分とインタフェース識別子とを連結することで、ＩＰｖ６アドレスを生成してもよい。もちろん、ＵＲＮ２は、Ｐ－ＧＷ６により生成されたインタフェース識別子とは別のインタフェース識別子を生成して、ＩＰｖ６アドレスを生成してもよい。ただし、ここで生成されるインタフェース識別子は、Ｐ－ＧＷ６が生成するインタフェース識別子との重複がないことが望ましい。また、ＵＲＮ２は、ＲＳメッセージ及びＲＡメッセージの代わりにＤＨＣＰｖ６プロトコルを用いて、ＤＨＣＰサーバからＩＰアドレスを取得してもよい。このようにして、ＵＲＮ２は、自身のＩＰアドレスを割り当てることが可能となる。
　以下、図１５を参照しながら、ＵＲＮ２へのＩＰアドレスの割り当て処理の具体的なシーケンスの一例を説明する。
　図１５は、本実施形態に係るＵＲＮ２へのＩＰアドレスの割り当て処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＲＮ２、ＤｅＮＢ３、Ｓ－ＧＷ５、Ｐ－ＧＷ６、ＭＭＥ７及びＨＳＳ８、並びにＰＣＲＦ９が関与する。
　図１５に示すように、まず、ＵＲＮ２Ａは、アタッチリクエスト（Attach　Request　(PCO　IP　Address　Request)）をＭＭＥ７へ送信する（ステップＳ１０２）。次いで、ＵＲＮ２Ａは、識別、認証及び暗号化等（Identification／Authentication／Ciphered　option　etc.）を、ＤｅＮＢ３、ＭＭＥ７、及びＨＳＳ８との間で行う（ステップＳ１０４）。次に、ＭＭＥ７は、ロケーションリクエスト（Location　Request）をＨＳＳ８へ送信する（ステップＳ１０６）。次いで、ＨＳＳ８は、ロケーションリクエストレスポンス（Location　Request　Response）をＭＭＥ７へ送信する（ステップＳ１０８）。次に、ＭＭＥ７は、ベアラリクエスト（Bearer　Request）をＳ－ＧＷ５へ送信する（ステップＳ１１０）。次いで、Ｓ－ＧＷ５は、ベアラ確立手続き（Bearer　establishment　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ１１２）。次に、Ｓ－ＧＷ５は、ベアラリクエストレスポンス（Bearer　Request　Response）をＭＭＥ７へ送信する（ステップＳ１１４）。次いで、ＭＭＥ７は、アタッチ承認（Attach　Accepted）及びＵＲＮ２ＡのインタフェースＩＤ（URN-Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＤｅＮＢ３へ送信する（ステップＳ１１６）。次に、ＤｅＮＢ３は、アタッチ承認（Attach　Accepted）及びＵＲＮ２ＡのインタフェースＩＤ（URN-Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＲＮ２Ａへ送信する（ステップＳ１１８）。これにより、ＵＲＮ２Ａは、自身のインタフェース識別子（URN　Interface　ID）を取得する（ステップＳ１２０）。次いで、ＵＲＮ２Ａは、ラジオベアラレスポンス（Radio　Bearer　Response）をＤｅＮＢ３へ送信する（ステップＳ１２２）。次に、ＤｅＮＢ３は、ラジオベアラレスポンス（Radio　Bearer　Response）をＭＭＥ７へ送信する（ステップＳ１２４）。次いで、ＵＲＮ２Ａは、アタッチ完了（Attach　Complete）をＭＭＥ７へ送信する（ステップＳ１２６）。次に、ＵＲＮ２Ａは、アップリンクユーザプレーントラフィックデータを、ＤｅＮＢ３、Ｓ－ＧＷ５、及びＰ－ＧＷ６を経由してＰＤＮ１０へ送信する事が可能になる（ステップＳ１２８）。次いで、ＭＭＥ７は、ベアラ更新リクエスト（Bearer　Update　Request）をＳ－ＧＷ５へ送信する（ステップＳ１３０）。次に、Ｓ－ＧＷ５は、ベアラ更新手続き（Bearer　update　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ１３２）。次いで、Ｓ－ＧＷ５は、ベアラ更新レスポンス（Bearer　Update　Response）をＭＭＥ７へ送信する（ステップＳ１３４）。これで、ＰＤＮ１０から、ダウンリンクユーザプレーントラフィックデータを、Ｐ－ＧＷ６、Ｓ－ＧＷ５、及びＤｅＮＢ３を経由してＵＲＮ２Ａへ送信する事が可能になる（ステップＳ１３６）。次いで、ＵＲＮ２Ａは、ＲＳメッセージ（Router　Solicitation　Message）をＰ－ＧＷ６へ送信する（ステップＳ１３８）。次に、Ｐ－ＧＷ６は、ｐｒｅｆｉｘ／６４を含むＲＡメッセージ（Router　Advertisement　Message）をＵＲＮ２Ａへ送信する（ステップＳ１４０）。そして、ＵＲＮ２Ａは、ｐｒｅｆｉｘ／６４及びインタフェース識別子から成る、自身のＩＰｖ６アドレス（URN　IPv6　Address）を生成する（ステップＳ１４２）。
　　（２）ＵＥへのＩＰアドレスの割り当て
　次いで、ＵＲＮ２Ａの配下のＵＥ１へのＩＰアドレスの割り当てについて説明する。
　ＵＥ１も、上述したＵＲＮ２と同様にして、ＩＰアドレスが割り当てられ得る。とりわけ本実施形態においては、ＵＲＮ２は、ひとつ以上の配下のＵＥ１又はひとつ以上の配下のＵＲＮ２の各々に、プレフィクス部分の少なくとも一部が共通する（即ち、同一の）ＩＰアドレスを割り当てる。これにより、同一のＵＲＮ２に接続するひとつ以上のＵＥ１又はＵＲＮ２には、プレフィクス部分の少なくとも一部が共通するＩＰアドレスが割り当てられる。そして、配下のＵＥ１又はＵＲＮ２は、割り当てられたＩＰアドレスを用いてＵＲＮ２及びその上位のネットワーク（Ｐ－ＧＷ６等）との通信を行う。このプリフィックス部分は、ＩＰｖ６におけるサブネットプレフィクスであってもよい。例えば、サブネットプレフィクスは、ＩＰｖ６の１２８ビットのうち上位６４ビットであってもよく、このうち上位５６ビット（以下、Ｐｒｅｆｉｘ／５６とも表記する）が共通する部分であってもよい。
　例えば、ＵＲＮ２は、接続完了後、ＤＨＣＰ－ＰＤ（Ｐｒｅｆｉｘ　ｄｅｌｅｇａｔｉｏｎ）プロトコルを利用して、Ｐ－ＧＷ６又はＤＨＣＰサーバから、配下のＵＥ１に共通して割り当てるプレフィクス部分を取得する。そのために、Ｐ－ＧＷ６は、プレフィクス部分のうち共通する部分（ＩＰｖ６　Ｐｒｅｆｉｘ／５６）をＵＲＮ２へ通知する。ＵＲＮ２は、実際に接続要求してきたＵＥ１にＩＰアドレスを割り当てる際には、このＰｒｅｆｉｘ／５６に、例えば「００００　００００」の下位ビットを指定したＰｒｅｆｉｘ／６４を作成して、割り当ててもよい。なお、ＤＨＣＰ－ＰＤに関しては、「O.　Troan　and　R.　Droms.　IPv6　Prefix　Options　for　Dynamic　Host　Configuration　Protocol　(DHCP)　version　6,　December　2003.　RFC　3633.」において詳細に説明されている。
　例えば、ＵＥ１は、通常の手続きにおいて付与されたＩＤ（例えば、ＩＰｖ６のインタフェース識別子）を利用してリンクローカルアドレス（Link　Local　Address）を生成する。そして、ＵＥ１は、いわゆるＩＰプロトコルであるＲＳメッセージをＵＲＮ２へ送信して、ＵＲＮ２において生成されたＩＰアドレスのプレフィクス部分（Ｐｒｅｆｉｘ／６４）を取得してもよい。例えば、ＲＡメッセージに、Ｐｒｅｆｉｘ／６４が含まれていてもよい。また、ＵＥ１は、ＲＳメッセージ及びＲＡメッセージの代わりにＤＨＣＰプロトコルを用いて、ＤＨＣＰサーバからＵＥ１のＩＰアドレスを取得してもよい。その際、ＤＨＣＰサーバは、ＵＥ１の接続先のＵＲＮ２によりＤＨＣＰ－ＰＤにより取得されたＰｒｅｆｉｘ／５６に、例えば「００００　００００」の下位ビットを指定したＰｒｅｆｉｘ／６４を作成して、ＵＥ１へ通知し得る。このとき、ＵＥ１は、ＰＣＯなどを利用して、ＤＮＳサーバ又はＤＨＣＰサーバの接続情報、及び接続先のＵＲＮ２のＩＰアドレスを取得する事が可能である。このようにして、ＵＥ１は、自身にＩＰアドレスを割り当てることが可能となる。
　ここで、ネットワーク上に実現されるベアラトンネルごとに、各エンティティ（Ｐ－ＧＷ６、Ｓ－ＧＷ５及びＤｅＮＢ３等）上でのベアラ生成のためのマッピング表が作成され各エンティティで記憶され得る。３ＧＰＰでは、このマッピング表は、ＭＭＥ７から指示されて作成される。また、端末装置（例えば、ＵＥ１又はＵＲＮ２)の移動に伴い、ソースからターゲットのエンティティ（例えば、ＤｅＮＢ３又はＳ－ＧＷ５）へベアラを更新するようＭＭＥ７から指示され、これに伴いマッピング表も更新される。本実施形態では、ＵＲＮ２は、ＵＲＮ２に接続されるＵＥ１群のために、ＤＨＣＰ－ＰＤを用いて例えばＰｒｅｆｉｘ／５６を取得する。取得されたＰｒｅｆｉｘ／５６と取得したＵＲＮ２（例えば、ＭＭＥ７が端末の接続プロセス時に作成する識別情報（URN_ID）等）とを関連付ける情報が、Ｐ－ＧＷ６、Ｓ－ＧＷ５及びＤｅＮＢ３等が記憶するマッピング表に加えられることが望ましい。そのために、例えばＰｒｅｆｉｘ／５６を割当てたＰ－ＧＷ６は、当該関連付けのための情報をＳ－ＧＷ５及びＤｅＮＢ３へ通知してもよい。本メッセージを、以下ではルートセットアップとも称する。なお、ルートセットアップ及びマッピング表については、後に詳しく説明する。
　以下、図１６及び図１７を参照しながら、ＵＥ１へのＩＰアドレスの割り当て処理の具体的なシーケンスの一例を説明する。
　図１６及び図１７は、本実施形態に係るＵＥ１ＡへのＩＰアドレスの割り当て処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１Ａ、ＵＲＮ２Ａ、ＤｅＮＢ３、Ｓ－ＧＷ５、Ｐ－ＧＷ６、ＭＭＥ７及びＨＳＳ８、並びにＰＣＲＦ９が関与する。
　図１６に示すように、まず、ＵＲＮ２Ａは、例えば図１５を参照して上記説明した手続きにより、ネットワークへの接続を完了し、ＩＰアドレスを取得済みであるものとする（ステップＳ２０２）。次いで、ＵＲＮ２Ａは、ＵＥ１ＡのＩＰアドレスのプレフィクス部分(Prefix/56)を要求するＤＨＣＰ－ＰＤリクエスト（DHCP_PD　Request）をＰ－ＧＷ６へ送信する（ステップＳ２０４）。次に、Ｐ－ＧＷ６は、ＵＥ１ＡのＩＰアドレスのプレフィクス部分(Prefix/56)を含むＤＨＣＰ－ＰＤレスポンス（DHCP_PD　Response）をＵＲＮ２Ａへ送信する（ステップＳ２０６）。これにより、ＵＲＮ２Ａは、ＵＥ１ＡのＩＰアドレスのプレフィクス部分(Prefix/56)を取得する（ステップＳ２０８）。他方、Ｐ－ＧＷ６は、ＵＲＮ２Ａの識別情報（URN_ID）とプレフィクス部分（Prefix/56）とを関連付けるためのルートセットアップ（Route　Setup）をＳ－ＧＷ５へ送信する（ステップＳ２１０）。Ｓ－ＧＷ５は、このルートセットアップ（Route　Setup）をＭＭＥ７へ転送する（ステップＳ２１２）。ＭＭＥ７は、このルートセットアップ（Route　Setup）をＤｅＮＢ３へ転送する（ステップＳ２１４）。次に、ＵＥ１Ａは、アタッチリクエスト（Attach　Request　(PCO　IP　Address　Request)）をＭＭＥ７へ送信する（ステップＳ２１６）。次いで、ＵＥ１Ａは、識別、認証及び暗号化等（Identification／Authentication／Ciphered　option　etc.）を、ＵＲＮ２Ａ、ＤｅＮＢ３、ＭＭＥ７、及びＨＳＳ８との間で行う（ステップＳ２１８）。次に、ＭＭＥ７は、ロケーションリクエスト（Location　Request）をＨＳＳ８へ送信する（ステップＳ２２０）。次いで、ＨＳＳ８は、ロケーションリクエストレスポンス（Location　Request　Response）をＭＭＥ７へ送信する（ステップＳ２２２）。
　次に、図１７に示すように、ＭＭＥ７は、ベアラリクエスト（Bearer　Request）をＳ－ＧＷ５へ送信する（ステップＳ２２４）。次いで、Ｓ－ＧＷ５は、ベアラ確立手続き（Bearer　establishment　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ２２６）。次に、Ｓ－ＧＷ５は、ベアラリクエストレスポンス（Bearer　Request　Response）をＭＭＥ７へ送信する（ステップＳ２２８）。次いで、ＭＭＥ７は、アタッチ承認（Attach　Accepted）及びＵＥ１ＡのインタフェースＩＤ（UE-Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＤｅＮＢ３へ送信する（ステップＳ２３０）。次に、ＤｅＮＢ３は、アタッチ承認（Attach　Accepted）及びＵＥ１ＡのインタフェースＩＤ（UE-Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＲＮ２Ａへ送信する（ステップＳ２３２）。次いで、ＵＲＮ２Ａは、アタッチ承認（Attach　Accepted）及びＵＥ１ＡのインタフェースＩＤ（UE-Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＥ１Ａへ送信する（ステップＳ２３４）。これにより、ＵＥ１Ａは、自身のインタフェース識別子（UE　Interface　ID）を取得する（ステップＳ２３６）。次に、ＵＥ１Ａは、ラジオベアラレスポンス（Radio　Bearer　Response）をＵＲＮ２Ａへ送信する（ステップＳ２３８）。次いで、ＵＲＮ２Ａは、ラジオベアラレスポンス（Radio　Bearer　Response）をＤｅＮＢ３へ送信する（ステップＳ２４０）。次に、ＤｅＮＢ３は、ラジオベアラレスポンス（Radio　Bearer　Response）をＭＭＥ７へ送信する（ステップＳ２４２）。次いで、ＵＥ１Ａは、アタッチ完了（Attach　Complete）をＭＭＥ７へ送信する（ステップＳ２４４）。次に、ＵＥ１Ａは、アップリンクユーザプレーントラフィックデータを、ＵＲＮ２Ａ、ＤｅＮＢ３、Ｓ－ＧＷ５、及びＰ－ＧＷ６を経由してＰＤＮ１０へ送信することが可能になる（ステップＳ２４６）。次いで、ＭＭＥ７は、ベアラ更新リクエスト（Bearer　Update　Request）をＳ－ＧＷ５へ送信する（ステップＳ２４８）。次に、Ｓ－ＧＷ５は、ベアラ更新手続き（Bearer　update　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ２５０）。次いで、Ｓ－ＧＷ５は、ベアラ更新レスポンス（Bearer　Update　Response）をＭＭＥ７へ送信する（ステップＳ２５２）。これで、ＰＤＮ１０から、ダウンリンクユーザプレーントラフィックデータを、Ｐ－ＧＷ６、Ｓ－ＧＷ５、ＤｅＮＢ３、及びＵＲＮ２Ａを経由してＵＥ１Ａへ送信する事が可能になる（ステップＳ２５４）。次いで、ＵＥ１Ａは、ＲＳメッセージ（Router　Solicitation　Message）をＵＲＮ２Ａへ送信する（ステップＳ２５６）。次に、ＵＲＮ２Ａは、ｐｒｅｆｉｘ／６４を含むＲＡメッセージ（Router　Advertisement　Message）をＵＥ１Ａへ送信する（ステップＳ２５８）。そして、ＵＥ１Ａは、ｐｒｅｆｉｘ／６４及びインタフェース識別子から成る、自身のＩＰｖ６アドレス（UE　IPv6　Address）を生成する（ステップＳ２６０）。
　　（３）入れ子構造のＵＲＮに関するＩＰアドレスの割り当て
　次いで、入れ子構造のＵＲＮ２に関するＩＰアドレスの割り当てについて説明する。
　以下、図１８～図２１を参照しながら、入れ子構造のＵＲＮに関するＩＰアドレスの割り当て処理の具体的なシーケンスの一例を説明する。ここでは一例として、ＵＲＮ２Ａに接続するＵＲＮ２Ｂ、及びＵＲＮ２Ｂに接続するＵＥ１Ｂへの、ＩＰアドレスの割り当て処理の流れの一例を説明する。
　図１８～図２１は、本実施形態に係るＵＲＮ２Ａに接続するＵＲＮ２Ｂ、及びＵＲＮ２Ｂに接続するＵＥ１ＢへのＩＰアドレスの割り当て処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１Ｂ、ＵＲＮ２Ｂ、ＵＲＮ２Ａ、ＤｅＮＢ３、Ｓ－ＧＷ５、Ｐ－ＧＷ６、ＭＭＥ７及びＨＳＳ８、並びにＰＣＲＦ９が関与する。
　図１８に示すように、まず、ＵＲＮ２Ａは、例えば図１５を参照して上記説明した手続きにより、ネットワークへの接続を完了し、ＩＰアドレスを取得済みであるものとする（ステップＳ３０２）。次いで、ＵＲＮ２Ａは、ＵＲＮ２ＢのＩＰアドレスのプレフィクス部分(Prefix/56)を要求するＤＨＣＰ－ＰＤリクエスト（DHCP_PD　Request）をＰ－ＧＷ６へ送信する（ステップＳ３０４）。次に、Ｐ－ＧＷ６は、ＵＲＮ２ＢのＩＰアドレスのプレフィクス部分(Prefix/56)を含むＤＨＣＰ－ＰＤレスポンス（DHCP_PD　Response）をＵＲＮ２Ａへ送信する（ステップＳ３０６）。これにより、ＵＲＮ２Ａは、ＵＲＮ２ＢのＩＰアドレスのプレフィクス部分(Prefix/56)を取得する（ステップＳ３０８)。他方、Ｐ－ＧＷ６は、ＵＲＮ２Ｂの識別情報（URN_ID）とプレフィクス部分（Prefix/56）とを関連付けるためのルートセットアップ（Route　Setup）をＳ－ＧＷ５へ送信する（ステップＳ３１０)。Ｓ－ＧＷ５は、このルートセットアップ（Route　Setup）をＭＭＥ７へ転送する（ステップＳ３１２)。ＭＭＥ７は、このルートセットアップ（Route　Setup）をＤｅＮＢ３へ転送する（ステップＳ３１４)。次に、ＵＲＮ２Ｂは、アタッチリクエスト（Attach　Request　(PCO　IP　Address　Request)）をＭＭＥ７へ送信する（ステップＳ３１６)。次いで、ＵＲＮ２Ｂは、識別、認証及び暗号化等（Identification／Authentication／Ciphered　option　etc.）を、ＵＲＮ２Ａ、ＤｅＮＢ３、ＭＭＥ７、及びＨＳＳ８との間で行う（ステップＳ３１８)。次に、ＭＭＥ７は、ロケーションリクエスト（Location　Request）をＨＳＳ８へ送信する（ステップＳ３２０)。次いで、ＨＳＳ８は、ロケーションリクエストレスポンス（Location　Request　Response）をＭＭＥ７へ送信する（ステップＳ３２２)。
　次に、図１９に示すように、ＭＭＥ７は、ベアラリクエスト（Bearer　Request）をＳ－ＧＷ５へ送信する（ステップＳ３２４)。次いで、Ｓ－ＧＷ５は、ベアラ確立手続き（Bearer　establishment　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ３２６)。次に、Ｓ－ＧＷ５は、ベアラリクエストレスポンス（Bearer　Request　Response）をＭＭＥ７へ送信する（ステップＳ３２８)。次いで、ＭＭＥ７は、アタッチ承認（Attach　Accepted）及びＵＲＮ２ＢのインタフェースＩＤ（URN　Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＤｅＮＢ３へ送信する（ステップＳ３３０)。次に、ＤｅＮＢ３は、アタッチ承認（Attach　Accepted）及びＵＲＮ２ＢのインタフェースＩＤ（URN　Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＲＮ２Ａへ送信する（ステップＳ３３２)。次いで、ＵＲＮ２Ａは、アタッチ承認（Attach　Accepted）及びＵＲＮ２ＢのインタフェースＩＤ（URN　Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＲＮ２Ｂへ送信する（ステップＳ３３４)。これにより、ＵＲＮ２Ｂは、自身のインタフェース識別子（URN　Interface　ID）を取得する（ステップＳ３３６)。次に、ＵＲＮ２Ｂは、ラジオベアラレスポンス（Radio　Bearer　Response）をＵＲＮ２Ａへ送信する（ステップＳ３３８)。次いで、ＵＲＮ２Ａは、ラジオベアラレスポンス（Radio　Bearer　Response）をＤｅＮＢ３へ送信する（ステップＳ３４０)。次に、ＤｅＮＢ３は、ラジオベアラレスポンス（Radio　Bearer　Response）をＭＭＥ７へ送信する（ステップＳ３４２)。次いで、ＵＲＮ２Ｂは、アタッチ完了（Attach　Complete）をＭＭＥ７へ送信する（ステップＳ３４４)。これで、ＵＲＮ２Ｂは、アップリンクユーザプレーントラフィックデータを、ＵＲＮ２Ａ、ＤｅＮＢ３、Ｓ－ＧＷ５、及びＰ－ＧＷ６を経由してＰＤＮ１０へ送信することが可能になる（ステップＳ３４６)。次いで、ＭＭＥ７は、ベアラ更新リクエスト（Bearer　Update　Request）をＳ－ＧＷ５へ送信する（ステップＳ３４８)。次に、Ｓ－ＧＷ５は、ベアラ更新手続き（Bearer　update　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ３５０)。次いで、Ｓ－ＧＷ５は、ベアラ更新レスポンス（Bearer　Update　Response）をＭＭＥ７へ送信する（ステップＳ３５２)。これで、ＰＤＮ１０から、ダウンリンクユーザプレーントラフィックデータを、Ｐ－ＧＷ６、Ｓ－ＧＷ５、ＤｅＮＢ３、及びＵＲＮ２Ａを経由してＵＲＮ２Ｂへ送信する事が可能になる（ステップＳ３５４)。
　次いで、図２０に示すように、ＵＲＮ２Ｂは、ＲＳメッセージ（Router　Solicitation　Message）をＵＲＮ２Ａへ送信する（ステップＳ３５６)。次に、ＵＲＮ２Ａは、ｐｒｅｆｉｘ／６４を含むＲＡメッセージ（Router　Advertisement　Message）をＵＲＮ２Ｂへ送信する（ステップＳ３５８)。そして、ＵＲＮ２Ｂは、ｐｒｅｆｉｘ／６４及びインタフェース識別子から成る、自身のＩＰｖ６アドレス（URN　IPv6　Address）を生成する（ステップＳ３６０)。
　以上、ＵＲＮ２Ａに接続するＵＲＮ２ＢへのＩＰアドレスの割り当て処理について説明した。続いて、ＵＲＮ２Ｂに接続するＵＥ１ＢへのＩＰアドレスの割り当て処理について説明する。
　まず、ＵＥ１Ｂは、アタッチリクエスト（Attach　Request　(PCO　IP　Address　Request)）をＭＭＥ７へ送信する（ステップＳ４０２)。次いで、ＵＥ１Ｂは、識別、認証及び暗号化等（Identification／Authentication／Ciphered　option　etc.）を、ＵＲＮ２Ｂ、ＵＲＮ２Ａ、ＤｅＮＢ３、ＭＭＥ７、及びＨＳＳ８との間で行う（ステップＳ４０４)。次に、ＭＭＥ７は、ロケーションリクエスト（Location　Request）をＨＳＳ８へ送信する（ステップＳ４０６)。次いで、ＨＳＳ８は、ロケーションリクエストレスポンス（Location　Request　Response）をＭＭＥ７へ送信する（ステップＳ４０８)。
　次に、図２１に示すように、ＭＭＥ７は、ベアラリクエスト（Bearer　Request）をＳ－ＧＷ５へ送信する（ステップＳ４１０)。次いで、Ｓ－ＧＷ５は、ベアラ確立手続き（Bearer　establishment　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ４１２)。次に、Ｓ－ＧＷ５は、ベアラリクエストレスポンス（Bearer　Request　Response）をＭＭＥ７へ送信する（ステップＳ４１４)。次いで、ＭＭＥ７は、アタッチ承認（Attach　Accepted）及びＵＥ１ＢのインタフェースＩＤ（UE　Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＤｅＮＢ３へ送信する（ステップＳ４１６)。次に、ＤｅＮＢ３は、アタッチ承認（Attach　Accepted）及びＵＥ１ＢのインタフェースＩＤ（UE　Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＲＮ２Ａへ送信する（ステップＳ４１８)。次いで、ＵＲＮ２Ａは、アタッチ承認（Attach　Accepted）及びＵＥ１ＢのインタフェースＩＤ（UE　Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＲＮ２Ｂへ送信する（ステップＳ４２０)。次に、ＵＲＮ２Ｂは、アタッチ承認（Attach　Accepted）及びＵＥ１ＢのインタフェースＩＤ（UE　Interface　ID）を含むラジオベアラリクエスト（Radio　Bearer　Request）をＵＥ１Ｂへ送信する（ステップＳ４２２)。これにより、ＵＥ１Ｂは、自身のインタフェース識別子（UE　Interface　ID）を取得する（ステップＳ４２４)。次いで、ＵＥ１Ｂは、ラジオベアラレスポンス（Radio　Bearer　Response）をＵＲＮ２Ｂへ送信する（ステップＳ４２６)。次に、ＵＲＮ２Ｂは、ラジオベアラレスポンス（Radio　Bearer　Response）をＵＲＮ２Ａへ送信する（ステップＳ４２８)。次いで、ＵＲＮ２Ａは、ラジオベアラレスポンス（Radio　Bearer　Response）をＤｅＮＢ３へ送信する（ステップＳ４３０)。次に、ＤｅＮＢ３は、ラジオベアラレスポンス（Radio　Bearer　Response）をＭＭＥ７へ送信する（ステップＳ４３２)。次いで、ＵＥ１Ｂは、アタッチ完了（Attach　Complete）をＭＭＥ７へ送信する（ステップＳ４３４)。これで、ＵＥ１Ｂは、アップリンクユーザプレーントラフィックデータを、ＵＲＮ２Ｂ、ＵＲＮ２Ａ、ＤｅＮＢ３、Ｓ－ＧＷ５、及びＰ－ＧＷ６を経由してＰＤＮ１０へ送信する事が可能になる（ステップＳ４３６)。次いで、ＭＭＥ７は、ベアラ更新リクエスト（Bearer　Update　Request）をＳ－ＧＷ５へ送信する（ステップＳ４３８)。次に、Ｓ－ＧＷ５は、ベアラ更新手続き（Bearer　update　procedures）を、ＰＣＲＦ９、及びＰ－ＧＷ６との間で行う（ステップＳ４４０)。次いで、Ｓ－ＧＷ５は、ベアラ更新レスポンス（Bearer　Update　Response）をＭＭＥ７へ送信する（ステップＳ４４２)。これで、ＰＤＮ１０は、ダウンリンクユーザプレーントラフィックデータを、Ｐ－ＧＷ６、Ｓ－ＧＷ５、ＤｅＮＢ３、ＵＲＮ２Ａ、及びＵＲＮ２Ｂを経由してＵＥ１Ｂへ送信する事が可能になる（ステップＳ４４４)。次いで、ＵＥ１Ｂは、ＲＳメッセージ（Router　Solicitation　Message）をＵＲＮ２Ａへ送信する（ステップＳ４４６)。次に、ＵＲＮ２Ａは、ｐｒｅｆｉｘ／６４を含むＲＡメッセージ（Router　Advertisement　Message）をＵＥ１Ｂへ送信する（ステップＳ４４８)。そして、ＵＥ１Ｂは、ｐｒｅｆｉｘ／６４及びインタフェース識別子から成る、自身のＩＰｖ６アドレス（UE　IPv6　Address）を生成する（ステップＳ４５０)。
　ここで、プレフィクス部分は、入れ子構造のネットワークに対応して階層化されてもよい。図２２及び図２３を参照しながら、プレフィクス部分の階層化について説明する。
　図２２は、本実施形態に係るＩＰｖ６のプレフィクス部分の階層化を説明するための図である。図２２に示すように、ＩＰｖ６のＩＰアドレスは、１２８ビットある。そのうち上位ビットはプレフィクス部分とも称され、残りの下位ビットはインタフェース識別子とも称される。各々の長さは任意であるが、本明細書では共に６４ビットであるものとする。そして、この６４ビットのＩＰアドレスのプレフィクス部分のうち共通しない部分により、ＵＲＮ２又は他のＵＲＮ２により形成される複数の仮想セルの各々が識別されてもよい。例えば、上位部分１０１（図２２に示した例では５６ビット）が、最上位のＵＲＮ２によりプレフィクスデリゲーションされる領域である。また、中位部分１０２（図２２に示した例では２ビット）が、仮想ネットワークを識別するための領域である。なお、仮想ネットワークとは、複数の仮想セルを含む入れ子構造のネットワークである。また、下位部分１０３（図２２に示した例では６ビット）が、各仮想ネットワーク内の仮想セルを識別するための領域である。このような階層化により、例えば図２３に示した入れ子構造のネットワークが表現可能である。
　図２３は、入れ子構造のネットワークの一例を示す図である。図２３に示すように、ＤｅＮＢ３に複数の仮想ネットワークが接続されている。仮想ネットワーク「０」は、ＵＲＮ２Ａ－０を最上位とする仮想セルの集合である。仮想ネットワーク「１」は、ＵＲＮ２Ａ－１を最上位とする仮想セルの集合である。仮想ネットワーク「３」は、ＵＲＮ２Ａ－３を最上位とする仮想セルの集合である。この各々の仮想ネットワークが、中位部分１０２により識別される。
　仮想ネットワーク内には、複数の仮想セルが含まれている。以下、仮想ネットワーク「０」に着目して説明する。ＵＲＮ２Ａ－０により形成される仮想セルには、ＵＲＮ２Ｂ－０１により形成される仮想セル、及びＵＲＮ２Ｂ－０２により形成される仮想セルが接続されている。これらの仮想セルは、１段入れ子仮想セルとも称され得る。そして、ＵＲＮ２Ｂ－０２により形成される仮想セルには、ＵＲＮ２Ｃ－０により形成される仮想セルが接続されている。この仮想セルは、２段入れ子仮想セルとも称され得る。図示は省略されているが、３段以上の入れ子仮想セルがあってもよい。これらの、ひとつの仮想ネットワークに含まれる仮想セルが、下位部分１０３により識別される。他の仮想ネットワークに関しても、同様の説明が成り立つ。
　このような、ＩＰアドレスのプレフィクス部分の階層化により、個々の仮想セルが一意に識別されるので、後述するマッピング表（ルーティング表）を簡略化することが可能となる。さらに、下位に位置するセル又は端末の移動に際して、上位でのマッピング表の更新が必要なくなる。
　このような階層化を実現するためには、図１８～図２１に示したシーケンスのうち、破線の矩形「Ａ」部分が図２４に示すシーケンスに、破線の矩形「Ｃ」部分が図２５に示すシーケンスに、それぞれ置き換えられる。図２４及び図２５は、本実施形態に係るＵＲＮ２Ａに接続するＵＲＮ２Ｂ、及びＵＲＮ２Ｂに接続するＵＥ１ＢへのＩＰアドレスの割り当て処理の流れの一例を示すシーケンス図である。
　図２４に示すように、ＵＲＮ２Ｂは、自身のＩＰアドレスのプレフィクス部分(Prefix/60)を要求するＤＨＣＰ－ＰＤリクエスト（DHCP_PD　Request）をＵＲＮ２Ａへ送信する（ステップＳ３５６Ａ）。次に、ＵＲＮ２Ａは、ＵＲＮ２ＢのＩＰアドレスのプレフィクス部分(Prefix/60)を含むＤＨＣＰ－ＰＤレスポンス（DHCP_PD　Response）をＵＲＮ２Ｂへ送信する（ステップＳ３５８Ａ）。そして、ＵＲＮ２Ｂは、取得したプレフィクス部分(Prefix/60)に、例えば「００００」の下位ビットを指定してＰｒｅｆｉｘ／６４を作成して、ｐｒｅｆｉｘ／６４及びインタフェース識別子から成る、自身のＩＰｖ６アドレス（URN　IPv6　Address）を生成する（ステップＳ３６０Ａ)。
　ＵＲＮ２Ｂは、ステップＳ３５８Ａにおいて取得したＩＰアドレスのプレフィクス部分(Prefix/60)の下位４ビット分を用いて、配下のＵＲＮ２Ｃ等を階層化する。例えば、ＵＲＮ２Ｂは、配下の仮想セルごとに異なる下位４ビットを割り当てて、配下のＵＲＮ２Ｃ等からＤＨＣＰ＿ＰＤリクエストメッセージを受信した場合に、ＤＨＣＰ＿ＰＤレスポンスメッセージにより下位４ビットを割り当てたプレフィクス部分(Prefix/64)を返信する。このため、ＵＥ１は、仮想ネットワークの最上位のＵＲＮ２ではなく、接続するＵＲＮ２から、ＩＰアドレスのプレフィクス部分(Prefix/64)の指定を受けることとなる。この場合のシーケンスは、図２５に示す通りである。
　図２５に示すように、ＵＥ１Ｂは、ＲＳメッセージ（Router　Solicitation　Message）をＵＲＮ２Ｂへ送信する（ステップＳ４４６Ａ)。次に、ＵＲＮ２Ｂは、階層化したｐｒｅｆｉｘ／６４を含むＲＡメッセージ（Router　Advertisement　Message）をＵＥ１Ｂへ送信する（ステップＳ４４８Ａ)。そして、ＵＥ１Ｂは、ｐｒｅｆｉｘ／６４及びインタフェース識別子から成る、自身のＩＰｖ６アドレス（UE　IPv6　Address）を生成する（ステップＳ４５０Ａ)。
　ここで、図２６に示すように、ＵＥ１からＵＲＮ２、ＤｅＮＢ３、及びＳ－ＧＷ５を経たＰ－ＧＷ６までの間には、ベアラが設定される。図２６は、ＵＥ１からＰ－ＧＷ６までの間に設定されるベアラ及びＴＦＴ（Traffic　Flow　Template）の一例を示す図である。
　配下のＵＥ１又は配下のＵＲＮ２とＰ－ＧＷ６との間に設定される伝送路のうち、ＵＲＮ２とＰ－ＧＷ６との間の区間に、ＵＲＮ２とＰ－ＧＷ６との間で設定される伝送路が流用されてもよい。なお、ここでの伝送路はベアラであってもよいし、ベアラレスのネットワークであればＩＰフローであってもよい。図１８～図２１に示したシーケンスに関して言えば、破線の矩形「Ｂ－２」で確立されるＰ－ＧＷ６からＵＥ１Ｂまでのベアラは、破線の矩形「Ｂ－１」で確立されるＰ－ＧＷ６からＵＲＮ２Ａまでのベアラを流用してもよい。これにより、ＵＲＮ２に接続するＵＥ１群、即ちＩＰアドレスのプレフィクス部分が共通するＵＥ１群のベアラが集約されることが可能となり、ベアラの確立に伴うシグナリング量を大幅に削減することが可能となる。以下、図２７を参照しながら、このような仮想セルのベアラ構成について説明する。
　図２７は、仮想セルのベアラ構成の一例を示す図である。図２７に示すように、ＵＲＮ２とＵＥ１との間には、デフォルトベアラ及び専用（dedicated）ベアラがそれぞれ確立されている。一方で、ＵＥ１とＰ－ＧＷ６との間には、ＵＥ１ごとの個別のデフォルトベアラ及び専用ベアラは確立されていない。その代わりに、ＵＲＮ２とＵＥ１との間に確立されたデフォルトベアラ及び専用ベアラが、ＵＲＮ２とＰ－ＧＷ６との間に確立された専用ベアラにマッピングされている。これにより、ＵＥ１は、個々にＵＲＮ２からＰ－ＧＷ６までのベアラを確立せずとも、接続先のＵＲＮ２がＰ－ＧＷ６との間で確立した専用ベアラを利用することが可能となる。
　ここで、ＵＲＮ２とＰ－ＧＷ６との間で確立されたひとつの専用ベアラは、配下の複数のＵＥ１により流用（即ち、共有）されてもよいし、ひとつのＵＥ１により個別に流用されてもよい。例えば、ＵＥ１群のデフォルトベアラ及び「Policy-1」の専用ベアラの各々は、ＵＲＮ２とＰ－ＧＷ６との間で確立されたひとつの専用ベアラにマッピングされている。一方で、ＵＥ１群のデフォルトベアラ「＃１」及び「＃ｍ」の各々は、ＵＲＮ２とＰ－ＧＷ６との間で確立された異なる専用ベアラにマッピングされている。
　ＵＲＮ２は、自身のデフォルトベアラを個別に利用する。ＵＲＮ２は、配下のＵＥ１又は配下のＵＲＮ２のために、複数の専用ベアラを、例えば帯域又はＱｏＳ等のポリシー毎に確立及び確保してもよい。
　もちろん、ＵＥ１は、ＵＲＮ２とＰ－ＧＷ６との間で確立されるベアラを流用することなく、Ｐ－ＧＷ６との間でベアラを確立してもよい。
　上述したシーケンスを参照して説明すると、例えば図１５に示したシーケンスのうち破線の矩形「Ａ」部分においてＵＲＮ２からＰ－ＧＷ６までのベアラが確立される際、ＵＲＮ２は、今後自身に接続してくるＵＥ１のために、予め複数の専用ベアラを確立及び確保する。そして、図１６及び図１７に示したシーケンスのうち破線の矩形「Ａ」の部分においてＵＥ１がベアラを確立する際には、ＵＥ１とＵＲＮ２との間のラジオベアラのみが新規に確立され、ＵＲＮ２からＰ－ＧＷ６までのベアラは、予め確立され確保されたものが利用される。この新規に確立されるラジオベアラは、図１７のステップＳ２４６及びステップＳ２５４における太字破線部分に相当する。図１８～図２１に示したシーケンスに関しても同様である。
　もちろん、提案プロトコルは、既存の３ＧＰＰのＥＰＣに準拠しない次世代のネットワークのアーキテクチャにも適用可能である。そのようなアーキテクチャについて、図２８及び図２９を参照して説明する。
　図２８及び図２９は、次世代ネットワークのアーキテクチャの一例を示す図である。図２８では、いわゆるピュアＩＰネットワークにより実現されるベアラレスなネットワークのアーキテクチャを示している。この場合、ベアラの役割をＩＰフローが担うこととなる。本アーキテクチャにおいても、プレフィクス部分を共通化することで、モバイルＩＰ等の仕組みが無くても、ＵＲＮ２に接続されるＵＥ１群のＩＰ透過性が実現可能となる。図２９は、制御プレーンとユーザプレーンとが、クラウドを利用して分離されるアーキテクチャを示している。
　　＜３．２．ハンドオーバ時のネットワーク層ＩＰアドレスの取り扱い＞
　以下、図３０～図３６を参照して、ＵＥ１又はＵＲＮ２移動に伴うハンドオーバ時のネットワーク層ＩＰアドレスの取り扱いについて説明する。本節では、ネットワーク層ＩＰアドレスのことを、単にＩＰアドレスとも称する。
　図３０は、ハンドオーバ時のＩＰアドレスの取り扱いを説明するための図である。本節では、図３０に示したネットワーク構成の遷移に伴う、ハンドオーバ時のＩＰアドレスの取り扱いを説明する。図３０に示すように、ＵＥ１は、ｅＮＢ４に最初に接続されている。符号１１１に示すハンドオーバは、ＵＥ１のハンドオーバである。符号１１２～符号１１４に示すハンドオーバは、ＵＲＮ２Ａのハンドオーバである。ここで、リレーノードがハンドオーバする手続きに関しては、３ＧＰＰでは明確には定義されていない。
　　（１）符号１１１に示すハンドオーバ
　ＵＥ１は、ｅＮＢ４からＵＲＮ２Ａへハンドオーバする。ＵＥ１は、ｅＮＢ４への接続時に行ったアタッチ手続きによりＩＰアドレスを取得済みである。そのため、ＵＥ１は、３ＧＰＰのハンドオーバの枠組みに従い、ハンドオーバ後もハンドオーバ前に取得したＩＰアドレスを継続して利用する。従って、ＵＥ１は、ハンドオーバ後、ＵＲＮ２Ａの仮想セルに最初に接続するＵＥに割当てられるプレフィクス部分（Prefix/56）が共通するＩＰアドレスとは、異なるＩＰアドレスを利用することとなる。なお、アタッチ手続きにより、Ｐ－ＧＷ６までのＥＰＳベアラは更新される。
　ＵＥ１は、すでにＩＰアドレスを取得済みであって、アタッチ手続きが完了してハンドオーバ後の仮想セルのプレフィクス部分を含んだＩＰアドレスを生成した場合、ＵＲＮ２Ａへのアタッチ手続きが完了した時刻を記憶する。そして、ＵＥ１は、記憶したＵＲＮ２Ａへのアタッチ手続きが完了した時刻よりも後に開かれるソケットにはハンドオーバ後に新たに割り当てられたＩＰアドレス（即ち、第１のネットワーク層ＩＰアドレス）を用いる。他方、ＵＥ１は、記憶したＵＲＮ２へのアタッチ手続きが完了した時刻よりも前に開かれたソケットには、ハンドオーバ前に割り当てられたＩＰアドレス（即ち、第２のネットワーク層ＩＰアドレス）を継続的に用いる。よって、記憶した時刻以前にオープンされたソケットがクローズされれば、ハンドオーバ前に取得したＩＰアドレスの利用が終了したこととなる。これにより、ＵＥ１は、ハンドオーバ後、時間経過と共に新たなＩＰアドレスを利用することが可能となり、ベアラの共通化、後述するマッピング表の活用等のメリットを享受することが可能となる。ＵＥ１は、ハンドオーバ前に割り当てられたＩＰアドレスを用いたソケットが閉じられたこと、即ちハンドオーバ前に割り当てられたＩＰアドレスの利用が終了したことを示す情報を、接続中のＵＲＮ２Ａへ通知してもよい。これにより、後述するマッピング表の情報量が削減可能となり、また仮想セル内のルーティングの階層化等が実現される。
　また、ＵＥ１は、新たなＩＰアドレスを利用する際、仮想セルの最上位に位置するＵＲＮ２Ａがアタッチ手続きで予め仮想セル内のＵＥ１群用に確立及び確保したベアラを利用することとなる。基本的には、アタッチ手続きにより、ＭＭＥ７でベアラの更新が行われ、ＵＥ１毎及びＵＲＮ２毎に専用のＥＰＳベアラが確立される。それぞれのベアラは、ＧＴＰ（GPRS（General　Packet　Radio　Service）　Tunneling　Protocol）のＴＥＩＤ（Tunnel　Endpoint　Identifier）並びにラジオベアラＩＤでマッピングされて、確立されることになる。ここで、Ｐ－ＧＷ６、Ｓ－ＧＷ５、ＤｅＮＢ３及びＵＲＮ２で管理されるマッピング表に関しては、後に詳細に説明する。
　　（２）符号１１２に示すハンドオーバ
　ＵＲＮ２Ａは、ＤｅＮＢ３ＡからＤｅＮＢ３Ｂへハンドオーバする。このハンドオーバは、Ｓ－ＧＷ５の切り替えを伴なわない、ＤｅＮＢ３間の論理パス(X2　Interface)を利用したハンドオーバである。ここでは、ＵＲＮ２ＡはＵＥ１として振る舞い、ＤｅＮＢ３ＡからＤｅＮＢ３Ｂへの基地局間ハンドオーバが行われる。
　ＵＲＮ２Ａは、３ＧＰＰのハンドオーバの枠組みに従い、ハンドオーバ後もハンドオーバ前に割り当てられたＩＰアドレスを継続して利用する。これに伴い、ＵＲＮ２Ａの配下のＵＥ１群も、ＵＲＮ２Ａのハンドオーバ後も、ハンドオーバ前に割り当てられたＩＰアドレスを継続して利用する。
　ここで、ＵＲＮ２は、ＵＲＮ２自身がハンドオーバを開始すること（又は、試みていること）を示す情報を配下のＵＥ１群へ通知してもよい（例えば、図３１におけるステップＳ５１４）。また、ＵＲＮ２は、ＵＲＮ２自身がハンドオーバを完了したことを示す情報を配下のＵＥ１群へ通知してもよい（例えば、図３２におけるステップＳ５４４）。これにより、配下の装置は、ＵＲＮ２Ａのハンドオーバ中に、他のＵＲＮ２へのハンドオーバに移行しないようにすることが可能となる。例えば、ＵＥ１は、接続先のＵＲＮ２Ａがハンドオーバを行うことが通知されると、ハンドオーバタイマー等を起動させて、ＵＲＮ２がハンドオーバを開始してから所定期間、他のネットワークへのアタッチ手続きを抑止してもよい。これにより、不要なハンドオーバ手続にかかるシグナリングが抑制可能となる。ハンドオーバ完了後は、仮想セル内のＵＥ１群がそれぞれにアタッチ手続きを試みる必要はない。
　以下、図３１及び図３２を参照して、上記説明した符号１１２に示すハンドオーバにおける処理の流れの一例を説明する。
　図３１及び図３２は、本実施形態に係るＵＲＮ２によるハンドオーバ処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１群、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＤｅＮＢ３Ｂ、ＭＭＥ７、Ｓ－ＧＷ５及びＰ－ＧＷ６が関与する。また、ＵＥ１群とＵＲＮ２Ａとは、仮想セルを形成している。また、ＤｅＮＢ３ＡがソースＤｅＮＢであり、ＤｅＮＢ３ＢがターゲットＤｅＮＢである。
　図３１に示すように、まず、ＵＥ１群、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、Ｓ－ＧＷ５Ａ及びＰ－ＧＷ６は、アップリンク及びダウンリンクユーザプレーントラフィックデータを送受信している状態である（ステップＳ５０２）。次いで、ＵＲＮ２Ａは、メジャメントレポート（RCC-URN：Measurement　Report）をＤｅＮＢ３Ａへ送信する（ステップＳ５０４）。次に、ＤｅＮＢ３Ａは、ハンドオーバ判定（Handover　Decision）を行う（ステップＳ５０６）。次いで、ＤｅＮＢ３Ａは、ハンドオーバリクエスト（X2-AP：Handover　Request）をＤｅＮＢ３Ｂへ送信する（ステップＳ５０８）。次に、ＤｅＮＢ３Ｂは、ハンドオーバリクエストＡＣＫ（X2-AP：Handover　Request　Ack）をＤｅＮＢ３Ａへ送信する（ステップＳ５１０）。次いで、ＤｅＮＢ３Ａは、ハンドオーバコマンド（RCC-URN：Handover　Command）をＵＲＮ２Ａへ送信する（ステップＳ５１２）。次に、ＵＲＮ２Ａは、ハンドオーバ通知（RCC-UEs：Handover　Notification）を配下のＵＥ１群へ送信する（ステップＳ５１４）。これにより、ＵＥ１群は、ハンドオーバタイマーをスタートして状態を保留し（UEs　State　Hold／HO-Timer　Start）、他のＵＲＮ２へのハンドオーバを抑制する（ステップＳ５１６）。次いで、ＤｅＮＢ３Ａは、ハンドオーバ実行（Handover　Execution）のために、ＤｅＮＢ３Ｂへのデータの転送（Forwarding　of　data）を行う（ステップＳ５１８）。
　次に、図３２に示すように、ＤｅＮＢ３Ｂは、ハンドオーバ完了（Handover　Completion）のために、ダウンリンクデータ（Downlink　data）をＵＲＮ２Ａへ送信する（ステップＳ５２０）。これで、ＵＲＮ２Ａは、アップリンクユーザプレーントラフィックデータを、ＤｅＮＢ３Ｂ、及びＳ－ＧＷ５Ａを経由してＰ－ＧＷ６へ送信する事が可能になる（ステップＳ５２２）。次に、ＤｅＮＢ３Ｂは、パススイッチリクエスト（Path　Switch　Request）をＭＭＥ７へ送信する（ステップＳ５２４）。次いで、ＭＭＥ７は、ベアラ変更リクエスト（Modify　Bearer　Request）をＳ－ＧＷ５Ａへ送信する（ステップＳ５２６）。次に、Ｓ－ＧＷ５Ａは、Ｐ－ＧＷ６との間でベアラ変更手続き（Modify　Bearer　procedures）を行う（ステップＳ５２８）。次いで、Ｓ－ＧＷ５Ａは、ベアラ変更レスポンス（Modify　Bearer　Response）をＭＭＥ７へ送信する（ステップＳ５３０）。これで、Ｐ－ＧＷ６は、ダウンリンクユーザプレーントラフィックデータを、Ｓ－ＧＷ５Ａ及びＤｅＮＢ３Ｂを経由してＵＲＮ２Ａへ送信する事が可能になる（ステップＳ５３２）。次いで、Ｓ－ＧＷ５Ａは、エンドマーカー（End　Marker）をＤｅＮＢ３Ａへ送信する（ステップＳ５３４）。次に、ＤｅＮＢ３Ａは、エンドマーカー（End　Marker）をＤｅＮＢ３Ｂへ送信する（ステップＳ５３６）。次いで、ＭＭＥ７は、パススイッチリクエストＡＣＫ（Path　Switch　Request　Ack）をＤｅＮＢ３Ｂへ送信する（ステップＳ５３８）。次に、ＤｅＮＢ３Ｂは、リリースリソース（Release　Resource）をＤｅＮＢ３Ａへ送信する（ステップＳ５４０）。次いで、ＵＲＮ２Ａは、ＤｅＮＢ３Ｂ及びＭＭＥ７との間でトラッキング及びアドレス等の更新手続き（Tracking／Address／etc．　Update　Procedures）を行う（ステップＳ５４２）。次に、ＵＲＮ２Ａは、ハンドオーバ完了（RCC-UEs：Handover　Completion）を配下のＵＥ１群へ送信する（ステップＳ５４４）。これにより、ＵＥ１群は、ハンドオーバタイマーを停止して状態を開放する（UEs　State　 Release／HO-Timer　Stop）（ステップＳ５４６）。次いで、ＵＥ１群、ＵＲＮ２Ａ、ＤｅＮＢ３Ｂ、Ｓ－ＧＷ５Ａ及びＰ－ＧＷ６は、アップリンク及びダウンリンクユーザプレーントラフィックデータを送受信する（ステップＳ５４８）。
　　（３）符号１１３に示すハンドオーバ
　ＵＲＮ２Ａは、ＤｅＮＢ３ＡからＵＲＮ２Ｂへハンドオーバする。ここでのハンドオーバは、図３１及び図３２を参照して上記説明した、符号１１２に示したハンドオーバと同様の手続きにより行われ得る。
　例えば、ＵＲＮ２Ａは、３ＧＰＰのハンドオーバの枠組みに従い、ハンドオーバ後もハンドオーバ前に割り当てられたＩＰアドレスを継続して利用する。これに伴い、ＵＲＮ２Ａの配下のＵＥ１群も、ＵＲＮ２Ａのハンドオーバ後も、ハンドオーバ前に割り当てられたＩＰアドレスを継続して利用する。
　例えば、ＵＲＮ２Ａは、ハンドオーバを試みていること、及びハンドオーバ完了の報告を、配下のＵＥ１群に通知してもよい。配下のＵＥ１群の動作も上述した通りである。
　　（４）符号１１４に示すハンドオーバ
　ＵＲＮ２Ａは、ＵＲＮ２ＢからＤｅＮＢ３Ｃへハンドオーバする。このハンドオーバは、Ｓ－ＧＷ５ＡからＳ－ＧＷ５Ｂへの変更を含む、ＤｅＮＢ３間の論理パス（X2　Interface）を利用したハンドオーバである。ここでは、ＵＲＮ２ＡはＵＥ１として振る舞い、ＵＲＮ２ＢからＤｅＮＢ３Ｃへの基地局間ハンドオーバが行われる。基本的には、ＵＲＮ２ＢをソースＤｅＮＢとし、ＤｅＮＢ３ＣをターゲットＤｅＮＢとして、３ＧＰＰの仕組みが応用される。即ち、ここでのハンドオーバも、上記説明した各ハンドオーバと同様の手続きにより行われ得る。
　例えば、ＵＲＮ２Ａは、３ＧＰＰのハンドオーバの枠組みに従い、ハンドオーバ後もハンドオーバ前に割り当てられたＩＰアドレスを継続して利用する。これに伴い、ＵＲＮ２Ａの配下のＵＥ１群も、ＵＲＮ２Ａのハンドオーバ後も、ハンドオーバ前に割り当てられたＩＰアドレスを継続して利用する。
　例えば、ＵＲＮ２Ａは、ハンドオーバを試みていること、及びハンドオーバ完了の報告を、配下のＵＥ１群に通知してもよい。配下のＵＥ１群の動作も上述した通りである。
　以下、図３３及び図３４を参照して、上記説明した符号１１３に示すハンドオーバにおける処理の流れの一例を説明する。
　図３３及び図３４は、本実施形態に係るＵＲＮ２によるハンドオーバ処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１群、ＵＲＮ２Ａ、ＵＲＮ２Ｂ、ＤｅＮＢ３Ｃ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、Ｓ－ＧＷ５Ｂ及びＰ－ＧＷ６が関与する。また、ＵＥ１群とＵＲＮ２Ａとは、仮想セルを形成している。また、ＵＲＮ２ＢがソースＤｅＮＢであり、ＤｅＮＢ３ＣがターゲットＤｅＮＢである。また、Ｓ－ＧＷ５ＡがソースＳ－ＧＷであり、Ｓ－ＧＷ５ＢがターゲットＳ－ＧＷである。
　図３３に示すように、まず、ＵＥ１群、ＵＲＮ２Ａ、ＵＲＮ２Ｂ、Ｓ－ＧＷ５Ａ及びＰ－ＧＷ６は、アップリンク及びダウンリンクユーザプレーントラフィックデータを送受信が可能な初期状態とする（ステップＳ６０２）。次いで、ＵＲＮ２Ａは、メジャメントレポート（RCC-URN：Measurement　Report）をＵＲＮ２Ｂへ送信する（ステップＳ６０４）。次に、ＵＲＮ２Ｂは、ハンドオーバ判定（Handover　Decision）を行う（ステップＳ６０６）。次いで、ＵＲＮ２Ｂは、ハンドオーバリクエスト（X2-AP：Handover　Request）をＤｅＮＢ３Ｃへ送信する（ステップＳ６０８）。次に、ＤｅＮＢ３Ｃは、ハンドオーバリクエストＡＣＫ（X2-AP：Handover　Request　Ack）をＵＲＮ２Ｂへ送信する（ステップＳ６１０）。次いで、ＵＲＮ２Ｂは、ハンドオーバコマンド（RCC-URN：Handover　Command）をＵＲＮ２Ａへ送信する（ステップＳ６１２）。次に、ＵＲＮ２Ａは、ハンドオーバ通知（RCC-UEs：Handover　Notification）を配下のＵＥ１群へ送信する（ステップＳ６１４）。これにより、ＵＥ１群は、ハンドオーバタイマーをスタートして状態を保留し（UEs　State　Hold／HO-Timer　Start）、他のＵＲＮ２へのハンドオーバを抑制する（ステップＳ６１６）。次いで、ＵＲＮ２Ｂは、ハンドオーバ実行（Handover　Execution）のために、ＤｅＮＢ３Ｃへのデータの転送（Forwarding　of　data）を行う（ステップＳ６１８）。
　次に、図３４に示すように、ＤｅＮＢ３Ｃは、ハンドオーバ完了（Handover　Completion）のために、ダウンリンクデータ（Downlink　data）をＵＲＮ２Ａへ送信する（ステップＳ６２０）。これで、ＵＲＮ２Ａは、アップリンクユーザプレーントラフィックデータを、ＤｅＮＢ３Ｃ、及びＳ－ＧＷ５Ａを経由してＰ－ＧＷ６へ送信する事が可能になる（ステップＳ６２２）。次に、ＤｅＮＢ３Ｃは、パススイッチリクエスト（Path　Switch　Request）をＭＭＥ７へ送信する（ステップＳ６２４）。次いで、ＭＭＥ７は、セッション生成リクエスト（Create　Session　Request）をＳ－ＧＷ５Ｂへ送信する（ステップＳ６２６）。次に、Ｓ－ＧＷ５Ｂは、Ｐ－ＧＷ６との間でベアラ変更手続き（Modify　Bearer　procedures）を行う（ステップＳ６２８）。次いで、Ｓ－ＧＷ５Ｂは、セッション生成レスポンス（Create　Session　Response）をＭＭＥ７へ送信する（ステップＳ６３０）。次に、Ｐ－ＧＷ６は、ダウンリンクユーザプレーントラフィックデータを、Ｓ－ＧＷ５Ｂ及びＤｅＮＢ３Ｃを経由してＵＲＮ２Ａへ送信する（ステップＳ６３２）。次いで、ＭＭＥ７は、パススイッチリクエストＡＣＫ（Path　Switch　Request　Ack）をＤｅＮＢ３Ｃへ送信する（ステップＳ６３４）。次に、ＵＲＮ２Ａは、アップリンクユーザプレーントラフィックデータを、ＤｅＮＢ３Ｃ、及びＳ－ＧＷ５Ｂを経由してＰ－ＧＷ６へ送信する（ステップＳ６３６）。次いで、ＤｅＮＢ３Ｃは、リリースリソース（Release　Resource）をＵＲＮ２Ｂへ送信する（ステップＳ６３８）。次に、ＭＭＥ７は、セッション削除リクエスト（Delete　Session　Request）をＳ－ＧＷ５Ａへ送信する（Ｓ６４０）。次いで、Ｓ－ＧＷ５Ａは、セッション削除レスポンス（Delete　Session　Response）をＭＭＥ７へ送信する（Ｓ６４２）。次に、ＵＲＮ２Ａは、ＤｅＮＢ３Ｃ及びＭＭＥ７との間でトラッキング及びアドレス等の更新手続き（Tracking／Address／etc．　Update　Procedures）を行う（ステップＳ６４４）。次に、ＵＲＮ２Ａは、ハンドオーバ完了（RCC-UEs：Handover　Completion）を配下のＵＥ１群へ送信する（ステップＳ６４６）。これにより、ＵＥ１群は、ハンドオーバタイマーを停止して状態を開放する（UEs　State　 Release／HO-Timer　Stop）（ステップＳ６４８）。これで、ＵＥ１群、ＵＲＮ２Ａ、ＤｅＮＢ３Ｃ、Ｓ－ＧＷ５Ｂ及びＰ－ＧＷ６は、アップリンク及びダウンリンクユーザプレーントラフィックデータを送受信する事が可能になる（ステップＳ６５０）。
　以上、Ｘ２インタフェースを利用したハンドオーバの手続きを説明してきたが、もちろんＳ１インタフェースを利用したハンドオーバの手続きであってもよい。その一例として、符号１１４に示すハンドオーバがＳ１インタフェースを利用して行われる場合の処理を、図３５及び図３６を参照して説明する。
　図３５及び図３６は、本実施形態に係るＵＲＮ２によるハンドオーバ処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１群、ＵＲＮ２Ａ、ＵＲＮ２Ｂ、ＤｅＮＢ３Ｃ、ＭＭＥ７Ａ、ＭＭＥ７Ｂ、Ｓ－ＧＷ５Ａ、Ｓ－ＧＷ５Ｂ及びＰ－ＧＷ６が関与する。また、ＵＥ１群とＵＲＮ２Ａとは、仮想セルを形成している。また、ＵＲＮ２ＢがソースＤｅＮＢであり、ＤｅＮＢ３ＣがターゲットＤｅＮＢである。また、Ｓ－ＧＷ５ＡがソースＳ－ＧＷであり、Ｓ－ＧＷ５ＢがターゲットＳ－ＧＷである。また、ＭＭＥ７ＡがソースＭＭＥであり、ＭＭＥ７ＢがターゲットＭＭＥである。
　図３５に示すように、まず、ＵＥ１群、ＵＲＮ２Ａ、ＵＲＮ２Ｂ、Ｓ－ＧＷ５Ａ及びＰ－ＧＷ６は、アップリンク及びダウンリンクユーザプレーントラフィックデータを送受信が可能な初期状態とする（ステップＳ７０２）。次いで、ＵＲＮ２Ａは、メジャメントレポート（RCC-URN：Measurement　Report）をＵＲＮ２Ｂへ送信する（ステップＳ７０４）。次に、ＵＲＮ２Ｂは、Ｓ１インタフェースを利用するハンドオーバ判定（Handover　Decision　via　S1）を行う（ステップＳ７０６）。次いで、ＵＲＮ２Ｂは、ハンドオーバリクエスト（S1-AP：Handover　Required）をＭＭＥ７Ａへ送信する（ステップＳ７０８）。次に、ＭＭＥ７Ａは、フォワードリロケーションリクエスト（Forward　Relocation　Request）をＭＭＥ７Ｂへ送信する（ステップＳ７１０）。次いで、ＭＭＥ７Ｂは、セッション生成リクエスト（Create　Session　Request）をＳ－ＧＷ５Ｂへ送信する（ステップＳ７１２）。次に、Ｓ－ＧＷ５Ｂは、セッション生成レスポンス（Create　Session　Response）をＭＭＥ７Ｂへ送信する（ステップＳ７１４）。次いで、ＭＭＥ７Ｂは、ハンドオーバリクエスト（Handover　Request）をＤｅＮＢ３Ｃへ送信する（ステップＳ７１６）。次に、ＤｅＮＢ３Ｃは、ハンドオーバリクエストＡＣＫ（Handover　Request　Ack）をＭＭＥ７Ｂへ送信する（ステップＳ７１８）。次いで、ＭＭＥ７Ｂは、インダイレクトデータ転送トンネル生成リクエスト（Create　Indirect　Data　Forwarding　Tunnel　Request）をＳ－ＧＷ５Ｂへ送信する（ステップＳ７２０）。次に、Ｓ－ＧＷ５Ｂは、インダイレクトデータ転送トンネル生成レスポンス（Create　Indirect　Data　Forwarding　Tunnel　Response）をＭＭＥ７Ｂへ送信する（ステップＳ７２２）。次いで、ＭＭＥ７Ｂは、フォワードリロケーションレスポンス（Forward　Relocation　Response）をＭＭＥ７Ａへ送信する（ステップＳ７２４）。次に、ＭＭＥ７Ａは、インダイレクトデータ転送トンネル生成リクエスト（Create　Indirect　Data　Forwarding　Tunnel　Request）をＳ－ＧＷ５Ａへ送信する（ステップＳ７２６）。次いで、Ｓ－ＧＷ５Ａは、インダイレクトデータ転送トンネル生成レスポンス（Create　Indirect　Data　Forwarding　Tunnel　Response）をＭＭＥ７Ａへ送信する（ステップＳ７２８）。次に、ＭＭＥ７Ａは、ハンドオーバコマンド（Handover　Command）をＵＲＮ２Ｂへ送信する（ステップＳ７３０）。次いで、ＵＲＮ２Ｂは、ハンドオーバコマンド（RCC-URN：Handover　Command）をＵＲＮ２Ａへ送信する（ステップＳ７３２）。次に、ＵＲＮ２Ａは、ハンドオーバ通知（RCC-UEs：Handover　Notification）を配下のＵＥ１群へ送信する（ステップＳ７３４）。これにより、ＵＥ１群は、ハンドオーバタイマーをスタートして状態を保留し（UEs　State　Hold／HO-Timer　Start）、他のＵＲＮ２へのハンドオーバを抑制する（ステップＳ７３６）。次いで、ＵＲＮ２Ｂは、基地局ステータス移転（eNB　Status　Transfer）をＭＭＥ７Ａへ送信する（ステップＳ７３８）。次に、ＭＭＥ７Ａは、フォワードアクセスコンテキスト通知（Forward　Access　Context　Notification）をＭＭＥ７Ｂへ送信する（ステップＳ７４０）。次いで、ＭＭＥ７Ｂは、フォワードアクセスコンテキスト承認（Forward　Access　Context　Acknowledge）をＭＭＥ７Ａへ送信する（ステップＳ７４２）。次に、ＭＭＥ７Ｂは、基地局ステータス移転（eNB　Status　Transfer）をＤｅＮＢ３Ｃへ送信する（ステップＳ７４４）。次いで、ＵＲＮ２Ｂは、ダイレクト転送データのみ（Only　for　Direct　forwarding　of　data）をＤｅＮＢ３Ｃへ送信する（ステップＳ７４６）。次に、ＵＲＮ２Ｂは、インダイレクト転送データの場合は（Only　for　Indirect　forwarding　of　data）をＳ－ＧＷ５Ａ及びＳ－ＧＷ５Ｂを経由してＤｅＮＢ３Ｃへ送信する（ステップＳ７４８）。
　次いで、図３６に示すように、ＵＲＮ２Ａは、ＵＲＮ２Ｂ、ＤｅＮＢ３Ｃ、ＭＭＥ７Ａ及びＭＭＥ７Ｂとの間で、古いセルからのデタッチ及び新たなセルへの同期（Detach　from　old　cell　and　synchronize　to　new　cell）を行う（ステップＳ７５０）。次に、ＵＲＮ２Ａは、ハンドオーバ確認（Handover　Confirm）をＤｅＮＢ３Ｃへ送信する（ステップＳ７５２）。次いで、ＤｅＮＢ３Ｃは、ダウンリンクデータ（Downlink　data）をＵＲＮ２Ａへ送信する（ステップＳ７５４）。これで、ＵＲＮ２Ａは、アップリンクユーザプレーントラフィックデータを、ＤｅＮＢ３ｃ及びＳ－ＧＷ５Ｂを経由してＰ－ＧＷ６へ送信する事が可能になる（ステップＳ７５６）。次いで、ＤｅＮＢ３Ｃは、ハンドオーバ通知（Handover　Notify）をＭＭＥ７Ｂへ送信する（ステップＳ７５８）。次に、ＭＭＥ７Ｂは、フォワードリロケーション完了通知（Forward　Relocation　Complete　Notification）をＭＭＥ７Ａへ送信する（ステップＳ７６０）。次いで、ＭＭＥ７Ａは、フォワードリロケーション完了確認（Forward　Relocation　Complete　Acknowledge）をＭＭＥ７Ｂへ送信する（ステップＳ７６２）。次に、ＭＭＥ７Ｂは、ベアラ変更リクエスト（Modify　Bearer　Request）をＳ－ＧＷ５Ｂへ送信する（ステップＳ７６４）。次いで、Ｓ－ＧＷ５Ｂは、Ｐ－ＧＷ６との間でベアラ変更手続き（Modify　Bearer　procedures）を行う（ステップＳ７６６）。次に、Ｓ－ＧＷ５Ｂは、ベアラ変更レスポンス（Modify　Bearer　Response）をＭＭＥ７Ｂへ送信する（ステップＳ７６８）。これで、Ｐ－ＧＷ６は、ダウンリンクユーザプレーントラフィックデータを、Ｓ－ＧＷ５Ｂ及びＤｅＮＢ３Ｃを経由してＵＲＮ２Ａへ送信する事が可能になる（ステップＳ７７０）。次に、ＵＲＮ２Ａは、ＵＲＮ２Ｂ、ＤｅＮＢ３Ｃ、ＭＭＥ７Ａ及びＭＭＥ７Ｂとの間でトラッキング及びアドレス等の更新手続き（Tracking／Address／etc.　Update　Procedures）を行う（ステップＳ７７２）。次いで、ＵＲＮ２Ａは、ハンドオーバ完了（RCC-UEs：Handover　Completion）を配下のＵＥ１群へ送信する（ステップＳ７７４）。これにより、ＵＥ１群は、ハンドオーバタイマーを停止して状態を開放する（UEs　State　 Release／HO-Timer　Stop）（ステップＳ７７６）。次に、ＭＭＥ７Ａは、ＵＲＮコンテキストリリースコマンド（URN　Context　Release　Command）をＵＲＮ２Ｂへ送信する（ステップＳ７７８）。次いで、ＵＲＮ２Ｂは、ＵＲＮコンテキストリリース完了（URN　Context　Release　Complete）をＭＭＥ７Ａへ送信する（ステップＳ７８０）。次に、ＭＭＥ７Ａは、セッション削除リクエスト（Delete　Session　Request）をＳ－ＧＷ５Ａへ送信する（ステップＳ７８２）。次いで、Ｓ－ＧＷ５Ａは、セッション削除レスポンス（Delete　Session　Response）をＭＭＥ７Ａへ送信する（ステップＳ７８４）。次に、ＭＭＥ７Ａは、インダイレクトデータ転送トンネル削除リクエスト（Delete　Indirect　Data　forwarding　Tunnel　Request）をＳ－ＧＷ５Ａへ送信する（ステップＳ７８６）。次いで、Ｓ－ＧＷ５Ａは、インダイレクトデータ転送トンネル削除レスポンス（Delete　Indirect　Data　forwarding　Tunnel　Response）をＭＭＥ７Ａへ送信する（ステップＳ７８８）。次に、ＭＭＥ７Ｂは、インダイレクトデータ転送トンネル削除リクエスト（Delete　Indirect　Data　forwarding　Tunnel　Request）をＳ－ＧＷ５Ｂへ送信する（ステップＳ７９０）。次いで、Ｓ－ＧＷ５Ｂは、インダイレクトデータ転送トンネル削除レスポンス（Delete　Indirect　Data　forwarding　Tunnel　Response）をＭＭＥ７Ｂへ送信する（ステップＳ７９２）。これで、ＵＥ１群、ＵＲＮ２Ａ、ＤｅＮＢ３Ｃ、Ｓ－ＧＷ５Ｂ及びＰ－ＧＷ６を経由して、アップリンク及びダウンリンクユーザプレーントラフィックデータを送受信する事が可能になる（ステップＳ７９４）。
　　＜３．３．ハンドオーバ時のトランスポート層ＩＰアドレスの取り扱い＞
　以下ＵＥ１又はＵＲＮ２移動に伴うハンドオーバ時のトランスポート層ＩＰアドレスの取り扱いについて説明する。
　図８に示したように、ネットワーク機器には、通常ＥＰＣトランスポート層ＩＰアドレスが付与されている。しかしながら、３ＧＰＰにおいて、ネットワーク機器の移動性は考慮されていなかった。ＵＲＮ２がＵＥ１として振る舞う場合を想定すれば、予めＵＲＮ２にトランスポート層ＩＰアドレスを割り当てておくことも困難な場合がある。そこで、いわゆるオートコンフィギュレーション（Auto　Configuration）のような、ネットワーク接続時に自動的にトランスポート層ＩＰアドレスが割り当てられる仕組みが考えられる。このように、オートコンフィギュレーション及びＵＲＮ２の移動性を考慮すると、移動後とにトランスポート層ＩＰアドレスが変更されることが想定される。
　例えば、ＵＲＮ２は、ネットワークに接続する際、自身を特定するＩＤ（例えばＩＭＳＩ又はＵＲＮ２に割り当てられているｅＮＢ　ＩＤ等)をＩＰｖ６インタフェース識別子に設定する。また、ＵＲＮ２は、ＩＰｖ６リンクローカルアドレスを用いて、接続先のＤｅＮＢ３とのＲＳメッセージ及びＲＡメッセージによりＰｒｅｆｉｘ／６４を取得する。そして、ＵＲＮ２は、設定したＩＰｖ６インタフェース識別子と取得したＰｒｅｆｉｘ／６４とを組み合わせることで、自身のトランスポート層ＩＰアドレスを生成してもよい。
　ＵＲＮ２は、このようにして生成したトランスポート層ＩＰアドレスをハンドオーバ後も継続して利用してもよい。また、ＵＲＮ２は、ハンドオーバの度に同様の方法で新たなトランスポート層ＩＰアドレスを生成してもよい。ここでのハンドオーバとは、接続先のＤｅＮＢ３が変わること、又は接続先のＵＲＮ２が変わることを意味し得る。
　いずれの場合であっても、ＵＲＮ２がＭＭＥ７に対してＲＣＣ／Ｓ１－ＡＰ／ＮＡＳ通信を行う際（例えば、図３２、図３４及び図３６におけるトラッキング及びアドレス等の更新手続き（Tracking／Address／etc．　Update　Procedures））に、ＭＭＥ７は、ＵＲＮ２のトランスポート層ＩＰアドレスに関する管理情報を更新する。なお、後述する図３８におけるステップＳ８０６及び図４１におけるステップＳ１１０６が、上述したオートコンフィギュレーションの一例である。
　　＜３．４．効果＞
　以下、上述したプロトコルの主な効果を説明する。
　例えば、ＵＲＮ２には、ネットワーク層ＩＰアドレスが割り当てられる。そのため、ＩＰ移動透過性が実現される。また、ＵＲＮ２は、ＩＰアプリケーションをＵＥ１と同様に利用することが可能となる。さらに、ＵＥ１－ＵＥ１、ＵＥ１－ＵＲＮ２、又はＵＲＮ２－ＵＲＮ２間でのネットワーク層ＩＰアドレスを用いたＤ２Ｄ通信が容易に実現される。
　また、ＥＰＣトランスポート層ＩＰアドレスのオートコンフィギュレーションが実現される。これにより、これにより、エンドユーザが利用するようなＵＲＮ２に対して、ＵＲＮ２がネットワークに接続する度に又はハンドオーバの度に、トランスポート層ＩＰアドレスをダイナミックに割り当てることが可能となる。そのため、ＵＲＮ２が移動する場合であっても、固定型ＲＮと同様に、ネットワークのメンテナンス、及びＭＭＥ７によるベアラの確立等を、他のＥＰＣ機器と同様に行うことが可能となる。
　また、ＵＲＮ２に接続したＵＥ１は、ＵＲＮ２がハンドオーバした場合であっても、再度の接続処理を省略することが可能である。よって、ＵＥ１は、位置登録の更新（Tracking　Area　Update）等を行わずとも、ページングの受信、及びプッシュアプリケーションの利用等が可能となる。これにより、ＵＲＮ２配下のＵＥ１からのシグナリング（例えば、トラッキングエリア更新メッセージ）の量を大幅に低減することが可能となる。これにより、仮想セルに接続されるウェアラブルデバイス群、又は移動する車に形成された仮想セルに接続するＵＥ１からの、移動に伴うシグナリングメッセージの低減が実現される。
　また、ＵＲＮ２は、配下の仮想セル内で利用される共通のＰｒｅｆｉｘ／５６以外のアドレスを持ったＵＥ１及びＵＲＮ２を、仮想セルへの取り込むことが可能である。よって、既にネットワークに接続済の端末を、仮想セルに取り込むことが可能である。
　＜＜４．第２の実施形態＞＞
　本実施形態は、第１の実施形態を、マッピング表の生成及び更新の観点から詳しく説明するものである。
　　＜４．１．はじめに＞
　図３７は、本実施形態に係るネットワーク構成例を示す図である。以下では、図３７に示したネットワーク構成例を前提に、本実施形態について説明する。図３７に示すように、本システムは、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、Ｓ－ＧＷ５Ｂ、ＭＭＥ７、ＤｅＮＢ３Ａ、ＤｅＮＢ３Ｂ、及びＵＲＮ２Ａにより形成される仮想セルを含む。ＵＲＮ２Ａにより形成される仮想セルには、ＵＥ１Ａ及びＵＥ１Ｂ、ＵＥ１Ｃが接続する入れ子の仮想セルを形成するＵＲＮ２Ｂ、ＵＥ１Ｄが接続する入れ子の仮想セルを形成するＵＲＮ２Ｃ、並びにＵＥ１Ｅが接続する入れ子の仮想セルを形成するＵＲＮ２Ｄが接続し得る。
　Ｐ－ＧＷの下流のインタフェースのＩＰｖ６アドレスをＩＰＤ ＰＧＷと表す。Ｓ－ＧＷの上流または下流のインタフェースのＩＰｖ６アドレスを、それぞれＩＰＵ ＳＧＷ、ＩＰＤ ＳＧＷと表す。ＤｅＮＢの上流または下流のインタフェースのＩＰｖ６アドレスを、それぞれＩＰＵ ＤｅＮＢ、ＩＰＤ ＤｅＮＢと表す。ＵＲＮ２がｅＮＢとして動作し、Ｓ１－Ｕインタフェースで上流のＤｅＮＢと接続するためのＩＰｖ６アドレスをＩＰＵ ＵＲＮと表す。ＵＲＮ２がＵＥとして動作し、ＵＲＮ上のアプリケーションが使用するＩＰｖ６アドレスをＩＰＵＥ ＵＲＮと表す。ＵＲＮ２が移動ルータとして動作し、下流の仮想セル内の機器と通信する際に使用するＩＰｖ６アドレスをＩＰＤ ＵＲＮと表す。
　　＜４．２．処理の流れ＞
　　（１）ＩＰｖ６アドレス未取得のＵＲＮ２ＡのＤｅＮＢ３Ａへの接続手順
　以下では、図３８を参照しながら、ＩＰｖ６アドレス未取得のＵＲＮ２ＡがＤｅＮＢ３Ａに接続してＩＰｖ６アドレスを取得する際の処理の流れを説明する。例えば、ＤｅＮＢ３Ａの付近でＵＲＮ２Ａの電源がオンになった場合に、本処理が実行され得る。
　図３８は、本実施形態に係るＵＲＮ２ＡによるＤｅＮＢ３Ａへの接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、及びＰ－ＧＷ６が関与する。
　図３８に示すように、まず、ＵＲＮ２Ａは、ＤｅＮＢ３Ａと無線回線を確立する（ステップＳ８０２）。
　次いで、ＵＲＮ２Ａは、リンクローカル全ルータマルチキャストアドレス宛に、ＲＳ（Router　Solicitation）を送信する（ステップＳ８０４）。このＲＳのソースアドレスは、ＵＲＮ２ＡのリンクローカルＩＰｖ６アドレスである。
　次に、ＤｅＮＢ３Ａは、このＲＳを受信し、ＵＲＮ２ＡのリンクローカルＩＰｖ６アドレス宛にＲＡ（Router　Advertisement）を送信する（ステップＳ８０６）。このＲＡは、ＩＰＤ ＤｅＮＢ３Ａの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次いで、ＵＲＮ２Ａは、このＲＡを受信し、ＩＰｖ６アドレスＩＰＵ ＵＲＮ２Ａを生成する（ステップＳ８０８）。ＩＰＵ ＵＲＮ２Ａは、ＵＲＮ２ＡがＤｅＮＢ３Ａとの間にＧＴＰトンネルを確立する際に使用される。
　次に、ＵＲＮ２Ａは、ＤｅＮＢ３Ａにアタッチリクエストを送信する（ステップＳ８１０）。このアタッチリクエストは、ＵＲＮ２Ａの識別子ＩＤＵＲＮ２ＡとＩＰＵ ＵＲＮ２Ａとを含む。
　次いで、ＤｅＮＢ３Ａは、このアタッチリクエストを受信すると、ＭＭＥ７に転送する（ステップＳ８１２）。
　次に、ＭＭＥ７は、Ｓ－ＧＷ５Ａにデフォルトベアラ生成リクエスト（Create　Default　Bearer　Request）を送信する（ステップＳ８１４）。このデフォルトベアラ生成リクエストは、ＩＤＵＲＮ２ＡとＩＰＵ ＵＲＮ２Ａとを含む。
　次いで、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成リクエストを受信すると、Ｐ－ＧＷ６に転送する（ステップＳ８１６）。
　次に、Ｐ－ＧＷ６は、このデフォルトベアラ生成リクエストを受信すると、自身が有するＩＰｖ６アドレススペースからＩＰｖ６アドレスＩＰＵＥ ＵＲＮ２Ａを割り当てる（ステップＳ８１８）。ＩＰＵＥ ＵＲＮ２Ａは、ＵＲＮ２ＡがＵＥとして動作する際、アプリケーションにより使用されるＩＰｖ６アドレスである。Ｐ－ＧＷ６は、Ｓ－ＧＷ５Ａとの間にＧＴＰトンネルを構成し、ＩＰＵＥ ＵＲＮ２Ａの転送先をこのＧＴＰトンネルに関連付ける。この関連付けは、マッピング表として記憶される。このＧＴＰトンネルの端点は、ＩＰＤ ＰＧＷ６とＩＰＵ ＳＧＷ５Ａである。
　次いで、Ｐ－ＧＷ６は、Ｓ－ＧＷ５Ａにデフォルトベアラ生成レスポンス（Create　Default　Bearer　Response）を送信する（ステップＳ８２０）。このデフォルトベアラ生成レスポンス（Create　Default　Bearer　Response）は、ＩＤＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２ＡおよびＩＰＤ ＰＧＷ６を含む。
　次に、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成レスポンスを受信すると、ＭＭＥ７に転送する（ステップＳ８２２）。Ｓ－ＧＷ５Ａは、Ｐ－ＧＷ６との間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点はＩＰＵ ＳＧＷ５ＡとＩＰＤ ＰＧＷ６である。さらにＳ－ＧＷ５Ａは、ＤｅＮＢ３Ａとの間にＧＴＰトンネルを構成し、ＩＰＵＥ ＵＲＮ２ＡをこのＧＴＰトンネルに関連付ける。この関連づけは、マッピング表として記憶される。このＧＴＰトンネルの端点は、ＩＰＤ ＳＧＷ５ＡとＩＰＵ ＤｅＮＢ３Ａである。
　次いで、ＭＭＥ７は、このデフォルトベアラ生成レスポンスを受信すると、ＤｅＮＢ３Ａにアタッチアクセプトを送信する（ステップＳ８２４）。アタッチアクセプトは、ＩＤＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａの下位６４ビット（ｉｆ－ｉｄ：インタフェース識別子）およびＩＰＤ ＰＧＷ６を含む。
　次に、ＤｅＮＢ３Ａは、このアタッチアクセプトを受信すると、ＵＲＮ２Ａに転送する（ステップＳ８２６）。ＤｅＮＢ３Ａは、Ｓ－ＧＷ５Ａとの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点はＩＰＵ ＤｅＮＢ３ＡとＩＰＤ ＳＧＷ５Ａである。さらに、ＤｅＮＢ３Ａは、ＵＲＮ２Ａとの間にＧＴＰトンネルを構成し、ＩＰＵＥ ＵＲＮ２Ａの転送先をこのＧＴＰトンネルに関連付ける。この関連付けは、マッピング表として記憶する。このＧＴＰトンネルの端点は、ＩＰＤ ＤｅＮＢ３ＡとＩＰＵ ＵＲＮ２Ａである。ＵＲＮ２Ａは、このアタッチアクセプトを受信し、ＩＰＵＥ ＵＲＮ２Ａの下位６４ビット（ｉｆ－ｉｄ）を得る。
　以上のシグナリングの結果、Ｐ－ＧＷ６とＳ－ＧＷ５Ａとの間、Ｓ－ＧＷ５ＡとＤｅＮＢ３Ａとの間、およびＤｅＮＢ３ＡとＵＲＮ２Ａとの間にそれぞれＧＴＰトンネルが生成される（ステップＳ８２８）。
　次いで、ＵＲＮ２Ａは、ＵＥとして動作するためのＩＰｖ６アドレスＩＰＵＥ ＵＲＮ２Ａを得るため、ＩＰｖ６の規定に従ってＰ－ＧＷ６にＲＳを送信する（ステップＳ８３０）。
　次に、Ｐ－ＧＷ６は、このＲＳを受信し、ＵＲＮ２ＡにＲＡを返送する（ステップＳ８３２）。このＲＡは、ＩＰＵＥ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次いで、ＵＲＮ２Ａは、このＲＡを受信し、ＩＰＵＥ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を得る。そして、ＵＲＮ２Ａは、ＩＰＵＥ ＵＲＮ２Ａを生成する（ステップＳ８３４）。ＩＰＵＥ ＵＲＮ２Ａは、ＵＲＮ２Ａ上のアプリケーションが通信するときに使用される。
　次に、ＵＲＮ２Ａは、Ｐ－ＧＷ６との間でＤＨＣＰ－ＰＤ（Prefix　Delegation）を実行する（ステップＳ８３６）。
　ＤＨＣＰ－ＰＤの結果、ＵＲＮ２Ａは、ＩＰｖ６アドレスのプレフィクスＰｒｅｆＵＲＮ２Ａ（例えば、／６０のＩＰｖ６アドレススペース）を得る（ステップＳ８３８）。Ｐ－ＧＷ６は、ＰｒｅｆＵＲＮ２Ａの転送先を、Ｓ－ＧＷ５ＡへのＧＴＰトンネルに関連付ける。この関連付けは、マッピング表により記憶される。一方、ＵＲＮ２Ａは、ＰｒｅｆＵＲＮ２Ａの空間からＩＰｖ６アドレスＩＰＤ ＵＲＮ２Ａを選択する。ＩＰＤ ＵＲＮ２Ａは、ＵＲＮ２Ａの下流のインタフェースに割り当てられる。
　次いで、Ｐ－ＧＷ６は、Ｓ－ＧＷ５Ａにルートセットアップメッセージを送信する（ステップＳ８４０）。このルートセットアップメッセージは、ＩＰｖ６アドレスのプレフィクスＰｒｅｆＵＲＮ２ＡとＵＲＮ２Ａとを関連付けるための情報であり、ＵＲＮ２ＡとＰ－ＧＷ６との通信を中継する装置（例えば、Ｓ－ＧＷ５Ａ、及びＤｅＮＢ３Ａ等）へ通知される。具体的には、このルートセットアップメッセージは、ＰｒｅｆＵＲＮ２Ａの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付けるという情報を含む。
　次に、Ｓ－ＧＷ５Ａは、このルートセットアップメッセージを受信すると、ＰｒｅｆＵＲＮ２Ａの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける（ステップＳ８４２）。そして、Ｓ－ＧＷ５Ａは、ルートセットアップメッセージをＭＭＥ７に中継する。
　次いで、ＭＭＥ７は、このルートセットアップメッセージを受信すると、ＤｅＮＢ３Ａに転送する（ステップＳ８４４）。ＤｅＮＢ３Ａは、このルートセットアップメッセージを受信すると、ＰｒｅｆＵＲＮ２Ａの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける。
　この結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５ＡおよびＤｅＮＢ３Ａは、それぞれ表２、表３、表４に示すマッピング表を記憶することとなる。
Figure JPOXMLDOC01-appb-T000002
Figure JPOXMLDOC01-appb-T000003
Figure JPOXMLDOC01-appb-T000004
　上記マッピング表について説明する。例えば、表２の１行目のエントリによれば、ＩＰＵＥ ＵＲＮ２Ａ宛てのパケットは、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとするエントリの転送先欄に記載された「ＧＴＰＳＧＷ５Ａ」（即ち、Ｓ－ＧＷ５Ａ宛てのＧＴＰトンネル）へ転送される。これにより、当該パケットはＳ－ＧＷ５Ａへ転送されることとなる。次いで、表３の１行目のエントリによれば、ＩＰＵＥ ＵＲＮ２Ａ宛てのパケットは、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとするエントリの転送先欄に記載された「ＧＴＰＤｅＮＢ３Ａ」（即ち、ＤｅＮＢ３Ａ宛てのＧＴＰトンネル）へ転送される。これにより、当該パケットはＤｅＮＢ３Ａへ転送されることとなる。次いで、表４の１行目のエントリによれば、ＩＰＵＥ ＵＲＮ２Ａ宛てのパケットは、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとするエントリの転送先欄に記載された「ＧＴＰＵＲＮ２Ａ」（即ち、ＵＲＮ２Ａ宛てのＧＴＰトンネル）へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。このように、各エンティティは、記憶したマッピング表を参照することで、パケットを適切に転送して宛先へ到達させることが可能である。
　また、表２の２行目のエントリによれば、宛先ＩＰアドレスのプレフィクス部分がＰｒｅｆＵＲＮ２Ａであるパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先である「ＧＴＰＳＧＷ５Ａ」へ転送される。これにより、当該パケットはＳ－ＧＷ５Ａへ転送されることとなる。また、表３の２行目のエントリによれば、宛先ＩＰアドレスのプレフィクス部分がＰｒｅｆＵＲＮ２Ａであるパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先である「ＧＴＰＤｅＮＢ３Ａ」へ転送される。これにより、当該パケットはＤｅＮＢ３Ａへ転送されることとなる。また、表４の２行目のエントリによれば、宛先ＩＰアドレスのプレフィクス部分がＰｒｅｆＵＲＮ２Ａであるパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先である「ＧＴＰＵＲＮ２Ａ」へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。このように、各エンティティは、記憶したマッピング表を参照することで、パケットを適切に転送して宛先へ到達させることが可能である。
　このように、各エンティティ（Ｐ－ＧＷ６、Ｓ－ＧＷ５、及びＤｅＮＢ３等）は、ＵＲＮ２に接続する端末（ＵＥ１又はＵＲＮ２）へ割り当てられるプレフィクス部分とＵＲＮ２とを関連付けて記憶する。各エンティティは、この関連付けを参照することで、ＵＲＮ２の配下の端末向けのパケットをＵＲＮ２へ送信して、最終的に各端末へ到達させることが可能となる。
　　（２）ＩＰｖ６アドレス未取得のＵＥ１ＡのＵＲＮ２Ａへの接続手順
　以下では、上述した接続処理の後に、ＩＰｖ６アドレス未取得のＵＥ１ＡがＵＲＮ２Ａに接続してＩＰｖ６アドレスを取得する場合の処理の流れを説明する。例えば、ＵＲＮ２Ａの付近でＵＥ１Ａの電源がオンになった場合に、本処理が実行され得る。
　図３９は、本実施形態に係るＵＥ１ＡによるＵＲＮ２Ａへの接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１Ａ、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、及びＰ－ＧＷ６が関与する。
　図３９に示すように、まず、ＵＥ１Ａは、ＵＲＮ２Ａと無線回線を確立する（ステップＳ９０２）。
　次いで、ＵＥ１Ａは、アタッチリクエストをＵＲＮ２Ａに送信する。このアタッチリクエストは、ＵＥ１Ａの識別子ＩＤＵＥ１Ａを含む（ステップＳ９０４）。
　次に、ＵＲＮ２Ａは、ＵＥ１Ａにアタッチアクセプトを送信する（ステップＳ９０６）。このアタッチアクセプトは、ＵＥ１ＡがＩＰＵＥ１Ａを構成するための下位６４ビット（ｉｆ－ｉｄ）とＩＰＤ ＵＲＮ２Ａとを含む。ＵＥ１Ａは、このアタッチアクセプトを受信し、ＩＰＵＥ１Ａの下位６４ビットを得る。
　次いで、ＵＥ１Ａは、ＵＲＮ２ＡにＲＳを送信する（ステップＳ９０８）。
　次に、ＵＲＮ２Ａは、このＲＳを受信すると、ＵＥ１ＡにＩＰＤ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を含むＲＡを送信する（ステップＳ９１０）。
　次いで、ＵＥ１Ａは、ＲＡを受信し、ＩＰＵＥ１Ａを生成する（ステップＳ９１２）。
　その後、ＵＲＮ２Ａは、ある程度の時間（たとえば１秒）待ち、その間にＵＲＮ２Ａの下流に接続したＵＥ１に関するアタッチリクエストをまとめてＤｅＮＢ３Ａに送信する（ステップＳ９１４）。即ち、ＵＲＮ２Ａは、複数台のＵＥ１に関するアタッチリクエストを一度に送信することで、ＵＲＮ２Ａの下流にＵＥ１が接続するごとにアタッチリクエストを送信することを回避することが可能である。このアタッチリクエストは、ＵＲＮ２Ａに接続したＵＥ１Ａの識別子（例えばＩＤＵＥ１Ａ）とＩＰｖ６アドレス（例えばＩＰＵＥ１Ａ）、および仮想セルへのＵＥ接続であることを示す情報を含む。
　次に、ＤｅＮＢ３Ａは、このアタッチリクエストを受信すると、ＭＭＥ７に転送する（ステップＳ９１６）。
　次いで、ＭＭＥ７は、このアタッチリクエストを受信すると、ＤｅＮＢ３Ａにアタッチアクセプトを送信する（ステップＳ９１８）。
　次に、ＤｅＮＢ３Ａは、このアタッチアクセプトを受信すると、ＵＲＮ２Ａに転送する（ステップＳ９２０）。
　以上の処理の結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、及びＤｅＮＢ３Ａの各々が記憶するマッピング表に変化はない。即ち、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、及びＤｅＮＢ３Ａが記憶する情報量は、ＵＲＮ２が提供する仮想セル内で電源がオンになったＵＥ１の数に依存しない。
　　（３）ＩＰｖ６アドレス取得済みのＵＥ１ＢのＵＲＮ２Ａへの接続手順
　以下では、上述した接続処理の後に、ＩＰｖ６アドレス取得済みのＵＥ１ＢがＵＲＮ２Ａに接続する場合の処理の流れを説明する。例えば、ＵＥ１Ｂは、ＵＲＮ２Ａに接続する前に、ＩＰＵＥ１ＢというＩＰｖ６アドレスを得ているものとする。ここで注意すべきは、ＩＰＵＥ１Ｂは、ＰｒｅｆＵＲＮ２Ａには属さない点である。例えば、他のｅＮＢ４に接続していたＵＥ１Ｂが、ＵＲＮ２Ａが提供する仮想セルに接続した場合に、本処理が実行され得る。
　図４０は、本実施形態に係るＵＥ１ＢによるＵＲＮ２Ａへの接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１Ｂ、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、及びＰ－ＧＷ６が関与する。
　図４０に示すように、まず、ＵＥ１Ｂは、ＵＲＮ２Ａと無線回線を確立する（ステップＳ１００２）。
　次いで、ＵＥ１Ｂは、ＵＲＮ２Ａにアタッチリクエストを送信する（ステップＳ１００４）。このアタッチリクエストは、ＵＥ１Ｂの識別子ＩＤＵＥ１ＢとＩＰＵＥ１Ｂとを含む。
　次に、ＵＲＮ２Ａは、ＵＥ１ＢにＩＰＵＥ１Ｂの下位６４ビット（ｉｆ－ｉｄ）を含むアタッチアクセプトを送信する（ステップＳ１００６）。
　次いで、ＵＲＮ２Ａは、ＩＰｖ６アドレスＩＰＤ２ ＵＲＮ２Ａを生成し、下流のインタフェースに割り当てる（ステップＳ１００８）。その際、ＵＲＮ２Ａは、ＩＰＤ２ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）をＩＰＵＥ１Ｂの上位６４ビット（ｐｒｅｆｉｘ）と等しくする。
　次に、ＩＰｖ６の規定に従い、ＵＥ１Ｂは、ＵＲＮ２ＡにＲＳを送信する（ステップＳ１０１０）。
　次いで、ＵＲＮ２Ａは、このＲＳを受信すると、ＵＥ１ＢにＩＰＵＥ１Ｂの上位６４ビット（ｐｒｅｆｉｘ）とＩＰＤ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を含むＲＡを送信する（ステップＳ１０１２）。
　次に、ＵＥ１Ｂは、ＲＡを受信し、ＩＰＵＥ１Ｂが使用可能であることを確認する（ステップＳ１０１４）。また、ＵＥ１Ｂは、ＩＰＤ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を使用し、ＩＰｖ６アドレスＩＰＵＲＮ２Ａ ＵＥ１Ｂを生成する。ＩＰＵＥ１Ｂは、ＰｒｅｆＵＲＮ２Ａに属さないが、ＩＰＵＲＮ２Ａ ＵＥ１ＢはＰｒｅｆＵＲＮ２Ａに属する。ＵＥ１ＢがＵＲＮ２Ａに接続する前から通信をしていたアプリケーションはＩＰＵＥ１Ｂを使い続け、ＵＥ１ＢがＵＲＮ２Ａに接続したあとに通信を開始したアプリケーションはＩＰＵＲＮ２Ａ ＵＥ１Ｂを使用する。このようにすることにより、やがてＩＰＵＥ１Ｂは使用されなくなる。ＵＥ１ＢにおいてＩＰＵＥ１Ｂが使用されなくなったことは、以下のような方法で検出できる。例えば、ＵＥ１Ｂは、ＵＲＮ２Ａに接続した時刻を記録しておく。ＵＥ１Ｂは、この時刻以降にオープンされたソケットには、ＩＰＵＲＮ２Ａ ＵＥ１Ｂを使用する。そして、この時刻以前にオープンされたすべてのソケットがクローズされれば、ＩＰＵＥ１Ｂは使用されなくなったことになる。ＵＥ１Ｂは、これを検知し、ＵＲＮ２Ａに通知する。
　その後、ＵＲＮ２Ａは、ある程度の時間（例えば１秒）待ち、その間にＵＲＮ２Ａの下流に接続したＵＥ１に関するアタッチリクエストをまとめてＤｅＮＢ３Ａに送信する（ステップＳ１０１６）。即ち、ＵＲＮ２Ａは、複数台のＵＥ１に関するアタッチリクエストを一度に送信することで、ＵＲＮ２Ａの下流にＵＥ１が接続するごとにアタッチリクエストを送信することを回避することが可能である。このアタッチリクエストは、ＵＲＮ２Ａに接続したＵＥ１Ｂの識別子（例えばＩＤＵＥ１Ｂ）とＩＰｖ６アドレス（例えばＩＰＵＥ１Ｂ）、ＩＰＵＥ ＵＲＮ２Ａ、ＩＤＵＲＮ２Ａ、および仮想セルへのＵＥ接続であることを示す情報を含む。
　次いで、ＤｅＮＢ３Ａは、このアタッチリクエストを受信すると、ＭＭＥ７に転送する（ステップＳ１０１８）。
　次に、ＭＭＥ７は、このアタッチリクエストを受信すると、デフォルトベアラ生成リクエストをＳ－ＧＷ５Ａに送信する（ステップＳ１０２０）。このデフォルトベアラ生成リクエストは、ＩＤＵＥ１Ｂ、ＩＰＵＥ１Ｂ、ＩＰＵＥ ＵＲＮ２ＡおよびＩＤＵＲＮ２Ａを含む。
　次いで、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成リクエストを受信すると、Ｐ－ＧＷ６に転送する（ステップＳ１０２２）。
　次に、Ｐ－ＧＷ６は、このデフォルトベアラ生成リクエストを受信すると、ＩＰＵＥ１Ｂの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付け、デフォルトベアラ生成レスポンスをＳ－ＧＷ５Ａに送信する（ステップＳ１０２４）。このデフォルトベアラ生成レスポンスは、ＩＤＵＥ１Ｂ、ＩＰＵＥ１Ｂ、ＩＰＵＥ ＵＲＮ２ＡおよびＩＤＵＲＮ２Ａを含む。
　次いで、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成レスポンスを受信すると、ＩＰＵＥ１Ｂの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付け、デフォルトベアラ生成レスポンスをＭＭＥ７に送信する（ステップＳ１０２６）。
　次に、ＭＭＥ７は、このデフォルトベアラ生成レスポンスを受信するとＤｅＮＢ３Ａにアタッチアクセプトを送信する（ステップＳ１０２８）。このアタッチアクセプトは、ＩＤＵＥ１Ｂ、ＩＰＵＥ１Ｂ、ＩＰＵＥ ＵＲＮ２ＡおよびＩＤＵＲＮ２Ａを含む。
　次いで、ＤｅＮＢ３Ａは、このアタッチアクセプトを受信すると、ＩＰＵＥ１Ｂの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付け、アタッチアクセプトをＵＲＮ２Ａに転送する（ステップＳ１０３０）。
　この結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、ＤｅＮＢ３Ａは、それぞれ表５、６、７に示すマッピング表を記憶することとなる。
Figure JPOXMLDOC01-appb-T000005
Figure JPOXMLDOC01-appb-T000006
Figure JPOXMLDOC01-appb-T000007
　上記マッピング表について説明する。上記マッピング表では、新たに３行目のエントリが追加されている。３行目のエントリによれば、ＩＰＵＥ１Ｂ宛てのパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先へ転送される。当該パケットは、表５によればＰ－ＧＷ６により「ＧＴＰＳＧＷ５Ａ」へ転送され、表６によればＳ－ＧＷ５Ａにより「ＧＴＰＤｅＮＢ３Ａ」へ転送され、表７によればＤｅＮＢ３Ａにより「ＧＴＰＵＲＮ２Ａ」へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。そして、ＵＲＮ２ＡからＵＥ１Ｂへ、当該パケットが転送される。
　　（４）ＩＰｖ６アドレス未取得のＵＲＮ２ＢのＵＲＮ２Ａへの接続手順
　以下では、上述した接続処理の後に、ＩＰｖ６アドレス未取得のＵＲＮ２ＢがＵＲＮ２Ａに接続する場合の処理の流れを説明する。例えば、ＵＲＮ２Ａの付近でＵＲＮ２Ｂの電源がオンになった場合に、本処理が実行され得る。
　図４１は、本実施形態に係るＵＲＮ２ＢによるＵＲＮ２Ａへの接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＲＮ２Ｂ、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、及びＰ－ＧＷ６が関与する。
　図４１に示すように、まず、ＵＲＮ２Ｂは、ＵＲＮ２Ａと無線回線を確立する（ステップＳ１１０２）。
　次いで、ＵＲＮ２Ｂは、リンクローカル全ルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ１１０４）。このＲＳのソースアドレスは、ＵＲＮ２Ｂのリンクローカルアドレスである。
　次に、ＵＲＮ２Ａは、ＵＲＮ２Ｂのリンクローカルアドレス宛にＲＡを送信する（ステップＳ１１０６）。このＲＡは、ＩＰＤ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）とＵＲＮ２Ａが仮想セル内に存在する旨を表す情報を含む。
　次いで、ＵＲＮ２Ｂは、このＲＡを受信し、ＩＰｖ６アドレスＩＰＵ ＵＲＮ２Ｂを生成する（ステップＳ１１０８）。また、ＵＲＮ２Ｂは、ＩＰＵＥ ＵＲＮ２Ｂを、ＩＰＵ ＵＲＮ２Ｂと同じ値とする。
　次に、ＵＲＮ２Ｂは、ＵＲＮ２Ａにアタッチリクエストを送信する（ステップＳ１１１０）。このアタッチリクエストは、ＵＲＮ２Ｂの識別子ＩＤＵＲＮ２ＢとＩＰＵ ＵＲＮ２Ｂとを含む。
　次いで、ＵＲＮ２Ａは、このアタッチリクエストを受信すると、ＵＲＮ２Ｂにアタッチアクセプトを送信する（ステップＳ１１１２）。このアタッチアクセプトは、ＩＰＤ ＵＲＮ２ＡとＩＰＵ ＵＲＮ２Ｂの下位６４ビット（ｉｆ－ｉｄ）を含む。
　次に、ＵＲＮ２Ｂは、ＵＲＮ２ＡにＲＳを送信する（ステップＳ１１１４）。
　次いで、ＵＲＮ２Ａは、このＲＳを受信すると、ＵＲＮ２ＢにＲＡを送信する（ステップＳ１１１６）。このＲＡは、ＩＰＤ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次に、ＵＲＮ２Ｂは、このＲＡを受信すると、ＩＰＵＥ ＵＲＮ２Ｂを生成する（ステップＳ１１１８）。結果として、ＩＰＵ ＵＲＮ２ＢとＩＰＵＥ ＵＲＮ２Ｂとは、等しくなる。
　次いで、ＵＲＮ２Ｂは、ＵＲＮ２Ａとの間でＤＨＣＰ－ＰＤを実行する（ステップＳ１１２０）。
　次に、ＤＨＣＰ－ＰＤを実行した結果、ＵＲＮ２Ａは、ＰｒｅｆＵＲＮ２Ａの中から例えば／６４のプレフィクスであるＰｒｅｆＵＲＮ２Ｂを切り出し、これをＵＲＮ２Ｂに割り当てる（ステップＳ１１２２）。ＵＲＮ２Ｂは、ＰｒｅｆＵＲＮ２ＢからＩＰｖ６アドレスＩＰＤ ＵＲＮ２Ｂを生成し、下流の入れ子仮想セルでの通信に使用する。ＵＲＮ２Ａは、ＰｒｅｆＵＲＮ２Ｂの転送先をＩＰＵ ＵＲＮ２Ｂに設定する。
　その後、ＵＲＮ２Ａは、ある程度の時間（たとえば１秒）待ち、その間にＵＲＮ２Ａの下流に接続したＵＲＮ２に関するアタッチリクエストをまとめてＤｅＮＢ３Ａに送信する（ステップＳ１１２４）。即ち、ＵＲＮ２Ａは、複数台のＵＲＮ２に関するアタッチリクエストを一度に送信することで、ＵＲＮ２Ａの下流にＵＲＮ２が接続するたびにアタッチリクエストを送信することを回避することが可能である。このアタッチリクエストは、ＵＲＮ２Ａに接続したＵＲＮ２Ｂの識別子（例えばＩＤＵＲＮ２Ｂ）とＩＰｖ６アドレス（例えばＩＰＵ ＵＲＮ２Ｂ）、ＩＤＵＲＮ２Ａおよび仮想セルへのＲＮ接続であることを示す情報を含む。
　次いで、ＤｅＮＢ３Ａは、このアタッチリクエストを受信すると、ＭＭＥ７に転送する（ステップＳ１１２６）。
　次に、ＭＭＥ７は、このアタッチリクエストを受信すると、アタッチアクセプトをＤｅＮＢ３Ａに送信する（ステップＳ１１２８）。
　次いで、ＤｅＮＢ３Ａは、このアタッチアクセプトを受信すると、ＵＲＮ２Ａに転送する（ステップＳ１１３０）。
　この処理の結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、及びＤｅＮＢ３Ａが記憶するマッピング表に変化はない。即ち、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、及びＤｅＮＢ３Ａの記憶する情報量は、ＵＲＮ２Ａが提供する仮想セル内で電源がオンになったＵＲＮ２の数に依存しない。
　　（５）ＩＰｖ６アドレス取得済みのＵＲＮ２ＣのＵＲＮ２Ａへの接続手順
　以下では、上述した接続処理の後に、ＩＰｖ６アドレス取得済みのＵＲＮ２ＣがＵＲＮ２Ａに接続する場合の処理の流れを説明する。例えば、ＵＲＮ２Ｃは、ＵＲＮ２Ａに接続する前に、ＩＰＵＥ ＵＲＮ２ＣというＩＰｖ６アドレスと、ＰｒｅｆＵＲＮ２Ｃというプレフィクスを得ているものとする。また、ＵＲＮ２ＣにはＵＥ１Ｄが接続しており、ＵＥ１ＤはＰｒｅｆＵＲＮ２Ｃに属するＩＰｖ６アドレスであるＩＰＵＥ１Ｄを得ているものとする。例えば、ＤｅＮＢ３に接続していた仮想セルがＵＲＮ２Ａの下流に接続する場合に、本処理が実行され得る。
　図４２は、本実施形態に係るＵＲＮ２ＣによるＵＲＮ２Ａへの接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＲＮ２Ｃ、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、及びＰ－ＧＷ６が関与する。
　図４２に示すように、まず、ＵＲＮ２Ｃは、ＵＲＮ２Ａと無線回線を確立する（ステップＳ１２０２）。
　次いで、ＵＲＮ２Ｃは、リンクローカル全ルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ１２０４）。このＲＳのソースアドレスは、ＵＲＮ２Ｃのリンクローカルアドレスである。
　次に、ＵＲＮ２Ａは、ＵＲＮ２Ｃのリンクローカルアドレス宛にＲＡを送信する（ステップＳ１２０６）。このＲＡは、ＰｒｅｆＵＲＮ２Ａに属する／６４のプレフィクス、例えばＰｒｅｆＵＲＮ２Ａ ＵＲＮ２Ｃを含む。
　次いで、ＵＲＮ２Ｃは、このＲＡを受信し、ＩＰＵ ＵＲＮ２Ｃを生成する（ステップＳ１２０８）。
　次に、ＵＲＮ２Ｃは、ＵＲＮ２Ａにアタッチリクエストを送信する（ステップＳ１２１０）。このアタッチリクエストは、ＵＲＮ２Ｃの識別子ＩＤＵＲＮ２Ｃ、ＩＰＵＥ ＵＲＮ２ＣおよびＰｒｅｆＵＲＮ２Ｃを含む。
　次いで、ＵＲＮ２Ａは、このアタッチリクエストを受信すると、ＤｅＮＢ３Ａに転送する（ステップＳ１２１２）。その際、ＵＲＮ２Ａは、ＩＰＵＥ ＵＲＮ２ＡおよびＩＤＵＲＮ２Ａをアタッチリクエストに加える。
　次に、ＤｅＮＢ３Ａは、このアタッチリクエストを受信すると、ＭＭＥ７に転送する（ステップＳ１２１４）。
　次いで、ＭＭＥ７は、このアタッチリクエストを受信すると、デフォルトベアラ生成リクエストをＳ－ＧＷ５Ａに送信する（ステップＳ１２１６）。このデフォルトベアラ生成リクエストは、ＩＤＵＲＮ２Ａ、ＩＤＵＲＮ２Ｃ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２ＣおよびＰｒｅｆＵＲＮ２Ｃを含む。
　次に、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成リクエストを受信すると、Ｐ－ＧＷ６に転送する（ステップＳ１２１８）。
　次いで、Ｐ－ＧＷ６は、ＩＰＵＥ ＵＲＮ２ＣとＰｒｅｆＵＲＮ２Ｃの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける。そして、Ｐ－ＧＷ６は、Ｓ－ＧＷ５Ａに、デフォルトベアラ生成レスポンスを送信する（ステップＳ１２２０）。このデフォルトベアラ生成レスポンスは、ＩＤＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２ＣおよびＰｒｅｆＵＲＮ２Ｃを含む。
　次に、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成レスポンスを受信すると、ＩＰＵＥ ＵＲＮ２ＣとＰｒｅｆＵＲＮ２Ｃの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける。そして、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成レスポンスをＭＭＥ７に送信する（ステップＳ１２２２）。
　次いで、ＭＭＥ７は、このデフォルトベアラ生成レスポンスを受信すると、ＤｅＮＢ３Ａにアタッチアクセプトを送信する（ステップＳ１２２４）。このアタッチアクセプトは、ＩＤＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２ＣおよびＰｒｅｆＵＲＮ２Ｃを含む。
　次に、ＤｅＮＢ３Ａは、このアタッチアクセプトを受信すると、ＩＰＵＥ ＵＲＮ２ＣとＰｒｅｆＵＲＮ２Ｃの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける。そして、ＤｅＮＢ３Ａは、このデフォルトベアラ生成レスポンスをＵＲＮ２Ａに送信する（ステップＳ１２２６）。
　次いで、ＵＲＮ２Ａは、このアタッチアクセプトを受信すると、ＵＲＮ２Ｃとの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＤ ＵＲＮ２ＡとＩＰＵ ＵＲＮ２Ｃである。次に、ＵＲＮ２Ａは、ＩＰＵＥ ＵＲＮ２ＣとＰｒｅｆＵＲＮ２Ｃの転送先をこのＧＴＰトンネルに関連付ける。そして、ＵＲＮ２Ａは、アタッチアクセプトをＵＲＮ２Ｃに送信する（ステップＳ１２２８）。このアタッチアクセプトは、ＩＰＵＥ ＵＲＮ２Ｃの下位６４ビット（ｉｆ－ｉｄ）とＩＰＵＥ ＵＲＮ２Ａを含む。
　次に、ＵＲＮ２Ｃは、このアタッチアクセプトを受信すると、ＩＰＵＥ ＵＲＮ２Ｃの下位６４ビット（ｉｆ－ｉｄ）を得る。そして、ＵＲＮ２Ｃは、ＵＲＮ２Ａとの間にＧＴＰトンネルを構成する（ステップＳ１２３０）。このＧＴＰトンネルの端点は、ＩＰＵ ＵＲＮ２ＣとＩＰＤ ＵＲＮ２Ａである。
　次いで、ＵＲＮ２Ｃは、ＵＲＮ２Ａ（ＩＰＵＥ ＵＲＮ２Ａ）にＲＳを送信する（ステップＳ１２３２）。
　次に、ＵＲＮ２Ａは、このＲＳを受信すると、ＵＲＮ２ＣにＲＡを送信する（ステップＳ１２３４）。このＲＡは、ＩＰＵＥ ＵＲＮ２Ｃの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次いで、ＵＲＮ２Ｃは、このＲＡを受信すると、ＩＰＵＥ ＵＲＮ２Ｃが使用可能であることを確認する（ステップＳ１２３６）。
　この結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、及びＤｅＮＢ３Ａはそれぞれ表８、９、１０に示すマッピング表を記憶することとなる。
Figure JPOXMLDOC01-appb-T000008
Figure JPOXMLDOC01-appb-T000009
Figure JPOXMLDOC01-appb-T000010
　上記マッピング表について説明する。上記マッピング表には、新たに４行目及び５行目のエントリが追加されている。４行目のエントリによれば、ＩＰＵＥ ＵＲＮ２Ｃ宛てのパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先へ転送される。当該パケットは、表８によればＰ－ＧＷ６により「ＧＴＰＳＧＷ５Ａ」へ転送され、表９によればＳ－ＧＷ５Ａにより「ＧＴＰＤｅＮＢ３Ａ」へ転送され、表１０によればＤｅＮＢ３Ａにより「ＧＴＰＵＲＮ２Ａ」へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。その後、ＵＲＮ２ＡからＵＲＮ２Ｃへ、当該パケットが転送される。
　５行目のエントリによれば、宛先ＩＰアドレスのプレフィクス部分がＰｒｅｆＵＲＮ２Ｃであるパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先へ転送される。当該パケットは、表８によればＰ－ＧＷ６により「ＧＴＰＳＧＷ５Ａ」へ転送され、表９によればＳ－ＧＷ５Ａにより「ＧＴＰＤｅＮＢ３Ａ」へ転送され、表１０によればＤｅＮＢ３Ａにより「ＧＴＰＵＲＮ２Ａ」へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。その後、ＵＲＮ２ＡからＵＲＮ２Ｃへ、当該パケットが転送される。
　　（６）ＩＰｖ６アドレス取得済みのＵＲＮ２ＤのＵＲＮ２Ａへの接続手順
　以下では、上述した接続処理の後に、ＩＰｖ６アドレス取得済みのＵＲＮ２ＤがＵＲＮ２Ａに接続する場合の処理の流れを説明する。例えば、ＵＲＮ２Ｄは、ＵＲＮ２Ａに接続する前に、ＩＰＵＥ ＵＲＮ２ＤというＩＰｖ６アドレスと、ＰｒｅｆＵＲＮ２Ｄというプレフィクスを得ているものとする。また、ＵＲＮ２ＤにはＵＥ１Ｅが接続しており、ＵＥ１ＥはＰｒｅｆＵＲＮ２Ｄに属さないＩＰｖ６アドレスであるＩＰＵＥ１Ｅを得ているものとする。例えば、ＤｅＮＢ３に接続していた仮想セルがＵＲＮ２Ａの下流に接続する場合に、本処理が実行され得る。
　図４３は、本実施形態に係るＵＲＮ２ＤによるＵＲＮ２Ａへの接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＲＮ２Ｄ、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、及びＰ－ＧＷ６が関与する。
　図４３に示すように、まず、ＵＲＮ２Ｄは、ＵＲＮ２Ａと無線回線を確立する（ステップＳ１３０２）。
　次いで、ＵＲＮ２Ｄは、リンクローカル全ルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ１３０４）。このＲＳのソースアドレスは、ＵＲＮ２Ｄのリンクローカルアドレスである。
　次に、ＵＲＮ２Ａは、このＲＳを受信し、ＵＲＮ２Ｄのリンクローカルアドレス宛にＲＡを送信する（ステップＳ１３０６）。このＲＡは、ＰｒｅｆＵＲＮ２Ａに属する／６４のプレフィクス、例えばＰｒｅｆＵＲＮ２Ａ ＵＲＮ２Ｄを含む。
　次いで、ＵＲＮ２Ｄは、このＲＡを受信し、ＩＰＵ ＵＲＮ２Ｄを生成する（ステップＳ１３０８）。
　次に、ＵＲＮ２Ｄは、ＵＲＮ２Ａにアタッチリクエストを送信する（ステップＳ１３１０）。このアタッチリクエストは、ＵＲＮ２Ｄの識別子ＩＤＵＲＮ２Ｄ、ＩＰＵＥ ＵＲＮ２Ｄ、ＰｒｅｆＵＲＮ２ＤおよびＩＰＵＥ１Ｅを含む。
　次いで、ＵＲＮ２Ａは、このアタッチリクエストを受信すると、ＤｅＮＢ３Ａに転送する（ステップＳ１３１２）。その際、ＵＲＮ２Ａは、ＩＰＵＥ ＵＲＮ２ＡおよびＩＤＵＲＮ２Ａをアタッチリクエストに加える。
　次に、ＤｅＮＢ３Ａは、このアタッチリクエストを受信すると、ＭＭＥ７に転送する（ステップＳ１３１４）。
　次いで、ＭＭＥ７は、このアタッチリクエストを受信すると、デフォルトベアラ生成リクエストをＳ－ＧＷ５Ａに送信する（ステップＳ１３１６）。このデフォルトベアラ生成リクエストは、ＩＤＵＲＮ２Ａ、ＩＤＵＲＮ２Ｄ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ｄ、ＰｒｅｆＵＲＮ２ＤおよびＩＰＵＥ１Ｅを含む。
　次に、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成リクエストを受信すると、Ｐ－ＧＷ６に転送する（ステップＳ１３１８）。
　次いで、Ｐ－ＧＷ６は、ＩＰＵＥ ＵＲＮ２ＤとＰｒｅｆＵＲＮ２Ｄの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける。また、Ｐ－ＧＷ６は、ＵＥ１Ｅの転送先をＰｒｅｆＵＲＮ２Ｄに関連付ける。そして、Ｐ－ＧＷ６は、Ｓ－ＧＷ５Ａに、デフォルトベアラ生成レスポンスを送信する（ステップＳ１３２０）。このデフォルトベアラ生成レスポンスは、ＩＤＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ｄ、ＰｒｅｆＵＲＮ２ＤおよびＩＰＵＥ１Ｅを含む。
　次に、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成レスポンスを受信すると、ＩＰＵＥ ＵＲＮ２ＤとＰｒｅｆＵＲＮ２Ｄの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける。また、Ｓ－ＧＷ５Ａは、ＵＥ１Ｅの転送先をＰｒｅｆＵＲＮ２Ｄに関連付ける。そして、Ｓ－ＧＷ５Ａは、このデフォルトベアラ生成レスポンスをＭＭＥ７に送信する（ステップＳ１３２２）。
　次いで、ＭＭＥ７は、このデフォルトベアラ生成レスポンスを受信すると、ＤｅＮＢ３Ａにアタッチアクセプトを送信する（ステップＳ１３２４）。このアタッチアクセプトは、ＩＤＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ｄ、ＰｒｅｆＵＲＮ２ＤおよびＩＰＵＥ１Ｅを含む。
　次に、ＤｅＮＢ３Ａは、このアタッチアクセプトを受信すると、ＩＰＵＥ ＵＲＮ２ＤとＰｒｅｆＵＲＮ２Ｄの転送先をＩＰＵＥ ＵＲＮ２Ａに関連付ける。また、ＤｅＮＢ３Ａは、ＵＥ１Ｅの転送先をＰｒｅｆＵＲＮ２Ｄに関連付ける。そして、ＤｅＮＢ３Ａは、このデフォルトベアラ生成レスポンスをＵＲＮ２Ａに送信する（ステップＳ１３２６）。
　次いで、ＵＲＮ２Ａは、このアタッチアクセプトを受信すると、ＵＲＮ２Ｄとの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＤ ＵＲＮ２ＡとＩＰＵ ＵＲＮ２Ｄである。次に、ＵＲＮ２Ａは、ＩＰＵＥ ＵＲＮ２ＤとＰｒｅｆＵＲＮ２Ｄの転送先をこのＧＴＰトンネルに関連付ける。そして、ＵＲＮ２Ａは、アタッチアクセプトをＵＲＮ２Ｄに送信する（ステップＳ１３２８）。このアタッチアクセプトは、ＩＰＵＥ ＵＲＮ２Ｄの下位６４ビット（ｉｆ－ｉｄ）とＩＰＵＥ ＵＲＮ２Ａを含む。
　次に、ＵＲＮ２Ｄは、このアタッチアクセプトを受信すると、ＩＰＵＥ ＵＲＮ２Ｄの下位６４ビット（ｉｆ－ｉｄ）を得る。そして、ＵＲＮ２Ｄは、ＵＲＮ２Ａとの間にＧＴＰトンネルを構成する（ステップＳ１３３０）。このＧＴＰトンネルの端点は、ＩＰＵ ＵＲＮ２ＤとＩＰＤ ＵＲＮ２Ａである。
　次いで、ＵＲＮ２Ｄは、ＵＲＮ２Ａ（ＩＰＵＥ ＵＲＮ２Ａ）にＲＳを送信する（ステップＳ１３３２）。
　次に、ＵＲＮ２Ａは、このＲＳを受信すると、ＵＲＮ２ＤにＲＡを送信する（ステップＳ１３３４）。このＲＡは、ＩＰＵＥ ＵＲＮ２Ｄの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次いで、ＵＲＮ２Ｄは、このＲＡを受信すると、ＩＰＵＥ ＵＲＮ２Ｄが使用可能であることを確認する（ステップＳ１３３６）。
　この結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、及びＤｅＮＢ３Ａはそれぞれ表１１、１２、１３に示すマッピング表を記憶することとなる。
Figure JPOXMLDOC01-appb-T000011
Figure JPOXMLDOC01-appb-T000012
Figure JPOXMLDOC01-appb-T000013
　上記マッピング表について説明する。上記マッピング表には、新たに６行目～８行目のエントリが追加されている。６行目のエントリによれば、ＩＰＵＥ ＵＲＮ２Ｄ宛てのパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先へ転送される。当該パケットは、表１１によればＰ－ＧＷ６により「ＧＴＰＳＧＷ５Ａ」へ転送され、表１２によればＳ－ＧＷ５Ａにより「ＧＴＰＤｅＮＢ３Ａ」へ転送され、表１３によればＤｅＮＢ３Ａにより「ＧＴＰＵＲＮ２Ａ」へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。その後、ＵＲＮ２ＡからＵＲＮ２Ｄへ、当該パケットが転送される。
　７行目のエントリによれば、宛先ＩＰアドレスのプレフィクス部分がＰｒｅｆＵＲＮ２Ｄであるパケットは、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」に基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先へ転送される。当該パケットは、表１１によればＰ－ＧＷ６により「ＧＴＰＳＧＷ５Ａ」へ転送され、表１２によればＳ－ＧＷ５Ａにより「ＧＴＰＤｅＮＢ３Ａ」へ転送され、表１３によればＤｅＮＢ３Ａにより「ＧＴＰＵＲＮ２Ａ」へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。その後、ＵＲＮ２ＡからＵＲＮ２Ｄへ、当該パケットが転送される。
　８行目のエントリによれば、ＩＰＵＥ１Ｅ宛てのパケットは、転送先欄に記載された「ＰｒｅｆＵＲＮ２Ｄを参照」に基づき、終点ＩＰｖ６アドレスをＰｒｅｆＵＲＮ２Ｄとする７行目のエントリの、転送先欄に記載された「ＩＰＵＥ ＵＲＮ２Ａを参照」にさらに基づき、終点ＩＰｖ６アドレスをＩＰＵＥ ＵＲＮ２Ａとする１行目のエントリの転送先へ転送される。当該パケットは、表１１によればＰ－ＧＷ６により「ＧＴＰＳＧＷ５Ａ」へ転送され、表１２によればＳ－ＧＷ５Ａにより「ＧＴＰＤｅＮＢ３Ａ」へ転送され、表１３によればＤｅＮＢ３Ａにより「ＧＴＰＵＲＮ２Ａ」へ転送される。これにより、当該パケットはＵＲＮ２Ａへ転送されることとなる。その後、ＵＲＮ２ＡからＵＲＮ２Ｄへ、続いてＵＲＮ２ＤからＵＥ１Ｅへ、当該パケットが転送される。
　　（７）Ｓ－ＧＷ５内ハンドオーバの手順
　以下では、上述した接続処理により、ＵＲＮ２Ａの下流にＵＥ１Ａ、ＵＥ１Ｂ、ＵＲＮ２Ｂ及びＵＥ１Ｃ、ＵＲＮ２Ｃ及びＵＥ１Ｄ、並びにＵＲＮ２Ｄ及びＵＥ１Ｅが接続している状態で、ＵＲＮ２ＡがＤｅＮＢ３ＡからＤｅＮＢ３Ｂへハンドオーバする場合の処理の流れを説明する。
　図４４は、本実施形態に係るＵＲＮ２ＡによるＤｅＮＢ３Ｂへのハンドオーバ処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＤｅＮＢ３Ｂ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、及びＰ－ＧＷ６が関与する。
　図４４に示すように、まず、ＤｅＮＢ３Ａは、ＵＲＮ２ＡのＤｅＮＢ３Ｂへのハンドオーバ実行を決定する（ステップＳ１４０２）。
　次いで、ＤｅＮＢ３Ａは、ＤｅＮＢ３Ｂにハンドオーバリクエストを送信する（ステップＳ１４０４）。このハンドオーバリクエストは、ＩＤＵＲＮ２Ａを含む。
　次に、ＤｅＮＢ３Ｂは、ＤｅＮＢ３ＡにハンドオーバリクエストＡＣＫを送信する（ステップＳ１４０６）。このハンドオーバリクエストＡＣＫは、ＩＤＵＲＮ２Ａを含む。
　次いで、ＵＲＮ２Ａは、ＤｅＮＢ３Ｂと無線回線を確立する（ステップＳ１４０８）。
　次に、ＵＲＮ２Ａは、リンクローカル全ルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ１４１０）。このＲＳのソースアドレスは、ＵＲＮ２Ａのリンクローカルアドレスである。
　次いで、ＤｅＮＢ３Ｂは、このＲＳを受信し、ＵＲＮ２Ａのリンクローカルアドレス宛にＲＡを送信する（ステップＳ１４１２）。このＲＡは、ＩＰＤ ＤｅＮＢ３Ｂの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次に、ＵＲＮ２Ａは、このＲＡを受信し、ＩＰｖ６アドレスＩＰ２Ｕ ＵＲＮ２Ａを生成する（ステップＳ１４１４）。ＩＰ２Ｕ ＵＲＮ２Ａは、ＵＲＮ２ＡがＤｅＮＢ３Ｂとの間にＧＴＰトンネルを確立する際に使用される。
　次いで、ＵＲＮ２Ａは、ＤｅＮＢ３Ｂにアタッチリクエストを送信する（ステップＳ１４１６）。このアタッチリクエストは、ＵＲＮ２Ａの識別子ＩＤＵＲＮ２Ａ、ＩＰ２Ｕ ＵＲＮ２ＡおよびＩＰＵＥ ＵＲＮ２Ａを含む。
　次に、ＤｅＮＢ３Ｂは、このアタッチリクエストを受信すると、ＭＭＥ７にパススイッチリクエストを送信する（ステップＳ１４１８）。このパススイッチリクエストは、ＩＤＵＲＮ２Ａ、ＩＰ２Ｕ ＵＲＮ２ＡおよびＩＰＵＥ ＵＲＮ２Ａを含む。
　次いで、ＭＭＥ７は、パススイッチリクエストを受信すると、Ｓ－ＧＷ５Ａにベアラ変更リクエストを送信する（ステップＳ１４２０）。このベアラ変更リクエストは、ＩＤＵＲＮ２Ａ、ＩＰ２Ｕ ＵＲＮ２ＡおよびＩＰＵＥ ＵＲＮ２Ａを含む。
　次に、Ｓ－ＧＷ５Ａは、このベアラ変更リクエストを受信すると、ＵＲＮ２ＡがＳ－ＧＷ５Ａの下流のＤｅＮＢ３間でハンドオーバしたことを検知し、Ｓ－ＧＷ５ＡとＤｅＮＢ３Ａとの間に確立したＧＴＰトンネルを解放し、Ｓ－ＧＷ５ＡとＤｅＮＢ３Ｂと間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＤ ＳＧＷ５ＡとＩＰＵ ＤｅＮＢ３Ｂである。そして、Ｓ－ＧＷ５Ａは、ＩＰＵＥ ＵＲＮ２Ａの転送先をこのＧＴＰトンネルに関連付ける。そして、Ｓ－ＧＷ５Ａは、ベアラ変更レスポンスをＭＭＥ７に送信する（ステップＳ１４２２）。このベアラ変更レスポンスは、ＩＤＵＲＮ２Ａ、ＩＰ２Ｕ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａおよびマッピング表のうちルートＵＲＮがＵＲＮ２Ａであるエントリを含む。
　次いで、ＭＭＥ７は、このベアラ変更レスポンスを受信すると、ＤｅＮＢ３ＢにパススイッチリクエストＡＣＫを送信する（ステップＳ１４２４）。このパススイッチリクエストＡＣＫは、ＩＤＵＲＮ２Ａ、ＩＰ２Ｕ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２ＡおよびＳ－ＧＷ５Ａのマッピング表のうちルートＵＲＮがＵＲＮ２Ａであるエントリを含む。
　次に、ＤｅＮＢ３Ｂは、このパススイッチリクエストＡＣＫを受信すると、ＤｅＮＢ３ＢとＳ－ＧＷ５Ａとの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＵ ＤｅＮＢ３ＢとＩＰＤ ＳＧＷ５Ａである。さらにＤｅＮＢ３Ｂは、ＵＲＮ２Ａとの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＤ ＤｅＮＢ３ＢとＩＰＵ ＵＲＮ２Ａである。次に、ＤｅＮＢ３Ｂは、アタッチアクセプトが含むマッピング表エントリを、自身のマッピング表に登録する。さらにＤｅＮＢ３Ｂは、ＩＰＵＥ ＵＲＮ２Ａの転送先をＵＲＮ２ＡへのＧＴＰトンネルに関連付ける。次に、ＤｅＮＢ３Ｂは、アタッチアクセプトをＵＲＮ２Ａに送信する（ステップＳ１４２６）。このアタッチアクセプトは、ＩＰＵＥ ＵＲＮ２Ａの下位６４ビット（ｉｆ－ｉｄ）を含む。
　以上の動作の結果、ＵＲＮ２Ａ、ＤｅＮＢ３Ｂ、Ｓ－ＧＷ５Ａ間にＧＴＰトンネルが確立される（ステップＳ１４２８）。また、Ｓ－ＧＷ５ＡとＰ－ＧＷ６との間のＧＴＰトンネルは維持される。
　次いで、ＵＲＮ２Ａは、このアタッチアクセプトを受信すると、ＵＥとして動作する際のＩＰｖ６アドレスを得るため、Ｐ－ＧＷ６にＲＳを送信する（ステップＳ１４３０）。
　次に、Ｐ－ＧＷ６は、このＲＳを受信すると、ＵＲＮ２ＡにＲＡを送信する（ステップＳ１４３２）。このＲＡはＩＰＵＥ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次いで、ＵＲＮ２Ａは、このＲＡを受信し、ＩＰＵＥ ＵＲＮ２Ａが利用可能であることを確認する（ステップＳ１４３４）。
　この結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ａ、ＤｅＮＢ３Ｂは、それぞれ表１４、１５、１６に示すマッピング表を記憶することとなる。
Figure JPOXMLDOC01-appb-T000014
Figure JPOXMLDOC01-appb-T000015
Figure JPOXMLDOC01-appb-T000016
　上記マッピング表について説明する。表１１と表１４とを比較すると、これらは同一であり、ハンドオーバによって変化していない。表１２と表１５とを比較すると、１行目のエントリの転送先が「ＧＴＰＤｅＮＢ３Ａ」から「ＧＴＰＤｅＮＢ３Ｂ」へ変化している。即ち、Ｓ－ＧＷ５Ａ内のハンドオーバの際には、Ｓ－ＧＷ５Ａはマッピング表の１行目のエントリのみを更新すればよい。表１３と表１６とを比較すると、これらは同一である。表１６に示したマッピング表のうち１行目のエントリは、ＤｅＮＢ３Ｂにより登録される。他方、表１６に示したマッピング表のうちルートＵＲＮの欄が「ＩＤＵＲＮ２Ａ」であるエントリ、即ち２行目以下の全てのエントリは、ハンドオーバにより引き継がれたものである。即ち、ハンドオーバの際には、ＤｅＮＢ３Ｂは、マッピング表の引き継ぎにより、マッピング表の生成処理を一部省略することが可能である。このように、ハンドオーバに際してはマッピング表の極一部の更新又は引き継ぎを行うことで転送先の再設定が完了されるため、ＵＲＮ２の配下のＵＥ１の位置登録等のためのシグナリングが大幅に削減可能となる。
　　（８）Ｓ－ＧＷ５間ハンドオーバの手順
　以下では、ＵＲＮ２Ａの下流にＵＥ１Ａ、ＵＥ１Ｂ、ＵＲＮ２Ｂ及びＵＥ１Ｃ、ＵＲＮ２Ｃ及びＵＥ１Ｄ、並びにＵＲＮ２Ｄ及びＵＥ１Ｅが接続している状態で、ＵＲＮ２ＡがＤｅＮＢ３ＡからＤｅＮＢ３Ｃへハンドオーバする場合の処理の流れを説明する。
　図４５は、本実施形態に係るＵＲＮ２ＡによるＤｅＮＢ３Ｃへのハンドオーバ処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＲＮ２Ａ、ＤｅＮＢ３Ａ、ＤｅＮＢ３Ｃ、ＭＭＥ７、Ｓ－ＧＷ５Ａ、Ｓ－ＧＷ５Ｂ及びＰ－ＧＷ６が関与する。
　図４５に示すように、まず、ＤｅＮＢ３Ａは、ＵＲＮ２ＡのＤｅＮＢ３Ｃへのハンドオーバ実行を決定する（ステップＳ１５０２）。
　次いで、ＤｅＮＢ３Ａは、ＤｅＮＢ３Ｃにハンドオーバリクエストを送信する（ステップＳ１５０４）。このハンドオーバリクエストは、ＩＤＵＲＮ２Ａを含む。
　次に、ＤｅＮＢ３Ｃは、ＤｅＮＢ３ＡにハンドオーバリクエストＡＣＫを送信する（ステップＳ１５０６）。このハンドオーバリクエストＡＣＫは、ＩＤＵＲＮ２Ａを含む。
　次いで、ＵＲＮ２Ａは、ＤｅＮＢ３Ｃと無線回線を確立する（ステップＳ１５０８）。
　次に、ＵＲＮ２Ａは、リンクローカル全ルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ１５１０）。このＲＳのソースアドレスは、ＵＲＮ２Ａのリンクローカルアドレスである。
　次いで、ＤｅＮＢ３Ｃは、このＲＳを受信すると、ＵＲＮ２Ａのリンクローカルアドレス宛にＲＡを送信する（ステップＳ１５１２）。このＲＡは、ＩＰＤ ＤｅＮＢ３Ｃの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次に、ＵＲＮ２Ａは、このＲＡを受信し、ＩＰｖ６アドレスＩＰ３Ｕ ＵＲＮ２Ａを生成する（ステップＳ１５１４）。ＩＰ３Ｕ ＵＲＮ２Ａは、ＵＲＮ２ＡがＤｅＮＢ３Ｃとの間にＧＴＰトンネルを確立する際に使用される。
　次いで、ＵＲＮ２Ａは、ＤｅＮＢ３Ｃにアタッチリクエストを送信する（ステップＳ１５１６）。このアタッチリクエストは、ＵＲＮ２Ａの識別子ＩＤＵＲＮ２Ａ、ＩＰ３Ｕ ＵＲＮ２ＡおよびＩＰＵＥ ＵＲＮ２Ａを含む。
　次に、ＤｅＮＢ３Ｃは、このアタッチリクエストを受信すると、ＭＭＥ７にパススイッチリクエストを送信する（ステップＳ１５１８）。このパススイッチリクエストは、ＩＤＵＲＮ２Ａ、ＩＰ３Ｕ ＵＲＮ２ＡおよびＩＰＵＥ ＵＲＮ２Ａを含む。
　次いで、ＭＭＥ７は、このパススイッチリクエストを受信すると、Ｓ－ＧＷ５Ｂにベアラ変更リクエストを送信する（ステップＳ１５２０）。このベアラ変更リクエストは、ＩＤＵＲＮ２Ａ、ＩＰ３Ｕ ＵＲＮ２ＡおよびＩＰＵＥ ＵＲＮ２Ａを含む。
　次に、Ｓ－ＧＷ５Ｂは、このベアラ変更リクエストを受信すると、Ｐ－ＧＷ６に転送する（ステップＳ１５２２）。
　次いで、Ｐ－ＧＷ６は、このベアラ変更リクエストを受信すると、ＵＲＮ２ＡがＳ－ＧＷ５ＡとＳ－ＧＷ５Ｂ間でハンドオーバしたことを検知し、Ｐ－ＧＷ６とＳ－ＧＷ５Ａ間に確立したＧＴＰトンネルを解放し、Ｐ－ＧＷ６とＳ－ＧＷ５Ｂ間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＤ ＰＧＷ６とＩＰＵ ＳＧＷ５Ｂである。そして、Ｐ－ＧＷ６は、ＩＰＵＥ ＵＲＮ２Ａの転送先をこのＧＴＰトンネルに関連付ける。そして、Ｐ－ＧＷ６は、ベアラ変更レスポンスをＳ－ＧＷ５Ｂに送信する（ステップＳ１５２４）。このベアラ変更レスポンスは、ＩＤＵＲＮ２Ａ、ＩＰ３Ｕ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａおよびマッピング表のうち、ルートＵＲＮがＵＲＮ２Ａであるエントリを含む。
　次に、Ｓ－ＧＷ５Ｂは、このベアラ変更レスポンスを受信すると、Ｐ－ＧＷ６とＳ－ＧＷ５Ｂの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点はＩＰＵ ＳＧＷ５ＢとＩＰＤ ＰＧＷ６である。さらにＳ－ＧＷ５Ｂは、ＤｅＮＢ３Ｃとの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＤ ＳＧＷ５ＢとＩＰＵ ＤｅＮＢ３Ｃである。次に、Ｓ－ＧＷ５Ｂは、ベアラ変更レスポンスが含むマッピング表エントリを自身のマッピング表に登録する。さらに、Ｓ－ＧＷ５Ｂは、ＩＰＵＥ ＵＲＮ２Ａの転送先をＤｅＮＢ３ＣへのＧＴＰトンネルに関連付ける。次に、Ｓ－ＧＷ５Ｂは、ベアラ変更レスポンスをＭＭＥ７に転送する（ステップＳ１５２６）。このベアラ変更レスポンスは、ＩＤＵＲＮ２Ａ、ＩＰ３Ｕ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａの下位６４ビット（ｉｆ－ｉｄ）およびマッピング表のうちルートＵＲＮがＵＲＮ２Ａであるエントリを含む。
　次いで、ＭＭＥ７は、このベアラ変更レスポンスを受信すると、ＤｅＮＢ３ＣにパススイッチリクエストＡＣＫを送信する（ステップＳ１５２８）。このパススイッチリクエストＡＣＫは、ＩＤＵＲＮ２Ａ、ＩＰ３Ｕ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａ、ＩＰＵＥ ＵＲＮ２Ａの下位６４ビット（ｉｆ－ｉｄ）およびＳ－ＧＷ５Ｂマッピング表のうちルートＵＲＮがＵＲＮ２Ａであるエントリを含む。
　次に、ＤｅＮＢ３Ｃは、このパススイッチリクエストＡＣＫを受信すると、ＤｅＮＢ３ＣとＳ－ＧＷ５Ｂの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＵ ＤｅＮＢ３ＣとＩＰＤ ＳＧＷ５Ｂである。さらに、ＤｅＮＢ３Ｃは、ＵＲＮ２Ａとの間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＤ ＤｅＮＢ３ＣとＩＰＵ ＵＲＮ２Ａである。次に、ＤｅＮＢ３Ｃは、パススイッチリクエストＡＣＫが含むマッピング表エントリを自身のマッピング表に登録する。さらに、ＤｅＮＢ３Ｃは、ＩＰＵＥ ＵＲＮ２Ａの転送先をＵＲＮ２ＡへのＧＴＰトンネルに関連付ける。次に、ＤｅＮＢ３Ｃは、アタッチアクセプトをＵＲＮ２Ａに転送する（ステップＳ１５３０）。このアタッチアクセプトは、ＩＰＵＥ ＵＲＮ２Ａの下位６４ビット（ｉｆ－ｉｄ）を含む。
　以上の処理の結果、ＵＲＮ２Ａ、ＤｅＮＢ３Ｃ、Ｓ－ＧＷ５Ｂ、Ｐ－ＧＷ６間にＧＴＰトンネルが確立される（ステップＳ１５３２）。
　次いで、ＵＲＮ２Ａは、このアタッチアクセプトを受信すると、ＵＥとして動作する際のＩＰｖ６アドレスを得るため、Ｐ－ＧＷ６にＲＳを送信する（ステップＳ１５３４）。
　次に、Ｐ－ＧＷ６は、このＲＳを受信すると、ＵＲＮ２ＡにＲＡを送信する（ステップＳ１５３６）。このＲＡは、ＩＰＵＥ ＵＲＮ２Ａの上位６４ビット（ｐｒｅｆｉｘ）を含む。
　次いで、ＵＲＮ２Ａは、このＲＡを受信し、ＩＰＵＥ ＵＲＮ２Ａが利用可能であることを確認する（ステップＳ１５３８）。
　この結果、Ｐ－ＧＷ６、Ｓ－ＧＷ５Ｂ、ＤｅＮＢ３Ｃはそれぞれ表１７、１８、１９に示すマッピング表を記憶することとなる。
Figure JPOXMLDOC01-appb-T000017
Figure JPOXMLDOC01-appb-T000018
Figure JPOXMLDOC01-appb-T000019
　上記マッピング表について説明する。表１４と表１７とを比較すると、１行目のエントリの転送先が「ＧＴＰＳＧＷ５Ａ」から「ＧＴＰＳＧＷ５Ｂ」へ変化している。即ち、Ｓ－ＧＷ５をまたぐハンドオーバの際には、Ｐ－ＧＷ６はマッピング表の１行目のエントリのみを更新すればよい。表１５と表１８とを比較すると、１行目のエントリの転送先が「ＧＴＰＤｅＮＢ３Ｂ」から「ＧＴＰＤｅＮＢ３Ｃ」へ変化している。表１８に示したマッピング表のうち１行目のエントリは、Ｓ－ＧＷ５Ｂにより登録される。他方、表１８に示したマッピング表のうちルートＵＲＮの欄が「ＩＤＵＲＮ２Ａ」であるエントリ、即ち２行目以下の全てのエントリは、ハンドオーバにより引き継がれたものである。即ち、ハンドオーバの際には、Ｓ－ＧＷ５Ｂは、マッピング表の引き継ぎにより、マッピング表の生成処理を一部省略することが可能である。表１６と表１９とを比較すると、これらは同一である。表１９に示したマッピング表のうち１行目のエントリは、ＤｅＮＢ３Ｃにより登録される。他方、表１９に示したマッピング表のうちルートＵＲＮの欄が「ＩＤＵＲＮ２Ａ」であるエントリ、即ち２行目以下の全てのエントリは、ハンドオーバにより引き継がれたものである。即ち、ハンドオーバの際には、ＤｅＮＢ３Ｃは、マッピング表の引き継ぎにより、マッピング表の生成処理を一部省略することが可能である。このように、Ｓ－ＧＷ５をまたぐハンドオーバに際してもマッピング表の極一部の更新又は引き継ぎを行うことで転送先の再設定が完了されるため、ＵＲＮ２の配下のＵＥ１の位置登録等のためのシグナリングが大幅に削減可能となる。
　　＜４．３．効果＞
　以下、上述したプロトコルの主な効果を説明する。
　例えば、上述したプロトコルは、３ＧＰＰのアーキテクチャに適合したプロトコルである。例えば、Ｐ－ＧＷ、Ｓ－ＧＷ、ＭＭＥ、ｅＮＢ、ＤｅＮＢ、ＲＮ、及びＵＥの機能分担が維持される。また、これらの機器間で定められたインタフェースが維持される。また、これらの機器間で定められたメッセージシーケンスが維持される。
　また、既にＩＰｖ６アドレスを取得済みのＵＥ１は、仮想セルに接続後も通信を継続することが可能である。
　また、本プロトコルでは、ＤＨＣＰ－ＰＤが用いられる。これにより、入れ子の仮想セルを実現することが可能である。また、ＤＨＣＰ－ＰＤが用いられることで、Ｐ－ＧＷ６、Ｓ－ＧＷ５、又はＤｅＮＢ３が記憶すべき情報量が、仮想セル内でＩＰｖ６アドレスを得たＵＥ１又はＵＲＮ２の台数に依存しない。
　また、本プロトコルでは、マッピング表が利用される。これにより、仮想セルがハンドオーバした際に更新する項目が少なくなる。また、ＵＲＮ２がＤｅＮＢ３間でハンドオーバした際、ＵＲＮ２のみがシグナリングを行う。これにより、ハンドオーバの際に、ＵＲＮ２配下のＵＥ１等が個々にシグナリングを行うことが回避され、シグナリング量が抑制される。
　また、仮想セル内でＩＰｖ６アドレスを得たＵＥ１又はＵＲＮ２の数によっては、ＵＲＮ２のハンドオーバ時のシグナリングトラフィックは増加しない。
　また、ＵＲＮ２は、仮想セルに接続したＵＥ又はＵＲＮ２をＭＭＥ７に登録する際、１台ごとに行うのではなく、複数台をまとめて行うことが可能である。これにより、シグナリングパケットの個数を抑制することが可能である。
　また、ＵＥ１及びＵＲＮ２が３ＧＰＰネットワーク内で行う際の通信の経路は、迂回がなく最適であると言える。
　また、本プロトコルでは、３ＧＰＰで規定されているトンネリング以外にはトンネリングが用いられない。よって、本プロトコルの導入に際して、ヘッダオーバヘッドは増加しない。
　＜＜５．ユースケース＞＞
　上述したプロトコルは、多様なユースケースに適用され得る。
　　（１）移動時のネットワークサービスの実現
　例えば、バス又は電車等の公共の乗り物にＵＲＮ２が搭載される場合、ＵＲＮ２は、ローカルコンテンツをＵＲＮ２に接続されているサーバから乗客のＵＥ１に提供することで、移動に伴うアクセスの非連続性等が解消可能である。また、ＵＲＮ２が接続しているＤｅＮＢ３、又はコアネットワーク上のエンティティに接続されたサーバからのサービスに関しても、移動透過性が実現される。特に低遅延時間が求められるサービスには、ＵＲＮ２に接続されたサーバが有効である。また、公共の乗り物に搭載されたＵＲＮ２に、乗客のＵＲＮ２により形成される入れ子仮想セルが接続する場合、乗客のＵＲＮ２のみが接続処理を行うだけで、入れ子仮想セルのネットワークへの接続性は継続される。これにより、乗車時すべてのＵＥ１がネットワークへの接続処理を行う事態が回避されるので、無線利用効率の改善が実現される。
　　（２）ＵＥ１が密集している環境での無線利用効率の向上
　例えば、繁華街又はイベント開催時などの、ＵＥ１の密度が著しく高い環境下においては、ＵＥ１がＲＮ機能を具備して、周囲の他のＵＥ１の移動透過性を実現することで、
無線利用効率の向上が実現され、より多くのＵＥ１を収容可能となる。
　　（３）セキュリティシステムへの応用
　例えば、移動する乗り物に搭載されたＵＲＮ２にカメラが接続されることで、高度なセキュリティシステムを移動環境にも提供可能となる。例えば、撮像画像がＵＲＮ２に接続されたサーバに蓄積及びデータ解析され、必要に応じてＵＲＮ２がコアネットワーク内のエンティティ又はクラウド上の計算リソースとの通信を行うことで、高度なセキュリティシステムが実現される。
　　（４）コグニティブ無線システムのダイナミックな運用サービスの実現
　コグニティブ無線システムとは、地域ごとの利用可能な周波数を管理する周波数データベースを利用することで、当該周波数を利用したアクセス網を提供するシステムである。例えば、ＵＲＮ２に、コグニティブ無線システムのアクセスポイント（即ち、基地局）としての機能が実装されることが考えられる。その場合、ＵＲＮ２は、ロケーション情報（ＧＰＳ情報又は無線基地局情報等）を利用して周波数データベースから現在位置で利用可能な周波数を特定し、当該周波数を利用して仮想セルを提供することが可能となる。また、ＵＲＮ２経由でネットワークアクセスサービス、若しくはＵＥ１－ＵＥ１間、ＵＲＮ２－ＵＥ１間でのＤ２Ｄ（Device　to　device）通信サービスの提供も可能となる。
　　（５）ドローン技術によるダイナミックな運用サービスの実現
　ドローンに、仮想セルを提供するＵＲＮ２としての機能を実装することで、飛行地域の各種デバイス群向けの無線サービスの提供が可能となる。ＵＲＮ２として機能するドローンを、以下ではキングドローンとも称する。キングドローンは、コグニティブ無線システムとしての機能を有していてもよく、飛行中の地域における利用可能な周波数を周波数データベースとの通信により特定してもよい。仮想セルに接続するデバイス群は、例えばセンサデバイスであってもよい。例えば、農業に関して、農作物を育てる畑に地質、温度、湿度又は熟成度センサ等が配置され、キングドローンが畑の上空を飛行して、センサデバイス群にネットワーク層ＩＰアドレスを割り当ててもよい。そして、キングドローンは、当該地域を飛行する度にセンサデバイス群からセンサ情報を取得して、クラウド上のサーバへリレーしてもよい。また、イベント会場又は海水浴場等の期間限定で人が集まる地域に関して、キングドローンが上空を飛行して当該地域のＬＴＥデバイスにネットワーク層ＩＰアドレスを割当てて、端末上のアプリケーションと連携したサービスを提供してもよい。キングドローンは、イベント等の期間が終了後、配布したネットワーク層ＩＰアドレスの無効化（即ち、回収）を行ってもよい。
　　（６）車載センサシステムの実現
　車にＵＲＮ２としての機能を搭載することで、車内又は車外モニタリング用の各種センサ（路面センサ又はレーダー等）により取得されたセンサ情報を収集し、車内で蓄積及び解析することが可能となる。また、ＵＲＮ２は、必要に応じてクラウド上のサーバへ接続し、ビッグデータ等と連携したより高度な解析処理を行ってもよい。仮想セルの移動透過性を実現する事で、車での移動時においても、車、ＵＲＮ２又はセンサへのこの解析サービスのフィードバックを行うことが可能となる。
　　（７）長距離無線接続サービスの実現
　入れ子構造の仮想セルの実現により、ＵＲＮ２－ＵＥ１のワンホップを数珠つなぎにする、いわゆるマルチホップ接続（即ち、仮想セルの数珠つなぎ）により、カバレッジの拡大が期待される。
　＜＜６．応用例＞＞
　本開示に係る技術は、様々な製品へ応用可能である。例えば、Ｐ－ＧＷ６は、タワーサーバ、ラックサーバ、又はブレードサーバなどのいずれかの種類のサーバとして実現されてもよい。また、Ｐ－ＧＷ６の少なくとも一部の構成要素は、サーバに搭載されるモジュール（例えば、１つのダイで構成される集積回路モジュール、又はブレードサーバのスロットに挿入されるカード若しくはブレード）において実現されてもよい。
　また、例えば、ＵＥ１又はＵＲＮ２は、スマートフォン、タブレットＰＣ（Personal　Computer）、ノートＰＣ、携帯型ゲーム端末、携帯型／ドングル型のモバイルルータ若しくはデジタルカメラなどのモバイル端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、ＵＥ１又はＵＲＮ２は、Ｍ２Ｍ（Machine　To　Machine）通信を行う端末（ＭＴＣ（Machine　Type　Communication）端末ともいう）として実現されてもよい。さらに、ＵＥ１又はＵＲＮ２の少なくとも一部の構成要素は、これら端末に搭載されるモジュール（例えば、１つのダイで構成される集積回路モジュール）において実現されてもよい。
　　＜６．１．通信制御装置に関する応用例＞
　図４６は、本開示に係る技術が適用され得るサーバ７００の概略的な構成の一例を示すブロック図である。サーバ７００は、プロセッサ７０１、メモリ７０２、ストレージ７０３、ネットワークインタフェース７０４及びバス７０６を備える。
　プロセッサ７０１は、例えばＣＰＵ（Central　Processing　Unit）又はＤＳＰ（Digital　Signal　Processor）であってよく、サーバ７００の各種機能を制御する。メモリ７０２は、ＲＡＭ（Random　Access　Memory）及びＲＯＭ（Read　Only　Memory）を含み、プロセッサ７０１により実行されるプログラム及びデータを記憶する。ストレージ７０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。
　ネットワークインタフェース７０４は、サーバ７００を有線通信ネットワーク７０５に接続するための有線通信インタフェースである。有線通信ネットワーク７０５は、ＥＰＣ（Evolved　Packet　Core）などのコアネットワークであってもよく、又はインターネットなどのＰＤＮ（Packet　Data　Network）であってもよい。
　バス７０６は、プロセッサ７０１、メモリ７０２、ストレージ７０３及びネットワークインタフェース７０４を互いに接続する。バス７０６は、速度の異なる２つ以上のバス（例えば、高速バス及び低速バス）を含んでもよい。
　図４６に示したサーバ７００において、図１１を参照して説明したＰ－ＧＷ６に含まれる１つ以上の構成要素（通信制御部６３１）は、プロセッサ７０１において実装されてもよい。一例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）がサーバ７００にインストールされ、プロセッサ７０１が当該プログラムを実行してもよい。別の例として、サーバ７００は、プロセッサ７０１及びメモリ７０２を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムをメモリ７０２に記憶し、当該プログラムをプロセッサ７０１により実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてサーバ７００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるための上記プログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図４６に示したサーバ７００において、例えば、図１１を参照して説明したネットワーク通信部６１０は、ネットワークインタフェース７０４において実装されてもよい。また、記憶部６２０は、メモリ７０２及び／又はストレージ７０３において実装されてもよい。
　　＜６．２．端末装置及び中継装置に関する応用例＞
　（第１の応用例）
　図４７は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２、１つ以上のアンテナスイッチ９１５、１つ以上のアンテナ９１６、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。
　プロセッサ９０１は、例えばＣＰＵ又はＳｏＣ（System　on　Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal　Serial　Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。
　カメラ９０６は、例えば、ＣＣＤ（Charge　Coupled　Device）又はＣＭＯＳ（Complementary　Metal　Oxide　Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。
　無線通信インタフェース９１２は、ＬＴＥ又はＬＴＥ－Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９１２は、典型的には、ＢＢプロセッサ９１３及びＲＦ回路９１４などを含み得る。ＢＢプロセッサ９１３は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９１４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９１６を介して無線信号を送受信する。無線通信インタフェース９１２は、ＢＢプロセッサ９１３及びＲＦ回路９１４を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１２は、図４７に示したように複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含んでもよい。なお、図４７には無線通信インタフェース９１２が複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含む例を示したが、無線通信インタフェース９１２は単一のＢＢプロセッサ９１３又は単一のＲＦ回路９１４を含んでもよい。
　さらに、無線通信インタフェース９１２は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ（Local　Area　Network）方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９１３及びＲＦ回路９１４を含んでもよい。
　アンテナスイッチ９１５の各々は、無線通信インタフェース９１２に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１６の接続先を切り替える。
　アンテナ９１６の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１２による無線信号の送受信のために使用される。スマートフォン９００は、図４７に示したように複数のアンテナ９１６を有してもよい。なお、図４７にはスマートフォン９００が複数のアンテナ９１６を有する例を示したが、スマートフォン９００は単一のアンテナ９１６を有してもよい。
　さらに、スマートフォン９００は、無線通信方式ごとにアンテナ９１６を備えてもよい。その場合に、アンテナスイッチ９１５は、スマートフォン９００の構成から省略されてもよい。
　バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図４７に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。
　図４７に示したスマートフォン９００において、図９を参照して説明したＵＥ１に含まれる１つ以上の構成要素（通信制御部１４１）、又は図１０を参照して説明したＵＲＮ２に含まれる１つ以上の構成要素（中継部２４１及び／又は通信制御部２４３）は、無線通信インタフェース９１２において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９０１又は補助コントローラ９１９において実装されてもよい。一例として、スマートフォン９００は、無線通信インタフェース９１２の一部（例えば、ＢＢプロセッサ９１３）若しくは全部、プロセッサ９０１、及び／又は補助コントローラ９１９を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがスマートフォン９００にインストールされ、無線通信インタフェース９１２（例えば、ＢＢプロセッサ９１３）、プロセッサ９０１、及び／又は補助コントローラ９１９が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてスマートフォン９００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図４７に示したスマートフォン９００において、例えば、図９を参照して説明した無線通信部１２０又は図１０を参照して説明した無線通信部２２０は、無線通信インタフェース９１２（例えば、ＲＦ回路９１４）において実装されてもよい。また、アンテナ部１１０又はアンテナ部２１０は、アンテナ９１６において実装されてもよい。また、記憶部１３０又は記憶部２３０は、メモリ９０２において実装されてもよい。
　（第２の応用例）
　図４８は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global　Positioning　System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、１つ以上のアンテナスイッチ９３６、１つ以上のアンテナ９３７及びバッテリー９３８を備える。
　プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。
　ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。
　コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。
　無線通信インタフェース９３３は、ＬＴＥ又はＬＴＥ－Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９３３は、典型的には、ＢＢプロセッサ９３４及びＲＦ回路９３５などを含み得る。ＢＢプロセッサ９３４は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９３５は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９３７を介して無線信号を送受信する。無線通信インタフェース９３３は、ＢＢプロセッサ９３４及びＲＦ回路９３５を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、図４８に示したように複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含んでもよい。なお、図４８には無線通信インタフェース９３３が複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含む例を示したが、無線通信インタフェース９３３は単一のＢＢプロセッサ９３４又は単一のＲＦ回路９３５を含んでもよい。
　さらに、無線通信インタフェース９３３は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９３４及びＲＦ回路９３５を含んでもよい。
　アンテナスイッチ９３６の各々は、無線通信インタフェース９３３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９３７の接続先を切り替える。
　アンテナ９３７の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９３３による無線信号の送受信のために使用される。カーナビゲーション装置９２０は、図４８に示したように複数のアンテナ９３７を有してもよい。なお、図４８にはカーナビゲーション装置９２０が複数のアンテナ９３７を有する例を示したが、カーナビゲーション装置９２０は単一のアンテナ９３７を有してもよい。
　さらに、カーナビゲーション装置９２０は、無線通信方式ごとにアンテナ９３７を備えてもよい。その場合に、アンテナスイッチ９３６は、カーナビゲーション装置９２０の構成から省略されてもよい。
　バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図４８に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。
　図４８に示したカーナビゲーション装置９２０において、図９を参照して説明したＵＥ１に含まれる１つ以上の構成要素（通信制御部１４１）、又は図１０を参照して説明したＵＲＮ２に含まれる１つ以上の構成要素（中継部２４１及び／又は通信制御部２４３）は、無線通信インタフェース９３３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９２１において実装されてもよい。一例として、カーナビゲーション装置９２０は、無線通信インタフェース９３３の一部（例えば、ＢＢプロセッサ９３４）若しくは全部及び／又はプロセッサ９２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがカーナビゲーション装置９２０にインストールされ、無線通信インタフェース９３３（例えば、ＢＢプロセッサ９３４）及び／又はプロセッサ９２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてカーナビゲーション装置９２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図４８に示したカーナビゲーション装置９２０において、例えば、図９を参照して説明した無線通信部１２０又は図１０を参照して説明した無線通信部２２０は、無線通信インタフェース９３３（例えば、ＲＦ回路９３５）において実装されてもよい。また、アンテナ部１１０又はアンテナ部２１０は、アンテナ９３７において実装されてもよい。また、記憶部１３０又は記憶部２３０は、メモリ９２２において実装されてもよい。
　また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。即ち、通信制御部１４１、又は中継部２４１及び通信制御部２４３を備える装置として車載システム（又は車両）９４０が提供されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。
　＜＜７．まとめ＞＞
　以上、図１～図４８を参照して、本開示の一実施形態について詳細に説明した。上記説明したように、本実施形態に係るＵＲＮ２は、接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継しつつ、ひとつ以上の第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる。これにより、仮想セルにおけるＩＰ移動透過性が実現されると共に、ＵＲＮ２又は配下の第２の装置のためにＰ－ＧＷ６、Ｓ－ＧＷ５、又はＤｅＮＢ３が記憶すべき情報量を抑制することが可能となる。
　以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
　また、本明細書においてフローチャート及びシーケンス図を用いて説明した処理は、必ずしも図示された順序で実行されなくてもよい。いくつかの処理ステップは、並列的に実行されてもよい。また、追加的な処理ステップが採用されてもよく、一部の処理ステップが省略されてもよい。
　また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
　なお、以下のような構成も本開示の技術的範囲に属する。
（１）
　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継する中継部と、
　ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる制御部と、
を備える中継装置。
（２）
　前記第２の装置とＰ－ＧＷ（Packet　Data　Network　Gateway）との間に設定される伝送路のうち前記中継装置とＰ－ＧＷとの間の区間に、前記中継装置とＰ－ＧＷとの間で設定される伝送路が流用される、前記（１）に記載の中継装置。
（３）
　前記伝送路は、ベアラである、前記（２）に記載の中継装置。
（４）
　前記伝送路は、ＩＰフローである、前記（２）又は（３）に記載の中継装置。
（５）
　前記制御部は、前記中継装置がハンドオーバを開始することを示す情報を前記第２の装置へ通知する、前記（１）～（４）のいずれか一項に記載の中継装置。
（６）
　前記制御部は、前記中継装置がハンドオーバを完了したことを示す情報を前記第２の装置へ通知する、前記（５）に記載の中継装置。
（７）
　前記プレフィクス部分のうち共通しない部分により、前記中継装置又は他の中継装置により形成される仮想セルの各々が識別される、前記（１）～（６）のいずれか一項に記載の中継装置。
（８）
　前記プレフィクス部分は、ＩＰｖ６におけるサブネットプレフィクスである、前記（１）～（７）のいずれか一項に記載の中継装置。
（９）
　前記制御部は、前記中継装置にネットワーク層ＩＰアドレスを割り当てる、前記（１）～（８）のいずれか一項に記載の中継装置。
（１０）
　同一の中継装置に接続するひとつ以上の端末装置に割り当てられるプレフィクス部分の少なくとも一部が共通する第１のネットワーク層ＩＰアドレスを用いて前記中継装置との通信を行う処理部、
を備える端末装置。
（１１）
　前記処理部は、前記中継装置がハンドオーバを開始してから所定期間、他のネットワークへのアタッチ手続きを抑止する、前記（１０）に記載の端末装置。
（１２）
　前記端末装置は、前記中継装置へのアタッチ手続きが完了した時刻を記憶する記憶部をさらに備える、前記（１０）又は（１１）に記載の端末装置。
（１３）
　前記処理部は、前記中継装置へのアタッチ手続きが完了した時刻よりも後に開かれるソケットには前記第１のネットワーク層ＩＰアドレスを用い、前記中継装置へのアタッチ手続きが完了した時刻よりも前に開かれたソケットには、ハンドオーバ前に割り当てられた第２のネットワーク層ＩＰアドレスを継続的に用いる、前記（１２）に記載の端末装置。
（１４）
　前記処理部は、前記第２のネットワーク層ＩＰアドレスを用いたソケットが閉じられたことを示す情報を前記中継装置へ通知する、前記（１３）に記載の端末装置。
（１５）
　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継し、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる中継装置に、前記プレフィクス部分のうち共通する部分を通知する処理部、
を備える通信制御装置。
（１６）
　前記通信制御装置は、前記プレフィクス部分と前記中継装置とを関連付けて記憶する記憶部をさらに備える、前記（１５）に記載の通信制御装置。
（１７）
　前記処理部は、前記プレフィクス部分と前記中継装置とを関連付けるための情報を、前記中継装置と前記通信制御装置との通信を中継する装置へ通知する、前記（１５）又は（１６）に記載の通信制御装置。
（１８）
　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継することと、
　ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスをプロセッサにより割り当てる制御部と、
を含む方法。
（１９）
　同一の中継装置に接続するひとつ以上の端末装置に割り当てられるプレフィクス部分の少なくとも一部が共通する第１のネットワーク層ＩＰアドレスを用いて前記中継装置との通信をプロセッサにより行うこと、
を含む方法。
（２０）
　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継し、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる中継装置に、前記プレフィクス部分のうち共通する部分をプロセッサにより通知すること、
を含む方法。
　１　　ＵＥ
　２　　ＵＲＮ
　３　　ＤｅＮＢ
　４　　ｅＮＢ
　５　　Ｓ－ＧＷ
　６　　Ｐ－ＧＷ
　７　　ＭＭＥ
　８　　ＨＳＳ
　９　　ＰＣＲＦ
　１０　　ＰＤＮ
　１１０　　アンテナ部
　１２０　　無線通信部
　１３０　　記憶部
　１４０　　処理部
　１４１　　通信制御部
　２１０　　アンテナ部
　２２０　　無線通信部
　２３０　　記憶部
　２４０　　処理部
　２４１　　中継部
　２４３　　通信制御部
　６１０　　ネットワーク通信部
　６２０　　記憶部
　６３０　　処理部
　６３１　　通信制御部

Claims (20)

  1. 　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継する中継部と、
    　ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる制御部と、
    を備える中継装置。
  2. 　前記第２の装置とＰ－ＧＷ（Packet　Data　Network　Gateway）との間に設定される伝送路のうち前記中継装置とＰ－ＧＷとの間の区間に、前記中継装置とＰ－ＧＷとの間で設定される伝送路が流用される、請求項１に記載の中継装置。
  3. 　前記伝送路は、ベアラである、請求項２に記載の中継装置。
  4. 　前記伝送路は、ＩＰフローである、請求項２に記載の中継装置。
  5. 　前記制御部は、前記中継装置がハンドオーバを開始することを示す情報を前記第２の装置へ通知する、請求項１に記載の中継装置。
  6. 　前記制御部は、前記中継装置がハンドオーバを完了したことを示す情報を前記第２の装置へ通知する、請求項５に記載の中継装置。
  7. 　前記プレフィクス部分のうち共通しない部分により、前記中継装置又は他の中継装置により形成される仮想セルの各々が識別される、請求項１に記載の中継装置。
  8. 　前記プレフィクス部分は、ＩＰｖ６におけるサブネットプレフィクスである、請求項１に記載の中継装置。
  9. 　前記制御部は、前記中継装置にネットワーク層ＩＰアドレスを割り当てる、請求項１に記載の中継装置。
  10. 　同一の中継装置に接続するひとつ以上の端末装置に割り当てられるプレフィクス部分の少なくとも一部が共通する第１のネットワーク層ＩＰアドレスを用いて前記中継装置との通信を行う処理部、
    を備える端末装置。
  11. 　前記処理部は、前記中継装置がハンドオーバを開始してから所定期間、他のネットワークへのアタッチ手続きを抑止する、請求項１０に記載の端末装置。
  12. 　前記端末装置は、前記中継装置へのアタッチ手続きが完了した時刻を記憶する記憶部をさらに備える、請求項１０に記載の端末装置。
  13. 　前記処理部は、前記中継装置へのアタッチ手続きが完了した時刻よりも後に開かれるソケットには前記第１のネットワーク層ＩＰアドレスを用い、前記中継装置へのアタッチ手続きが完了した時刻よりも前に開かれたソケットには、ハンドオーバ前に割り当てられた第２のネットワーク層ＩＰアドレスを継続的に用いる、請求項１２に記載の端末装置。
  14. 　前記処理部は、前記第２のネットワーク層ＩＰアドレスを用いたソケットが閉じられたことを示す情報を前記中継装置へ通知する、請求項１３に記載の端末装置。
  15. 　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継し、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる中継装置に、前記プレフィクス部分のうち共通する部分を通知する処理部、
    を備える通信制御装置。
  16. 　前記通信制御装置は、前記プレフィクス部分と前記中継装置とを関連付けて記憶する記憶部をさらに備える、請求項１５に記載の通信制御装置。
  17. 　前記処理部は、前記プレフィクス部分と前記中継装置とを関連付けるための情報を、前記中継装置と前記通信制御装置との通信を中継する装置へ通知する、請求項１５に記載の通信制御装置。
  18. 　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継することと、
    　ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスをプロセッサにより割り当てる制御部と、
    を含む方法。
  19. 　同一の中継装置に接続するひとつ以上の端末装置に割り当てられるプレフィクス部分の少なくとも一部が共通する第１のネットワーク層ＩＰアドレスを用いて前記中継装置との通信をプロセッサにより行うこと、
    を含む方法。
  20. 　接続先の第１の装置と配下のひとつ以上の第２の装置との間で無線信号を中継し、ひとつ以上の前記第２の装置の各々にプレフィクス部分の少なくとも一部が共通するネットワーク層ＩＰアドレスを割り当てる中継装置に、前記プレフィクス部分のうち共通する部分をプロセッサにより通知すること、
    を含む方法。
PCT/JP2016/081953 2016-01-29 2016-10-27 中継装置、端末装置、通信制御装置及び方法 WO2017130495A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA3010773A CA3010773A1 (en) 2016-01-29 2016-10-27 Relay device, terminal device, communication control device, and method
EP16888080.5A EP3410755B1 (en) 2016-01-29 2016-10-27 Relay device, terminal device, and communication control device and method
US16/071,752 US10694396B2 (en) 2016-01-29 2016-10-27 Relay device, terminal device, communication control device, and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-016599 2016-01-29
JP2016016599 2016-01-29

Publications (1)

Publication Number Publication Date
WO2017130495A1 true WO2017130495A1 (ja) 2017-08-03

Family

ID=59398952

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/081953 WO2017130495A1 (ja) 2016-01-29 2016-10-27 中継装置、端末装置、通信制御装置及び方法

Country Status (5)

Country Link
US (1) US10694396B2 (ja)
EP (1) EP3410755B1 (ja)
CA (1) CA3010773A1 (ja)
TW (1) TWI715707B (ja)
WO (1) WO2017130495A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021261582A1 (ja) * 2020-06-26 2021-12-30 Kddi株式会社 中継装置のハンドオーバ処理を実行するための、中継装置、通信装置、制御方法、および、プログラム
WO2021261583A1 (ja) * 2020-06-26 2021-12-30 Kddi株式会社 中継装置のハンドオーバ処理を実行するための、基地局装置、中継装置、制御方法、および、プログラム
US20240106794A1 (en) * 2022-09-06 2024-03-28 Kt Corporation Method and apparatus for enabling bidirectional communication for second devices

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106304036B (zh) * 2015-05-19 2019-11-19 华为技术有限公司 一种提供中继业务的方法和装置
WO2019240646A1 (en) * 2018-06-13 2019-12-19 Telefonaktiebolaget Lm Ericsson (Publ) Internet protocol (ip) address assignment in integrated access backhaul (iab) networks
CN111246453B (zh) * 2018-11-28 2021-06-15 华为技术有限公司 一种数据传输方法、用户面网元及控制面网元

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015522963A (ja) * 2012-05-03 2015-08-06 アイトロン インコーポレイテッド メッシュネットワークにおける効率的なデバイスハンドオーバ／移動

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101690322B (zh) * 2007-06-29 2013-04-10 诺基亚公司 避免乒乓切换
FI122751B (fi) * 2008-02-15 2012-06-29 Teliasonera Ab IP-etuliitteiden jakelu
US8228861B1 (en) * 2008-09-12 2012-07-24 Nix John A Efficient handover of media communications in heterogeneous IP networks using handover procedure rules and media handover relays
US8880705B2 (en) * 2008-10-15 2014-11-04 Qualcomm Incorporated Systems and methods for dynamic creation and release of proxy mobile IP connections
JP4976588B2 (ja) * 2009-03-27 2012-07-18 シャープ株式会社 移動端末装置、外部ゲートウェイ装置、移動体通信システムおよび通信方法
WO2012171585A1 (en) * 2011-06-17 2012-12-20 Nokia Siemens Networks Oy Gateway functionality for mobile relay system
EP3253083B1 (en) * 2012-01-18 2021-03-24 LG Electronics Inc. Control method and device based on multiple priorities in wireless communication system
US9155089B2 (en) * 2012-08-10 2015-10-06 Qualcomm Incorporated Cell ID and antenna port configurations for EPDCCH
TW201509144A (zh) * 2013-05-08 2015-03-01 Interdigital Patent Holdings 在長期進化(lte)系統中網路輔助干擾取消及/或抑制(naics)方法、系統及裝置
US20160330077A1 (en) * 2014-01-08 2016-11-10 Interdigital Patent Holding, Inc. WiFi VIRTUAL NETWORK SOLUTION
US20160036772A1 (en) * 2014-07-31 2016-02-04 Qualcomm Incorporated Technique to Prevent IPv6 Address Exhaustion in Prefix Delegation Mode for Mobile Access Point Routers
US20160150454A1 (en) * 2014-11-24 2016-05-26 Laird Technologies, Inc. Client managed soft handover and seamless link failover for wireless networks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015522963A (ja) * 2012-05-03 2015-08-06 アイトロン インコーポレイテッド メッシュネットワークにおける効率的なデバイスハンドオーバ／移動

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021261582A1 (ja) * 2020-06-26 2021-12-30 Kddi株式会社 中継装置のハンドオーバ処理を実行するための、中継装置、通信装置、制御方法、および、プログラム
WO2021261583A1 (ja) * 2020-06-26 2021-12-30 Kddi株式会社 中継装置のハンドオーバ処理を実行するための、基地局装置、中継装置、制御方法、および、プログラム
JP7511400B2 (ja) 2020-06-26 2024-07-05 Kddi株式会社 中継装置のハンドオーバ処理を実行するための、基地局装置、中継装置、制御方法、および、プログラム
JP7514122B2 (ja) 2020-06-26 2024-07-10 Kddi株式会社 中継装置のハンドオーバ処理を実行するための、中継装置、通信装置、制御方法、および、プログラム
JP7607172B2 (ja) 2020-06-26 2024-12-26 Kddi株式会社 中継装置のハンドオーバ処理を実行するための、中継装置、通信装置、制御方法、および、プログラム
US20240106794A1 (en) * 2022-09-06 2024-03-28 Kt Corporation Method and apparatus for enabling bidirectional communication for second devices
US12199947B2 (en) * 2022-09-06 2025-01-14 Kt Corporation Method and apparatus for enabling bidirectional communication for second devices

Also Published As

Publication number Publication date
US20190037414A1 (en) 2019-01-31
EP3410755A4 (en) 2018-12-05
TW201739307A (zh) 2017-11-01
CA3010773A1 (en) 2017-08-03
US10694396B2 (en) 2020-06-23
EP3410755A1 (en) 2018-12-05
EP3410755B1 (en) 2020-12-09
TWI715707B (zh) 2021-01-11

Similar Documents

Publication Publication Date Title
WO2017130495A1 (ja) 中継装置、端末装置、通信制御装置及び方法
US10750418B2 (en) SDN based connectionless architecture with dual connectivity and carrier aggregation
US9247490B2 (en) Statistics for optimizing distributed mobility anchoring for wireless networks
EP3499923B1 (en) Wireless-communication electronic device
EP2111708B1 (en) Method and apparatus for providing ip mobility and ip routing in ad hoc wireless networks
EP3220712B1 (en) Terminal device, base station device, mme, and communications control method
EP3547794B1 (en) Base station and terminal device
WO2016203798A1 (ja) 装置及び方法
CN110546989B (zh) 无线通信系统中的电子设备以及无线通信方法
WO2017168999A1 (ja) 無線通信装置、サーバ及び方法
JP2020010385A (ja) 端末装置及びＰｒｏＳｅサーバ装置
CN115699887B (zh) 一种通信方法及装置
JP6751717B2 (ja) 無線通信システム、ゲートウェイ装置、移動管理エンティティ及び通信制御方法
KR100465209B1 (ko) Ａｄ-ｈｏｃ 병용 다중 무선이동통신 시스템,무선이동단말장치, 및 이동통신 방법
WO2017169000A1 (ja) 中継装置、端末装置及び通信方法
JP6854764B2 (ja) 無線通信システム、無線基地局、移動管理エンティティ、ユーザ装置及び通信制御方法
WO2017104281A1 (ja) 装置、方法及びプログラム
EP3565375B1 (en) Wireless communication device, repeating device, wireless communication method, repeating method and information processing method
WO2024170503A2 (en) Pci collision detection in 5g mobile iab
CN119605109A (zh) 5g移动iab中的pci冲突避免
GB2627318A (en) PCI collision detection in 5G mobile IAB
GB2620777A (en) PCI collision avoidance in 5G mobile IAB
KR20250033280A (ko) 무선 통신 시스템에서의 네트워크 접속성 관리
WO2017094360A1 (ja) 装置、方法及びプログラム
CN115918243A (zh) 电子设备、无线通信方法和计算机可读存储介质

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: 16888080

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3010773

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016888080

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016888080

Country of ref document: EP

Effective date: 20180829

NENP Non-entry into the national phase

Ref country code: JP