WO2019058418A1 - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
WO2019058418A1
WO2019058418A1 PCT/JP2017/033704 JP2017033704W WO2019058418A1 WO 2019058418 A1 WO2019058418 A1 WO 2019058418A1 JP 2017033704 W JP2017033704 W JP 2017033704W WO 2019058418 A1 WO2019058418 A1 WO 2019058418A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
compressed
communication
communication device
header
Prior art date
Application number
PCT/JP2017/033704
Other languages
English (en)
French (fr)
Inventor
智也 庄司
鈴木　道奉
信幸 内川
Original Assignee
株式会社日立国際電気
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立国際電気 filed Critical 株式会社日立国際電気
Priority to JP2019542835A priority Critical patent/JP7008714B2/ja
Priority to US16/644,301 priority patent/US11172051B2/en
Priority to PCT/JP2017/033704 priority patent/WO2019058418A1/ja
Publication of WO2019058418A1 publication Critical patent/WO2019058418A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • the present disclosure relates to a communication apparatus, and is applicable to, for example, a communication apparatus used for an IPv6 network.
  • IP Internet Protocol
  • IPv4 Internet Protocol version 4
  • IP address 32-bit address
  • a global IP address which uniquely assigns this IP address to each source / destination is adopted, and each source / destination is determined according to the IP address.
  • the world of the Internet is rapidly expanding, and the range which can be defined by 32 bits of IPv4 address is fully used, and the condition that can not be newly assigned, that is, the exhaustion of the global address becomes a problem.
  • IPv6 Internet Protocol version 6
  • Mobile IP Mobile IP
  • WiMAX Worldwide Interoperability for Microwave Access
  • IPv6 networks and communications will be used in the future even in simple or broadband wireless networks, but expansion of address information will increase control information, and radio link utilization rates As a result, the amount of data that the user is supposed to send to the destination may be reduced.
  • a communication method called 6LoWPAN is uniquely decided from the above concern and reduction of the amount of information is carried out, but when it is used, all communication devices are used Medium-scale and wide-band networks using the same scheme from reduction processing using information from the BLE protocol, which is a data link layer protocol, and from the fact that it is necessary to It is impossible to apply to
  • BLE Bluetooth Low Energy
  • An object of the present disclosure is to provide a communication apparatus capable of performing optimal traffic suppression in consideration of a communication apparatus that can not perform information compression processing.
  • the communication device used in a wireless system that is configured of a plurality of communication devices and performs communication via one or more communication devices is a neighbor search message and its response among the plurality of communication devices, or ad hoc routing
  • the communication apparatus of the embodiment has a function related to management and suppression of communication traffic in IPv6 communication or relay (routing) in wireless communication.
  • control information header information
  • information replacement including IPv6 address information
  • FIG. 1 is a diagram showing a network configuration.
  • the network 100 includes a communication device # 1 (101), a communication device # 2 (102), a communication device # 3 (103), a communication device # 4 (104), and a communication device # 5 (105).
  • communication devices # 1 to # 5 (101 to 105) constitute an ad hoc network (wireless network (dotted line double-headed arrow), and each of the communication devices # 1 to # 5 (101 to 105) Terminals # 1 to # 5 (111 to 115) are connected by a wired autonomous network (solid line), and terminal # 6 (116) is also connected to communication apparatus # 1 (101). ... # 5 (101 to 105) are communication devices relaying both the wired autonomous network and the wireless network.
  • FIG. 2 is a diagram showing the configuration of a communication apparatus according to a comparative example.
  • FIG. 3 is a diagram showing the configuration of the communication apparatus according to the embodiment.
  • ICMPv6 Internet Control Message Protocol for IPv6
  • ad hoc routing protocol wireless network routing protocol
  • PHY physical which is layer 1 (L1).
  • the communication device 200 When there is an IPv6 packet input from the wired autonomous network, the communication device 200 confirms the communication path registered in its own routing table 207. After confirmation, if there is one that matches the destination IP address of the IPv6 packet and the communication path registered in its own routing table 207, the IPv6 packet is output to the output interface set at the time of registration.
  • the IPv6 packet is composed of an IPv6 header and a payload (extension header and data).
  • the routing table 207 works similarly for IPv6 packets input from the interface on the wireless side.
  • the output destination of the route registered in the routing table 207 can be the wired autonomous network side interface or the wireless side interface.
  • the communication apparatus 200 also has a function of storing information on a path matching the input data in a temporary storage area (routing table cache (RTC)) 217.
  • RTC routing table cache
  • the communication device 300 performs an IPv6 Comp / DeComp (IP6CD) module 301 that performs compression and decompression of IPv6 header information in the NW layer. Equipped with The IP6 CD module 301 is configured by software, for example.
  • the communication device 300 includes a CPU that executes software and a memory that stores the software.
  • FIG. 4 is a flowchart showing processing at the time of wireless transmission of the communication apparatus of FIG.
  • FIG. 5 is a flowchart showing processing upon wireless reception of the communication apparatus of FIG.
  • the IP6CD module 301 receives an IPv6 packet from the wired network (step S11).
  • the IP6 CD module 301 determines whether the input information (upper layer protocol of the received IPv6 packet) is a neighbor node search message according to ICMPv6 with the own device as the transmission source (step S12). In the case (YES), the information to the effect that the own communication device can be compressed is stored in the payload information in the message (step S13), and the IPv6 packet is output (transferred) to the MAC layer 211 or later of the wireless network. , Wirelessly transmit (step S14).
  • step S12 determines whether the upper protocol of the received IPv6 packet is an ad hoc routing message (step S15). If YES, the process proceeds to step S13.
  • the communication apparatus 300 can be notified by adding information indicating that the apparatus itself can compress IPv6 header information in neighbor node search message transmission or ad hoc routing message transmission.
  • an IPv6 packet is received from the wireless network (step S21).
  • the IP6CD module 301 determines whether the data (upper layer protocol of the received IPv6 packet) input from the MAC layer 211 of the wireless network is a neighbor node search message according to ICMPv6 (step S22). If there is (in the case of YES), it is checked whether information (compressible information) to the effect that the communication apparatus can be compressed is stored in the neighboring node search message (step S23).
  • step S24 It is judged whether or not compressible information is stored in the neighbor node search message (step S24), and if it is stored (in the case of YES), an IPv6 header for the IPv6 packet to be sent to the target communication device It is registered in the IPv6 compression database (IPv6 CompDataBase) that the information can be compressed (the IPv6 address of the compressible communication device) (step S25). Then, the IPv6 packet is transferred to the wired network side (step S26). In the case of NO at step S24, the process proceeds to step S26.
  • IPv6 CompDataBase IPv6 compression database
  • step S23 This process is similar to the adjacent node confirmation process by upper ad hoc routing (when the determination in step S22 is NO, it is determined whether the upper protocol of the received packet is an ad hoc routing message (step S27), In the case of (1), the process proceeds to step S23).
  • step S16 it is determined whether the destination IPv6 address or destination MAC address belongs to a compressible communication device. If the destination of the IPv6 packet is a compressible communication device or if the IPv6 packet relay destination is a compressible communication device (YES in step S17), compression processing of the IPv6 header information is performed ( Step S18). Then, the compressed IPv6 packet is output (transferred) to the MAC layer 211 and the subsequent layers of the wireless network, and is wirelessly transmitted (step S14). Thereby, the compressed IPv6 packet can be transmitted only to the compressible communication device.
  • step S22 If there is an IPv6 packet input from the wireless network to the communication apparatus 300, NO is determined in step S22 and NO is determined in step S27, and it is determined whether the head of the received IPv6 packet is compressed header information (step S28). If the beginning of the IPv6 packet is compressed header information (in the case of YES), the IPv6 packet is decompressed (step S29), and the IPv6 packet is transferred to the wired network side (step S26). In the case of NO at step S28, the IPv6 packet is transferred to the wired network side (step S26).
  • FIG. 6 is a diagram showing IPv6 header information.
  • FIG. 7 is a diagram showing IPv6 fragment header information.
  • FIG. 8 is a diagram showing UDP header information.
  • FIG. 9 is a diagram showing an example of compression algorithm information.
  • FIG. 10 is a diagram showing an example of compressed IPv6 header information.
  • FIG. 11 is a diagram showing an example of compressed IPv6 fragment header information.
  • FIG. 12 is a diagram showing an example of compressed UDP header information.
  • FIG. 13 is a diagram showing an example of all header information before compression.
  • FIG. 14 is a diagram showing an example of all header information after compression.
  • IPv6 fragment header and a UDP header as an extension header other than an IPv6 header as an IPv6 packet is demonstrated below.
  • payload information is stored after the extension header.
  • the IPv6 header is 320 bits (40 octets) long and is 4-bit version (IPv6 Version), 8-bit traffic class (Traffic Class), 16-bit flow label (Flow Label) , Payload length of 16 bits (Payload Length), Next header of 8 bits (Next Header), Hop limit of 8 bits (128 bits), Source address (128 bits), Destination address (128 bits) Destination Address), and each field.
  • IPv6 Version stores “0110 (binary notation)” representing IPv6.
  • QoS Quality of Service
  • the flow label stores information for securing the quality of the communication path or for preferentially selecting the path in multicast communication and the like.
  • the payload length (Payload Length) stores information specifying the total size of the extension header and the payload data.
  • the Next Header (Next Header) stores an extension header and information indicating the type of upper protocol following the IPv6 header. If there are multiple extension headers, information indicating the type of the first extension header is stored. Subsequent headers are arranged in a beaded connection.
  • the hop limit or the maximum number of routers that can pass is stored. Each time it passes one router, it is decremented by one. When it reaches 0, the packet is discarded and an ICMPv6 "hop limit exceeded in transit" is sent back to the source.
  • the source address (Source Address) stores the IPv6 address of the source node.
  • the destination address (Destination Address) stores the IPv6 address of the destination node.
  • the IPv6 fragment header is a header used by the source to transmit larger packets that enter the path MTU (Maximum Transmission Unit) to the destination.
  • the IPv6 fragment header is identified by the next header value "44" of the previous header, and has a format as shown in FIG.
  • the IPv6 fragment header is 64 bits long and is 8 bits next header (Next Header), 8 bits reserved (RSV), 13 bits Fragment Offset (Fragment Offset), 2 bits reserved (RSV), It has fields of 1 bit flag (Flag) and 32 bit identification (Identification).
  • the Next Header contains information identifying the initial header type of the fragmentable part of the original packet.
  • the reserved (RSV) fields of the two fields are each initialized to 0 on transfer and ignored on receive.
  • the Fragment Offset is an unsigned integer, an 8-octet offset of the data following this header, and stored relative to the start of the fragmentable portion of the original packet.
  • Fragment information stores fragment information, and if there is a fragment, 1 is stored, and if it is the final fragment, 0 is stored.
  • the identification number stores the identification number of the fragmented packet. When you fragment packets, they all have the same identifier. Based on this, the original packet is identified and restored.
  • the UDP header is 64 bits long, and has 16 bit source port number (Source Port), destination port number (Destination Port), segment length (Segment Length), checksum (Checksum), It has each field.
  • the source port number (Source Port) stores a number for identifying the source application. In the case of a UDP packet which does not require a reply, the source port number is set to 0.
  • the destination port number (Destination Port) stores a number for identifying a destination application.
  • the segment length stores information indicating the length of the UDP packet, and stores the number of bytes including the length of the data portion to be transmitted by UDP.
  • Checksum stores check data for checking the integrity of the UDP packet.
  • the compression process of the IPv6 header, the IPv6 fragment header and the UDP header is performed by the compression algorithm information described in FIG. If the contents of the IPv6 header, the IPv6 fragment header, and the UDP header shown in FIGS. 6 to 8 match the contents (conditions) of the compression algorithm information of FIG. 9, compression processing and data replacement processing are performed.
  • compression header fixing unit compression information header as shown in FIGS. 10 to 12 is placed before the compressed header (compression header variable unit).
  • the compressed information IPv6 header is 16 bits long and has a 4-bit version (IPv6 Version), 2-bit QoS information compression information (qos_comp), 1-bit next protocol compression information (nexthead_comp), 2 Hop information compression information (hoplimit_comp) of 1 bit, payload length (payload length) of 1 bit, transmission source address compression information (sa_mode) of 2 bits, multicast flag (m_flag) of 1 bit, destination address compression information of 3 bits (da_mode) Has a field of).
  • IPv6 Version stores information (0x7) indicating that it is a compressed information IPv6 header.
  • the QoS information compression information stores information on compression of the field of the traffic class and the field of the flow label.
  • the upper six bits of the traffic class store DSCP (Differentiated Services Code Point). The last two bits are used for a congestion control mechanism called ECN (Explicit Congestion Notification).
  • ECN Exlicit Congestion Notification
  • the ECN is composed of two bits, ECT (ECN Capable Transport) and CE (Congestion Experienced), and when the network is congested, it should be sent to the host that is in data communication before the network device actually starts to drop packets. It has the role of informing congestion. If the stored value of the traffic class and flow label fields is 0, 3 is stored in the QoS information compression information, and the traffic class and flow label fields are compressed to 0 bytes.
  • next protocol compression information stores compression information of the field of the next header. If there is no next header, 1 is stored in the next protocol compression information, and the field of the next header is omitted. If the field of the next header is not compressed, 0 is stored in the next protocol compression information, and the field of the next header is left 8 bits.
  • the hop information compression information stores compression information of the hop limit field. If the stored value of the hop limit field is 254 or 255, 3 is stored in the hop information compression information, and the hop limit field is omitted. If the stored value of the hop limit field is 63 or 64, 2 is stored in the hop information compression information, and the hop limit field is omitted. Thus, the value of the hop limit field is replaced with hop information compression information. If the stored value of the hop limit field is 1, 1 is stored in the hop information compression information, and the hop limit field is omitted. If the hop limit field is not compressed, 0 is stored in the hop information compression information, and the hop limit field is left 8 bits.
  • the payload length compression information stores compression information of the payload length field. If the stored value of the field of payload length is 255 or less, 1 is stored in the payload length compression information, and the field of payload length is compressed to 8 bits. If the payload length field is not compressed, 0 is stored in the payload length compression information, and the payload length field is left 16 bits.
  • the compression information of the field of the transmission source address is stored in the transmission source address compression information (sa_mode). If the address of the source address field is a link local address and is EIA and wirelessly transmits the MAC address (EIA + MAC ADDRESS TRANSPARENT), 3 is stored in the transmission address source compression information, and the source address Compress the field to 48 bits. If the address of the source address field is a link local address and EIA (link local: EIA), 2 is stored in the transmission address compression information, and the source address field is compressed to 96 bits.
  • the address of the source address field is a link local address and it is not EIA (link local: NOT_EIA)
  • 1 is stored in the source address compression information, and the source address field is compressed to 112 bits.
  • the field of the source address is not compressed, 0 is stored in the source address compression information, and the field of the source address is left 128 bits.
  • the multicast flag (m_flag) stores information on whether the destination address is multicast.
  • the compression information of the field of the destination address is stored in the destination address compression information (da_mode). If the address of the destination address field is unicast and 120 bits overlap with the source address (same prefix source), 7 is stored in the destination address compression information, and the destination address field is compressed to 8 bits. If the address of the field of the destination address is unicast and overlaps with the source address by 112 bits, 6 is stored in the destination address compression information, and the field of the destination address is compressed to 16 bits. If the address of the field of the destination address is unicast and overlaps with the source address by 96 bits, 5 is stored in the destination address compression information, and the field of the destination address is compressed into 32 bits.
  • the address of the field of the destination address is unicast and 80 bits overlap with the source address
  • 4 is stored in the destination address compression information, and the field of the destination address is compressed to 48 bits.
  • 3 is stored in the destination address compression information, and the field of the destination address is compressed to 64 bits.
  • the address of the destination address field is a unicast link local address and is an EIA (link local)
  • 2 is stored in the destination address compression information, and the destination address field is compressed to 96 bits. If the address in the destination address field is a unicast link local address and the same vendor as the source (link local same vendor), store 1 in the destination address compression information and set the destination address field to 24 bits Compress.
  • the compression information IPv6 fragment header is 16 bits long and is 1 bit next protocol compression information (nexthead_comp), 1 bit Identification compression information (ID_comp), 1 bit fragment flag (flag), 13 It has a field of bit fragment offset.
  • next protocol compression information stores compression information of the field of the next header. If there is no next header, 1 is stored in the next protocol compression information, and the field of the next header is omitted. If the field of the next header is not compressed, 0 is stored in the next protocol compression information, and the field of the next header is left 8 bits.
  • the compression information of the field of the identifier is stored in the identification compression information (ID_comp). If the field of the identifier is less than or equal to the 8-bit expression, 3 is stored in the Identification compression information, and the field of the identifier is compressed into 8 bits. If the field of Identification is less than or equal to the 16-bit representation, 2 is stored in the Identification compression information, and the field of the identifier is compressed to 16 bits. If the field of Identification is less than or equal to the 24-bit representation, 1 is stored in the Identification compression information, and the field of the identifier is compressed into 24 bits. When not compressing the field of the identifier, 0 is stored in the Identification compression information, and the field of the identifier is left 32 bits.
  • the fragment flag (flag) stores information as to whether or not there is a fragment.
  • the fragment offset field stores the value of the field of fragment offset.
  • the compression information UDP header is 8 bits long, and 1-bit port number compression enable / disable information (port_comp), 2-bit transmission source port number compression information (srcportcomp), 3-bit destination port number compression It has fields of information (dstportcomp), 1-bit checksum compression information (checksum_comp), and 1-bit payload length compression information (len_comp).
  • the port number compression enable / disable information stores information as to whether the port number can be compressed. When the port number is compressed, 1 is stored in the port number compression availability information, and when the port number is not compressed, 0 is stored in the port number compression availability information.
  • the transmission source port number compression information stores compression information of the field of the transmission source port number. If the port number is within the specified range, for example, 1 in the case of 50000, 3 in the case of 20000 in the case of 60000, 3 in the case of the port number 30001, store 3 and the port information is 1 byte Compress to When the field of the transmission source port number is not compressed, 0 is stored in the transmission source port number compression information, and the transmission source port number field is left as 2 bytes.
  • Destination port number compression information stores compression information of a destination port number field. When the port number is within the prescribed range, it is similar to the transmission source port number compression information. If the destination port number is the same as the source port number (dst port same), 4 is stored in the destination port number compression information, and the destination port number is omitted. If 0 ⁇ (destination port number)-(source port number) ⁇ 255 (dst port differ less than plus 255), store 5 in the destination port number compression information and compress the destination port number field to 1 byte Do.
  • checksum_comp stores compression information of the checksum field.
  • 1 is stored in the checksum compression information, and the checksum field is omitted.
  • the receiving side calculates and reproduces a checksum. If the checksum field is not compressed, 0 is stored in the checksum compression information, and the checksum field remains 2 bytes.
  • the payload length compression information stores compression information of the segment length field. If the segment length is 255 or less, 1 is stored in the payload length compression information, and the segment length field is compressed to 1 byte. If the segment length field is not compressed, 0 is stored in the payload length compression information, and the segment length field remains 2 bytes.
  • IPv6 header As shown in FIG. 13, all header information (IPv6 header, IPv6 fragment header, UDP header) before compression is 56 bytes long, and as shown in FIG. 14, all header information after compression is 22 bytes long.
  • the traffic class and flow label are 0 bytes
  • the payload length is 1 byte
  • the next header is 1 byte
  • the hop limit is 0 byte
  • the source address is 6 bytes
  • the destination address is 6 bytes. It is compressed. Segment length is compressed to 1 byte.
  • the communication apparatus that has received the IPv6 packet including the compressed IPv6 header as shown in FIG. 14 performs the decompression process based on the compression information header as shown in FIGS. 10 to 12, and the IPv6 header as shown in FIG. Get
  • IP6CD IPv6 Comp / DeComp

