WO2012046503A1 - 通信装置、通信制御方法及び通信システム - Google Patents

通信装置、通信制御方法及び通信システム Download PDF

Info

Publication number
WO2012046503A1
WO2012046503A1 PCT/JP2011/068288 JP2011068288W WO2012046503A1 WO 2012046503 A1 WO2012046503 A1 WO 2012046503A1 JP 2011068288 W JP2011068288 W JP 2011068288W WO 2012046503 A1 WO2012046503 A1 WO 2012046503A1
Authority
WO
WIPO (PCT)
Prior art keywords
data packet
communication
destination node
data
transfer destination
Prior art date
Application number
PCT/JP2011/068288
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
Priority to EP11830436.9A priority Critical patent/EP2627123B1/en
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to KR20137007307A priority patent/KR20130099073A/ko
Priority to CN2011800468815A priority patent/CN103155649A/zh
Priority to BR112013007690A priority patent/BR112013007690A2/pt
Priority to US13/819,353 priority patent/US9143885B2/en
Priority to AU2011311009A priority patent/AU2011311009A1/en
Priority to CA2808204A priority patent/CA2808204A1/en
Priority to ES11830436T priority patent/ES2701761T3/es
Priority to RU2013113963/08A priority patent/RU2013113963A/ru
Publication of WO2012046503A1 publication Critical patent/WO2012046503A1/ja
Priority to US14/824,296 priority patent/US9949058B2/en
Priority to US15/924,649 priority patent/US10334391B2/en
Priority to US16/414,291 priority patent/US10893376B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2475—Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/125—Shortest path evaluation based on throughput or bandwidth

