Sign In to Follow Application
View All Documents & Correspondence

Forwarding A Packet In A Sensor Personal Area Network

Abstract: A METHOD TO FORWARD A PACKET ACCORDING TO PREDEFINED PROTOCOL STEPS IN A SENSOR PERSONAL AREA NETWORK COMPRISING DATA COMMUNICATION SENSOR DEVICES AND THE RESPECTIVE SENSOR DEVICES ARE DESCRIBED. THE METHOD COMPRISES THE STEPS OF ASSIGNING A PREDEFINED COMPRESSION VALUE TO A COMPRESSION FIELD IN THE PACKET FOR INDICATING THAT A SOURCE NETWORK IDENTIFIER OF THE ORIGINATOR OF THE PACKET IS ASSUMED TO BE EQUAL TO A DESTINATION NETWORK IDENTIFIER OF AN INTENDED RECIPIENT OF THE PACKET. FURTHERMORE,THE METHOD COMPRISES ASSIGNING A PREDEFINED LABEL SWITCHING VALUE LSV TO AN ADDRESSING MODE FIELD DAM-F IN THE PACKET P FOR INDICATING THAT THE ABOVE MENTIONED PROTOCOL STEPS FURTHER COMPRISE A LABEL SWITCHING PRINCIPLE THAT MUST BE APPLIED TO FORWARD THE PACKET. FINALLY THE METHOD COMPRISES USING A SOURCE NETWORK IDENTIFIER FIELD SNI-F OF THE PACKET FOR STORING AND RETRIEVING THE LABEL VALUE LAB1 FOR APPLICATION OF THE LA

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
15 May 2012
Publication Number
23/2014
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application
Patent Number
Legal Status
Grant Date
2020-02-17
Renewal Date

Applicants

ALCATEL LUCENT
3  avenue Octave Greard  F-75007 Paris

Inventors

1. BRUNO VAN BOGAERT
Square Plasky 105/2  B-1030 Schaarbeek
2. WERNER LIEKENS
Abeel 10  B-2860 Sint Katelijne Waver
3. TOM VAN LEEUWEN
Haagstuk 31  B-8032 Wondelgem
4. WILLEM ACKE
Hoogstraat 30  B-2820 Bonheiden

Specification