Abstract

複数の通信装置から構成され、１つ以上の通信装置を経由して通信を行う無線システムに用いられる通信装置は、前記複数の通信装置間での近隣探索メッセージとその応答、またはアドホックルーティングプロトコルによる経路制御情報の交換に基づいて通信制御情報の圧縮可否を判断する第一手段と、前記通信制御情報の圧縮が可能な場合、前記通信制御情報の内容を判断し、冗長な情報または常時固定な情報を削減または置換することで、前記通信制御情報の情報量を圧縮する第二手段と、を備える。

Description

通信装置
　本開示は通信装置に関し、例えばＩＰｖ６ネットワークに用いる通信装置に適用可能である。
　今日のネットワーク通信方式として、インターネット(ＷＥＢ)、電子メールではＩＰ（Internet Protocol）が用いられている。一部の広帯域回線を除けば、現在多く使用されている方式はＩＰｖ４（Internet Protocol version 4）であり、送信元／宛先を示すものとして３２ビットからなるアドレス（ＩＰアドレス）が用いられている。インターネット通信においては、このＩＰアドレスを各送信元／宛先にユニークに割り当てるグローバルＩＰアドレスを採用し、ＩＰアドレスに応じて、個々の発信元／宛先を判別している。しかし、インターネットの世界は急速に広がりを見せており、ＩＰｖ４アドレスの３２ビットで定義可能な範囲が全て使用され、新規に割り当てできない状態、すなわちグローバルアドレスの枯渇が問題となっている。
　これを解決するためにＩＥＴＦ（Internet Engineering Task Force）では、次世代のネットワーク通信方式とし、ＩＰアドレスを３２ビットから１２８ビットに拡張したＩＰｖ６（Internet Protocol version 6）の利用を提唱し、移行を推奨している。
　無線ネットワークにおいては、ＷｉＭＡＸ(Worldwide Interoperability for Microwave Access)にて、モバイルＩＰ（Mobile IP）と呼ばれる通信方式を採用している。しかし、システムが複雑であることや広帯域回線を利用する前提であることから、簡易利用はできず、無線ＬＡＮ等を初めとした一般無線回線では普及は進んでいない状況である。
　このような背景から、簡易的または広帯域な無線ネットワークにおいてもＩＰｖ６でのネットワークおよび通信は今後利用されていく状況にあるが、一方でアドレス情報の拡張により制御情報が増大し、無線回線の使用率が増大することから、利用者が本来宛先に送るべきデータ量が抑制されてしまう恐れがある。
　ＢＬＥ（Bluetooth Low Energy）を初めとしたＰＡＮ(Personal Area Network)では、上記の懸念から独自に６ＬｏＷＰＡＮと呼ばれる通信方式を決め、情報量の削減を実施しているが、利用する場合は全通信装置の対応が必要であることや、ＰＡＮの特性上通信相手が小規模であること、さらにはデータリンク層プロトコルであるＢＬＥプロトコルの情報を利用した削減処理から、同一の方式を中規模ならびに広帯域ネットワークに適用することは不可能である。
特開２０１６－２５４０１号公報
　前述の通り、ＩＰｖ６ネットワークへの移行が進められる一方で、無線ネットワークへのトラフィック増加が見込まれるが、従来方式は小規模かつＢＬＥの方式を利用した情報量削減処理であるため、中規模または大規模な無線ネットワークでは適用できない。中規模および大規模な無線ネットワークでは様々な通信装置が存在するため、低性能の通信装置では情報量削減処理ができない可能性もあるため、情報圧縮処理のできない通信装置を考慮した上での、最適なトラフィック抑制が必要になる。
  本開示の課題は、情報圧縮処理のできない通信装置を考慮した上での、最適なトラフィック抑制が可能な通信装置を提供することにある。
  その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
　本開示のうち代表的なものの概要を簡単に説明すれば下記の通りである。
  すなわち、複数の通信装置から構成され、１つ以上の通信装置を経由して通信を行う無線システムに用いられる通信装置は、前記複数の通信装置間での近隣探索メッセージとその応答、またはアドホックルーティングプロトコルによる経路制御情報の交換に基づいて通信制御情報の圧縮可否を判断する第一手段と、前記通信制御情報の圧縮が可能な場合、前記通信制御情報の内容を判断し、冗長な情報または常時固定な情報を削減または置換することで、前記通信制御情報の情報量を圧縮する第二手段と、を備える。
　上記通信装置によれば、情報圧縮処理のできない通信装置を考慮した上での、最適なトラフィック抑制が可能となる。
ネットワーク構成を説明する図である。 比較例に係る通信装置の構成を説明する図である。 実施例に係る通信装置の構成を説明する図である。 図３の通信装置の無線送信の処理を説明する図である。 図３の通信装置の無線受信の処理を説明する図である。 ＩＰｖ６ヘッダ情報を説明する図である。 ＩＰｖ６フラグメントヘッダ情報を説明する図である。 ＵＤＰヘッダ情報を説明する図である。 圧縮アルゴリズム情報の例を説明する図である。 圧縮ＩＰｖ６ヘッダ情報の例を説明する図である。 圧縮ＩＰｖ６フラグメントヘッダ情報の例を説明する図である。 圧縮ＵＤＰヘッダ情報の例を説明する図である。 圧縮前の全ヘッダ情報の例を説明する図である。 圧縮後の全ヘッダ情報の例を説明する図である。
　実施例形態の通信装置は無線通信におけるＩＰｖ６通信または中継（ルーティング）において通信トラフィックの管理、抑制に関する機能を備える。実施形態では、ＩＰｖ６のアドレス情報を初めとした制御情報（ヘッダ情報）の削減ならびに情報置換を行うことで、制御情報を圧縮しトラフィックを抑制することができる。また、ヘッダ情報が圧縮可能な通信装置を判断し、ヘッダ情報が圧縮不可能な通信装置に対しては圧縮を行わずに無線伝送することによって、ネットワークの通信不全などを未然に防ぐことができる。
　以下、実施例について、図面を用いて説明する。ただし、以下の説明において、同一構成要素には同一符号を付し繰り返しの説明を省略することがある。
　ネットワークの構成例について図１を用いて説明する。図１はネットワーク構成を示す図である。ネットワーク１００は通信装置＃１（１０１）、通信装置＃２（１０２）、通信装置＃３（１０３）、通信装置＃４（１０４）および通信装置＃５（１０５）で構成される。
　ネットワーク１００では、通信装置＃１～＃５（１０１～１０５）がアドホックネットワーク（無線ネットワーク（点線両方向矢印）を構成しており、各通信装置＃１～＃５（１０１～１０５）には、それぞれ有線自立ネットワーク（実線）で端末＃１～＃５（１１１～１１５）が接続されている。通信装置＃１（１０１）には、端末＃６（１１６）も接続されている。通信装置＃１～＃５（１０１～１０５）は有線自律ネットワーク及び無線ネットワークの双方を中継する通信装置である。
　次に、通信装置の構成例について図２、３を用いて説明する。図２は比較例に係る通信装置の構成を示す図である。図３は実施例に係る通信装置の構成を示す図である。
　図２に示すように、比較例に係る通信装置２００では、レイヤー４（Ｌ４）であるトランスポート層以上に、ＩＣＭＰｖ６（Internet Control Message Protocol for IPv6）とアドホックルーティングプロトコル（無線ネットワークルーティングプロトコル）を実現するネットワークモジュール（ＮＷＭ）２０１が配置され、レイヤー３（Ｌ３）であるネットワーク（ＮＷ）層にルーティングテーブル（ＲＴ）２０７配置される。また、レイヤー２（Ｌ２）である媒体アクセス制御（ＭＡＣ）層に有線ネットワークのＭＡＣ層（Ethernet MAC）２１０および無線ネットワークのＭＡＣ層（Wireless MAC）２１１が配置され、レイヤー１（Ｌ１）である物理（ＰＨＹ）層に有線ネットワークのＰＨＹ層（Ethernet PHY）２１２および無線ネットワークのＰＨＹ層（Wireless Network PHY）２１３が配置される。
　有線自律ネットワークからのＩＰｖ６パケット入力があった場合、通信装置２００は、自身のルーティングテーブル２０７に登録されている通信経路を確認する。確認の後、ＩＰｖ６パケットの宛先ＩＰアドレスと自身のルーティングテーブル２０７に登録されている通信経路に合致したものがあれば、登録時に設定した、出力インタフェースに対して、ＩＰｖ６パケットを出力する。ここで、ＩＰｖ６パケットは、ＩＰｖ６ヘッダとペイロード（拡張ヘッダおよびデータ）で構成される。
　また、ルーティングテーブル２０７は、無線側のインタフェースから入力されたＩＰｖ６パケットにも同様に作用する。その際、ルーティングテーブル２０７に登録されている経路の出力先が有線自律ネットワーク側インタフェースにも、また無線側のインタフェースにもなりうる。また通信装置２００は、入力データに合致した経路の情報を一時的な記憶領域（ルーティングテーブルキャッシュ（ＲＴＣ））２１７に保管する機能を有する。
　次に、図３に示すように、実施例に係る通信装置３００は比較例に係る通信装置の構成に加え、ＮＷ層にＩＰｖ６ヘッダ情報の圧縮および伸張等を行うＩＰｖ６Ｃｏｍｐ／ＤｅＣｏｍｐ（ＩＰ６ＣＤ）モジュール３０１を備える。ＩＰ６ＣＤモジュール３０１は例えばソフトウェアで構成される。よって、通信装置３００はソフトウェアを実行するＣＰＵとソフトウェアを格納するメモリとを備える。
　次に、通信装置３００のＩＰｖ６ヘッダの圧縮可否の情報通知および判断における処理について図４、５を用いて説明する。図４は図３の通信装置の無線送信時の処理を示すフローチャートである。図５は図３の通信装置の無線受信時の処理を示すフローチャートである。
　図４に示すように、まず、ＩＰ６ＣＤモジュール３０１は有線ネットワークからＩＰｖ６パケットを受信する（ステップＳ１１）。次に、ＩＰ６ＣＤモジュール３０１では、入力された情報（受信したＩＰｖ６パケットの上位プロトコル）が自装置を送信元とするＩＣＭＰｖ６による近隣ノード探索メッセージかどうかを判別し（ステップＳ１２）、近隣ノード探索メッセージの場合（ＹＥＳの場合）は、メッセージ内のペイロード情報に自通信装置が圧縮可能な旨の情報を格納して（ステップＳ１３）、ＩＰｖ６パケットを無線ネットワークのＭＡＣ層２１１以降に出力（転送）して、無線送信する（ステップＳ１４）。ステップＳ１２での判断がＮＯの場合は、受信したＩＰｖ６パケットの上位プロトコルがアドホックルーティングメッセージかどうかを判断し（ステップＳ１５）、ＹＥＳの場合はステップＳ１３に移る。これにより、近隣ノード探索メッセージ送信またはアドホックルーティングメッセージ送信において通信装置３００は自装置がＩＰｖ６ヘッダ情報を圧縮可能であること示す情報を付与して通知することができる。
　一方、無線受信の場合は、図５に示すように、無線ネットワークからＩＰｖ６パケットを受信する（ステップＳ２１）。次に、ＩＰ６ＣＤモジュール３０１では、無線ネットワークのＭＡＣ層２１１から入力されたデータ（受信したＩＰｖ６パケットの上位プロトコル）がＩＣＭＰｖ６による近隣ノード探索メッセージかどうかを判別し（ステップＳ２２）、近隣ノード探索メッセージであれば（ＹＥＳの場合）、近隣ノード探索メッセージ内に通信装置が圧縮可能な旨の情報（圧縮可能情報）が格納されているかを確認する（ステップＳ２３）。近隣ノード探索メッセージ内に圧縮可能情報が格納されているかどうかを判断し（ステップＳ２４）、格納されている場合（ＹＥＳの場合）は、対象の通信装置に送信するＩＰｖ６パケットに対してはＩＰｖ６ヘッダ情報が圧縮可能であること（圧縮可能通信装置としてそのＩＰｖ６アドレス）をＩＰｖ６圧縮データベース（IPv6CompDataBase）に登録する（ステップＳ２５）。そして、ＩＰｖ６パケットを有線ネットワーク側に転送する（ステップＳ２６）。ステップＳ２４でＮＯの場合はステップＳ２６に移る。この処理は上位のアドホックルーティングによる近接ノード確認処理についても同様である（ステップＳ２２での判断がＮＯの場合は、受信したパケットの上位プロトコルがアドホックルーティングメッセージかどうかを判断し（ステップＳ２７）、ＹＥＳの場合はステップＳ２３に移る）。
　上記実施後、通信装置３００に有線自律ネットワークからＩＰｖ６パケット入力があった場合はステップＳ１２でＮＯ、ステップＳ１５でＮＯになり、ＩＰｖ６圧縮データベースの内容を確認（ＩＰｖ６圧縮データベースで圧縮可能な通信装置を検索）し（ステップＳ１６）、宛先ＩＰｖ６アドレスまたは宛先ＭＡＣアドレスが圧縮可能な通信装置のものかどうかを判断する（ステップＳ１７）。ＩＰｖ６パケットの宛先が圧縮可能な通信装置であった場合、またはＩＰｖ６パケット中継先が圧縮可能な通信装置であった場合（ステップＳ１７でＹＥＳの場合）は、ＩＰｖ６ヘッダ情報の圧縮処理を実施する（ステップＳ１８）。そして、圧縮したＩＰｖ６パケットを無線ネットワークのＭＡＣ層２１１以降に出力（転送）して、無線送信する（ステップＳ１４）。これにより、圧縮可能な通信装置のみに対して圧縮済ＩＰｖ６パケットを送信することができる。
　通信装置３００に無線ネットワークからＩＰｖ６パケット入力があった場合はステップＳ２２でＮＯ、ステップＳ２７でＮＯになり、受信したＩＰｖ６パケットの先頭が圧縮ヘッダ情報かどうかを判断する（ステップＳ２８）。ＩＰｖ６パケットの先頭が圧縮ヘッダ情報の場合（ＹＥＳの場合）、ＩＰｖ６パケットの伸長処理を行い（ステップＳ２９）、ＩＰｖ６パケットを有線ネットワーク側に転送する（ステップＳ２６）。ステップＳ２８でＮＯの場合、ＩＰｖ６パケットを有線ネットワーク側に転送する（ステップＳ２６）。
　次に、ステップＳ１８の圧縮処理について図６～１４を用いて説明する。図６はＩＰｖ６ヘッダ情報を示す図である。図７はＩＰｖ６フラグメントヘッダ情報を示す図である。図８はＵＤＰヘッダ情報を示す図である。図９は圧縮アルゴリズム情報の例を示す図である。図１０は圧縮ＩＰｖ６ヘッダ情報の例を示す図である。図１１は圧縮ＩＰｖ６フラグメントヘッダ情報の例を示す図である。図１２は圧縮ＵＤＰヘッダ情報の例を示す図である。図１３は圧縮前の全ヘッダ情報の例を示す図である。図１４は圧縮後の全ヘッダ情報の例を示す図である。
　ＩＰｖ６パケットとして、ＩＰｖ６ヘッダの他に、拡張ヘッダとしてＩＰｖ６フラグメントヘッダおよびＵＤＰヘッダを有する例について以下説明する。なお、ＩＰｖ６パケットでは拡張ヘッダの後にペイロード情報が格納される。
　図６に示すように、ＩＰｖ６ヘッダは３２０ビット（４０オクテット）長であり、４ビットのバージョン（ＩＰｖ６ Version）、８ビットのトラフィック・クラス（Traffic Class）、１６ビットのフロー・ラベル（Flow Label）、１６ビットのペイロード長（Payload Length）、８ビットのネクスト・ヘッダ（Next Header）、８ビットのホップ・リミット（Hop Limit）、１２８ビットの送信元アドレス（Source Address）、１２８ビットの宛先アドレス（Destination Address）、の各フィールドを有する。
　バージョン（ＩＰｖ６ Version）にはＩＰｖ６を表す「０１１０（２進数表示）」が格納される。
　トラフィック・クラス（Traffic Class）にはパケット送信時のＱｏＳ（Quality of Service）を指定し、パケット送信時の優先度を表す情報が格納される。
　フロー・ラベル（Flow Label）にはマルチキャスト通信などにおいて、通信経路の品質を確保したり、経路を優先的に選択させたりするための情報が格納される。
　ペイロード長（Payload Length）には拡張ヘッダとペイロード・データの合計サイズを指定する情報が格納される。
　ネクスト・ヘッダ（Next Header）にはこのＩＰｖ６ヘッダに続く、拡張ヘッダや上位プロトコルのタイプを表す情報が格納される。拡張ヘッダが複数ある場合は、最初の拡張ヘッダのタイプを表す情報が格納される。以後のヘッダは、数珠つなぎで並べられる。
　ホップ・リミット（Hop Limit）いは通過可能なルータの最大数が格納される。ルータを１つ通過するたびに１ずつ減算される。０になるとパケットは破棄され、送信元に対してＩＣＭＰｖ６の「hop limit exceeded in transit」が返信される。
　送信元アドレス（Source Address）には送信元ノードのＩＰｖ６アドレスが格納される。宛先アドレス（Destination Address）は送信先ノードのＩＰｖ６アドレスが格納される。
　ＩＰｖ６フラグメントヘッダは、宛先へパスＭＴＵ（Maximum Transmission Unit）に入るより大きいパケットを送信するために送信元によって用いられるヘッダである。ＩＰｖ６フラグメントヘッダは直前のヘッダのネクスト・ヘッダ値“４４”によって識別され、図７に示すようなフォーマットである。
　ＩＰｖ６フラグメントヘッダは６４ビット長であり、８ビットのネクスト・ヘッダ（Next Header）、８ビットの予約済み（ＲＳＶ）、１３ビットのフラグメント・オフセット（Fragment Offset）、２ビットの予約済み（ＲＳＶ）、１ビットのフラグ（Flag）、３２ビットの識別子（Identification）、の各フィールドを有する。
　ネクスト・ヘッダ（Next Header）には元のパケットのフラグメント可能部分の初期ヘッダタイプを識別する情報が格納される。二つのフィールドの予約済み（ＲＳＶ）はそれぞれ転送時に０に初期化され、受信時に無視される。
　フラグメント・オフセット（Fragment Offset）には符号無し整数で、このヘッダに続くデータの８オクテット単位のオフセットで、元のパケットのフラグメント可能部分の開始からの相対値が格納される。
　フラグ（Flag）にはフラグメント情報が格納され、さらにフラグメント有る場合は１、最終フラグメントの場合は０が格納される。
　識別子（Identification）にはフラグメント化されたパケットの識別用番号が格納される。パケットをフラグメント化すると、すべて同じ識別子を持つ。これを元に、元のパケットが識別・復元される。
　図８に示すように、ＵＤＰヘッダは６４ビット長であり、１６ビットの送信元ポート番号（Source Port）、宛先ポート番号（Destination Port）、セグメント長（Segment Length）、チェックサム（Checksum）、の各フィールドを有する。
　送信元ポート番号（Source Port）には送信元のアプリケーションを識別するための番号が格納される。返信を要求しないＵＤＰパケットの場合は、送信元ポート番号を０にする。宛先ポート番号（Destination Port）は宛先のアプリケーションを識別するための番号が格納される。
　セグメント長（Segment Length）にはＵＤＰパケットの長さを表す情報が格納され、ＵＤＰで送信するデータ部分の長さを加えたバイト数が格納される。
　チェックサム（Checksum）にはＵＤＰパケットの整合性を検査するための検査用データが格納される。
　ＩＰｖ６ヘッダ、ＩＰｖ６フラグメントヘッダおよびＵＤＰヘッダの圧縮処理は、図９に記載する圧縮アルゴリズム情報により実施する。図６～図８に示すＩＰｖ６ヘッダ、ＩＰｖ６フラグメントヘッダおよびＵＤＰヘッダの内容が、図９の圧縮アルゴリズム情報の内容（条件）と一致するものについては、圧縮処理およびデータ置換処理を実施する。
　圧縮処理およびデータ置換を実施した場合は圧縮済ヘッダ（圧縮ヘッダ可変部）の前に図１０～図１２に示すような圧縮情報ヘッダ（圧縮ヘッダ固定部）を配置する。
　図１０に示すように、圧縮情報ＩＰｖ６ヘッダは１６ビット長であり、４ビットのバージョン（ＩＰｖ６ Version）、２ビットのＱｏＳ情報圧縮情報（qos_comp）、１ビットの次プロトコル圧縮情報（nexthead_comp）、２ビットのホップ情報圧縮情報（hoplimit_comp）、１ビットのペイロード長（payload length）、２ビットの送信元アドレス圧縮情報（sa_mode）、１ビットのマルチキャストフラグ（m_flag）、３ビットの宛先アドレス圧縮情報（da_mode）のフィールドを有する。
　バージョン（ＩＰｖ６ Version）には圧縮情報ＩＰｖ６ヘッダであることを示す情報（0x7）が格納される。
　ＱｏＳ情報圧縮情報（qos_comp）にはトラフィック・クラスのフィールドおよびフロー・ラベルのフィールドの圧縮の情報が格納される。トラフィック・クラスの上位６ビットはＤＳＣＰ（Differentiated Services Code Point）を格納している。最後の２ビットはＥＣＮ（Explicit Congestion Notification）という輻輳制御の仕組みに使われる。ＥＣＮは、ＥＣＴ（ECN Capable Transport）とＣＥ（Congestion Experienced）の２ビットから構成され、ネットワークが輻輳を起こした際、 実際にネットワーク機器がパケット破棄を始める前に、データ通信をしているホストに輻輳を知らせる役目を持つ。トラフィック・クラスおよびフロー・ラベルのフィールドの格納値が０の場合、ＱｏＳ情報圧縮情報に３を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドを０バイトに圧縮する。トラフィック・クラスにＤＳＣＰを格納する場合は、ＱｏＳ情報圧縮情報に２を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドを１バイトに圧縮する。トラフィック・クラスにＥＣＮを格納し、フロー・ラベルを格納する場合は、ＱｏＳ情報圧縮情報に１を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドを３バイトに圧縮する。トラフィック・クラスおよびフロー・ラベルのフィールドを圧縮しない場合は、ＱｏＳ情報圧縮情報に０を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドは２８ビットのままにする。
　次プロトコル圧縮情報（nexthead_comp）にはネクスト・ヘッダのフィールドの圧縮情報が格納される。ネクスト・ヘッダがない場合、次プロトコル圧縮情報に１を格納し、ネクスト・ヘッダのフィールドを省略する。ネクスト・ヘッダのフィールドを圧縮しない場合、次プロトコル圧縮情報に０を格納し、ネクスト・ヘッダのフィールドは８ビットのままにする。
　ホップ情報圧縮情報（hoplimit_comp）にはホップ・リミットのフィールドの圧縮情報が格納される。ホップ・リミットのフィールドの格納値が２５４、２５５の場合は、ホップ情報圧縮情報に３を格納し、ホップ・リミットのフィールドを省略する。ホップ・リミットのフィールドの格納値が６３、６４の場合は、ホップ情報圧縮情報に２を格納し、ホップ・リミットのフィールドを省略する。よって、ホップ・リミットのフィールドの値がホップ情報圧縮情報にデータ置換される。ホップ・リミットのフィールドの格納値が１の場合は、ホップ情報圧縮情報に１を格納し、ホップ・リミットのフィールドを省略する。ホップ・リミットのフィールドを圧縮しない場合は、ホップ情報圧縮情報に０を格納し、ホップ・リミットのフィールドは８ビットのままにする。
　ペイロード長圧縮情報（payload length）にはペイロード長のフィールドの圧縮情報が格納される。ペイロード長のフィールドの格納値が２５５以下の場合、ペイロード長圧縮情報に１を格納し、ペイロード長のフィールドを８ビットに圧縮する。ペイロード長のフィールドを圧縮しない場合は、ペイロード長圧縮情報に０を格納し、ペイロード長のフィールドは１６ビットのままにする。
　送信元アドレス圧縮情報（sa_mode）には送信元アドレスのフィールドの圧縮情報が格納される。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡであり、かつＭＡＣアドレスを無線送信する場合（EIA + MAC ADDRESS TRANSPARENT）、送信アドレス元圧縮情報に３を格納し、送信元アドレスのフィールドを４８ビットに圧縮する。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡである場合（link local : EIA）、送信アドレス圧縮情報に２を格納し、送信元アドレスのフィールドを９６ビットに圧縮する。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡでない場合（link local : NOT_EIA）、送信元アドレス圧縮情報に１を格納し、送信元アドレスのフィールドを１１２ビットに圧縮する。送信元アドレスのフィールドを圧縮しない場合は、送信元アドレス圧縮情報に０を格納し、送信元アドレスのフィールドは１２８ビットのままにする。
　マルチキャストフラグ（m_flag）には宛先アドレスがマルチキャストであるかどうかの情報が格納される。
　宛先アドレス圧縮情報（da_mode）には宛先アドレスのフィールドの圧縮情報が格納される。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと１２０ビット重複している場合（same prefix source）、宛先アドレス圧縮情報に７を格納し、宛先アドレスのフィールドを８ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと１１２ビット重複している場合、宛先アドレス圧縮情報に６を格納し、宛先アドレスのフィールドを１６ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと９６ビット重複している場合、宛先アドレス圧縮情報に５を格納し、宛先アドレスのフィールドを３２ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと８０ビット重複している場合、宛先アドレス圧縮情報に４を格納し、宛先アドレスのフィールドを４８ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと６４ビット重複している場合、宛先アドレス圧縮情報に３を格納し、宛先アドレスのフィールドを６４ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストのリンクローカルアドレスであり、かつＥＩＡである場合（link local）、宛先アドレス圧縮情報に２を格納し、宛先アドレスのフィールドを９６ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストのリンクローカルアドレスであり、かつ送信元と同一ベンダである場合（link local same vender）、宛先アドレス圧縮情報に１を格納し、宛先アドレスのフィールドを２４ビットに圧縮する。
　図１１に示すように、圧縮情報ＩＰｖ６フラグメントヘッダは１６ビット長であり、１ビットの次プロトコル圧縮情報（nexthead_comp）、１ビットのIdentification圧縮情報（ID_comp）、１ビットのフラグメントフラグ（flag）、１３ビットのフラグメント・オフセット（fragment offset）のフィールドを有する。
　次プロトコル圧縮情報（nexthead_comp）にはネクスト・ヘッダのフィールドの圧縮情報が格納される。ネクスト・ヘッダがない場合、次プロトコル圧縮情報に１を格納し、ネクスト・ヘッダのフィールドを省略する。ネクスト・ヘッダのフィールドを圧縮しない場合、次プロトコル圧縮情報に０を格納し、ネクスト・ヘッダのフィールドは８ビットのままにする。
　Identification圧縮情報（ID_comp）には識別子のフィールドの圧縮情報が格納される。識別子のフィールドが８ビット表現以下である場合、Identification圧縮情報に３を格納し、識別子のフィールドを８ビットに圧縮する。Identificationのフィールドが１６ビット表現以下である場合、Identification圧縮情報に２を格納し、識別子のフィールドを１６ビットに圧縮する。Identificationのフィールドが２４ビット表現以下である場合、Identification圧縮情報に１を格納し、識別子のフィールドを２４ビットに圧縮する。識別子のフィールドを圧縮しない場合、Identification圧縮情報に０を格納し、識別子のフィールドは３２ビットのままにする。
　フラグメントフラグ（flag）にはフラグメントがあるかどうかの情報が格納される。フラグメント・オフセット（fragment offset）にはフラグメント・オフセットのフィールドの値が格納される。
　図１２に示すように、圧縮情報ＵＤＰヘッダは８ビット長であり、１ビットのポート番号圧縮可否情報（port_comp）、２ビットの送信元ポート番号圧縮情報（srcportcomp）、３ビットの宛先ポート番号圧縮情報（dstportcomp）、１ビットのチェックサム圧縮情報（checksum_comp）、１ビットのペイロード長圧縮情報（len_comp）のフィールドを有する。
　ポート番号圧縮可否情報（port_comp）にはポート番号の圧縮が可能かどうかの情報が格納される。ポート番号を圧縮する場合、ポート番号圧縮可否情報に１を格納し、ポート番号を圧縮しない場合、ポート番号圧縮可否情報に０を格納する。
　送信元ポート番号圧縮情報（srcportcomp）には送信元ポート番号のフィールドの圧縮情報が格納される。ポート番号が規定の範囲の場合、例えば５００００の場合は１、６００００の場合は２、３００００の場合は３を格納し、ポート番号が３０００１であれば、３を格納値し、ポート情報を１バイトに圧縮する。送信元ポート番号のフィールドを圧縮しない場合、送信元ポート番号圧縮情報に０を格納し、送信元ポート番号のフィールドを２バイトのままとする。
　宛先ポート番号圧縮情報（srcportcomp）には宛先ポート番号のフィールドの圧縮情報が格納される。ポート番号が規定の範囲の場合、送信元ポート番号圧縮情報と同様である。宛先ポート番号が送信元ポート番号と同じである場合（dst port same）、宛先ポート番号圧縮情報に４を格納し、宛先ポート番号を省略する。０＜（宛先ポート番号）－（送信元ポート番号）＜２５５である場合(dst port differ less than plus 255)、宛先ポート番号圧縮情報に５を格納し、宛先ポート番号のフィールドを１バイトに圧縮する。０＞（宛先ポート番号）－（送信元ポート番号）＞－２５５である場合(dst port differ less than mius 255)、宛先ポート番号圧縮情報に６を格納し、宛先ポート番号のフィールドを１バイトに圧縮する。宛先ポート番号のフィールドを圧縮しない場合、宛先ポート番号圧縮情報に０を格納し、宛先ポート番号のフィールドを２バイトのままとする。
　チェックサム圧縮情報（checksum_comp）にはチェックサムのフィールドの圧縮情報が格納される。チェックサムのフィールドを圧縮する場合、チェックサム圧縮情報に１を格納し、チェックサムのフィールドを省略する。この場合、受信側でチェックサムを計算し再生する。チェックサムのフィールドを圧縮しない場合、チェックサム圧縮情報に０を格納し、チェックサムのフィールドは２バイトのままとする。
　ペイロード長圧縮情報（len_comp）にはセグメント長のフィールドの圧縮情報が格納される。セグメント長が２５５以下の場合、ペイロード長圧縮情報に１を格納し、セグメント長のフィールドを１バイトに圧縮する。セグメント長のフィールドを圧縮しない場合、ペイロード長圧縮情報に０を格納し、セグメント長のフィールドは２バイトのままとする。
　図１３に示すように、圧縮前の全ヘッダ情報（ＩＰｖ６ヘッダ、ＩＰｖ６フラグメントヘッダ、ＵＤＰヘッダ）は５６バイト長であり、図１４に示すように圧縮後の全ヘッダ情報は２２バイト長である。なお、図１４では、トラフィック・クラスおよびフロー・ラベルが０バイト、ペイロード長が１バイト、ネクスト・ヘッダが１バイト、ホップ・リミットが０バイト、送信元アドレスが６バイト、宛先アドレスが６バイトに圧縮されている。セグメント長が１バイトに圧縮されている。
　図１４に示すような圧縮されたＩＰｖ６ヘッダを含むＩＰｖ６パケットを受信した通信装置は、図１０～１２に示すような圧縮情報ヘッダに基づいて伸長処理を実施し、図１３に示すようなＩＰｖ６ヘッダを得る。
　以上、本発明者によってなされた発明を実施形態および実施例に基づき具体的に説明したが、本発明は、上記実施形態および実施例に限定されるものではなく、種々変更可能であることはいうまでもない。
１００・・・ネットワーク
１０１・・・通信装置
１１１・・・端末
２００・・・通信装置
２０１・・・ネットワークモジュール
２０７・・・ルーティングテーブル
２０８・・・有線自律ネットワークのインタフェース
２０９・・・無線自律ネットワークのインタフェース
２１０・・・有線ネットワークのＭＡＣ層（Ethernet MAC）
２１１・・・無線ネットワークのＭＡＣ層（Wireless Network MAC）
２１２・・・有線ネットワークのＰＨＹ層（Ethernet PHY）
２１３・・・無線ネットワークのＰＨＹ層（Wireless Network PHY）
２１７・・・ルーティングテーブルキャッシュ（ＲＴＣ）
３０１・・・ＩＰｖ６Ｃｏｍｐ／ＤｅＣｏｍｐ（ＩＰ６ＣＤ）モジュール