Definitions

  • the present disclosure relates to a communication device, a communication control method, and a communication system.
  • MTC Machine-Type Communication
  • M2M Machine-to-Machine
  • Patent Document 1 proposes a technique for monitoring the state of a communication node in a mobile communication network and changing the transfer path of a signal from a terminal when congestion or abnormality is detected.
  • Patent Document 1 the technique described in Patent Document 1 described above is for reducing the influence of congestion when congestion has already occurred, and does not prevent the occurrence of congestion itself.
  • MTC communication contains a risk of concentrated data transmission at a specific time and a specific region.
  • MTC communication since most of the MTC communication is performed in a planned manner, it is possible to foresee the risk of concentration of data transmission in the MTC communication unlike communication from a terminal used by a human.
  • low delay such as voice call and real-time streaming in MTC communication. Therefore, it is presumed that traffic congestion in MTC communication can be avoided or alleviated by controlling the communication path of MTC communication systematically and flexibly to some extent.
  • a communication device in a communication network including a plurality of communication nodes, the receiving unit receiving a data packet transmitted from the terminal device or transmitted to the terminal device, and the terminal device is an MTC terminal
  • a communication control unit that selects a transfer destination node of the data packet from a plurality of transfer destination node candidates, a transmission unit that transmits the data packet to the transfer destination node selected by the communication control unit, A communication device is provided.
  • the communication control unit may select a transfer destination node of the data packet based on the control information in the data packet.
  • the communication apparatus further includes a storage unit that stores transfer destination data that associates the classification of the data packet with the transfer destination node, and the communication control unit classifies the data packet according to the control information, A transfer destination node associated with the classification of the data packet in the transfer destination data may be selected as the transfer destination node of the data packet.
  • control information may include a terminal ID, class or group of the terminal device, or an application ID or class of an application related to the data packet.
  • the communication control unit classifies each data packet according to the control information, and forwards each data packet to a plurality of forwarding nodes so that the forwarding destination of the data packet belonging to the same classification is distributed to a plurality of forwarding destination nodes. May be selected.
  • the communication control unit may select the transfer destination node of the data packet from the plurality of transfer destination node candidates regardless of the routing metric regarding the route to the destination node of the data packet.
  • the communication control unit may insert intermediate node designation information for designating an intermediate node different from the destination node on the route to the destination node of the data packet into the destination field of the data packet. Good.
  • the communication control unit may transfer the information described in the destination field to the other field when the data packet is received.
  • the communication control unit may add a flag indicating that the destination field has been changed to the data packet.
  • the communication network may be a core network of a cellular communication system.
  • a communication control method in a communication device in a communication network including a plurality of communication nodes, receiving a data packet transmitted from a terminal device or transmitted to a terminal device; Communication including selecting the transfer destination node of the data packet from a plurality of transfer destination node candidates and transmitting the data packet to the selected transfer destination node when the terminal device is an MTC terminal A control method is provided.
  • a communication apparatus comprising: a communication control unit that selects a transfer destination node of the data packet; and a transmission unit that transmits the data packet to a transfer destination node selected by the communication control unit; and candidates for the transfer destination node, respectively And a communication system including the plurality of communication nodes.
  • a communication device in a communication network including a plurality of communication nodes, the receiving unit receiving a data packet transmitted from the terminal device or transmitted to the terminal device, and the terminal device A transmission unit that transmits the data packet to a communication node that selects the transfer destination node of the data packet from a plurality of transfer destination node candidates when the node is an MTC terminal, and the communication node for selection of the transfer destination node And a communication control unit that inserts control information used for classification of the data packet into the data packet.
  • traffic congestion in MTC communication can be avoided or alleviated.
  • FIG. 1 is a schematic diagram illustrating an overview of a communication system 1 according to the first embodiment.
  • the communication system 1 includes a plurality of terminal devices 100a to 100e, a plurality of base stations 120a to 120d, a plurality of communication devices 140a to 140d, and a plurality of application servers 190a to 190c.
  • the plurality of communication devices 140a to 140d form the core network 10 in the communication system 1.
  • the base station 120d and the application servers 190a and 190b are connected to the network 20.
  • the terminal device 100 when there is no need to distinguish the terminal devices 100a to 100e from each other, these are collectively referred to as the terminal device 100.
  • the base station 120 120a to 120d
  • the communication device 140 140a to 140d
  • the application server 190 190a to 190c
  • the terminal device 100 is a wireless communication device that operates as an MTC terminal. Each terminal device 100 transmits and receives radio signals to and from the base station 120 that provides a radio communication service to the cell to which the terminal device 100 belongs. For example, the terminal device 100 generates application data such as a gas usage amount or a vending machine inventory amount, and transmits a data packet including the generated application data to the base station 120. The data packet transmitted from the terminal device 100 to the base station 120 is finally delivered to the target application server 190 via some communication nodes.
  • application data such as a gas usage amount or a vending machine inventory amount
  • the base station 120 is a communication node that provides a wireless communication service in a cell that extends around its own device, for example, according to a cellular communication method represented by LTE (Long Term Evolution) or LTE-Advanced.
  • LTE Long Term Evolution
  • LTE-Advanced a cellular communication method represented by LTE (Long Term Evolution) or LTE-Advanced.
  • the base station 120 receives a data packet including application data generated by the terminal device 100, and transfers the received data packet to the communication device 140 of the core network 10. Further, the base station 120 receives the data packet addressed to the terminal device 100 transferred via the core network 10 and transfers the received data packet to the destination terminal device 100.
  • the base stations 120a to 120c are so-called macro cell base stations directly connected to the core network 10.
  • the base station 120d is a femtocell base station (also referred to as HeNB (Home eNB) in LTE) connected to the core network 10 via the network 20.
  • HeNB Home eNB
  • These base stations 120 may provide wireless communication services not only to MTC terminals such as the terminal device 100 but also to general user terminals.
  • the communication device 140 is a communication node that forms the core network 10.
  • Each communication device 140 may be, for example, RNC (Radio Network Controller), MME (Mobility Management Entity), HSS (Home Subscriber Server), SGSN (Serving GPRS Support Node), or GGSN (Gateway GPRS Support Node).
  • RNC Radio Network Controller
  • MME Mobility Management Entity
  • HSS Home Subscriber Server
  • SGSN Serving GPRS Support Node
  • GGSN Gateway GPRS Support Node
  • Each communication device 140 may be a network device such as a switch or a router that connects these communication nodes, for example.
  • the communication device 140 receives a data packet transmitted from the terminal device 100 or transmitted to the terminal device 100 and sequentially transfers the received data packet so as to reach the destination application server 190.
  • the communication device 140d is a GGSN having a role of a so-called gateway, and is located at the boundary between the core network 10 and the network 20.
  • the network 20 may be, for example, an IP (Internet Protocol) network such as the Internet, or a non-IP network such as an ATM (Asynchronous Transfer Mode) network.
  • the application server 190 is a server device having an application (AP) function such as, for example, charging a gas charge or planning a delivery of a product to a vending machine. Such a server device that uses application data transmitted from an MTC terminal is also called an MTC server.
  • the application server 190 may be connected to the network 20 or may exist in the core network 10. In the example of FIG. 1, the application servers 190 a and 190 b are connected to the network 20, and the application server 190 c exists in the core network 10.
  • the application server 190c may be mounted on a device that is physically the same as the communication node that forms the core network 10.
  • the application server 190 finally receives a data packet transmitted from the terminal device 100, for example. Then, the application server 190 acquires application data included in the received data packet, and executes the application function as exemplified above. Further, the application server 190 may provide a user with a user interface for accepting input of settings regarding the MTC terminal.
  • the setting related to the MTC terminal can include, for example, a setting related to a schedule for MTC communication between the application server 190 and the terminal device 100.
  • a data packet transmitted from the MTC terminal may cause congestion on the communication path to the destination application server 190. is there.
  • data packets may be transmitted from the terminal device 100 simultaneously at a specific time or in a specific area.
  • the purpose of MTC communication is data collection, the data packet does not necessarily reach the application server 190 at the maximum rate. Therefore, in the present embodiment, the occurrence of traffic congestion in MTC communication is avoided or alleviated by adopting the configuration of each device described in the next section.
  • the term “communication node” or “communication device” is any of the terminal device 100, the base station 120, the communication device 140, and the application server 190 illustrated in FIG. Note that can also represent
  • FIG. 2 is a block diagram illustrating an example of the configuration of the terminal device 100 according to the present embodiment.
  • the terminal device 100 includes an application unit 102, a storage unit 104, a communication control unit 110, a wireless transmission unit 112, and a wireless reception unit 114.
  • the application unit 102 generates application data to be transmitted to the application server 190, and outputs the generated application data to the communication control unit 110.
  • the application data generated by the application unit 102 may be any data such as gas usage, vending machine inventory, copier toner remaining, or location data for transportation management, depending on the purpose of the application. It can contain types of data.
  • the generation of application data may be performed periodically at a preset time or frequency, for example. Instead, the generation of application data may be triggered by the occurrence of a predetermined event (for example, a decrease in inventory amount exceeding a certain amount).
  • the storage unit 104 stores a program and data for processing by the application unit 102 and the communication control unit 110 using a storage medium such as a hard disk or a semiconductor memory. In addition, the storage unit 104 stores data serving as a basis for generating application data by the application unit 102. The storage unit 104 stores in advance at least a part of control information to be inserted into a data packet described later.
  • the communication control unit 110 When the application data to be transmitted to the application server 190 is input from the application unit 102, the communication control unit 110 generates a data packet including the application data. Then, the communication control unit 110 causes the wireless transmission unit 112 to transmit the generated data packet. In addition, when the wireless reception unit 114 receives a data packet, the communication control unit 110 acquires application data included in the data packet and outputs the application data to the application unit 102.
  • the wireless transmission unit 112 and the wireless reception unit 114 have an antenna and an RF (Radio Frequency) circuit.
  • the radio transmission unit 112 transmits the data packet generated by the communication control unit 110 to the base station 120 as a radio signal over the air interface.
  • the radio reception unit 114 receives a data packet transmitted from the base station 120 as a radio signal over the air interface, and outputs the received data packet to the communication control unit 110.
  • FIG. 3 is an explanatory diagram for explaining an example of a packet format of a data packet transmitted by the terminal device 100 in the present embodiment.
  • the data packet according to the present embodiment includes a header area HS and a data area DS.
  • the header area HS has eight fields F1 to F8 in which control information is stored.
  • the data area DS is an area for storing the application data described above.
  • the destination field F1 of the header area HS information specifying the destination node of the data packet is stored.
  • the information stored in the destination field F1 may be, for example, the IP (Internet Protocol) address, MAC (Media Access Control) address, host name, or other unique identifier of the destination node.
  • the application server 190 that provides the corresponding application function is the destination node. Further, when the terminal device 100 receives a data packet, the terminal device 100 becomes a destination node.
  • transmission source node information for specifying the transmission source node of the data packet is stored.
  • the terminal device 100 transmits application data to the application server 190, the terminal device 100 that generated the application data becomes a transmission source node.
  • Application (AP) class field F3 and AP ID (IDentifier) field F4 are fields for storing an AP class and an AP ID, respectively.
  • the AP class and AP ID are control information related to the application related to the data packet.
  • the AP class represents a class to which each application belongs when the application is classified into several classes. For example, a QoS class classified according to quality of service (QoS) requirements may be used as the AP class.
  • QoS quality of service
  • the AP ID is an identifier for uniquely identifying each application.
  • the AP class and AP ID values supported by each terminal device 100 can be stored in advance by the storage unit 104.
  • the terminal class field F5, the terminal group (Grp) field F6, and the terminal ID field F7 are fields for storing a terminal class, a terminal group, and a terminal ID, respectively.
  • the terminal class, terminal group, and terminal ID are control information related to the MTC terminal.
  • the terminal class and the terminal group respectively represent a class and a group to which each terminal device belongs when the MTC terminals are classified into several classes and groups.
  • the MTC terminal is a security device, a traffic-related device, a payment device, a health care-related device, a remote control device according to the service field. And can be classified into measuring equipment, consumer equipment, and the like.
  • MTC terminals may be classified in more detail according to their use, such as vending machines or point-of-sale (POS) devices for payment devices and power meters or gas meters for measurement devices. it can.
  • the terminal class may be, for example, a classification of MTC terminals according to such a service field or usage.
  • 3GPP TS22.368 proposes to assign each MTC terminal to one or more groups defined in terms of, for example, a QoS policy or a maximum bit rate.
  • the terminal group may be a group defined for managing such a group-based MTC terminal, for example.
  • classification of MTC terminals according to other concepts may be used.
  • the terminal ID is an identifier for uniquely identifying each terminal device.
  • the terminal class, terminal group, and terminal ID values of each terminal device 100 can be stored in advance by the storage unit 104.
  • the provider ID field F8 is a field for storing a provider ID that uniquely identifies a provider that provides an application related to the data packet transmitted by each terminal device 100.
  • the business operator ID can also be stored in advance by the storage unit 104.
  • FIG. 4 is a flowchart illustrating an example of the flow of data transmission processing by the terminal device 100 according to the present embodiment.
  • the application unit 102 of the terminal device 100 generates application data regularly or in response to occurrence of a predetermined event (step S102).
  • the communication control unit 110 acquires control information related to the application such as the AP class and the AP ID for the generated application data from the storage unit 104 (step S104). Further, the communication control unit 110 acquires control information such as a terminal class, a terminal group, and a terminal ID related to the MTC terminal of the terminal device 100 from the storage unit 104 (Step S106).
  • the communication control unit 110 generates a data packet having the packet format illustrated in FIG. 3 using the acquired control information and application data (step S108). The destination of the data packet generated here can be specified by the application unit 102 in association with the application data, for example.
  • the wireless transmission unit 112 transmits the data packet generated by the communication control unit 110 to the base station 120 (step S110).
  • the terminal device 100 inserts the control information into the data packet
  • other communication nodes for example, the base station 120 or the communication device 140
  • control information in the data packet instead of the terminal device 100. May be inserted.
  • the device that inserts the control information into the data packet may be a device that is not illustrated in FIG. 1 (for example, a relay station that may be interposed between the terminal device 100 and the base station 120).
  • the base station 120 inserts a part of control information into a data packet will be described as an example.
  • FIG. 5 is a block diagram illustrating an example of the configuration of the base station 120 according to the present embodiment.
  • the base station 120 includes a wireless reception unit 122, a wireless transmission unit 124, a transmission unit 126, a reception unit 128, a storage unit 130, and a communication control unit 132.
  • the wireless reception unit 122 and the wireless transmission unit 124 include an antenna and an RF circuit for performing wireless communication with the plurality of terminal devices 100.
  • the wireless reception unit 122 receives a data packet transmitted from the terminal device 100 and outputs the received data packet to the communication control unit 132.
  • the wireless transmission unit 124 transmits the data packet to the terminal device 100.
  • the transmission unit 126 and the reception unit 128 are communication interfaces for the base station 120 to communicate with the communication device 140 of the core network 10.
  • the transmission unit 126 transmits the data packet to the core network 10.
  • the receiving unit 128 outputs the data packet to the communication control unit 132.
  • the storage unit 130 stores a program and data for processing by the communication control unit 132 using a storage medium. Further, the storage unit 130 may store in advance a part of the control information illustrated in FIG. 3 in association with the terminal ID or address information of each terminal device 100.
  • the communication control unit 132 causes the base station 120 to operate as a base station for cellular communication according to standard specifications such as LTE or LTE-A.
  • the communication control unit 132 can insert the control information described above into a data packet transmitted from the terminal device 100 instead of the terminal device 100. For example, when a data packet from the terminal device 100 is input from the wireless reception unit 122, the communication control unit 132 stores control information associated with the terminal ID or the transmission source address described in the data packet. From 130. Then, the communication control unit 132 inserts the acquired control information into the data packet.
  • FIG. 6 is a flowchart showing an example of the flow of control information insertion processing by the base station 120 according to this embodiment.
  • the radio reception unit 122 of the base station 120 receives a data packet transmitted from the terminal device 100 (step S122). Then, the wireless reception unit 122 outputs the received data packet to the communication control unit 132. Next, the communication control unit 132 determines whether or not the received data packet is a packet for MTC communication (step S124).
  • the packet for MTC communication includes both a packet whose source is an MTC terminal and a packet whose final destination is an MTC terminal.
  • the communication control unit 132 refers to the terminal group or the terminal class included in the data packet, or collates the terminal ID included in the data packet with an ID list registered in advance, so that the data packet is transferred to the MTC communication. It is possible to determine whether or not the packet is for.
  • the communication control unit 132 refers to the AP class included in the data packet, or collates the AP ID included in the data packet with an ID list registered in advance, so that the data packet is MTC. It may be determined whether the packet is for communication. Here, if the data packet is a packet for MTC communication, processing in steps S126 and S128 is subsequently performed.
  • the communication control unit 132 inserts control information (AP class, AP ID, etc.) related to the application into the data packet (step S126). Further, the communication control unit 132 inserts control information (such as a terminal class or a terminal group) regarding the MTC terminal into the data packet (step S128).
  • control information AP class, AP ID, etc.
  • the communication control unit 132 regenerates the data packet (step S130). Then, the regenerated data packet is transferred from the transmission unit 126 to the core network 10 (step S132).
  • FIG. 7 is a block diagram illustrating an example of the configuration of the communication device 140 according to the present embodiment.
  • the communication device 140 includes a reception unit 142, a transmission unit 144, a storage unit 150, and a communication control unit 152.
  • the receiving unit 142 and the transmitting unit 144 are communication interfaces for the communication device 140 to communicate with other communication devices.
  • the receiving unit 142 When receiving a data packet from another communication device, the receiving unit 142 outputs the data packet to the communication control unit 152.
  • the transmission unit 144 transmits the data packet to another communication device.
  • the storage unit 150 stores a program and data for processing by the communication control unit 152 using a storage medium.
  • the storage unit 150 also stores transfer destination data that associates the classification based on the control information in the data packet with the transfer destination node of the data packet.
  • transfer destination data stored in the storage unit 150 will be described later with an example.
  • the communication control unit 152 transmits data packet transfer destination nodes from a plurality of transfer destination node candidates so that traffic is distributed when the transmission source device of the data packet received by the reception unit 142 is an MTC terminal. Select. More specifically, in the present embodiment, the communication control unit 152 selects a data packet transfer destination node based on control information in the data packet. For example, the communication control unit 152 classifies the data packet according to the control information in the data packet, and sets the transfer destination node associated with the classification of the data packet in the transfer destination data stored in the storage unit 150. The data packet may be selected as a transfer destination node.
  • the communication control unit 152 may select the transfer destination node of each data packet so that the transfer destination of the data packet belonging to the same classification is distributed to a plurality of transfer destination nodes.
  • the selection of the transfer destination node by the communication control unit 152 is typically performed regardless of the routing metric regarding the route to the destination node of the data packet. That is, the communication apparatus 140 according to the present embodiment does not necessarily select a transfer destination node that minimizes a metric such as the number of hops to the destination node or the cost of the communication path.
  • 8A and 8B are explanatory diagrams for describing an example of transfer destination data that can be used for selection of a transfer destination node by the communication device 140, respectively.
  • transfer destination data 151a as a first example is shown.
  • the transfer destination data 151a has three data items of “application class”, “terminal ID”, and “transfer destination node”.
  • the communication control unit 152 classifies the data packet into six categories according to the application class and the terminal ID included in the control information in the data packet. For example, when the application class is “C1”, the data packet is classified into one of the first to fourth categories according to the lower 2 bits of the terminal ID.
  • the application class is “C2”
  • the data packet is classified into the fifth category regardless of the terminal ID.
  • the transfer destination node of the data packet classified into the fifth category is the node N5.
  • the application class is “C3”
  • the data packet is classified into the sixth category regardless of the terminal ID.
  • the transfer destination node of the data packet classified into the sixth category is the node N6.
  • the application class “C1” is, for example, a class for which low delay is recommended for QoS (for example, an upper limit value of allowable delay is specified).
  • the communication control unit 152 distributes the transfer destination of the data packet of the application class “C1” among the four transfer destination nodes N1 to N4 by using, for example, the round robin method or the random method without using the terminal ID. Also good.
  • data packets of different application classes are transferred to different transfer destination nodes.
  • the node N5 and the node N6 may be nodes that do not have high throughput or nodes that have a low-speed link compared to the nodes N1 to N4.
  • transfer destination data 151b as a second example is shown.
  • the transfer destination data 151b has two data items “terminal class” and “transfer destination node”.
  • the communication control unit 152 classifies the data packet into four categories according to the terminal class included in the control information in the data packet. For example, when the terminal class is “T1”, the data packet is classified into the first category, and the node N1 is selected as the transfer destination node.
  • the terminal class is “T2”
  • the data packet is classified into the second category, and the node N2 is selected as the transfer destination node.
  • the terminal class is “T3”
  • the data packet is classified into the third category, and the node N3 is selected as the transfer destination node.
  • the terminal class is “T4”
  • the data packet is classified into the fourth category, and the node N4 is selected as the transfer destination node.
  • the communication control unit 152 may distribute the transfer destination of the data packet from the terminal device 100 of the same terminal class among the four transfer destination nodes N1 to N4 by the round robin method or the random method.
  • a terminal group may be used instead of the terminal class.
  • the content of the transfer destination node data may be different for each communication device 140 that functions as the transfer destination node. That is, the first transfer destination node may have the transfer destination data illustrated in FIG. 8A, while the second transfer destination node may have the transfer destination data illustrated in FIG. 8B.
  • the transfer destination node data may be individually registered and updated in each transfer destination node, or may be collectively managed and dynamically updated in an information management server as described in the second embodiment. .
  • FIG. 9 is a flowchart showing an example of the flow of data transfer processing by the communication device 140 according to this embodiment.
  • the receiving unit 142 of the communication device 140 receives a data packet transmitted from the terminal device 100 (step S142). Then, the reception unit 142 outputs the received data packet to the communication control unit 152. Next, the communication control unit 152 determines whether or not the received data packet is a packet for MTC communication (step S144). If the data packet is a packet for MTC communication, the process proceeds to step S146. On the other hand, if the data packet is not a packet for MTC communication, the process proceeds to step S154.
  • step S146 the communication control unit 152 acquires control information included in the header area of the data packet (step S146).
  • the communication control unit 152 classifies the data packet into one of a plurality of categories according to the acquired control information (step S148).
  • the communication control unit 152 determines whether or not the transfer destination node corresponding to the category to which the data packet belongs exists in the transfer destination node data stored in the storage unit 150 (step S150). If the corresponding transfer destination node exists in the transfer destination node data, the process proceeds to step S152. On the other hand, if the corresponding transfer destination node does not exist in the transfer destination node data, the process proceeds to step S154.
  • step S152 the communication control unit 152 selects the transfer destination node associated with the category to which the data packet belongs in the transfer destination node data as the transfer destination node of the data packet (step S152).
  • step S154 the communication control unit 152 selects a predetermined transfer destination node as a data packet transfer destination node (step S154).
  • the predetermined transfer destination node may be, for example, a transfer destination node that is fixedly defined in advance, or may be a transfer destination node that is dynamically selected according to a routing metric.
  • the transmission unit 144 transfers the data packet to the transfer destination node selected by the communication control unit 152 (step S156).
  • a transfer node in the communication network selects a transfer destination node from a plurality of transfer destination node candidates, and transmits the selected transfer destination node to the selected transfer destination node.
  • Data packet is forwarded.
  • traffic of MTC communication can be routed to a plurality of routes, and congestion can be avoided or alleviated.
  • the number of MTC terminals that can be accommodated in the communication system can be increased.
  • the forwarding node selects the forwarding destination node based on the control information in the data packet.
  • control information may be used to classify data packets in terms of applications related to MTC communication or the type of MTC terminal.
  • data packets can be systematically distributed according to the type of application or the type of terminal. For example, it is possible to distribute the transfer destinations of data packets of the same kind of application or the same kind of terminal that may transmit data all at once among a plurality of transfer destination nodes. Therefore, the occurrence of congestion due to MTC communication can be avoided in advance, or the congestion can be effectively reduced.
  • the above-described congestion avoidance can be achieved without impacting the processing logic on existing devices such as MTC terminals or base stations.
  • Mechanism can be introduced.
  • the selection of the transfer destination node in the transfer node can be performed regardless of the routing metric relating to the route to the destination node.
  • the transfer destination node selection mechanism described above is also applicable to data packets transmitted to the MTC terminal.
  • the communication device 140 illustrated in FIG. 1 has additional transfer destination data that describes a plurality of transfer destination node candidates for a data packet transmitted to the terminal device 100, and includes control information in the data packet. Based on the additional transfer destination data, a transfer destination node of a data packet transmitted to the terminal device 100 may be selected from a plurality of transfer destination node candidates so that traffic is distributed.
  • the forwarding node distributes the traffic of the MTC communication, thereby preventing the traffic from being concentrated on a specific communication path.
  • the concentration of traffic on a specific communication path is also prevented by guiding MTC communication traffic to a path via an intermediate node described later.
  • FIG. 10 is a schematic diagram illustrating an overview of the communication system 2 according to the second embodiment.
  • the communication system 2 includes a plurality of terminal devices 200a to 200d, a plurality of base stations 220a to 220c, communication devices 140, 240a and 240b in the core network 10, an information management server 270, and a plurality of application servers. 190a-190c.
  • the terminal device 200 is a wireless communication device that operates as an MTC terminal, like the terminal device 100 according to the first embodiment.
  • Each terminal device 200 transmits and receives radio signals to and from the base station 220 that provides a radio communication service to the cell to which the terminal device 200 belongs.
  • the terminal device 200 generates application data and transmits a data packet including the generated application data to the base station 220.
  • the data packet transmitted from the terminal device 200 to the base station 220 is finally delivered to the target application server 190 via some communication nodes.
  • the terminal device 200 can specify information specifying a communication node different from the destination node that is the final destination in the destination field of the data packet.
  • a communication node designated as a temporary destination (not a final destination) of a data packet transmitted from an MTC terminal is referred to as an intermediate node.
  • the base station 220 is a communication that provides a wireless communication service in a cell that spreads around its own device, for example, according to a cellular communication method represented by LTE or LTE-Advanced. It is a node.
  • the base station 220 receives a data packet including application data generated by the terminal device 200 and transfers the received data packet to the communication node of the core network 10.
  • the base station 220 can insert information specifying the intermediate node in the destination field of the data packet to be transferred. Further, the base station 220 receives the data packet addressed to the terminal device 200 transferred via the core network 10 and transfers the received data packet to the destination terminal device 200.
  • the communication device 240 is a communication node that may be designated as an intermediate node.
  • Each communication device 240 may be, for example, an RNC, MME, HSS, SGSN, or GGSN, or may be a switch or a router that connects these communication nodes.
  • the communication device 240 receives, for example, the data packet specified in the destination field by the communication device 240, identifies an appropriate destination node using the control information in the data packet, and moves toward the identified destination node. Transfer data packets.
  • the information management server 270 is a communication device that manages the master of destination node data used when the intermediate node identifies the destination node.
  • the information management server 270 is connected to the network 20.
  • the present invention is not limited to this example, and the information management server 270 may exist in the core network 10, for example. Further, the information management server 270 may be mounted on the same physical device as the communication nodes forming the core network 10.
  • the information management server 270 may manage the master of the transfer destination data described in the first embodiment in addition to the master of the destination node data.
  • FIG. 11 is a block diagram illustrating an example of the configuration of the terminal device 200 according to the present embodiment.
  • the terminal device 200 includes an application unit 102, a storage unit 204, a communication control unit 210, a wireless transmission unit 112, and a wireless reception unit 114.
  • the storage unit 204 stores a program and data for processing by the application unit 102 and the communication control unit 210 using a storage medium.
  • the storage unit 204 stores data serving as a basis for generating application data by the application unit 102, similarly to the storage unit 104 of the terminal device 100 according to the first embodiment.
  • the storage unit 204 stores in advance control information to be inserted into the data packet.
  • the storage unit 204 stores in advance, in association with, for example, an application, intermediate node designation information for designating an intermediate node different from the destination node on the route to the final destination node of the data packet.
  • the intermediate node designation information may be, for example, the IP address, MAC address, host name, or other unique identifier of the intermediate node.
  • the communication control unit 210 When the application data to be transmitted to the application server 190 is input from the application unit 102, the communication control unit 210 generates a data packet including the application data. At this time, the communication control unit 210 can insert intermediate node designation information stored in association with the application in the storage unit 204 in the destination field of the data packet. Then, the communication control unit 210 causes the wireless transmission unit 112 to transmit the generated data packet. In addition, when the wireless reception unit 114 receives a data packet, the communication control unit 210 acquires application data included in the data packet and outputs the application data to the application unit 102.
  • FIG. 12 is a flowchart showing an example of the flow of data transmission processing by the terminal device 200 according to the present embodiment.
  • the application unit 102 of the terminal device 200 generates application data periodically or in response to occurrence of a predetermined event (step S202).
  • the communication control unit 210 acquires control information related to the application such as the AP class and the AP ID for the generated application data from the storage unit 204 (step S204). Also, the communication control unit 210 acquires control information such as a terminal class, a terminal group, and a terminal ID related to the MTC terminal of the terminal device 200 from the storage unit 204 (step S206). Next, the communication control unit 210 acquires the intermediate node designation information to be inserted into the destination field of the data packet from the storage unit 204 (step S208).
  • the communication control unit 210 generates a data packet including the acquired intermediate node designation information and control information in the header area and application data in the data area (step S210). Then, the wireless transmission unit 112 transmits the data packet generated by the communication control unit 210 to the base station 220 (step S212).
  • the terminal device 200 inserts the control information into the data packet
  • other communication nodes for example, the base station 220 or the communication device 240
  • control information in the data packet instead of the terminal device 200. May be inserted.
  • another communication node may insert the intermediate node designation information into the destination field.
  • the device that inserts the intermediate node designation information into the destination field may be a device that is not illustrated in FIG. 10 (for example, a relay station that may be interposed between the terminal device 200 and the base station 220).
  • the terminal device 200 can insert destination node designation information for designating the final destination node in the destination field, as in general data transmission processing.
  • FIG. 13 is a block diagram illustrating an example of the configuration of the base station 220 according to the present embodiment.
  • the base station 220 includes a radio reception unit 122, a radio transmission unit 124, a transmission unit 126, a reception unit 128, a storage unit 230, and a communication control unit 232.
  • the storage unit 230 stores a program and data for processing by the communication control unit 232 using a storage medium. Further, the storage unit 230 stores in advance at least a part of the control information illustrated in FIG. 3 in association with the terminal ID or address information of each terminal device 200. In the present embodiment, the storage unit 230 stores in advance intermediate node data in which candidates for intermediate nodes to be designated for data packets are listed.
  • FIG. 14A and 14B are explanatory diagrams for explaining an example of intermediate node data, respectively.
  • intermediate node data 231a as a first example is shown.
  • the intermediate node data 231a includes two data items “application class” and “intermediate node”.
  • the intermediate node data 231a is data defining an intermediate node to be designated for each application class of the data packet.
  • intermediate node data 231b as a second example is shown.
  • the intermediate node data 231b includes two data items “terminal class” and “intermediate node”.
  • the intermediate node data 231b is data defining an intermediate node to be specified for each terminal class of the data packet.
  • the intermediate node data may be data defining an intermediate node in association with arbitrary control information as illustrated in FIG.
  • the communication control unit 232 operates the base station 220 as a base station for cellular communication according to standard specifications such as LTE or LTE-A, for example.
  • the communication control unit 232 specifies an intermediate node that specifies an intermediate node different from the final destination node of the data packet in the destination field of the data packet received by the wireless reception unit 122. Information can be inserted. For example, when a data packet from the terminal device 200 is input from the wireless reception unit 122, the communication control unit 232 stores an intermediate node associated with the application class or the terminal class described in the data packet as a storage unit
  • the intermediate node data stored in the above-described intermediate node data 230 is used for identification.
  • the communication control unit 232 inserts intermediate node designation information for designating the identified intermediate node into the destination field of the data packet.
  • a plurality of patterns of the update process of the destination field here will be described in detail later with examples.
  • the communication control unit 232 may designate a different intermediate node for each data packet from a plurality of intermediate node candidates by, for example, a round robin method or a random method.
  • the communication control unit 232 inserts control information used by the intermediate node to identify the final destination node of the data packet into the data packet transmitted from the terminal device 200 instead of the terminal device 200. May be.
  • the control information used for identifying the final destination node may include, for example, at least one of the control information described with reference to FIG.
  • FIGS. 15A to 15E are explanatory diagrams for explaining an example of the destination field update process by the communication control unit 232 according to this embodiment. In each figure, the contents of the destination field before and after the update by the communication control unit 232 are shown.
  • the communication control unit 232 simply sets the information regarding the destination node inserted in the destination field F1 of the data packet as intermediate node designation information (for example, the IP address of the intermediate node). Or host name). In this case, the destination field update process can be realized most simply.
  • the communication control unit 232 overwrites the information regarding the destination node inserted in the destination field F1 of the data packet with the intermediate node designation information (F1b), and at the same time, the destination field A flag indicating that F1 has been changed is added to the data packet (F1a).
  • the intermediate node receiving the updated data packet can know whether or not the destination field F1 has been changed by referring to the flag.
  • the position of the flag in the data packet may be a position different from the position illustrated in FIG. 15B.
  • the destination field F1 is divided in advance into a flag subfield F1a and node information subfield F1b.
  • the terminal device 200 sets a flag of the subfield F1a to zero and transmits a data packet in which information regarding the destination node is inserted into the subfield F1b.
  • the communication control unit 232 of the base station 220 updates the flag of the subfield F1a to 1, and overwrites the subfield F1b with the intermediate node designation information.
  • all the communication nodes that receive the data packet can know whether or not the destination field F1 has been changed by referring to the flag subfield F1a.
  • the communication control unit 232 updates the flag to 1, inserts intermediate node designation information into the destination field F1, and is described in the destination field F1 when receiving the data packet. Is transferred to the spare field F9.
  • the intermediate node that receives the updated data packet can identify the final destination node by referring to the information on the destination node transferred in the spare field F9.
  • the fifth example shown in FIG. 15E shows an example of a destination field update process that can be adopted when a plurality of intermediate nodes are designated in order when transferring one data packet.
  • the communication control unit 232 of the base station 220 inserts the intermediate node designation information into the destination field F1, and also designates information for designating the final destination node (destination node 1) in the spare field F9. copy.
  • the intermediate node that has received the data packet inserts new intermediate node designation information in the destination field F1, and further transfers the original intermediate node designation information described in the destination field F1 to the spare field F9. To do.
  • the intermediate node that receives the updated data packet can easily know the number of node information transcribed in the spare field F9.
  • the spare field F9 represents an intermediate node designation history, it is possible to prevent a loop-shaped communication path from being formed by designating one intermediate node a plurality of times.
  • FIGS. 16A and 16B are flowcharts showing an example of the flow of data transfer processing by the base station 220 according to the present embodiment, respectively.
  • FIG. 16A shows an example of a flow including the destination field update process exemplified in FIGS. 15A to 15C.
  • the radio reception unit 122 of the base station 220 receives a data packet transmitted from the terminal device 200 (step S222). Then, wireless reception unit 122 outputs the received data packet to communication control unit 232.
  • the communication control unit 232 determines whether or not the received data packet is a packet for MTC communication (step S224). Here, if the data packet is a packet for MTC communication, processing in steps S226 to S232 is subsequently performed.
  • the communication control unit 232 specifies an intermediate node to be specified in the destination field of the data packet using the intermediate node data (step S226).
  • the communication control unit 232 inserts intermediate node designation information for designating the identified intermediate node into the destination field of the data packet (step S230).
  • the data packet is transferred from the transmission unit 126 to the core network 10 (step S234).
  • FIG. 16B shows an example of a flow including the destination field update process exemplified in FIGS. 15D and 15E.
  • the radio reception unit 122 of the base station 220 receives a data packet transmitted from the terminal device 200 (step S222). Then, wireless reception unit 122 outputs the received data packet to communication control unit 232.
  • the communication control unit 232 determines whether or not the received data packet is a packet for MTC communication (step S224). Here, if the data packet is a packet for MTC communication, processing in steps S226 to S233 is subsequently performed.
  • the communication control unit 232 specifies an intermediate node to be specified in the destination field of the data packet using the intermediate node data (step S226).
  • the communication control unit 232 transfers information on the destination node described in the destination field to the other field such as a spare field when the data packet is received (step S228).
  • the communication control unit 232 inserts intermediate node designation information for designating the identified intermediate node into the destination field of the data packet (step S230).
  • the communication control unit 232 updates the flag (step S233).
  • the data packet is transferred from the transmission unit 126 to the core network 10 (step S234).
  • FIG. 17 is a block diagram illustrating an example of the configuration of the communication device 240 that operates as an intermediate node.
  • the communication device 240 includes a reception unit 142, a transmission unit 144, a storage unit 250, a communication control unit 252, and an information management unit 254.
  • the storage unit 250 stores a program and data for processing by the communication control unit 252 and the information management unit 254 using a storage medium.
  • the storage unit 250 may store destination node data (to be described later) that associates the control information in the data packet with the destination node of the data packet.
  • the storage unit 250 may store transfer destination data that associates control information in a data packet with a transfer destination node of the data packet, similarly to the storage unit 150 of the communication device 140 according to the first embodiment.
  • the communication control unit 252 determines the final destination node of the data packet from the information included in the field different from the destination field. Identify More specifically, the communication control unit 252 identifies the final destination node for each data packet using, for example, the destination node data that associates the control information in the data packet with the destination node of the data packet. can do.
  • FIG. 18 is an explanatory diagram for explaining an example of destination node data that can be stored in the storage unit 250.
  • destination node data 251 as an example has four data items of “application class”, “terminal class”, “operator”, and “destination node”.
  • the combination of “application class”, “terminal class”, and “provider” serves as an identification key for identifying any destination node.
  • a data packet in which the application class is “C1”, the terminal class is “T3”, and the provider is “J01” corresponds to the destination node D1.
  • a data packet whose application class is “C1”, terminal class is “T3”, and service provider is “J02” corresponds to the destination node D2 (the description of the remaining records is omitted).
  • Control information that can be used as an identification key for identifying a destination node is not limited to such an example.
  • any item of the control information (or other control information) illustrated in FIG. 3 may be used as an identification key for identifying the destination node.
  • such destination node data is managed by the information management server 270 illustrated in FIG. 10 and can be shared between intermediate nodes.
  • the communication control unit 252 can identify the destination node corresponding to the control information in the data packet as the final destination node. In addition, when the information regarding the destination node is transferred to the backup field by the device that designates the intermediate node (for example, the base station 220 described above), the communication control unit 252 does not use the destination node data. The final destination node can be identified. In that case, the storage unit 250 may not store the destination node data illustrated in FIG.
  • the communication control unit 252 inserts destination node designation information for designating the identified destination node as described above into the destination field of the data packet. In other words, the communication control unit 252 corrects the temporarily specified destination field information to the destination node information that the data packet should finally reach. Then, the communication control unit 252 causes the transmission unit 144 to transmit the data packet including the final destination node designation information in the destination field.
  • the communication control unit 252 selects a data packet transfer destination node (next hop) from a plurality of transfer destination node candidates so that traffic is distributed, as in the transfer node according to the first embodiment. May be. Further, the communication control unit 252 inserts intermediate node designation information for designating another intermediate node in the destination field instead of the final destination node, and further forwards the data packet to the other intermediate node. May be.
  • the information management unit 254 acquires update data for updating the destination node data stored in the storage unit 250 from the information management server 270, and updates the destination node data using the acquired update data.
  • the information management unit 254 may periodically request the information management server 270 to distribute update data at a certain frequency. Instead, the information management unit 254 may passively update the destination node data when update data is received from the information management server 270.
  • FIGS. 19A and 19B are flowcharts showing an example of the flow of data transfer processing by the communication device 240 according to the present embodiment, respectively.
  • FIG. 19A shows an example of a flow including destination node identification processing using destination node data.
  • the receiving unit 142 of the communication device 240 receives a data packet transmitted from the terminal device 200 (step S242). Then, the reception unit 142 outputs the received data packet to the communication control unit 252.
  • the communication control unit 252 determines whether or not the received data packet is a packet for MTC communication (step S244). If the data packet is a packet for MTC communication, the process proceeds to step S246. On the other hand, if the data packet is not a packet for MTC communication, the process proceeds to step S254.
  • step S246 the communication control unit 252 acquires control information included in the header area of the data packet (step S246).
  • the communication control unit 252 identifies the transfer destination node corresponding to the combination of the application class, the terminal class, and the provider included in the acquired control information using the destination node data (step S248).
  • the communication control unit 252 inserts destination node designation information for designating the identified destination node into the destination field of the data packet (step S250).
  • the communication control unit 252 updates the value of the flag in the data packet as necessary.
  • the transmission unit 144 transfers the data packet to the next hop (for example, a transfer destination node or a predetermined communication node selected so that traffic is distributed) (step S254).
  • FIG. 19B shows an example of the flow of data transfer processing that does not use the destination node data.
  • the receiving unit 142 of the communication device 240 receives a data packet transmitted from the terminal device 200 (step S242). Then, the reception unit 142 outputs the received data packet to the communication control unit 252.
  • the communication control unit 252 determines whether or not the received data packet is a packet for MTC communication (step S244). Here, if the data packet is a packet for MTC communication, the process proceeds to step S247. On the other hand, if the data packet is not a packet for MTC communication, the process proceeds to step S254.
  • step S247 the communication control unit 252 determines whether or not the destination field has been changed by referring to the flag in the data packet (step S247). If the destination field has been changed, the process proceeds to step S249. On the other hand, if the destination field has not been changed, the process proceeds to step S254.
  • step S249 the communication control unit 252 identifies the destination node from the information transferred in the spare field in the data packet (step S249). Then, the communication control unit 252 inserts destination node designation information for designating the identified destination node into the destination field of the data packet (step S252). At this time, the communication control unit 252 updates the value of the flag in the data packet as necessary.
  • the transmission unit 144 transfers the data packet to the next hop (for example, a transfer destination node or a predetermined communication node selected so that traffic is distributed) (step S254).
  • FIG. 20 is an explanatory diagram for describing an example of a communication path that can be realized by the present embodiment.
  • a terminal device 200 that is a transmission source of MTC communication as an example and an application server 190 that is a destination are illustrated.
  • incidental control signaling such as ACK and NACK is not shown in the figure.
  • the communication route R1 is the shortest route (having the optimum routing metric) between the terminal device 200 and the application server 190.
  • the communication paths R2 and R3 are redundant paths that bypass some links included in the communication path R1.
  • the data packet can reach the application server 190 via the communication path R2.
  • the terminal device 200 or the base station 220 designates the intermediate node M2
  • the intermediate node M2 designates the intermediate node M3
  • the data packet reaches the application server 190 via the communication path R3.
  • Can do By diverting the data packet of MTC communication from the shortest path in this way, traffic is distributed, and concentration of traffic on a specific communication path is prevented beforehand.
  • FIG. 21 is a block diagram showing an example of the configuration of the information management server 270 according to the present embodiment.
  • the information management server 270 includes a reception unit 272, a transmission unit 274, a storage unit 280, and an information management unit 282.
  • the receiving unit 272 and the transmitting unit 274 are communication interfaces for the information management server 270 to communicate with other communication devices.
  • the storage unit 280 uses a storage medium to store a master of destination node data having data items similar to the destination node data illustrated in FIG.
  • the storage unit 280 may store a master of intermediate node data having the same data items as the intermediate node data illustrated in FIGS. 14A and 14B. Furthermore, the storage unit 280 may store the master of the transfer destination data described in the first embodiment.
  • the information management unit 282 provides a master management function for information stored in the storage unit 280.
  • the information management unit 282 provides an interface for accepting registration of new information related to an application when the application server 190 is newly introduced into the communication system 2.
  • the interface may be, for example, a graphical user interface (GUI) that receives information input from the user on the screen of the apparatus.
  • GUI graphical user interface
  • the interface may be, for example, an API (Application Program Interface) that receives registration information from the application server 190.
  • the interface provided by the information management unit 282 may accept changes and deletions of registered information.
  • the information management unit 282 distributes update data based on the master difference to the communication nodes included in the communication system 2.
  • FIG. 22 is an explanatory diagram for describing an example of update data.
  • the business operator J01 newly introduces application servers D1, D3, and D5.
  • the user (engineer) of the business operator J01 registers information about each of the application servers D1, D3, and D5 in the information management server 270 via the user interface provided by the information management unit 282.
  • the information registered here may include, for example, an application class, a terminal class, a communication schedule for MTC communication, and the like corresponding to each application server.
  • the information management unit 282 updates the master of the destination node data stored in the storage unit 280, and generates update data 283 as illustrated in FIG.
  • the update data 283 is data describing information on the corresponding application class, terminal class, and communication schedule for each application server that can be a candidate for the destination node using the carrier ID as a key.
  • Each record of the update data 283 is given an “update category” that can take a value such as “add”, “change”, or “delete”.
  • the intermediate node that has received such update data 283 from the information management server 270 uses the update data 283 to synchronize the destination node data stored individually with the latest master.
  • FIGS. 23A and 23B are flowcharts illustrating an example of the flow of update data distribution processing by the information management server 270 according to the present embodiment, respectively.
  • FIG. 23A shows an example in which update data is distributed to an intermediate node each time a master is updated.
  • the information management unit 282 of the information management server 270 acquires registration information about the application server 190 via the GUI (or from the application server 190) (step S272).
  • the information management unit 282 updates the master of the destination node data stored in the storage unit 280 using the acquired registration information (step S274).
  • the information management unit 282 generates update data illustrated in FIG. 22 based on the master difference generated by the update (step S276).
  • the transmission unit 274 distributes the update data generated by the information management unit 282 to each intermediate node (step S278).
  • the update data may be broadcast to each intermediate node, or may be individually unicast or multicast.
  • FIG. 23B shows an example in which update data is distributed to an intermediate node in response to a request from the intermediate node.
  • the process proceeds to step S284 (step S282).
  • step S284 the information management unit 282 determines whether a difference has occurred in the master of the destination node data since the previous distribution of the update data (step S284). If there is a difference in the master of the destination node data, the information management unit 282 generates update data based on the master difference (step S286). Then, the transmission unit 274 distributes the update data generated by the information management unit 282 to the requesting intermediate node (step S278). On the other hand, if there is no difference in the master of the destination node data, the information management unit 282 notifies the requesting intermediate node that there is no difference (step S289).
  • the information management server 270 is not limited to the examples of FIGS. 23A and 23B, and the information management server 270 determines whether or not there is a master difference periodically at a certain frequency, for example. Update data may be distributed to the nodes.
  • FIG. 24 is a flowchart showing an example of the flow of destination node data update processing by the intermediate node according to this embodiment.
  • the receiving unit 142 of the communication device 240 receives the update data of the destination node data distributed from the information management server 270 (step S291).
  • the information management unit 254 determines whether or not a new application class exists in the update data (step S292). If a new application class exists in the update data, the new application class is added to the destination node data 251 illustrated in FIG. 18 (step S293). Further, the information management unit 254 determines whether or not a new terminal class exists in the update data (step S294). If a new terminal class exists in the update data, the new terminal class is added to the destination node data 251 (step S295).
  • the information management unit 254 determines whether or not the business ID in the update data is the business ID of a new business (step S296). If the business ID in the update data is the business ID of the new business, the business ID of the new business is added to the destination node data 251 (step S297). Then, the information management unit 254 adds a destination node (information such as an IP address or a host name) corresponding to the combination of the application class, the terminal class, and the carrier ID in the update data to the destination node data 251. Alternatively, the existing destination node is updated (step S298).
  • the communication schedule information included in the update data 283 illustrated in FIG. 22 can be distributed from the intermediate node to each corresponding terminal device 200.
  • the information management server 270 may distribute communication schedule information to each terminal device 200 separately from the update data 283.
  • Each terminal device 200 that has received the communication schedule information controls the sleep time of the own device according to the communication schedule information and realizes an intermittent operation (DRX: Discontinuous Reception).
  • the intermittent operation of the terminal device 200 is controlled according to a simple parameter such as once a day (“every day”) or once a week (“every week”) as in the communication schedule information illustrated in FIG. May be.
  • a simple parameter such as once a day (“every day”) or once a week (“every week”) as in the communication schedule information illustrated in FIG. May be.
  • the radio reception unit 122 and the radio transmission unit 124 of the terminal device 200 wake up at an arbitrary time zone once a day
  • Application data is generated in the time zone and the above-described data packet is transmitted to the application server 190.
  • the communication schedule information may include information related to a wake-up time zone (for example, a start time and an end time or a time length) in addition to the intermittent operation cycle.
  • the base station 220 or other communication node may determine a shorter period of auxiliary intermittent operation in the above-described wake-up time zone. In that case, the radio reception unit 122 and the radio transmission unit 124 of the terminal device 200 sleep in the designated wake-up time period, for example, except for the timing when communication resources are scheduled for the own device. obtain. Thereby, the power consumption of the terminal device 200 can be greatly reduced.
  • intermediate node designation information for designating an intermediate node different from the destination node on the route to the destination node of the data packet is inserted into the destination field of the data packet transmitted from the MTC terminal. Is done. Thereby, the traffic of the MTC communication is detoured to the route via the designated intermediate node without being concentrated on the specific communication route. As a result, traffic is distributed, and traffic congestion in MTC communication is avoided or alleviated.
  • the device that inserts the intermediate node designation information in the destination field may be a communication node (for example, a base station) that receives a data packet from the MTC terminal.
  • a communication node for example, a base station
  • the congestion avoidance technique according to the above-described embodiment can be introduced without giving an impact such as modification of processing logic to the MTC terminal. .
  • the designated intermediate node can determine the final destination node of the data packet from the control information regarding the MTC terminal inserted in the data packet or the information transferred in the preliminary field. Identify Therefore, even when the destination field of the data packet is changed, the data packet can be appropriately delivered to the final destination node (for example, a corresponding application server) via the intermediate node.
  • the destination node when the destination node is identified using the control information related to the MTC terminal, it is not necessary to transfer the information related to the destination node to the preliminary field. Can be used.
  • the destination node when the destination node is identified from the information posted in the preliminary field, each intermediate node does not have to hold the destination node data, so the processing cost required for referring to the destination node data and Storage medium resources can be reduced.
  • the intermediate node designation mechanism described above can also be applied to data packets transmitted to the MTC terminal.
  • the communication device 140 illustrated in FIG. 10 inserts intermediate node designation information into the destination field of the data packet transmitted to the terminal device 200 according to the destination field update processing illustrated in FIG. 15D or 15E, Information such as the address of the terminal device 200 described in the destination field may be transferred to the spare field.
  • a series of control processing by each device described in this specification may be realized using any of software, hardware, and a combination of software and hardware.
  • a program constituting the software is stored in advance in a storage medium provided inside or outside each device.
  • Each program is read into a RAM (Random Access Memory) at the time of execution and executed by a processor such as a CPU (Central Processing Unit).
  • a processor such as a CPU (Central Processing Unit).
  • the terminal devices 100 and 200 which are MTC terminals access the network through wireless communication has been mainly described.
  • the effects of the two embodiments described above can be equally enjoyed when the MTC terminal accesses the network by wired communication.

Abstract

【課題】ＭＴＣ通信におけるトラフィックの輻輳を回避し又は緩和すること。 【解決手段】複数の通信ノードを含む通信ネットワーク内の通信装置であって、端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、上記端末装置がＭＴＣ端末である場合に、複数の転送先ノードの候補から上記データパケットの転送先ノードを選択する通信制御部と、上記通信制御部により選択される転送先ノードへ上記データパケットを送信する送信部と、を備える通信装置を提供する。

Description

通信装置、通信制御方法及び通信システム
　本開示は、通信装置、通信制御方法及び通信システムに関する。
　近年、人間が介在することなく通信ネットワークに接続する端末装置が自ら通信を行う、ＭＴＣ（Machine-Type　Communication）通信又はＭ２Ｍ（Machine-to-Machine）通信と呼ばれる通信の一形態の利用が広まっている。例えば、家庭用ガスのメータをＭＴＣ端末とし、メータから定期的にガスの残量を事業者のサーバに送信することで、事業者は、検針員による検針作業を要することなく、各家庭でのガスの利用量を把握することができる。また、例えば、自動販売機からの在庫量の送信、コピー機からのトナー残量の送信、運輸業における輸送管理、及びセキュリティのための監視といった様々な用途に、ＭＴＣ通信は利用され得る。ＭＴＣ通信の利用は、今後も拡大していくことが予想されている。
　ＭＴＣ通信の利用が広まるにつれて、通信ネットワークが収容すべき端末の数は格段に増加する。その結果、通信ネットワーク内でトラフィックの輻輳が発生し、通信障害又はＱｏＳの低下などといった問題が生じる可能性が高まる。
　下記特許文献１は、移動体通信ネットワークにおける通信ノードの状態を監視し、輻輳又は異常が検知された場合に端末からの信号の転送経路を変化させる技術を提案している。
特開２００９－１３０６５７号公報
　しかしながら、上記特許文献１に記載された技術は、輻輳が既に発生している場合にその輻輳による影響を低減するためのものであって、輻輳の発生自体を回避し得るものではない。
　ここで、ＭＴＣ通信の上述した用途を考えると、ＭＴＣ通信は、特定の時間及び特定の地域においてデータ送信が集中するリスクを内包している。但し、ＭＴＣ通信の多くは計画的に行われることから、人間が利用する端末からの通信と異なり、ＭＴＣ通信におけるデータ送信の集中のリスクを予見することは十分に可能である。また、音声通話及びリアルタイムストリーミングなどのように低遅延が厳しく要求されるケースは、ＭＴＣ通信では比較的少ない。従って、ＭＴＣ通信の通信経路をある程度計画的かつ柔軟に制御することで、ＭＴＣ通信におけるトラフィックの輻輳を回避し又は緩和することが可能であるものと推測される。
　そこで、ＭＴＣ通信におけるトラフィックの輻輳を回避し又は緩和することのできる、新規かつ改良された仕組みが提供されることが望ましい。
　ある実施形態によれば、複数の通信ノードを含む通信ネットワーク内の通信装置であって、端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、上記端末装置がＭＴＣ端末である場合に、複数の転送先ノードの候補から上記データパケットの転送先ノードを選択する通信制御部と、上記通信制御部により選択される転送先ノードへ上記データパケットを送信する送信部と、を備える通信装置が提供される。
　また、上記通信制御部は、上記データパケット内の制御情報に基づいて、上記データパケットの転送先ノードを選択してもよい。
　また、上記通信装置は、データパケットの分類と転送先ノードとを対応付ける転送先データを記憶する記憶部、をさらに備え、上記通信制御部は、上記制御情報に応じて上記データパケットを分類し、上記転送先データにおいて上記データパケットの分類と対応付けられた転送先ノードを上記データパケットの転送先ノードとして選択してもよい。
　また、上記制御情報は、上記端末装置の端末ＩＤ、クラス若しくはグループ、又は上記データパケットに関連するアプリケーションのアプリケーションＩＤ若しくはクラスを含んでもよい。
　また、上記通信制御部は、上記制御情報に応じて各データパケットを分類し、同じ分類に属するデータパケットの転送先が複数の転送先ノードに分散されるように、各データパケットの転送先ノードを選択してもよい。
　また、上記通信制御部は、上記データパケットの宛て先ノードまでの経路に関するルーティングメトリックとは関係なく、上記複数の転送先ノードの候補から上記データパケットの転送先ノードを選択してもよい。
　また、上記通信制御部は、上記データパケットの宛て先ノードまでの経路上の上記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、上記データパケットの宛て先フィールドに挿入してもよい。
　また、上記通信制御部は、上記データパケットの受信時に上記宛て先フィールドに記述されている情報を、他のフィールドに転記してもよい。
　また、上記通信制御部は、上記宛て先フィールドが変更されたことを示すフラグを上記データパケットに付加してもよい。
　また、上記通信ネットワークは、セルラー通信システムのコアネットワークであってもよい。
　また、別の実施形態によれば、複数の通信ノードを含む通信ネットワーク内の通信装置における通信制御方法であって、端末装置から送信され又は端末装置へ送信されるデータパケットを受信することと、上記端末装置がＭＴＣ端末である場合に、複数の転送先ノードの候補から上記データパケットの転送先ノードを選択することと、選択した転送先ノードへ上記データパケットを送信することと、を含む通信制御方法が提供される。
　また、別の実施形態によれば、端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、上記端末装置がＭＴＣ端末である場合に、複数の転送先ノードの候補から上記データパケットの転送先ノードを選択する通信制御部と、上記通信制御部により選択される転送先ノードへ上記データパケットを送信する送信部と、を備える通信装置と、それぞれ上記転送先ノードの候補である上記複数の通信ノードと、を含む通信システムが提供される。
　また、別の実施形態によれば、複数の通信ノードを含む通信ネットワーク内の通信装置であって、端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、上記端末装置がＭＴＣ端末である場合に複数の転送先ノードの候補から上記データパケットの転送先ノードを選択する通信ノードへ、上記データパケットを送信する送信部と、転送先ノードの選択のための上記通信ノードによる上記データパケットの分類に利用される制御情報を、上記データパケットに挿入する通信制御部と、を備える通信装置が提供される。
　以上説明したように、本開示に係る技術によれば、ＭＴＣ通信におけるトラフィックの輻輳を回避し又は緩和することができる。
第１の実施形態に係る通信システムの概要を示す模式図である。 第１の実施形態に係る端末装置の構成の一例を示すブロック図である。 パケットフォーマットの一例について説明するための説明図である。 第１の実施形態に係るデータ送信処理の流れの一例を示すフローチャートである。 第１の実施形態に係る基地局の構成の一例を示すブロック図である。 第１の実施形態に係る制御情報挿入処理の流れの一例を示すフローチャートである。 第１の実施形態に係る転送ノードの構成の一例を示すブロック図である。 転送先データの第１の例について説明するための説明図である。 転送先データの第２の例について説明するための説明図である。 第１の実施形態に係るデータ転送処理の流れの一例を示すフローチャートである。 第２の実施形態に係る通信システムの概要を示す模式図である。 第２の実施形態に係る端末装置の構成の一例を示すブロック図である。 第２の実施形態に係るデータ送信処理の流れの一例を示すフローチャートである。 第２の実施形態に係る基地局の構成の一例を示すブロック図である。 中間ノードデータの第１の例について説明するための説明図である。 中間ノードデータの第２の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第１の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第２の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第３の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第４の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第５の例について説明するための説明図である。 第２の実施形態に係る基地局によるデータ転送処理の流れの一例を示すフローチャートである。 第２の実施形態に係る基地局によるデータ転送処理の流れの他の例を示すフローチャートである。 第２の実施形態に係る中間ノードの構成の一例を示すブロック図である。 宛て先ノードデータの一例について説明するための説明図である。 第２の実施形態に係る中間ノードによるデータ転送処理の流れの一例を示すフローチャートである。 第２の実施形態に係る中間ノードによるデータ転送処理の流れの他の例を示すフローチャートである。 第２の実施形態により実現され得る通信経路の例について説明するための説明図である。 第２の実施形態に係る情報管理サーバの構成の一例を示すブロック図である。 更新データの一例について説明するための説明図である。 第２の実施形態に係る更新データ配信処理の流れの第１の例を示すフローチャートである。 第２の実施形態に係る更新データ配信処理の流れの第２の例を示すフローチャートである。 第２の実施形態に係る宛て先ノードデータ更新処理の流れの一例を示すフローチャートである。
　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付すことにより重複説明を省略する。
　また、以下の順序にしたがって当該「発明を実施するための形態」を説明する。
　　１．第１の実施形態の説明
　　　１－１．システムの概要
　　　１－２．端末装置
　　　１－３．基地局
　　　１－４．転送ノード
　　　１－５．第１の実施形態のまとめ
　　　１－６．応用例
　　２．第２の実施形態の説明
　　　２－１．システムの概要
　　　２－２．端末装置
　　　２－３．基地局
　　　２－４．中間ノード
　　　２－５．通信経路の例
　　　２－６．情報管理サーバ
　　　２－７．ＤＲＸの管理
　　　２－８．第２の実施形態のまとめ
　　　２－９．応用例
　＜１．第１の実施形態の説明＞
　　［１－１．システムの概要］
　まず、図１～図９を用いて、第１の実施形態を説明する。図１は、第１の実施形態に係る通信システム１の概要を示す模式図である。図１を参照すると、通信システム１は、複数の端末装置１００ａ～１００ｅ、複数の基地局１２０ａ～１２０ｄ、複数の通信装置１４０ａ～１４０ｄ、及び複数のアプリケーションサーバ１９０ａ～１９０ｃを含む。複数の通信装置１４０ａ～１４０ｄは、通信システム１におけるコアネットワーク１０を形成する。基地局１２０ｄ、アプリケーションサーバ１９０ａ及び１９０ｂは、ネットワーク２０に接続される。
　本明細書では、端末装置１００ａ～１００ｅを互いに区別する必要がない場合には、これらを端末装置１００と総称する。基地局１２０（１２０ａ～１２０ｄ）、通信装置１４０（１４０ａ～１４０ｄ）、及びアプリケーションサーバ１９０（１９０ａ～１９０ｃ）についても同様とする。
　端末装置１００は、ＭＴＣ端末として動作する無線通信装置である。各端末装置１００は、自らが属するセルに無線通信サービスを提供している基地局１２０との間で、無線信号を送受信する。例えば、端末装置１００は、ガスの利用量又は自動販売器の在庫量などのアプリケーションデータを生成し、生成したアプリケーションデータを含むデータパケットを基地局１２０へ送信する。端末装置１００から基地局１２０へ送信されたデータパケットは、最終的には、いくつかの通信ノードを経由して、目的とするアプリケーションサーバ１９０へ届けられる。
　基地局１２０は、例えばＬＴＥ（Long　Term　Evolution）又はＬＴＥ－Ａｄｖａｎｃｅｄなどに代表されるセルラー通信方式に従って、自装置の周囲に広がるセル内に無線通信サービスを提供する通信ノードである。基地局１２０は、例えば、端末装置１００により生成されるアプリケーションデータを含むデータパケットを受信し、受信したデータパケットをコアネットワーク１０の通信装置１４０へ転送する。また、基地局１２０は、コアネットワーク１０を経由して転送されてくる端末装置１００宛てのデータパケットを受信し、受信したデータパケットを宛て先の端末装置１００へ転送する。
　図１の例において、基地局１２０ａ～１２０ｃは、コアネットワーク１０に直接接続されるいわゆるマクロセルの基地局である。一方、基地局１２０ｄは、ネットワーク２０を介してコアネットワーク１０と接続されるフェムトセルの基地局（ＬＴＥではＨｅＮＢ（Home　eNB）とも呼ばれる）である。これら基地局１２０は、端末装置１００のようなＭＴＣ端末のみならず、一般的なユーザ端末にも無線通信サービスを提供してよい。
　通信装置１４０は、コアネットワーク１０を形成する通信ノードである。各通信装置１４０は、例えば、ＲＮＣ（Radio　Network　Controller）、ＭＭＥ（Mobility　Management　Entity）、ＨＳＳ（Home　Subscriber　Server）、ＳＧＳＮ（Serving　GPRS　Support　Node）又はＧＧＳＮ（Gateway　GPRS　Support　Node）などであってもよい。また、各通信装置１４０は、例えば、これら通信ノード間を接続するスイッチ又はルータなどのネットワーク装置であってもよい。通信装置１４０は、例えば、端末装置１００から送信され又は端末装置１００へ送信されるデータパケットを受信し、受信したデータパケットを宛て先のアプリケーションサーバ１９０へ届くように順次転送する。
　図１に示した通信装置１４０のうち、例えば、通信装置１４０ｄは、いわゆるゲートウェイの役割を有するＧＧＳＮであり、コアネットワーク１０とネットワーク２０との境界に位置する。ネットワーク２０は、例えば、インターネットなどのＩＰ（Internet　Protocol）ネットワークであってもよく、又はＡＴＭ（Asynchronous　Transfer　Mode）ネットワークなどの非ＩＰネットワークであってもよい。
　アプリケーションサーバ１９０は、例えば、ガス料金の課金、又は自動販売機への商品の配送のプランニングなどのアプリケーション（ＡＰ）機能を有するサーバ装置である。ＭＴＣ端末から送信されるアプリケーションデータを利用するこのようなサーバ装置は、ＭＴＣサーバとも呼ばれる。アプリケーションサーバ１９０は、ネットワーク２０に接続されてもよく、又はコアネットワーク１０内に存在してもよい。図１の例では、アプリケーションサーバ１９０ａ及び１９０ｂはネットワーク２０に接続され、アプリケーションサーバ１９０ｃはコアネットワーク１０内に存在する。アプリケーションサーバ１９０ｃは、コアネットワーク１０を形成する通信ノードと物理的に同一の装置上に実装されてもよい。
　アプリケーションサーバ１９０は、例えば、端末装置１００から送信されるデータパケットを最終的に受信する。そして、アプリケーションサーバ１９０は、受信したデータパケットに含まれるアプリケーションデータを取得して、上で例示したようなアプリケーション機能を実行する。また、アプリケーションサーバ１９０は、ＭＴＣ端末に関する設定の入力を受け付けるためのユーザインタフェースをユーザに提供してもよい。ＭＴＣ端末に関する設定とは、例えば、アプリケーションサーバ１９０と端末装置１００との間のＭＴＣ通信のスケジュールに関する設定を含み得る。
　図１に例示した通信システム１において、多数のＭＴＣ端末が存在する場合には、ＭＴＣ端末から送信されるデータパケットが、宛て先のアプリケーションサーバ１９０までの通信経路上で輻輳を生じさせる可能性がある。特に、定期的なデータの収集を要するアプリケーションが導入されると、特定の時間又は特定の地域において端末装置１００から一斉にデータパケットが送信され得る。但し、ＭＴＣ通信の多くは計画的に行われるため、ＭＴＣ通信による輻輳が生じる前に、これを回避できる余地がある。また、ＭＴＣ通信の目的がデータ収集であるような場合には、データパケットは必ずしも最大のレートでアプリケーションサーバ１９０に届かなくてもよい。そこで、本実施形態では、次項より説明する各装置の構成を採用することにより、ＭＴＣ通信におけるトラフィックの輻輳の発生を回避し又は緩和する。
　なお、本明細書において、「通信ノード」又は「通信装置」という用語は、特に符号が付されない場合において、図１に例示した端末装置１００、基地局１２０、通信装置１４０及びアプリケーションサーバ１９０のいずれをも表し得ることに留意されたい。
　　［１－２．端末装置］
　　　（１）装置の構成例
　図２は、本実施形態に係る端末装置１００の構成の一例を示すブロック図である。図２を参照すると、端末装置１００は、アプリケーション部１０２、記憶部１０４、通信制御部１１０、無線送信部１１２及び無線受信部１１４を備える。
　アプリケーション部１０２は、アプリケーションサーバ１９０へ送信されるべきアプリケーションデータを生成し、生成したアプリケーションデータを通信制御部１１０へ出力する。アプリケーション部１０２により生成されるアプリケーションデータは、アプリケーションの目的に応じて、例えばガスの利用量、自動販売機の在庫量、コピー機のトナー残量、又は輸送管理のための位置データなど、任意の種類のデータを含み得る。アプリケーションデータの生成は、例えば、予め設定される時刻又は頻度で定期的に行われてもよい。その代わりに、アプリケーションデータの生成は、所定のイベント（例えば、一定量を超える在庫量の減少など）の発生をきっかけとして行われてもよい。
　記憶部１０４は、ハードディスク又は半導体メモリなどの記憶媒体を用いて、アプリケーション部１０２及び通信制御部１１０による処理のためのプログラム及びデータを記憶する。また、記憶部１０４は、アプリケーション部１０２によるアプリケーションデータの生成の基礎となるデータを記憶する。また、記憶部１０４は、後に説明するデータパケットに挿入される制御情報の少なくとも一部を予め記憶する。
　通信制御部１１０は、アプリケーションサーバ１９０へ送信されるべきアプリケーションデータがアプリケーション部１０２から入力されると、当該アプリケーションデータを含むデータパケットを生成する。そして、通信制御部１１０は、生成したデータパケットを無線送信部１１２から送信させる。また、通信制御部１１０は、無線受信部１１４によりデータパケットが受信されると、当該データパケットに含まれるアプリケーションデータを取得してアプリケーション部１０２へ出力する。
　無線送信部１１２及び無線受信部１１４は、アンテナ及びＲＦ（Radio　Frequency）回路を有する。無線送信部１１２は、通信制御部１１０により生成されるデータパケットをエアインタフェース上で無線信号として基地局１２０へ送信する。また、無線受信部１１４は、エアインタフェース上で無線信号として基地局１２０から送信されるデータパケットを受信し、受信したデータパケットを通信制御部１１０へ出力する。
　　　（２）パケットフォーマットの例
　図３は、本実施形態において端末装置１００が送信するデータパケットのパケットフォーマットの一例について説明するための説明図である。図３を参照すると、本実施形態に係るデータパケットは、ヘッダ領域ＨＳ及びデータ領域ＤＳを含む。図３に例示したように、ヘッダ領域ＨＳは、制御情報が格納される８つのフィールドＦ１～Ｆ８を有する。データ領域ＤＳは、上述したアプリケーションデータを格納するための領域である。
　ヘッダ領域ＨＳの宛て先フィールドＦ１には、データパケットの宛て先ノードを指定する情報が格納される。宛て先フィールドＦ１に格納される情報は、例えば、宛て先ノードのＩＰ（Internet　Protocol）アドレス、ＭＡＣ（Media　Access　Control）アドレス、ホスト名又はその他の固有の識別子などであってよい。端末装置１００がアプリケーションデータを送信する場合には、対応するアプリケーション機能を提供するアプリケーションサーバ１９０が宛て先ノードとなる。また、端末装置１００がデータパケットを受信する場合には、当該端末装置１００が宛て先ノードとなる。
　送信元フィールドＦ２には、データパケットの送信元ノードを指定する送信元ノード情報が格納される。端末装置１００がアプリケーションデータをアプリケーションサーバ１９０へ送信する場合には、当該アプリケーションデータを生成した端末装置１００が送信元ノードとなる。
　アプリケーション（ＡＰ）クラスフィールドＦ３及びＡＰ　ＩＤ（IDentifier）フィールドＦ４は、ＡＰクラス及びＡＰ　ＩＤをそれぞれ格納するためのフィールドである。ＡＰクラス及びＡＰ　ＩＤは、データパケットに関連するアプリケーションに関する制御情報である。ＡＰクラスは、アプリケーションをいくつかのクラスに分類した場合の、個々のアプリケーションが属するクラスを表す。例えば、サービス品質（ＱｏＳ）要件に応じて分類されるＱｏＳクラスがＡＰクラスとして利用されてもよい。ＡＰ　ＩＤは、個々のアプリケーションを一意に識別するための識別子である。各端末装置１００がサポートするＡＰクラス及びＡＰ　ＩＤの値は、記憶部１０４により予め記憶され得る。
　端末クラスフィールドＦ５、端末グループ（Ｇｒｐ）フィールドＦ６及び端末ＩＤフィールドＦ７は、端末クラス、端末グループ及び端末ＩＤをそれぞれ格納するためのフィールドである。端末クラス、端末グループ及び端末ＩＤは、ＭＴＣ端末に関する制御情報である。端末クラス及び端末グループは、ＭＴＣ端末をいくつかのクラス及びグループに分類した場合の、個々の端末装置が属するクラス及びグループをそれぞれ表す。例えば、３ＧＰＰ（3rd　Generation　Partnership　Project）　ＴＳ（Technical　Specification）２２．３６８によれば、ＭＴＣ端末は、そのサービス分野に応じて、セキュリティ機器、交通関連機器、支払機器、健康医療関連機器、遠隔操作機器、計測機器及びコンシューマ機器などに分類され得る。また、例えば、支払機器であれば自動販売機又はＰＯＳ（Point　of　sales）機器、計測機器であれば電力メータ又はガスメータなどのように、ＭＴＣ端末をその用途に応じてより詳細に分類することもできる。端末クラスとは、例えば、このようなサービス分野又は用途に応じたＭＴＣ端末の分類であってもよい。また、３ＧＰＰ　ＴＳ２２．３６８は、例えばＱｏＳポリシー又は最大ビットレートなどの観点で定義される１つ以上のグループに各ＭＴＣ端末を割り当てることを提案している。端末グループとは、例えば、このようなグループベースのＭＴＣ端末の管理のために定義されるグループであってもよい。なお、当然ながら、他の考え方に従ったＭＴＣ端末の分類が利用されてもよい。端末ＩＤは、個々の端末装置を一意に識別するための識別子である。各端末装置１００の端末クラス、端末グループ及び端末ＩＤの値は、記憶部１０４により予め記憶され得る。
　事業者ＩＤフィールドＦ８は、各端末装置１００が送信するデータパケットに関連するアプリケーションを提供する事業者を一意に特定する事業者ＩＤを格納するためのフィールドである。事業者ＩＤもまた、記憶部１０４により予め記憶され得る。
　　　（３）データ送信処理の流れ
　図４は、本実施形態に係る端末装置１００によるデータ送信処理の流れの一例を示すフローチャートである。
　図４を参照すると、まず、端末装置１００のアプリケーション部１０２は、定期的に又は所定のイベントの発生に応じて、アプリケーションデータを生成する（ステップＳ１０２）。次に、通信制御部１１０は、生成されたアプリケーションデータについてのＡＰクラス及びＡＰ　ＩＤなどのアプリケーションに関する制御情報を、記憶部１０４から取得する（ステップＳ１０４）。また、通信制御部１１０は、端末装置１００のＭＴＣ端末に関する端末クラス、端末グループ及び端末ＩＤなどの制御情報を、記憶部１０４から取得する（ステップＳ１０６）。次に、通信制御部１１０は、取得した制御情報とアプリケーションデータとを用いて、図３に例示したパケットフォーマットを有するデータパケットを生成する（ステップＳ１０８）。なお、ここで生成されるデータパケットの宛て先は、例えば、アプリケーションデータと関連付けてアプリケーション部１０２により指定され得る。そして、無線送信部１１２は、通信制御部１１０により生成されたデータパケットを基地局１２０へ送信する（ステップＳ１１０）。
　なお、ここでは端末装置１００がデータパケットに制御情報を挿入する例について説明したが、その他の通信ノード（例えば、基地局１２０又は通信装置１４０など）が端末装置１００の代わりにデータパケットに制御情報を挿入してもよい。データパケットに制御情報を挿入する装置は、図１に例示していない装置（例えば、端末装置１００と基地局１２０との間に介在し得る中継局など）であってもよい。次項では、一例として、基地局１２０がデータパケットに制御情報の一部を挿入する例を説明する。
　　［１－３．基地局］
　　　（１）装置の構成例
　図５は、本実施形態に係る基地局１２０の構成の一例を示すブロック図である。図５を参照すると、基地局１２０は、無線受信部１２２、無線送信部１２４、送信部１２６、受信部１２８、記憶部１３０及び通信制御部１３２を備える。
　無線受信部１２２及び無線送信部１２４は、複数の端末装置１００との間で無線通信を行うためのアンテナ及びＲＦ回路を有する。無線受信部１２２は、端末装置１００から送信されるデータパケットを受信し、受信したデータパケットを通信制御部１３２へ出力する。また、無線送信部１２４は、端末装置１００を宛て先とするデータパケットが通信制御部１３２から入力されると、当該データパケットを端末装置１００へ送信する。
　送信部１２６及び受信部１２８は、基地局１２０がコアネットワーク１０の通信装置１４０との間で通信を行うための通信インタフェースである。送信部１２６は、通信制御部１３２からデータパケットが入力されると、当該データパケットをコアネットワーク１０へ送信する。受信部１２８は、コアネットワーク１０からデータパケットを受信すると、当該データパケットを通信制御部１３２へ出力する。
　記憶部１３０は、記憶媒体を用いて、通信制御部１３２による処理のためのプログラム及びデータを記憶する。また、記憶部１３０は、図３に例示した制御情報の一部を、各端末装置１００の端末ＩＤ又はアドレス情報と関連付けて予め記憶してもよい。
　通信制御部１３２は、例えば、ＬＴＥ又はＬＴＥ－Ａなどの標準仕様に従って、基地局１２０をセルラー通信のための基地局として動作させる。また、本実施形態において、通信制御部１３２は、端末装置１００の代わりに、端末装置１００から送信されるデータパケットに上述した制御情報を挿入し得る。例えば、通信制御部１３２は、端末装置１００からのデータパケットが無線受信部１２２から入力されると、当該データパケット内に記述された端末ＩＤ又は送信元アドレスと関連付けられている制御情報を記憶部１３０から取得する。そして、通信制御部１３２は、取得した制御情報をデータパケットに挿入する。
　　　（２）制御情報挿入処理の流れ
　図６は、本実施形態に係る基地局１２０による制御情報挿入処理の流れの一例を示すフローチャートである。
　図６を参照すると、まず、基地局１２０の無線受信部１２２は、端末装置１００から送信されたデータパケットを受信する（ステップＳ１２２）。そして、無線受信部１２２は、受信したデータパケットを通信制御部１３２へ出力する。次に、通信制御部１３２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ１２４）。ＭＴＣ通信のためのパケットとは、送信元がＭＴＣ端末であるパケット、及び最終的な宛て先がＭＴＣ端末であるパケットの双方を含む。通信制御部１３２は、例えば、データパケットに含まれる端末グループ若しくは端末クラスを参照することにより、又はデータパケットに含まれる端末ＩＤを予め登録されるＩＤリストと照合することにより、データパケットがＭＴＣ通信のためのパケットであるか否かを判定することができる。その代わりに、通信制御部１３２は、例えば、データパケットに含まれるＡＰクラスを参照することにより、又はデータパケットに含まれるＡＰ　ＩＤを予め登録されるＩＤリストと照合することにより、データパケットがＭＴＣ通信のためのパケットであるか否かを判定してもよい。ここで、データパケットがＭＴＣ通信のためのパケットであれば、続いてステップＳ１２６及びＳ１２８の処理が行われる。
　送信元の装置がＭＴＣ端末である場合、通信制御部１３２は、データパケットにアプリケーションに関する制御情報（ＡＰクラス及びＡＰ　ＩＤなど）を挿入する（ステップＳ１２６）。また、通信制御部１３２は、データパケットにＭＴＣ端末に関する制御情報（端末クラス又は端末グループなど）を挿入する（ステップＳ１２８）。
　次に、通信制御部１３２は、データパケットを再生成する（ステップＳ１３０）。そして、再生成されたデータパケットは、送信部１２６からコアネットワーク１０へ転送される（ステップＳ１３２）。
　なお、次に説明する通信装置１４０（転送ノード）によるデータ転送処理のために利用される全ての制御情報が端末装置１００によりデータパケットに挿入される場合には、図６に例示した基地局１２０による制御情報挿入処理は省略される。その場合、基地局１２０は、端末装置１００から送信されるデータパケットを、通常のユーザ端末から送信されるデータパケットと同様に、コアネットワーク１０へ転送する。
　　［１－４．転送ノード］
　　　（１）装置の構成例
　図７は、本実施形態に係る通信装置１４０の構成の一例を示すブロック図である。図７を参照すると、通信装置１４０は、受信部１４２、送信部１４４、記憶部１５０、及び通信制御部１５２を備える。
　受信部１４２及び送信部１４４は、通信装置１４０が他の通信装置との間で通信を行うための通信インタフェースである。受信部１４２は、他の通信装置からデータパケットを受信すると、当該データパケットを通信制御部１５２へ出力する。送信部１４４は、通信制御部１５２からデータパケットが入力されると、当該データパケットを他の通信装置へ送信する。
　記憶部１５０は、記憶媒体を用いて、通信制御部１５２による処理のためのプログラム及びデータを記憶する。また、記憶部１５０は、データパケット内の制御情報に基づく分類とデータパケットの転送先ノードとを対応付ける転送先データを記憶する。記憶部１５０により記憶される転送先データの例について、後に例を挙げて説明する。
　通信制御部１５２は、受信部１４２により受信されたデータパケットの送信元の装置がＭＴＣ端末である場合に、トラフィックが分散されるように、複数の転送先ノードの候補からデータパケットの転送先ノードを選択する。より具体的には、本実施形態において、通信制御部１５２は、データパケット内の制御情報に基づいてデータパケットの転送先ノードを選択する。例えば、通信制御部１５２は、データパケット内の制御情報に応じてデータパケットを分類し、記憶部１５０により記憶されている転送先データにおいて当該データパケットの分類と対応付けられた転送先ノードを、当該データパケットの転送先ノードとして選択してもよい。その代わりに、通信制御部１５２は、例えば、同じ分類に属するデータパケットの転送先が複数の転送先ノードに分散されるように、各データパケットの転送先ノードを選択してもよい。通信制御部１５２による転送先ノードの選択は、典型的には、データパケットの宛て先ノードまでの経路に関するルーティングメトリックとは関係なく行われる。即ち、本実施形態に係る通信装置１４０は、必ずしも宛て先ノードまでのホップ数又は通信経路のコストなどのメトリックが最小となる転送先ノードを選択するわけではない。
　図８Ａ及び図８Ｂは、それぞれ、通信装置１４０による転送先ノードの選択のために使用され得る転送先データの一例について説明するための説明図である。
　図８Ａを参照すると、第１の例としての転送先データ１５１ａが示されている。転送先データ１５１ａは、「アプリケーションクラス」、「端末ＩＤ」及び「転送先ノード」という３つのデータ項目を有する。第１の例においては、通信制御部１５２は、データパケット内の制御情報に含まれるアプリケーションクラス及び端末ＩＤに応じて、データパケットを６つのカテゴリに分類する。例えば、アプリケーションクラスが「Ｃ１」である場合には、端末ＩＤの下位２ビットに応じて、データパケットは、第１から第４のいずれかのカテゴリに分類される。第１のカテゴリ（端末ＩＤの下位２ビット＝「００」）に分類されるデータパケットの転送先ノードは、ノードＮ１である。第２のカテゴリ（端末ＩＤの下位２ビット＝「０１」）に分類されるデータパケットの転送先ノードは、ノードＮ２である。第３のカテゴリ（端末ＩＤの下位２ビット＝「１０」）に分類されるデータパケットの転送先ノードは、ノードＮ３である。第４のカテゴリ（端末ＩＤの下位２ビット＝「１１」）に分類されるデータパケットの転送先ノードは、ノードＮ４である。また、アプリケーションクラスが「Ｃ２」である場合には、端末ＩＤによらず、データパケットは、第５のカテゴリに分類される。第５のカテゴリに分類されるデータパケットの転送先ノードは、ノードＮ５である。アプリケーションクラスが「Ｃ３」である場合には、端末ＩＤによらず、データパケットは、第６のカテゴリに分類される。第６のカテゴリに分類されるデータパケットの転送先ノードは、ノードＮ６である。
　アプリケーションクラス「Ｃ１」は、例えば、ＱｏＳに関して低遅延が推奨される（例えば、許容される遅延の上限値が指定されている）クラスである。この場合には、第１の例のように端末ＩＤに応じてデータパケットの転送先を複数の転送先ノードに分散させて輻輳の発生を回避し、ＱｏＳ違反のリスクを低減することができる。なお、通信制御部１５２は、端末ＩＤを用いることなく、例えばラウンドロビン方式又はランダム方式で、アプリケーションクラス「Ｃ１」のデータパケットの転送先を４つの転送先ノードＮ１～Ｎ４の間で分散させてもよい。
　また、第１の例では、異なるアプリケーションクラスのデータパケットが異なる転送先ノードへ転送される。例えば、ノードＮ５及びノードＮ６は、ノードＮ１～Ｎ４と比較してスループットが高くないノード又は低速なリンクを有するノードであってもよい。このようにアプリケーションごとに異なる転送先ノードを選択することで、トラフィックの輻輳が生じる可能性はさらに低減され得る。
　図８Ｂを参照すると、第２の例としての転送先データ１５１ｂが示されている。転送先データ１５１ｂは、「端末クラス」及び「転送先ノード」という２つのデータ項目を有する。第２の例においては、通信制御部１５２は、データパケット内の制御情報に含まれる端末クラスに応じて、データパケットを４つのカテゴリに分類する。例えば、端末クラスが「Ｔ１」である場合には、データパケットは第１のカテゴリに分類され、転送先ノードとしてノードＮ１が選択される。端末クラスが「Ｔ２」である場合には、データパケットは第２のカテゴリに分類され、転送先ノードとしてノードＮ２が選択される。端末クラスが「Ｔ３」である場合には、データパケットは第３のカテゴリに分類され、転送先ノードとしてノードＮ３が選択される。端末クラスが「Ｔ４」である場合には、データパケットは第４のカテゴリに分類され、転送先ノードとしてノードＮ４が選択される。
　第２の例では、異なる端末クラスのデータパケットが異なる転送先ノードへ転送されるため、端末クラス間でデータパケットの転送先が分散される。そのため、データパケットの輻輳の可能性が低減される。なお、通信制御部１５２は、例えば、同じ端末クラスの端末装置１００からのデータパケットの転送先を、４つの転送先ノードＮ１～Ｎ４の間でラウンドロビン方式又はランダム方式で分散させてもよい。また、端末クラスの代わりに端末グループが使用されてもよい。
　なお、コアネットワーク１０内に存在する全ての通信装置１４０がここで説明した転送先ノードとしての機能を有しなくてもよい。また、転送先ノードデータの内容は、転送先ノードとして機能する通信装置１４０ごとに異なってもよい。即ち、第１の転送先ノードが図８Ａに例示した転送先データを有し、一方で第２の転送先ノードが図８Ｂに例示した転送先データを有してもよい。転送先ノードデータは、各転送先ノードにおいて個別に登録及び更新されてもよく、又は第２の実施形態において説明するような情報管理サーバにおいて一括的に管理され、動的に更新されてもよい。
　　　（２）データ転送処理の流れ
　図９は、本実施形態に係る通信装置１４０によるデータ転送処理の流れの一例を示すフローチャートである。
　図９を参照すると、まず、通信装置１４０の受信部１４２は、端末装置１００から送信されたデータパケットを受信する（ステップＳ１４２）。そして、受信部１４２は、受信したデータパケットを通信制御部１５２へ出力する。次に、通信制御部１５２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ１４４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、処理はステップＳ１４６へ進む。一方、データパケットがＭＴＣ通信のためのパケットでなければ、処理はステップＳ１５４へ進む。
　ステップＳ１４６では、通信制御部１５２は、データパケットのヘッダ領域に含まれる制御情報を取得する（ステップＳ１４６）。次に、通信制御部１５２は、取得した制御情報に応じてデータパケットを複数のカテゴリのいずれかに分類する（ステップＳ１４８）。次に、通信制御部１５２は、データパケットが属するカテゴリに対応する転送先ノードが記憶部１５０に記憶されている転送先ノードデータに存在するか否かを判定する（ステップＳ１５０）。ここで、対応する転送先ノードが転送先ノードデータに存在する場合には、処理はステップＳ１５２へ進む。一方、対応する転送先ノードが転送先ノードデータに存在しない場合には、処理はステップＳ１５４へ進む。
　ステップＳ１５２では、通信制御部１５２は、転送先ノードデータにおいてデータパケットが属するカテゴリに対応付けられている転送先ノードを、データパケットの転送先ノードとして選択する（ステップＳ１５２）。一方、ステップＳ１５４では、通信制御部１５２は、既定の転送先ノードを、データパケットの転送先ノードとして選択する（ステップＳ１５４）。ここで、既定の転送先ノードとは、例えば、予め固定的に定義される転送先ノードであってもよく、又はルーティングメトリックに応じて動的に選択される転送先ノードであってもよい。
　そして、送信部１４４は、通信制御部１５２により選択された転送先ノードへデータパケットを転送する（ステップＳ１５６）。
　　［１－５．第１の実施形態のまとめ］
　ここまで、図１～図９を用いて、第１の実施形態について説明した。本実施形態によれば、ＭＴＣ端末からデータパケットが送信された場合に、通信ネットワーク内の転送ノードによって、複数の転送先ノードの候補から転送先ノードが選択され、選択された転送先ノードへ当該データパケットが転送される。それにより、ＭＴＣ通信のトラフィックを複数のルートに経路させ、輻輳を回避し又は緩和することができる。また、結果として、通信システムに収容可能なＭＴＣ端末の数を増加させることができる。
　また、本実施形態によれば、転送ノードは、データパケット内の制御情報に基づいて転送先ノードを選択する。かかる制御情報は、ＭＴＣ通信に関連するアプリケーション又はＭＴＣ端末の種類の観点でデータパケットを分類するために用いられ得る。かかる構成によれば、アプリケーションの種類又は端末の種類などに応じて計画的にデータパケットを分散させることができる。例えば、一斉にデータを送信する可能性のある同種のアプリケーションの又は同種の端末からのデータパケットの転送先を、複数の転送先ノードの間で分散させることも可能である。従って、ＭＴＣ通信による輻輳の発生を未然に回避し、又は輻輳を効果的に緩和することができる。
　また、標準的にデータパケット内に包含される情報を制御情報として利用することで、ＭＴＣ端末又は基地局などの既存の装置に処理ロジックの改変などのインパクトを与えることなく、上述した輻輳回避のためのメカニズムを導入することができる。
　また、本実施形態によれば、転送ノードにおける転送先ノードの選択は、宛て先ノードまでの経路に関するルーティングメトリックとは関係なく行われ得る。これは、通常の（人間が利用する）ユーザ端末による通信と比較して必ずしも最大のレートでデータが宛て先に届かなくてもよいケースの多いＭＴＣ通信の特性に着目した考え方である。従って、ＭＴＣ通信のデータパケットは、ルーティングメトリックの観点でいわゆる「最適な」通信経路に集中することがない。その結果、例えば優先度の高い音声通話又はリアルタイムストリーミングなどの非ＭＴＣ通信を、ＭＴＣ通信が阻害するリスクが低減される。
　　［１－６．応用例］
　第１の実施形態では、主にＭＴＣ端末から送信されるデータパケットの転送先を複数の転送先ノードの候補の間で分散させる例について説明した。しかしながら、上述した転送先ノードの選択の仕組みは、ＭＴＣ端末へ送信されるデータパケットにも同様に適用可能である。例えば、図１に示した通信装置１４０は、端末装置１００へ送信されるデータパケットについての複数の転送先ノードの候補を記述する追加的な転送先データを有し、データパケット内の制御情報とその追加的な転送先データとに基づいて、トラフィックが分散されるように、端末装置１００へ送信されるデータパケットの転送先ノードを複数の転送先ノードの候補から選択してもよい。
　＜２．第２の実施形態の説明＞
　次に、図１０～図２４を用いて、第２の実施形態を説明する。第１の実施形態では、転送ノードがＭＴＣ通信のトラフィックを分散させることで、特定の通信経路へのトラフィックの集中が未然に防がれる。本節で説明する第２の実施形態では、ＭＴＣ通信のトラフィックを後述する中間ノードを経由する経路に導くことで、やはり特定の通信経路へのトラフィックの集中を防止する。
　　［２－１．システムの概要］
　図１０は、第２の実施形態に係る通信システム２の概要を示す模式図である。図１０を参照すると、通信システム２は、複数の端末装置２００ａ～２００ｄ、複数の基地局２２０ａ～２２０ｃ、コアネットワーク１０内の通信装置１４０、２４０ａ及び２４０ｂ、情報管理サーバ２７０、並びに複数のアプリケーションサーバ１９０ａ～１９０ｃを含む。
　端末装置２００は、第１の実施形態に係る端末装置１００と同様、ＭＴＣ端末として動作する無線通信装置である。各端末装置２００は、自らが属するセルに無線通信サービスを提供している基地局２２０との間で、無線信号を送受信する。端末装置２００は、例えば、アプリケーションデータを生成し、生成したアプリケーションデータを含むデータパケットを基地局２２０へ送信する。端末装置２００から基地局２２０へ送信されたデータパケットは、最終的には、いくつかの通信ノードを経由して、目的とするアプリケーションサーバ１９０へ届けられる。但し、本実施形態では、端末装置２００は、最終的な宛て先である宛て先ノードとは異なる通信ノードを指定する情報を、データパケットの宛て先フィールドにおいて指定し得る。本明細書では、このように、ＭＴＣ端末から送信されるデータパケットの（最終的な宛て先ではなく）一時的な宛て先として指定される通信ノードを、中間ノードという。
　基地局２２０は、第１の実施形態に係る基地局２２０と同様、例えばＬＴＥ又はＬＴＥ－Ａｄｖａｎｃｅｄなどに代表されるセルラー通信方式に従って、自装置の周囲に広がるセル内に無線通信サービスを提供する通信ノードである。基地局２２０は、例えば、端末装置２００により生成されるアプリケーションデータを含むデータパケットを受信し、受信したデータパケットをコアネットワーク１０の通信ノードへ転送する。但し、本実施形態では、基地局２２０は、転送するデータパケットの宛て先フィールドに中間ノードを指定する情報を挿入し得る。また、基地局２２０は、コアネットワーク１０を経由して転送されてくる端末装置２００宛てのデータパケットを受信し、受信したデータパケットを宛て先の端末装置２００へ転送する。
　通信装置２４０は、中間ノードとして指定される可能性のある通信ノードである。各通信装置２４０は、例えば、ＲＮＣ、ＭＭＥ、ＨＳＳ、ＳＧＳＮ若しくはＧＧＳＮなどであってもよく、又はこれら通信ノード間を接続するスイッチ若しくはルータなどであってもよい。通信装置２４０は、例えば、自装置が宛て先フィールドにおいて指定されているデータパケットを受信し、データパケット内の制御情報を用いて適切な宛て先ノードを識別し、識別した宛て先ノードに向けてデータパケットを転送する。
　情報管理サーバ２７０は、中間ノードが宛て先ノードを識別する際に使用する宛て先ノードデータのマスタを管理する通信装置である。図１０の例では、情報管理サーバ２７０は、ネットワーク２０に接続されている。しかしながら、かかる例に限定されず、情報管理サーバ２７０は、例えば、コアネットワーク１０内に存在してもよい。また、情報管理サーバ２７０は、コアネットワーク１０を形成する通信ノードと物理的に同一の装置上に実装されてもよい。情報管理サーバ２７０は、宛て先ノードデータのマスタに加えて、第１の実施形態で説明した転送先データのマスタを管理してもよい。
　　［２－２．端末装置］
　　　（１）装置の構成例
　図１１は、本実施形態に係る端末装置２００の構成の一例を示すブロック図である。図１１を参照すると、端末装置２００は、アプリケーション部１０２、記憶部２０４、通信制御部２１０、無線送信部１１２及び無線受信部１１４を備える。
　記憶部２０４は、記憶媒体を用いて、アプリケーション部１０２及び通信制御部２１０による処理のためのプログラム及びデータを記憶する。また、記憶部２０４は、第１の実施形態に係る端末装置１００の記憶部１０４と同様、アプリケーション部１０２によるアプリケーションデータの生成の基礎となるデータを記憶する。また、記憶部２０４は、データパケットに挿入される制御情報を予め記憶する。さらに本実施形態において、記憶部２０４は、データパケットの最終的な宛て先ノードまでの経路上の宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、例えばアプリケーションと関連付けて予め記憶する。中間ノード指定情報とは、例えば、中間ノードのＩＰアドレス、ＭＡＣアドレス、ホスト名又はその他の固有の識別子などであってよい。
　通信制御部２１０は、アプリケーションサーバ１９０へ送信されるべきアプリケーションデータがアプリケーション部１０２から入力されると、当該アプリケーションデータを含むデータパケットを生成する。このとき、通信制御部２１０は、データパケットの宛て先フィールドに、記憶部２０４においてアプリケーションと関連付けて記憶されている中間ノード指定情報を挿入し得る。そして、通信制御部２１０は、生成したデータパケットを無線送信部１１２から送信させる。また、通信制御部２１０は、無線受信部１１４によりデータパケットが受信されると、当該データパケットに含まれるアプリケーションデータを取得してアプリケーション部１０２へ出力する。
　　　（２）データ送信処理の流れ
　図１２は、本実施形態に係る端末装置２００によるデータ送信処理の流れの一例を示すフローチャートである。
　図１２を参照すると、まず、端末装置２００のアプリケーション部１０２は、定期的に又は所定のイベントの発生に応じて、アプリケーションデータを生成する（ステップＳ２０２）。次に、通信制御部２１０は、生成されたアプリケーションデータについてのＡＰクラス及びＡＰ　ＩＤなどのアプリケーションに関する制御情報を、記憶部２０４から取得する（ステップＳ２０４）。また、通信制御部２１０は、端末装置２００のＭＴＣ端末に関する端末クラス、端末グループ及び端末ＩＤなどの制御情報を、記憶部２０４から取得する（ステップＳ２０６）。次に、通信制御部２１０は、データパケットの宛て先フィールドに挿入すべき中間ノード指定情報を、記憶部２０４から取得する（ステップＳ２０８）。次に、通信制御部２１０は、取得した中間ノード指定情報及び制御情報をヘッダ領域に、アプリケーションデータをデータ領域にそれぞれ含むデータパケットを生成する（ステップＳ２１０）。そして、無線送信部１１２は、通信制御部２１０により生成されたデータパケットを基地局２２０へ送信する（ステップＳ２１２）。
　なお、ここでは端末装置２００がデータパケットに制御情報を挿入する例について説明したが、その他の通信ノード（例えば、基地局２２０又は通信装置２４０など）が端末装置２００の代わりにデータパケットに制御情報を挿入してもよい。また、次に説明するように、端末装置２００の代わりに、その他の通信ノードが中間ノード指定情報を宛て先フィールドに挿入してもよい。中間ノード指定情報を宛て先フィールドに挿入する装置は、図１０に例示していない装置（例えば、端末装置２００と基地局２２０との間に介在し得る中継局など）であってもよい。次項では、一例として、基地局２２０が中間ノード指定情報を宛て先フィールドに挿入する例を説明する。なお、次項の例において、端末装置２００は、一般的なデータ送信処理と同様、最終的な宛て先ノードを指定する宛て先ノード指定情報を宛て先フィールドに挿入し得る。
　　［２－３．基地局］
　　　（１）装置の構成例
　図１３は、本実施形態に係る基地局２２０の構成の一例を示すブロック図である。図１３を参照すると、基地局２２０は、無線受信部１２２、無線送信部１２４、送信部１２６、受信部１２８、記憶部２３０及び通信制御部２３２を備える。
　記憶部２３０は、記憶媒体を用いて、通信制御部２３２による処理のためのプログラム及びデータを記憶する。また、記憶部２３０は、図３に例示した制御情報の少なくとも一部を、各端末装置２００の端末ＩＤ又はアドレス情報と関連付けて予め記憶する。また、本実施形態において、記憶部２３０は、データパケットのために指定すべき中間ノードの候補をリスト化した中間ノードデータを予め記憶する。
　図１４Ａ及び図１４Ｂは、それぞれ、中間ノードデータの一例について説明するための説明図である。図１４Ａを参照すると、第１の例としての中間ノードデータ２３１ａが示されている。中間ノードデータ２３１ａは、「アプリケーションクラス」及び「中間ノード」という２つのデータ項目を有する。この場合、中間ノードデータ２３１ａは、データパケットのアプリケーションクラスごとに、指定すべき中間ノードを定義するデータである。一方、図１４Ｂを参照すると、第２の例としての中間ノードデータ２３１ｂが示されている。中間ノードデータ２３１ｂは、「端末クラス」及び「中間ノード」という２つのデータ項目を有する。この場合、中間ノードデータ２３１ｂは、データパケットの端末クラスごとに、指定すべき中間ノードを定義するデータである。なお、これらの例に限定されず、中間ノードデータは、図３に例示したような任意の制御情報と関連付けて中間ノードを定義するデータであってよい。
　通信制御部２３２は、例えば、ＬＴＥ又はＬＴＥ－Ａなどの標準仕様に従って、基地局２２０をセルラー通信のための基地局として動作させる。また、本実施形態において、通信制御部２３２は、無線受信部１２２により受信されるデータパケットの宛て先フィールドに、当該データパケットの最終的な宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を挿入し得る。例えば、通信制御部２３２は、端末装置２００からのデータパケットが無線受信部１２２から入力されると、当該データパケット内に記述されたアプリケーションクラス又は端末クラスと関連付けられている中間ノードを、記憶部２３０により記憶されている上述した中間ノードデータを用いて特定する。そして、通信制御部２３２は、特定した中間ノードを指定する中間ノード指定情報を、データパケットの宛て先フィールドに挿入する。ここでの宛て先フィールドの更新処理の複数のパターンについて、後に例を挙げて詳細に説明する。なお、通信制御部２３２は、複数の中間ノードの候補から、例えばラウンドロビン方式又はランダム方式で、データパケットごとに異なる中間ノードを指定してもよい。
　また、通信制御部２３２は、中間ノードによりデータパケットの最終的な宛て先ノードを識別するために使用される制御情報を、端末装置２００の代わりに、端末装置２００から送信されるデータパケットに挿入してもよい。最終的な宛て先ノードを識別するために使用される制御情報とは、例えば、図３を用いて説明した制御情報のうちの少なくとも１つを含み得る。
　　　（２）宛て先フィールド更新処理の例
　図１５Ａ～図１５Ｅは、それぞれ、本実施形態に係る通信制御部２３２による宛て先フィールド更新処理の一例について説明するための説明図である。各図には、通信制御部２３２による更新の前後の宛て先フィールドの内容が示されている。
　図１５Ａに示した第１の例において、通信制御部２３２は、データパケットの宛て先フィールドＦ１に挿入されている宛て先ノードに関する情報を、単純に中間ノード指定情報（例えば、中間ノードのＩＰアドレス又はホスト名など）で上書きする。この場合、宛て先フィールド更新処理は、最も簡易に実現され得る。
　図１５Ｂに示した第２の例において、通信制御部２３２は、データパケットの宛て先フィールドＦ１に挿入されている宛て先ノードに関する情報を中間ノード指定情報で上書きする（Ｆ１ｂ）と共に、宛て先フィールドＦ１が変更されたことを示すフラグをデータパケットに付加する（Ｆ１ａ）。この場合、更新後のデータパケットを受信する中間ノードは、フラグを参照することにより、宛て先フィールドＦ１が変更されているか否かを知ることができる。なお、データパケット内でのフラグの位置は、図１５Ｂに例示した位置とは異なる位置であってもよい。
　図１５Ｃに示した第３の例においては、宛て先フィールドＦ１が、フラグ用のサブフィールドＦ１ａ及びノード情報用のサブフィールドＦ１ｂに予め分割されている。この場合、例えば、端末装置２００は、サブフィールドＦ１ａのフラグをゼロに設定すると共に、サブフィールドＦ１ｂに宛て先ノードに関する情報を挿入したデータパケットを送信する。そして、基地局２２０の通信制御部２３２は、サブフィールドＦ１ａのフラグを１に更新すると共に、サブフィールドＦ１ｂを中間ノード指定情報で上書きする。この場合、データパケットを受信する全ての通信ノードは、フラグ用のサブフィールドＦ１ａを参照することにより、宛て先フィールドＦ１が変更されているか否かを知ることができる。
　図１５Ｄに示した第４の例において、通信制御部２３２は、フラグを１に更新し、宛て先フィールドＦ１に中間ノード指定情報を挿入すると共に、データパケットの受信時に宛て先フィールドＦ１に記述されている情報を予備フィールドＦ９に転記する。この場合、更新後のデータパケットを受信する中間ノードは、予備フィールドＦ９に転記された宛て先ノードに関する情報を参照することにより、最終的な宛て先ノードを識別することができる。
　図１５Ｅに示した第５の例は、１つのデータパケットの転送に際して複数の中間ノードが順に指定される場合に採用され得る、宛て先フィールド更新処理の例を示している。この場合、まず、基地局２２０の通信制御部２３２は、宛て先フィールドＦ１に中間ノード指定情報を挿入すると共に、最終的な宛て先ノード（宛て先ノード１）を指定する情報を予備フィールドＦ９に転記する。次に、データパケットを受信した中間ノードは、宛て先フィールドＦ１に新たな中間ノード指定情報を挿入すると共に、宛て先フィールドＦ１に記載された元の中間ノード指定情報を、さらに予備フィールドＦ９に転記する。このとき、更新の有無を示す２値のフラグの代わりに、更新の回数を示す情報をデータパケットに付加する（更新回数をインクリメントする）ことが望ましい。それにより、更新後のデータパケットを受信する中間ノードは、予備フィールドＦ９に転記されたノード情報の個数を容易に知ることができる。第５の例においては、予備フィールドＦ９が中間ノードの指定の履歴を表すため、１つの中間ノードが複数回指定されることによりループ状の通信経路が形成されることを防止することができる。
　　　（３）データ転送処理の流れ
　図１６Ａ及び図１６Ｂは、それぞれ、本実施形態に係る基地局２２０によるデータ転送処理の流れの一例を示すフローチャートである。
　図１６Ａは、図１５Ａ～図１５Ｃに例示した宛て先フィールド更新処理を含む流れの一例を示している。図１６Ａの例において、まず、基地局２２０の無線受信部１２２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２２２）。そして、無線受信部１２２は、受信したデータパケットを通信制御部２３２へ出力する。次に、通信制御部２３２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２２４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、続いてステップＳ２２６～Ｓ２３２の処理が行われる。
　送信元の装置がＭＴＣ端末である場合、通信制御部２３２は、データパケットの宛て先フィールドにおいて指定すべき中間ノードを、中間ノードデータを用いて特定する（ステップＳ２２６）。次に、通信制御部２３２は、特定した中間ノードを指定する中間ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２３０）。次に、通信制御部２３２は、宛て先フィールドが変更されたことを示すフラグ（例えば、フラグ＝１）をデータパケットに設定する（ステップＳ２３２）
　そして、データパケットは、送信部１２６からコアネットワーク１０へ転送される（ステップＳ２３４）。
　図１６Ｂは、図１５Ｄ及び図１５Ｅに例示した宛て先フィールド更新処理を含む流れの一例を示している。図１６Ｂの例において、まず、基地局２２０の無線受信部１２２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２２２）。そして、無線受信部１２２は、受信したデータパケットを通信制御部２３２へ出力する。次に、通信制御部２３２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２２４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、続いてステップＳ２２６～Ｓ２３３の処理が行われる。
　送信元の装置がＭＴＣ端末である場合、通信制御部２３２は、データパケットの宛て先フィールドにおいて指定すべき中間ノードを、中間ノードデータを用いて特定する（ステップＳ２２６）。次に、通信制御部２３２は、データパケットの受信時に宛て先フィールドに記述されている宛て先ノードに関する情報を予備フィールドなどの他のフィールドに転記する（ステップＳ２２８）。次に、通信制御部２３２は、特定した中間ノードを指定する中間ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２３０）。次に、通信制御部２３２は、フラグを更新する（ステップＳ２３３）
　そして、データパケットは、送信部１２６からコアネットワーク１０へ転送される（ステップＳ２３４）。
　　［２－４．中間ノード］
　　　（１）装置の構成例
　図１７は、中間ノードとして動作する通信装置２４０の構成の一例を示すブロック図である。図１７を参照すると、通信装置２４０は、受信部１４２、送信部１４４、記憶部２５０、通信制御部２５２及び情報管理部２５４を備える。
　記憶部２５０は、記憶媒体を用いて、通信制御部２５２及び情報管理部２５４による処理のためのプログラム及びデータを記憶する。また、本実施形態において、記憶部２５０は、データパケット内の制御情報とデータパケットの宛て先ノードとを対応付ける、後述する宛て先ノードデータを記憶してもよい。また、記憶部２５０は、第１の実施形態に係る通信装置１４０の記憶部１５０と同様、データパケット内の制御情報とデータパケットの転送先ノードとを対応付ける転送先データを記憶してもよい。
　通信制御部２５２は、自装置が宛て先フィールドにおいて指定されているデータパケットを受信部１４２が受信すると、宛て先フィールドとは異なるフィールドに含まれる情報から、当該データパケットの最終的な宛て先ノードを識別する。より具体的には、通信制御部２５２は、例えば、データパケット内の制御情報とデータパケットの宛て先ノードとを対応付ける宛て先ノードデータを用いて、データパケットごとに最終的な宛て先ノードを識別することができる。
　図１８は、記憶部２５０により記憶され得る宛て先ノードデータの一例について説明するための説明図である。図１８を参照すると、一例としての宛て先ノードデータ２５１は、「アプリケーションクラス」、「端末クラス」、「事業者」及び「宛て先ノード」という４つのデータ項目を有する。このうち、「アプリケーションクラス」、「端末クラス」及び「事業者」の組合せが、いずれかの宛て先ノードを識別するための識別キーとなる。例えば、アプリケーションクラスが「Ｃ１」、端末クラスが「Ｔ３」、事業者が「Ｊ０１」であるデータパケットは、宛て先ノードＤ１に対応する。アプリケーションクラスが「Ｃ１」、端末クラスが「Ｔ３」、事業者が「Ｊ０２」であるデータパケットは、宛て先ノードＤ２に対応する（残りのレコードについての説明は省略する）。なお、宛て先ノードを識別するための識別キーとして用いられ得る制御情報は、かかる例に限定されない。例えば、図３に例示した制御情報（又は他の制御情報）のうち任意の項目が、宛て先ノードを識別するための識別キーとして用いられてよい。本実施形態において、このような宛て先ノードデータは、図１０に例示した情報管理サーバ２７０において管理され、中間ノード間で共有され得る。
　通信制御部２５２は、このような宛て先ノードデータを用いて、データパケット内の制御情報と対応する宛て先ノードを最終的な宛て先ノードとして識別することができる。なお、中間ノードを指定した装置（例えば、上述した基地局２２０）により予備フィールドに宛て先ノードに関する情報が転記されている場合には、通信制御部２５２は、宛て先ノードデータを用いることなく、最終的な宛て先ノードを識別することができる。その場合、記憶部２５０は、図１８に例示した宛て先ノードデータを記憶しなくてもよい。
　通信制御部２５２は、上述したように識別した宛て先ノードを指定する宛て先ノード指定情報を、データパケットの宛て先フィールドに挿入する。即ち、通信制御部２５２は、一時的に指定された宛て先フィールドの情報を、最終的にデータパケットが到達すべき宛て先ノードの情報に修正する。そして、通信制御部２５２は、最終的な宛て先ノード指定情報を宛て先フィールドに含むデータパケットを、送信部１４４により送信させる。
　なお、通信制御部２５２は、第１の実施形態に係る転送ノードと同様、トラフィックが分散されるように、複数の転送先ノードの候補からデータパケットの転送先ノード（次のホップ）を選択してもよい。また、通信制御部２５２は、最終的な宛て先ノードの代わりに、別の中間ノードを指定する中間ノード指定情報を宛て先フィールドに挿入して、当該別の中間ノードへデータパケットをさらに転送してもよい。
　情報管理部２５４は、記憶部２５０により記憶されている宛て先ノードデータを更新するための更新データを情報管理サーバ２７０から取得し、取得した更新データを用いて宛て先ノードデータを更新する。情報管理部２５４は、更新データの配信を一定の頻度で定期的に情報管理サーバ２７０に要求してもよい。その代わりに、情報管理部２５４は、情報管理サーバ２７０から更新データが受信された場合に、受動的に宛て先ノードデータを更新してもよい。
　　　（２）データ転送処理の流れ
　図１９Ａ及び図１９Ｂは、それぞれ、本実施形態に係る通信装置２４０によるデータ転送処理の流れの一例を示すフローチャートである。
　図１９Ａは、宛て先ノードデータを用いた宛て先ノードの識別処理を含む流れの一例を示している。図１９Ａの例において、まず、通信装置２４０の受信部１４２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２４２）。そして、受信部１４２は、受信したデータパケットを通信制御部２５２へ出力する。次に、通信制御部２５２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２４４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、処理はステップＳ２４６へ進む。一方、データパケットがＭＴＣ通信のためのパケットでなければ、処理はステップＳ２５４へ進む。
　ステップＳ２４６では、通信制御部２５２は、データパケットのヘッダ領域に含まれる制御情報を取得する（ステップＳ２４６）。次に、通信制御部２５２は、例えば、取得した制御情報に含まれるアプリケーションクラス、端末クラス及び事業者の組合せに対応する転送先ノードを、宛て先ノードデータを用いて識別する（ステップＳ２４８）。そして、通信制御部２５２は、識別した宛て先ノードを指定する宛て先ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２５０）。このとき、通信制御部２５２は、必要に応じてデータパケット内のフラグの値を更新する。
　そして、送信部１４４は、次のホップ（例えば、トラフィックが分散されるように選択される転送先ノード又は既定の通信ノード）へデータパケットを転送する（ステップＳ２５４）。
　図１９Ｂは、宛て先ノードデータを用いないデータ転送処理の流れの一例を示している。図１９Ｂの例において、まず、通信装置２４０の受信部１４２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２４２）。そして、受信部１４２は、受信したデータパケットを通信制御部２５２へ出力する。次に、通信制御部２５２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２４４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、処理はステップＳ２４７へ進む。一方、データパケットがＭＴＣ通信のためのパケットでなければ、処理はステップＳ２５４へ進む。
　ステップＳ２４７では、通信制御部２５２は、データパケット内のフラグを参照することにより、宛て先フィールドが変更されているか否かを判定する（ステップＳ２４７）。ここで、宛て先フィールドが変更されている場合には、処理はステップＳ２４９へ進む。一方、宛て先フィールドが変更されていない場合には、処理はステップＳ２５４へ進む。
　ステップＳ２４９では、通信制御部２５２は、データパケット内の予備フィールドに転記された情報から宛て先ノードを識別する（ステップＳ２４９）。そして、通信制御部２５２は、識別した宛て先ノードを指定する宛て先ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２５２）。このとき、通信制御部２５２は、必要に応じてデータパケット内のフラグの値を更新する。
　そして、送信部１４４は、次のホップ（例えば、トラフィックが分散されるように選択される転送先ノード又は既定の通信ノード）へデータパケットを転送する（ステップＳ２５４）。
　　［２－５．通信経路の例］
　図２０は、本実施形態により実現され得る通信経路の例について説明するための説明図である。図２０を参照すると、一例としてのＭＴＣ通信の送信元である端末装置２００と、宛て先であるアプリケーションサーバ１９０との間の簡略化された３つの通信経路Ｒ１、Ｒ２及びＲ３が示されている。なお、ＡＣＫ及びＮＡＣＫなど付随的に行われる制御シグナリングについては、図中に示していない。通信経路Ｒ１は、端末装置２００とアプリケーションサーバ１９０との間の最短の（ルーティングメトリックが最適な）経路である。一方、通信経路Ｒ２及びＲ３は、通信経路Ｒ１に含まれる一部のリンクを迂回する冗長な経路である。
　例えば、端末装置２００又は基地局２２０がデータパケットの宛て先フィールドにおいて中間ノードＭ１を指定した場合には、当該データパケットは通信経路Ｒ２を経由してアプリケーションサーバ１９０に到達し得る。また、例えば、端末装置２００又は基地局２２０が中間ノードＭ２を指定し、さらに中間ノードＭ２が中間ノードＭ３を指定した場合には、当該データパケットは通信経路Ｒ３を経由してアプリケーションサーバ１９０に到達し得る。このようにＭＴＣ通信のデータパケットを最短の経路から迂回させることで、トラフィックが分散され、特定の通信経路へのトラフィックの集中が未然に防がれる。
　　［２－６．情報管理サーバ］
　　　（１）装置の構成例
　図２１は、本実施形態に係る情報管理サーバ２７０の構成の一例を示すブロック図である。図２１を参照すると、情報管理サーバ２７０は、受信部２７２、送信部２７４、記憶部２８０及び情報管理部２８２を備える。
　受信部２７２及び送信部２７４は、情報管理サーバ２７０が他の通信装置との間で通信を行うための通信インタフェースである。
　記憶部２８０は、記憶媒体を用いて、図１８に例示した宛て先ノードデータと同様のデータ項目を有する宛て先ノードデータのマスタを記憶する。また、記憶部２８０は、図１４Ａ及び図１４Ｂに例示した中間ノードデータと同様のデータ項目を有する中間ノードデータのマスタを記憶してもよい。さらに、記憶部２８０は、第１の実施形態で説明した転送先データのマスタを記憶してもよい。
　情報管理部２８２は、記憶部２８０により記憶される情報についてのマスタ管理機能を提供する。例えば、情報管理部２８２は、通信システム２に新たにアプリケーションサーバ１９０が導入された場合にアプリケーションに関する新たな情報の登録を受け付けるためのインタフェースを提供する。当該インタフェースは、例えば、装置の画面上でユーザからの情報入力を受け付けるグラフィカルユーザインタフェース（ＧＵＩ）であってよい。その代わりに、当該インタフェースは、例えば、アプリケーションサーバ１９０から登録情報を受信するＡＰＩ（Application　Program　Interface）であってもよい。また、情報管理部２８２が提供するインタフェースは、登録済みの情報の変更及び削除を受け付けてもよい。そして、情報管理部２８２は、マスタの更新（情報の追加、変更又は削除）が発生すると、マスタの差分に基づく更新データを通信システム２に含まれる通信ノードへ配信する。
　　　（２）更新データの例
　図２２は、更新データの一例について説明するための説明図である。例えば、事業者Ｊ０１が、新たにアプリケーションサーバＤ１、Ｄ３及びＤ５を導入した場合を想定する。その場合、事業者Ｊ０１のユーザ（エンジニア）は、情報管理部２８２が提供するユーザインタフェースを介して、アプリケーションサーバＤ１、Ｄ３及びＤ５の各々についての情報を情報管理サーバ２７０に登録する。ここで登録される情報は、例えば、各アプリケーションサーバに対応する、アプリケーションクラス、端末クラス及びＭＴＣ通信のための通信スケジュールなどを含み得る。その結果、情報管理部２８２は、記憶部２８０により記憶されている宛て先ノードデータのマスタを更新すると共に、図２２に例示したような更新データ２８３を生成する。
　図２２を参照すると、更新データ２８３は、事業者ＩＤをキーとして、宛て先ノードの候補となり得るアプリケーションサーバごとに、対応するアプリケーションクラス、端末クラス及び通信スケジュールの情報を記述したデータである。更新データ２８３の各レコードには、「追加」、「変更」又は「削除」などの値をとり得る「更新区分」が付与される。情報管理サーバ２７０からこのような更新データ２８３を受信した中間ノードは、更新データ２８３を用いて、個々に記憶している宛て先ノードデータを最新のマスタに同期させる。
　　　（３）更新データ配信処理の流れ
　図２３Ａ及び図２３Ｂは、それぞれ、本実施形態に係る情報管理サーバ２７０による更新データ配信処理の流れの一例を示すフローチャートである。
　図２３Ａは、マスタの更新の都度、更新データが中間ノードへ配信される例を示している。図２３Ａの例において、まず、情報管理サーバ２７０の情報管理部２８２は、ＧＵＩを介して（又はアプリケーションサーバ１９０から）、アプリケーションサーバ１９０についての登録情報を取得する（ステップＳ２７２）。次に、情報管理部２８２は、取得した登録情報を用いて、記憶部２８０により記憶されている宛て先ノードデータのマスタを更新する（ステップＳ２７４）。次に、情報管理部２８２は、更新により生じたマスタの差分に基づいて、図２２に例示したような更新データを生成する（ステップＳ２７６）。そして、送信部２７４は、情報管理部２８２により生成された更新データを、各中間ノードに配信する（ステップＳ２７８）。なお、更新データは、各中間ノードへブロードキャストされてもよく、個別にユニキャスト又はマルチキャストされてもよい。
　図２３Ｂは、中間ノードからの要求に応じて更新データが中間ノードへ配信される例を示している。図２３Ｂの例において、情報管理サーバ２７０の受信部２７２により中間ノードからの更新データ配信要求が受信されると、処理はステップＳ２８４へ進む（ステップＳ２８２）。ステップＳ２８４において、情報管理部２８２は、更新データの前回の配信以降、宛て先ノードデータのマスタに差分が生じているか否かを判定する（ステップＳ２８４）。ここで、宛て先ノードデータのマスタに差分が生じている場合には、情報管理部２８２は、マスタの差分に基づいて更新データを生成する（ステップＳ２８６）。そして、送信部２７４は、情報管理部２８２により生成された更新データを、要求元の中間ノードに配信する（ステップＳ２７８）。一方、宛て先ノードデータのマスタに差分が生じていない場合には、情報管理部２８２は、差分が無いことを要求元の中間ノードに通知する（ステップＳ２８９）。
　なお、図２３Ａ及び図２３Ｂの例に限定されず、情報管理サーバ２７０は、例えば、一定の頻度で定期的にマスタの差分の有無を判定し、差分が生じている場合に能動的に各中間ノードへ更新データを配信してもよい。
　　　（４）データ更新処理の流れ
　図２４は、本実施形態に係る中間ノードによる宛て先ノードデータ更新処理の流れの一例を示すフローチャートである。
　図２４を参照すると、まず、通信装置２４０の受信部１４２は、情報管理サーバ２７０から配信される宛て先ノードデータの更新データを受信する（ステップＳ２９１）。次に、情報管理部２５４は、更新データ内に新たなアプリケーションクラスが存在するか否かを判定する（ステップＳ２９２）。ここで、更新データ内に新たなアプリケーションクラスが存在する場合には、当該新たなアプリケーションクラスを図１８に例示した宛て先ノードデータ２５１に追加する（ステップＳ２９３）。また、情報管理部２５４は、更新データ内に新たな端末クラスが存在するか否かを判定する（ステップＳ２９４）。ここで、更新データ内に新たな端末クラスが存在する場合には、当該新たな端末クラスを宛て先ノードデータ２５１に追加する（ステップＳ２９５）。さらに、情報管理部２５４は、更新データ内の事業者ＩＤが新たな事業者の事業者ＩＤであるか否かを判定する（ステップＳ２９６）。ここで、更新データ内の事業者ＩＤが新たな事業者の事業者ＩＤである場合には、当該新たな事業者の事業者ＩＤを宛て先ノードデータ２５１に追加する（ステップＳ２９７）。そして、情報管理部２５４は、更新データ内のアプリケーションクラス、端末クラス及び事業者ＩＤの組合せに対応する宛て先ノード（のＩＰアドレス又はホスト名などの情報）を宛て先ノードデータ２５１に追加し、又は既存の宛て先ノードを更新する（ステップＳ２９８）。
　　［２－７．ＤＲＸの管理］
　なお、図２２に例示した更新データ２８３に含まれる通信スケジュール情報は、中間ノードからさらに対応する各端末装置２００へ配信され得る。その代わりに、情報管理サーバ２７０は、更新データ２８３とは別に通信スケジュール情報を各端末装置２００へ配信してもよい。通信スケジュール情報を受信した各端末装置２００は、当該通信スケジュール情報に従って自装置のスリープ時間を制御し、間欠動作（ＤＲＸ：Discontinuous　Reception）を実現する。
　端末装置２００の間欠動作の制御は、図２２に例示した通信スケジュール情報のように、１日１回（“every　day”）又は１週間に１回（“every　week”）といった単純なパラメータに従って制御されてもよい。例えば、１日１回（“every　day”）が指定された場合には、端末装置２００の無線受信部１２２及び無線送信部１２４は、１日１回だけ任意の時間帯にウェイクアップし、その時間帯にアプリケーションデータを生成して上述したデータパケットをアプリケーションサーバ１９０に送信する。通信スケジュール情報は、間欠動作の周期に加えて、ウェイクアップの時間帯に関する情報（例えば、開始時刻及び終了時刻又は時間長など）を含んでもよい。
　また、各端末装置２００について、基地局２２０又はその他の通信ノードにより、上述したウェイクアップの時間帯におけるより短い補助的な間欠動作の周期が決定されてもよい。その場合には、端末装置２００の無線受信部１２２及び無線送信部１２４は、指定されたウェイクアップの時間帯においても、例えば自装置のために通信リソースがスケジューリングされたタイミングを除いて、スリープし得る。それにより、端末装置２００の消費電力をより大きく低減することができる。
　　［２－８．第２の実施形態のまとめ］
　ここまで、図１０～図２４を用いて、第２の実施形態について説明した。本実施形態によれば、データパケットの宛て先ノードまでの経路上の、宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報が、ＭＴＣ端末から送信されるデータパケットの宛て先フィールドに挿入される。それにより、ＭＴＣ通信のトラフィックが特定の通信経路に集中することなく、指定された中間ノードを経由する経路に迂回する。その結果、トラフィックが分散され、ＭＴＣ通信におけるトラフィックの輻輳が回避され又は緩和される。
　また、本実施形態によれば、宛て先フィールドに中間ノード指定情報を挿入する装置は、ＭＴＣ端末からデータパケットを受信する通信ノード（例えば、基地局など）であってよい。このような通信ノードがデータパケットに中間ノード指定情報を挿入する場合には、ＭＴＣ端末に処理ロジックの改変などのインパクトを与えることなく、上述した実施形態による輻輳回避の手法を導入することができる。
　また、本実施形態によれば、指定された中間ノードは、データパケット内に挿入されるＭＴＣ端末に関する制御情報、又は予備的なフィールドに転記される情報から、データパケットの最終的な宛て先ノードを識別する。従って、データパケットの宛て先フィールドが変更された場合であっても、中間ノードを経由して適切にデータパケットを最終的な宛て先ノード（例えば、対応するアプリケーションサーバ）に届けることができる。
　本実施形態において、ＭＴＣ端末に関する制御情報を用いて宛て先ノードが識別される場合には、予備的なフィールドに宛て先ノードに関する情報を転記する必要がないため、既存のパケットフォーマットを効果的に活用することができる。一方、予備的なフィールドに転記される情報から宛て先ノードが識別される場合には、各中間ノードは宛て先ノードデータを保持しなくてよいため、宛て先ノードデータの参照に要する処理コスト及び記憶媒体のリソースを削減することができる。
　　［２－９．応用例］
　第２の実施形態では、主にＭＴＣ端末から送信されるデータパケットを中間ノードを経由する経路に迂回させる例について説明した。しかしながら、上述した中間ノードの指定の仕組みは、ＭＴＣ端末へ送信されるデータパケットにも適用可能である。例えば、図１０に示した通信装置１４０は、図１５Ｄ又は図１５Ｅに示した宛て先フィールド更新処理に従って、端末装置２００へ送信されるデータパケットの宛て先フィールドに中間ノード指定情報を挿入すると共に、宛て先フィールドに記述されていた端末装置２００のアドレスなどの情報を予備フィールドに転記してもよい。
　なお、本明細書において説明した各装置による一連の制御処理は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組合せのいずれを用いて実現されてもよい。ソフトウェアを構成するプログラムは、例えば、各装置の内部又は外部に設けられる記憶媒体に予め格納される。そして、各プログラムは、例えば、実行時にＲＡＭ（Random　Access　Memory）に読み込まれ、ＣＰＵ（Central　Processing　Unit）などのプロセッサにより実行される。
　また、本明細書では、ＭＴＣ端末である端末装置１００及び２００が無線通信によりネットワークにアクセスする例について主に説明した。しかしながら、上述した２つの実施形態の効果は、ＭＴＣ端末が有線通信によりネットワークにアクセスする場合にも同等に享受され得る。
　以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
　１，２　　　　　　通信システム
　１０　　　　　　　コアネットワーク
　２０　　　　　　　ネットワーク
　１００，２００　　端末装置
　１２０，２２０　　基地局
　１４０　　　　　　通信装置（転送ノード）
　２４０　　　　　　通信装置（中間ノード）
　２７０　　　　　　情報管理サーバ
　１９０　　　　　　アプリケーションサーバ

Claims (13)

  1. 　複数の通信ノードを含む通信ネットワーク内の通信装置であって、
    　端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、
    　前記端末装置がＭＴＣ端末である場合に、複数の転送先ノードの候補から前記データパケットの転送先ノードを選択する通信制御部と、
    　前記通信制御部により選択される転送先ノードへ前記データパケットを送信する送信部と、
    　を備える通信装置。
  2. 　前記通信制御部は、前記データパケット内の制御情報に基づいて、前記データパケットの転送先ノードを選択する、請求項１に記載の通信装置。
  3. 　前記通信装置は、データパケットの分類と転送先ノードとを対応付ける転送先データを記憶する記憶部、をさらに備え、
    　前記通信制御部は、前記制御情報に応じて前記データパケットを分類し、前記転送先データにおいて前記データパケットの分類と対応付けられた転送先ノードを前記データパケットの転送先ノードとして選択する、
    　請求項２に記載の通信装置。
  4. 　前記制御情報は、前記端末装置の端末ＩＤ、クラス若しくはグループ、又は前記データパケットに関連するアプリケーションのアプリケーションＩＤ若しくはクラスを含む、請求項２に記載の通信装置。
  5. 　前記通信制御部は、前記制御情報に応じて各データパケットを分類し、同じ分類に属するデータパケットの転送先が複数の転送先ノードに分散されるように、各データパケットの転送先ノードを選択する、請求項２に記載の通信装置。
  6. 　前記通信制御部は、前記データパケットの宛て先ノードまでの経路に関するルーティングメトリックとは関係なく、前記複数の転送先ノードの候補から前記データパケットの転送先ノードを選択する、請求項１に記載の通信装置。
  7. 　前記通信制御部は、前記データパケットの宛て先ノードまでの経路上の前記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、前記データパケットの宛て先フィールドに挿入する、請求項１に記載の通信装置。
  8. 　前記通信制御部は、前記データパケットの受信時に前記宛て先フィールドに記述されている情報を、他のフィールドに転記する、請求項７に記載の通信装置。
  9. 　前記通信制御部は、前記宛て先フィールドが変更されたことを示すフラグを前記データパケットに付加する、請求項７に記載の通信装置。
  10. 　前記通信ネットワークは、セルラー通信システムのコアネットワークである、請求項１に記載の通信装置。
  11. 　複数の通信ノードを含む通信ネットワーク内の通信装置における通信制御方法であって、
    　端末装置から送信され又は端末装置へ送信されるデータパケットを受信することと、
    　前記端末装置がＭＴＣ端末である場合に、複数の転送先ノードの候補から前記データパケットの転送先ノードを選択することと、
    　選択した転送先ノードへ前記データパケットを送信することと、
    　を含む通信制御方法。
  12. 　端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、
    　前記端末装置がＭＴＣ端末である場合に、複数の転送先ノードの候補から前記データパケットの転送先ノードを選択する通信制御部と、
    　前記通信制御部により選択される転送先ノードへ前記データパケットを送信する送信部と、
    　を備える通信装置と、
    　それぞれ前記転送先ノードの候補である前記複数の通信ノードと、
    　を含む通信システム。
  13. 　複数の通信ノードを含む通信ネットワーク内の通信装置であって、
    　端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、
    　前記端末装置がＭＴＣ端末である場合に複数の転送先ノードの候補から前記データパケットの転送先ノードを選択する通信ノードへ、前記データパケットを送信する送信部と、
    　転送先ノードの選択のための前記通信ノードによる前記データパケットの分類に利用される制御情報を、前記データパケットに挿入する通信制御部と、
    　を備える通信装置。