FORWARDING A PACKET IN A SENSOR PERSONAL AREA NETWORK
The present invention relates to a method to forward a packet
according to predefined protocol steps in a sensor personal area
5 network that comprises data communication sensor devices and to
related sensor nodes to execute the method.
Such methods and related sensor nodes are already known in
the art e.g. from IEEE Standard 802.15.4-2003 and IEEE Standard 802.15.4-
2006 that -defines--Medium Access---Control--and Physical--Layer---
10 Specifications for compatible interconnection for data communication
devices in a personal area network. In this standard the physical layer
and the Media Access Control Layer is specified for low power low
bandwidth networks.
One of the known steps in such a method to forward a packet
15 is a step of assigning a predefined compression value to a compression
field in the packet for indicating that a source network identifier of the
originator or originating node of the packet is assumed to be equal to a
destination network identifier of an intended recipient of the packet. This
is described e.g. in paragraph 7.2.1 General MAC frame format of the
20 above mentioned standard and more particular in paragraph 7:2.-1.-1.5
PAN ID Compression subfield. Herein it is described that the personal
area network identifier compression subfield, or shortly PAN ID
Compression subfield, is 1 bit in length and specifies whether the MAC
frame is to be sent containing only one of the personal area network
25 PAN identifier fields when both source and destination PAN identifier
addresses are present. If this subfield is set to one and both the source
and destination PAN identifier addresses are present, the frame shall
contain only the Destination PAN Identifier field, and the Source PAN
Identifier field shall be assumed equal to that of the destination and can
30 thereby be omitted. So, this step needs to be applied when forwarding
a packet to a node that belongs to a same personal area network.
-2-
Furthermore, it is to be explained that this standard is a basis for
e.g. Zigbee, which is a specification for a suite of high level
communication protocols using small, low-power sensor nodes. The
technology defined by the ZigBee specification is intended to be simple
5 and not expensive and targets radio-frequency applications that require
a low data rate, long battery life, and secure networking. Another
example that uses the 802.15.4 Standard is SUN with the Sunspot
networks.
- - Both technologies-use a-layerthree protocol to, ensure-the -
10 communication in a sensor network. The routing tables in these two
solutions are populated with knowledge about the network obtained
from a routing protocol such as e.g. Ad-hoc On-demand Distance
Vector - AODV.
Furthermore 6lowpan, which is an acronym of IPv6 over Low
15 power Wireless Personal Area Networks, or IPv6 over LoW Power wireless
Area Networks, defines encapsulation and header compression
mechanisms that allow lPv6 packets to be sent to and received from
over IEEE 802.15.4 based networks. So, 6LowPan in combination with IEEE
Routing Over Lossy and Low-power links protocol - shortly called IEEE
20 ROLL anotheary-eelrr- pr-of-o-c-ol-fha 1lovvs transmission of tP-v 6
packets over 802.15.4 networks.
A sensor node in a sensor network can as such be
implemented by means of a device containing an implementation of
the IEEE 802.15.4 medium access control and physical interface to the
25 wireless medium. Such a sensor node may be a reduced-function
device or a full function device. Most sensor nodes, especially the
reduced-function nodes usually only have low processing power and do
have small batteries. However, the above described methods to
forward a packet in a sensor personal area network that comprises data
30 communication sensor devices do not always comply with these
requirements.
An object of the present invention is to provide a method and
related sensor nodes to forward a packet in such a sensor personal area
network that requires only reduced processing power since the
forwarding requires only processing at layer 2.
5 This is realized with the methods to forward a packet according
to claim 1 and claim 8; and the sensor nodes implementing these
methods according to claim 9 and claim 10.
When assigning a predefined compression value to a
- -compression field-in the packet for-indicating that a--source --network
10 identifier of the originator of the packet is being assume i equal to a
destination network identifier of an intended recipient of the packet, the
method applies the principle steps of
- assigning a predefined label switching value to an addressing
mode field in the packet for indicating that the protocol steps further
15 comprises a label switching principle that must be applied to forward the
packet; and
- using a source network identifier field of the packet for storing
and retrieving a label value for application of the label switching
principle based thereon.
20 In this way a sensor nodeiat receives the packet only needs
to read the header of the incoming frame of the incoming packet. After
"learning", through the value in the compression field and in addition
through the value in the addressing mode field, that the label switching
principle needs to be applied, the node knows that the source network
25 identifier field is not empty and that the value which it contains needs to
be seen as the required label.
Hereby the node doesn't needs to dig deeper into the
payload of the frame and processing power is saved.
Moreover this principle is applied without adding extra
30 overhead to the packets. Indeed, in the event when labels would need
to be written within the payload of an IEEE 802.15.4 packet and if the
labels are e.g. 2 bytes long (as suggested in a later described
-4-
embodiment) the advantage of the present application is at least 1,57 %
more room in the payload for data since the maximum length of the
payload of a 802.15.4 frame is 127 bytes.
Packets belonging to the same network are forwarded
5 according to a label switching principle . According to a label switching
principle, all packets that belong to a same flow are forwarded over a
same path which is set up before the first packet of the flow is being
transmitted. Nodes that are contributing to the realization of such a path
i:esour-ceintermediate and- destination-nodes-,-are- using a 'label' which
10 is transmitted within the packet in order to identify to w )ich flow the
packet belongs . Based on such a label a node will be able to look up in
his switching table what to do with the packet . Either this node is the end
of the path, or the node is an intermediate node. In the latter case the
switching table refers to the next hop to which the packet needs to be
15 transmitted and the label which the packet needs to be configured with.
It has to be remarked that the label for the outgoing packet
does not need to be the same one as the label of the incoming packet.
Furthermore , it has to be remarked that label switching
forwarding as such is a know principle from e.g. Multiprotocol Label
20 Switing MPLS eing usover wirec networks- . Id the
difference here is that firstly, an indication is used to make the sensor
node clear that the label switching principle needs indeed to be applied
and secondly that the label is to be found in a source network identifier
field of the control frame i.e. label switching on layer 2 level.
25 Also IPv6, as a routing protocol, allows the use of a 'label' in its
header to forward packets belonging to a flow, but* this technology
demands also the handling of packets on layer 3, while the present
solution does not need to look deeper than into some fields of the
header of the packet. This makes the present solution also faster in its
30 forwarding process.
The different steps to be executed when applying the basic
principle of the method of claim 1 are described in the method of claim
-5-
8. These steps are executed by the sensor nodes of claim 9 and claim
10. These steps and devices are described hereafter.
Indeed, a method to forward a packet according to
predefined protocol steps in a sensor personal area network comprising
5 data communication sensor devices comprises the steps of
by an originating node of the packet to be forwarded :
- inserting with a first inserter (INS11) a predefined compression
value in a compression field of the packet and indicating thereby that a
--source network identifier-of-the--originating---node is assumed to be equal -
10 to a destination network identifier of an intended recipient of the packet;
and
- inserting with a second inserter a predefined label switching
value in an addressing mode field in the packet and thereby indicating
to the actual sensor node that the actual protocol steps comprises a
15 label switching principle that should be applied to forward the present
packet; and
- inserting with a third inserter a label value in a source network
identifier field in the packet; and furthermore
by an intermediate node of the packet to be forwarded :
20 interpreting with a first inferpretehe predefined compression
value in the compression field and thereby determining that the source
network identifier of the originating node of the packet is assumed to be
equal to a destination network identifier of an intended recipient of said
packet; and
25 - interpreting with a second interpreter the predefined label
switching value in the addressing mode field and thereby determining
that the actual protocol steps comprises a label switching principle
which must be applied for forwarding the packet, and upon
establishment of such an interpretation, accordingly triggering a
30 retriever; and
retrieving with the retriever the label value from the source
network identifier field, whereby the label value needs to be used by the
-6-
intermediate node for forwarding the actual packet according to the
label switching principle. This is described in the method of claim 2.
As mentioned before, a suitable implementation for the
predefined protocol steps are described according to the IEEE Standard
5 802.15.4 that defines Medium Access Control and Physical Layer
Specifications for compatible interconnection for data communication
devices in a personal area network. It has to be clear that although as a
basis the predefined protocol steps of IEEE Standard 802.15.4 can be use,
-by-applying-the basic idea of-the present invention, these protocol--steps-
10 as are extended with the additional steps described here a, >ove.
As mentioned above, a suitable field for implementing the
compression field is a PAN ID Compression subfield of a Frame control
field according to an IEEE Standard with reference 802.15.4 and which
defines Medium Access Control and Physical Layer Specifications for
15 compatible interconnection for data communication devices in a
personal area network. This is described in claim 3.
When each independent Personal Area Network selects a
unique identifier, the PAN identifier allows communication between
sensor within a network by using short addresses but enables also
20 transmission between devices across independent networks. The PAN lD
Compression subfield of the 802.15.4 standard is only 1 bit long and
specifies whether the MAC frame is to be sent containing only one of the
PAN identifier fields in the event when both source and destination PAN
identifier addresses are present. In the event when this subfield is set to
25 one and both the source and destination PAN identifier addresses are
present, the frame shall contain only the Destination PAN Identifier field,
and the Source PAN Identifier field shall be assumed equal to that of the
destination.
A possible implementation of the addressing mode field is by
30 means of a destination addressing mode field. This is described in claim
4.
-7-
Furthermore by constituting such a destination addressing
mode field with a destination addressing mode field of a Frame Control
field according to the IEEE Standard with reference 802.15.4 a
convenient implementation is realized. This is described in claim 5.
5 A further implementation is described in claim 6 whereby the
destination addressing mode field is defined two bits long and whereby
the assigned predefined label switching value is for the first bit equal to
zero and for the second bit equal to one. It has to be remarked that
according to the present versions-of-the-IEEE-802..1-5..4 Standard -this-value----
10 for the destination addressing mode field is a reserved v glue which in
principle might not be used. This means that the above described
implementation requires a release of this reserved value.
Finally claim 7 describes an implementation of constituting the
source network identifier field by a Source PAN Identifier field of a Frame
15 control field according to the IEEE Standard with reference 802.15.4. This
Source PAN Identifier field, when present, is 2 octets long and specifies
normally the unique PAN identifier of the originator of the frame.
According to the known IEEE 802.15.4. Standard implementation, the
Source PAN identifier is only present when the PAN id compression is
20 equal to the predefined value `zero' . According to the present
application, this field can also be included in the MAC frame when the
PAN ID Compression subfield is "nonzero".
The above and other objects and features of the invention will
become more apparent and the invention itself will be best understood
25 by referring to the following description of an embodiment taken in
conjunction with the accompanying drawings wherein Figure 1
represents a personal area network with sensor nodes and Figure 2
represents a structure of a packet.
It is to be noticed that the term 'comprising', used in the claims,
30 should not be interpreted as being limitative to the means listed thereafter.
Thus, the scope of the expression 'a device comprising means A and B'
should not be limited to devices consisting only of components A and B. It
means that with respect to the present invention, the only relevant
components of the device are A and B.
Similarly, it is to be noticed that the term 'coupled' should not be
interpreted as being limitative to direct connections only. Thus, the scope
5 of the expression 'a device A coupled to a device B' should not be limited
to devices or systems wherein an output of device A is directly connected
to an input of device B. It means that there exists a path between an
output of A and an input of B which may be a path including other
devices or means.
10 The working of the device according to the prese. it invention in
accordance with its telecommunication environment that is shown in
Figure 1 will be explained by means of a functional description of the
different blocks shown therein. Based on this description, the practical
implementation of the blocks will be obvious to a person skilled in the art
15 and will therefor not be described in details. In addition, the principle
working of the method to forward a packet in a sensor personal area
network will be described in further detail.
Referring to Figure 1 a Personal Area Network PAN 1 is shown.
The Personal Area Network comprises sensor nodes whereof SN 1, SN2,
20 SN3, SN4 and SN5 are _shown as am-example. In order notto overlodJ
Figure 1 only in Sensor node SN1 and SN3 more details are shown. In
sensor node SN3 the relevant functional blocks of an originating node
are shown and in sensor node SN1 the relevant blocks of an intermediate
or receiving node are shown.
25 The mentioned different functional blocks of sensor node 1 are
each coupled to an input interface and the mentioned functional blocks
of an originating node are each coupled to an output interface of the
node. All these functional blocks are enabled to insert or store, to retrieve
and to interpret the bits and bytes of incoming or leaving packet such as
30 packet P.
It has to be remarked here that the different functional blocks
of e.g. the described originating sensor such as SN3 are not limited to be
-9-
only comprised in such an originating sensor. Indeed, a sensor might as
well comprise the functional blocks that are here described for the
originating node SN3 as the functional blocks that are here described for
the intermediate/receiving node SN 1 /SN5 in order to respectively
5 transmit, forward or receive a packet.
Looking to sensor node SN 1, a first interpreter INTI, a second
interpreter INT2 and a retriever RET are shown. The three functional
blocks are coupled to an input interface of sensor node 'SN 1. The first
inter-preterHNT-1--is-an interpretermeans that is -enabled to interprets a
10 predefined compression value cv in a compression field C-F in the
packet P and to determine thereby that a source network identifier of an
originator of the packet e .g. SN3 is assumed to be equal to a destination
network identifier of an intended recipient e.g . SN5 of the packet P. The
second interpreter INT2 is an interpreting means which is enabled to
15 interpret a predefined label switching value Isv in an addressing mode
field DAM-F of the packet P . Upon interpretation of the value in the
addressing mode field DAM- F and determination that it is indeed the
predefined label switching value Isv, the second interpreter shall
accordingly trigger the retriever RET. The retriever RET is a retriever means
2 0 - b Ied to refrieve, upon reception of -d-tngger of the second
interpreter INT2, a label value labl from a source network identifier field
SNI-F in the packet. As will be explained hereafter, this label value labl is
the value of a label that should be used by the sensor node SN1 to
forward the packet P according to the label switching principle.
25 Looking to sensor node SN3, a first inserter INS1, a second
inserter INS2 and a third inserter INS3 are shown. The three functional
blocks are coupled to an output interface of sensor node SN3. The first
inserter INS1, is an inserting means that is enabled to insert a predefined
compression value cv in a compression field C-F of packet P that is
30 prepared to be transmitted. The second inserter INS2, is an inserting
means that is enabled to insert a predefined label switching value Isv in
an addressing mode field DAM-F of that packet P. The third inserter INS3,
-10-
is an inserting means that is enabled to insert a label value labl in a
source network identifier field SNI-F in the packet.
Referring to Figure 2 ,convenient mapping to the known IEEE
Standard with reference 802.15.4 will be explained. On top of Figure 2, in
5 the first row, a frame structure according to an IEEE Standard with
reference 802.15.4 is shown : a Frame Control field of 2 bytes, a
Sequence number of 1 byte, an addressing Field of ' to 20 bytes, a
payload and a Frame Check Sequence of 1 byte is shown.
-- ---In-the second-row, the-Frame-Control-Field-and the-Addressing -
10 Fields are shown in more details. In this way, the Frame Control Field
shows A Frame Type (bit 1, 2, 3), a Security enabled bit (bit 4), a Frame
Pending bit (bit 5), an Ack Request bit (bit 5), a PAN id Compression Field
(bit 6), Reserved bits (bits 7, 8 and 9), Destination addressing mode bits
(bits 10, 11), Frame version bits (bits 12 and 13) and Source Addressing
15 mode bits (bits 14 and 15). The Structure of the addressing field shows a
Destination PAN Identifier Field (0 or 2 bytes), Destination MAC address
field (0, 2 or 8 bytes), a Source PAN identifier field (0 or 2 bytes) and a
Source MAC address field (0, 2 or 8 bytes). A convenient implementation
of the defined fields of the present applications by means of an IEEE
20 Standard with reference 802.15:4 are made clear by means of an arrow
from the third row in Figure 2 towards the second row. In this way is a
convenient implementation for the Compression Field of the present
application the PAN id Compression field of an IEEE Standard with
reference 802.15.4 i.e. bit 6 of the Frame Control Field. In a similar way is
25 the Destination addressing mode field of the Frame Control Field of an
IEEE Standard with reference 802.15.4 a convenient implementation for
the Addressing Mode field of the present application. Furthermore can
the Source Network Identifier field be implemented by means of the
Source PAN Identifier field of an IEEE Standard with reference 802.15.4. It
30 has to be remarked here that although actual known fields of an IEEE
Standard with reference 802.15.4 can be re-used in the packet, the
actual known values or newly defined values for the different fields are
-11 -
getting different or additional meanings to be respected according to
the designed functional blocks. This will become clearer in the following
paragraphs.
Referring to the Compression Field C-F of a packet P, and
5 according to the known specifications, bit 6 tells, in the event when it is
set to 1, that the Destination PAN identification of the receiving node
intended to receive the packet is the same as the Source PAN
identification of the Source node i.e. originating sensor node. In that
case the Source PAN-identification-might be-omitted--according to these
10 known specifications. This means that the Source Network dentifier Field
does in fact not exist. Furthermore, referring to the addressing mode field
DAM-F, the bits 10 and 11 can have the following values:
00 Destination PAN id and destination address are not
present
15 10 Destination address uses 16 bits notation
11 Destination address uses 64 bits notation
According to the present application these rules are extended
with the following principles. Firstly an additional value for the addressing
mode field is defined i.e. bits 10 and 11 might as well get a predefined
20 value called ^`lael switching value According to t e above
implementation according to IEEE Standard with reference 802.15.4 only
the value "01 " is left for these two bits. So, according to this described
implementation the predefined "label switching value" receives the
actual value "01 ".
25 Now, according to the present application, in the event when:
- bit number 6 of the Compression Field is indeed set to the
compression value cv i.e. "1 "; and when
- bits number 10 and 11 of the Addressing Mode Field in the
Frame Control field do have the newly defined label switching value Isv
30 i.e. "01 ",
the newly defined and implemented rule in the sensor nodes is
that the Source; Network Identifier field SNI-F should not be omitted but
-12-
must, to the contrary of the known rules, be checked upon its value i.e.
the Source Network Identifier Field does exist and a certain value is
included a that place of the field in the packet. This value is called, the
label value labl. And this label value labl needs to be used to forward
5 the packet according to a label switching principle.
It has to be remarked here that in the present application the
structure of the label is not described in, detail since this goes beyond the
aim of the present application. The aim of the present application is to
- -include-in--the packet- Palabelon the level of the packet-header-
10 whereby the principle of label switching can be applied \A, ithout having
the different sensor nodes to execute deep processing of the packet to
find the required label i.e. without having to look into the payload field of
the packet P. The two bytes of the label can e.g. be used to contain a 1
byte label value and a 1 byte TTL "Time To Live". Alternatively, the two
15 bytes could be used to carry a label within a label i.e. called "label
stacking" or some bits can be used to carry QoS information.
A further advantage of the application of label switching for
the forwarding of a packet in a sensor personal area network is the
flexibility to manually influence the path of the packet P to be taken.
20 Inc eed, as describes( above, according to a e switch ing princip e he
respective value for the labels is kept in forwarding tables which needs to
be checked by the sensor devices to learn whereto the packet P needs
to be forwarded. These forwarding tables can manually adjusted
whereby the route of a packet can be influenced to pass e.g. sensor
25 devices with more processing power.
The working of the sensor devices according to the present
invention in accordance with its telecommunication environment that is
shown in Figure 1 will now be explained by means of a functional
description of the different blocks shown therein.
30 Presume that a packet is to be transmitted by originating node
SN3 via intermediate sensor node SN 1 towards the receiving node SN5.
All nodes are part of the same sensor personal area network PAN 1.
-13-
The method according to the present application comprises
therefore the following steps. At sensor device SN3, the header of the
packet P is constructed in order to prepare the complete packet P for
forwarding towards the next sensor device SN1. The sensor device SN3
5 executes the following steps:
- inserting with the first inserter INS1 of SN3 the predefined
compression value cv such as "1" in the compression field C-F of
constructed packet P and indicating thereby that a source network
-identifier-of the--originating node SN3-is -indeed assumed 'equal-to a-
10 destination network identifier of the intended recipient i.,-. SN5 of the
packet P; and
- inserting with a second inserter INS2 of SN3 a predefined label
switching value Isv such as "01" in the addressing mode field DAM-F in
the packet P and thereby indicating that the protocol steps to forward
15 the packet comprises a label switching principle which must be applied
to forward or to finally receive the packet P; and
- inserting with a third inserter INS3 of SN3 a label value labl in a
source network identifier field SNI-F in the packet. It has to be remarked
that this labl value is predetermined according to label switching
20 rwarding princi51es. This first- label va a abl is m value that will
instruct the first following sensor device on the way of the packet,
according to its forwarding table, to take the right actions to forward the
packet towards the next sensor device. After executing these previous
steps the sensor device SN3 transmits the packet P towards sensor device
25 SN 1. Upon reception of the packet P, sensor device SN1 executes the
following steps:
- interpreting with a first interpreter INT1 of SN1 the predefined
compression value cv "I" in the compression field C-F and thereby
indeed determining that the source network identifier of the originating
30 node SN3 of the packet P is indeed equal to the destination network
identifier of the intended recipient of the packet SN5; and
-14-
- interpreting with a second interpreter INT2 of SN1 the
predefined label switching value Isv "01" in the addressing mode field
DAM-F and thereby determining that the protocol steps comprises a
label switching principle that must be applied for forwarding the packet
5 P, and accordingly thereby triggering the retriever RET; and
- retrieving with the retriever RET the label value lab] from the
source network identifier. field SNI-F. This label value labl is used by the
intermediate node SN 1 to forward the packet according to the label
switching-principle.
10 It is shortly mentioned here that the value of labl might remain
the same value labl or might as well be replaced with another label
value e.g. lab2. This is dependent of the forwarding table and
instructions of the label switching specification. In this way the packet P
is forwarded by the sensor device SN1 towards sensor device SN5. Upon
15 reception of the packet P, sensor device SN5 executes similar steps as
being executed by sensor device SN1. However, upon determination of
the actual included label value and consulting of its label switching
forwarding table the Sensor device SN5 learns that packet P reached its
destination.
20 A final rema ishat embodime f^he present invention are
described above in terms of functional blocks. From the functional
description of these blocks, given above, it will be apparent for a person
skilled in the art of designing electronic devices how embodiments of
these blocks can be manufactured with well-known electronic
25 components. A detailed architecture of the contents of the functional
blocks hence is not given.
While the principles of the invention have been described
above in connection with specific apparatus, it is to be clearly
understood that this description is made only by way of example and not
30 as a limitation on the scope of the invention, as defined in the appended
claims.
-15-

CLAIMS
1. Method to forward a packet (P) according to predefined
protocol steps in a sensor personal area network (PANT) comprising data
communication sensor devices (SN1, SN2, SN3, SN4, SN5, ...), said method
5 comprises
- assigning a predefined compression value (cv) to a
compression field (C-F) in said packet (P) for indicating that,a source
network identifier of the originator (SN3) of said packet being assumed
equal to a-destination network-identifier-of-an--intended--recipient-of-said
10 packet,'
characterized in that said method further comprises
- assigning a predefined label switching value (Isv) to an
addressing mode field (DAM-F) in said packet (P) for indicating that said
protocol steps further comprises a label switching principle that must be
15 applied to forward said packet (P); and
- using a source network identifier field (SNI-F) of said packet for
storing and retrieving a label value (labl) for application of said label
switching principle based thereon.
20 _ _ _ - 2 . method-according fo claim 1, wherein said -predefined- -
protocol steps being described according to an IEEE Standard with
reference 802.15.4 that defines Medium Access Control and Physical
Layer Specifications for compatible interconnection for data
communication devices in a personal area network.
25
3. The method according to claim 1, characterized by
constituting said compression field (C-F) by a PAN ID Compression
subfield of a Frame control field according to according an IEEE
Standard with reference 802.15.4 that defines Medium Access Control
30 and Physical Layer Specifications for compatible interconnection for
data communication devices in a personal area network.
-16-
4. The method according to claim 1, characterized by
implementing said addressing mode field (DAM-F) by means of a
destination addressing mode field.
5. The method according to claim 4, characterized by
5 constituting said destination addressing mode field (DAM-F) by a
destination addressing mode field of a Frame control field according to
an IEEE Standard with reference 802.15.4 that defines Medium Access
Control and Physical Layer Specifications for compatible interconnection
fordata -communccatiorrdevices in-a-personal-area network.,-------- -
10
6. The method according to claim 5, characterized by defining
said destination addressing mode field (DAM-F) two bits long and
assigning to said predefined label switching value (Isv) first bit equal to
zero and a second bit equal to one,.
15
7. The method according to claim 1 , characterized by
constituting said source network identifier field (SNI-F) by a Source PAN
Identifier field of a Frame control field according to an IEEE Standard
with reference 802.15.4 that defines Medium Access Control and Physical
20 Layer Specificafionsfor compible erconnection for data
communication devices in a personal area network.
8. Method to forward a packet (P) according to predefined
protocol steps in a sensor personal area network (PAN 1) comprising data
25 communication sensor devices (SN1, SN2, SN3, SN4, SN5, ...), said method
comprises
by an originating node (SN3)
- inserting with a first inserter (INS1) a predefined compression
value (cv) in a compression field (C-F) in said packet (P) and indicating
30 thereby that a source network identifier of said originating node (SN3)
being assumed equal to a destination network identifier of an intended
recipient of said packet (P); and
-17-
- inserting with a second inserter (INS2) a predefined label
switching value (Isv) in an addressing mode field (DAM-F) in said packet
(P) and thereby indicating that said protocol steps comprises a label
switching principle that must be applied to forward said packet (P); and
5 - inserting with a third inserter (INS3) a label value (labl) in a
source network identifier field (SNI-F) in said packet; and
by an intermediate node (SN1) :
- interpreting with a first interpreter (INT1) said predefined
- compression value-(cv-)--in said-compression-field (C-F) andthereby-
10 determining that said source network identifier of said oricinating node
(SN3) of said packet being assumed equal to a destination network
identifier of an intended recipient of said packet; and
- interpreting with a second interpreter (INT2) said predefined
label switching value (Isv) in said addressing mode field (DAM-F) and
15 thereby determining that said protocol steps comprises a label switching
principle that must be applied for forwarding said packet (P), and
accordingly thereby triggering a retriever (RET); and
- retrieving with said retriever (RET) said label value (labl) from
said source network identifier field (SNI-F), said label value (labl) being
20 used y said intermediate node (SN1) for forwarding said pacc^et
according to said label switching principle.
9. A Sensor node (SN1) to forward a packet (P) according to
predefined protocol steps in a sensor personal area network (PANT)
25 comprising data communication sensor devices (SN1, SN2, SN3, SN4, SN5,
), said sensor node comprises
- a first interpreter (INT1) to interprets a predefined compression
value (cv) in a compression field (C-F) in said packet (P) and to thereby
determine that a source network identifier of an originator (SN3) of said
30 packet being assumed equal to a destination network identifier of an
intended recipient of said packet,
ch&ih', is ierized in that said sensor node (SN 1 ) further comprises
-13-
- a second interpreter (INT2) to interprets a predefined label
switching value (Isv) in an addressing mode field (DAM-F) in said packet
(P) and to determine thereby that said protocol steps comprises a label
switching principle that must be applied to forward said packet (P), and
accordingly to trigger thereby a retriever (RET); and
said retriever (RET) to retrieve a label value (labl) from a
source network identifier field (SNI-F) in said packet, said label value
(labl) being used by said sensor node (SN1) to forward said packet
-acc(_,rdirrg to-said-label-swi-aching-principle--- --
10
10. An originating sensor node (SN3) to forward a packet (P)
according to predefined protocol steps in a sensor personal area
network (PAN 1) comprising data communication sensor devices (SN 1,
SN2, SN3, SN4, SN5, ...), said sensor node (SN3) comprises
15 - a first inserter (INS1) to insert a predefined compression value
(cv) in a compression field (C-F) in said packet (P) and to thereby
indicate that a source network identifier of said originating sensor node
(SN3) of said packet being assumed equal to a destination network
identifier of an intended recipient of said packet (P),
20 c aracefn-z 'n tha-F said- originating no- e (SN3 ur er
comprises
- a second inserter (INS2) to insert a predefined label switching
value (Isv) in an addressing mode field (DAM-F) in said packet (P) and to
thereby indicate that said protocol steps comprises a label switching
25 principle that must be applied to forward said packet (P); and
- a third inserter (INS3)' to insert 'a label value (Igbl) in a source
network identifier field (SNI-F). in said packet, said label value (lab] )
being used by an intermediate sensor node (SN1) to forward said packet
according to said label switching principle.