Claims (5)

  1. 　複数の通信装置から構成され、１つ以上の通信装置を経由して通信を行う無線システムに用いられる通信装置であって、
    　前記複数の通信装置間での近隣探索メッセージとその応答、またはアドホックルーティングプロトコルによる経路制御情報の交換に基づいて通信制御情報の圧縮可否を判断する第一手段と、
    　前記通信制御情報の圧縮が可能な場合、前記通信制御情報の内容を判断し、冗長な情報または常時固定な情報を削減または置換することで、前記通信制御情報の情報量を圧縮する第二手段と、
    を備える通信装置。
  2. 　請求項１において、
    　前記第一手段は、
    　　受信したＩＰｖ６パケットの上位プロトコルが、自通信装置を送信元とするＩＣＭＰｖ６による近隣ノード探索のメッセージまたはアドホックルーティングのメッセージである場合、前記メッセージ内のペイロード情報に自通信装置が圧縮可能な旨の圧縮可能情報を格納する手段と、
    　　前記メッセージ内に他通信装置の圧縮可能情報が格納されている場合、前記他通信装置を圧縮可能通信装置としてそのアドレスをデータベースに登録する手段と、
    　　前記データベースを検索し宛先ＩＰｖ６アドレスまたは宛先ＭＡＣアドレスが圧縮可能通信装置である場合、前記通信制御情報を圧縮可能と判断する手段と、
    を備える通信装置。
  3. 　請求項２において、
    　前記第二手段は、所定の圧縮アルゴリズムに基づいて前記通信制御情報の所定のフィールドの情報を削減または置換して圧縮し、圧縮した前記所定のフィールドの情報の前に圧縮の状態を示す圧縮情報ヘッダを付加して圧縮された通信制御情報を得る通信装置。
  4. 　請求項３において、
    　さらに、受信したＩＰｖ６パケットの先頭が前記圧縮情報ヘッダである場合、前記圧縮された通信制御情報を伸長する第三手段を備える通信装置。
  5. 　請求項３において、
    　前記第三手段は、前記圧縮情報ヘッダに基づいて前記圧縮された通信制御情報を前記通信制御情報に復元する通信装置。
PCT/JP2017/033704 2017-09-19 2017-09-19 通信装置 WO2019058418A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019542835A JP7008714B2 (ja) 2017-09-19 2017-09-19 通信装置
US16/644,301 US11172051B2 (en) 2017-09-19 2017-09-19 Communication device
PCT/JP2017/033704 WO2019058418A1 (ja) 2017-09-19 2017-09-19 通信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/033704 WO2019058418A1 (ja) 2017-09-19 2017-09-19 通信装置

Publications (1)

Publication Number Publication Date
WO2019058418A1 true WO2019058418A1 (ja) 2019-03-28

Family

ID=65811423

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/033704 WO2019058418A1 (ja) 2017-09-19 2017-09-19 通信装置

Country Status (3)

Country Link
US (1) US11172051B2 (ja)
JP (1) JP7008714B2 (ja)
WO (1) WO2019058418A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010130175A (ja) * 2008-11-26 2010-06-10 Fujitsu Ltd 送信装置、受信装置、送信方法及び受信方法
JP2013502187A (ja) * 2009-08-14 2013-01-17 クゥアルコム・インコーポレイテッド リレーノードのためのロバスト・ヘッダ圧縮

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1636374A (zh) * 2001-11-06 2005-07-06 皇家飞利浦电子股份有限公司 带有标题压缩的无线通信设备
JP2012169729A (ja) * 2011-02-10 2012-09-06 Hitachi Kokusai Electric Inc 無線システム
JP5882688B2 (ja) * 2011-11-18 2016-03-09 株式会社日立国際電気 通信装置
JP2015109544A (ja) * 2013-12-04 2015-06-11 株式会社日立製作所 無線通信システム
JP6451116B2 (ja) 2014-07-16 2019-01-16 富士電機株式会社 無線通信システム、無線通信方法、ソースルーチング方式の無線機識別符号短縮方法
US9716653B2 (en) * 2014-11-18 2017-07-25 Hauwei Technologies Co., Ltd. System and method for flow-based addressing in a mobile environment
JP6505868B2 (ja) * 2015-12-08 2019-04-24 株式会社日立国際電気 通信装置及び通信方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010130175A (ja) * 2008-11-26 2010-06-10 Fujitsu Ltd 送信装置、受信装置、送信方法及び受信方法
JP2013502187A (ja) * 2009-08-14 2013-01-17 クゥアルコム・インコーポレイテッド リレーノードのためのロバスト・ヘッダ圧縮