PCT/JP2011/068288 2010-10-04 2011-08-10 通信装置、通信制御方法及び通信システム WO2012046503A1 (ja)

Priority Applications (12)

Application Number Priority Date Filing Date Title
AU2011311009A AU2011311009A1 (en) 2010-10-04 2011-08-10 Communication device, communication control method, and communication system
KR20137007307A KR20130099073A (ko) 2010-10-04 2011-08-10 통신 장치, 통신 제어 방법 및 통신 시스템
CN2011800468815A CN103155649A (zh) 2010-10-04 2011-08-10 通信装置、通信控制方法以及通信系统
BR112013007690A BR112013007690A2 (pt) 2010-10-04 2011-08-10 Dispositivo e sistema de comunicação, e, método de controle de comunicação
US13/819,353 US9143885B2 (en) 2010-10-04 2011-08-10 Communication device, communication control method, and communication system
EP11830436.9A EP2627123B1 (en) 2010-10-04 2011-08-10 Communication device, communication control method, and communication system
CA2808204A CA2808204A1 (en) 2010-10-04 2011-08-10 Communication device, communication control method, and communication system
ES11830436T ES2701761T3 (es) 2010-10-04 2011-08-10 Dispositivo de comunicación, procedimiento de control de comunicación y sistema de comunicación
RU2013113963/08A RU2013113963A (ru) 2010-10-04 2011-08-10 Устройство связи, способ управления связью и система связи
US14/824,296 US9949058B2 (en) 2010-10-04 2015-08-12 Communication device, communication control method, and communication system
US15/924,649 US10334391B2 (en) 2010-10-04 2018-03-19 Communication device, communication control method, and communication system
US16/414,291 US10893376B2 (en) 2010-10-04 2019-05-16 Communication device, communication control method, and communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-225078 2010-10-04
JP2010225078A JP5682208B2 (ja) 2010-10-04 2010-10-04 通信装置、通信制御方法及び通信システム

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/819,353 A-371-Of-International US9143885B2 (en) 2010-10-04 2011-08-10 Communication device, communication control method, and communication system
US14/824,296 Continuation US9949058B2 (en) 2010-10-04 2015-08-12 Communication device, communication control method, and communication system