Documents

Application Documents

# Name Date
1 4242-DELNP-2012-IntimationOfGrant17-02-2020.pdf 2020-02-17
1 Translation-Search Report.pdf 2012-05-15
2 4242-DELNP-2012-PatentCertificate17-02-2020.pdf 2020-02-17
2 Priority Document.pdf 2012-05-15
3 Power of Authority.pdf 2012-05-15
3 4242-DELNP-2012-AMENDED DOCUMENTS [07-02-2020(online)].pdf 2020-02-07
4 Form-5.doc 2012-05-15
4 4242-DELNP-2012-FORM 13 [07-02-2020(online)].pdf 2020-02-07
5 4242-DELNP-2012-Correspondence-070818.pdf 2018-08-10
6 Form-1.pdf 2012-05-15
6 4242-DELNP-2012-Power of Attorney-070818.pdf 2018-08-10
7 Drawings.pdf 2012-05-15
7 4242-DELNP-2012-CLAIMS [06-08-2018(online)].pdf 2018-08-06
8 4242-delnp-2012-Form-18-(17-05-2012).pdf 2012-05-17
8 4242-DELNP-2012-COMPLETE SPECIFICATION [06-08-2018(online)].pdf 2018-08-06
9 4242-delnp-2012-Correspondence Others-(17-05-2012).pdf 2012-05-17
9 4242-DELNP-2012-CORRESPONDENCE [06-08-2018(online)].pdf 2018-08-06
10 4242-DELNP-2012-DRAWING [06-08-2018(online)].pdf 2018-08-06
10 4242-delnp-2012-Form-3-(04-07-2013).pdf 2013-07-04
11 4242-delnp-2012-Correspondence-Others-(04-07-2013).pdf 2013-07-04
11 4242-DELNP-2012-FER_SER_REPLY [06-08-2018(online)].pdf 2018-08-06
12 4242-DELNP-2012-FORM 3 [06-08-2018(online)].pdf 2018-08-06
12 4242-delnp-2012-Form-3-(18-02-2014).pdf 2014-02-18
13 4242-delnp-2012-Correspondence-Others-(18-02-2014).pdf 2014-02-18
13 4242-DELNP-2012-FORM-26 [06-08-2018(online)].pdf 2018-08-06
14 4242-delnp-2012-Form-3-(18-06-2015).pdf 2015-06-18
14 4242-DELNP-2012-OTHERS [06-08-2018(online)].pdf 2018-08-06
15 4242-delnp-2012-Correspondence Others-(18-06-2015).pdf 2015-06-18
15 4242-DELNP-2012-PETITION UNDER RULE 137 [06-08-2018(online)].pdf 2018-08-06
16 4242-delnp-2012-Form-3-(27-10-2015).pdf 2015-10-27
16 4242-DELNP-2012-Correspondence-080618.pdf 2018-06-14
17 4242-DELNP-2012-OTHERS-080618.pdf 2018-06-14
17 4242-delnp-2012-Correspondence Others-(27-10-2015).pdf 2015-10-27
18 4242-DELNP-2012-FORM 3 [24-01-2018(online)].pdf 2018-01-24
18 4242-DELNP-2012-Proof of Right (MANDATORY) [07-06-2018(online)].pdf 2018-06-07
19 4242-DELNP-2012-FER.pdf 2018-02-22
19 4242-DELNP-2012-PETITION UNDER RULE 137 [05-06-2018(online)].pdf 2018-06-05
20 4242-DELNP-2012-FORM 3 [23-04-2018(online)]-1.pdf 2018-04-23
20 4242-DELNP-2012-FORM 3 [23-04-2018(online)].pdf 2018-04-23
21 4242-DELNP-2012-FORM 3 [23-04-2018(online)]-1.pdf 2018-04-23
21 4242-DELNP-2012-FORM 3 [23-04-2018(online)].pdf 2018-04-23
22 4242-DELNP-2012-FER.pdf 2018-02-22
22 4242-DELNP-2012-PETITION UNDER RULE 137 [05-06-2018(online)].pdf 2018-06-05
23 4242-DELNP-2012-FORM 3 [24-01-2018(online)].pdf 2018-01-24
23 4242-DELNP-2012-Proof of Right (MANDATORY) [07-06-2018(online)].pdf 2018-06-07
24 4242-delnp-2012-Correspondence Others-(27-10-2015).pdf 2015-10-27
24 4242-DELNP-2012-OTHERS-080618.pdf 2018-06-14
25 4242-DELNP-2012-Correspondence-080618.pdf 2018-06-14
25 4242-delnp-2012-Form-3-(27-10-2015).pdf 2015-10-27
26 4242-delnp-2012-Correspondence Others-(18-06-2015).pdf 2015-06-18
26 4242-DELNP-2012-PETITION UNDER RULE 137 [06-08-2018(online)].pdf 2018-08-06
27 4242-delnp-2012-Form-3-(18-06-2015).pdf 2015-06-18
27 4242-DELNP-2012-OTHERS [06-08-2018(online)].pdf 2018-08-06
28 4242-delnp-2012-Correspondence-Others-(18-02-2014).pdf 2014-02-18
28 4242-DELNP-2012-FORM-26 [06-08-2018(online)].pdf 2018-08-06
29 4242-delnp-2012-Form-3-(18-02-2014).pdf 2014-02-18
29 4242-DELNP-2012-FORM 3 [06-08-2018(online)].pdf 2018-08-06
30 4242-delnp-2012-Correspondence-Others-(04-07-2013).pdf 2013-07-04
30 4242-DELNP-2012-FER_SER_REPLY [06-08-2018(online)].pdf 2018-08-06
31 4242-DELNP-2012-DRAWING [06-08-2018(online)].pdf 2018-08-06
31 4242-delnp-2012-Form-3-(04-07-2013).pdf 2013-07-04
32 4242-delnp-2012-Correspondence Others-(17-05-2012).pdf 2012-05-17
32 4242-DELNP-2012-CORRESPONDENCE [06-08-2018(online)].pdf 2018-08-06
33 4242-DELNP-2012-COMPLETE SPECIFICATION [06-08-2018(online)].pdf 2018-08-06
33 4242-delnp-2012-Form-18-(17-05-2012).pdf 2012-05-17
34 4242-DELNP-2012-CLAIMS [06-08-2018(online)].pdf 2018-08-06
34 Drawings.pdf 2012-05-15
35 Form-1.pdf 2012-05-15
35 4242-DELNP-2012-Power of Attorney-070818.pdf 2018-08-10
36 4242-DELNP-2012-Correspondence-070818.pdf 2018-08-10
37 4242-DELNP-2012-FORM 13 [07-02-2020(online)].pdf 2020-02-07
38 Power of Authority.pdf 2012-05-15
38 4242-DELNP-2012-AMENDED DOCUMENTS [07-02-2020(online)].pdf 2020-02-07
39 Priority Document.pdf 2012-05-15
39 4242-DELNP-2012-PatentCertificate17-02-2020.pdf 2020-02-17
40 4242-DELNP-2012-IntimationOfGrant17-02-2020.pdf 2020-02-17
40 Translation-Search Report.pdf 2012-05-15

Search Strategy

1 Current_Searches_04-10-2017.pdf

ERegister / Renewals