Also Published As

Publication number Publication date
US11172051B2 (en) 2021-11-09
US20210051216A1 (en) 2021-02-18
JP7008714B2 (ja) 2022-01-25
JPWO2019058418A1 (ja) 2020-10-08

Similar Documents

Publication Publication Date Title
WO2022078509A1 (zh) IPv6报文的扩展头封装方法及装置
US8213403B2 (en) Mobility header compression method and system for internet protocol-based low power wireless network
US7058728B1 (en) Method and apparatus for initiating compression of headers of packets and refreshing the context related to the packets
KR100453055B1 (ko) Ｉｐ 네트워크 상에서의 경로 ｍｔｕ 탐색 방법 및 그 장치
US20070030848A1 (en) Network communication system
US20030185208A1 (en) Method and apparatus for changing path maximum transmission unit on dynamic IP network
US20160234101A1 (en) Optimized path maximum transmission unit discovery
WO2021000827A1 (zh) 数据传输链路建立方法、装置以及计算机可读存储介质
WO2012156852A1 (en) Label switched routing to connect low power network domains
US8767704B2 (en) Compressing header data
KR100533669B1 (ko) 모바일 애드 혹 네트워크에서 데이터 패킷 전송 효율의개선을 위한 네트워크 장치 및 패킷 송수신 방법
EP1491005A1 (en) Method for changing pmtu on dynamic ip network and apparatus using the method
Papadopoulos et al. RFC 4944: per-hop fragmentation and reassembly issues
JP2005252855A (ja) ヘッダ圧縮パケット処理装置及びヘッダ圧縮パケット処理方法
JP7008714B2 (ja) 通信装置
US20220182320A1 (en) Secure data connections in low data rate networks
WO2024074031A1 (zh) 业务处理方法、通信设备、存储介质及程序产品
JP2013110689A (ja) ネットワークシステム、中継装置、通信方法、中継方法及び中継プログラム
CN102377829A (zh) 基于hip的通信方法、系统及设备
CN116232996A (zh) 基于标签交换的边缘网络数据包头压缩传输方法及系统
AU2021390925A1 (en) Secure data connections in low data rate networks
JP2007074198A (ja) ネットワーク通信システム
Herrero et al. Network and Transport Layers
CN115022924A (zh) 一种无线自组网的数据包头压缩及数据传输方法及系统
Kaddoura et al. SEEHOC: scalable and robust end-to-end header compression techniques for wireless ad hoc networks

Legal Events

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

Ref document number: 17926054

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019542835

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17926054

Country of ref document: EP

Kind code of ref document: A1