Publications (1)

Publication Number Publication Date
WO2012046503A1 true WO2012046503A1 (ja) 2012-04-12

Family

ID=45927502

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/068288 WO2012046503A1 (ja) 2010-10-04 2011-08-10 通信装置、通信制御方法及び通信システム

Country Status (11)

Country Link
US (4) US9143885B2 (ja)
EP (1) EP2627123B1 (ja)
JP (1) JP5682208B2 (ja)
KR (1) KR20130099073A (ja)
CN (1) CN103155649A (ja)
AU (1) AU2011311009A1 (ja)
BR (1) BR112013007690A2 (ja)
CA (1) CA2808204A1 (ja)
ES (1) ES2701761T3 (ja)
RU (1) RU2013113963A (ja)
WO (1) WO2012046503A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014002355A1 (en) * 2012-06-29 2014-01-03 Nec Corporation Optimization of mtc device trigger delivery

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5682208B2 (ja) 2010-10-04 2015-03-11 ソニー株式会社 通信装置、通信制御方法及び通信システム
CN103460786B (zh) 2011-04-01 2016-11-09 交互数字专利控股公司 用于共享公共pdp上下文的系统和方法
KR101723274B1 (ko) * 2011-09-26 2017-04-18 엘지전자 주식회사 무선 접속 시스템에서 액세스 포인트에 최소 보장 자원량을 할당하기 위한 방법 및 장치
US8638724B1 (en) * 2012-06-01 2014-01-28 Sprint Communications Company L.P. Machine-to-machine traffic indicator
JP5583830B1 (ja) * 2013-09-27 2014-09-03 日本瓦斯株式会社 Ｌｐガスメータの指針値入力チェックシステムおよび方法
WO2015142232A1 (en) * 2014-03-19 2015-09-24 Telefonaktiebolaget L M Ericsson (Publ) Network assistance in groupcast transmission
JP6760294B2 (ja) * 2015-09-11 2020-09-23 ソニー株式会社 通信制御装置、記憶装置、通信制御判断装置及びサーバ装置、ならびに、方法及びコンピュータプログラム
EP3725106A1 (en) 2017-12-12 2020-10-21 Telefonaktiebolaget Lm Ericsson (Publ) Processing delay tolerant communications
JP7047660B2 (ja) * 2018-08-08 2022-04-05 日本電信電話株式会社 通知装置および通知方法
CN111224743B (zh) * 2018-11-23 2022-11-15 中兴通讯股份有限公司 一种检测方法、终端和计算机可读存储介质
WO2020255654A1 (ja) * 2019-06-17 2020-12-24 株式会社Ｎｔｔドコモ 通信装置及び通信方法
CN116099147B (zh) * 2023-03-09 2024-04-16 重新定义(杭州)科技发展有限公司 一种智能消防管理系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006332755A (ja) * 2005-05-23 2006-12-07 Nippon Telegr & Teleph Corp <Ntt> コンテクストスイッチ通信網、コンテクストスイッチおよびコンテクストベースドルーチング方法
JP2007151013A (ja) * 2005-11-30 2007-06-14 Nippon Telegr & Teleph Corp <Ntt> セマンティックスイッチ通信網、セマンティックスイッチ、およびセマンティック通信方法
JP2007156779A (ja) * 2005-12-05 2007-06-21 Hitachi Ltd センサネットシステム、基地局及びセンシングデータの中継方法
JP2009130657A (ja) 2007-11-26 2009-06-11 Fujitsu Ltd 移動通信システムの負荷分散方法及び移動通信システム

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2001234860A1 (en) * 2000-02-04 2001-08-14 Hrl Laboratories, Llc A system for pricing-based quality of service (pqos) control in networks
US7376125B1 (en) * 2002-06-04 2008-05-20 Fortinet, Inc. Service processing switch
US8555352B2 (en) * 2003-06-20 2013-10-08 Juniper Networks, Inc. Controlling access nodes with network transport devices within wireless mobile networks
US8081566B1 (en) * 2004-04-19 2011-12-20 Rockstar BIDCO, LLP Method and apparatus for indicating congestion in a source routed network
US7774008B2 (en) * 2006-12-22 2010-08-10 Cellco Partnership MDN-less SMS messaging (network solution) for wireless M2M application
US8279870B2 (en) * 2007-08-01 2012-10-02 Silver Spring Networks, Inc. Method and system of routing in a utility smart-grid network
CN101369960A (zh) * 2007-08-17 2009-02-18 华为技术有限公司 在下一代网络中处理消息的方法、装置及系统
US8284664B1 (en) * 2007-09-28 2012-10-09 Juniper Networks, Inc. Redirecting data units to service modules based on service tags and a redirection table
US8737989B2 (en) * 2008-08-29 2014-05-27 Apple Inc. Methods and apparatus for machine-to-machine based communication service classes
US8812726B2 (en) * 2008-09-09 2014-08-19 Cisco Technology, Inc. Service insertion in a computer network using internet protocol version 6 techniques
US20100142538A1 (en) * 2008-12-09 2010-06-10 Enfora, Inc. M2M data router
US20100192225A1 (en) * 2009-01-28 2010-07-29 Juniper Networks, Inc. Efficient application identification with network devices
US8265022B2 (en) * 2009-02-10 2012-09-11 Apple Inc. Apparatus and methods for transmission of emergency call data over wireless networks
EP3352413B1 (en) * 2009-07-17 2019-08-14 Koninklijke KPN N.V. Information transmission in a machine-to-machine telecommunications network
EP2603034B1 (en) * 2009-07-17 2015-11-04 Koninklijke KPN N.V. Congestion control in a telecommunications network
EP2494766B1 (en) * 2009-10-29 2013-12-11 Telefonaktiebolaget LM Ericsson (publ) M2m resource preservation in mobile networks
KR101167939B1 (ko) * 2010-01-08 2012-08-02 엘지전자 주식회사 이동통신 시스템에서의 ｍｔｃ 장치의 모니터링 방법
WO2011098150A1 (en) * 2010-02-15 2011-08-18 Telefonaktiebolaget L M Ericsson (Publ) Machine-to-machine device triggering using session initiation protocol uniform resourse identifier
US8462722B2 (en) * 2010-03-26 2013-06-11 Telefonaktiebolaget L M Ericsson (Publ) Access control for machine-type communication devices
US9729516B2 (en) * 2010-04-09 2017-08-08 Gemalto Sa Method of machine-to-machine communication
US8611352B2 (en) * 2010-04-20 2013-12-17 Marvell World Trade Ltd. System and method for adapting a packet processing pipeline
US9015319B2 (en) * 2010-06-04 2015-04-21 Telefonaktiebolaget L M Ericsson (Publ) Layered access control for machine type communication devices
US9100707B2 (en) * 2010-06-11 2015-08-04 At&T Intellectual Property I, L.P. Integrating video share and text messaging with set-top box and access point
EP2599340B1 (en) * 2010-07-27 2014-05-14 Telefonaktiebolaget LM Ericsson (publ) Machine-type communication subscription control
US8650619B2 (en) * 2010-08-19 2014-02-11 Alcatel Lucent Method and apparatus of automated discovery in a communication network
JP5776161B2 (ja) 2010-10-04 2015-09-09 ソニー株式会社 通信装置、通信制御方法及び通信システム
JP5682208B2 (ja) * 2010-10-04 2015-03-11 ソニー株式会社 通信装置、通信制御方法及び通信システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006332755A (ja) * 2005-05-23 2006-12-07 Nippon Telegr & Teleph Corp <Ntt> コンテクストスイッチ通信網、コンテクストスイッチおよびコンテクストベースドルーチング方法
JP2007151013A (ja) * 2005-11-30 2007-06-14 Nippon Telegr & Teleph Corp <Ntt> セマンティックスイッチ通信網、セマンティックスイッチ、およびセマンティック通信方法
JP2007156779A (ja) * 2005-12-05 2007-06-21 Hitachi Ltd センサネットシステム、基地局及びセンシングデータの中継方法
JP2009130657A (ja) 2007-11-26 2009-06-11 Fujitsu Ltd 移動通信システムの負荷分散方法及び移動通信システム

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014002355A1 (en) * 2012-06-29 2014-01-03 Nec Corporation Optimization of mtc device trigger delivery
KR20160141869A (ko) * 2012-06-29 2016-12-09 닛본 덴끼 가부시끼가이샤 Ｍｔｃ 디바이스 트리거 전달의 최적화
KR101725030B1 (ko) 2012-06-29 2017-04-07 닛본 덴끼 가부시끼가이샤 Ｍｔｃ 디바이스 트리거 전달의 최적화
CN107682842A (zh) * 2012-06-29 2018-02-09 日本电气株式会社 Mtc设备触发传递的优化
EP3396986A1 (en) * 2012-06-29 2018-10-31 Nec Corporation Optimization of mtc device trigger delivery
US10447576B2 (en) 2012-06-29 2019-10-15 Nec Corporation Optimization of MTC device trigger delivery
CN107682842B (zh) * 2012-06-29 2020-10-16 日本电气株式会社 Mtc设备触发传递的优化
US11296976B2 (en) 2012-06-29 2022-04-05 Nec Corporation Optimization of MTC device trigger delivery
US11863425B2 (en) 2012-06-29 2024-01-02 Nec Corporation Optimization of MTC device trigger delivery

Also Published As

Publication number Publication date
RU2013113963A (ru) 2014-10-10
EP2627123A1 (en) 2013-08-14
US9949058B2 (en) 2018-04-17
JP2012080413A (ja) 2012-04-19
US20180213346A1 (en) 2018-07-26
US10334391B2 (en) 2019-06-25
EP2627123A4 (en) 2015-11-18
ES2701761T3 (es) 2019-02-25
US20190274002A1 (en) 2019-09-05
KR20130099073A (ko) 2013-09-05
US9143885B2 (en) 2015-09-22
BR112013007690A2 (pt) 2017-10-03
CN103155649A (zh) 2013-06-12
CA2808204A1 (en) 2012-04-12
US20130163520A1 (en) 2013-06-27
US10893376B2 (en) 2021-01-12
AU2011311009A1 (en) 2013-03-28
US20150350808A1 (en) 2015-12-03
EP2627123B1 (en) 2018-11-14
JP5682208B2 (ja) 2015-03-11

Similar Documents

Publication Publication Date Title
JP5776161B2 (ja) 通信装置、通信制御方法及び通信システム
JP5682208B2 (ja) 通信装置、通信制御方法及び通信システム
JP4762735B2 (ja) 無線通信装置、通信経路制御装置、通信経路制御方法及び通信システム
US10491411B2 (en) Limiting forwarding of multicast communications
US10419231B2 (en) Multi-network operation for multicast groups
Chen et al. GAR: Group aware cooperative routing protocol for resource-constraint opportunistic networks
CN105814948B (zh) 用于通信网络中控制连接的方法和布置
US10205665B2 (en) Mesh network nodes configured to alleviate congestion in cellular network
JP6254840B2 (ja) 集約装置、配信方法、配信プログラム、及び、ネットワークシステム
JP6259622B2 (ja) 通信装置、無線ネットワークシステム、無線ネットワーク制御方法、及び、無線ネットワーク制御プログラム
Tang et al. Knowledge‐based replica deletion scheme using directional anti‐packets for vehicular delay‐tolerant networks
CN113170375B (zh) 检测蓝牙网格网络中的关键链路
Dehghani et al. A routing metric for load balancing considering energy and delay constraints in wireless sensor network
Roustaei et al. The Addition of Data Aggregation to SPEED Routing Algorithm While Keeping the Functionality of Available Techniques
Liu A distributed intelligent broadcasting protocol for mobile ad hoc networks

Legal Events

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

Ref document number: 201180046881.5

Country of ref document: CN

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

Ref document number: 11830436

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2808204

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2011830436

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13819353

Country of ref document: US

ENP Entry into the national phase

Ref document number: 20137007307

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2011311009

Country of ref document: AU

Date of ref document: 20110810

Kind code of ref document: A

Ref document number: 2013113963

Country of ref document: RU

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112013007690

Country of ref document: BR

REG Reference to national code

Ref country code: BR

Ref legal event code: B01E

Ref document number: 112013007690

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112013007690

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20130328