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

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

Info

Publication number
WO2017169000A1
WO2017169000A1 PCT/JP2017/002222 JP2017002222W WO2017169000A1 WO 2017169000 A1 WO2017169000 A1 WO 2017169000A1 JP 2017002222 W JP2017002222 W JP 2017002222W WO 2017169000 A1 WO2017169000 A1 WO 2017169000A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
packet
information
node
downstream
Prior art date
Application number
PCT/JP2017/002222
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 MX2018011417A priority Critical patent/MX2018011417A/es
Priority to RU2018133238A priority patent/RU2018133238A/ru
Priority to SG11201808121XA priority patent/SG11201808121XA/en
Priority to EP17773550.3A priority patent/EP3439424A4/en
Publication of WO2017169000A1 publication Critical patent/WO2017169000A1/ja
Priority to ZA2018/05140A priority patent/ZA201805140B/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/155—Ground-based stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • 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, and a communication 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 etc. is still short after being proposed and is not sufficient as a technology for utilizing relay nodes. For example, improving the efficiency of information processing related to relay nodes is one of the technologies that are not sufficient.
  • the storage unit that stores the first conversion table of the address information and the transmission destination information or the transmission source information of the packets that are transmitted and received between the upstream node that is the connection destination and the downstream node that is under control thereof are And a control unit that converts and relays based on the first conversion table stored in the unit.
  • the first conversion table is registered in an upstream node that converts the transmission destination information or transmission source information of the relayed packet based on the first conversion table of the stored address information.
  • a terminal device including a control unit that transmits a message to be requested.
  • a communication method including: converting and relaying by a processor based on the stored first conversion table.
  • the first conversion table is registered in an upstream node that converts the transmission destination information or transmission source information of the relayed packet based on the first conversion table of the stored address information.
  • a communication method is provided that includes sending a requesting message by a processor.
  • FIG. 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 block diagram which shows an example of a structure of UE which concerns on the embodiment. It is a block diagram which shows an example of a structure of RN which concerns on the same embodiment. It is a block diagram which shows an example of a structure of DeNB which concerns on the embodiment. It is a block diagram which shows an example of a structure of the core network node which concerns on the embodiment. It is a sequence diagram which shows an example of the flow of the connection process performed in the system which concerns on the same embodiment. It is a sequence diagram which shows an example of the flow of the connection process performed in the system which concerns on the same embodiment.
  • nodes having substantially the same functional configuration may be distinguished by attaching different reference numerals.
  • a plurality of nodes having substantially the same functional configuration are distinguished as UE1, UE2, and UE3 as necessary.
  • the reference numerals are omitted.
  • UE when it is not necessary to distinguish UE1, UE2, and UE3, they are simply referred to as UE.
  • the same applies to other nodes constituting the cellular network such as P-GW, S-GW, MME, DeNB, and RN.
  • Mobility support protocols can be classified from two viewpoints.
  • the first point of view is whether the protocol is for realizing the movement of a single node (Node Mobility) or the movement of a set of nodes (network) (Network Mobility: NEMO).
  • 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) Is a viewpoint of whether the protocol is a network-based localized mobility protocol regardless of signaling for mobility management and only in a limited mobility range.
  • 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. 1 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 this embodiment includes a P-GW (PDN (Packet Data Network) -Gateway), an S-GW (Serving Gateway), an MME (Mobility Management Entity), a DeNB (Donor evolved Node B). ), RN (Relay-Node) and UE (User Equipment).
  • P-GW Packet Data Network
  • S-GW Serving Gateway
  • MME Mobility Management Entity
  • DeNB Donor evolved Node B
  • RN Relay-Node
  • UE User Equipment
  • the UE is a terminal device.
  • the RN is a relay device that relays communication between an upstream node such as DeNB and a downstream node such as UE.
  • the RN may operate as a UE.
  • DeNB is a base station to which RN is connected.
  • the S-GW is a gateway that transmits user data.
  • the P-GW is a gateway that serves as a contact point between the core network and an external PDN, and is a communication control device that assigns IP addresses and the like.
  • the MME performs UE mobility management, authentication, and user data transfer path setting.
  • the system according to the present embodiment may include nodes such as eNB, HSS (Home Subscriber Server), and PCRF (policy and charging rules function).
  • An eNB is a base station to which a UE is connected.
  • the HSS is an entity that manages user information.
  • the PCRF is an entity that determines policy control and charging control rules such as QoS.
  • the solid line connecting each node means wired connection, and the broken line means wireless connection.
  • the P-GW is connected to the IPv6 global Internet (ie, PDN). Further, the P-GW and the S-GW are connected by an S5 / S8 interface.
  • the S-GW and the MME are connected by an S11 interface.
  • the S-GW and DeNB are connected by the S1-U interface.
  • the MME and DeNB are connected by an S1-MME interface.
  • the DeNBs are connected by an X2 interface. Further, the DeNB and the RN are connected by an S1-U interface. Further, the RN and the UE are connected by an E-UTRAN-Uu interface. Further, the RNs are connected by an S1-U interface.
  • a cell formed by RN may also be referred to as a moving cell or a virtual cell.
  • the moving cell is indicated by a broken-line rectangle.
  • a structure in which another moving cell is included in the moving cell such as a moving cell formed by RN2 and a moving cell formed by RN3, is also referred to as a nested structure.
  • a mobile cell on the side of inclusion in the nested structure for example, a mobile cell formed by RN2 or RN3 is also referred to as a nested mobile cell.
  • the direction closer to the PDN is also referred to as upstream, and the direction closer to the UE is also referred to as downstream.
  • RN1 is an upstream node
  • UE3 and UE4 are downstream nodes.
  • the proposed protocol can operate with a cellular phone network as a domain (network range), for example.
  • the domain may have other network configurations.
  • IPv6 address notation used in the system according to the present embodiment will be described.
  • IP D PGW The IPv6 address of the interface downstream of the P-GW is represented as IP D PGW . This IPv6 address is assigned in advance and is unchanged.
  • IPv6 addresses of the upstream and downstream interfaces of the S-GW are represented as IP U SGW and IP D SGW , respectively. This IPv6 address is assigned in advance and is unchanged.
  • IP U DeNB and IP D DeNB The IPv6 addresses of the upstream and downstream interfaces of the DeNB are represented as IP U DeNB and IP D DeNB , respectively. These IPv6 addresses are assigned in advance and are unchanged. Further, the upper 64 bits (prefix) of the IP D DeNB are represented as Pref D DeNB .
  • IP U RN When the RN operates as an eNB, an IPv6 address for connecting to an upstream DeNB via the S1-U interface is represented as IP U RN .
  • the upper 64 bits (prefix) of IP U RN are equal to Pref D DeNB .
  • the lower 64 bits of the IP U RN the (interface ID), expressed as ifid U RN. Ifid U RN is pre-assigned and is unchanged.
  • IP UE RN An IPv6 address used by an application on the RN when the RN operates as a UE is denoted as IP UE RN .
  • the upper 64 bits (prefix) of the IP UE RN are denoted as Pref UE RN, and the lower 64 bits (interface ID) are denoted as if UE RN .
  • the Pref UE RN and ifid UE RN are assigned when the RN is turned on and first connected to the LTE network, and do not change until the power is turned off.
  • the IPv6 prefix (/ 64) assigned to the downstream moving cell is represented as Pref D RN .
  • Pref D RN is assigned when the RN is turned on and is first connected to the LTE network, and does not change until the power is turned off.
  • IP D RN an IPv6 address used when communicating with a device in a downstream moving cell is represented as IP D RN .
  • the upper 64 bits (prefix) of IP D RN are equal to Pref D RN .
  • the lower 64 bits of the IP D RN represents a ifid D RN. Ifid D RN is assigned in advance and is unchanged.
  • IP UE The IP address of the UE is represented as IP UE .
  • the upper 64 bits (prefix) of the IP UE are expressed as Pref UE, and the lower 64 bits (interface ID) are expressed as if UE .
  • FIG. 2 is a block diagram illustrating an exemplary configuration of a UE according to an embodiment of the present disclosure.
  • the UE includes an antenna unit 110, a radio communication unit 120, a storage unit 130, and a control 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 the eNB or RN, and transmits an uplink signal to the eNB or RN.
  • Storage unit 130 The storage unit 130 temporarily or permanently stores a program for operating the UE and various data.
  • Control unit 140 provides various functions of the UE.
  • the UE operates based on control by the control unit 140.
  • the operation of the UE based on the control by the control unit 140 will be described in detail later.
  • FIG. 3 is a block diagram illustrating an example of a configuration of an RN according to an embodiment of the present disclosure.
  • the RN includes an antenna unit 210, a wireless communication unit 220, a storage unit 230, and a control 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 an upstream DeNB or another RN and relays it to a downstream UE or RN.
  • the radio communication unit 220 receives an uplink signal from a downstream UE or RN and relays it to an upstream DeNB or another RN.
  • Storage unit 230 The storage unit 230 temporarily or permanently stores a program for operating the RN and various data.
  • Control unit 240 provides various functions of the RN.
  • the RN operates based on control by the control unit 240.
  • the operation of the RN based on the control by the control unit 240 will be described in detail later.
  • FIG. 4 is a block diagram illustrating an exemplary configuration of the DeNB according to an embodiment of the present disclosure.
  • the DeNB includes an antenna unit 310, a radio communication unit 320, a network communication unit 330, a storage unit 340, and a control unit 350.
  • Antenna unit 310 The antenna unit 310 radiates a signal output from the wireless communication unit 320 as a radio wave to space. Further, the antenna unit 310 converts radio waves in space into a signal and outputs the signal to the wireless communication unit 320.
  • the wireless communication unit 320 transmits and receives signals.
  • the radio communication unit 320 transmits a downlink signal to a downstream UE or RN, and receives an uplink signal from the downstream UE or RN.
  • the network communication unit 330 transmits and receives information.
  • the network communication unit 330 transmits information to other nodes and receives information from other nodes.
  • the other nodes include other DeNBs and core network nodes.
  • Storage unit 340 The storage unit 340 temporarily or permanently stores programs and various data for DeNB operation.
  • Control unit 350 provides various functions of the DeNB.
  • the DeNB operates based on control by the control unit 350.
  • the operation of the DeNB based on the control by the control unit 350 will be described in detail later.
  • FIG. 5 is a block diagram illustrating an exemplary configuration of a core network node according to an embodiment of the present disclosure.
  • the core network node includes a network communication unit 410, a storage unit 420, and a control unit 430.
  • the network communication unit 410 transmits and receives information.
  • the network communication unit 410 transmits information to other nodes and receives information from other nodes.
  • the other nodes include other core network nodes, PDNs, and DeNBs.
  • Storage unit 420 The storage unit 420 temporarily or permanently stores a program for operating the core network node and various data.
  • Control unit 430 provides various functions of the core network node.
  • the core network node operates based on control by the control unit 430.
  • the operation of the core network node based on the control by the control unit 430 will be described in detail later.
  • connection process refers to a process in which the UE or RN connects with the DeNB or RN.
  • Each node (for example, DeNB, S-GW, and P-GW) from the base station to the P-GW stores a route table in which transmission destination information is associated with a transfer destination.
  • the routing table includes an entry in which an end point IP address (that is, a destination IP address) is associated with a transfer destination GTP tunnel.
  • Each node relays the received packet using an appropriate GTP tunnel based on the routing table.
  • each node can store is shown below.
  • the MME stores a management table in which identification information of a node (UE or RN) attached to a network, address information, and address information of an upstream node (that is, a connection destination node) of the node are associated with each other.
  • the MME can grasp all RNs and UEs connected to the moving cell using the management table.
  • Conversion table RN stores a conversion table of address information (first conversion table).
  • This conversion table includes information in which address information of a downstream node is associated with address information of an RN corresponding to the downstream node.
  • the address information is information including an IP address and / or a port number.
  • the IP address here is, for example, an IPv6 address.
  • the P-GW also stores an address information conversion table (second conversion table).
  • This conversion table includes information in which the address information of the most downstream node (that is, the UE or the RN operating as the UE) is associated with the address information of the RN corresponding to the most downstream node. By using this conversion table, the P-GW can aggregate packets addressed to the downstream node of the RN into the RN.
  • UE sends a message requesting registration of conversion table in RN which is upstream node of connection destination.
  • the RN also sends a message requesting registration of the conversion table to the P-GW or the RN when the RN exists upstream.
  • This message is also referred to as a NAT registration request (NAT (Network Address Translation) Registration Request) below.
  • NAT registration request Network Address Translation
  • the RN and P-GW can appropriately update the conversion table based on this message.
  • a NAT registration response (NAT Registration Ack) is returned.
  • each RN can store is shown below.
  • the RN receives the assignment of the prefix part of the IP address from the P-GW. This is the same whether the RN is connected to the DeNB or the moving cell.
  • the RN may execute DHCP-PD (Prefix delegation) with the P-GW. Thereby, the RN can receive a prefix assignment.
  • 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 RN can assign a prefix (eg, IPv6 Prefix / 64) that is a part of the assigned prefix (eg, IPv6 Prefix / 56) to a subordinate node.
  • a prefix eg, IPv6 Prefix / 64
  • IPv6 Prefix / 56 a part of the assigned prefix
  • the RN transmits information indicating the positioning of the mobile cell formed by the RN.
  • the RN controls the transmission timing of the attach request regarding the downstream node that has been attached. For example, the RN collectively transmits an attach request regarding one or more downstream nodes that have been attached to the upstream node.
  • the transmission timing control method is arbitrary. For example, it is conceivable to periodically transmit at predetermined time intervals or to transmit after waiting for a predetermined time from when an attach request from a downstream node is received. Accordingly, the RN can transmit an attach request for a plurality of nodes at a time instead of transmitting an attach request every time a node is connected downstream of the RN. Thereby, the communication load of the network is reduced.
  • connection process to DeNB by RN that has not acquired IPv6 address In this section, connection process to DeNB by RN that has not acquired IPv6 address will be described. As an example, a case is assumed where the power supply of RN1 is turned on in the vicinity of DeNB1. An example of connection processing to DeNB1 by RN1 that has not acquired an IPv6 address in this case will be described with reference to FIG.
  • FIG. 6 is a sequence diagram showing an example of the flow of connection processing executed in the system according to the present embodiment.
  • RN1, DeNB1, MME1, S-GW1, and P-GW1 are involved.
  • RN1 forms a moving cell.
  • RN1 establishes a radio channel with DeNB1 (step S102).
  • the RN 1 transmits an RS (Router Solicitation) to all router multicast addresses in the link local (step S104).
  • DeNB1 receives this RS, and transmits RA (Router Advertisement) to the link local IPv6 address of RN1 (step S106).
  • This RA includes Pref D DeNB1 , which is a prefix of the IPv6 address assigned to the downstream interface of DeNB1 .
  • RN1 receives this RA and generates IP U RN1 that is an IPv6 address from Pref D DeNB1 and ifid U RN1 that is the ID of its upstream interface (step S108).
  • the IP U RN1 is used when the RN1 establishes a GTP (General Packet Radio Service) Tunneling Protocol (GPRS) tunnel with the DeNB1.
  • GTP General Packet Radio Service
  • GPRS General Packet Radio Service Tunneling Protocol
  • RN1 transmits an attach request (Attach Request) to DeNB1 (step S110).
  • DeNB1 when receiving this attach request, DeNB1 adds IP D DeNB1 , which is the IPv6 address of its downstream interface, to the received attach request and transfers it to MME1 (step S112).
  • the MME 1 transmits a default bearer request (Create Default Bearer Request) to the S-GW 1 (step S114).
  • the S-GW 1 transfers it to the P-GW 1 (step S116).
  • P-GW 1 allocates Pref UE RN1 and ifid UE RN1 (step S118). Specifically, the P-GW 1 assigns Pref UE RN1 that is an IPv6 prefix of / 64 from its own IPv6 address space. Also, the P-GW1 generates an if UE RN1 that is an interface ID when the RN1 operates as a UE . Also, P-GW1 forms a GTP tunnel with S-GW1, associates the forwarding destination of Pref UE RN1 with this GTP tunnel, and registers it in the routing table (corresponding to the entry in the first row of Table 2A). . The end points of this GTP tunnel are IP D PGW1 , which is the IPv6 address of the downstream interface of P-GW1, and IP U SGW1 , which is the IPv6 address of the upstream interface of S-GW1.
  • the P-GW 1 transmits a default bearer generation response (Create Default Bearer Response) to the S-GW 1 (step S120).
  • This default bearer generation response includes ID RN1 , IP D PGW1 , Pref UE RN1 , if UE RN1 , and IP D DeNB1 .
  • the S-GW1 receives this default bearer generation response, the IP D SGW1 is added to the received default bearer generation response and forwarded to the MME1 (step S122). Further, the S-GW 1 forms a GTP tunnel with the P-GW 1. The end points of this GTP tunnel are IP U SGW1 and IP D PGW1 . Further, the S-GW1 configures a GTP tunnel with the DeNB1, associates the transfer destination of the Pref UE RN1 with this GTP tunnel, and registers it in the routing table (corresponding to the entry in the first row of Table 2B). The end points of this GTP tunnel are IP D SGW1 which is the IPv6 address of the downstream interface of S-GW1, and IP U DeNB1 which is the IPv6 address of the upstream interface of DeNB1 .
  • MME1 when receiving this default bearer generation response, MME1 registers RN1 in its own management table (corresponding to the entry in the first row of Table 3). Next, the MME 1 transmits an attach accept to the DeNB 1 (step S124).
  • This attach accept includes ID RN1 , IP D SGW1 , Pref UE RN1 , and ifid UE RN1 .
  • the DeNB1 When the DeNB1 receives this attach accept, it transfers it to the RN1 (step S126).
  • the DeNB 1 configures a GTP tunnel with the S-GW 1.
  • the end points of this GTP tunnel are IP U DeNB1 which is the IPv6 address of the upstream interface of DeNB1 , and IP D SGW1 which is the IPv6 address of the downstream interface of S-GW1.
  • DeNB1 configures a GTP tunnel with RN1 , associates the transfer destination of Pref UE RN1 with this GTP tunnel, and registers it in the routing table (corresponding to the entry in the first row of Table 2C).
  • IP D DeNB1 which is the IPv6 address of the downstream interface of DeNB1
  • IP U RN1 which is the IPv6 address of the upstream interface of RN1 .
  • RN1 receives this attach accept and obtains if UE RN1 .
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • the RN1 transmits an RS (Router Solicitation) to the P-GW1 in accordance with the IPv6 regulations in order to obtain the IP UE RN1 that is an IPv6 address for operating as a UE (step S128).
  • RS Raster Solicitation
  • the P-GW1 receives this RS and returns an RA (Router Advertisement) to the RN1 (step S130).
  • This RA includes Pref UE RN1 .
  • RN1 receives this RA and obtains Pref UE RN1 . And RN1 produces
  • IP UE RN1 is an IPv6 address used when an application on RN1 communicates.
  • the RN1 executes DHCP-PD with the P-GW1 in order to obtain the prefix of the downstream interface (step S134).
  • the P-GW1 assigns the prefix Pref D RN1 to the RN1.
  • RN1 acquires Pref D RN1 . Then, the RN 1 generates an IPv6 address IP D RN1 from the Pref D RN1 and the ifid D RN1 that is the interface ID of the downstream interface, and assigns it to the downstream interface (step S136).
  • P-GW1 associates the route of Pref D RN1 with the tunnel to S-GW1 and registers it in the route table (corresponding to the entry in the second row of Table 2A).
  • the P-GW 1 transmits a route setup to the S-GW 1 (step S138).
  • This route setup includes Pref UE RN1 and Pref D RN1 .
  • S-GW1 associates the route of Pref D RN1 with the tunnel to DeNB1 and registers it in the route table (corresponding to the entry in the second row of Table 2B).
  • S-GW1 transfers the route setup to DeNB1 (step S140).
  • DeNB1 associates the route of Pref D RN1 with the tunnel to RN1 and registers it in the route table (corresponding to the entry in the second row of Table 2C).
  • P-GW1, S-GW1, and DeNB1 store the route tables shown in Tables 2A, 2B, and 2C, respectively.
  • the MME 1 stores the management table shown in Table 3. The MME grasps all RNs connected in the moving cell by the management table.
  • connection process to RN by UE not acquiring IPv6 address will be described. For example, it is assumed that UE1 is powered on in the vicinity of RN1 after the processing described in section (1.1) above. An example of connection processing to RN1 by UE1 that has not acquired an IPv6 address in this case will be described with reference to FIG.
  • FIG. 7 is a sequence diagram showing an example of the flow of connection processing executed in the system according to the present embodiment.
  • UE1, RN1, DeNB1, and MME1 are involved.
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • UE1 establishes a radio channel with RN1 (step S202).
  • UE1 transmits an attach request to RN1 (step S204).
  • This attach request includes ID UE1 , which is an identifier of UE1 .
  • RN1 generates ifid UE1 that is an interface ID of UE1 from ID UE1 using, for example, a hash function.
  • RN1 transmits an attach accept to UE1 (step S206).
  • This attach accept includes ifid UE1 .
  • UE1 receives the attach accept, acquires ifid UE1.
  • UE1 transmits RS to RN1 (step S208).
  • RN1 transmits an RA including Pref D RN1 to UE1 (step S210).
  • UE1 receives the RA, and generates IP UE1 that is its IPv6 address from Pref D RN1 and ifid UE1 (step S212).
  • RN1 waits for a certain amount of time (for example, 1 second), and during that time, attach requests regarding UEs connected downstream of RN1 are collectively transmitted to DeNB1 (step S214). Thereby, RN1 can transmit an attach request regarding a plurality of UEs at a time, instead of transmitting an attach request every time a UE connects downstream of RN1.
  • DeNB1 transfers the request to MME1 (step S216).
  • the MME1 when the MME1 receives this attach request, it registers the information of the UE (for example, UE1) connected downstream of the RN1 in the mapping table (corresponding to the entry in the second row of Table 3), and attaches to the DeNB1. Transmit (step S218).
  • This attach accept contains the identifier of the UE connected to RN1 (eg ID UE1 ).
  • step S220 when the DeNB1 receives this attach accept, it transfers it to the RN1 (step S220).
  • connection process to RN by UE having acquired IPv6 address will be described.
  • UE2 connected to another eNB moves to a moving cell provided by RN1.
  • UE2 having an IPv6 address of IP UE2 is assumed to be connected to RN1.
  • IP UE2 does not belong to Pref D RN1 .
  • An example of connection processing to the RN 1 by the UE 2 having acquired the IPv6 address in this case will be described with reference to FIG.
  • FIG. 8 is a sequence diagram showing an example of the flow of connection processing executed in the system according to the present embodiment.
  • UE2, RN1, DeNB1, MME1, S-GW1, and P-GW1 are involved.
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • UE2 establishes a radio channel with RN1 (step S302).
  • UE2 transmits an attach request to RN1 (step S304).
  • This attach request includes ID UE2 and IP UE2 which are identifiers of UE2 .
  • RN1 detects that UE2 has moved downstream from RN1 from another eNB or RN with the IPv6 address because IP UE2 does not belong to Pref D RN1 . Therefore, RN1 from Pref UE2 and ifid D RN1 a prefix of IP UE2, generates the IPv6 address IP2 D RN1, assigned to the downstream interface.
  • RN1 transmits an attach accept to UE2 (step S306).
  • This attach accept includes if UE2 which is the interface ID of IP UE2 .
  • UE2 receives this attach accept and obtains ifid UE2 .
  • UE2 transmits RS to RN1 (step S308).
  • RN1 transmits RA to UE2 (step S310).
  • UE2 that has received the RA generates IP UE2 from Pref UE2 and ifid UE2, confirms that IP UE2 can be used continuously (step S312).
  • UE2 transmits a NAT registration request to RN1 (step S314).
  • This NAT registration request includes a list of IP UEs 2 and port numbers currently used for communication (here, for the sake of simplicity, it is assumed that there is one port in communication and is represented as Pt1 UE2 ).
  • RN1 when receiving this NAT registration request, assigns a new port number Pt1 RN1 UE2 respect Pt1 UE2, adding a new entry (1 row entry in Table 5) into its address conversion table .
  • RN1 transmits a NAT registration request to P-GW1 (step S316).
  • This NAT registration request includes IP UE2 , Pt1 UE2 , IP UE RN1 , and Pt1 RN1 UE2 .
  • the P-GW 1 when the P-GW 1 receives this NAT registration request, it adds a new entry (entry on the first line in Table 4) to its address translation table. Next, the P-GW1 transmits a NAT registration response to the RN1 (step S318).
  • step S320 when the RN1 receives this NAT registration response, it forwards it to the UE2 (step S320).
  • RN1 waits for a certain amount of time (for example, 1 second) after transmission of RA, and during that time, attach requests regarding UEs connected downstream of RN1 are collectively transmitted to DeNB1 (step S322). Thereby, RN1 can transmit an attach request regarding a plurality of UEs at a time, instead of transmitting an attach request every time a UE connects downstream of RN1.
  • DeNB1 transmits a path switch request to MME1 (step S324).
  • MME1 since the UE (for example, UE2) connected to RN1 already has an IPv6 address, MME1 already stores an entry related to this UE in its management table. Therefore, when MME1 receives this path switch request, it updates the upstream node column of the entry of UE connected downstream of RN1 (for example, the entry of UE2 (the third row entry in Table 3)) in the management table of MME1. To do. Next, the MME 1 transmits a modify bearer request to the S-GW 1 (step S326). This bearer change request includes the ID and IPv6 address (for example, ID UE2 and IP UE2 ) of the UE connected downstream of RN1.
  • This bearer change request includes the ID and IPv6 address (for example, ID UE2 and IP UE2 ) of the UE connected downstream of RN1.
  • the S-GW 1 transfers the request to the P-GW 1 (step S328).
  • P-GW1 releases the GTP tunnel established in the UE (for example, UE2) connected downstream of RN1.
  • the P-GW 1 transmits a modify bearer response to the S-GW 1 (step S330).
  • This bearer change response includes the identifier (for example, ID UE2 ) of the UE connected downstream of RN1.
  • the S-GW 1 transfers it to the MME 1 (step S332).
  • This path switch request response includes the identifier (for example, ID UE2 ) of the UE connected downstream of RN1.
  • DeNB1 transmits an attach accept to RN1 (step S336).
  • This attach accept includes an identifier (for example, ID UE2 ) of the UE connected downstream of RN1.
  • the information amount of the routing table stored in the P-GW, S-GW, and DeNB does not depend on the number of UEs in the moving cell.
  • the same number of address translation table entries as the number of ports in communication with this UE are added to the upstream RN and P-GW.
  • the address conversion tables stored in P-GW1 and RN1 are as shown in Table 4 and Table 5, respectively.
  • MME1 grasps
  • connection process to moving cell by RN not acquiring IPv6 address will be described.
  • the power of RN2 is turned on in the vicinity of RN1 after the processing described in the above section (1.3).
  • An example of connection processing to the moving cell provided by RN1 by RN2 that has not acquired an IPv6 address in this case will be described with reference to FIG.
  • FIG. 9 is a sequence diagram showing an example of the flow of connection processing executed in the system according to the present embodiment.
  • RN2, RN1, DeNB1, MME1, and P-GW1 are involved in this sequence.
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • RN2 establishes a radio channel with RN1 (step S402).
  • the RN 2 transmits the RS to all the link-local router multicast addresses (step S404).
  • RN1 transmits RA to the link local address of RN2 (step S406).
  • RN2 upon receiving this RA, RN2 generates IP U RN2 that is an IPv6 address from Pref D RN1 and ifid U RN2 that is the ID of its upstream interface (step S408).
  • IP U RN2 is equal to IP UE RN2 , which is an IPv6 address used by an application on RN2 .
  • RN2 transmits an attach request to RN1 (step S410).
  • RN1 when receiving this attach request, RN1 adds IP D RN1 and transfers it to DeNB1 (step S412).
  • DeNB1 transfers the request to MME1 (step S414).
  • the MME 1 when receiving this attach request, registers the information of the RN 2 in the management table (corresponding to the entry on the fourth line in Table 3). Then, the MME 1 transmits an attach accept to the DeNB 1 (step S416).
  • This attach accept includes ID RN2 .
  • DeNB1 when DeNB1 receives this attach accept, it transfers it to RN1 (step S418).
  • RN1 transfers it to RN2 (step S420).
  • This attach accept contains if U RN2 .
  • RN2 receives the attach accept and obtains if U RN2 .
  • RN2 transmits RS to RN1 (step S422).
  • RN1 transmits RA to RN2 (step S424).
  • This RA includes Pref D RN1 and IP D PGW1 .
  • IP UE RN2 is an IPv6 address used by an application when RN2 operates as a UE. As a result, IP U RN2 and IP UE RN2 are equal.
  • the RN2 executes DHCP-PD with the P-GW1 in order to acquire the prefix of the downstream interface (step S428).
  • P-GW1 assigns Pref D RN2 as a prefix of the downstream interface of RN2 . Since P-GW1 knows that RN2 is nested, P-GW1 does not change the route information.
  • RN2 acquires Pref D RN2 . Then, RN2 from ifid D RN2 an ID Pref D RN2 and downstream interfaces, generates IP D RN2, allocates downstream interface (step S430).
  • the MME grasps all the RNs connected in the moving cell from the management table.
  • connection process to a nested mobile cell by a UE that has not obtained an IPv6 address will be described.
  • a case is assumed in which the UE 3 is turned on in the vicinity of the RN 2 after the processing described in the above section (1.4).
  • An example of the connection process to the nested mobile cell provided by the RN 2 by the UE 3 that has not acquired the IPv6 address in this case will be described with reference to FIG.
  • FIG. 10 is a sequence diagram showing an example of the flow of connection processing executed in the system according to the present embodiment.
  • UE3, RN2, RN1, DeNB1, and MME1 are involved.
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • UE3 establishes a radio channel with RN2 (step S502).
  • UE3 transmits an attach request to RN2 (step S504).
  • This attach request includes ID UE3 that is an identifier of UE3 .
  • RN2 for example using a hash function to generate a ifid UE3 from ID UE3, transmits an attach accept comprising this UE3 (step S506).
  • UE3 receives this attach accept, acquires ifid UE3.
  • UE3 transmits RS to RN2 (step S508).
  • RN2 transmits RA including Pref D RN2 to UE3 (step S510).
  • UE3 receives this RA, and generates IP UE3 that is an IPv6 address from Pref D RN2 and ifid UE3 (step S512).
  • RN2 waits for a certain amount of time (for example, 1 second), and during that time, attach requests regarding UEs connected downstream of RN2 are collectively transmitted to RN1 (step S514). Accordingly, the RN2 can transmit an attach request for a plurality of UEs at a time, instead of transmitting an attach request every time a UE is connected downstream of the RN2.
  • RN1 transfers the request to DeNB1 (step S516).
  • DeNB1 transfers the request to MME1 (step S518).
  • MME1 registers the information of the UE (for example, UE3) connected downstream of RN2 in the management table (corresponding to the entry in the fifth row in Table 3), and transmits an attach accept to DeNB1.
  • This attach accept includes the identifier (for example, ID UE3 ) of the UE connected to RN2.
  • DeNB1 when DeNB1 receives this attach accept, it transfers it to RN1 (step S522).
  • RN1 forwards it to RN2 (step S524).
  • the MME grasps all UEs connected in the moving cell by the management table.
  • connection process to a nested mobile cell by a UE that has obtained an IPv6 address will be described.
  • UE 4 that has obtained an IPv6 address of IP UE 4 under the control of another eNB or RN has moved to a nested moving cell provided by RN 2.
  • An example of the connection process to the nested mobile cell provided by the RN 2 by the UE 4 having acquired the IPv6 address in this case will be described with reference to FIG.
  • FIG. 11 is a sequence diagram showing an example of the flow of connection processing executed in the system according to the present embodiment.
  • UE4, RN2, RN1, DeNB1, MME1, S-GW1, and P-GW1 are involved.
  • GTP tunnels are respectively configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1.
  • the UE 4 establishes a radio channel with the RN 2 (step S602).
  • UE4 transmits an attach request to RN2 (step S604).
  • This attach request includes ID UE4 and IP UE4 which are identifiers of UE4 .
  • RN2 detects that UE4 has moved downstream from RN2 from another eNB or RN with the IPv6 address because IP UE4 does not belong to Pref D RN2 . Therefore, RN2 from ifid D RN2 an ID Pref UE4 and its downstream interfaces is a prefix of IP UE4, generates the IPv6 address IP2 D RN2, assigned to the downstream interface.
  • RN2 transmits an attach accept to UE2 (step S606).
  • UE4 receives this attach accept, acquires ifid UE4.
  • UE4 transmits RS to RN2 (step S608).
  • RN2 transmits RA including Pref UE4 to UE4 (step S610).
  • the UE 4 when the UE 4 receives the RA, the UE 4 generates an IP UE 4 from the Pref UE 4 and the if UE 4 and confirms that the IP UE 4 is still usable (step S612).
  • This NAT registration request includes a list of IP UE 4 and the port number currently in communication (here, for simplicity of explanation, only one Pt 1 UE 4 is in communication).
  • RN2 upon receiving the NAT registration request, allocates a new port number Pt1 RN2 UE4 respect Pt1 UE4, a new entry in its own address conversion table (first row entry in Table 6) Add.
  • RN2 transmits a NAT registration request to RN1 (step S616).
  • This NAT registration request includes IP UE4 , Pt1 UE4 , IP UE RN2 , and Pt1 RN2 UE4 .
  • RN1 when receiving this NAT registration request, RN1 assigns a new port number Pt1 RN1 UE4 to Pt1 RN2 UE4 , and creates a new entry (entry in the second row of Table 5) in its address translation table. ).
  • RN1 transmits a NAT registration request to P-GW1 (step S618).
  • This NAT registration request includes IP UE4 , Pt1 UE4 , IP UE RN1 , and Pt1 RN1 UE4 .
  • the P-GW 1 when the P-GW 1 receives this NAT registration request, it adds a new entry (entry on the second line in Table 4) to its address translation table. Next, the P-GW 1 transmits a NAT registration response to the RN 1 (Step S620).
  • RN1 receives this NAT registration response and transfers it to RN2 (step S622).
  • the RN 2 forwards it to the UE 4 (step S624).
  • RN2 waits for a certain amount of time (for example, 1 second) after the transmission of RA, and during that time, attach requests regarding UEs connected downstream of RN2 are collectively transmitted to RN1 (step S626). Accordingly, the RN2 can transmit an attach request for a plurality of UEs at a time, instead of transmitting an attach request every time a UE is connected downstream of the RN2.
  • RN1 transfers the request to DeNB1 (step S628).
  • DeNB1 transmits a path switch request to MME1 (step S630).
  • MME1 since the UE that has moved downstream of RN2 already has an IPv6 address, MME1 has already registered information on the moved UE in the management table. Therefore, when MME1 receives this path switch request, it changes the upstream node column of the entry in the management table related to the UE connected to RN2 (for example, the entry related to UE4 (the sixth row entry in Table 3)) to IP D RN2 . Then, a bearer change request is transmitted to S-GW1 (step S632).
  • the S-GW 1 transfers it to the P-GW 1 (step S634).
  • the P-GW 1 when receiving the bearer change request, the P-GW 1 performs release processing when a GTP tunnel related to a UE (for example, UE 4) connected downstream of the RN 2 is established. Then, the P-GW1 transmits a bearer change response to the S-GW1 (step S636).
  • This bearer change response includes the identifier (for example, ID UE4 ) of the UE that has moved downstream of RN2.
  • the S-GW 1 transfers it to the MME 1 (step S638).
  • This path switch request response includes the identifier (for example, ID UE4 ) of the UE that has moved downstream of RN2.
  • DeNB1 transmits an attach accept to RN1 (step S642).
  • This attach accept includes an identifier (for example, ID UE4 ) of the UE that has moved downstream of RN2.
  • RN1 transfers it to RN2 (step S644).
  • the information amount of the routing table stored in the P-GW, S-GW, and DeNB does not depend on the number of UEs in the moving cell.
  • the same number of address translation table entries as the number of ports in communication with this UE are added to the upstream RN and P-GW.
  • MME1 grasps
  • connection process to moving cell by RN having acquired IPv6 address will be described.
  • RN3 that has obtained an IPv6 address under the control of another eNB or RN moves to a moving cell provided by RN1 after the processing described in section (1.6) above.
  • An example of connection processing to the moving cell provided by RN1 by RN3 that has acquired an IPv6 address in this case will be described with reference to FIG.
  • RN3 the application to IP UE RN3 is an IPv6 address to be used, and the IP D RN3 is an IPv6 address of the downstream interface what is already obtained. Further, it is assumed that UE 5 is connected further downstream of RN 3. The UE 5 is assumed to have the IP UE 5 as an IPv6 address. Since the UE 5 has already performed the connection process to the RN 3, the RN 3 knows the ID UE 5 that is the identifier of the UE 5 and the IP UE 5 that is the IPv6 address.
  • FIG. 12 is a sequence diagram showing an example of the flow of connection processing executed in the system according to the present embodiment.
  • RN3, RN1, DeNB1, MME1, S-GW1, and P-GW1 are involved.
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • RN3 establishes a radio channel with RN1 (step S702).
  • the RN 3 transmits an RS to all link-local router multicast addresses (step S704).
  • This RS includes IP UE RN3 .
  • RN3 recognizes that RN3 already has an IP UE RN3 with an IPv6 address, and RN3 connects to Pref UE RN3, which is a prefix of IP UE RN3 , and a moving cell.
  • RN1 from ifid D RN1 is an ID of the downstream interfaces Pref UE RN3 and itself to generate IP3 D RN1 is an IPv6 address, assigns it to the downstream interface.
  • RN3 receives this RA, from ifid U RN3 is the ID of the upstream interfaces Pref UE RN3 and itself generates an IP U RN3 is an IPv6 address (step S 708).
  • RN3 transmits an attach request to RN1 (step S710).
  • This attach request includes ID RN3 and IP UE RN3 which are identifiers of RN3 .
  • RN1 transmits an attach accept to RN3 (step S712).
  • the attach accept includes ifid UE RN3 is an interface ID of the IP UE RN3.
  • RN3 receives this attach accept, acquires ifid UE RN3. Next, RN3 transmits RS to RN1 (step S714).
  • RN1 transmits RA to RN3 (step S716).
  • This RA includes Pref UE RN3 , which is a prefix of IP UE RN3 .
  • RN3 receives this RA, generates IP UE RN3 from Pref UE RN3 and ifid UE RN3, confirms that IP UE RN3 are still available (step S718).
  • RN3 transmits a NAT registration request to RN1 (step S720).
  • This NAT registration request is made up of IP UE RN3 , the port number used by the application on RN3 for communication (for the sake of simplicity, the port number is only one of Pt1 RN3 ), IP UE5 , and UE5 It includes a list of port numbers used in communication (for the sake of simplicity, only one port number is Pt1 UE5 ).
  • RN1 when receiving this NAT registration request, Pt1 RN3 and Pt1 for each UE 5, assign each Pt1 RN1 RN3 and Pt1 RN1 UE 5 as a new port number, a new entry to its own address translation table (Entry in the third row and entry in the fourth row in Table 5) is added.
  • the RN1 transmits a NAT registration request to the P-GW1 (step S722).
  • This NAT registration request includes IP UE RN3 , Pt1 RN3 , IP UE RN1 , Pt1 RN1 RN3 , IP UE5 , Pt1 UE5 , and Pt1 RN1 UE5 .
  • the P-GW 1 when the P-GW 1 receives this NAT registration request, it adds new entries (the third row entry and the fourth row entry in Table 4) to its own address translation table. Next, the P-GW 1 transmits a NAT registration response to the RN 1 (step S724).
  • RN1 forwards it to RN3 (step S726).
  • RN1 waits for a certain amount of time (for example, 1 second) after the transmission of RA, and during that time, attach requests regarding RNs and UEs in a nested mobile cell connected downstream of RN1 are collectively transmitted to DeNB1 (step S728). . Accordingly, RN1 can transmit an attach request for a plurality of nested mobile cells at a time, instead of transmitting an attach request every time a nested mobile cell is connected downstream of RN1.
  • a certain amount of time for example, 1 second
  • the attach request includes an identifier of an RN and a UE (for example, ID RN3 , ID UE5 ), an IPv6 address (for example, IP UE RN3 , IP UE5 ), an IP D RN1 , and a connection to the mobile cell connected to the RN1 .
  • DeNB1 transfers the path switch request to MME1 (step S730).
  • This path switch request includes an identifier of an RN and a UE (eg, ID RN3 , ID UE5 ), an IPv6 address (eg, IP UE RN3 , IP UE5 ), an IP D RN1 , and a mobile cell connected to the RN 1 .
  • MC Flag ON
  • MME1 since the RN and UE that have moved downstream of RN1 already have an IPv6 address, MME1 has already registered information on the UE that is connected to the moved RN and nested mobile cell in the management table. is there. Therefore, when receiving this path switch request, MME1 updates the upstream node column of the management table entry related to the RN and UE in the nested mobile cell connected downstream of RN1 (for example, the column of RN3 and UE5 (Table 3). Entry on line 7 and entry on line 8)). Next, the MME 1 transmits a bearer change request to the S-GW 1 (step S732).
  • the S-GW 1 transfers it to the P-GW 1 (step S734).
  • P-GW1 upon receiving this bearer change request, P-GW1 performs release processing when there is a GTP tunnel related to the most upstream RN (for example, RN3) of the nested mobile cell connected downstream of RN1.
  • P-GW1 transmits a bearer change response to S-GW1 (step S736).
  • This bearer change response includes the identifiers of the RN and UE (for example, ID RN3 and ID UE5 ) in the nested mobile cell connected downstream of RN1.
  • the S-GW 1 transfers it to the MME 1 (step S738).
  • This path switch request response includes the identifiers of RNs and UEs (for example, ID RN3 and ID UE5 ) in the nested mobile cell connected downstream of RN1.
  • the DeNB1 transmits an attach accept to the RN1 (step S742).
  • This attach accept includes the identifiers of RNs and UEs (eg, ID RN3 and ID UE5 ) in the nested mobile cell connected downstream of RN1.
  • the information amount of the routing table stored in the P-GW, S-GW, and DeNB does not depend on the number of RNs and UEs connected in the moving cell.
  • the same number of address translation table entries as the number of ports in communication in the connected nested mobile cell are added to the upstream RN and P-GW.
  • the MME also stores entries for all RNs and UEs connected in the moving cell.
  • Communication processing refers to processing in which the RN or UE that has completed the connection processing communicates with an application on the Internet.
  • the RN converts and relays transmission destination information or transmission source information of a packet transmitted / received between a connection destination upstream node and a downstream node under the control based on a stored conversion table. As a result, the RN can aggregate packets addressed to the downstream node of the RN into the RN.
  • the RN converts the address information of the downstream node in the destination information or the source information included in the packet header.
  • the source information includes, for example, a start point IP address and a start point port number
  • the destination information includes, for example, an end point IP address and an end point port number.
  • the RN identifies whether the packet to be relayed is a packet from the upstream node to the downstream node or a packet from the downstream node to the upstream node. For example, this identification can be performed based on destination information. Then, the RN controls the relay process based on the identification result.
  • the RN converts the source information from the address information of the downstream node to the address information of the RN corresponding to the downstream node. Specifically, the RN converts the IP address of the transmission source information of the packet from the downstream node to the upstream node into the RN IP address. Further, the RN converts the port number of the transmission source information of the packet from the downstream node to the upstream node into the port number of the RN corresponding to the application operating in the most downstream node (that is, the UE or RN at the transmission source end). . As a result, a reply to the packet transmitted from the downstream node connected to the RN can be made to reach the RN.
  • the RN converts destination information from address information of the RN corresponding to the downstream node to address information of the downstream node. Specifically, the RN converts the IP address of the transmission destination information of the packet from the upstream node to the downstream node into the IP address of the downstream node. Further, the RN sets the port number of the transmission destination information of the packet from the upstream node to the downstream node to the port number of the downstream node corresponding to the application operating in the most downstream node (that is, the UE or RN at the transmission destination end). Convert. As a result, the packet transmitted to the downstream node connected to the RN can reach the downstream node.
  • the P-GW converts the transmission destination information or transmission source information of the transmitted / received packet based on the stored conversion table and relays it. More specifically, the P-GW converts destination information of a packet to the UE into address information of an RN upstream of the UE. Also, the P-GW converts the source information converted to the RN address information of the packet from the UE into the UE address information. As a result, the P-GW can aggregate packets transmitted and received by the downstream node connected to the RN into the RN.
  • FIG. 13 is a diagram illustrating an example of the content of a packet header transmitted and received by each node for communication by the UE 1 according to the present embodiment.
  • Each packet header includes the start point IP address srcIP and start point port number srcPort of the packet, the end point IP address dstIP, and the end point port number dstPort.
  • the part which is rewritten during the relay is underlined.
  • UE1 transmits a packet having the header shown in FIG. 13A to RN1.
  • RN1 receives this packet, it recognizes that the communication is from downstream to upstream. Then, the RN 1 searches the address conversion table (Table 5) stored in itself for whether there is an entry whose downstream IP address and downstream port number match the starting point IP address and starting point port number of this packet. Since there is no corresponding entry at this point, RN1 generates a new port number PtRN1 UE1 and adds a new entry (entry on the fifth line in Table 5) to its own address translation table.
  • Table 5 address conversion table
  • this entry sets the start point IP address and the start point port number to the IP UE RN1 and Pt1 RN1 UE1 . It means rewriting.
  • RN1 performs rewriting based on this entry.
  • the packet header after RN1 relays from downstream to upstream has the contents shown in FIG.
  • This packet reaches the P-GW 1 by route control in LTE, and further reaches an application on the Internet by route control in the Internet.
  • the packet header when the application on the Internet receives and returns the packet has the content shown in FIG.
  • This packet reaches P-GW1 by route control in the Internet, and further reaches RN1 by route control in LTE.
  • RN1 receives this packet, it recognizes that the communication is from upstream to downstream. Then, the RN 1 searches the address conversion table stored therein for whether there is an entry whose upstream IP address and upstream port number match the end point IP address and end point port number of the packet. As a result, the entry on the fifth line in Table 5 is found.
  • This entry indicates that when the destination IP address and the destination port number are IP UE RN1 and Pt1 RN1 UE1 when the RN1 transfers a packet from upstream to downstream, the destination IP address and the destination port number are transferred to the IP UE1 and Pt1 UE1 . It means rewriting. RN1 performs rewriting based on this entry. As a result, the packet header after RN1 relays from upstream to downstream has the contents shown in FIG. This packet reaches the application on UE1.
  • FIG. 14 is a diagram illustrating an example of the content of a packet header transmitted and received by each node for communication by the UE 1 according to the present embodiment.
  • Each packet header includes the start point IP address srcIP and start point port number srcPort of the packet, the end point IP address dstIP, and the end point port number dstPort.
  • the part which is rewritten during the relay is underlined.
  • UE1 transmits a NAT registration request to RN1.
  • This NAT registration request includes IP UE1 and Pt2 UE1 .
  • RN1 Upon receiving this NAT registration request, RN1 generates a new port number Pt2 RN1 UE1 and adds a new entry (entry on the sixth line in Table 5) to its address translation table.
  • This entry rewrites the destination IP address and destination port number to IP UE1 and Pt2 UE1 when the destination IP address and destination port number are IP UE RN1 and Pt2 RN1 UE1 when RN1 forwards the packet from upstream to downstream Means that.
  • this entry indicates the start point IP address and the start point port number as IP UE RN1 and Pt2 RN1 UE1. It means to rewrite.
  • RN1 transmits a NAT registration request to P-GW1.
  • This NAT registration request includes IP UE RN1 , Pt2 RN1 UE1 , IP UE1 and Pt2 UE1 .
  • the P-GW 1 receives this NAT registration request, it adds a new entry (entry on the fifth line in Table 4) to its address translation table.
  • This entry is used when the destination IP address and the destination port number are IP UE1 and Pt2 UE1 when the P-GW1 forwards the packet from upstream (ie, PDN) to downstream (ie, CN). This means that the port number is rewritten to IP UE RN1 and Pt2 RN1 UE1 .
  • the P-GW1 transfers a packet from the downstream to the upstream when the start point IP address and the start point port number are IP UE RN1 and Pt2 RN1 UE1 , the start point IP address and the start point port number are set to IP UE1 and It means rewriting to Pt2 UE1 .
  • IP address: IP CN , port number: Pt CN IP address: IP CN , port number: Pt CN
  • Pt2 UE1 application operating on UE1
  • This packet reaches the P-GW 1 by route control in the Internet.
  • P-GW1 rewrites the end point IP address and end point port number from IP UE1 and Pt2 UE1 to IP UE RN1 and Pt2 RN1 UE1 according to the entry in the fifth row of its own address translation table (Table 4).
  • Table 4 its own address translation table
  • the RN1 When receiving this packet, the RN1 rewrites the end point IP address and the end point port number from the IP UE RN1 and the Pt2 RN1 UE1 to the IP UE1 and the Pt2 UE1 according to the entry in the sixth row of its own address translation table (Table 5). As a result, the packet header has the contents shown in FIG. This packet reaches UE1.
  • the packet header has the content shown in FIG. UE1 transmits this packet to RN1.
  • RN1 Upon receiving this packet, RN1 rewrites the start point IP address and start point port number from IP UE1 and Pt2 UE1 to IP UE RN1 and Pt2 RN1 UE1 according to the entry in the sixth row of its own address translation table (Table 5). As a result, the packet header has the contents shown in FIG. This packet reaches the P-GW 1 by route control in LTE.
  • the P-GW1 Upon receiving this packet, the P-GW1 changes the start point IP address and the start point port number from the IP UE RN1 and Pt2 RN1 UE1 to the IP UE1 and Pt2 UE1 according to the entry in the fifth row of its own address translation table (Table 4). rewrite. As a result, the packet header has the contents shown in FIG. This packet reaches an application in the Internet by route control in the Internet.
  • FIG. 15 is a diagram illustrating an example of the contents of a packet header transmitted and received by each node for communication by the UE 2 according to the present embodiment.
  • Each packet header includes the start point IP address srcIP and start point port number srcPort of the packet, the end point IP address dstIP, and the end point port number dstPort.
  • the part which is rewritten during the relay is underlined.
  • the UE2 transmits to RN1 a packet having the header shown in FIG.
  • the RN1 changes the start point IP address and start point port number of this packet from the IP UE2 and Pt1 UE2 to the IP UE RN1 and Pt1 RN1 UE2 according to the entry in the first row of its own address translation table (Table 5). Rewrite to As a result, the packet header after RN1 relays from downstream to upstream has the contents shown in FIG. This packet reaches the P-GW 1 by route control in LTE.
  • the P-GW1 When the P-GW1 receives this packet, it follows the entries in the first row of its own address translation table (Table 4), and changes the IP address and source port number of this packet from IP UE RN1 and Pt1 RN1 UE2 to IP UE2 and Rewrite to Pt1 UE2 . As a result, the packet header after P-GW 1 relays has the contents shown in FIG. This packet reaches an application on the Internet by route control in the Internet.
  • Table 4 the entries in the first row of its own address translation table
  • the packet header when the application on the Internet receives and returns this packet has the content shown in FIG. This packet reaches the P-GW 1 by route control in the Internet.
  • P-GW1 rewrites the end point IP address and end point port number of this packet from IP UE2 and Pt1 UE2 to IP UE RN1 and Pt1 RN1 UE2 according to the entry in the first row of its own address translation table (Table 4).
  • Table 4 the packet header after P-GW 1 relays has the contents shown in FIG. This packet reaches RN1 by route control in LTE.
  • RN1 Upon receiving this packet, RN1 changes the destination IP address and destination port number of this packet from IP UE RN1 and Pt1 RN1 UE2 to IP UE2 and Pt1 UE2 according to the entry in the first row of its own address translation table (Table 5). Rewrite to As a result, the packet header after RN1 relays has the contents shown in FIG. This packet reaches UE2.
  • the communication process in this case is the same as the communication process in the case where the UE 1 waits for the communication start described in the above section (2.1.2).
  • the entry in the seventh row of Table 5 is added to the address conversion table stored in RN1
  • the entry in the sixth row in Table 4 is added to the address conversion table stored in P-GW1.
  • the communication process in this case is the same as the communication process in the case where the UE 1 starts communication described in the above section (2.1.1). As a result, an entry in the eighth row of Table 5 is added to the address conversion table of RN1.
  • the communication processing in this case is the same as the communication processing in the case where UE1 waits for communication start described in the above section (2.1.2).
  • the entry in the ninth row of Table 5 is added to the address conversion table stored in RN1
  • the entry in the seventh row in Table 4 is added to the address conversion table stored in P-GW1.
  • FIG. 16 is a diagram illustrating an example of the contents of a packet header transmitted and received by each node for communication by the UE 3 according to the present embodiment.
  • Each packet header includes the start point IP address srcIP and start point port number srcPort of the packet, the end point IP address dstIP, and the end point port number dstPort.
  • the part which is rewritten during the relay is underlined.
  • the RN 2 searches the address translation table (Table 6) stored therein for an entry in which the downstream IP address and the downstream port number match the starting point IP address and the starting point port number of the packet. . Since there is no corresponding entry at this time, RN2 generates a new port number Pt1 RN2 UE3 and adds a new entry (entry in the second row of Table 6) to its address translation table.
  • Table 6 the address translation table
  • This entry indicates that when the start point IP address and the start point port number are IP UE3 and Pt1 UE3 when the RN2 transfers the packet from the downstream to the upstream, the start point IP address and the start point port number are transferred to the IP UE RN2 and Pt1 RN2 UE3 . It means rewriting.
  • the destination IP address and the destination port number are IP UE RN2 and Pt1 RN2 UE3 when the RN2 transfers the packet from upstream to downstream, this entry indicates the destination IP address and the destination port number as IP UE3 and Pt1. This means rewriting to UE3 .
  • RN2 performs rewriting based on this entry.
  • the packet header after RN2 relays from downstream to upstream has the contents shown in FIG. This packet reaches RN1.
  • the RN 1 When receiving this packet, the RN 1 searches the address conversion table stored in itself for an entry whose downstream IP address and downstream port number match the start point IP address and start point port number of the packet. Since there is no corresponding entry at this time, RN1 generates a new port number Pt1 RN1 UE3 and adds a new entry (entry on the 10th line in Table 5) to its own address translation table.
  • This entry indicates that when the RN1 transfers a packet from downstream to upstream and the source IP address and source port number are IP UE RN2 and Pt1 RN2 UE3 , the source IP address and source port number are set to IP UE RN1 and Pt1 RN1. This means rewriting to UE3 .
  • the end point IP address and the end point port number are IP UE RN1 and Pt1 RN1 UE3 when RN1 transfers a packet from upstream to downstream, this entry indicates the end point IP address and end point port number as IP UE RN2 and This means rewriting to Pt1 RN2 UE3 .
  • RN1 performs rewriting based on this entry.
  • the packet header after RN1 relays from downstream to upstream has the contents shown in FIG.
  • This packet reaches the P-GW 1 by route control in LTE, and further reaches an application on the Internet by route control in the Internet.
  • the packet header when the application on the Internet receives and returns this packet has the content shown in FIG.
  • This packet reaches P-GW1 by route control in the Internet, and further reaches RN1 by route control in LTE.
  • the RN1 rewrites the end point IP address and the end point port number from the IP UE RN1 and the Pt1 RN1 UE3 to the IP UE RN2 and the Pt1 RN2 UE3 according to the entry in the 10th line of its own address translation table (Table 5).
  • Table 5 the entry in the 10th line of its own address translation table
  • RN2 Upon receiving this packet, RN2 rewrites the end point IP address and end point port number from IP UE RN2 and Pt1 RN2 UE3 to IP UE3 and Pt1 UE3 according to the entry in the second row of its own address translation table (Table 6). As a result, the packet header after RN2 relays from upstream to downstream has the contents shown in FIG. This packet reaches the application on UE3.
  • FIG. 17 is a diagram illustrating an example of the contents of a packet header transmitted and received by each node for communication by the UE 3 according to the present embodiment.
  • Each packet header includes the start point IP address srcIP and start point port number srcPort of the packet, the end point IP address dstIP, and the end point port number dstPort.
  • the part which is rewritten during the relay is underlined.
  • UE3 transmits a NAT registration request to RN2.
  • This NAT registration request includes IP UE3 and Pt2 UE3 .
  • RN2 Upon receiving this NAT registration request, RN2 generates a new port number Pt2 RN2 UE3 and adds a new entry (entry on the third line in Table 6) to its address translation table.
  • This entry rewrites the end point IP address and end point port number to IP UE3 and Pt2 UE3 when the end point IP address and end point port number are IP UE RN2 and Pt2 RN2 UE3 when RN2 forwards the packet from upstream to downstream Means that.
  • the entry indicates the start point IP address and the start point port number as IP UE RN2 and Pt2 RN2 UE3. It means to rewrite.
  • RN2 forwards the NAT registration request to RN1.
  • This NAT registration request includes IP UE RN2 , Pt2 RN2 UE3 , IP UE3 , and Pt2 UE3 .
  • RN1 Upon receiving this NAT registration request, RN1 generates a new port number Pt2 RN1 UE3 and adds a new entry (entry on the 11th line in Table 5) to the address translation table stored by itself.
  • the destination IP address and the destination port number are IP UE RN1 and Pt2 RN1 UE3 when RN1 transfers a packet from upstream to downstream
  • the destination IP address and the destination port number are set to IP U RN2 and Pt2 RN2 UE3. It means to rewrite.
  • the entry indicates the start point IP address and the start point port number as the IP UE RN1 and Pt2. It means rewriting to RN1 UE3 .
  • This NAT registration request includes IP UE RN1 , Pt2 RN1 UE3 , IP UE3 , and Pt2 UE3 .
  • the P-GW 1 receives this NAT registration request, it adds a new entry (entry on the eighth line in Table 4) to the address conversion table stored by itself.
  • This entry indicates that when the end point IP address and the end point port number are IP UE3 and Pt2 UE3 when the packet is transferred by the P-GW1, the end point IP address and the end point port number are rewritten to IP UE RN1 and Pt2 RN1 UE3. means. Further, this entry means that when the start point IP address and start point port number are IP UE RN1 and Pt2 RN1 UE3 , the start point IP address and start point port number are rewritten to IP UE3 and Pt2 UE3 .
  • IP address: IP CN , port number: Pt CN IP address: IP CN , port number: Pt CN
  • Pt2 UE3 application operating on UE3
  • This packet reaches the P-GW 1 by route control in the Internet.
  • the P-GW 1 rewrites the end point IP address and end point port number from the IP UE 3 and Pt 2 UE 3 to the IP UE RN 1 and Pt 2 RN 1 UE 3 according to the entry in the eighth line of its own address translation table (Table 4).
  • Table 4 the eighth line of its own address translation table
  • RN1 Upon receiving this packet, RN1 changes the end point IP address and end point port number from IP UE RN1 and Pt2 RN1 UE3 to IP UE RN2 and Pt2 RN2 UE3 according to the entry in the eleventh row of its own address translation table (Table 5). rewrite. As a result, the packet header has the contents shown in FIG. This packet reaches RN2.
  • RN2 Upon receiving this packet, RN2 rewrites the end point IP address and end point port number from IP UE RN2 and Pt2 RN2 UE3 to IP UE3 and Pt2 UE3 in accordance with the entry in the third row of its own address translation table (Table 6). As a result, the packet header has the contents shown in FIG. This packet reaches the application on UE2.
  • RN2 Upon receiving this packet, RN2 rewrites the start point IP address and start point port number from IP UE3 and Pt2 UE3 to IP UE RN2 and Pt2 RN2 UE3 in accordance with the entry in the third row of its own address translation table (Table 6). As a result, the packet header has the contents shown in FIG. This packet reaches RN1.
  • the RN1 Upon receiving this packet, the RN1 changes the start point IP address and the start point port number from the IP UE RN2 and the Pt2 RN2 UE3 to the IP UE RN1 and the Pt2 RN1 UE3 according to the entry in the eleventh line of its own address translation table (Table 5). rewrite. As a result, the packet header has the contents shown in FIG. This packet reaches the P-GW 1 by route control in LTE.
  • the P-GW1 When receiving this packet, the P-GW1 rewrites the start point IP address and the start point port number from the IP UE RN1 and the Pt2 RN1 UE3 to the IP UE3 and the Pt2 UE3 according to the entry in the eighth row of its own address translation table (Table 4). .
  • Table 4 the eighth row of its own address translation table
  • FIG. 18 is a diagram illustrating an example of the content of a packet header transmitted and received by each node for communication by the UE 4 according to the present embodiment.
  • Each packet header includes the start point IP address srcIP and start point port number srcPort of the packet, the end point IP address dstIP, and the end point port number dstPort.
  • the part which is rewritten during the relay is underlined.
  • the UE4 transmits to RN1 a packet having the header shown in FIG.
  • the start point IP address and start point port number of the packet are transferred from the IP UE4 and the Pt1 UE4 to the IP UE RN2 and the Pt1 RN2 UE4 according to the entry in the first row of its own conversion table (Table 6). rewrite.
  • Table 6 the first row of its own conversion table
  • RN1 When RN1 receives this packet, it follows the entries in the second row of its own address translation table (Table 5) and changes the IP address and source port number of this packet from IP UE RN2 and Pt1 RN2 UE4 to IP UE RN1 and Pt1. Rewrite to RN1 UE4 . As a result, the packet header after RN1 relays from downstream to upstream has the contents shown in FIG. This packet reaches the P-GW 1 by LTE path control.
  • Table 5 the entries in the second row of its own address translation table
  • the P-GW1 When the P-GW1 receives this packet, it follows the entries in the second row of its own address translation table (Table 4), and changes the IP address and source port number of this packet from IP UE RN1 and Pt1 RN1 UE4 to IP UE4 and Rewrite to Pt1 UE4 . As a result, the packet header after the P-GW 1 relays from downstream to upstream has the contents shown in FIG. This packet reaches an application on the Internet by route control in the Internet.
  • Table 4 the entries in the second row of its own address translation table
  • the packet header when the application on the Internet receives and returns this packet has the contents shown in FIG. This packet reaches the P-GW 1 by route control in the Internet.
  • the P-GW 1 When the P-GW 1 receives this packet, it changes the destination IP address and destination port number of this packet from the IP UE 4 and Pt 1 UE 4 to the IP UE RN 1 and Pt 1 according to the entry in the second row of its own address translation table (Table 4). Rewrite to RN1 UE4 . As a result, the packet header after the P-GW 1 relays from upstream to downstream has the contents shown in FIG. This packet reaches RN1 by route control in LTE.
  • RN1 Upon receiving this packet, RN1 changes the destination IP address and destination port number of this packet from IP UE RN1 and Pt1 RN1 UE4 to IP UE RN2 and Pt1 according to the entry in the second row of its own address translation table (Table 5). Rewrite to RN2 UE4 .
  • Table 5 the second row of its own address translation table
  • RN2 Upon receiving this packet, RN2 changes the destination IP address and destination port number of this packet from IP UE RN2 and Pt1 RN2 UE4 to IP UE4 and Pt1 UE4 according to the entry in the first row of its own address translation table (Table 6). Rewrite to As a result, the packet header after RN2 relays from upstream to downstream has the contents shown in FIG. This packet reaches the application on UE4.
  • the communication process in this case is the same as the communication process in the case where the UE 3 waits for the communication start described in the section (2.4.2) above.
  • the entry in the fourth row of Table 6 is added to the address conversion table stored in RN2
  • the entry in the twelfth row in Table 5 is added to the address conversion table stored in RN1
  • P-GW1 is stored.
  • An entry on the ninth line of Table 4 is added to the address conversion table.
  • the communication process in this case is the same as the communication process in the case where the UE 2 continues the communication described in the section (2.2.1) above.
  • the communication process in this case is the same as the communication process in the case where the UE 1 waits for the communication start described in the above section (2.1.2).
  • the 13th line entry of Table 5 is added to the address conversion table stored in RN1
  • the 10th line entry in Table 4 is added to the address conversion table stored in P-GW1.
  • the communication process in this case is the same as the communication process in the case where the UE 4 continues the communication described in the above section (2.5.1).
  • the communication process in this case is the same as the communication process in the case where the UE 3 waits for the communication start described in the section (2.4.2) above.
  • the entry of the second row of Table 7 is added to the address conversion table stored in RN3
  • the entry of the 14th row of Table 5 is added to the address conversion table stored in RN1, and P-GW1 is stored.
  • An entry on the 11th line of Table 4 is added to the address conversion table.
  • Intra-S-GW Handover This section describes processing related to intra-S-GW handover. As an example, it is assumed that RN1 performs handover from DeNB1 to DeNB2. An example of a handover process when RN1 hands over from DeNB1 to DeNB2 in a state where UE1, RN2, and UE2 are connected downstream of RN1, will be described with reference to FIG.
  • FIG. 19 is a sequence diagram showing an example of the flow of handover processing executed in the system according to the present embodiment.
  • RN1, DeNB1, DeNB2, MME1, S-GW1, and P-GW1 are involved.
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • DeNB1 determines the handover execution of RN1 to DeNB2 (step S802).
  • DeNB1 transmits a handover request (Handover Request) to DeNB2 (step S804).
  • This handover request includes ID RN1 .
  • DeNB2 transmits a handover request response (Handover Request Ack) to DeNB1 (step S806).
  • This handover request response includes ID RN1 .
  • RN1 establishes a radio channel with DeNB2 (step S808).
  • RN1 transmits the RS to all the link-local router multicast addresses (step S810).
  • DeNB2 receives this RS and transmits RA to the link local address of RN1 (step S812).
  • This RA includes Pref D DeNB2 , which is a prefix of the downstream interface of DeNB2 .
  • RN1 receives this RA, and generates IP2 U RN1 that is an IPv6 address from Pref D DeNB2 and ifid U RN1 (step S814).
  • IP2 U RN1 is used when RN1 establishes a GTP tunnel with DeNB2.
  • RN1 transmits an attach request to DeNB2 (step S816).
  • This attach request includes ID RN1 , IP UE RN1 and Pref D RN1 which are identifiers of RN1 .
  • DeNB 2 transmits a path switch request to MME 1 (step S818).
  • This path switch request includes ID RN1 , IP UE RN1 , Pref D RN1 , and IP D DeNB2 .
  • the MME 1 transmits a bearer change request to the S-GW 1 (step S820).
  • This bearer change request includes ID RN1 , IP UE RN1 , and Pref D RN1 .
  • S-GW1 detects that RN1 has handed over between DeNBs downstream of S-GW1, and releases the GTP tunnel established between S-GW1 and DeNB1.
  • a GTP tunnel is configured between S-GW1 and DeNB2.
  • the end points of this GTP tunnel are IP D SGW1 which is the IPv6 address of the downstream interface of S-GW1, and IP U DeNB2 which is the IPv6 address of the upstream interface of DeNB2 .
  • S-GW1 associates the forwarding destinations of Pref UE RN1 and Pref D RN1 with this GTP tunnel.
  • the S-GW1 transmits a bearer change response to the MME1 (Step S822).
  • This bearer change response includes ID RN1 , IP UE RN1 , and Pref D RN1 .
  • This path switch request response includes ID RN1 , IP UE RN1 , and Pref D RN1 .
  • DeNB2 configures a GTP tunnel between DeNB2 and S-GW1.
  • the end points of this GTP tunnel are IP U DeNB2 and IP D SGW1 .
  • DeNB2 configures a GTP tunnel with RN1.
  • the end points of this GTP tunnel are IP D DeNB2 , which is the IPv6 address of the downstream interface of DeNB2 , and IP U RN1 , which is the IPv6 address of the upstream interface of RN1 .
  • DeNB2 is the transfer destination of Pref UE RN1 and Pref D RN1, associated with GTP tunnel to RN1.
  • DeNB2 transmits an attach accept to RN1 (step S826). This attach accept includes Pref UE RN1 .
  • RN1 transmits an RS to P-GW1 in order to obtain an IPv6 address when operating as a UE (step S828).
  • P-GW1 transmits RA to RN1 (step S830).
  • This RA includes Pref UE RN1 .
  • RN1 receives this RA and confirms that IP UE RN1 is continuously available (step S832).
  • each of the S-GW1 and DeNB2 stores the route tables shown in Table 9A and Table 9B, respectively.
  • the MME 1 stores the management table shown in Table 8. Note that there is no change in the route table and address conversion table stored in the P-GW 1 and the address conversion tables stored in the RN 1, RN 2, and RN 3.
  • Inter-S-GW Handover This section describes processing related to inter-S-GW handover. As an example, it is assumed that RN1 performs handover from DeNB1 to DeNB3. An example of a handover process when RN1 performs handover from DeNB1 to DeNB3 in a state where UE1, RN2, and UE2 are connected downstream of RN1 will be described with reference to FIG.
  • FIG. 20 is a sequence diagram showing an example of the flow of handover processing executed in the system according to the present embodiment.
  • RN1, DeNB1, DeNB3, MME1, S-GW1, S-GW2, and P-GW1 are involved.
  • GTP tunnels are configured between P-GW1 and S-GW1, between S-GW1 and DeNB1, and between DeNB1 and RN1, respectively.
  • DeNB1 decides to execute handover of RN1 to DeNB3 (step S902).
  • DeNB1 transmits a handover request to DeNB3 (step S904).
  • This handover request includes ID RN1 .
  • DeNB3 transmits a handover request response to DeNB1 (step S906).
  • This handover request response includes ID RN1 .
  • RN1 establishes a radio channel with DeNB3 (step S908).
  • RN1 transmits the RS to all the link-local router multicast addresses (step S910).
  • the DeNB 3 transmits the RA to the link local address of the RN 1 (step S912).
  • This RA includes Pref D DeNB 3 which is a prefix of the downstream interface of DeNB 3 .
  • RN1 receives this RA, and generates IP3 U RN1 that is an IPv6 address from Pref D DeNB3 and ifid U RN1 (step S914).
  • IP3 U RN1 is used when RN1 establishes a GTP tunnel with DeNB3.
  • RN1 transmits an attach request to DeNB3 (step S916).
  • This attach request includes the identifier ID RN1 of RN1 , IP UE RN1 , and Pref D RN1 .
  • DeNB 3 transmits a path switch request to MME 1 (step S918).
  • This path switch request includes ID RN1 , IP UE RN1 , Pref D RN1 and IP D DeNB3 .
  • This bearer change request includes ID RN1 , IP UE RN1 , and Pref D RN1 .
  • the S-GW 2 transfers the request to the P-GW 1 (step S922).
  • P-GW1 detects that RN1 has handed over between S-GW1 and S-GW2, and establishes a GTP tunnel established between P-GW1 and S-GW1.
  • the GTP tunnel established between S-GW1 and DeNB1 is released, and the GTP tunnel is configured between P-GW1 and S-GW2.
  • the end points of this GTP tunnel are IP D PGW1 , which is the IPv6 address of the downstream interface of P-GW1, and IP U SGW2 , which is the IPv6 address of the upstream interface of S-GW2.
  • P-GW1 associates the forwarding destinations of Pref UE RN1 and Pref D RN1 with this GTP tunnel.
  • the P-GW1 transmits a bearer change response to the S-GW2 (Step S924).
  • This bearer change response includes ID RN1 , IP UE RN1 , and Pref D RN1 .
  • the S-GW 2 configures a GTP tunnel between the P-GW 1 and the S-GW 2.
  • the end points of this GTP tunnel are IP U SGW2 which is the IPv6 address of the upstream interface of S-GW2, and IP D PGW1 which is the IPv6 address of the downstream interface of P-GW1.
  • the S-GW 2 configures a GTP tunnel with the DeNB 3.
  • the end points of this GTP tunnel are IP D SGW2 which is the IPv6 address of the downstream interface of S-GW2, and IP U DeNB3 which is the IPv6 address of the upstream interface of DeNB3 .
  • the S-GW 2 associates the forwarding destinations of the Pref UE RN1 and Pref D RN1 with the GTP tunnel to the DeNB 3.
  • the S-GW 2 transfers the bearer change response to the MME 1 (Step S926).
  • This bearer change response includes ID RN1 , IP UE RN1 , and Pref D RN1 .
  • This path switch request response includes ID RN1 , IP UE RN1 , and Pref D RN1 .
  • the DeNB 3 when the DeNB 3 receives this path switch request response, it configures a GTP tunnel between the DeNB 3 and the S-GW 2.
  • the end points of this GTP tunnel are IP U DeNB3 , which is the IPv6 address of the upstream interface of DeNB3 , and IP D SGW2 , which is the IPv6 address of the downstream interface of S-GW2.
  • DeNB3 forms a GTP tunnel with RN1.
  • the end points of this GTP tunnel are IP D DeNB3 which is the IPv6 address of the downstream interface of DeNB3 , and IP U RN1 which is the IPv6 address of the upstream interface of RN1 .
  • the DeNB 3 associates the Pref UE RN1 and the Pref D RN1 transfer destination with the GTP tunnel to the RN1.
  • the DeNB 3 transfers the attach accept to the RN 1 (Step S930). This attach accept contains if UE RN1 .
  • a GTP tunnel is established between RN1 and DeNB3, between DeNB3 and S-GW2, and between S-GW2 and P-GW1.
  • RN1 transmits an RS to P-GW1 in order to obtain an IPv6 address when operating as a UE (step S932).
  • P-GW1 transmits RA to RN1 (step S934).
  • This RA includes Pref UE RN1 .
  • the RN1 receives this RA and confirms that the IP UE RN1 is continuously available (step S936).
  • each of P-GW1, S-GW2, and DeNB3 stores the route tables shown in Table 11A, Table 11B, and Table 11C, respectively.
  • the MME 1 stores the management table shown in Table 10. There is no change in the address conversion table stored in P-GW1, RN1, and RN2.
  • the conversion table entry has a timer field.
  • a timeout time for example, 60 seconds
  • the timer field of each entry is subtracted by the elapsed time every predetermined time (for example, 1 second), and when the value becomes 0 or less, the entry may be deleted.
  • the application waiting for the start of communication on the UE or RN transmits a NAT registration request to the upstream node at every update time (for example, 30 seconds) and receives a NAT registration response.
  • update time for example, 30 seconds
  • FIG. 21 is a sequence diagram showing an example of the flow of address translation table entry maintenance processing executed in the system according to the present embodiment.
  • UE1, RN1, and P-GW1 are involved.
  • UE1 transmits a NAT registration request to RN1 (step S1002).
  • the RN1 transmits a NAT registration request to the P-GW1 (step S1004).
  • the P-GW1 transmits a NAT registration response to the RN1 (step S1006).
  • RN1 transmits a NAT registration response to UE1 (step S1008).
  • P-GW 1 stores the entries in the fifth row of Table 4
  • RN 1 stores the entries in the fifth and sixth rows of Table 5.
  • FIG. 22 and 23 are diagrams showing an example of the architecture of the next-generation network.
  • FIG. 22 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 IP transparency of the UE group connected to the RN without a mechanism such as mobile IP.
  • FIG. 23 shows an architecture in which the control plane and the user plane are separated using the cloud.
  • FIG. 24 is a diagram illustrating an example of an RN protocol stack according to the present embodiment.
  • the RN has a network layer IP address in addition to the EPC transport layer IP address. Since this RN can also operate as a UE, it may be called URN (User-Equipment-Relay-Node).
  • FIG. 25 is a diagram illustrating an example of a protocol stack in communication between the UE via the RN and the server on the PDN according to the present embodiment.
  • the RN is connected to the DeNB and communicates with the application server on the PDN via the EPC (S-GW and P-GW). Further, the RN relays radio communication between the subordinate UE and the connected DeNB.
  • (1) Realization of network service when moving For example, when an RN is mounted on a public vehicle such as a bus or a train, the RN provides local content from a server connected to the RN to a passenger's UE. The discontinuity of access associated with movement can be resolved. Also, mobility is realized for services from a DeNB to which the RN is connected or a server connected to an entity on the core network. In particular, a server connected to the RN is effective for a service that requires a low delay time. In addition, when a nested virtual cell formed by a passenger's RN is connected to an RN mounted on a public vehicle, only the passenger's RN performs connection processing, and the connectivity of the nested virtual cell to the network continues. Is done. This avoids a situation in which all UEs perform connection processing 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 a cognitive radio system may be implemented in the RN.
  • the RN can use the location information (such as GPS information or radio base station information) to identify a frequency that can be used at the current position from the frequency database, and provide a virtual cell using the frequency. It becomes. It is also possible to provide a network access service via the RN, or a D2D (Device to Device) communication service between the UE and UE, or between the RN and UE.
  • D2D Device to Device
  • a drone that functions as an RN is also referred to as a king drone below.
  • 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.
  • Realization of long-distance wireless connection services Realization of nested virtual cells is expected to expand coverage by so-called multi-hop connection (ie, linking of virtual cells) that connects one hop of RN-UE. Is done.
  • the core network node eg, P-GW, S-GW, MME, etc.
  • the core network node may be realized as any type of server such as a tower server, a rack server, or a blade server.
  • at least a part of the components of the core network node is realized in a module (for example, an integrated circuit module configured by one die or a card or a blade inserted in a slot of the blade server) mounted on the server. May be.
  • the DeNB may be realized as any kind of eNB (evolved Node B) such as a macro eNB or a small eNB.
  • the small eNB may be an eNB that covers a cell smaller than a macro cell, such as a pico eNB, a micro eNB, or a home (femto) eNB.
  • the DeNB may be realized as another type of base station such as Node B or BTS (Base Transceiver Station).
  • the DeNB may include a main body (also referred to as a base station apparatus) that controls radio communication and one or more RRHs (Remote Radio Heads) that are arranged at locations different from the main body.
  • RRHs Remote Radio Heads
  • various types of terminals described later may operate as the DeNB by temporarily or semi-permanently executing the base station function.
  • at least some components of the DeNB may be realized in a base station device or a module for the base station device.
  • the UE and the RN are 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 and the RN may be realized as terminals (also referred to as MTC (Machine Type Communication) terminals) that perform M2M (Machine To Machine) communication. Furthermore, at least some components of the UE and the RN may be realized in a module (for example, an integrated circuit module configured by one die) mounted on these terminals.
  • MTC Machine Type Communication
  • FIG. 26 is a block diagram illustrating an example of a schematic configuration of a server 700 to which the technology according to the present disclosure can 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 core network node (for example, P-GW, S-GW, and MME) described with reference to FIG. May be implemented in the processor 701.
  • 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.
  • 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 410 described with reference to FIG. 5 may be implemented in the network interface 704.
  • the storage unit 420 may be implemented in the memory 702 and / or the storage 703.
  • FIG. 27 is a block diagram illustrating a first example of a schematic configuration of an eNB to which the technology according to the present disclosure may be applied.
  • the eNB 800 includes one or more antennas 810 and a base station device 820. Each antenna 810 and the base station apparatus 820 can be connected to each other via an RF cable.
  • Each of the antennas 810 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 and reception of radio signals by the base station apparatus 820.
  • the eNB 800 includes a plurality of antennas 810 as illustrated in FIG. 27, and the plurality of antennas 810 may respectively correspond to a plurality of frequency bands used by the eNB 800, for example. Note that although FIG. 27 illustrates an example in which the eNB 800 includes a plurality of antennas 810, the eNB 800 may include a single antenna 810.
  • the base station apparatus 820 includes a controller 821, a memory 822, a network interface 823, and a wireless communication interface 825.
  • the controller 821 may be a CPU or a DSP, for example, and operates various functions of the upper layer of the base station apparatus 820. For example, the controller 821 generates a data packet from the data in the signal processed by the wireless communication interface 825, and transfers the generated packet via the network interface 823. The controller 821 may generate a bundled packet by bundling data from a plurality of baseband processors, and may transfer the generated bundled packet. In addition, the controller 821 is a logic that executes control such as radio resource control, radio bearer control, mobility management, inflow control, or scheduling. May have a typical function. Moreover, the said control may be performed in cooperation with a surrounding eNB or a core network node.
  • the memory 822 includes RAM and ROM, and stores programs executed by the controller 821 and various control data (for example, terminal list, transmission power data, scheduling data, and the like).
  • the network interface 823 is a communication interface for connecting the base station device 820 to the core network 824.
  • the controller 821 may communicate with the core network node or other eNB via the network interface 823.
  • the eNB 800 and the core network node or another eNB may be connected to each other by a logical interface (for example, an S1 interface or an X2 interface).
  • the network interface 823 may be a wired communication interface or a wireless communication interface for wireless backhaul.
  • the network interface 823 may use a frequency band higher than the frequency band used by the wireless communication interface 825 for wireless communication.
  • the wireless communication interface 825 supports any cellular communication scheme such as LTE (Long Term Evolution) or LTE-Advanced, and provides a wireless connection to terminals located in the cell of the eNB 800 via the antenna 810.
  • the wireless communication interface 825 may typically include a baseband (BB) processor 826, an RF circuit 827, and the like.
  • the BB processor 826 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and each layer (for example, L1, MAC (Medium Access Control), RLC (Radio Link Control), and PDCP).
  • Various signal processing of Packet Data Convergence Protocol
  • Packet Data Convergence Protocol is executed.
  • the BB processor 826 may have some or all of the logical functions described above instead of the controller 821.
  • the BB processor 826 may be a module that includes a memory that stores a communication control program, a processor that executes the program, and related circuits. The function of the BB processor 826 may be changed by updating the program. Good.
  • the module may be a card or a blade inserted into a slot of the base station apparatus 820, or a chip mounted on the card or the blade.
  • the RF circuit 827 may include a mixer, a filter, an amplifier, and the like, and transmits and receives a radio signal via the antenna 810.
  • the wireless communication interface 825 includes a plurality of BB processors 826 as shown in FIG. 27, and the plurality of BB processors 826 may correspond to a plurality of frequency bands used by the eNB 800, for example.
  • the wireless communication interface 825 includes a plurality of RF circuits 827 as shown in FIG. 27, and the plurality of RF circuits 827 may correspond to, for example, a plurality of antenna elements, respectively.
  • 27 shows an example in which the wireless communication interface 825 includes a plurality of BB processors 826 and a plurality of RF circuits 827, the wireless communication interface 825 includes a single BB processor 826 or a single RF circuit 827. But you can.
  • the eNB 800 illustrated in FIG. 27 one or more components (for example, the control unit 350) included in the DeNB described with reference to FIG. 4 may be implemented in the wireless communication interface 825. Alternatively, at least some of these components may be implemented in the controller 821.
  • the eNB 800 includes a module including a part (for example, the BB processor 826) or all of the wireless communication interface 825 and / or the controller 821, and the one or more components are mounted in the module. Good.
  • 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 eNB 800, and the radio communication interface 825 (eg, the BB processor 826) and / or the controller 821 executes the program.
  • the eNB 800, the base station apparatus 820, 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 is provided. May be.
  • a readable recording medium in which the program is recorded may be provided.
  • the wireless communication unit 320 described with reference to FIG. 4 may be implemented in the wireless communication interface 825 (for example, the RF circuit 827).
  • the antenna unit 310 may be mounted on the antenna 810.
  • the network communication unit 330 may be implemented in the controller 821 and / or the network interface 823.
  • the storage unit 340 may be implemented in the memory 822.
  • FIG. 28 is a block diagram illustrating a second example of a schematic configuration of an eNB to which the technology according to the present disclosure may be applied.
  • the eNB 830 includes one or more antennas 840, a base station apparatus 850, and an RRH 860. Each antenna 840 and RRH 860 may be connected to each other via an RF cable. Base station apparatus 850 and RRH 860 can be connected to each other via a high-speed line such as an optical fiber cable.
  • Each of the antennas 840 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 radio signals by the RRH 860.
  • the eNB 830 includes a plurality of antennas 840 as illustrated in FIG. 28, and the plurality of antennas 840 may respectively correspond to a plurality of frequency bands used by the eNB 830, for example. Note that although FIG. 28 illustrates an example in which the eNB 830 includes a plurality of antennas 840, the eNB 830 may include a single antenna 840.
  • the base station device 850 includes a controller 851, a memory 852, a network interface 853, a wireless communication interface 855, and a connection interface 857.
  • the controller 851, the memory 852, and the network interface 853 are the same as the controller 821, the memory 822, and the network interface 823 described with reference to FIG.
  • the wireless communication interface 855 supports a cellular communication method such as LTE or LTE-Advanced, and provides a wireless connection to a terminal located in a sector corresponding to the RRH 860 via the RRH 860 and the antenna 840.
  • the wireless communication interface 855 may typically include a BB processor 856 and the like.
  • the BB processor 856 is the same as the BB processor 826 described with reference to FIG. 27 except that the BB processor 856 is connected to the RF circuit 864 of the RRH 860 via the connection interface 857.
  • the wireless communication interface 855 includes a plurality of BB processors 856 as illustrated in FIG.
  • the plurality of BB processors 856 may respectively correspond to a plurality of frequency bands used by the eNB 830, for example.
  • 28 shows an example in which the wireless communication interface 855 includes a plurality of BB processors 856, the wireless communication interface 855 may include a single BB processor 856.
  • connection interface 857 is an interface for connecting the base station device 850 (wireless communication interface 855) to the RRH 860.
  • the connection interface 857 may be a communication module for communication on the high-speed line that connects the base station apparatus 850 (wireless communication interface 855) and the RRH 860.
  • the RRH 860 includes a connection interface 861 and a wireless communication interface 863.
  • connection interface 861 is an interface for connecting the RRH 860 (wireless communication interface 863) to the base station device 850.
  • the connection interface 861 may be a communication module for communication on the high-speed line.
  • the wireless communication interface 863 transmits and receives wireless signals via the antenna 840.
  • the wireless communication interface 863 may typically include an RF circuit 864 and the like.
  • the RF circuit 864 may include a mixer, a filter, an amplifier, and the like, and transmits and receives wireless signals via the antenna 840.
  • the wireless communication interface 863 includes a plurality of RF circuits 864 as illustrated in FIG. 28, and the plurality of RF circuits 864 may correspond to, for example, a plurality of antenna elements, respectively. 28 illustrates an example in which the wireless communication interface 863 includes a plurality of RF circuits 864, the wireless communication interface 863 may include a single RF circuit 864.
  • the eNB 830 illustrated in FIG. 28 one or more components (for example, the control unit 350) included in the DeNB described with reference to FIG. 4 are implemented in the wireless communication interface 855 and / or the wireless communication interface 863. Also good. Alternatively, at least some of these components may be implemented in the controller 851. As an example, the eNB 830 includes a module including a part (for example, the BB processor 856) or the whole of the wireless communication interface 855 and / or the controller 851, and the one or more components are mounted in the module. Good. In this case, 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.
  • 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 eNB 830, and the wireless communication interface 855 (eg, the BB processor 856) and / or the controller 851 executes the program.
  • the eNB 830, the base station apparatus 850, 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 is provided. May be.
  • a readable recording medium in which the program is recorded may be provided.
  • the wireless communication unit 320 described with reference to FIG. 4 may be implemented in the wireless communication interface 863 (for example, the RF circuit 864). Further, the antenna unit 310 may be mounted on the antenna 840.
  • the network communication unit 330 may be implemented in the controller 851 and / or the network interface 853.
  • the storage unit 340 may be mounted in the memory 852.
  • FIG. 29 is a block diagram illustrating an example of a schematic configuration of a smartphone 900 to which the technology according to the present disclosure can 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 illustrated in FIG. 29 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 although FIG. 29 illustrates an example in which the smartphone 900 includes a plurality of antennas 916, 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 electric power to each block of the smartphone 900 shown in FIG. 29 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.
  • the smartphone 900 illustrated in FIG. 29 one or more components (the control unit 140 or the control unit 240) included in the UE described with reference to FIG. 2 or the RN described with reference to FIG. It may be implemented at interface 912. Alternatively, at least some of these components may be implemented in the processor 901 or the auxiliary controller 919. As an example, 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 or the wireless communication unit 220 described with reference to FIG. 2 or FIG. 3 is implemented in the wireless communication interface 912 (for example, the RF circuit 914). Also good. 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. 30 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. 30 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. Note that FIG. 30 illustrates an example in which the car navigation apparatus 920 includes a plurality of antennas 937, but the car navigation apparatus 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. 30 through a power supply line partially shown by broken lines in the drawing. Further, the battery 938 stores electric power supplied from the vehicle side.
  • 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 wireless communication unit 120 or the wireless communication unit 220 described with reference to FIG. 2 or 3 is implemented in the wireless communication interface 933 (for example, the RF circuit 935). May be. Further, the antenna unit 110 or the antenna unit 210 may be mounted on the antenna 937. Further, 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 control unit 140 or the control unit 240.
  • 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 RN stores a conversion table of address information, and stores transmission destination information or transmission source information of packets transmitted / received between the upstream node of the connection destination and the downstream node under the connection. Convert and relay based on the table. As a result, the RN can aggregate packets transmitted and received by a downstream node connected to the RN into the RN, and the efficiency of information processing regarding the RN is realized.
  • the RN stores an address conversion table.
  • the information amount of the routing table stored in the DeNB, S-GW, and P-GW does not depend on the number of UEs or RNs in the moving cell.
  • these nodes only store entries in the first and second rows of Tables 2A, 2B, and 2C.
  • the number of UEs or RNs in the moving cell does not contribute to an increase in the amount of information managed by the DeNB, S-GW, and P-GW.
  • it is assumed that an RN or UE for which an IPv6 address has been acquired is often connected to a moving cell, so such a property is important. In this way, the efficiency of information processing regarding RN is realized.
  • Storing the address conversion table by the RN also contributes to efficient information processing related to handover.
  • the RN when the RN is handed over between the DeNBs, only the handed over RN needs to perform signaling, and the downstream UE or RN signaling is unnecessary. Therefore, signaling traffic at the time of RN handover does not increase depending on the number of UEs or RNs in the moving cell.
  • the RN since the RN performs signaling independently of the number of UEs connected to the RN at the time of handover of a mobile cell configured with the RN, it is possible to greatly reduce UE signaling. This can be expected to improve the efficiency of radio resources and shorten the delay time until the start of communication. And this can support the reduction in delay in New Radio Network Technology (RAT) in the 5G era, which will be studied in the future.
  • RAT New Radio Network Technology
  • DeNB Downlink Packet Control Function
  • S-GW1 transmits route information to DeNB2 in order to update the route table of DeNB2.
  • the transmitted route information is constant regardless of the number of UEs or RNs connected to the moving cell of the RN to be handed over. Specifically, only information related to entries in the first and second rows of Tables 2A, 2B, and 2C is transmitted. As a result, the number of entries in the routing table updated at the time of RN handover can be suppressed to at most two in each node of P-GW, S-GW, and DeNB.
  • P-GW stores an address conversion table. As a result, an application operating on the RN or UE in the moving cell can wait for the start of communication.
  • the RN can collectively make a request for attaching UEs or RNs connected to the moving cell. Thereby, the number of signaling packets can be reduced.
  • the proposed protocol is a protocol that conforms to the 3GPP architecture. That is, the functional sharing of P-GW, S-GW, MME, eNB, DeNB, RN, and UE is maintained, the interface defined between these nodes is maintained, and the message sequence defined between these nodes is maintained. Is maintained. In the proposed protocol, since the tunneling is not used other than the tunneling used by 3GPP, the header overhead does not increase.
  • nested mobile cells are realized by using DHCP-PD.
  • a UE that has already acquired an IPv6 address can continue communication even after connecting to a moving cell.
  • a control unit that converts and relays transmission destination information or transmission source information of a packet transmitted and received between a connection destination upstream node and a subordinate downstream node based on the first conversion table stored in the storage unit
  • a relay device comprising: (2) The relay device according to (1), wherein the control unit converts the address information of the downstream node from the transmission destination information or the transmission source information.
  • the first conversion table includes information in which address information of the downstream node is associated with address information of the relay device corresponding to the downstream node.
  • the control unit converts the port number of the transmission source information of the packet from the downstream node to the upstream node into the port number of the relay device according to the application operating at the most downstream node.
  • the relay device according to any one of (6).
  • the control unit identifies whether the packet to be relayed is a packet from the upstream node to the downstream node or a packet from the downstream node to the upstream node, any of (1) to (7)
  • the destination information or source information of the packet is converted by a P-GW (Packet Data Network Gateway) based on the second conversion table of address information stored in the P-GW, (1) to (8) )
  • the relay device according to any one of the above.
  • the relay device (10) The relay device according to (9), wherein the second conversion table includes information in which address information of the most downstream node is associated with address information of the relay device corresponding to the most downstream node. (11) The relay device according to any one of (9) and (10), wherein the control unit transmits a message requesting registration of the second conversion table to the P-GW. (12) Each node from the base station to the P-GW stores a routing table in which the transmission destination information and the transfer destination are associated with each other, and relays the packet based on the routing table. (1) to (11) The relay device according to any one of the above.
  • the MME stores a management table in which identification information of a node attached to a network, address information, and address information of an upstream node of the node are associated with each other, according to any one of (1) to (12).
  • Relay device (14) The relay device according to any one of (1) to (13), wherein the control unit receives assignment of an IP address prefix from the P-GW when an IP address is not acquired. (15) The relay device according to any one of (1) to (14), wherein the control unit transmits information indicating a position of a moving cell formed by the relay device. (16) The relay device according to any one of (1) to (15), wherein the control unit controls transmission timing of an attach request related to the downstream node that has been attached.
  • the said control part is a relay apparatus as described in said (16) which transmits the attachment request regarding the one or more said downstream nodes which have been attached to the said upstream node collectively.
  • a control unit that transmits a message requesting registration of the first conversion table to an upstream node that converts transmission destination information or transmission source information of a packet to be relayed based on the first conversion table of stored address information.
  • a terminal device comprising: (19) Storing a first conversion table of address information; Relaying the destination information or source information of a packet transmitted and received between the upstream node of the connection destination and the downstream node under the control by the processor based on the stored first conversion table; Including a communication method.
  • the processor transmits a message requesting registration of the first conversion table to the upstream node that converts the transmission destination information or the transmission source information of the packet to be relayed based on the first conversion table of the stored address information.
  • a message requesting registration of the first conversion table to the upstream node that converts the transmission destination information or the transmission source information of the packet to be relayed based on the first conversion table of the stored address information.
  • UE terminal device RN relay device eNB DeNB base station P-GW, S-GW, MME Core network node 110 Antenna unit 120 Wireless communication unit 130 Storage unit 140 Control unit 210 Antenna unit 220 Wireless communication unit 230 Storage unit 240 Control unit 310 Antenna unit 320 Wireless communication unit 330 Network communication unit 340 Storage unit 350 Control unit 410 Network communication unit 420 Storage unit 430 Control unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (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
　上記非特許文献１などで提案されている技術は、提案されてからまだ日が浅く、リレーノードを活用するための技術として十分であるとはいいがたい。例えば、リレーノードに関する情報処理の効率化も、十分でない技術のひとつである。
　本開示によれば、アドレス情報の第１の変換表を記憶する記憶部と、接続先の上流ノードと配下の下流ノードとの間で送受信されるパケットの送信先情報又は送信元情報を前記記憶部に記憶された前記第１の変換表に基づいて変換して中継する制御部と、を備える中継装置が提供される。
　また、本開示によれば、中継するパケットの送信先情報又は送信元情報を、記憶されたアドレス情報の第１の変換表に基づいて変換する上流ノードに、前記第１の変換表の登録を要求するメッセージを送信する制御部、を備える端末装置が提供される。
　また、本開示によれば、アドレス情報の第１の変換表を記憶することと、接続先の上流ノードと配下の下流ノードとの間で送受信されるパケットの送信先情報又は送信元情報を、記憶された前記第１の変換表に基づいてプロセッサにより変換して中継することと、を含む通信方法が提供される。
　また、本開示によれば、中継するパケットの送信先情報又は送信元情報を、記憶されたアドレス情報の第１の変換表に基づいて変換する上流ノードに、前記第１の変換表の登録を要求するメッセージをプロセッサにより送信すること、を含む通信方法が提供される。
　以上説明したように本開示によれば、リレーノードに関する情報処理を効率化する仕組みが提供される。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、又は上記の効果に代えて、本明細書に示されたいずれかの効果、又は本明細書から把握され得る他の効果が奏されてもよい。
本開示の一実施形態に係るシステムの概略的な構成の一例を示す図である。 同実施形態に係るＵＥの構成の一例を示すブロック図である。 同実施形態に係るＲＮの構成の一例を示すブロック図である。 同実施形態に係るＤｅＮＢの構成の一例を示すブロック図である。 同実施形態に係るコアネットワークノードの構成の一例を示すブロック図である。 同実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。 同実施形態に係るＵＥによる通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。 同実施形態に係るＵＥによる通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。 同実施形態に係るＵＥによる通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。 同実施形態に係るＵＥによる通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。 同実施形態に係るＵＥによる通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。 同実施形態に係るＵＥによる通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。 同実施形態に係るシステムにおいて実行されるハンドオーバ処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行されるハンドオーバ処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行されるアドレス変換表エントリの維持処理の流れの一例を示すシーケンス図である。 次世代ネットワークのアーキテクチャの一例を示す図である。 次世代ネットワークのアーキテクチャの一例を示す図である。 同実施形態に係るＲＮのプロトコルスタックの一例を示す図である。 同実施形態に係るＲＮを経由するＵＥとＰＤＮ上のサーバとの通信におけるプロトコルスタックの一例を示す図である。 サーバの概略的な構成の一例を示すブロック図である。 ｅＮＢの概略的な構成の第１の例を示すブロック図である。 ｅＮＢの概略的な構成の第２の例を示すブロック図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。
　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
　また、本明細書及び図面において、実質的に同一の機能構成を有するノードに、異なる符号を付して区別する場合がある。例えば、実質的に同一の機能構成を有する複数のノードを、必要に応じてＵＥ１、ＵＥ２及びＵＥ３のように区別する。ただし、実質的に同一の機能構成を有する複数のノードの各々を特に区別する必要が無い場合、符号を省略する。例えば、ＵＥ１、ＵＥ２及びＵＥ３を特に区別する必要がない場合には、単にＵＥと称する。このことは、Ｐ－ＧＷ、Ｓ－ＧＷ、ＭＭＥ、ＤｅＮＢ、及びＲＮといった、セルラーネットワークを構成する他のノードに関しても同様である。
　なお、説明は以下の順序で行うものとする。
　　１．はじめに
　　２．構成例
　　　２．１．システムの構成例
　　　２．２．ＵＥの構成例
　　　２．３．ＲＮの構成例
　　　２．４．ＤｅＮＢの構成例
　　　２．５．コアネットワークノードの構成例
　　３．技術的特徴
　　　３．１．接続処理
　　　３．２．通信処理
　　　３．３．ハンドオーバ処理
　　　３．４．アドレス変換表エントリの管理
　　　３．５．変形例
　　　３．６．補足
　　４．ユースケース
　　５．応用例
　　６．まとめ
　＜＜１．はじめに＞＞
　表１に、既存のモビリティサポートプロトコルをまとめた表を示す。モビリティサポートプロトコルは２つの視点で分類可能である。１つ目の視点は、ノード単体の移動を実現する（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.
　＜＜２．構成例＞＞
　＜２．１．システムの構成例＞
　図１は、本開示の一実施形態に係るシステムの概略的な構成の一例を示す図である。図１に示すように、本実施形態に係るシステムは、Ｐ－ＧＷ（PDN（Packet　Data　Network）－Gateway）、Ｓ－ＧＷ（Serving　Gateway）、ＭＭＥ（Mobility　Management　Entity）、ＤｅＮＢ（Donor　evolved　Node　B）、ＲＮ（Relay-Node）及びＵＥ（User　Equipment）を含む。
　ＵＥは、端末装置である。ＲＮは、ＤｅＮＢ等の上流ノードとＵＥ等の下流ノードとの通信を中継する中継装置である。ＲＮは、ＵＥとして動作する場合もある。ＤｅＮＢは、ＲＮが接続される基地局である。Ｓ－ＧＷは、ユーザデータの伝送を行うゲートウェイである。Ｐ－ＧＷは、コアネットワークと外部のＰＤＮとの接点となるゲートウェイであり、ＩＰアドレスの割り当て等を行う通信制御装置である。ＭＭＥは、ＵＥの移動管理、認証、及びユーザデータの転送経路の設定等を行う。
　その他、本実施形態に係るシステムは、ｅＮＢ、ＨＳＳ（Home　Subscriber　Server）、及びＰＣＲＦ（policy　and　charging　rules　function）等のノードを含み得る。ｅＮＢは、ＵＥが接続される基地局である。ＨＳＳは、ユーザ情報を管理するエンティティである。ＰＣＲＦは、ＱｏＳ等のポリシー制御及び課金制御ルールを決定するエンティティである。
　各々のノードを結ぶ実線は有線接続を意味し、破線は無線接続を意味する。図１に示すように、Ｐ－ＧＷは、ＩＰｖ６グローバルインターネット（即ち、ＰＤＮ）に接続される。また、Ｐ－ＧＷとＳ－ＧＷとは、Ｓ５／Ｓ８インタフェースにより接続される。また、Ｓ－ＧＷとＭＭＥとは、Ｓ１１インタフェースにより接続される。また、Ｓ－ＧＷとＤｅＮＢとは、Ｓ１－Ｕインタフェースにより接続される。また、ＭＭＥとＤｅＮＢとは、Ｓ１－ＭＭＥインタフェースにより接続される。また、ＤｅＮＢ同士は、Ｘ２インタフェースにより接続される。また、ＤｅＮＢとＲＮとは、Ｓ１－Ｕインタフェースにより接続される。また、ＲＮとＵＥとは、Ｅ－ＵＴＲＡＮ－Ｕｕインタフェースにより接続される。また、ＲＮ同士は、Ｓ１－Ｕインタフェースにより接続される。
　ＲＮにより形成されるセルは、移動セル又は仮想セルとも称され得る。図１においては、移動セルは破線の矩形で示されている。ＲＮ２により形成される移動セル及びＲＮ３により形成される移動セルのように、移動セル内に他の移動セルが含まれる構造を、入れ子構造とも称する。そして、入れ子構造における包含される側の移動セル、例えばＲＮ２又はＲＮ３により形成される移動セルを、入れ子移動セルとも称する。
　また、よりＰＤＮに近い方向を上流とも称し、よりＵＥに近い方を下流とも称する。例えば、ＲＮ２にとって、ＲＮ１は上流ノードであり、ＵＥ３及びＵＥ４は下流ノードである。
　提案プロトコルは、図１に示すように、例えば携帯電話網をドメイン（ネットワークの範囲）として動作し得る。もちろん、ドメインは他のネットワーク構成であってもよい。
　以下、本実施形態に係るシステムにおいて用いる、ＩＰｖ６アドレスの表記法について説明する。
　Ｐ－ＧＷの下流のインタフェースのＩＰｖ６アドレスをＩＰＤ ＰＧＷと表す。このＩＰｖ６アドレスは予め割り当てられており、不変である。
　Ｓ－ＧＷの上流と下流のインタフェースのＩＰｖ６アドレスを、それぞれＩＰＵ ＳＧＷ、ＩＰＤ ＳＧＷと表す。このＩＰｖ６アドレスは予め割り当てられており、不変である。
　ＤｅＮＢの上流と下流のインタフェースのＩＰｖ６アドレスを、それぞれＩＰＵ ＤｅＮＢ、ＩＰＤ ＤｅＮＢと表す。これらのＩＰｖ６アドレスは予め割り当てられており、不変である。また、ＩＰＤ ＤｅＮＢの上位６４ビット（ｐｒｅｆｉｘ）をＰｒｅｆＤ ＤｅＮＢと表す。
　ＲＮがｅＮＢとして動作する場合の、Ｓ１－Ｕインタフェースで上流のＤｅＮＢと接続するためのＩＰｖ６アドレスをＩＰＵ ＲＮと表す。ＩＰＵ ＲＮの上位６４ビット（ｐｒｅｆｉｘ）は、ＰｒｅｆＤ ＤｅＮＢと等しくなる。また、ＩＰＵ ＲＮの下位６４ビット（インタフェースＩＤ）を、ｉｆｉｄＵ ＲＮと表す。ｉｆｉｄＵ ＲＮは予め割り当てられており、不変である。
　ＲＮがＵＥとして動作する場合の、ＲＮ上のアプリケーションが使用するＩＰｖ６アドレスをＩＰＵＥ ＲＮと表す。ＩＰＵＥ ＲＮの上位６４ビット（ｐｒｅｆｉｘ）をＰｒｅｆＵＥ ＲＮと表し、下位６４ビット（インタフェースＩＤ）をｉｆｉｄＵＥ ＲＮと表す。ＰｒｅｆＵＥ ＲＮ及びｉｆｉｄＵＥ ＲＮは、ＲＮが電源ＯＮになり、最初にＬＴＥネットワークに接続したときに割り当てられ、電源がＯＦＦになるまで変化しない。
　ＲＮが移動するルータとして動作する場合の、下流の移動セルに割り当てるＩＰｖ６プリフィクス（／６４）をＰｒｅｆＤ ＲＮと表す。ＰｒｅｆＤ ＲＮは、ＲＮが電源ＯＮになり、最初にＬＴＥネットワークに接続したときに割り当てられ、電源がＯＦＦになるまで変化しない。ＲＮが、移動するルータとして動作する場合に下流の移動セル内の機器と通信する際に使用するＩＰｖ６アドレスを、ＩＰＤ ＲＮと表す。ＩＰＤ ＲＮの上位６４ビット（ｐｒｅｆｉｘ）は、ＰｒｅｆＤ ＲＮと等しくなる。ＩＰＤ ＲＮの下位６４ビットをｉｆｉｄＤ ＲＮと表す。ｉｆｉｄＤ ＲＮは、予め割り当てられており、不変である。
　ＵＥのＩＰアドレスを、ＩＰＵＥと表す。ＩＰＵＥの上位６４ビット（ｐｒｅｆｉｘ）をＰｒｅｆＵＥと表し、下位６４ビット（インタフェースＩＤ）をｉｆｉｄＵＥと表す。
　＜２．２．ＵＥの構成例＞
　続いて、図２を参照して、本開示の一実施形態に係るＵＥの構成の一例を説明する。図２は、本開示の一実施形態に係るＵＥの構成の一例を示すブロック図である。図２を参照すると、ＵＥは、アンテナ部１１０、無線通信部１２０、記憶部１３０及び制御部１４０を備える。
　（１）アンテナ部１１０
　アンテナ部１１０は、無線通信部１２０により出力される信号を電波として空間に放射する。また、アンテナ部１１０は、空間の電波を信号に変換し、当該信号を無線通信部１２０へ出力する。
　（２）無線通信部１２０
　無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、ｅＮＢ又はＲＮからのダウンリンク信号を受信し、ｅＮＢ又はＲＮへのアップリンク信号を送信する。
　（３）記憶部１３０
　記憶部１３０は、ＵＥの動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　（４）制御部１４０
　制御部１４０は、ＵＥの様々な機能を提供する。ＵＥは、制御部１４０による制御に基づき動作する。制御部１４０による制御に基づくＵＥの動作については、後に詳しく説明する。
　＜２．３．ＲＮの構成例＞
　続いて、図３を参照して、本開示の一実施形態に係るＲＮの構成の一例を説明する。図３は、本開示の一実施形態に係るＲＮの構成の一例を示すブロック図である。図３を参照すると、ＲＮは、アンテナ部２１０、無線通信部２２０、記憶部２３０及び制御部２４０を備える。
　（１）アンテナ部２１０
　アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。
　（２）無線通信部２２０
　無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、上流のＤｅＮＢ又は他のＲＮからのダウンリンク信号を受信し、下流のＵＥ又はＲＮに中継する。また、例えば、無線通信部２２０は、下流のＵＥ又はＲＮからアップリンク信号を受信し、上流のＤｅＮＢ又は他のＲＮに中継する。
　（３）記憶部２３０
　記憶部２３０は、ＲＮの動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　（４）制御部２４０
　制御部２４０は、ＲＮの様々な機能を提供する。ＲＮは、制御部２４０による制御に基づき動作する。制御部２４０による制御に基づくＲＮの動作については、後に詳しく説明する。
　＜２．４．ＤｅＮＢの構成例＞
　続いて、図４を参照して、本開示の一実施形態に係るＤｅＮＢの構成の一例を説明する。図４は、本開示の一実施形態に係るＤｅＮＢの構成の一例を示すブロック図である。図４を参照すると、ＤｅＮＢは、アンテナ部３１０、無線通信部３２０、ネットワーク通信部３３０、記憶部３４０及び制御部３５０を備える。
　（１）アンテナ部３１０
　アンテナ部３１０は、無線通信部３２０により出力される信号を電波として空間に放射する。また、アンテナ部３１０は、空間の電波を信号に変換し、当該信号を無線通信部３２０へ出力する。
　（２）無線通信部３２０
　無線通信部３２０は、信号を送受信する。例えば、無線通信部３２０は、下流のＵＥ又はＲＮへのダウンリンク信号を送信し、下流のＵＥ又はＲＮからのアップリンク信号を受信する。
　（３）ネットワーク通信部３３０
　ネットワーク通信部３３０は、情報を送受信する。例えば、ネットワーク通信部３３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、他のＤｅＮＢ及びコアネットワークノードを含む。
　（４）記憶部３４０
　記憶部３４０は、ＤｅＮＢの動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　（５）制御部３５０
　制御部３５０は、ＤｅＮＢの様々な機能を提供する。ＤｅＮＢは、制御部３５０による制御に基づき動作する。制御部３５０による制御に基づくＤｅＮＢの動作については、後に詳しく説明する。
　＜２．５．コアネットワークノードの構成例＞
　続いて、図５を参照して、本開示の一実施形態に係るコアネットワークノードの構成の一例を説明する。ここでのコアネットワークノードとは、例えばＰ－ＧＷ、Ｓ－ＧＷ及びＭＭＥ等を含む。図５は、本開示の一実施形態に係るコアネットワークノードの構成の一例を示すブロック図である。図５を参照すると、コアネットワークノードは、ネットワーク通信部４１０、記憶部４２０及び制御部４３０を備える。
　（１）ネットワーク通信部４１０
　ネットワーク通信部４１０は、情報を送受信する。例えば、ネットワーク通信部４１０は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、他のコアネットワークノード、ＰＤＮ、及びＤｅＮＢを含む。
　（２）記憶部４２０
　記憶部４２０は、コアネットワークノードの動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　（３）制御部４３０
　制御部４３０は、コアネットワークノードの様々な機能を提供する。コアネットワークノードは、制御部４３０による制御に基づき動作する。制御部４３０による制御に基づくコアネットワークノードの動作については、後に詳しく説明する。
　＜＜３．技術的特徴＞＞
　＜３．１．接続処理＞
　まず、本実施形態に係るシステムの、接続処理に関する技術的特徴を説明する。ここでの接続処理とは、ＵＥ又はＲＮがＤｅＮＢ又はＲＮにより接続する処理を指す。
　　・経路表
　基地局からＰ－ＧＷまでの各ノード（例えば、ＤｅＮＢ、Ｓ－ＧＷ、及びＰ－ＧＷ）は、送信先情報と転送先とを対応付けた経路表を記憶する。例えば、経路表は、終点ＩＰアドレス（即ち、宛先ＩＰアドレス）と転送先のＧＴＰトンネルとを対応付けたエントリを含む。各ノードは、経路表に基づいて、受信したパケットを適切なＧＴＰトンネルを用いて中継する。
　一例として、各ノードが記憶し得る経路表の例を下記に示す。
Figure JPOXMLDOC01-appb-T000002
Figure JPOXMLDOC01-appb-T000003
Figure JPOXMLDOC01-appb-T000004
　　・管理表
　ＭＭＥは、ネットワークにアタッチしたノード（ＵＥ又はＲＮ）の識別情報、アドレス情報、及び当該ノードの上流ノード（即ち、接続先のノード）のアドレス情報を対応付けた管理表を記憶する。ＭＭＥは、管理表により、移動セルに接続するすべてのＲＮ及びＵＥを把握することができる。
　一例として、ＭＭＥ１が記憶し得る管理表の例を下記に示す。
Figure JPOXMLDOC01-appb-T000005
　　・変換表
　ＲＮは、アドレス情報の変換表（第１の変換表）を記憶する。この変換表は、下流ノードのアドレス情報と当該下流ノードに対応するＲＮのアドレス情報とを対応付けた情報を含む。なお、アドレス情報は、ＩＰアドレス及び／又はポート番号を含む情報である。ここでのＩＰアドレスは、例えばＩＰｖ６アドレスである。ＲＮは、この変換表を用いることで、ＲＮの下流ノード宛てのパケットを、ＲＮに集約させることが可能となる。
　Ｐ－ＧＷも、アドレス情報の変換表（第２の変換表）を記憶する。この変換表は、最下流ノード（即ち、ＵＥ又はＵＥとして動作するＲＮ）のアドレス情報と、当該最下流ノードに対応するＲＮのアドレス情報とを対応付けた情報を含む。Ｐ－ＧＷは、この変換表を用いることで、ＲＮの下流ノード宛てのパケットを、ＲＮに集約させることが可能となる。
　ＵＥは、接続先の上流ノードであるＲＮにおける変換表の登録を要求するメッセージを送信する。また、ＲＮも、Ｐ－ＧＷ又は上流にＲＮが存在する場合はＲＮに、変換表の登録を要求するメッセージを送信する。本メッセージを、以下では、ＮＡＴ登録リクエスト（NAT（Network　Address　Translation）　Registration　Request）とも称する。ＲＮ及びＰ－ＧＷは、本メッセージに基づいて、変換表を適切に更新することが可能となる。ＮＡＴ登録リクエストへの回答として、ＮＡＴ登録応答（NAT　Registration　Ack）が回答される。
　一例として、各ＲＮが記憶し得る変換表の例を下記に示す。
Figure JPOXMLDOC01-appb-T000006
Figure JPOXMLDOC01-appb-T000007
Figure JPOXMLDOC01-appb-T000008
Figure JPOXMLDOC01-appb-T000009
　　・ＤＨＣＰ－ＰＤ
　ＲＮは、ＩＰアドレスを未取得の場合、Ｐ－ＧＷからＩＰアドレスのプリフィックス部分の割り当てを受ける。このことは、ＲＮがＤｅＮＢに接続する場合も移動セルに接続する場合も同様である。ＲＮは、Ｐ－ＧＷとの間で、ＤＨＣＰ－ＰＤ（Ｐｒｅｆｉｘ　ｄｅｌｅｇａｔｉｏｎ）を実行してもよい。これにより、ＲＮは、プリフィクスの割り当てを受けることができる。なお、ＤＨＣＰ－ＰＤに関しては、「O.　Troan　and　R.　Droms.　IPv6　Prefix　Options　for　Dynamic　Host　Configuration　Protocol　(DHCP)　version　6,　December　2003.　RFC　3633.」において詳細に説明されている。
　ＲＮは、割り当てられたプリフィックス（例えば、ＩＰｖ６　Ｐｒｅｆｉｘ／５６）の一部となるプリフィックス（例えば、ＩＰｖ６　Ｐｒｅｆｉｘ／６４）を、配下のノードに割り当て得る。これにより、ＲＮ及びＲＮの配下のノードが共通するプリフィックスを有することとなるので、経路表の簡略化が可能となる。
　　・位置付けを示す情報
　ＲＮは、ＲＮが形成する移動セルの位置付けを示す情報を送信する。この情報は、例えば、ＲＮが最上流であることを示す情報（例えばＭＣＴＯＰ　Ｆｌａｇ＝ＯＮ）、又は入れ子移動セルを形成すること（例えば、ＭＣＮＥＳＴ　Ｆｌａｇ＝ＯＮ）を示す情報である。この情報は、例えばアタッチリクエストに含めて送信される。
　　・アタッチリクエストの送信
　ＲＮは、アタッチしてきた下流ノードに関するアタッチリクエストの送信タイミングを制御する。例えば、ＲＮは、アタッチしてきたひとつ以上の下流ノードに関するアタッチリクエストをまとめて上流ノードに送信する。送信タイミングの制御方法は任意である。例えば、所定時間ごとに周期的送信したり、下流ノードからのアタッチリクエストを受信したときから所定時間待機後に送信したりすることが考えられる。これにより、ＲＮは、ＲＮの下流にノードが接続するごとにアタッチリクエストを送信するのではなく、複数台のノードに関するアタッチリクエストを一度に送信することが可能となる。これにより、ネットワークの通信負荷が軽減される。
　以下、図１に示したネットワーク構成例を前提に、接続処理の流れを詳細に説明する。
　（１．１）ＩＰｖ６アドレスを未取得のＲＮによるＤｅＮＢへの接続処理
　本節では、ＩＰｖ６アドレスを未取得のＲＮによるＤｅＮＢへの接続処理について説明する。一例として、ＤｅＮＢ１の近傍でＲＮ１の電源がオンになった場合を想定する。この場合の、ＩＰｖ６アドレスを未取得のＲＮ１によるＤｅＮＢ１への接続処理の一例を、図６を参照して説明する。
　図６は、本実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＲＮ１、ＤｅＮＢ１、ＭＭＥ１、Ｓ－ＧＷ１、及びＰ－ＧＷ１が関与する。ＲＮ１は、移動セルを形成する。
　まず、ＲＮ１は、ＤｅＮＢ１と無線回線を確立する（ステップＳ１０２）。
　次いで、ＲＮ１は、リンクローカルの全てのルータマルチキャストアドレス宛に、ＲＳ（Router　Solicitation）を送信する（ステップＳ１０４）。
　次に、ＤｅＮＢ１は、このＲＳを受信し、ＲＮ１のリンクローカルのＩＰｖ６アドレス宛に、ＲＡ（Router　Advertisement）を送信する（ステップＳ１０６）。このＲＡは、ＤｅＮＢ１の下流インタフェースに割り当てられたＩＰｖ６アドレスのプレフィクスである、ＰｒｅｆＤ ＤｅＮＢ１を含む。
　次いで、ＲＮ１は、このＲＡを受信し、ＰｒｅｆＤ ＤｅＮＢ１と自身の上流インタフェースのＩＤであるｉｆｉｄＵ ＲＮ１から、ＩＰｖ６アドレスであるＩＰＵ ＲＮ１を生成する（ステップＳ１０８）。ＩＰＵ ＲＮ１は、ＲＮ１がＤｅＮＢ１との間にＧＴＰ（GPRS（General　Packet　Radio　Service）　Tunneling　Protocol）トンネルを確立する際に使用される。
　次に、ＲＮ１は、ＤｅＮＢ１にアタッチリクエスト（Attach　Request）を送信する（ステップＳ１１０）。このアタッチリクエストは、ＲＮ１の識別子であるＩＤＲＮ１、ＩＰＵ ＲＮ１、及びＲＮ１が移動セルの最上流のＲＮであることを示す情報（たとえばＭＣＴＯＰ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＤｅＮＢ１は、このアタッチリクエストを受信すると、受信したアタッチリクエストに自身の下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＤｅＮＢ１を追加して、ＭＭＥ１に転送する（ステップＳ１１２）。
　次に、ＭＭＥ１は、このアタッチリクエストを受信すると、Ｓ－ＧＷ１にデフォルトベアラ生成リクエスト（Create　Default　Bearer　Request）を送信する（ステップＳ１１４）。このデフォルトベアラ生成リクエストは、ＩＤＲＮ１、ＩＰＵ ＲＮ１、ＩＰＤ ＤｅＮＢ１、及びＲＮ１が移動セルの最上流のＲＮであることを示す情報（たとえばＭＣＴＯＰ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、Ｓ－ＧＷ１は、このデフォルトベアラ生成リクエストを受信すると、Ｐ－ＧＷ１に転送する（ステップＳ１１６）。
　次に、Ｐ－ＧＷ１は、このデフォルトベアラ生成リクエストを受信すると、ＰｒｅｆＵＥ ＲＮ１及びｉｆｉｄＵＥ ＲＮ１を割当てる（ステップＳ１１８）。詳しくは、Ｐ－ＧＷ１は、自身が持つＩＰｖ６アドレススペースから、／６４のＩＰｖ６プリフィクスであるＰｒｅｆＵＥ ＲＮ１を割り当てる。また、Ｐ－ＧＷ１は、ＲＮ１がＵＥとして動作する際のインタフェースＩＤであるｉｆｉｄＵＥ ＲＮ１を生成する。また、Ｐ－ＧＷ１は、Ｓ－ＧＷ１との間にＧＴＰトンネルを構成し、ＰｒｅｆＵＥ ＲＮ１の転送先をこのＧＴＰトンネルに関連付け、経路表に登録する（表２Ａの１行目のエントリに相当）。このＧＴＰトンネルの端点は、Ｐ－ＧＷ１の下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＰＧＷ１、及びＳ－ＧＷ１の上流インタフェースのＩＰｖ６アドレスであるＩＰＵ ＳＧＷ１である。
　次いで、Ｐ－ＧＷ１は、Ｓ－ＧＷ１にデフォルトベアラ生成レスポンス（Create　Default　Bearer　Response）を送信する（ステップＳ１２０）。このデフォルトベアラ生成レスポンスは、ＩＤＲＮ１、ＩＰＤ ＰＧＷ１、ＰｒｅｆＵＥ ＲＮ１、ｉｆｉｄＵＥ ＲＮ１、及びＩＰＤ ＤｅＮＢ１を含む。
　次に、Ｓ－ＧＷ１は、このデフォルトベアラ生成レスポンスを受信すると、受信したデフォルトベアラ生成レスポンスにＩＰＤ ＳＧＷ１を追加して、ＭＭＥ１に転送する（ステップＳ１２２）。また、Ｓ－ＧＷ１は、Ｐ－ＧＷ１との間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＵ ＳＧＷ１及びＩＰＤ ＰＧＷ１である。さらに、Ｓ－ＧＷ１は、ＤｅＮＢ１との間にＧＴＰトンネルを構成し、ＰｒｅｆＵＥ ＲＮ１の転送先をこのＧＴＰトンネルに関連付け、経路表に登録する（表２Ｂの１行目のエントリに相当）。このＧＴＰトンネルの端点は、Ｓ－ＧＷ１の下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＳＧＷ１、及びＤｅＮＢ１の上流インタフェースのＩＰｖ６　アドレスであるＩＰＵ ＤｅＮＢ１である。
　次いで、ＭＭＥ１は、このデフォルトベアラ生成レスポンスを受信すると、ＲＮ１を自身の管理表に登録する（表３の１行目のエントリに相当）。次に、ＭＭＥ１は、ＤｅＮＢ１にアタッチアクセプト（Attach　Accept）を送信する（ステップＳ１２４）。このアタッチアクセプトは、ＩＤＲＮ１、ＩＰＤ ＳＧＷ１、ＰｒｅｆＵＥ ＲＮ１、及びｉｆｉｄＵＥ ＲＮ１を含む。
　次いで、ＤｅＮＢ１は、このアタッチアクセプトを受信すると、ＲＮ１に転送する（ステップＳ１２６）。また、ＤｅＮＢ１は、Ｓ－ＧＷ１との間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＤｅＮＢ１の上流インタフェースのＩＰｖ６アドレスであるＩＰＵ ＤｅＮＢ１、及びＳ－ＧＷ１の下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＳＧＷ１である。さらに、ＤｅＮＢ１は、ＲＮ１との間にＧＴＰトンネルを構成し、ＰｒｅｆＵＥ ＲＮ１の転送先をこのＧＴＰトンネルに関連付け、経路表に登録する（表２Ｃの１行目のエントリに相当）。このＧＴＰトンネルの端点は、ＤｅＮＢ１の下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＤｅＮＢ１、及びＲＮ１の上流インタフェースのＩＰｖ６アドレスであるＩＰＵ ＲＮ１である。ＲＮ１は、このアタッチアクセプトを受信して、ｉｆｉｄＵＥ ＲＮ１を取得する。
　以上の処理の結果、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成される。
　次に、ＲＮ１は、ＵＥとして動作するためのＩＰｖ６アドレスであるＩＰＵＥ ＲＮ１を取得するために、ＩＰｖ６の規定に従ってＰ－ＧＷ１にＲＳ（Router　Solicitation）を送信する（ステップＳ１２８）。
　次いで、Ｐ－ＧＷ１は、このＲＳを受信し、ＲＮ１にＲＡ（Router　Advertisement）を返送する（ステップＳ１３０）。このＲＡは、ＰｒｅｆＵＥ ＲＮ１を含む。
　次に、ＲＮ１は、このＲＡを受信し、ＰｒｅｆＵＥ ＲＮ１を取得する。そして、ＲＮ１は、このプリフィクスとｉｆｉｄＵＥ ＲＮ１から、ＩＰＵＥ ＲＮ１を生成する（ステップＳ１３２）。ここで、ＩＰＵＥ ＲＮ１は、ＲＮ１上のアプリケーションが通信するときに使用するＩＰｖ６アドレスである。
　次いで、ＲＮ１は、下流インタフェースのプリフィクスを取得するため、Ｐ－ＧＷ１との間でＤＨＣＰ－ＰＤを実行する（ステップＳ１３４）。これにより、Ｐ－ＧＷ１は、プリフィクスＰｒｅｆＤ ＲＮ１をＲＮ１に割り当てる。
　ＤＨＣＰ－ＰＤの結果、ＲＮ１は、ＰｒｅｆＤ ＲＮ１を取得する。そして、ＲＮ１は、ＰｒｅｆＤ ＲＮ１と下流インタフェースのインタフェースＩＤであるｉｆｉｄＤ ＲＮ１とから、ＩＰｖ６アドレスＩＰＤ ＲＮ１を生成し、下流のインタフェースに割り当てる（ステップＳ１３６）。
　他方、Ｐ－ＧＷ１は、ＰｒｅｆＤ ＲＮ１の経路をＳ－ＧＷ１へのトンネルに関連付け、経路表に登録する（表２Ａの２行目のエントリに相当）。次に、Ｐ－ＧＷ１は、Ｓ－ＧＷ１にルートセットアップ（Route　Setup）を送信する（ステップＳ１３８）。このルートセットアップは、ＰｒｅｆＵＥ ＲＮ１及びＰｒｅｆＤ ＲＮ１を含む。
　次いで、Ｓ－ＧＷ１は、ルートセットアップを受信すると、ＰｒｅｆＤ ＲＮ１の経路をＤｅＮＢ１へのトンネルに関連付け、経路表に登録する（表２Ｂの２行目のエントリに相当）。次に、Ｓ－ＧＷ１は、ＤｅＮＢ１にルートセットアップを転送する（ステップＳ１４０）。ＤｅＮＢ１は、ルートセットアップを受信すると、ＰｒｅｆＤ ＲＮ１の経路をＲＮ１へのトンネルに関連付け、経路表に登録する（表２Ｃの２行目のエントリに相当）。
　以上説明した処理の結果、Ｐ－ＧＷ１、Ｓ－ＧＷ１、及びＤｅＮＢ１は、それぞれ表２Ａ、表２Ｂ、及び表２Ｃに示す経路表を記憶することとなる。一方、ＭＭＥ１は、表３に示す管理表を記憶することとなる。ＭＭＥは、移動セル内に接続するすべてのＲＮを、管理表により把握する。
　（１．２）ＩＰｖ６アドレスを未取得のＵＥによるＲＮへの接続処理
　本節では、ＩＰｖ６アドレスを未取得のＵＥによるＲＮへの接続処理について説明する。例えば、上記（１．１）節で説明した処理後に、ＲＮ１の近傍でＵＥ１の電源がオンになった場合を想定する。この場合の、ＩＰｖ６アドレスを未取得のＵＥ１によるＲＮ１への接続処理の一例を、図７を参照して説明する。
　図７は、本実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１、ＲＮ１、ＤｅＮＢ１、及びＭＭＥ１が関与する。図７に示す通り、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成されている。
　まず、ＵＥ１は、ＲＮ１と無線回線を確立する（ステップＳ２０２）。
　次いで、ＵＥ１は、アタッチリクエストをＲＮ１に送信する（ステップＳ２０４）。このアタッチリクエストは、ＵＥ１の識別子であるＩＤＵＥ１を含む。ＲＮ１は、例えばハッシュ関数を利用してＩＤＵＥ１からＵＥ１のインタフェースＩＤであるｉｆｉｄＵＥ１を生成する。
　次に、ＲＮ１は、ＵＥ１にアタッチアクセプトを送信する（ステップＳ２０６）。このアタッチアクセプトは、ｉｆｉｄＵＥ１を含む。
　次いで、ＵＥ１は、このアタッチアクセプトを受信して、ｉｆｉｄＵＥ１を取得する。次に、ＵＥ１は、ＲＮ１にＲＳを送信する（ステップＳ２０８）。
　次に、ＲＮ１は、このＲＳを受信すると、ＵＥ１にＰｒｅｆＤ ＲＮ１を含むＲＡを送信する（ステップＳ２１０）。
　次いで、ＵＥ１は、ＲＡを受信し、ＰｒｅｆＤ ＲＮ１及びｉｆｉｄＵＥ１から、自身のＩＰｖ６アドレスであるＩＰＵＥ１を生成する（ステップＳ２１２）。
　次に、ＲＮ１は、ある程度の時間（例えば１秒）待ち、その間にＲＮ１の下流に接続したＵＥに関するアタッチリクエストをまとめてＤｅＮＢ１に送信する（ステップＳ２１４）。これにより、ＲＮ１は、ＲＮ１の下流にＵＥが接続するごとにアタッチリクエストを送信するのではなく、複数台のＵＥに関するアタッチリクエストを一度に送信することが可能となる。このアタッチリクエストは、ＲＮ１に接続したＵＥの識別子（例えばＩＤＵＥ１）、ＩＰｖ６アドレス（例えばＩＰＵＥ１）、ＩＰＤ ＲＮ１、及び移動セルへのＵＥ接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＤｅＮＢ１は、このアタッチリクエストを受信すると、ＭＭＥ１に転送する（ステップＳ２１６）。
　次に、ＭＭＥ１は、このアタッチリクエストを受信すると、ＲＮ１の下流に接続したＵＥ（例えばＵＥ１）の情報をマッピング表に登録し（表３の２行目のエントリに相当）、ＤｅＮＢ１にアタッチアクセプトを送信する（ステップＳ２１８）。このアタッチアクセプトはＲＮ１　に接続したＵＥ　の識別子（例えばＩＤＵＥ１）　を含む。
　次いで、ＤｅＮＢ１は、このアタッチアクセプトを受信すると、ＲＮ１に転送する（ステップＳ２２０）。
　以上説明した処理の結果、Ｐ－ＧＷ１、Ｓ－ＧＷ１、及びＤｅＮＢ１が記憶する経路表に変更はない。即ち、Ｐ－ＧＷ、Ｓ－ＧＷ、及びＤｅＮＢが記憶する経路表の情報量は、移動セル内のＵＥの数に依存しない。一方、ＭＭＥは、移動セル内に接続している全てのＵＥを、管理表により把握する。
　（１．３）ＩＰｖ６アドレスを取得済みのＵＥによるＲＮへの接続処理
　本節では、ＩＰｖ６アドレスを取得済みのＵＥによるＲＮへの接続処理について説明する。一例として、他のｅＮＢに接続していたＵＥ２が、ＲＮ１が提供する移動セルに移動してきた場合を想定する。より具体的には、上記（１．２）節で説明した処理後に、ＲＮ１にＩＰＵＥ２というＩＰｖ６アドレスを有しているＵＥ２が接続する場合を想定する。なお、ＩＰＵＥ２は、ＰｒｅｆＤ ＲＮ１には属さない。この場合の、ＩＰｖ６アドレスを取得済みのＵＥ２によるＲＮ１への接続処理の一例を、図８を参照して説明する。
　図８は、本実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ２、ＲＮ１、ＤｅＮＢ１、ＭＭＥ１、Ｓ－ＧＷ１、及びＰ－ＧＷ１が関与する。図８に示す通り、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成されている。
　まず、ＵＥ２は、ＲＮ１と無線回線を確立する（ステップＳ３０２）。
　次いで、ＵＥ２は、ＲＮ１にアタッチリクエストを送信する（ステップＳ３０４）。このアタッチリクエストは、ＵＥ２の識別子であるＩＤＵＥ２及びＩＰＵＥ２を含む。ＲＮ１は、このアタッチリクエストを受信すると、ＩＰＵＥ２がＰｒｅｆＤ ＲＮ１に属さないので、ＵＥ２がＩＰｖ６アドレスを有したまま他のｅＮＢ又はＲＮからＲＮ１の下流に移動してきたことを検知する。そこで、ＲＮ１は、ＩＰＵＥ２のプリフィクスであるＰｒｅｆＵＥ２及びｉｆｉｄＤ ＲＮ１から、ＩＰｖ６アドレスＩＰ２Ｄ ＲＮ１を生成し、下流インタフェースに割り当てる。
　次に、ＲＮ１は、アタッチアクセプトをＵＥ２に送信する（ステップＳ３０６）。このアタッチアクセプトは、ＩＰＵＥ２のインタフェースＩＤであるｉｆｉｄＵＥ２を含む。
　次いで、ＵＥ２は、このアタッチアクセプトを受信し、ｉｆｉｄＵＥ２を取得する。次に、ＵＥ２は、ＲＮ１にＲＳを送信する（ステップＳ３０８）。
　次いで、ＲＮ１は、このＲＳを受信すると、ＲＡをＵＥ２に送信する（ステップＳ３１０）。このＲＡは、ＰｒｅｆＵＥ２、及び移動セルへの接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次に、このＲＡを受信したＵＥ２は、ＰｒｅｆＵＥ２及びｉｆｉｄＵＥ２からＩＰＵＥ２を生成し、ＩＰＵＥ２が継続して使用可能であることを確認する（ステップＳ３１２）。
　次いで、ＵＥ２は、ＲＮ１にＮＡＴ登録リクエストを送信する（ステップＳ３１４）。このＮＡＴ登録リクエストは、ＩＰＵＥ２及び現在通信で使用しているポート番号のリスト（ここでは説明を簡単にするため、通信中のポートは１つであるものとし、Ｐｔ１ＵＥ２と表す）を含む。
　次に、ＲＮ１は、このＮＡＴ登録リクエストを受信すると、Ｐｔ１ＵＥ２に対して新たなポート番号Ｐｔ１ＲＮ１ ＵＥ２を割当て、自身のアドレス変換表に新たなエントリ（表５の１行目のエントリ）を加える。次いで、ＲＮ１は、ＮＡＴ登録リクエストをＰ－ＧＷ１に送信する（ステップＳ３１６）。このＮＡＴ登録リクエストは、ＩＰＵＥ２、Ｐｔ１ＵＥ２、ＩＰＵＥ ＲＮ１、及びＰｔ１ＲＮ１ ＵＥ２を含む。
　次に、Ｐ－ＧＷ１は、このＮＡＴ登録リクエストを受信すると、自身のアドレス変換表に新たなエントリ（表４の１行目のエントリ）を加える。次いで、Ｐ－ＧＷ１は、ＲＮ１にＮＡＴ登録応答を送信する（ステップＳ３１８）。
　次に、ＲＮ１は、このＮＡＴ登録応答を受信すると、ＵＥ２に転送する（ステップＳ３２０）。
　次いで、ＲＮ１は、ＲＡの送信後、ある程度の時間（例えば１秒）待ち、その間にＲＮ１の下流に接続したＵＥに関するアタッチリクエストを、まとめてＤｅＮＢ１に送信する（ステップＳ３２２）。これにより、ＲＮ１は、ＲＮ１の下流にＵＥが接続するごとにアタッチリクエストを送信するのではなく、複数台のＵＥに関するアタッチリクエストを一度に送信することが可能となる。このアタッチリクエストは、ＲＮ１に接続したＵＥの識別子（例えばＩＤＵＥ２）、ＩＰｖ６アドレス（例えばＩＰＵＥ２）、ＩＰＤ ＲＮ１、及び移動セルへの接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次に、ＤｅＮＢ１は、このアタッチリクエストを受信すると、パススイッチリクエスト（Path　Switch　Request）をＭＭＥ１に送信する（ステップＳ３２４）。このパススイッチリクエストは、ＲＮ１に接続したＵＥの識別子（例えばＩＤＵＥ２）、ＩＰｖ６アドレス（例えばＩＰＵＥ２）、ＩＰＤ ＲＮ１、及び移動セルへの接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＭＭＥ１は、ＲＮ１に接続したＵＥ（例えばＵＥ２）が既にＩＰｖ６アドレスを有しているので、既に自身の管理表にこのＵＥに関するエントリを記憶している。そこで、ＭＭＥ１は、このパススイッチリクエストを受信すると、ＭＭＥ１の管理表においてＲＮ１の下流に接続したＵＥのエントリ（例えばＵＥ２のエントリ（表３の３行目のエントリ））の上流ノードの欄を更新する。次に、ＭＭＥ１は、Ｓ－ＧＷ１にベアラ変更リクエスト（Modify　Bearer　Request）を送信する（ステップＳ３２６）。このベアラ変更リクエストは、ＲＮ１の下流に接続したＵＥのＩＤ及びＩＰｖ６アドレス（例えば、ＩＤＵＥ２及びＩＰＵＥ２）を含む。
　次に、Ｓ－ＧＷ１は、このベアラ変更リクエストを受信すると、Ｐ－ＧＷ１に転送する（ステップＳ３２８）。
　次いで、Ｐ－ＧＷ１は、このベアラ変更リクエストを受信すると、ＲＮ１の下流に接続したＵＥ（例えばＵＥ２）にＧＴＰトンネルが確立されていればそれを解放する。次に、Ｐ－ＧＷ１は、ベアラ変更レスポンス（Modify　Bearer　Response）をＳ－ＧＷ１に送信する（ステップＳ３３０）。このベアラ変更レスポンスは、ＲＮ１の下流に接続したＵＥの識別子（例えばＩＤＵＥ２）を含む。
　次いで、Ｓ－ＧＷ１は、このベアラ変更レスポンスを受信すると、ＭＭＥ１に転送する（ステップＳ３３２）。
　次に、ＭＭＥ１は、このベアラ変更レスポンスを受信すると、パススイッチリクエスト応答（Path　Switch　Request　Ack）をＤｅＮＢ１に送信する（ステップＳ３３４）。このパススイッチリクエスト応答は、ＲＮ１の下流に接続したＵＥの識別子（例えばＩＤＵＥ２）を含む。
　次いで、ＤｅＮＢ１は、このパススイッチリクエスト応答を受信すると、アタッチアクセプトをＲＮ１に送信する（ステップＳ３３６）。このアタッチアクセプトは、ＲＮ１の下流に接続したＵＥの識別子（例えばＩＤＵＥ２）を含む。
　以上説明した処理の結果、Ｐ－ＧＷ１、Ｓ－ＧＷ１、及びＤｅＮＢ１が記憶する経路表に変化はない。即ち、Ｐ－ＧＷ、Ｓ－ＧＷ、及びＤｅＮＢが記憶する経路表の情報量は、移動セル内のＵＥの数に依存しない。一方、アドレス取得済のＵＥが移動セルに接続すると、上流のＲＮとＰ－ＧＷにはこのＵＥにおいて通信中のポートの数と同数のアドレス変換表エントリが追加される。Ｐ－ＧＷ１、及びＲＮ１が記憶するアドレス変換表は、それぞれ表４及び表５に示した通りである。また、ＭＭＥ１は移動セル内に接続しているすべてのＵＥを、管理表により把握する。
　（１．４）ＩＰｖ６アドレスを未取得のＲＮによる移動セルへの接続処理
　本節では、ＩＰｖ６アドレスを未取得のＲＮによる移動セルへの接続処理について説明する。例えば、上記（１．３）節で説明した処理後に、ＲＮ１の近傍でＲＮ２の電源がオンになった場合を想定する。この場合の、ＩＰｖ６アドレスを未取得のＲＮ２による、ＲＮ１が提供する移動セルへの接続処理の一例を、図９を参照して説明する。
　図９は、本実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＲＮ２、ＲＮ１、ＤｅＮＢ１、ＭＭＥ１、及びＰ－ＧＷ１が関与する。図９に示す通り、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成されている。
　まず、ＲＮ２は、ＲＮ１と無線回線を確立する（ステップＳ４０２）。
　次いで、ＲＮ２は、リンクローカルの全てのルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ４０４）。
　次に、ＲＮ１は、このＲＳを受信すると、ＲＮ２のリンクローカルアドレス宛にＲＡを送信する（ステップＳ４０６）。このＲＡは、ＰｒｅｆＤ ＲＮ１、及びＲＮ１が移動セル内に存在する旨を表す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＲＮ２は、このＲＡを受信すると、ＰｒｅｆＤ ＲＮ１及び自身の上流インタフェースのＩＤであるｉｆｉｄＵ ＲＮ２から、ＩＰｖ６アドレスであるＩＰＵ ＲＮ２を生成する（ステップＳ４０８）。後述するように、ＩＰＵ ＲＮ２は、ＲＮ２上のアプリケーションが使用するＩＰｖ６アドレスであるＩＰＵＥ ＲＮ２と等しくなる。
　次に、ＲＮ２は、ＲＮ１にアタッチリクエストを送信する（ステップＳ４１０）。このアタッチリクエストは、ＲＮ２の識別子であるＩＤＲＮ２、ＩＰＵ ＲＮ２、及びＲＮ２が入れ子状態であることを示す情報（例えばＭＣＮＥＳＴ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＲＮ１は、このアタッチリクエストを受信すると、ＩＰＤ ＲＮ１を加えてＤｅＮＢ１に転送する（ステップＳ４１２）。
　次に、ＤｅＮＢ１は、このアタッチリクエストを受信すると、ＭＭＥ１に転送する（ステップＳ４１４）。
　次いで、ＭＭＥ１は、このアタッチリクエストを受信すると、ＲＮ２の情報を管理表に登録する（表３の４行目のエントリに相当）。そして、ＭＭＥ１は、ＤｅＮＢ１にアタッチアクセプトを送信する（ステップＳ４１６）。このアタッチアクセプトは、ＩＤＲＮ２を含む。
　次に、ＤｅＮＢ１は、このアタッチアクセプトを受信すると、ＲＮ１に転送する（ステップＳ４１８）。
　次いで、ＲＮ１は、このアタッチアクセプトを受信すると、ＲＮ２に転送する（ステップＳ４２０）。このアタッチアクセプトは、ｉｆｉｄＵ ＲＮ２を含む。
　次に、ＲＮ２は、アタッチアクセプトを受信し、ｉｆｉｄＵ ＲＮ２を取得する。次いで、ＲＮ２は、ＲＮ１にＲＳを送信する（ステップＳ４２２）。
　次に、ＲＮ１は、このＲＳを受信すると、ＲＮ２にＲＡを送信する（ステップＳ４２４）。このＲＡは、ＰｒｅｆＤ ＲＮ１及びＩＰＤ ＰＧＷ１を含む。
　次いで、ＲＮ２は、このＲＡを受信すると、ＰｒｅｆＤ ＲＮ１及びｉｆｉｄＵ ＲＮ２からＩＰＵＥ ＲＮ２を生成する（ステップＳ４２６）。ＩＰＵＥ ＲＮ２は、ＲＮ２がＵＥとして動作する際、アプリケーションが使用するＩＰｖ６アドレスである。結果的に、ＩＰＵ ＲＮ２とＩＰＵＥ ＲＮ２とは等しくなる。
　次に、ＲＮ２は、下流インタフェースのプリフィクスを取得するため、Ｐ－ＧＷ１との間でＤＨＣＰ－ＰＤを実行する（ステップＳ４２８）。その際、ＲＮ２は、入れ子状態であることを示す情報（例えばＭＣＮＥＳＴ　Ｆｌａｇ＝ＯＮ）が、Ｐ－ＧＷ１に送信される。Ｐ－ＧＷ１は、ＲＮ２の下流インタフェースのプリフィクスとしてＰｒｅｆＤ ＲＮ２を割り当てる。Ｐ－ＧＷ１は、ＲＮ２が入れ子状態であることが分かるので、経路情報を変更しない。
　ＤＨＣＰ－ＰＤの結果、ＲＮ２は、ＰｒｅｆＤ ＲＮ２を取得する。そして、ＲＮ２は、ＰｒｅｆＤ ＲＮ２及び下流インタフェースのＩＤであるｉｆｉｄＤ ＲＮ２から、ＩＰＤ ＲＮ２を生成し、下流のインタフェースに割り当てる（ステップＳ４３０）。
　以上説明した処理の結果、Ｐ－ＧＷ１、Ｓ－ＧＷ１、及びＤｅＮＢ１が記憶する経路表に変化はない。即ち、Ｐ－ＧＷ、Ｓ－ＧＷ、及びＤｅＮＢが記憶する経路表の情報量は、移動セル内に接続する入れ子のＲＮの数に依存しない。一方、ＭＭＥは、移動セル内に接続したすべてのＲＮを、管理表により把握する。
　（１．５）ＩＰｖ６アドレスを未取得のＵＥによる入れ子移動セルへの接続処理
　本節では、ＩＰｖ６アドレスを未取得のＵＥによる入れ子移動セルへの接続処理について説明する。例えば、上記（１．４）節で説明した処理後に、ＲＮ２の近傍でＵＥ３の電源がオンになった場合を想定する。この場合の、ＩＰｖ６アドレスを未取得のＵＥ３による、ＲＮ２が提供する入れ子移動セルへの接続処理の一例を、図１０を参照して説明する。
　図１０は、本実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ３、ＲＮ２、ＲＮ１、ＤｅＮＢ１、及びＭＭＥ１が関与する。図１０に示す通り、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成されている。
　まず、ＵＥ３は、ＲＮ２と無線回線を確立する（ステップＳ５０２）。
　次いで、ＵＥ３は、アタッチリクエストをＲＮ２に送信する（ステップＳ５０４）。このアタッチリクエストは、ＵＥ３の識別子であるＩＤＵＥ３を含む。
　次に、ＲＮ２は、例えばハッシュ関数を用いてＩＤＵＥ３からｉｆｉｄＵＥ３を生成し、これを含むアタッチアクセプトをＵＥ３に送信する（ステップＳ５０６）。
　次いで、ＵＥ３は、このアタッチアクセプトを受信し、ｉｆｉｄＵＥ３を取得する。次に、ＵＥ３は、ＲＮ２にＲＳを送信する（ステップＳ５０８）。
　次に、ＲＮ２は、このＲＳを受信すると、ＵＥ３にＰｒｅｆＤ ＲＮ２を含むＲＡを送信する（ステップＳ５１０）。
　次いで、ＵＥ３は、このＲＡを受信し、ＰｒｅｆＤ ＲＮ２及びｉｆｉｄＵＥ３からＩＰｖ６アドレスであるＩＰＵＥ３を生成する（ステップＳ５１２）。
　次に、ＲＮ２は、ある程度の時間（例えば１秒）待ち、その間にＲＮ２の下流に接続したＵＥに関するアタッチリクエストをまとめてＲＮ１に送信する（ステップＳ５１４）。これにより、ＲＮ２は、ＲＮ２の下流にＵＥが接続するごとにアタッチリクエストを送信するのではなく、複数台のＵＥに関するアタッチリクエストを一度に送信することが可能となる。このアタッチリクエストは、ＲＮ２に接続したＵＥの識別子（例えばＩＤＵＥ３）、ＩＰｖ６アドレス（例えばＩＰＵＥ３）、ＩＰＤ ＲＮ２、及び移動セルへのＵＥ接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＲＮ１は、このアタッチリクエストを受信すると、ＤｅＮＢ１に転送する（ステップＳ５１６）。
　次に、ＤｅＮＢ１は、このアタッチリクエストを受信すると、ＭＭＥ１に転送する（ステップＳ５１８）。
　次いで、ＭＭＥ１は、このアタッチリクエストを受信すると、ＲＮ２の下流に接続したＵＥ（例えばＵＥ３）の情報を管理表に登録し（表３の５行目のエントリに相当）、ＤｅＮＢ１にアタッチアクセプトを送信する（ステップＳ５２０）。このアタッチアクセプトは、ＲＮ２に接続したＵＥの識別子（例えばＩＤＵＥ３）を含む。
　次に、ＤｅＮＢ１は、このアタッチアクセプトを受信すると、ＲＮ１に転送する（ステップＳ５２２）。
　次いで、ＲＮ１は、このアタッチアクセプトを受信すると、ＲＮ２に転送する（ステップＳ５２４）。
　以上説明した処理の結果、Ｐ－ＧＷ１、Ｓ－ＧＷ１、及びＤｅＮＢ１の記憶する経路表に変更はない。即ち、Ｐ－ＧＷ、Ｓ－ＧＷ、及びＤｅＮＢが記憶する経路表の情報量は、移動セル内のＵＥの数に依存しない。一方、ＭＭＥは移動セル内に接続しているすべてのＵＥを、管理表により把握する。
　（１．６）ＩＰｖ６アドレスを取得済みのＵＥによる入れ子移動セルへの接続処理
　本節では、ＩＰｖ６アドレスを取得済みのＵＥによる入れ子移動セルへの接続処理について説明する。例えば、上記（１．５）節で説明した処理後に、他のｅＮＢ又はＲＮの配下でＩＰＵＥ４というＩＰｖ６アドレスを得たＵＥ４が、ＲＮ２が提供する入れ子移動セルに移動してきた場合を想定する。この場合の、ＩＰｖ６アドレスを取得済みのＵＥ４による、ＲＮ２が提供する入れ子移動セルへの接続処理の一例を、図１１を参照して説明する。
　図１１は、本実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ４、ＲＮ２、ＲＮ１、ＤｅＮＢ１、ＭＭＥ１、Ｓ－ＧＷ１、及びＰ－ＧＷ１が関与する。図１１に示す通り、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成されている。
　まず、ＵＥ４は、ＲＮ２と無線回線を確立する（ステップＳ６０２）。
　次いで、ＵＥ４は、アタッチリクエストをＲＮ２に送信する（ステップＳ６０４）。このアタッチリクエストは、ＵＥ４の識別子であるＩＤＵＥ４及びＩＰＵＥ４を含む。ＲＮ２は、このアタッチリクエストを受信すると、ＩＰＵＥ４がＰｒｅｆＤ ＲＮ２には属さないので、ＵＥ４がＩＰｖ６アドレスを有したまま他のｅＮＢ又はＲＮからＲＮ２の下流に移動してきたことを検知する。そこで、ＲＮ２は、ＩＰＵＥ４のプリフィクスであるＰｒｅｆＵＥ４及び自身の下流インタフェースのＩＤであるｉｆｉｄＤ ＲＮ２から、ＩＰｖ６アドレスＩＰ２Ｄ ＲＮ２を生成し、下流インタフェースに割り当てる。
　次に、ＲＮ２は、ＵＥ２にアタッチアクセプトを送信する（ステップＳ６０６）。このアタッチアクセプトは、ＩＰＵＥ４のインタフェースＩＤであるｉｆｉｄＵＥ４、ＩＰＤ ＲＮ２、及び移動セルへの接続であることを示す情報（例えばＭＣ　ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＵＥ４は、このアタッチアクセプトを受信し、ｉｆｉｄＵＥ４を取得する。次に、ＵＥ４は、ＲＮ２にＲＳを送信する（ステップＳ６０８）。
　次に、ＲＮ２は、このＲＳを受信すると、ＵＥ４にＰｒｅｆＵＥ４を含むＲＡを送信する（ステップＳ６１０）。
　次いで、ＵＥ４は、ＲＡを受信すると、ＰｒｅｆＵＥ４及びｉｆｉｄＵＥ４からＩＰＵＥ４を生成し、ＩＰＵＥ４が引き続き使用可能であることを確認する（ステップＳ６１２）。
　次に、ＵＥ４は、移動セル内への接続であることを認識し、ＲＮ２にＮＡＴ登録リクエストを送信する（ステップＳ６１４）。このＮＡＴ登録リクエストは、ＩＰＵＥ４及び現在通信しているポート番号のリスト（ここでは説明を簡単にするため、通信中のポートはＰｔ１ＵＥ４の１つのみとする）を含む。
　次いで、ＲＮ２は、このＮＡＴ登録リクエストを受信すると、Ｐｔ１ＵＥ４に対して新たなポート番号であるＰｔ１ＲＮ２ ＵＥ４を割当て、自身のアドレス変換表に新たなエントリ（表６の１行目のエントリ）を加える。次に、ＲＮ２は、ＮＡＴ登録リクエストをＲＮ１に送信する（ステップＳ６１６）。このＮＡＴ登録リクエストは、ＩＰＵＥ４、Ｐｔ１ＵＥ４、ＩＰＵＥ ＲＮ２、及びＰｔ１ＲＮ２ ＵＥ４を含む。
　次に、ＲＮ１は、このＮＡＴ登録リクエスト　を受信すると、Ｐｔ１ＲＮ２ ＵＥ４に対して新たなポート番号であるＰｔ１ＲＮ１ ＵＥ４を割当て、自身のアドレス変換表に新たなエントリ（表５の２行目のエントリ）を加える。次に、ＲＮ１は、ＮＡＴ登録リクエストをＰ－ＧＷ１に送信する（ステップＳ６１８）。このＮＡＴ登録リクエストは、ＩＰＵＥ４、Ｐｔ１ＵＥ４、ＩＰＵＥ ＲＮ１、及びＰｔ１ＲＮ１ ＵＥ４を含む。
　次いで、Ｐ－ＧＷ１は、このＮＡＴ登録リクエストを受信すると、自身のアドレス変換表に新たなエントリ（表４の２行目のエントリ）を加える。次に、Ｐ－ＧＷ１は、ＲＮ１にＮＡＴ登録応答を送信する（ステップＳ６２０）。
　次に、ＲＮ１は、このＮＡＴ登録応答を受信すると、ＲＮ２に転送する（ステップＳ６２２）。
　次いで、ＲＮ２は、このＮＡＴ登録応答を受信すると、ＵＥ４に転送する（ステップＳ６２４）。
　次に、ＲＮ２は、ＲＡの送信後ある程度の時間（例えば１秒）待ち、その間にＲＮ２の下流に接続したＵＥに関するアタッチリクエストをまとめてＲＮ１に送信する（ステップＳ６２６）。これにより、ＲＮ２は、ＲＮ２の下流にＵＥが接続するごとにアタッチリクエストを送信するのではなく、複数台のＵＥに関するアタッチリクエストを一度に送信することが可能となる。このアタッチリクエストは、ＲＮ２に接続したＵＥの識別子（例えばＩＤＵＥ４）、ＩＰｖ６アドレス（例えばＩＰＵＥ４）、ＩＰＤ ＲＮ２、及び移動セルへのＵＥ接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、ＲＮ１は、このアタッチリクエストを受信すると、ＤｅＮＢ１に転送する（ステップＳ６２８）。
　次に、ＤｅＮＢ１は、このアタッチリクエストを受信すると、パススイッチリクエストをＭＭＥ１に送信する（ステップＳ６３０）。このパススイッチリクエストは、ＲＮ２に接続したＵＥの識別子（例えばＩＤＵＥ４）、ＩＰｖ６　アドレス（例えばＩＰＵＥ４）、ＩＰＤ ＲＮ２、及び移動セルへのＵＥ接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　ここで、ＲＮ２の下流に移動したＵＥは既にＩＰｖ６アドレスを有しているので、ＭＭＥ１は移動したＵＥに関する情報をすでに管理表に登録済みである。そこで、ＭＭＥ１は、このパススイッチリクエストを受信すると、ＲＮ２に接続したＵＥに関する管理表のエントリ（例えばＵＥ４に関するエントリ（表３の６行目のエントリ））の上流ノードの欄をＩＰＤ ＲＮ２に変更し、Ｓ－ＧＷ１にベアラ変更リクエストを送信する（ステップＳ６３２）。このベアラ変更リクエストは、ＲＮ２に接続したＵＥの識別子（例えばＩＤＵＥ４）、ＩＰｖ６アドレス（例えばＩＰＵＥ４）、及び移動セルへのＵＥ接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、Ｓ－ＧＷ１は、このベアラ変更リクエストを受信すると、Ｐ－ＧＷ１に転送する（ステップＳ６３４）。
　次に、Ｐ－ＧＷ１は、このベアラ変更リクエストを受信すると、ＲＮ２の下流に接続したＵＥ（例えばＵＥ４）に関するＧＴＰトンネルが確立されている場合、その解放処理を行う。そして、Ｐ－ＧＷ１は、Ｓ－ＧＷ１にベアラ変更レスポンスを送信する（ステップＳ６３６）。このベアラ変更レスポンスは、ＲＮ２の下流に移動したＵＥの識別子（例えばＩＤＵＥ４）を含む。
　次いで、Ｓ－ＧＷ１は、このベアラ変更レスポンスを受信すると、ＭＭＥ１に転送する（ステップＳ６３８）。
　次に、ＭＭＥ１は、このベアラ変更レスポンスを受信すると、ＤｅＮＢ１にパススイッチリクエスト応答を送信する（ステップＳ６４０）。このパススイッチリクエスト応答は、ＲＮ２の下流に移動したＵＥの識別子（例えばＩＤＵＥ４）を含む。
　次いで、ＤｅＮＢ１は、このパススイッチリクエスト応答を受信すると、ＲＮ１にアタッチアクセプトを送信する（ステップＳ６４２）。このアタッチアクセプトは、ＲＮ２の下流に移動したＵＥの識別子（例えばＩＤＵＥ４）を含む。
　次に、ＲＮ１は、このアタッチアクセプトを受信すると、ＲＮ２に転送する（ステップＳ６４４）。
　以上説明した処理の結果、Ｐ－ＧＷ１、Ｓ－ＧＷ１、及びＤｅＮＢ１の記憶する経路表に変更はない。即ち、Ｐ－ＧＷ、Ｓ－ＧＷ、及びＤｅＮＢの記憶する経路表の情報量は、移動セル内のＵＥの数に依存しない。一方、アドレス取得済のＵＥが入れ子の移動セルに接続すると、上流のＲＮ及びＰ－ＧＷには、このＵＥにおいて通信中のポートの数と同数のアドレス変換表のエントリが追加される。また、ＭＭＥ１は、移動セル内に接続しているすべてのＲＮ及びＵＥを、管理表により把握する。
　（１．７）ＩＰｖ６アドレスを取得済みのＲＮによる移動セルへの接続処理
　本節では、ＩＰｖ６アドレスを取得済みのＲＮによる移動セルへの接続処理について説明する。例えば、上記（１．６）節で説明した処理後に、他のｅＮＢ又はＲＮの配下でＩＰｖ６アドレスを得たＲＮ３が、ＲＮ１が提供する移動セルに移動してきた場合を想定する。この場合の、ＩＰｖ６アドレスを取得済みのＲＮ３による、ＲＮ１が提供する移動セルへの接続処理の一例を、図１２を参照して説明する。
　なお、ＲＮ３は、アプリケーションが使用するＩＰｖ６アドレスであるＩＰＵＥ ＲＮ３、及び下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＲＮ３を取得済であるものとする。また、ＲＮ３のさらに下流にはＵＥ５が接続しているものとする。ＵＥ５は、ＩＰｖ６アドレスとしてＩＰＵＥ５を有しているものとする。ＵＥ５は、すでにＲＮ３への接続処理を行ったため、ＲＮ３はＵＥ５の識別子であるＩＤＵＥ５及びＩＰｖ６アドレスであるＩＰＵＥ５を把握している。
　図１２は、本実施形態に係るシステムにおいて実行される接続処理の流れの一例を示すシーケンス図である。本シーケンスには、ＲＮ３、ＲＮ１、ＤｅＮＢ１、ＭＭＥ１、Ｓ－ＧＷ１、及びＰ－ＧＷ１が関与する。図１２に示す通り、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成されている。
　まず、ＲＮ３は、ＲＮ１と無線回線を確立する（ステップＳ７０２）。
　次いで、ＲＮ３は、リンクローカルの全てのルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ７０４）。このＲＳは、ＩＰＵＥ ＲＮ３を含む。
　次に、ＲＮ１は、このＲＳを受信すると、ＲＮ３がすでにＩＰｖ６アドレスであるＩＰＵＥ ＲＮ３を有していることを認識し、ＲＮ３にＩＰＵＥ ＲＮ３のプリフィクスであるＰｒｅｆＵＥ ＲＮ３及び移動セルへの接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含むＲＡを送信する（ステップＳ７０６）。また、ＲＮ１は、ＰｒｅｆＵＥ ＲＮ３及び自身の下流インタフェースのＩＤであるｉｆｉｄＤ ＲＮ１から、ＩＰｖ６アドレスであるＩＰ３Ｄ ＲＮ１を生成し、これを下流インタフェースに割り当てる。
　次いで、ＲＮ３は、このＲＡを受信し、ＰｒｅｆＵＥ ＲＮ３及び自身の上流インタフェースのＩＤであるｉｆｉｄＵ ＲＮ３から、ＩＰｖ６アドレスであるＩＰＵ ＲＮ３を生成する（ステップＳ７０８）。
　次に、ＲＮ３は、ＲＮ１にアタッチリクエストを送信する（ステップＳ７１０）。このアタッチリクエストは、ＲＮ３の識別子であるＩＤＲＮ３及びＩＰＵＥ ＲＮ３を含む。
　次いで、ＲＮ１は、このアタッチリクエストを受信すると、ＲＮ３にアタッチアクセプトを送信する（ステップＳ７１２）。このアタッチアクセプトは、ＩＰＵＥ ＲＮ３のインタフェースＩＤであるｉｆｉｄＵＥ ＲＮ３を含む。
　次に、ＲＮ３は、このアタッチアクセプトを受信し、ｉｆｉｄＵＥ ＲＮ３を取得する。次いで、ＲＮ３は、ＲＮ１にＲＳを送信する（ステップＳ７１４）。
　次いで、ＲＮ１は、このＲＳを受信すると、ＲＮ３にＲＡを送信する（ステップＳ７１６）。このＲＡは、ＩＰＵＥ ＲＮ３のプリフィクスであるＰｒｅｆＵＥ ＲＮ３を含む。
　次に、ＲＮ３は、このＲＡを受信すると、ＰｒｅｆＵＥ ＲＮ３及びｉｆｉｄＵＥ ＲＮ３からＩＰＵＥ ＲＮ３を生成し、ＩＰＵＥ ＲＮ３が引き続き使用可能であることを確認する（ステップＳ７１８）。
　次いで、ＲＮ３は、ＲＮ１にＮＡＴ登録リクエストを送信する（ステップＳ７２０）。このＮＡＴ登録リクエストは、ＩＰＵＥ ＲＮ３、ＲＮ３上のアプリケーションが通信で使用しているポート番号（説明を簡単にするため、ポート番号はＰｔ１ＲＮ３の１つのみとする）、ＩＰＵＥ５、及びＵＥ５が通信で使用しているポート番号のリスト（説明を簡単にするため、ポート番号はＰｔ１ＵＥ５の１つのみとする）を含む。
　次に、ＲＮ１は、このＮＡＴ登録リクエストを受信すると、Ｐｔ１ＲＮ３及びＰｔ１ＵＥ５の各々に対して、新たなポート番号としてそれぞれＰｔ１ＲＮ１ ＲＮ３及びＰｔ１ＲＮ１ ＵＥ５を割当て、自身のアドレス変換表に新たなエントリ（表５の３行目のエントリ及び４行目のエントリ）を追加する。次に、ＲＮ１は、Ｐ－ＧＷ１にＮＡＴ登録リクエストを送信する（ステップＳ７２２）。このＮＡＴ登録リクエストは、ＩＰＵＥ ＲＮ３、Ｐｔ１ＲＮ３、ＩＰＵＥ ＲＮ１、Ｐｔ１ＲＮ１ ＲＮ３、ＩＰＵＥ５、Ｐｔ１ＵＥ５、及びＰｔ１ＲＮ１ ＵＥ５を含む。
　次いで、Ｐ－ＧＷ１は、このＮＡＴ登録リクエストを受信すると、自身のアドレス変換表に新たなエントリ（表４の３行目のエントリ及び４行目のエントリ）を追加する。次に、Ｐ－ＧＷ１は、ＲＮ１にＮＡＴ登録応答を送信する（ステップＳ７２４）。
　次に、ＲＮ１は、このＮＡＴ登録応答を受信すると、ＲＮ３に転送する（ステップＳ７２６）。
　次いで、ＲＮ１は、ＲＡの送信後、ある程度の時間（例えば１秒）待ち、その間にＲＮ１の下流に接続した入れ子移動セル内のＲＮ及びＵＥに関するアタッチリクエストをまとめてＤｅＮＢ１に送信する（ステップＳ７２８）。これにより、ＲＮ１は、ＲＮ１の下流に入れ子の移動セルが接続するごとにアタッチリクエストを送信するのではなく、複数台の入れ子移動セルに関するアタッチリクエストを一度に送信することが可能となる。このアタッチリクエストは、ＲＮ１に接続した入れ子移動セル内のＲＮ及びＵＥの識別子（例えばＩＤＲＮ３、ＩＤＵＥ５）、ＩＰｖ６アドレス（例えばＩＰＵＥ ＲＮ３、ＩＰＵＥ５）、ＩＰＤ ＲＮ１、及び移動セルへの接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次に、ＤｅＮＢ１は、このアタッチリクエストを受信すると、パススイッチリクエストをＭＭＥ１に転送する（ステップＳ７３０）。このパススイッチリクエストは、ＲＮ１に接続した入れ子移動セル内のＲＮ及びＵＥの識別子（例えばＩＤＲＮ３、ＩＤＵＥ５）、ＩＰｖ６アドレス（例えばＩＰＵＥ ＲＮ３、ＩＰＵＥ５）、ＩＰＤ ＲＮ１、及び移動セルへの接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　ここで、ＲＮ１の下流に移動したＲＮ及びＵＥは、既にＩＰｖ６アドレスを有しているので、ＭＭＥ１は、移動したＲＮ及び入れ子移動セルに接続しているＵＥに関する情報をすでに管理表に登録済みである。そこで、ＭＭＥ１は、このパススイッチリクエストを受信すると、ＲＮ１の下流に接続した入れ子移動セル内のＲＮ及びＵＥに関する管理表エントリの上流ノードの欄を更新する（例えばＲＮ３及びＵＥ５の欄（表３の７行目のエントリ及び８行目のエントリ））。次に、ＭＭＥ１は、Ｓ－ＧＷ１にベアラ変更リクエストを送信する（ステップＳ７３２）。このベアラ変更リクエストは、ＲＮ１に接続した入れ子移動セル内のＲＮ及びＵＥの識別子（例えばＩＤＲＮ３、ＩＤＵＥ５）、ＩＰｖ６アドレス（例えばＩＰＵＥ ＲＮ３、ＩＰＵＥ５）、及び移動セルへの接続であることを示す情報（例えばＭＣ　Ｆｌａｇ＝ＯＮ）を含む。
　次いで、Ｓ－ＧＷ１は、このベアラ変更リクエストを受信すると、Ｐ－ＧＷ１に転送する（ステップＳ７３４）。
　次に、Ｐ－ＧＷ１は、このベアラ変更リクエストを受信すると、ＲＮ１の下流に接続した入れ子移動セルの最上流のＲＮ（例えばＲＮ３）に関するＧＴＰトンネルが存在する場合は解放処理を行う。次に、Ｐ－ＧＷ１は、Ｓ－ＧＷ１にベアラ変更レスポンスを送信する（ステップＳ７３６）。このベアラ変更レスポンスは、ＲＮ１の下流に接続した入れ子移動セル内のＲＮ及びＵＥの識別子（例えばＩＤＲＮ３及びＩＤＵＥ５）を含む。
　次いで、Ｓ－ＧＷ１は、このベアラ変更レスポンスを受信すると、ＭＭＥ１に転送する（ステップＳ７３８）。
　次に、ＭＭＥ１は、このベアラ変更レスポンスを受信すると、ＤｅＮＢ１にパススイッチリクエスト応答を送信する（ステップＳ７４０）。このパススイッチリクエスト応答は、ＲＮ１の下流に接続した入れ子移動セル内のＲＮ及びＵＥの識別子（例えばＩＤＲＮ３及びＩＤＵＥ５）を含む。
　次いで、ＤｅＮＢ１は、このパススイッチリクエスト応答を受信すると、ＲＮ１にアタッチアクセプトを送信する（ステップＳ７４２）。このアタッチアクセプトは、ＲＮ１の下流に接続した入れ子移動セル内のＲＮ及びＵＥの識別子（例えばＩＤＲＮ３及びＩＤＵＥ５）を含む。
　以上説明した処理の結果、Ｐ－ＧＷ１、Ｓ－ＧＷ１、及びＤｅＮＢ１が記憶する経路表に変化はない。即ち、Ｐ－ＧＷ、Ｓ－ＧＷ、及びＤｅＮＢの記憶する経路表の情報量は、移動セル内に接続するＲＮ及びＵＥの数に依存しない。一方、アドレス取得済の移動セルが入れ子として移動セル内に接続すると、上流のＲＮ及びＰ－ＧＷには、接続した入れ子移動セルにおいて通信中のポートの数と同数のアドレス変換表エントリが追加される。また、ＭＭＥは、移動セル内に接続したすべてのＲＮ及びＵＥに関するエントリを記憶する。
　＜３．２．通信処理＞
以下では、本実施形態に係るシステムの、通信処理に関する技術的特徴を説明する。ここでの通信処理とは、上記接続処理を終えたＲＮ又はＵＥが、インターネット上のアプリケーションと通信する処理を指す。
　・アドレス変換
　ＲＮは、接続先の上流ノードと配下の下流ノードとの間で送受信されるパケットの送信先情報又は送信元情報を、記憶された変換表に基づいて変換して中継する。これにより、ＲＮは、ＲＮの下流ノード宛てのパケットを、ＲＮに集約させることが可能となる。
　より詳しくは、ＲＮは、パケットヘッダに含まれる送信先情報又は送信元情報のうち前記下流ノードの前記アドレス情報を変換する。なお、送信元情報は、例えば始点ＩＰアドレス及び始点ポート番号を含み、送信先情報は、例えば終点ＩＰアドレス及び終点ポート番号を含む。ＲＮは、中継するパケットが上流ノードから下流ノードへのパケットであるか、下流ノードから上流ノードへのパケットであるかを識別する。例えば、この識別は、送信先情報に基づいて行われ得る。そして、ＲＮは、この識別結果に基づいて、中継処理を制御する。
　例えば、ＲＮは、下流から上流へ中継されるパケットに関しては、送信元情報を、下流ノードのアドレス情報から、当該下流ノードに対応するＲＮのアドレス情報に変換する。具体的には、ＲＮは、下流ノードから上流ノードへのパケットの送信元情報のＩＰアドレスを、ＲＮのＩＰアドレスに変換する。また、ＲＮは、下流ノードから上流ノードへのパケットの送信元情報のポート番号を、最下流ノード（即ち、送信元終端のＵＥ又はＲＮ）で動作するアプリケーションに応じたＲＮのポート番号に変換する。これにより、ＲＮに接続する下流ノードから送信されたパケットへの返信を、ＲＮに到達させることが可能となる。
　例えば、ＲＮは、上流から下流へ中継されるパケットに関しては、送信先情報を、下流ノードに対応するＲＮのアドレス情報から、当該下流ノードのアドレス情報に変換する。具体的には、ＲＮは、上流ノードから下流ノードへのパケットの送信先情報のＩＰアドレスを、下流ノードのＩＰアドレスに変換する。また、ＲＮは、上流ノードから下流ノードへのパケットの前記送信先情報のポート番号を、最下流ノード（即ち、送信先終端のＵＥ又はＲＮ）で動作するアプリケーションに応じた下流ノードのポート番号に変換する。これにより、ＲＮに接続する下流ノードへ送信されたパケットを、当該下流ノードに到達させることが可能となる。
　Ｐ－ＧＷは、送受信されるパケットの送信先情報又は送信元情報を、記憶された変換表に基づいて変換して中継する。より詳しくは、Ｐ－ＧＷは、ＵＥへのパケットの送信先情報を、ＵＥの上流のＲＮのアドレス情報に変換する。また、Ｐ－ＧＷは、ＵＥからのパケットの、ＲＮのアドレス情報に変換された送信元情報を、ＵＥのアドレス情報に変換する。これにより、Ｐ－ＧＷは、ＲＮに接続する下流ノードにより送受信されるパケットを、ＲＮに集約させることが可能となる。
　以下、図１に示したネットワーク構成例を前提に、通信処理の流れを詳細に説明する。
　（２．１）ＵＥ１の通信処理
　以下では、ＩＰｖ６アドレスを未取得のＵＥがＲＮに接続した後に行われる通信処理について説明する。一例として、ＵＥ１の通信処理を説明する。
　（２．１．１）ＵＥ１が通信を開始する場合
　本節では、ＵＥ１が通信を開始する場合の通信処理について説明する。例えば、上記（１．７）節で説明した処理後に、ＵＥ１のアプリケーション（ポート番号：Ｐｔ１ＵＥ１）が、インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）と通信を開始する場合を想定する。以下、図１３を参照しながら、具体的に説明する。
　図１３は、本実施形態に係るＵＥ１による通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。各々のパケットヘッダには、パケットの始点ＩＰアドレスｓｒｃＩＰ及び始点ポート番号ｓｒｃＰｏｒｔ、並びに終点ＩＰアドレスｄｓｔＩＰ及び終点ポート番号ｄｓｔＰｏｒｔが含まれる。本図では、中継途中に書き替えられる部分に下線が付されている。
　ＵＥ１は、ＲＮ１へ、図１３（ａ）に示すヘッダを持つパケットを送信する。ＲＮ１はこのパケットを受信すると、下流から上流への通信であることを認識する。そして、ＲＮ１は、自身が記憶するアドレス変換表（表５）内に、下流ＩＰアドレス及び下流ポート番号が、このパケットの始点ＩＰアドレス及び始点ポート番号と一致するエントリがあるかを検索する。この時点では該当するエントリは存在しないので、ＲＮ１は、新たなポート番号ＰｔＲＮ１ ＵＥ１を生成し、自身のアドレス変換表に新たなエントリ（表５の５行目のエントリ）を加える。
　このエントリは、ＲＮ１が下流から上流にパケットを転送する際に始点ＩＰアドレス及び始点ポート番号がＩＰＵＥ１及びＰｔ１ＵＥ１である場合は、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ１に書き換えることを意味する。ＲＮ１は、本エントリに基づいた書き替えを行う。この結果、ＲＮ１が下流から上流へ中継したあとのパケットヘッダは、図１３（ｂ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によってＰ－ＧＷ１に到達し、さらにインターネット内の経路制御によってインターネット上のアプリケーションに到達する。
　インターネット上のアプリケーションが上記パケットを受信し、返信する際のパケットヘッダは、図１３（ｃ）に示す内容になる。このパケットは、インターネット内の経路制御によってＰ－ＧＷ１に到達し、さらにＬＴＥ内の経路制御によってＲＮ１に到達する。ＲＮ１は、このパケットを受信すると、上流から下流への通信であることを認識する。そして、ＲＮ１は、自身が記憶するアドレス変換表内に、上流ＩＰアドレス及び上流ポート番号がパケットの終点ＩＰアドレス及び終点ポート番号に一致するエントリがあるかを検索する。この結果、表５の５行目のエントリが見つかる。
　このエントリは、ＲＮ１が上流から下流にパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ１である場合は、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ１及びＰｔ１ＵＥ１に書き換えることを意味する。ＲＮ１は、本エントリに基づいた書き替えを行う。この結果、ＲＮ１が上流から下流へ中継したあとのパケットヘッダは、図１３（ｄ）に示す内容になる。このパケットは、ＵＥ１上のアプリケーションに到達する。
　（２．１．２）ＵＥ１が通信開始待ちをする場合
　本節では、ＵＥ１が通信開始待ちをする場合の通信処理について説明する。例えば、上記（２．１．１）節で説明した処理後に、ＵＥ１上のアプリケーション（ポート番号：Ｐｔ２ＵＥ１）が、インターネット上のアプリケーションからの通信開始待ちになった場合を想定する。以下、図１４を参照しながら、具体的に説明する。
　図１４は、本実施形態に係るＵＥ１による通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。各々のパケットヘッダには、パケットの始点ＩＰアドレスｓｒｃＩＰ及び始点ポート番号ｓｒｃＰｏｒｔ、並びに終点ＩＰアドレスｄｓｔＩＰ及び終点ポート番号ｄｓｔＰｏｒｔが含まれる。本図では、中継途中に書き替えられる部分に下線が付されている。
　ＵＥ１は、ＲＮ１にＮＡＴ登録リクエストを送信する。このＮＡＴ登録リクエストは、ＩＰＵＥ１及びＰｔ２ＵＥ１を含む。ＲＮ１は、このＮＡＴ登録リクエストを受信すると、新たなポート番号Ｐｔ２ＲＮ１ ＵＥ１を生成し、自身のアドレス変換表に新たなエントリ（表５の６行目のエントリ）を加える。
　このエントリは、ＲＮ１が上流から下流にパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１である場合、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ１及びＰｔ２ＵＥ１に書き換えることを意味する。また、このエントリは、ＲＮ１が下流から上流にパケットを転送する際に始点ＩＰアドレス及び始点ポート番号がＩＰＵＥ１及びＰｔ２ＵＥ１である場合、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１に書き換えることを意味する。
　次に、ＲＮ１は、Ｐ－ＧＷ１にＮＡＴ登録リクエストを送信する。このＮＡＴ登録リクエストは、ＩＰＵＥ ＲＮ１、Ｐｔ２ＲＮ１ ＵＥ１、ＩＰＵＥ１、及びＰｔ２ＵＥ１を含む。Ｐ－ＧＷ１は、このＮＡＴ登録リクエストを受信すると、自身のアドレス変換表に新たなエントリ（表４の５行目のエントリ）を加える。
　このエントリは、Ｐ－ＧＷ１が上流（即ち、ＰＤＮ）から下流（即ち、ＣＮ）にパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ１及びＰｔ２ＵＥ１である場合、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１に書き換えることを意味する。また、このエントリは、Ｐ－ＧＷ１が下流から上流にパケットを転送する際に始点ＩＰアドレス及び始点ポート番号がＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１である場合、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ１及びＰｔ２ＵＥ１に書き換えることを意味する。
　インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）は、ＵＥ１上で動作するアプリケーション（ポート番号：Ｐｔ２ＵＥ１）と通信を開始する場合、図１４（ａ）に示すヘッダを持つパケットを送信する。このパケットはインターネット内の経路制御によりＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、自身のアドレス変換表（表４）の５行目のエントリに従い、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ１及びＰｔ２ＵＥ１からＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１に書き換える。この結果、パケットヘッダは、図１４（ｂ）に示す内容になる。ＬＴＥ内の経路制御により、このパケットはＲＮ１に到達する。
　ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の６行目のエントリに従い、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１からＩＰＵＥ１及びＰｔ２ＵＥ１に書き換える。この結果、パケットヘッダは、図１４（ｃ）に示す内容になる。このパケットは、ＵＥ１に到達する。
　ＵＥ１がこのパケットを受信して返信する際、パケットヘッダは、図１４（ｄ）に示す内容になる。ＵＥ１は、このパケットをＲＮ１へ送信する。
　ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の６行目のエントリに従い、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ１及びＰｔ２ＵＥ１からＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１に書き換える。この結果、パケットヘッダは、図１４（ｅ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によりＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、このパケットを受信すると、自身のアドレス変換表（表４）の５行目のエントリに従い、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ１からＩＰＵＥ１及びＰｔ２ＵＥ１に書き換える。この結果、パケットヘッダは、図１４（ｆ）に示す内容になる。このパケットは、インターネット内の経路制御によりインターネット内のアプリケーションに到達する。
　（２．２）ＵＥ２の通信処理
　以下では、ＩＰｖ６アドレスを取得済みのＵＥがＲＮに接続した後に行われる通信処理について説明する。一例として、ＵＥ２の通信処理を説明する。
　（２．２．１）ＵＥ２が通信を継続する場合
　本節では、ＵＥ２が通信を継続する場合の通信処理について説明する。例えば、上記（２．１．２）節で説明した処理後に、ＵＥ２上のアプリケーション（ポート番号Ｐｔ１ＵＥ２）が、インターネット上のアプリケーション（ＩＰｖ６アドレス：ＩＰＣＮ、ポート番号：Ｐｔ１ＣＮ）と通信を継続する場合を想定する。以下、図１５を参照しながら、具体的に説明する。
　図１５は、本実施形態に係るＵＥ２による通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。各々のパケットヘッダには、パケットの始点ＩＰアドレスｓｒｃＩＰ及び始点ポート番号ｓｒｃＰｏｒｔ、並びに終点ＩＰアドレスｄｓｔＩＰ及び終点ポート番号ｄｓｔＰｏｒｔが含まれる。本図では、中継途中に書き替えられる部分に下線が付されている。
　ＵＥ２は、ＲＮ１へ、図１５（ａ）に示すヘッダを持つパケットを送信する。ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の１行目のエントリに従い、このパケットの始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ２及びＰｔ１ＵＥ２からＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ２に書き換える。この結果、ＲＮ１が下流から上流へ中継したあとのパケットヘッダは、図１５（ｂ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によりＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、このパケットを受信すると、自身のアドレス変換表（表４）の１行目のエントリに従い、このパケットの始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ２からＩＰＵＥ２及びＰｔ１ＵＥ２に書き換える。この結果、Ｐ－ＧＷ１が中継したあとのパケットヘッダは、図１５（ｃ）に示す内容になる。このパケットはインターネット内の経路制御によりインターネット上のアプリケーションに到達する。
　インターネット上のアプリケーションがこのパケットを受信し、返信する際のパケットヘッダは、図１５（ｄ）に示す内容になる。このパケットは、インターネット内の経路制御によりＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、自身のアドレス変換表（表４）の１行目のエントリに従い、このパケットの終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ２及びＰｔ１ＵＥ２からＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ２に書き換える。この結果、Ｐ－ＧＷ１が中継したあとのパケットヘッダは、図１５（ｅ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によりＲＮ１に到達する。
　ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の１行目のエントリに従い、このパケットの終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ２からＩＰＵＥ２及びＰｔ１ＵＥ２に書き換える。この結果、ＲＮ１が中継したあとのパケットヘッダは、図１５（ｆ）に示す内容になる。このパケットは、ＵＥ２に到達する。
　（２．２．２）ＵＥ２が通信開始待ちをする場合
　本節では、ＵＥ２が通信開始待ちをする場合の通信処理について説明する。例えば、上記（２．２．１）節で説明した処理後に、ＲＮ２上のアプリケーション（ポート番号：Ｐｔ２ＵＥ２）が、インターネット上のアプリケーションからの通信開始待ちになった場合を想定する。
　この場合の通信処理は、上記（２．１．２）節で説明した、ＵＥ１が通信開始待ちをする場合の通信処理と同様である。その結果、ＲＮ１が記憶するアドレス変換表には、表５の７行目のエントリが追加され、Ｐ－ＧＷ１が記憶するアドレス変換表には、表４の６行目のエントリが追加される。
　（２．３）ＲＮ２の通信処理
　以下では、ＩＰｖ６アドレスを未取得のＲＮが、他のＲＮにより提供される移動セルに接続した後に行われる通信処理について説明する。一例として、ＲＮ２の通信処理を説明する。
　（２．３．１）ＲＮ２が通信を開始する場合
　本節では、ＲＮ２が通信を開始する場合の通信処理について説明する。例えば、上記（２．２．２）節で説明した処理後に、ＲＮ２上のアプリケーション（ポート番号：Ｐｔ１ＲＮ２）が、インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）と通信を開始する場合を想定する。
　この場合の通信処理は、上記（２．１．１）節で説明した、ＵＥ１が通信を開始する場合の通信処理と同様である。その結果、ＲＮ１のアドレス変換表には、表５の８行目のエントリが追加される。
　（２．３．２）ＲＮ２が通信開始待ちをする場合
　本節では、ＲＮ２が通信待ちを開始する場合の通信処理について説明する。例えば、上記（２．３．１）節で説明した処理後に、ＲＮ２上のアプリケーション（ポート番号：Ｐｔ２ＲＮ２）が、インターネット上のアプリケーションからの通信開始待ちになった場合を想定する。
　この場合の通信処理は、上記（２．１．２）節で説明したＵＥ１が通信開始待ちをする場合の通信処理と同様である。その結果、ＲＮ１が記憶するアドレス変換表には表５の９行目のエントリが追加され、Ｐ－ＧＷ１が記憶するアドレス変換表には表４の７行目のエントリが追加される。
　（２．４）ＵＥ３の通信処理
　以下では、ＩＰｖ６アドレスを未取得のＵＥが、入れ子移動セルに接続した後に行われる通信処理について説明する。一例として、ＵＥ３の通信処理を説明する。
　（２．４．１）ＵＥ３が通信を開始する場合
　本節では、ＵＥ３が通信を開始する場合の通信処理について説明する。例えば、上記（２．３．２）節で説明した処理後に、ＵＥ３上のアプリケーション（ポート番号：Ｐｔ１ＵＥ３）が、インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）と通信を開始する場合を想定する。以下、図１６を参照しながら、具体的に説明する。
　図１６は、本実施形態に係るＵＥ３による通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。各々のパケットヘッダには、パケットの始点ＩＰアドレスｓｒｃＩＰ及び始点ポート番号ｓｒｃＰｏｒｔ、並びに終点ＩＰアドレスｄｓｔＩＰ及び終点ポート番号ｄｓｔＰｏｒｔが含まれる。本図では、中継途中に書き替えられる部分に下線が付されている。
　ＵＥ３は、図１６（ａ）に示すヘッダを持つパケットを送信する。ＲＮ２は、このパケットを受信すると、自身が記憶するアドレス変換表（表６）内に、下流ＩＰアドレス及び下流ポート番号がパケットの始点ＩＰアドレス及び始点ポート番号と一致するエントリが存在するか検索する。この時点では該当するエントリは存在しないので、ＲＮ２は、新たなポート番号Ｐｔ１ＲＮ２ ＵＥ３を生成し、自身のアドレス変換表に新たなエントリ（表６の２行目のエントリ）を加える。
　このエントリは、ＲＮ２が下流から上流にパケットを転送する際に始点ＩＰアドレス及び始点ポート番号がＩＰＵＥ３及びＰｔ１ＵＥ３である場合は、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ３に書き換えることを意味する。また、このエントリは、ＲＮ２が上流から下流にパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ３である場合は、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ３及びＰｔ１ＵＥ３に書き換えることを意味する。
　ＲＮ２は、本エントリに基づいた書き替えを行う。この結果、ＲＮ２が下流から上流へ中継したあとのパケットヘッダは、図１６（ｂ）に示す内容になる。このパケットは、ＲＮ１に到達する。
　ＲＮ１は、このパケットを受信すると、自身が記憶するアドレス変換表から、下流ＩＰアドレス及び下流ポート番号がパケットの始点ＩＰアドレスと始点ポート番号と一致するエントリを検索する。この時点では該当するエントリは存在しないので、ＲＮ１は、新たなポート番号Ｐｔ１ＲＮ１ ＵＥ３を生成し、自身のアドレス変換表に新しいエントリ（表５の１０行目のエントリ）を加える。
　このエントリは、ＲＮ１が下流から上流にパケットを転送する際に始点ＩＰアドレス及び始点ポート番号がＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ３である場合は、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ３に書き換えることを意味する。また、このエントリは、ＲＮ１が上流から下流にパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ３である場合は、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ３に書き換えることを意味する。
　ＲＮ１は、本エントリに基づいた書き替えを行う。この結果、ＲＮ１が下流から上流へ中継したあとのパケットヘッダは、図１６（ｃ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によってＰ－ＧＷ１に到達し、さらにインターネット内の経路制御によってインターネット上のアプリケーションに到達する。
　インターネット上のアプリケーションがこのパケットを受信し、返信する際のパケットヘッダは、図１６（ｄ）に示す内容になる。このパケットは、インターネット内の経路制御によりＰ－ＧＷ１に到達し、さらにＬＴＥ内の経路制御によってＲＮ１に到達する。
　ＲＮ１は、自身のアドレス変換表（表５）の１０行目のエントリに従い、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ３からＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ３に書き換える。その結果、ＲＮ１が上流から下流へ中継したあとのパケットヘッダは、図１６（ｅ）に示す内容になる。このパケットは、ＲＮ２に到達する。
　ＲＮ２は、このパケットを受信すると、自身のアドレス変換表（表６）の２行目のエントリに従い、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ３からＩＰＵＥ３及びＰｔ１ＵＥ３に書き換える。この結果、ＲＮ２が上流から下流へ中継したあとのパケットヘッダは、図１６（ｆ）に示す内容になる。このパケットは、ＵＥ３上のアプリケーションに到達する。
　（２．４．２）ＵＥ３が通信開始待ちをする場合
　本節では、ＵＥ３が通信開始待ちをする場合の通信処理について説明する。例えば、上記（２．４．１）節で説明した処理後に、ＵＥ３上のアプリケーション（ポート番号：Ｐｔ２ＵＥ３）が、インターネット上のアプリケーションからの通信開始待ちになった場合を想定する。以下、図１７を参照しながら、具体的に説明する。
　図１７は、本実施形態に係るＵＥ３による通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。各々のパケットヘッダには、パケットの始点ＩＰアドレスｓｒｃＩＰ及び始点ポート番号ｓｒｃＰｏｒｔ、並びに終点ＩＰアドレスｄｓｔＩＰ及び終点ポート番号ｄｓｔＰｏｒｔが含まれる。本図では、中継途中に書き替えられる部分に下線が付されている。
　ＵＥ３は、ＲＮ２にＮＡＴ登録リクエストを送信する。このＮＡＴ登録リクエストは、ＩＰＵＥ３及びＰｔ２ＵＥ３を含む。ＲＮ２は、このＮＡＴ登録リクエストを受信すると、新たなポート番号Ｐｔ２ＲＮ２ ＵＥ３を生成し、自身のアドレス変換表に新しいエントリ（表６の３行目のエントリ）を加える。
　このエントリは、ＲＮ２が上流から下流へパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３である場合、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ３及びＰｔ２ＵＥ３に書き換えることを意味する。また、このエントリは、ＲＮ２が下流から上流にパケットを転送する際に始点ＩＰアドレス及び始点ポート番号がＩＰＵＥ３及びＰｔ２ＵＥ３である場合、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３に書き換えることを意味する。
　次に、ＲＮ２は、ＲＮ１にＮＡＴ登録リクエストを転送する。このＮＡＴ登録リクエストは、ＩＰＵＥ ＲＮ２、Ｐｔ２ＲＮ２ ＵＥ３、ＩＰＵＥ３、及びＰｔ２ＵＥ３を含む。ＲＮ１は、このＮＡＴ登録リクエストを受信すると、新たなポート番号Ｐｔ２ＲＮ１ ＵＥ３を生成し、自身が記憶するアドレス変換表に新しいエントリ（表５の１１行目のエントリ）を加える。
　このエントリは、ＲＮ１が上流から下流にパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３である場合、終点ＩＰアドレス及び終点ポート番号をＩＰＵ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３に書き換えることを意味する。また、このエントリは、ＲＮ１が下流から上流にパケットを転送する際に始点ＩＰアドレス及び始点ポート番号がＩＰＵ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３である場合、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３に書き換えることを意味する。
　次いで、ＲＮ１は、Ｐ－ＧＷ１にＮＡＴ登録リクエストを転送する。このＮＡＴ登録リクエストはＩＰＵＥ ＲＮ１、Ｐｔ２ＲＮ１ ＵＥ３、ＩＰＵＥ３、及びＰｔ２ＵＥ３を含む。Ｐ－ＧＷ１は、このＮＡＴ登録リクエストを受信すると、自身が記憶するアドレス変換表に新しいエントリ（表４の８行目のエントリ）を加える。
　このエントリは、Ｐ－ＧＷ１がパケットを転送する際に終点ＩＰアドレス及び終点ポート番号がＩＰＵＥ３及びＰｔ２ＵＥ３である場合、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３に書き換えることを意味する。また、このエントリは、始点ＩＰアドレス及び始点ポート番号がＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３である場合、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ３及びＰｔ２ＵＥ３に書き換えることを意味する。
　インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）は、ＵＥ３上で動作するアプリケーション（ポート番号：Ｐｔ２ＵＥ３）と通信を開始する場合、図１７（ａ）に示すヘッダを持つパケットを送信する。このパケットは、インターネット内の経路制御によりＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、自身のアドレス変換表（表４）の８行目のエントリに従い、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ３及びＰｔ２ＵＥ３からＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３に書き換える。この結果、パケットヘッダは、図１７（ｂ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によりＲＮ１に到達する。
　ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の１１行目のエントリに従い、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３からＩＰＵＥ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３に書き換える。この結果、パケットヘッダは、図１７（ｃ）に示す内容になる。このパケットは、ＲＮ２に到達する。
　ＲＮ２は、このパケットを受信すると、自身のアドレス変換表（表６）の３行目のエントリに従い、終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３からＩＰＵＥ３及びＰｔ２ＵＥ３に書き換える。この結果、パケットヘッダは、図１７（ｄ）に示す内容になる。このパケットは、ＵＥ２上のアプリケーションに到達する。
　ＵＥ３がこのパケットを受信して返信する際、パケットヘッダは、図１７（ｅ）に示す内容になる。このパケットは、ＲＮ２に到達する。
　ＲＮ２は、このパケットを受信すると、自身のアドレス変換表（表６）の３行目のエントリに従い、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ３及びＰｔ２ＵＥ３からＩＰＵＥ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３に書き換える。この結果、パケットヘッダは、図１７（ｆ）に示す内容になる。このパケットは、ＲＮ１に到達する。
　ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の１１行目のエントリに従い、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ２ＲＮ２ ＵＥ３からＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３に書き換える。この結果、パケットヘッダは、図１７（ｇ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によってＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、このパケットを受信すると自身のアドレス変換表（表４）の８行目のエントリに従い、始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ２ＲＮ１ ＵＥ３からＩＰＵＥ３及びＰｔ２ＵＥ３に書き換える。この結果、パケットヘッダは、図１７（ｈ）に示す内容になる。このパケットは、インターネット内の経路制御によりインターネット内のアプリケーションに到達する。
　（２．５）ＵＥ４の通信処理
　以下では、ＩＰｖ６アドレスを取得済みのＵＥが、入れ子移動セルに接続した後に行われる通信処理について説明する。一例として、ＵＥ４の通信処理を説明する。
　（２．５．１）ＵＥ４が通信を継続する場合
　本節では、ＵＥ４が通信を継続する場合の通信処理について説明する。例えば、上記（２．４．２）節で説明した処理後に、ＵＥ４上のアプリケーション（ポート番号：Ｐｔ１ＵＥ４）が、インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）と通信を継続する場合を想定する。以下、図１８を参照しながら、具体的に説明する。
　図１８は、本実施形態に係るＵＥ４による通信のために各ノードが送受信するパケットヘッダの内容の一例を示す図である。各々のパケットヘッダには、パケットの始点ＩＰアドレスｓｒｃＩＰ及び始点ポート番号ｓｒｃＰｏｒｔ、並びに終点ＩＰアドレスｄｓｔＩＰ及び終点ポート番号ｄｓｔＰｏｒｔが含まれる。本図では、中継途中に書き替えられる部分に下線が付されている。
　ＵＥ４は、ＲＮ１へ、図１８（ａ）に示すヘッダを持つパケットを送信する。ＲＮ２は、このパケットを受信すると、自身の変換表（表６）の１行目のエントリに従い、このパケットの始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ４及びＰｔ１ＵＥ４からＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ４　に書き換える。この結果、ＲＮ２が下流から上流へ中継したあとのパケットヘッダは、図１８（ｂ）に示す内容になる。このパケットは、ＲＮ１に到達する。
　ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の２行目のエントリに従い、このパケットの始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ４からＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ４に書き換える。この結果、ＲＮ１が下流から上流へ中継したあとのパケットヘッダは、図１８（ｃ）に示す内容になる。このパケットはＬＴＥの経路制御によりＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、このパケットを受信すると、自身のアドレス変換表（表４）の２行目のエントリに従い、このパケットの始点ＩＰアドレス及び始点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ４からＩＰＵＥ４及びＰｔ１ＵＥ４に書き換える。この結果、Ｐ－ＧＷ１が下流から上流へ中継したあとのパケットヘッダは、図１８（ｄ）に示す内容になる。このパケットはインターネット内の経路制御により、インターネット上のアプリケーションに到達する。
　インターネット上のアプリケーションがこのパケットを受信し、返信する際のパケットヘッダは、図１８（ｅ）に示す内容になる。このパケットはインターネット内の経路制御によりＰ－ＧＷ１に到達する。
　Ｐ－ＧＷ１は、このパケットを受信すると、自身のアドレス変換表（表４）の２行目のエントリに従い、このパケットの終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ４及びＰｔ１ＵＥ４からＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ４に書き換える。この結果、Ｐ－ＧＷ１が上流から下流へ中継したあとのパケットヘッダは、図１８（ｆ）に示す内容になる。このパケットは、ＬＴＥ内の経路制御によりＲＮ１に到達する。
　ＲＮ１は、このパケットを受信すると、自身のアドレス変換表（表５）の２行目のエントリに従い、このパケットの終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ１及びＰｔ１ＲＮ１ ＵＥ４からＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ４に書き換える。この結果、ＲＮ１が上流から下流へ中継したあとのパケットヘッダは、図１８（ｇ）に示す内容になる。このパケットはＲＮ２に到達する。
　ＲＮ２は、このパケットを受信すると、自身のアドレス変換表（表６）の１行目のエントリに従い、このパケットの終点ＩＰアドレス及び終点ポート番号をＩＰＵＥ ＲＮ２及びＰｔ１ＲＮ２ ＵＥ４からＩＰＵＥ４及びＰｔ１ＵＥ４に書き換える。この結果、ＲＮ２が上流から下流へ中継したあとのパケットヘッダは、図１８（ｈ）に示す内容になる。このパケットは、ＵＥ４上のアプリケーションに到達する。
　（２．５．２）ＵＥ４が通信開始待ちをする場合
　本節では、ＵＥ４が通信開始待ちをする場合の通信処理について説明する。例えば、上記（２．５．１）節で説明した処理後に、ＵＥ４上のアプリケーション（ポート番号：Ｐｔ２ＵＥ４）が、インターネット上のアプリケーションからの通信開始待ちになった場合を想定する。
　この場合の通信処理は、上記（２．４．２）節で説明した、ＵＥ３が通信開始待ちをする場合の通信処理と同様である。その結果、ＲＮ２が記憶するアドレス変換表には表６の４行目のエントリが追加され、ＲＮ１が記憶するアドレス変換表には表５の１２行目のエントリが追加され、Ｐ－ＧＷ１が記憶するアドレス変換表には表４の９行目のエントリが追加される。
　（２．６）ＲＮ３の通信処理
　以下では、ＩＰｖ６アドレスを取得済みのＲＮが、他のＲＮにより提供される移動セルに接続した後に行われる通信処理について説明する。一例として、ＲＮ３の通信処理を説明する。
　（２．６．１）ＲＮ３が通信を継続する場合
　本節では、ＲＮ３が通信を継続する場合の通信処理について説明する。例えば、上記（２．５．２）節で説明した処理後に、ＲＮ３上のアプリケーション（ポート番号：Ｐｔ１ＲＮ３）が、インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）と通信を継続する場合を想定する。
　この場合の通信処理は、上記（２．２．１）節で説明した、ＵＥ２が通信を継続する場合の通信処理と同様である。
　（２．６．２）ＲＮ３が通信開始待ちをする場合
　本節では、ＲＮ３が通信開始待ちをする場合の通信処理について説明する。例えば、上記（２．６．１）節で説明した処理後に、ＲＮ３上のアプリケーション（ポート番号：Ｐｔ２ＲＮ３）が、インターネット上のアプリケーションからの通信開始待ちになった場合を想定する。
　この場合の通信処理は、上記（２．１．２）節で説明した、ＵＥ１が通信開始待ちをする場合の通信処理と同様である。その結果、ＲＮ１が記憶するアドレス変換表には表５の１３行目のエントリが追加され、Ｐ－ＧＷ１が記憶するアドレス変換表には表４の１０行目のエントリが追加される。
　（２．７）ＵＥ５の通信処理
　以下では、ＵＥの接続先のＲＮが他のＲＮにより提供される移動セルに移動した場合に行われる通信処理について説明する。一例として、ＵＥ５の通信処理を説明する。
　（２．７．１）ＵＥ５が通信を継続する場合
　本節では、ＵＥ５が通信を継続する場合の通信処理について説明する。例えば、上記（２．６．２）節で説明した処理後に、ＲＮ５上のアプリケーション（ポート番号：Ｐｔ１ＲＮ５）が、インターネット上のアプリケーション（ＩＰアドレス：ＩＰＣＮ、ポート番号：ＰｔＣＮ）と通信を継続する場合を想定する。
　この場合の通信処理は、上記（２．５．１）節で説明した、ＵＥ４が通信を継続する場合の通信処理と同様である。
　（２．７．２）ＵＥ５が通信開始待ちをする場合
　本節では、ＵＥ５が通信開始待ちをする場合の通信処理について説明する。例えば、上記（２．７．１）節で説明した処理後に、ＲＮ５上のアプリケーション（ポート番号：Ｐｔ２ＵＥ５）が、インターネット上のアプリケーションからの通信開始待ちになった場合を想定する。
　この場合の通信処理は、上記（２．４．２）節で説明した、ＵＥ３が通信開始待ちをする場合の通信処理と同様である。その結果、ＲＮ３が記憶するアドレス変換表には表７の２行目のエントリが追加され、ＲＮ１が記憶するアドレス変換表には表５の１４行目のエントリが追加され、Ｐ－ＧＷ１が記憶するアドレス変換表には表４の１１行目のエントリが追加される。
　＜３．３．ハンドオーバ処理＞
　（３．１）Ｓ－ＧＷ内ハンドオーバ
　本節では、Ｓ－ＧＷ内ハンドオーバに係る処理について説明する。一例として、ＲＮ１が、ＤｅＮＢ１からＤｅＮＢ２にハンドオーバする場合を想定する。ＲＮ１の下流にＵＥ１、ＲＮ２及びＵＥ２が接続している状態で、ＲＮ１がＤｅＮＢ１からＤｅＮＢ２にハンドオーバする際のハンドオーバ処理の一例を、図１９を参照して説明する。
　図１９は、本実施形態に係るシステムにおいて実行されるハンドオーバ処理の流れの一例を示すシーケンス図である。本シーケンスには、ＲＮ１、ＤｅＮＢ１、ＤｅＮＢ２、ＭＭＥ１、Ｓ－ＧＷ１、及びＰ－ＧＷ１が関与する。図１９に示す通り、Ｐ－ＧＷ１とＳ－ＧＷ１との間、Ｓ－ＧＷ１とＤｅＮＢ１との間、及びＤｅＮＢ１とＲＮ１との間に、それぞれＧＴＰトンネルが構成されている。
　まず、ＤｅＮＢ１は、ＲＮ１のＤｅＮＢ２へのハンドオーバ実行を決定する（ステップＳ８０２）。
　次いで、ＤｅＮＢ１は、ＤｅＮＢ２にハンドオーバリクエスト（Handover　Request）を送信する（ステップＳ８０４）。このハンドオーバリクエストは、ＩＤＲＮ１を含む。
　次に、ＤｅＮＢ２は、ＤｅＮＢ１にハンドオーバリクエスト応答（Handover　Request　Ack）を送信する（ステップＳ８０６）。このハンドオーバリクエスト応答は、ＩＤＲＮ１を含む。
　次いで、ＲＮ１は、ＤｅＮＢ２と無線回線を確立する（ステップＳ８０８）。
　次に、ＲＮ１は、リンクローカルの全てのルータマルチキャストアドレス宛にＲＳを送信する（ステップＳ８１０）。
　次いで、ＤｅＮＢ２は、このＲＳを受信し、ＲＮ１のリンクローカルアドレス宛にＲＡを送信する（ステップＳ８１２）。このＲＡは、ＤｅＮＢ２の下流インタフェースのプリフィクスであるＰｒｅｆＤ ＤｅＮＢ２を含む。
　次に、ＲＮ１は、このＲＡを受信し、ＰｒｅｆＤ ＤｅＮＢ２及びｉｆｉｄＵ ＲＮ１からＩＰｖ６アドレスであるＩＰ２Ｕ ＲＮ１を生成する（ステップＳ８１４）。ＩＰ２Ｕ ＲＮ１は、ＲＮ１がＤｅＮＢ２との間にＧＴＰトンネルを確立する際に使用される。
　次いで、ＲＮ１は、ＤｅＮＢ２にアタッチリクエストを送信する（ステップＳ８１６）。このアタッチリクエストは、ＲＮ１の識別子であるＩＤＲＮ１、ＩＰＵＥ ＲＮ１、及びＰｒｅｆＤ ＲＮ１を含む。
　次に、ＤｅＮＢ２は、このアタッチリクエストを受信すると、ＭＭＥ１にパススイッチリクエストを送信する（ステップＳ８１８）。このパススイッチリクエストは、ＩＤＲＮ１、ＩＰＵＥ ＲＮ１、ＰｒｅｆＤ ＲＮ１、及びＩＰＤ ＤｅＮＢ２を含む。
　次いで、ＭＭＥ１は、パススイッチリクエストを受信すると、Ｓ－ＧＷ１にベアラ変更リクエストを送信する（ステップＳ８２０）。このベアラ変更リクエストは、ＩＤＲＮ１、ＩＰＵＥ ＲＮ１、及びＰｒｅｆＤ ＲＮ１を含む。
　次に、Ｓ－ＧＷ１は、このベアラ変更リクエストを受信すると、ＲＮ１がＳ－ＧＷ１の下流のＤｅＮＢ間でハンドオーバしたことを検知し、Ｓ－ＧＷ１とＤｅＮＢ１との間に確立したＧＴＰトンネルを解放し、Ｓ－ＧＷ１とＤｅＮＢ２との間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、Ｓ－ＧＷ１の下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＳＧＷ１、及びＤｅＮＢ２の上流インタフェースのＩＰｖ６アドレスであるＩＰＵ ＤｅＮＢ２である。そして、Ｓ－ＧＷ１は、ＰｒｅｆＵＥ ＲＮ１及びＰｒｅｆＤ ＲＮ１の転送先をこのＧＴＰトンネルに関連付ける。そして、Ｓ－ＧＷ１は、ベアラ変更レスポンスをＭＭＥ１に送信する（ステップＳ８２２）。このベアラ変更レスポンスは、ＩＤＲＮ１、ＩＰＵＥ ＲＮ１、及びＰｒｅｆＤ ＲＮ１を含む。
　次いで、ＭＭＥ１は、このベアラ変更レスポンスを受信すると、管理表を更新する（表８の１行目のエントリが更新対象）。そして、ＭＭＥ１は、ＤｅＮＢ２にパススイッチリクエスト応答を送信する（ステップＳ８２４）。このパススイッチリクエスト応答は、ＩＤＲＮ１、ＩＰＵＥ ＲＮ１、及びＰｒｅｆＤ ＲＮ１を含む。
　次に、ＤｅＮＢ２は、このパススイッチリクエスト応答を受信すると、ＤｅＮＢ２とＳ－ＧＷ１との間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＩＰＵ ＤｅＮＢ２及びＩＰＤ ＳＧＷ１である。さらに、ＤｅＮＢ２は、ＲＮ１との間にＧＴＰトンネルを構成する。このＧＴＰトンネルの端点は、ＤｅＮＢ２の下流インタフェースのＩＰｖ６アドレスであるＩＰＤ ＤｅＮＢ２、及びＲＮ１の上流インタフェースのＩＰｖ６アドレスであるＩＰＵ ＲＮ１である。さらに、ＤｅＮＢ２は、ＰｒｅｆＵＥ ＲＮ１及びＰｒｅｆＤ ＲＮ１の転送先を、ＲＮ１へのＧＴＰトンネルに関連付ける。次に、ＤｅＮＢ２は、アタッチアクセプトをＲＮ１に送信する（ステップＳ８２６）。このアタッチアクセプトは、ＰｒｅｆＵＥ ＲＮ１を含む。
　以上の処理の結果、ＲＮ１とＤｅＮＢ２との間、及びＤｅＮＢ２とＳ－ＧＷ１との間にＧＴＰトンネルが確立する。他方、Ｓ－ＧＷ１とＰ－ＧＷ１との間のＧＴＰトンネルは維持される。
　次いで、ＲＮ１は、このアタッチアクセプトを受信すると、ＵＥとして動作する際のＩＰｖ６アドレスを取得するため、Ｐ－ＧＷ１にＲＳを送信する（ステップＳ８２８）。
　次に、Ｐ－ＧＷ１は、このＲＳを受信すると、ＲＮ１にＲＡを送信する（ステップＳ８３０）。このＲＡは、ＰｒｅｆＵＥ ＲＮ１を含む。
　次いで、ＲＮ１は、このＲＡを受信し、ＩＰＵＥ ＲＮ１が継続して利用可能であることを確認する（ステップＳ８３２）。
　以上説明した処理の結果、Ｓ－ＧＷ１及びＤｅＮＢ２の各々は、表９Ａ及び表９Ｂにそれぞれ示す経路表を記憶するようになる。また、ＭＭＥ１は、表８に示す管理表を記憶するようになる。なお、Ｐ－ＧＷ１が記憶する経路表及びアドレス変換表、並びにＲＮ１、ＲＮ２、及びＲＮ３が記憶するアドレス変換表には変化はない。
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
　＜３．４．アドレス変換表エントリの管理＞
　上記表４～表７に示したように、変換表のエントリはタイマフィールドを持つ。タイマフィールドには、当該エントリが作成されたとき、あるいはアクセスされたときに、タイムアウト時間（例えば６０秒）が設定される。そして、所定時間（例えば１秒）ごとに各エントリのタイマフィールドは経過した時間分減算され、値が０以下になった場合、そのエントリは削除されてもよい。
　また、ＵＥ又はＲＮ上で通信開始待ちになっているアプリケーションは、更新時間（例えば３０秒）ごとにＮＡＴ登録リクエストを上流ノードに送信し、ＮＡＴ登録応答を受信する。このメッセージ交換により、通信開始待ちのためのアドレス変換表エントリが削除されないようにすることが可能である。この場合のシーケンスを、図２１に示した。
　図２１は、本実施形態に係るシステムにおいて実行されるアドレス変換表エントリの維持処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１、ＲＮ１、及びＰ－ＧＷ１が関与する。図２１に示すように、まず、ＵＥ１はＮＡＴ登録リクエストをＲＮ１に送信する（ステップＳ１００２）。次いで、ＲＮ１は、ＮＡＴ登録リクエストをＰ－ＧＷ１に送信する（ステップＳ１００４）。次に、Ｐ－ＧＷ１は、ＮＡＴ登録応答をＲＮ１に送信する（ステップＳ１００６）。次いで、ＲＮ１は、ＮＡＴ登録応答をＵＥ１に送信する（ステップＳ１００８）。
　例えば、上記（２．１．２）節の通信後には、Ｐ－ＧＷ１は表４の５行目のエントリを記憶し、ＲＮ１は表５の５行目と６行目のエントリを記憶する。この状態で、ＵＥ１がＲＮ１から切断すると、タイムアウト時間後には、これら３つのエントリは削除される。このようにして、移動セルから切断したＵＥ又はＲＮのためのアドレス変換表エントリが削除される。
　＜３．５．変形例＞
　上記説明した提案プロトコルは、既存の３ＧＰＰのＥＰＣに準拠しない次世代のネットワークのアーキテクチャにも適用可能である。そのようなアーキテクチャについて、図２２及び図２３を参照して説明する。
　図２２及び図２３は、次世代ネットワークのアーキテクチャの一例を示す図である。図２２では、いわゆるピュアＩＰネットワークにより実現されるベアラレスなネットワークのアーキテクチャを示している。この場合、ベアラの役割をＩＰフローが担うこととなる。本アーキテクチャにおいても、プレフィクス部分を共通化することで、モバイルＩＰ等の仕組みが無くても、ＲＮに接続されるＵＥ群のＩＰ透過性が実現可能となる。図２３は、制御プレーンとユーザプレーンとが、クラウドを利用して分離されるアーキテクチャを示している。
　＜３．６．補足＞
　図２４は、本実施形態に係るＲＮのプロトコルスタックの一例を示す図である。図２４に示すように、ＲＮは、ＥＰＣトランスポート層ＩＰアドレスに加えて、ネットワーク層ＩＰアドレスを有する。このＲＮは、ＵＥとしての動作も可能であることから、ＵＲＮ（User-Equipment-Relay-Node）と称される場合がある。
　図２５は、本実施形態に係るＲＮを経由するＵＥとＰＤＮ上のサーバとの通信におけるプロトコルスタックの一例を示す図である。図２５に示すように、ＲＮは、ＤｅＮＢに接続されて、ＥＰＣ（Ｓ－ＧＷ及びＰ－ＧＷ）を経由してＰＤＮ上のアプリケーションサーバと通信を行う。また、ＲＮは、配下のＵＥと接続先のＤｅＮＢとの無線通信を中継する。
　＜＜４．ユースケース＞＞
　上述した提案プロトコルは、多様なユースケースに適用され得る。
　　（１）移動時のネットワークサービスの実現
　例えば、バス又は電車等の公共の乗り物にＲＮが搭載される場合、ＲＮは、ローカルコンテンツをＲＮに接続されているサーバから乗客のＵＥに提供することで、移動に伴うアクセスの非連続性等が解消可能である。また、ＲＮが接続しているＤｅＮＢ、又はコアネットワーク上のエンティティに接続されたサーバからのサービスに関しても、移動透過性が実現される。特に低遅延時間が求められるサービスには、ＲＮに接続されたサーバが有効である。また、公共の乗り物に搭載されたＲＮに、乗客のＲＮにより形成される入れ子仮想セルが接続する場合、乗客のＲＮのみが接続処理を行うだけで、入れ子仮想セルのネットワークへの接続性は継続される。これにより、乗車時すべてのＵＥがネットワークへの接続処理を行う事態が回避されるので、無線利用効率の改善が実現される。
　　（２）ＵＥが密集している環境での無線利用効率の向上
　例えば、繁華街又はイベント開催時などの、ＵＥの密度が著しく高い環境下においては、ＵＥがＲＮ機能を具備して、周囲の他のＵＥの移動透過性を実現することで、
無線利用効率の向上が実現され、より多くのＵＥを収容可能となる。
　　（３）セキュリティシステムへの応用
　例えば、移動する乗り物に搭載されたＲＮにカメラが接続されることで、高度なセキュリティシステムを移動環境にも提供可能となる。例えば、撮像画像がＲＮに接続されたサーバに蓄積及びデータ解析され、必要に応じてＲＮがコアネットワーク内のエンティティ又はクラウド上の計算リソースとの通信を行うことで、高度なセキュリティシステムが実現される。
　　（４）コグニティブ無線システムのダイナミックな運用サービスの実現
　コグニティブ無線システムとは、地域ごとの利用可能な周波数を管理する周波数データベースを利用することで、当該周波数を利用したアクセス網を提供するシステムである。例えば、ＲＮに、コグニティブ無線システムのアクセスポイント（即ち、基地局）としての機能が実装されることが考えられる。その場合、ＲＮは、ロケーション情報（ＧＰＳ情報又は無線基地局情報等）を利用して周波数データベースから現在位置で利用可能な周波数を特定し、当該周波数を利用して仮想セルを提供することが可能となる。また、ＲＮ経由でネットワークアクセスサービス、若しくはＵＥ－ＵＥ間、ＲＮ－ＵＥ間でのＤ２Ｄ（Device　to　device）通信サービスの提供も可能となる。
　　（５）ドローン技術によるダイナミックな運用サービスの実現
　ドローンに、仮想セルを提供するＲＮとしての機能を実装することで、飛行地域の各種デバイス群向けの無線サービスの提供が可能となる。ＲＮとして機能するドローンを、以下ではキングドローンとも称する。キングドローンは、コグニティブ無線システムとしての機能を有していてもよく、飛行中の地域における利用可能な周波数を周波数データベースとの通信により特定してもよい。仮想セルに接続するデバイス群は、例えばセンサデバイスであってもよい。例えば、農業に関して、農作物を育てる畑に地質、温度、湿度又は熟成度センサ等が配置され、キングドローンが畑の上空を飛行して、センサデバイス群にネットワーク層ＩＰアドレスを割り当ててもよい。そして、キングドローンは、当該地域を飛行する度にセンサデバイス群からセンサ情報を取得して、クラウド上のサーバへリレーしてもよい。また、イベント会場又は海水浴場等の期間限定で人が集まる地域に関して、キングドローンが上空を飛行して当該地域のＬＴＥデバイスにネットワーク層ＩＰアドレスを割当てて、端末上のアプリケーションと連携したサービスを提供してもよい。キングドローンは、イベント等の期間が終了後、配布したネットワーク層ＩＰアドレスの無効化（即ち、回収）を行ってもよい。
　　（６）車載センサシステムの実現
　車にＲＮとしての機能を搭載することで、車内又は車外モニタリング用の各種センサ（路面センサ又はレーダー等）により取得されたセンサ情報を収集し、車内で蓄積及び解析することが可能となる。また、ＲＮは、必要に応じてクラウド上のサーバへ接続し、ビッグデータ等と連携したより高度な解析処理を行ってもよい。仮想セルの移動透過性を実現する事で、車での移動時においても、車、ＲＮ又はセンサへのこの解析サービスのフィードバックを行うことが可能となる。
　　（７）長距離無線接続サービスの実現
　入れ子構造の仮想セルの実現により、ＲＮ－ＵＥのワンホップを数珠つなぎにする、いわゆるマルチホップ接続（即ち、仮想セルの数珠つなぎ）により、カバレッジの拡大が期待される。
　＜＜５．応用例＞＞
　本開示に係る技術は、様々な製品へ応用可能である。例えば、コアネットワークノード（例えばＰ－ＧＷ、Ｓ－ＧＷ及びＭＭＥ等）は、タワーサーバ、ラックサーバ、又はブレードサーバなどのいずれかの種類のサーバとして実現されてもよい。また、コアネットワークノードの少なくとも一部の構成要素は、サーバに搭載されるモジュール（例えば、１つのダイで構成される集積回路モジュール、又はブレードサーバのスロットに挿入されるカード若しくはブレード）において実現されてもよい。
　また、例えば、ＤｅＮＢは、マクロｅＮＢ又はスモールｅＮＢなどのいずれかの種類のｅＮＢ（evolved　Node　B）として実現されてもよい。スモールｅＮＢは、ピコｅＮＢ、マイクロｅＮＢ又はホーム（フェムト）ｅＮＢなどの、マクロセルよりも小さいセルをカバーするｅＮＢであってよい。その代わりに、ＤｅＮＢは、ＮｏｄｅＢ又はＢＴＳ（Base　Transceiver　Station）などの他の種類の基地局として実現されてもよい。ＤｅＮＢは、無線通信を制御する本体（基地局装置ともいう）と、本体とは別の場所に配置される１つ以上のＲＲＨ（Remote　Radio　Head）とを含んでもよい。また、後述する様々な種類の端末が一時的に又は半永続的に基地局機能を実行することにより、ＤｅＮＢとして動作してもよい。さらに、ＤｅＮＢの少なくとも一部の構成要素は、基地局装置又は基地局装置のためのモジュールにおいて実現されてもよい。
　また、例えば、ＵＥ及びＲＮは、スマートフォン、タブレットＰＣ（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）であってもよい。
　バス７０６は、プロセッサ７０１、メモリ７０２、ストレージ７０３及びネットワークインタフェース７０４を互いに接続する。バス７０６は、速度の異なる２つ以上のバス（例えば、高速バス及び低速バス）を含んでもよい。
　図２６に示したサーバ７００において、図５を参照して説明したコアネットワークノード（例えばＰ－ＧＷ、Ｓ－ＧＷ及びＭＭＥ等）に含まれる１つ以上の構成要素（例えば、制御部４３０）は、プロセッサ７０１において実装されてもよい。一例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）がサーバ７００にインストールされ、プロセッサ７０１が当該プログラムを実行してもよい。別の例として、サーバ７００は、プロセッサ７０１及びメモリ７０２を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムをメモリ７０２に記憶し、当該プログラムをプロセッサ７０１により実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてサーバ７００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるための上記プログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図２６に示したサーバ７００において、例えば、図５を参照して説明したネットワーク通信部４１０は、ネットワークインタフェース７０４において実装されてもよい。また、記憶部４２０は、メモリ７０２及び／又はストレージ７０３において実装されてもよい。
　　＜５．２．基地局に関する応用例＞
　（第１の応用例）
　図２７は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第１の例を示すブロック図である。ｅＮＢ８００は、１つ以上のアンテナ８１０、及び基地局装置８２０を有する。各アンテナ８１０及び基地局装置８２０は、ＲＦケーブルを介して互いに接続され得る。
　アンテナ８１０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、基地局装置８２０による無線信号の送受信のために使用される。ｅＮＢ８００は、図２７に示したように複数のアンテナ８１０を有し、複数のアンテナ８１０は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図２７にはｅＮＢ８００が複数のアンテナ８１０を有する例を示したが、ｅＮＢ８００は単一のアンテナ８１０を有してもよい。
　基地局装置８２０は、コントローラ８２１、メモリ８２２、ネットワークインタフェース８２３及び無線通信インタフェース８２５を備える。
　コントローラ８２１は、例えばＣＰＵ又はＤＳＰであってよく、基地局装置８２０の上位レイヤの様々な機能を動作させる。例えば、コントローラ８２１は、無線通信インタフェース８２５により処理された信号内のデータからデータパケットを生成し、生成したパケットをネットワークインタフェース８２３を介して転送する。コントローラ８２１は、複数のベースバンドプロセッサからのデータをバンドリングすることによりバンドルドパケットを生成し、生成したバンドルドパケットを転送してもよい。また、コントローラ８２１は、無線リソース管理（Radio　Resource　Control）、無線ベアラ制御（Radio　Bearer　Control）、移動性管理（Mobility　Management）、流入制御（Admission　Control）又はスケジューリング（Scheduling）などの制御を実行する論理的な機能を有してもよい。また、当該制御は、周辺のｅＮＢ又はコアネットワークノードと連携して実行されてもよい。メモリ８２２は、ＲＡＭ及びＲＯＭを含み、コントローラ８２１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、送信電力データ及びスケジューリングデータなど）を記憶する。
　ネットワークインタフェース８２３は、基地局装置８２０をコアネットワーク８２４に接続するための通信インタフェースである。コントローラ８２１は、ネットワークインタフェース８２３を介して、コアネットワークノード又は他のｅＮＢと通信してもよい。その場合に、ｅＮＢ８００と、コアネットワークノード又は他のｅＮＢとは、論理的なインタフェース（例えば、Ｓ１インタフェース又はＸ２インタフェース）により互いに接続されてもよい。ネットワークインタフェース８２３は、有線通信インタフェースであってもよく、又は無線バックホールのための無線通信インタフェースであってもよい。ネットワークインタフェース８２３が無線通信インタフェースである場合、ネットワークインタフェース８２３は、無線通信インタフェース８２５により使用される周波数帯域よりもより高い周波数帯域を無線通信に使用してもよい。
　無線通信インタフェース８２５は、ＬＴＥ（Long　Term　Evolution）又はＬＴＥ－Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、アンテナ８１０を介して、ｅＮＢ８００のセル内に位置する端末に無線接続を提供する。無線通信インタフェース８２５は、典型的には、ベースバンド（ＢＢ）プロセッサ８２６及びＲＦ回路８２７などを含み得る。ＢＢプロセッサ８２６は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、各レイヤ（例えば、Ｌ１、ＭＡＣ（Medium　Access　Control）、ＲＬＣ（Radio　Link　Control）及びＰＤＣＰ（Packet　Data　Convergence　Protocol））の様々な信号処理を実行する。ＢＢプロセッサ８２６は、コントローラ８２１の代わりに、上述した論理的な機能の一部又は全部を有してもよい。ＢＢプロセッサ８２６は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を含むモジュールであってもよく、ＢＢプロセッサ８２６の機能は、上記プログラムのアップデートにより変更可能であってもよい。また、上記モジュールは、基地局装置８２０のスロットに挿入されるカード若しくはブレードであってもよく、又は上記カード若しくは上記ブレードに搭載されるチップであってもよい。一方、ＲＦ回路８２７は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８１０を介して無線信号を送受信する。
　無線通信インタフェース８２５は、図２７に示したように複数のＢＢプロセッサ８２６を含み、複数のＢＢプロセッサ８２６は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。また、無線通信インタフェース８２５は、図２７に示したように複数のＲＦ回路８２７を含み、複数のＲＦ回路８２７は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図２７には無線通信インタフェース８２５が複数のＢＢプロセッサ８２６及び複数のＲＦ回路８２７を含む例を示したが、無線通信インタフェース８２５は単一のＢＢプロセッサ８２６又は単一のＲＦ回路８２７を含んでもよい。
　図２７に示したｅＮＢ８００において、図４を参照して説明したＤｅＮＢに含まれる１つ以上の構成要素（例えば、制御部３５０）は、無線通信インタフェース８２５において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ８２１において実装されてもよい。一例として、ｅＮＢ８００は、無線通信インタフェース８２５の一部（例えば、ＢＢプロセッサ８２６）若しくは全部、及び／又はコントローラ８２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがｅＮＢ８００にインストールされ、無線通信インタフェース８２５（例えば、ＢＢプロセッサ８２６）及び／又はコントローラ８２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてｅＮＢ８００、基地局装置８２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図２７に示したｅＮＢ８００において、図４を参照して説明した無線通信部３２０は、無線通信インタフェース８２５（例えば、ＲＦ回路８２７）において実装されてもよい。また、アンテナ部３１０は、アンテナ８１０において実装されてもよい。また、ネットワーク通信部３３０は、コントローラ８２１及び／又はネットワークインタフェース８２３において実装されてもよい。また、記憶部３４０は、メモリ８２２において実装されてもよい。
　（第２の応用例）
　図２８は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第２の例を示すブロック図である。ｅＮＢ８３０は、１つ以上のアンテナ８４０、基地局装置８５０、及びＲＲＨ８６０を有する。各アンテナ８４０及びＲＲＨ８６０は、ＲＦケーブルを介して互いに接続され得る。また、基地局装置８５０及びＲＲＨ８６０は、光ファイバケーブルなどの高速回線で互いに接続され得る。
　アンテナ８４０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、ＲＲＨ８６０による無線信号の送受信のために使用される。ｅＮＢ８３０は、図２８に示したように複数のアンテナ８４０を有し、複数のアンテナ８４０は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図２８にはｅＮＢ８３０が複数のアンテナ８４０を有する例を示したが、ｅＮＢ８３０は単一のアンテナ８４０を有してもよい。
　基地局装置８５０は、コントローラ８５１、メモリ８５２、ネットワークインタフェース８５３、無線通信インタフェース８５５及び接続インタフェース８５７を備える。コントローラ８５１、メモリ８５２及びネットワークインタフェース８５３は、図２７を参照して説明したコントローラ８２１、メモリ８２２及びネットワークインタフェース８２３と同様のものである。
　無線通信インタフェース８５５は、ＬＴＥ又はＬＴＥ－Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、ＲＲＨ８６０及びアンテナ８４０を介して、ＲＲＨ８６０に対応するセクタ内に位置する端末に無線接続を提供する。無線通信インタフェース８５５は、典型的には、ＢＢプロセッサ８５６などを含み得る。ＢＢプロセッサ８５６は、接続インタフェース８５７を介してＲＲＨ８６０のＲＦ回路８６４と接続されることを除き、図２７を参照して説明したＢＢプロセッサ８２６と同様のものである。無線通信インタフェース８５５は、図２８に示したように複数のＢＢプロセッサ８５６を含み、複数のＢＢプロセッサ８５６は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図２８には無線通信インタフェース８５５が複数のＢＢプロセッサ８５６を含む例を示したが、無線通信インタフェース８５５は単一のＢＢプロセッサ８５６を含んでもよい。
　接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）をＲＲＨ８６０と接続するためのインタフェースである。接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）とＲＲＨ８６０とを接続する上記高速回線での通信のための通信モジュールであってもよい。
　また、ＲＲＨ８６０は、接続インタフェース８６１及び無線通信インタフェース８６３を備える。
　接続インタフェース８６１は、ＲＲＨ８６０（無線通信インタフェース８６３）を基地局装置８５０と接続するためのインタフェースである。接続インタフェース８６１は、上記高速回線での通信のための通信モジュールであってもよい。
　無線通信インタフェース８６３は、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、典型的には、ＲＦ回路８６４などを含み得る。ＲＦ回路８６４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、図２８に示したように複数のＲＦ回路８６４を含み、複数のＲＦ回路８６４は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図２８には無線通信インタフェース８６３が複数のＲＦ回路８６４を含む例を示したが、無線通信インタフェース８６３は単一のＲＦ回路８６４を含んでもよい。
　図２８に示したｅＮＢ８３０において、図４を参照して説明したＤｅＮＢに含まれる１つ以上の構成要素（例えば、制御部３５０）は、無線通信インタフェース８５５及び／又は無線通信インタフェース８６３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ８５１において実装されてもよい。一例として、ｅＮＢ８３０は、無線通信インタフェース８５５の一部（例えば、ＢＢプロセッサ８５６）若しくは全部、及び／又はコントローラ８５１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがｅＮＢ８３０にインストールされ、無線通信インタフェース８５５（例えば、ＢＢプロセッサ８５６）及び／又はコントローラ８５１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてｅＮＢ８３０、基地局装置８５０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図２８に示したｅＮＢ８３０において、例えば、図４を参照して説明した無線通信部３２０は、無線通信インタフェース８６３（例えば、ＲＦ回路８６４）において実装されてもよい。また、アンテナ部３１０は、アンテナ８４０において実装されてもよい。また、ネットワーク通信部３３０は、コントローラ８５１及び／又はネットワークインタフェース８５３において実装されてもよい。また、記憶部３４０は、メモリ８５２において実装されてもよい。
　　＜５．３．端末装置に関する応用例＞
　（第１の応用例）
　図２９は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２、１つ以上のアンテナスイッチ９１５、１つ以上のアンテナ９１６、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。
　プロセッサ９０１は、例えばＣＰＵ又はＳｏＣ（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. 　前記制御部は、前記送信先情報又は前記送信元情報のうち前記下流ノードの前記アドレス情報を変換する、請求項１に記載の中継装置。
  3. 　前記第１の変換表は、前記下流ノードのアドレス情報と当該下流ノードに対応する前記中継装置のアドレス情報とを対応付けた情報を含む、請求項１に記載の中継装置。
  4. 　前記制御部は、前記上流ノードから前記下流ノードへのパケットの前記送信先情報のＩＰアドレスを、前記下流ノードのＩＰアドレスに変換する、請求項２に記載の中継装置。
  5. 　前記制御部は、前記上流ノードから前記下流ノードへのパケットの前記送信先情報のポート番号を、最下流ノードで動作するアプリケーションに応じた前記下流ノードのポート番号に変換する、請求項２に記載の中継装置。
  6. 　前記制御部は、前記下流ノードから前記上流ノードへのパケットの前記送信元情報のＩＰアドレスを、前記中継装置のＩＰアドレスに変換する、請求項２に記載の中継装置。
  7. 　前記制御部は、前記下流ノードから前記上流ノードへのパケットの前記送信元情報のポート番号を、最下流ノードで動作するアプリケーションに応じた前記中継装置のポート番号に変換する、請求項２に記載の中継装置。
  8. 　前記制御部は、中継するパケットが前記上流ノードから前記下流ノードへのパケットであるか、前記下流ノードから前記上流ノードへのパケットであるかを識別する、請求項１に記載の中継装置。
  9. 　前記パケットの送信先情報又は送信元情報は、Ｐ－ＧＷ（Packet　Data　Network　Gateway）によりＰ－ＧＷが記憶するアドレス情報の第２の変換表に基づいて変換される、請求項１に記載の中継装置。
  10. 　前記第２の変換表は、最下流ノードのアドレス情報と、当該最下流ノードに対応する前記中継装置のアドレス情報とを対応付けた情報を含む、請求項９に記載の中継装置。
  11. 　前記制御部は、前記第２の変換表の登録を要求するメッセージをＰ－ＧＷへ送信する、請求項９に記載の中継装置。
  12. 　基地局からＰ－ＧＷまでの各ノードは、前記送信先情報と転送先とを対応付けた経路表を記憶し、前記経路表に基づいて前記パケットを中継する、請求項１に記載の中継装置。
  13. 　ＭＭＥは、ネットワークにアタッチしたノードの識別情報、アドレス情報、及び前記ノードの上流ノードのアドレス情報を対応付けた管理表を記憶する、請求項１に記載の中継装置。
  14. 　前記制御部は、ＩＰアドレスを未取得の場合、Ｐ－ＧＷからＩＰアドレスのプリフィックスの割り当てを受ける、請求項１に記載の中継装置。
  15. 　前記制御部は、前記中継装置が形成する移動セルの位置付けを示す情報を送信する、請求項１に記載の中継装置。
  16. 　前記制御部は、アタッチしてきた前記下流ノードに関するアタッチリクエストの送信タイミングを制御する、請求項１に記載の中継装置。
  17. 　前記制御部は、アタッチしてきたひとつ以上の前記下流ノードに関するアタッチリクエストをまとめて前記上流ノードに送信する、請求項１６に記載の中継装置。
  18. 　中継するパケットの送信先情報又は送信元情報を、記憶されたアドレス情報の第１の変換表に基づいて変換する上流ノードに、前記第１の変換表の登録を要求するメッセージを送信する制御部、
    を備える端末装置。
  19. 　アドレス情報の第１の変換表を記憶することと、
    　接続先の上流ノードと配下の下流ノードとの間で送受信されるパケットの送信先情報又は送信元情報を、記憶された前記第１の変換表に基づいてプロセッサにより変換して中継することと、
    を含む通信方法。
  20. 　中継するパケットの送信先情報又は送信元情報を、記憶されたアドレス情報の第１の変換表に基づいて変換する上流ノードに、前記第１の変換表の登録を要求するメッセージをプロセッサにより送信すること、
    を含む通信方法。
PCT/JP2017/002222 2016-03-31 2017-01-24 中継装置、端末装置及び通信方法 WO2017169000A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
MX2018011417A MX2018011417A (es) 2016-03-31 2017-01-24 Dispositivo de retransmision, dispositivo de terminal y metodo de comunicacion.
RU2018133238A RU2018133238A (ru) 2016-03-31 2017-01-24 Ретрансляционное устройство, терминальное устройство и способ коммуникации
SG11201808121XA SG11201808121XA (en) 2016-03-31 2017-01-24 Relay device, terminal device, and communication method
EP17773550.3A EP3439424A4 (en) 2016-03-31 2017-01-24 RELAY DEVICE, TERMINAL DEVICE, AND COMMUNICATION METHOD
ZA2018/05140A ZA201805140B (en) 2016-03-31 2018-07-31 Relay device, terminal device, and communication method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-072459 2016-03-31
JP2016072459 2016-03-31

Publications (1)

Publication Number Publication Date
WO2017169000A1 true WO2017169000A1 (ja) 2017-10-05

Family

ID=59964036

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/002222 WO2017169000A1 (ja) 2016-03-31 2017-01-24 中継装置、端末装置及び通信方法

Country Status (7)

Country Link
EP (1) EP3439424A4 (ja)
MX (1) MX2018011417A (ja)
RU (1) RU2018133238A (ja)
SG (1) SG11201808121XA (ja)
TW (1) TW201739214A (ja)
WO (1) WO2017169000A1 (ja)
ZA (1) ZA201805140B (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107919899B (zh) * 2017-12-27 2024-01-26 成都西科微波通讯有限公司 云中继通信系统
CN110868704B (zh) * 2018-08-27 2023-04-25 中国移动通信集团山东有限公司 一种基于d2d中继的物联网覆盖增强处理方法及装置
JP7386621B2 (ja) 2019-05-14 2023-11-27 日本無線株式会社 無線通信ユニット及びそれを用いた無線ネットワークシステム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009246614A (ja) * 2008-03-31 2009-10-22 Nec Corp 通信システム、端末、中継装置、通信モード判定方法、及びプログラム
JP2013197895A (ja) * 2012-03-19 2013-09-30 Fujitsu Ltd 無線通信システム、基地局及び中継局並びに通信方法
JP2014526851A (ja) * 2011-09-30 2014-10-06 日本電気株式会社 通信システム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8902805B2 (en) * 2008-10-24 2014-12-02 Qualcomm Incorporated Cell relay packet routing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009246614A (ja) * 2008-03-31 2009-10-22 Nec Corp 通信システム、端末、中継装置、通信モード判定方法、及びプログラム
JP2014526851A (ja) * 2011-09-30 2014-10-06 日本電気株式会社 通信システム
JP2013197895A (ja) * 2012-03-19 2013-09-30 Fujitsu Ltd 無線通信システム、基地局及び中継局並びに通信方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3439424A4 *

Also Published As

Publication number Publication date
SG11201808121XA (en) 2018-10-30
RU2018133238A (ru) 2020-03-20
MX2018011417A (es) 2019-01-10
EP3439424A4 (en) 2019-05-01
TW201739214A (zh) 2017-11-01
ZA201805140B (en) 2019-05-29
EP3439424A1 (en) 2019-02-06

Similar Documents

Publication Publication Date Title
US10560424B2 (en) Apparatus and method
US10750418B2 (en) SDN based connectionless architecture with dual connectivity and carrier aggregation
US11172539B2 (en) Base station and terminal device
US20100322148A1 (en) Base station and attaching method thereof
US10694396B2 (en) Relay device, terminal device, communication control device, and method
CN110546989B (zh) 无线通信系统中的电子设备以及无线通信方法
WO2017043204A1 (ja) 装置、方法及びプログラム
EP3222084B1 (en) Information processing apparatus, information processing method and non-transitory computer-readable medium
US11445479B2 (en) Radio network slicing in 5G new radio (NR)
WO2017169000A1 (ja) 中継装置、端末装置及び通信方法
EP3439364A1 (en) Wireless communication device, server, and method
US20200120726A1 (en) Mechanism for Realizing LWA/LWIP Aggregator Function
WO2013189443A2 (zh) 一种家庭基站中获取标识和地址匹配关系的方法、系统及网关
WO2017104281A1 (ja) 装置、方法及びプログラム
KR20090110677A (ko) ｕ―ＴＳＮ 망 내에서 교통정보를 수집하고 제공하기 위한시스템 및 방법
US20140293871A1 (en) Mobile communication network and mobile communication method using the same
US20130322405A1 (en) Method for supporting node mobility in wireless mesh network
CN115699887A (zh) 一种通信方法及装置
EP3565375B1 (en) Wireless communication device, repeating device, wireless communication method, repeating method and information processing method
WO2017090158A1 (ja) 基地局装置、端末装置、及び、無線通信システム、通信切替方法
WO2017094360A1 (ja) 装置、方法及びプログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: MX/A/2018/011417

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 11201808121X

Country of ref document: SG

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017773550

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017773550

Country of ref document: EP

Effective date: 20181031

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

Ref document number: 17773550

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP