FI125092B - Menetelmä, laite ja järjestelmä datapakettien lähettämiseksi ja vastaanottamiseksi - Google Patents
Menetelmä, laite ja järjestelmä datapakettien lähettämiseksi ja vastaanottamiseksi Download PDFInfo
- Publication number
- FI125092B FI125092B FI20125807A FI20125807A FI125092B FI 125092 B FI125092 B FI 125092B FI 20125807 A FI20125807 A FI 20125807A FI 20125807 A FI20125807 A FI 20125807A FI 125092 B FI125092 B FI 125092B
- Authority
- FI
- Finland
- Prior art keywords
- node
- packet
- indicator
- data packet
- communication network
- Prior art date
Links
Classifications
-
- 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/74—Address processing for 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/16—Multipoint 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/20—Hop count for routing purposes, e.g. TTL
-
- 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/32—Flooding
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
Method, apparatus and system for transmitting and receiving data packets
Field
The invention relates to a method, an apparatus and a system for routing data packets. In particular, the invention relates to routing data packets in a network comprising low memory resource nodes.
Background
The following description of background art may include insights, discoveries, understandings or disclosures, or associations together with disclosures not known to the relevant art prior to the present invention but provided by the invention. Some of such contributions of the invention may be specifically pointed out below, whereas other such contributions of the invention will be apparent from their context.
In modern communication and computer networks, data exchange between programs and computers is a vital element. Different programs, computers and processors exchange data without human intervention. This kind of communication is usually called machine-to-machine (M2M) communications.
An example of a network technology where M2M communication is widely applied is a low-power wireless network, such as an IEEE 802.15.4 based embedded and sensor network. More recently, as machine-to-machine devices have become IP enabled, systems have become more open by using IP as a networking protocol.
In typical M2M networks the devices or nodes connected to the networks, communicate with each other. Networks may have a connection to Internet or other external network, and in such a case the nodes may communicate with devices outside the M2M network.
For the nodes to be able to communicate, a routing protocol is required. Routing protocols and techniques can divided very roughly into two groups: those utilizing a storing mode and those utilizing source or flow routing techniques. A storing mode requires that each device participating in routing maintains a routing table of downward routes. This requires the devices to have relatively large memory capabilities. In source routing, routing information is attached each transmitted packet. This reduces the payload of the packets.
Brief description
An object of the invention is to provide a solution for routing data packets.
According to an aspect of the present invention, there is provided an apparatus of claim 1.
According to an aspect of the present invention, there is provided an apparatus of claim 11.
According to an aspect of the present invention, there is provided a web service system of claim 16.
According to another aspect of the present invention, there is provided methods of claim 16 and 24.
According to another aspect of the present invention, there is provided computer program products encoding a computer program of instructions as claimed in claims 27 and 28.
List of drawings
Embodiments of the present invention are described below, by way of example only, with reference to the accompanying drawings, in which
Figure 1 illustrates a simple example of the tree-like structure of a M2M network;
Figures 2A and 2B are flow charts illustrating an example of a registration procedure of a node;
Figures 3A and 3B are flow charts illustrating transmitting and receiving a data packet;
Figures 4A and 4B are flow charts illustrating transmitting and receiving a data packet;
Figure 5 illustrates a simplified example of the transmission of a data packet in the tree-like structure of a M2M network; and Figures 6 and 7 illustrate examples of apparatuses.
Description of embodiments
The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.
Data exchange between programs and computers is a vital element. Different programs, computers and processors may exchange data without human intervention. Different networks and protocols are used in different environments. On the Internet, the Transmission Control Protocol/lnternet Protocol (TCP/IP) is the basic protocol used in communication. TCP/IP takes care of assembling and disassembling the data to be transmitted in packets. IP handles the addressing so that packets are delivered to the correct destination. Above TCP/IP, the Hypertext Transfer Protocol (HTTP) is used as a client/server protocol. A program may send an HTTP request to a server which responds with another HTTP message.
Low-power wireless networks, such as IEEE 802.15.4 based embedded and sensor networks, have extremely limited resources for transmitting packets. These networks are very energy-efficient, and the chip technology is cheap. For this reason the technology is making its way to embedded devices very quickly for automation, measurement, tracking and control, for example.
State-of-the-art routing algorithms meant for normal backbone wired networks or ad-hoc wireless mesh protocols meant for high-performance Wireless Local Area Networks (WLAN, WiFi), are not suitable for extremely constrained networks such as IEEE 802.15.4 where node resources are very limited, or networks must scale to large numbers of nodes.
In many cases, low-power wireless networks and other M2M networks resemble a tree-like structure where an access point is connected to a given number of network nodes. The access point takes care of the connections of the network to external networks such as Internet.
Figure 1 illustrates a simple example of the tree-like structure of a M2M network. The network comprises an access point 100 and a set of nodes 102 connected to the access point either directly or via other nodes. The connections within the networks (between the nodes and between the access point and the nodes) are in many networks realized typically with wireless connections but they may be wired connections as well. The transmission direction from a node towards the access point is usually referred as up direction and the opposite transmission direction as down direction.
Those nodes 104, 106, 108, 110 and 112 having more than one connection in the down directions may be referred as knots. In general, any node which receives data packets from another node and transmits the packets onwards may be called a router.
For the nodes to be able to communicate with each other, the access point and the external networks, some kind of routing protocol is required.
Basically, there are two types of routing protocols in use. The protocols of the first type require that each device participating in routing maintains a routing table of downward routes. The drawback of this is the amount of data memory that is required from the device to maintain the routing table information. A typical entry (with for example IPv6 addressing) in the table requires approximately 20 bytes of memory. One fairly common workaround for this problem is to store the routing table information in persistent memory such as flash (either on-chip or external). Flowever, the problem with on-chip flash is that the access time to that storage is typically significantly slower than standard RAM which leads into reduced performance. Additionally common semiconductor technologies used to manufacture the on-chip flash limit the number of write operations to a single flash segment so that the lifetime of the part would be prohibitively reduced if this typically very volatile routing information would be stored on it. Typically protocols of this type are efficient in small to medium size networks.
The protocols of the second type, which may denotes a source routing, require that routing information is attached each transmitted packet.
This reduces the payload of the packets. Where these protocols can be efficient in medium sized networks their shortcoming is in very deep networks. A very deep network could be characterized as one where the number of hops from the access point to the furthermost device (leaf of the network) is significantly larger than 10. With standard source routing each additional hop on a downward (from access point towards the edge of the network) will increase the routing overhead by at least 16 bytes (thus decreasing the available application payload). If the connections are realized with wireless connections, some wireless technologies have a hard limit to the maximum transmission unit (MTU). The increasing header size will lead into situation where even a small application payload packet would have to be fragmented on higher layers (such as on the IP layer). This will significantly reduce the overall performance (throughput) and scalability of the network. Additionally the fragmentation does not mitigate in any way the increased RAM consumption in routing devices caused by the larger header size (a routing device must be capable of storing and reassembling of all the fragments of a single packet). In fact the fragmentation makes the problem worse by adding more overhead information to the headers.
In an embodiment, the wireless links in the network may be realized by using IEEE 802.15.4, with Internet Protocol v6 IPv6 (6LowPAN), IEEE 802.15.4 with ZigBee, Bluetooth or Bluetooth Ultra Low Power (ULP), Low Power Wireless Local Area Network, proprietary low-power radio, cellular radio system or any other system suitable for low-power transmission. IEEE stands for the Institute of Electrical and Electronics Engineers.
In an embodiment of the invention, devices or apparatuses of the network communicate by transmitting and receiving data packets, the data packets comprising a recipient identification, a transmission direction indicator, and depending on the transmission direction indicator a hop count indicator.
Embodiment of the invention can be applied to virtually any networks and may be integrated into existing routing protocols as an enhancement or alternative mode of operation. The proposed solution is agnostic to the actual method how the network topology information is determined and delivered.
To be able to communicate with the network a node registers itself to the network. When a node is set up, it is configured to request from underlying routing protocol components the best possible parent. In this context, a parent means the next device towards the network access point in the network topology. As the proposed method does not take any part in determining the best path towards the access point it can be considered fully agnostic to the specifics of the underlying physical link technology. After receiving from the underlying routing protocol components the next hop towards the access point the node is capable of communicating with the access point. The full bi-directional communication capability is achieved when the node sends a registration message to the network access point.
Figure 2A is a flow chart illustrating a simplified example of the registration procedure. The procedure starts at step 200.
In step 202, the node determines the nearest or best node towards the access point of the network. Typically this information may be obtained from the underlying routing protocol components such as from the IPv6 Neighbor Discovery protocol in IPv6 networks. For example, referring to Figure 1, the parent of node 106 is node 104.
Regarding terminology, the transmission direction which is towards the access point of the network may be denoted as direction "up". The transmission direction which is away from the access point of the network may be denoted as direction "down".
Another point regarding terminology, a node of the network which is nearest in the direction away from the access point (direction "down") may be denoted a child. A node may have one or more child nodes. For example, referring to Figure 1, the node 104 has two child nodes, 106 and 114. Node 114 in turn has one child node 108. The nodes having more than one child nodes may be called knots.
In step 204, the node transmits a registration message to the access point. In an embodiment, the message comprises the identification of the apparatus, a lifetime indicator of the information in the message, an identification of the node which is next in the up transmission direction (i.e. the parent) and a transmission direction indicator equaling a value corresponding to direction up. The identification may in theory be of any type and size. As an example, IPv6 addresses have been successfully used as node identifiers. The lifetime indicator indicates the access point how long the transmitted information is valid. The transmission direction indicator is used in the routing procedure as will be explained below.
The process ends in step 206.
Figure 2B is a flow chart illustrating a simplified example of the registration procedure from point of view of the access point. The procedure starts at step 210.
In step 212, the access point receives a registration message from a node.
In step 214, the access point is configured to determine the identification of the sender of the registration message.
In step 216, the access point is configured to determine the direction of the sender of the registration message in the network. The structure of the network may be such that there is more than one branch of the network leaving from the access point. Referring to Figure 1, there are two branches leaving form the access point 100. The direction corresponds to the identification of the first node in the branch. The access point may determine the identification from the registration message as the message includes the identification of the last node that forwarded the message to the access point.
In step 218, the access point is configured to determine the lifetime indicator from the registration message.
In step 220, the access point determines the hop count to the sender. The hop count is the number of hops starting from the access point that must be performed in the network from a node to node to reach the sender of the registration message. For example, referring to Figure 1 the hop count to reach node 112 from the access point is 5.
The process ends in step 222.
In an embodiment, the access point stores a list of nodes, a routing table, where each entry represents a destination node that has reported its parent. The hop count may be determined using the following procedure: 1. A node is browsed from this list. 2. A parent of the node is retrieved from the list. 3. Step 2 is repeated also for parent's parent until the last parent is the access point itself.
With this mechanism, it is possible to calculate the hop of any given node, even though the node itself doesn't know its exact hop count when registering. It should be noted that the above procedure is merely an example of a method to determine hop length.
In the network of Figure 1, there are basically following kinds of communication: nodes transmitting to other nodes, nodes transmitting to access point or an external network, and access point transmitting to nodes or access point transmitting to an external network.
When nodes are transmitting to other nodes, all traffic is directed first to the access point as the nodes are not aware of the network structure or the location of the other nodes.
Figure 3A is a flow chart illustrating a simplified example of a node transmitting a data packet either to another node or to the access point. The procedure starts at step 300.
In step 302, the node determines the recipient identification. As an example, IPv6 address may be used as identifiers.
In step 304, the node sets a transmission direction indicator equaling a value corresponding to direction up.
In step 306, the node transmits the data packet including the recipient id and the transmission direction indicator.
The process ends in step 308.
Figure 3B is a flow chart illustrating a simplified example of a node receiving a data packet either from another node or from an access point. The procedure starts at step 320.
In step 322, the node receives a data packet. As connections between the nodes are typically realized with wireless connection the node is not directly aware from which node or from which direction the data packet arrived.
In step 324, the node is configured to determine the transmission direction indicator of the data packet. The indicator may typically have two possible values, a value corresponding to direction up and another value corresponding to direction down.
In step 326, the node determines whether it is the recipient of the data packet. If it is, it processes the data if required and the process ends in step 344.
In step 328, the node determines, if the transmission direction indicator value corresponds to direction down, whether the hop count indicator equals zero. If this is the case the data packet is discarded in step 330 and the process ends in step 344.
In step 332, the node checks whether the transmission direction indicator equals the value corresponding to direction up. If so; it transmits the data packet forward in step 334 and the process ends in step 344. The recipient id and transmission direction indicator values remain the same in the transmission compared to the received data packet.
Otherwise, the node reduces the value of the hop count indicator by one in step 336.
In step 338, where the transmission direction indicator equals a value corresponding to direction down, it is determined whether the number of child nodes of the node is greater than one. If this is not the case, the data packet is transmitted in step 340 and the process ends in step 344. Compared to the received data packet, the recipient id and transmission direction indicator values remain the same but the hop count has reduced by one.
If the number of child nodes was greater than one, the node broadcasts the data packet in step 342. Compared to the received data packet, the recipient id and transmission direction indicator values remain the same but the hop count has reduced by one.
The process ends in step 344.
The difference between broadcast and regular transmission is that a broadcasted packet comprises information that the packet is to be received by everyone who receives the transmission.
In an embodiment, a node stores only limited information regarding surrounding nodes of the network. For example, a node may store the id of its parent and up to two child nodes. If it has more than two child nodes, it has no information regarding their ids. If a node has only one child and a data packet is transmitted with a direction indicator value corresponding to direction down the node may indicate in a Mac layer field of the data packet that the recipient of the transmission is the child.
Thus in an embodiment, in a situation where a routing node has multiple child nodes, i.e. the node forms a knot in the network topology, an alternative mechanism to route packets is proposed. The up packets are forwarded as before but a different procedure is proposed for down packets. The headers of data packets do not contain any information as to which one of the child nodes they should be forwarded to. This is why the proposed method resorts into delivering the packet to all of the routing node's neighbors. As the delivery can be implemented using a low level broadcast message the packet might be received also by the parent device of the routing node. It is however simple for the parent device to drop the packet immediately based on the direction bit information and the source address of the packet. If the direction is down and the source is not the parent of a node the node has to drop the packet. The child nodes of the routing node however do not have any means to filter this packet. Thus the packet is forwarded to all the child nodes of these child nodes.
Figure 4A is a flow chart illustrating a simplified example of an access point receiving a data packet from a node. The procedure starts at step 400.
In step 402, the access point receives a data packet.
In step 404, the access point determines the recipient identification. If it determines that it is the recipient of the data packet, it processes the data if required and the process ends in step 412.
Otherwise, in step 406, the access point is configured to determine if the data packet is addressed to external network. If so, it transmits 408 the packet to the network and the process ends in step 412.
If the data packet is addressed to a node in the network under the access point the access point is configured to transmit the data packet to the recipient in step 410 and the process ends in step 412.
Figure 4B is a flow chart illustrating a simplified example of an access point transmitting a data packet to a node. The procedure starts at step 420. The process is similar when the access point forwards a data packet it has received as described with Figure 4A or when the data packet is generated by the access point.
In step 422, the access point determines the recipient identification.
In step 424, the access point determines the direction of the recipient in the network. The structure of the network may be such that there are more than one branches of the network leaving from the access point. Referring to Figure 1, there are two branches leaving from the access point 100. The direction corresponds to the identification of the first node in the branch where the node is located. In an embodiment, this information is stored in the routing table kept by the access point.
In step 426, the access point determines the hop count to the recipient. The hop count is the number of hops starting from the access point that must be performed in the network from a node to node to reach the recipient of the data packet. In an embodiment, this information is stored in the routing table kept by the access point.
In step 428, the access point sets a transmission direction indicator equaling a value corresponding to direction down
In step 430, the access point transmits the data packet including the recipient id, hop count and the transmission direction indicator to the direction of the recipient in the network.
The process ends in step 432.
Figure 5 illustrates a simplified example of the transmission of a data packet in the tree-like structure of a M2M network. The network comprises an access point 100 and a set of nodes 102. In this example, the access point 100 transmits a data packet to the node 500. Prior transmission the access point determines the hop count and the direction of node 500 in the network. In this case the hop count is 6 and the transmission should be directed to node 104 which is the first node in the branch where node 500 is located.
The access point transmits the data packet 502. The node 104 receives the packet, determines that it is not the recipient and forwards the data packet. As the number of child nodes of the node 104 is larger than one, the node 104 broadcasts the data packet so that all its neighbors receive the data packet, including the access point. The access point rejects the data packet as the packet has the transmission direction indicator equal to down. The data packet is received by nodes 106 and 114.
In Figure 5, the correct path of the packet is designated with solid arrows and redundant path with dotted arrows. Each node that receives the data packet determines whether it is addressed to the node and if not forwards the packet either by transmitting or by broadcasting the packet. Thus, the data packet is transmitted on multiple routes of which only one is correct. However, in before each transmission or broadcast, the hop count is reduced by one. Thus, the redundant paths expire after 6 hops or if the packet reaches the end of a particular branch. On the correct path, when node 500 receives the data packet is determines that it is the correct recipient of the packet.
The proposed method reduces significantly the resource requirements for a typical network device that provides routing service for other devices in the network, i.e. a router node. More specifically, the required routing table size in a fully functional router is reduced to a static number of bytes and the routing header packet overhead is reduced to static number of bytes. The routing table size is not dependent on the size or topology of the network at all. Also the routing header size in a mesh routable packet is not dependent on the number of intermediate hops. Additionally the size of the routing header is almost static. Third major improvement from traditional routing methods is the reduction in the amount of routing and topology information that has to be stored in a network access point.
Figure 6 illustrates an example of a routing node 104. The node comprises a protocol stack 604, a routing protocol component 606 and possible application logic 602 that is application specific (e.g. a home or building automation device function). The protocol stack 604 consists of the needed protocol layers for the network. Examples of possible protocol layers include User Datagram Protocol UDP, TCP, IPv6 6L0WPAN. The IEEE 802.15.4 Media Access Control +Physical Layer MAC+PHY is an example of a network stack.
Figure 7 illustrates an example of an access point node 100. In an embodiment, an access point consists of two network interfaces and corresponding network stacks 706, 708, a common layer between the stacks for forwarding 704 and a routing protocol component 702. First protocol stack 706 is used to communicate with the constrained network, for example using IPv6 6L0WPAN and an IEEE 802.15.4 MAC+PFIY. The other protocol stack 708 is used to communicate with an external network, for example the Internet using IPv6 and Ethernet.
Physically, a routing node and an access node may be realized with one or more processors, a memory operationally connected to the processor, a power source, and one or more transceivers or communication units. The memory may store software executable by the one or more processors.
In an embodiment, the aspects of the invention may be realized as software in a node, an access point, a computer or a set of computers connected to Internet.
The software or computer programs may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. Such carriers include a record medium, computer memory, read-only memory, and software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital controller or it may be distributed amongst a number of controllers.
The software may comprise program steps which, when executed by one or more processors, realize the two network interfaces and corresponding network stacks, the common layer between the stacks for forwarding and the routing protocol component of the access node and the protocol stack, the routing protocol component and the possible application logic of the routing node.
It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.
Claims (28)
1. Laite, joka on joukon laitteita käsittävässä ensimmäisessä viestintäverkossa ja käsittää: ainakin yhden prosessorin; ja ainakin yhden muistin, joka sisältää tietokoneohjelmakoodin, jolloin mainittu ainakin yksi muisti ja tietokoneohjelmakoodi on konfiguroitu mainitulla ainakin yhdellä prosessorilla saamaan laitteen ainakin: ohjaamaan viestintää laitteeseen toiminnallisesti kytkettyjen laitteiden kanssa lähettämällä ja vastaanottamalla tietopaketteja, jotka käsittävät vastaanottajan tunnisteen, lähetyssuunnan osoittimen ja lähetyssuunnan osoittimesta riippuen hyppymäärän osoittimen, ja laite on konfiguroitu vastaanottamaan (322) tietopaketin; tunnettu siitä, että laite on konfiguroitu määrittämään (324) tietopaketin lähetyssuunnan osoittimen; määrittämään (326), onko laite tietopaketin vastaanottaja, ja mikäli näin on, käsittelemään paketin; muutoin, mikäli lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo, määrittämään (328), onko hyppymäärän osoitin yhtä suuri kuin nolla, ja mikäli se on, hylkäämään (330) tietopaketin; muutoin, mikäli lähetyssuunnan osoitin on yhtä suuri kuin ylöspäinsuuntaa vastaava arvo, lähettämään (334) tietopaketin; muutoin vähentämään (336) hyppymäärän osoittimen lukua yhdellä ja mikäli lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo ja niiden laitteiden määrä, joiden tietoja on tallennettu laitteeseen, alaspäinsuunnassa on suurempi kuin yksi, yleislähetetään (342) tietopaketti, muussa tapauksessa lähetetään tietopaketti.
2. Patenttivaatimuksen 1 mukainen laite, joka on konfiguroitu lähettämään ja vastaanottamaan tietopaketteja, jotka käsittävät lähetyssuunnan osoittimen, jolla on yksi arvo kahdesta mahdollisesta ylöspäin-ja alaspäinsuuntaa vastaavasta arvosta.
3. Patenttivaatimuksen 2 mukainen laite, jossa tietopaketit käsittävät hyppymäärän osoittimen, jos lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo.
4. Patenttivaatimuksen 2 mukainen laite, joka lähetettäessä laitteesta peräisin olevaa pakettia on konfiguroitu sisällyttämään pakettiin paketin vastaanottajan tunniste; lähetyssuunnan osoitin; ja hyppymäärän osoitin, jos lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo.
5. Patenttivaatimuksen 1 mukainen laite, joka on konfiguroitu tallentamaan tietoja viestintäverkon laitteista, joihin laite on toiminnallisesti kytketty.
6. Patenttivaatimuksen 5 mukainen laite, joka on konfiguroitu tallentamaan tietoja yhdestä laitteesta, joka on lähetyssuunnassa ylöspäin, ja enintään kahdesta laitteesta, jotka ovat lähetyssuunnassa alaspäin.
7. Patenttivaatimuksen 1 mukainen laite, joka on konfiguroitu rekisteröitymään viestintäverkkoon lähettämällä lähetyssuunnassa ylöspäin viestin, joka käsittää laitteen tunnisteen, eliniän osoittimen ja lähetyssuunnan osoittimen, joka on yhtä suuri kuin ylöspäinsuuntaa vastaava arvo.
8. Patenttivaatimuksen 1 mukainen laite, joka on konfiguroitu yleislähettämään paketti asettamalla ennen paketin lähetystä tietopaketin Medium Access Layer -osoite yleislähetysarvoon, joka osoittaa, että tietopaketti on tarkoitettu kaikkien lähetyksen vastaanottavien laitteiden vastaanotettavaksi.
9. Patenttivaatimuksen 1 mukainen laite, joka on konfiguroitu viestimään langattomasti ainakin yhden toisen viestintäverkon laitteen kanssa.
10. Jonkin edeltävän patenttivaatimuksen mukainen laite, joka on viestintäverkon solmu.
11. Laite, joka on joukon solmuja käsittävässä ensimmäisessä viestintäverkossa ja käsittää: ainakin yhden prosessorin; ja ainakin yhden muistin, joka sisältää tietokoneohjelmakoodin, jolloin mainittu ainakin yksi muisti ja tietokoneohjelmakoodi on konfiguroitu mainitulla ainakin yhdellä prosessorilla saamaan laitteen ainakin: tallentamaan viestintäverkon solmuihin liittyvää tietoa; ja lähetettäessä tietopaketti viestintäverkon kohdesolmuun määrittämään (422) ja sisällyttämään tietopakettiin vastaanottajan IPv6-osoitteen; määrittämään (424) kohdesolmun haaran verkossa; määrittämään (426) ja sisällyttämään tietopakettiin hyppymäärän osoittimen, joka osoittaa solmusta-solmuun-hyppyjen määrän kohdesolmuun saakka; asettamaan (428) ja sisällyttämään tietopakettiin lähetyssuunnan osoittimen, joka on yhtä suuri kuin alaspäinsuuntaa vastaava arvo; lähettämään (430) paketin, tunnettu s iitä, että laite on konfiguroitu vastaanottamaan (402) tietopaketin viestintäverkossa olevasta solmusta; määrittämään (404), onko laite tietopaketin vastaanottaja, ja mikäli näin on, käsittelemään paketin; muutoin määrittelemään (406), onko tietopaketin vastaanottaja viestintäverkossa oleva solmu, ja mikäli näin on, lähettämään (410) paketin; muutoin lähettämään (408) tietopaketin ulkoiseen verkkoon.
12. Patenttivaatimuksen 11 mukainen laite, jossa viestintäverkon solmuihin liittyvä tallennettu tieto käsittää: solmun tunnisteen; solmun suunnan verkossa; tallennetun tiedon eliniän osoittimen; ja hyppymäärän osoittimen, joka osoittaa solmusta-solmuun-hyppyjen määrän solmuun saakka.
13. Patenttivaatimuksen 11 mukainen laite, joka on konfiguroitu vastaanottamaan solmulta rekisteröintiviestin, joka käsittää solmun tunnisteen ja viestissä olevan tiedon eliniän osoittimen.
14. Patenttivaatimuksen 11 mukainen laite, joka on konfiguroitu ylläpitämään solmulistaa ja määrittämään solmun hyppymäärän osoittimen A) selaamalla solmu listasta, B) hakemalla solmun edeltäjä listalta, C) toistamalla vaihe B myös edeltäjän edeltäjälle, kunnes viimeinen edeltäjä on laite itse.
15. Verkkopalvelujärjestelmä, joka käsittää yhden tai useamman laitteen joukon laitteita käsittävässä ensimmäisessä viestintäverkossa, ja laite käsittää: ainakin yhden prosessorin ja ainakin yhden muistin, joka sisältää tietokoneohjelmakoodin, jolloin mainittu ainakin yksi muisti ja tietokoneohjelmakoodi on konfiguroitu mainitulla ainakin yhdellä prosessorilla saamaan laitteen ainakin: ohjaamaan viestintää laitteeseen toiminnallisesti kytkettyjen laitteiden kanssa lähettämällä ja vastaanottamalla tietopaketteja, jotka käsittävät vastaanottajan tunnisteen, lähetyssuunnan osoittimen ja lähetyssuunnan osoittimesta riippuen hyppymäärän osoittimen, ja laite on konfiguroitu vastaanottamaan (322) tietopaketin; tunnettu siitä, että laite on konfiguroitu määrittämään (324) tietopaketin lähetyssuunnan osoittimen; määrittämään (326), onko laite tietopaketin vastaanottaja, ja mikäli näin on, käsittelemään paketin; muutoin, mikäli lähetyssuunnan osoitin on yhtä suuri kuin alaspäin-suuntaa vastaava arvo, määrittämään (328), onko hyppymäärän osoitin yhtä suuri kuin nolla, ja mikäli se on, hylkäämään (330) tietopaketin; muutoin, mikäli lähetyssuunnan osoitin on yhtä suuri kuin ylöspäinsuuntaa vastaava arvo, lähettämään (334) tietopaketin; muutoin vähentämään (336) hyppymäärän osoittimen lukua yhdellä ja mikäli lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo ja niiden laitteiden määrä, joiden tietoja on tallennettu laitteeseen, alaspäinsuunnassa on suurempi kuin yksi, yleislähettämään (342) tietopaketti, muussa tapauksessa lähettämään tietopaketti; ja laite, joka on joukon solmuja käsittävässä ensimmäisessä viestintäverkossa ja käsittää: ainakin yhden prosessorin ja ainakin yhden muistin, joka sisältää tietokoneohjelmakoodin, jolloin mainittu ainakin yksi muisti ja tietokoneohjelmakoodi on konfiguroitu mainitulla ainakin yhdellä prosessorilla saamaan laitteen ainakin: tallentamaan viestintäverkon solmuihin liittyvää tietoa; ja lähetettäessä tietopaketti viestintäverkon kohdesolmuun määrittämään (422) ja sisällyttämään tietopakettiin vastaanottajan IPv6-osoitteen; määrittämään (424) kohdesolmun haaran verkossa; määrittämään (426) ja sisällyttämään tietopakettiin hyppymäärän osoittimen, joka osoittaa solmusta-solmuun-hyppyjen määrän kohdesolmuun saakka; asettamaan (428) ja sisällyttämään tietopakettiin lähetyssuunnan osoittimen, joka on yhtä suuri kuin alaspäinsuuntaa vastaava arvo; lähettämään (430) paketin.
16. Menetelmä laitteessa, jossa menetelmässä: ohjataan viestintää yhden tai useamman laitteen kanssa; lähetetään ja vastaanotetaan tietopaketteja, jotka käsittävät vastaanottajan tunnisteen, lähetyssuunnan osoittimen ja lähetyssuunnan osoittimesta riippuen hyppymäärän osoittimen; vastaanotetaan (322) tietopaketti; tunnettu siitä, että määritetään (324) tietopaketin lähetyssuunnan osoitin; määritetään (326), onko laite tietopaketin vastaanottaja, ja mikäli näin on, käsitellään paketti; muutoin, mikäli lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo, määritetään (328), onko hyppymäärän osoitin yhtä suuri kuin nolla, ja mikäli se on, hylätään (330) tietopaketti; muutoin, mikäli lähetyssuunnan osoitin on yhtä suuri kuin ylöspäinsuuntaa vastaava arvo, lähetetään (334) tietopaketti; muutoin vähennetään (336) hyppymäärän osoittimen lukua yhdellä ja mikäli lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo ja niiden laitteiden määrä, joiden tietoja on tallennettu laitteeseen, alaspäinsuunnassa on suurempi kuin yksi, yleislähetetään (342) tietopaketti, muussa tapauksessa lähetetään tietopaketti.
17. Patenttivaatimuksen 16 mukainen menetelmä, jossa lisäksi: lähetetään ja vastaanotetaan tietopaketteja, jotka käsittävät lähetyssuunnan osoittimen, jolla on yksi arvo kahdesta mahdollisesta ylöspäin ja alaspäinsuuntaa vastaavasta arvosta.
18. Patenttivaatimuksen 17 mukainen laite, jossa tietopaketit käsittävät hyppymäärän osoittimen, jos lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo.
19. Patenttivaatimuksen 17 mukainen menetelmä, jossa lisäksi: lähetettäessä laitteesta peräisin olevaa pakettia siihen sisällytetään paketin vastaanottajan tunniste; lähetyssuunnan osoitin; ja hyppymäärän osoitin, jos lähetyssuunnan osoitin on yhtä suuri kuin alaspäinsuuntaa vastaava arvo.
20. Patenttivaatimuksen 16 mukainen menetelmä, jossa lisäksi: tallennetaan tietoja viestintäverkon laitteista, joihin laite on toiminnallisesti kytketty.
21. Patenttivaatimuksen 20 mukainen menetelmä, jossa lisäksi: tallennetaan tietoja yhdestä laitteesta, joka on lähetyssuunnassa ylöspäin, ja enintään kahdesta laitteesta, jotka ovat lähetyssuunnassa alaspäin.
22. Patenttivaatimuksen 16 mukainen menetelmä, jossa lisäksi: rekisteröidään laite viestintäverkkoon lähettämällä lähetyssuunnassa ylöspäin viesti, joka käsittää laitteen tunnisteen, eliniän osoittimen ja lähetyssuunnan osoittimen, joka on yhtä suuri kuin ylöspäinsuuntaa vastaava arvo.
23. Patenttivaatimuksen 16 mukainen menetelmä, jossa lisäksi: yleislähetetään paketti asettamalla ennen paketin lähetystä tietopaketin Medium Access Layer -osoite yleislähetysarvoon, joka osoittaa, että tietopaketti on tarkoitettu kaikkien lähetyksen vastaanottavien laitteiden vastaanotettavaksi.
24. Menetelmä laitteessa, joka on joukon solmuja käsittävässä ensimmäisessä viestintäverkossa, jossa menetelmässä: tallennetaan viestintäverkon solmuihin liittyvää tietoa; ja lähetettäessä tietopaketti viestintäverkon kohdesolmuun määritetään (422) ja sisällytetään tietopakettiin vastaanottajan IPv6- osoite; määritetään (424) kohdesolmun haara verkossa; määritetään (426) ja sisällytetään tietopakettiin hyppymäärän osoitin, joka osoittaa solmusta-solmuun-hyppyjen määrän kohdesolmuun saakka; asetetaan (428) ja sisällytetään tietopakettiin lähetyssuunnan osoitin, joka on yhtä suuri kuin alaspäinsuuntaa vastaava arvo; lähetetään (430) paketti, tunnettu siitä, että vastaanotetaan (402) tietopaketti viestintäverkossa olevasta solmusta; määritetään (404), onko laite tietopaketin vastaanottaja, ja mikäli näin on, käsitellään paketti; muutoin määritellään (406), onko tietopaketin vastaanottaja viestintäverkossa oleva solmu, ja mikäli näin on, lähetetään (410) tietopaketti; muutoin lähetetään (408) tietopaketti ulkoiseen verkkoon.
25. Patenttivaatimuksen 24 mukainen menetelmä, jossa viestintäverkon solmuihin liittyvä tallennettu tieto käsittää: solmun tunnisteen; solmun suunnan verkossa; tallennetun tiedon eliniän osoittimen; ja hyppymäärän osoittimen, joka osoittaa solmusta-solmuun-hyppyjen määrän solmuun saakka.
26. Patenttivaatimuksen 24 mukainen menetelmä, jossa lisäksi: vastaanotetaan solmulta rekisteröintiviesti, joka käsittää solmun tunnisteen ja viestissä olevan tiedon eliniän osoittimen.
27. Tietokoneohjelmatuote, joka koodaa ohjeita sisältävän tietokoneohjelman, jolla suoritetaan patenttivaatimuksen 16 mukaisen menetelmän toteuttava tietokoneprosessi.
28. Tietokoneohjelmatuote, joka koodaa ohjeita sisältävän tietokoneohjelman, jolla suoritetaan patenttivaatimuksen 24 mukaisen menetelmän toteuttava tietokoneprosessi.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FI20125807A FI125092B (fi) | 2012-07-18 | 2012-07-18 | Menetelmä, laite ja järjestelmä datapakettien lähettämiseksi ja vastaanottamiseksi |
US13/942,809 US9774528B2 (en) | 2012-07-18 | 2013-07-16 | Method, apparatus and system for transmitting and receiving data packets |
US15/691,022 US10554550B2 (en) | 2012-07-18 | 2017-08-30 | Method, apparatus and system for transmitting and receiving data packets |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FI20125807A FI125092B (fi) | 2012-07-18 | 2012-07-18 | Menetelmä, laite ja järjestelmä datapakettien lähettämiseksi ja vastaanottamiseksi |
FI20125807 | 2012-07-18 |
Publications (2)
Publication Number | Publication Date |
---|---|
FI20125807A FI20125807A (fi) | 2014-01-19 |
FI125092B true FI125092B (fi) | 2015-05-29 |
Family
ID=49946509
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FI20125807A FI125092B (fi) | 2012-07-18 | 2012-07-18 | Menetelmä, laite ja järjestelmä datapakettien lähettämiseksi ja vastaanottamiseksi |
Country Status (2)
Country | Link |
---|---|
US (2) | US9774528B2 (fi) |
FI (1) | FI125092B (fi) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2539914A (en) * | 2015-06-30 | 2017-01-04 | Perpetuum Ltd | Radio relay |
TWI619754B (zh) * | 2016-11-01 | 2018-04-01 | Chen Jin Fu | 環保材料及使用該環保材料所製成之窗簾葉片 |
US11031993B2 (en) * | 2017-01-12 | 2021-06-08 | Lg Electronics Inc. | Method and apparatus for performing relay communication based on counter information in wireless communication system |
US11321604B2 (en) * | 2017-06-21 | 2022-05-03 | Arm Ltd. | Systems and devices for compressing neural network parameters |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU664864B2 (en) * | 1991-10-01 | 1995-12-07 | Broadcom Corporation | A radio frequency local area network |
JP3821847B2 (ja) | 1995-06-30 | 2006-09-13 | コーニンクレッカ、フィリップス、エレクトロニクス、エヌ.ヴィ. | ノードのネットワークにおいてメッセージを経路指定するための方法および装置 |
US6842430B1 (en) * | 1996-10-16 | 2005-01-11 | Koninklijke Philips Electronics N.V. | Method for configuring and routing data within a wireless multihop network and a wireless network for implementing the same |
US6556574B1 (en) * | 1999-03-31 | 2003-04-29 | Cisco Technology, Inc. | Duplicate ignore delay timer for ARP like protocol messages using are protocol |
GB2354912B (en) * | 1999-09-17 | 2004-03-10 | Ericsson Telefon Ab L M | Routing in a packet switched network |
US7698463B2 (en) * | 2000-09-12 | 2010-04-13 | Sri International | System and method for disseminating topology and link-state information to routing nodes in a mobile ad hoc network |
US7447197B2 (en) * | 2001-10-18 | 2008-11-04 | Qlogic, Corporation | System and method of providing network node services |
US7398322B1 (en) * | 2003-05-20 | 2008-07-08 | Sun Microsystems, Inc. | System using routing bridges to transparently interconnect multiple network links to form a single virtual network link |
US7720006B1 (en) * | 2003-08-06 | 2010-05-18 | Cisco Technology, Inc. | System for determining reachablity of a neighboring node in a network |
US7587757B2 (en) * | 2004-02-11 | 2009-09-08 | Texas Instruments Incorporated | Surveillance implementation in managed VOP networks |
KR20060006583A (ko) | 2004-07-16 | 2006-01-19 | 아주대학교산학협력단 | 무선 센서 네트워크에 있어서의 방향성 플러딩 방법 |
US8185653B2 (en) * | 2004-08-09 | 2012-05-22 | Johnny Yau | Method and apparatus for ad hoc mesh routing |
US7738859B2 (en) * | 2005-03-10 | 2010-06-15 | Interdigital Technology Corporation | Multi-node communication system and method of requesting, reporting and collecting destination-node-based measurements and route-based measurements |
US7801110B2 (en) * | 2005-03-31 | 2010-09-21 | Toshiba America Research, Inc. | Efficient detection and/or processing in multi-hop wireless networks |
US7813326B1 (en) | 2005-05-27 | 2010-10-12 | Bluetronix Inc. | Swarm location service for mobile ad hoc network communications |
US20080123584A1 (en) * | 2006-08-08 | 2008-05-29 | Siemens Corporate Research, Inc. | Route Optimization for MultiHop Relay Transmission Systems |
KR100948836B1 (ko) | 2007-12-03 | 2010-03-22 | 한국전자통신연구원 | Ip 기반의 무선 센서 네트워크에서의도메인이름자동설정장치 및 방법 |
JP5421392B2 (ja) * | 2009-01-15 | 2014-02-19 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 宅内ネットワーク内におけるプロキシモバイルIPv6のサポート |
JP4817131B2 (ja) * | 2009-02-03 | 2011-11-16 | 横河電機株式会社 | Ipネットワークシステム |
US9081501B2 (en) * | 2010-01-08 | 2015-07-14 | International Business Machines Corporation | Multi-petascale highly efficient parallel supercomputer |
-
2012
- 2012-07-18 FI FI20125807A patent/FI125092B/fi active IP Right Grant
-
2013
- 2013-07-16 US US13/942,809 patent/US9774528B2/en active Active
-
2017
- 2017-08-30 US US15/691,022 patent/US10554550B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US20180006940A1 (en) | 2018-01-04 |
US10554550B2 (en) | 2020-02-04 |
US9774528B2 (en) | 2017-09-26 |
FI20125807A (fi) | 2014-01-19 |
US20140023077A1 (en) | 2014-01-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6518747B2 (ja) | スリーピノードをサポートするための近隣発見 | |
KR101961049B1 (ko) | 타임 슬롯화 채널 홉핑 네트워크에서의 효율적인 중앙 집중식 자원 및 스케줄 관리 | |
US10820253B2 (en) | Distributed reactive resource and schedule management in time slotted channel hopping networks | |
US10499313B2 (en) | Efficient hybrid resource and schedule management in time slotted channel hopping networks | |
Kim et al. | Blemesh: A wireless mesh network protocol for bluetooth low energy devices | |
US9992661B2 (en) | Neighbor aware network logical channels | |
EP2984784B1 (en) | System and method for providing a software defined protocol stack | |
US10554550B2 (en) | Method, apparatus and system for transmitting and receiving data packets | |
US20170126569A1 (en) | Enhanced neighbor discovery to support load balancing | |
EP3011698B1 (en) | Cross-layer and cross-application acknowledgment for data transmission | |
GB2559310A (en) | Building technology device communication system with IoT-network devices | |
WO2012059821A1 (en) | A method and device for transmitting an ipv6 over low power wireless personal area network data packet | |
CN104754687B (zh) | 信息发送方法及设备 | |
Dashkova et al. | Survey on congestion control mechanisms for wireless sensor networks | |
Padma et al. | End-to-end communication protocol in IoT-enabled ZigBee network: Investigation and performance analysis | |
US20190182854A1 (en) | Methods and apparatuses for dynamic resource and schedule management in time slotted channel hopping networks | |
Bocchino et al. | SPEED routing protocol in 6LoWPAN networks | |
JP7176237B2 (ja) | 情報伝送方法、装置及び電子機器 | |
Papadopoulos et al. | Updates on RFC 4944: Fragment forwarding and recovery | |
Chan et al. | Development of 6LoWPAN adaptation layer with fragmentation and reassembly mechanisms by using Qualnet Simulator | |
Jin et al. | Bapu: efficient and practical bunching of access point uplinks | |
Alassery | Fast Packets Delivery Techniques for Urgent Packets in Emergency Applications of Internet of Things | |
US10687244B2 (en) | Methods, first transmit device and relay device for supporting wireless communication | |
Cheng et al. | Utilizing the broadcast medium while maintaining per-link information: A practical approach | |
JP2014150449A (ja) | 通信ノード及びネットワークシステム及び通信方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PC | Transfer of assignment of patent |
Owner name: ARM FINLAND OY |
|
FG | Patent granted |
Ref document number: 125092 Country of ref document: FI Kind code of ref document: B |
|
PC | Transfer of assignment of patent |
Owner name: PELION (FINLAND) OY |