WO2013080034A2

WO2013080034A2 - Method and apparatus for network-based multicast in a ubiquitous sensor network

Info

Publication number: WO2013080034A2
Application number: PCT/IB2012/002682
Authority: WO
Inventors: Shuigen Yang; Jun.b. ZHENG; Fanxiang Bin; Haibo Wen; Chunyan Yao
Original assignee: Alcatel Lucent
Priority date: 2011-11-29
Filing date: 2012-11-16
Publication date: 2013-06-06
Also published as: TWI466576B; TW201330679A; CN103139083B; CN103139083A; WO2013080034A3

Abstract

The present invention provides a method and apparatus for network-based multicast in a ubiquitous sensor network. In the present method, after receiving an association request from a sensor node, a sensor network gateway sends a first binding update message to a sensor network controller, wherein the first binding update message comprises an identifier of the sensor node; receives a first binding update confirmation message from the sensor network controller, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to a multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group; determines whether each sensor node governed by the sensor network gateway comprises a member sensor node of the multicast group; when sensor nodes governed by the sensor network gateway comprises a member sensor node of the multicast group, sends a second binding update message to the sensor network controller, the second binding update message comprising the multicast address of the multicast group, and an identifier of the member sensor node in the multicast group governed by the sensor network gateway.

Description

Method And Apparatus For Network-Based Multicast In A Ubiquitous Sensor Network

FIELD OF THE INVENTION

The present invention relates to a sensor network, and more specifically, to a method and apparatus for network-based multicast in a ubiquitous sensor network.

Background of the Invention

As a comprehensive intelligent information system integrating radio technology, embedded technology, and sensor network technology, a sensor network may be applied to various fields such as public security, ecology and environment, emergency management, intelligent transport, anti-terrorism, intelligent home, and etc. For example, a sensor/controller network in intelligent home, collection of various parameters in an industrial site, and uniform networking regulation of controllers, etc., can be implemented through a sensor network. A ubiquitous sensor network USN contains a considerable amount of sensor nodes/networks. Thus, the USN introduces the effective automatic routing, monitoring, and managing requirements in a set of sensor nodes with limited resources. For example, in a scenario of environment monitoring, the USN may comprise a plurality of sensor nodes, and these sensor nodes are deployed in different regions to collect environment-related information, respectively. For these sensor nodes, because a user is always interested in properties of a group of sensor nodes, instead of a single sensor node, effective multicast is a desired network service. For example, a new parameter should be configured for all sensor nodes that monitor the temperature of a given region and are located in the given region, or firmware should be updated for them. Compared with unicasting the same message "Configure a New Parameter or Update Sensor Firmware" to each temperature sensor, multicasting such message can provide a higher energy efficiency and lower overheads, which is also more flexible.

However, it is not an easy task to provide multicast support to the USN due to the following characteristics:

1. The battery life of a sensor is rather limited, and due to the limitation of costs, the memory, the CPU speed, and the wireless interface complexity are all limited. Thus, the USN frequently suffers from serious resource limitation and functional limitation. Due to these limitations, a multicast protocol should be light-weighted as much as possible, or even the involvement of a sensor node is not required.

2. The USN faces the challenge from mobile sensor nodes. A sensor node will enter into a network, or change its location within the network, or leave the network. These events will occur frequently in some applications. Thus, a multicast protocol must allow mobility of a sensor and provide an adaptive mobility management. In other words, a multicast protocol for the USN must be adaptable to network topological change caused by a sensor joining/ leaving the network or location change of the sensor. 3. The number of sensors supporting some application is expected to be huge, for example, a level from 10²-10⁷. If each mobile sensor node individually updates its location information and rejoins a multicast group of its interest when it moves into a new domain, it will cause signaling inrush and increase network load. With the increase of the number of sensor nodes, the issue of signaling overheads will also become more serious. Thus, the multicast protocol for the USN must provide scalability.

At present, for the USN, because IPv6 has a massive address space, it is an optimal solution for connecting isolated sensor nodes. Because the IPv6 mobile multicast allows effective utilization of network bandwidth and supports mobility management for multi-point communication, it is expected to be a substantive communication type for delivering services to the USN.

Most existing IPv6 mobile multicast solutions are host computer-based mobility management protocols. They rely on mobility signaling of mobile nodes (MN) to support IPv6 mobility. In other words, a mobility stack at a mobile node is needed. Correspondingly, they are merely limited to mobile nodes with powerful functions, which also is a greater defect for a host computer-based mobility management protocol.

A traditional method of enabling IPv6 mobile multicast is based on a network-based mobility management protocol. Currently, the best existing solution is using a proxy mobile IPv6 (hereinafter referred to as ΡΜΙΡνδ), which is being standardized by the IETF. By using the ΡΜΙΡνδ, a mobile node is managed by a mobility entity, such as a mobile access gateway MAG and a local mobility anchor LMA.

In the traditional ΡΜΙΡνδ, after performing location update by exchanging a proxy binding update message and a proxy binding confirmation message between a new MAG (n-MAG) and the LMA, the n-MAG currently serving a mobile node sends a multicast listener discovery MLD query message to the mobile node. As a response, the mobile node sends an MLD member report message that indicates a particular multicast group of interest. After the n-MAG receives the MLD member report message from the mobile node, it updates its multicast forward state and its MLD proxy member database if necessary, and sends an aggregated MLD member report message to the LMA. When the LMA receives the MLD member report message, it updates its multicast forward state. Therefore, the deployment requirements for MAG and LAM are defined as follows: 1 ) the MAG needs a multicast monitor discovery proxy function to facilitate the MLD member report transmitted from the mobile node and forward multicast traffic to the mobile node; 2) A multicast router function is needed to maintain the multicast forward state for the mobile node and forward the multicast traffic to the mobile node.

However, when the traditional multicast-enabled PMIPv6 is applied to a massive USN, some drawbacks arise: 1. In the traditional PMIPv6, the MAG needs to assign a unique proxy care-of-address to each mobile node (MN) so as to operate as a tunnel endpoint, and the mobile node should support the TCP/IP stack. However, in most cases, because the power and function of a sensor node/network are limited, a private protocol stack (for example, ZigBee), instead of TCP/IP, is used. It would be too heavy for a sensor node/ network to use TCP/IP.

2. In the traditional multicast-enabled ΡΜΙΡνδ, when a MN moves to a new MAG, it will send an MLD member report message to indicate its particular multicast group or service of interest. However, in the USN, a sensor node/ network always does not know which multicast group it belongs to. Therefore, it cannot send the MLD member report message to the new MAG. On the contrary, the multicast group for the sensor node/ network is managed by network. In fact, the sensor node/network does not concern which multicast group it belongs to. Thus, the new MAG should know the multicast group into which the sensor network/node is interested in other manner.

3. In the USN, the number of sensor nodes/networks is huge. It may be expected that the number of sensor nodes/ networks under an MAG can easily exceed hundreds or even more. When a sensor nodes/network moves, the new MAG will update its location information at the LMA and rejoin the multicast group of its interest. If the MAG separately updates location information for each mobile sensor node/ network and rejoins a multicast group, it will cause inrush of signaling and therefore increases the network traffic load.

SUMMARY OF THE INVENTION

The present invention provides a network-based multicast solution for a USN. The inventive ideas are specified below: 1. A USN network is divided into a plurality of domains, each domain having a coordinator called ubiquitous sensor network controller (UC). The UC records the location of a sensor node/ network as well as a multicast group of its interest and forwards a data packet sent to or from the domain (UC domain). Each UC domain contains a set of sensor node/ network gateways (SGWs). Further, all UCs responsible for different domains form a distributed architecture. 2. When a sensor node/network moves to a new SWG, it is the new SGW, instead of the sensor node/ network, that updates location information of the sensor node/network at the UC. 3. The new SGW obtains from the UC the multicast group into which the sensor node/network is interested, instead of obtaining from the sensor node/ network the multicast group into which the sensor node/ network is interested. Therefore, it does not need the involvement of the sensor node/ network whose power and function are limited. 4. The new SGW performs location management and rejoins a multicast group of interest for a set of sensor nodes/ networks within the same multicast group.

5. A binding update message and a binding confirmation message between the UC and the new SGW contain a tag "C" which specifies multicast-enabled location management.

According to a first aspect of the present invention, there is provided a method of supporting multicast in a sensor network gateway, the method comprising the following steps: after receiving an association request from a sensor node governed by the sensor network gateway, sending a first binding update message to a sensor network controller, wherein the first binding update message comprises an identifier of the sensor node; receiving a first binding update confirmation message from the sensor network controller, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to a multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group; determining whether each sensor node governed by the sensor network gateway comprises a member sensor node of the multicast group based on the first binding update confirmation message; when sensor nodes governed by the sensor network gateway comprise a member sensor node of the multicast group, sending a second binding update message to the sensor network controller, the second binding update message comprising the multicast address of the multicast group, and an identifier of the member sensor node in the multicast group governed by the sensor network gateway.

According to a second aspect of the present invention, there is provided a method of controlling multicast to a sensor node in a sensor network controller, the method comprising the following steps: receiving a first binding update message from a sensor network gateway, wherein the first binding update message comprises an identifier of the sensor node; determining whether the sensor node is a member of a multicast group based on the identifier of the sensor node; sending a first binding update confirmation message to the sensor network gateway if the sensor node is a member of the multicast group, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to the multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group.

According to a third aspect of the present invention, there is provided a first apparatus for supporting multicast in a sensor network gateway, comprising: a first sending module configured to send a first binding update message to a sensor network controller after receiving an association request from a sensor node governed by the sensor network gateway, wherein the first binding update message comprises an identifier of the sensor node; a first receiving module configured to receive a first binding update confirmation message from the sensor network controller, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to a multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group; a first determining module configured to determine whether each sensor node governed by the sensor network gateway comprise a member sensor node of the multicast group based on the first binding update confirmation message; wherein the first sending module is further configured to send a second binding update message to the sensor network controller when sensor nodes governed by the sensor network gateway comprise a member sensor node of the multicast group, the second binding update message comprising the multicast address of the multicast group, and an identifier of the member sensor node in the multicast group governed by the sensor network gateway. According to a fourth aspect of the present invention, there is provided a second apparatus for controlling multicast to a sensor node in a sensor network controller, comprising: a second receiving module configured to receive a first binding update message from a sensor network gateway, wherein the first binding update message comprises an identifier of the sensor node; a second determining module configured to determine whether the sensor node is a member of a multicast group based on the identifier of the sensor node; a second sending module configured to send a first binding update confirmation message to the sensor network gateway if the sensor node is a member of the multicast group, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to the multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group.

The present invention provides a multicast-based data traffic forwarding mechanism, which, compared with a traditional unicast-based data traffic forwarding mechanism, provides a higher energy efficiency, lower overheads, and a higher flexibility. The present invention further lowers power consumption of sensor nodes/networks, because the present invention does not need the sensor nodes/networks to be involved in the process of rejoining a multicast group and updating location. The present invention provides a multicast-enabled location update mechanism for massive sensor nodes/ networks so as to lower signaling overheads and network traffic related to updating a location system database and rejoining a multicast group. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Through reading the following detailed depiction on non-limiting embodiments with reference to the accompanying drawings, other features, objectives, and advantages of the present invention will become more apparent. Fig. 1 shows a network topological structure diagram according to one embodiment of the present invention;

Fig. 2 shows a flowchart of a method comprising a process of registration, joining in a multicast group, and data forwarding in a multicast-enabled ubiquitous sensor network;

Fig. 3 shows a flowchart of a method comprising a process of location information management in a multicast-enabled ubiquitous sensor network;

Fig. 4 shows an exemplary binding cache entry according to one embodiment of the present invention;

Fig. 5 shows a diagram of an exemplary format of a binding update message having a multicast extension option according to one embodiment of the present invention; Fig. 6 shows a diagram of an exemplary format of a binding confirmation message having a multicast extension option according to one embodiment of the present invention;

Fig. 7 shows block diagrams of apparatuses according to one embodiment of the present invention. I n the accompanying drawings, like or similar reference numerals indicate the same or corresponding step features or means/modules.

DETAILED DESCRIPTION OF THE INVENTION

Network Architecture

Fig. 1 shows a network-based multicast solution for a USN according to the present invention. It comprises two main functional components.

SGW: responsible for connecting a sensor node/ network (SN) to the Internet and translating multicast data traffic from a UC to unicast data traffic to the SN. A SGW periodically sends a beacon containing information about a Personal Area Network (PAN) ID and an Extended Unique Identifier (EUI) of the SGW. Each SGW has a unique PAN ID in the network. The beacon has a frame structure of a standard I EEE 802.15.4 beacon. For example, in Fig. 1 , SGW1 is responsible for connecting SN 1 and SN2 to the Internet, while SGW2 is responsible for connecting SN3 to the Internet.

UC: a coordinator responsible for managing SNs and SGWs within a domain. A UC records an identifier of a sensor node (sensor node ID), location information (for example, which SGW is associated with the sensor node), and a multicast group of interest. Moreover, the UC forwards multicast data to a SGW. For example, in Fig. 1 , the UC manages the location information of SGW1 , SGW2, SN1 , SN2, and SN3 and the multicast group of interest within its domain.

In the present embodiment, SGW and UC are two functional components. They can be directly implemented in an existing network entity. For example, the function of UC can be implemented in LAM of PMIPv6, and the function of SGW can be implemented in MAG of PMIPv6.

When an SN is connected to the Internet or started for the first time, the SGW and UC will register the SN and records relevant information of the SN, for example, its sensor node ID, location, and multicast group of interest. Besides, the SGW and UC will join in the multicast group of interest on behalf of the SN.

Next, with reference to Fig. 2, Fig. 2 describes a process of registration, joining a multicast group, and forwarding data, wherein SN1 and SN2 are assumed to be connected to SGW1 , and SN3 is assumed to be connected to SGW2.

Fig. 2 shows a process of registration, joining a multicast group, and forwarding data.

First, in step S21 (including S21 a, S21 b, and S21 c) and step S22 (including S22a, S22b, and S22c), when an SN is initiated and connected to the Internet for the first time, it registers with an SGW, and the SGW and UC perform registration of the SN. During the registration, the SGW records the sensor node ID of the SN and its location information (which SGW the SN is associated with). Further, the SGW is configured with a multicast group into which the SN is interested by a USN operator according to some predetermined policies. For example, upon registration, SGW1 records the sensor node ID (sensor node ID1 ) of SN 1 and the multicast group of interest (G1 ), and the sensor node ID (sensor node ID2) of SN2 and the multicast group of interest (G1 ); SGW2 records the sensor node ID (sensor node ID3) of SN3 and the multicast group of interest (G2). The UC records those sensor node IDs and location information of SN 1 , SN2, and SN3, for example, SN1 and SN2 are under SGW1 , and SN3 is under SGW2. Registration of SN may use an existing device management protocol, for example, the Open Mobile Alliance-Device Management (OMA-DM), which is known to those skilled in the art. Besides, because SN 1 , SN2, and SN3 are different entities, their registrations with their respective SGWs and the UC have no clear order.

When an SN is initiated for the first time, an SGW is configured with a multicast group of interest of the SN by a USN operator. Upon registration, the SGW obtains the SN's sensor node ID and multicast group of interest into which the SN is interested. Next, in step S23 (including S23a and S23b), the SGW detects multicast members, i .e., whether all SNs under it belong to a same multicast group. Then, in step S24, based on the result of the detection of multicast members, the SGW aggregates the multicast members and joins the UC on behalf of the SNs. For example, when SGW1 detects that SN1 and SN2 belong to a multicast group (G1 ), in step S24a, it aggregates SN1 and SN2 to join the UC, wherein the source address is the address (S1 ) of SGW1 . For another example, through detecting multicast members in step S23b, SGW2 detects that SN3 belongs to a multicast group (G2), then in step S24b, SGW2 joins the UC on behalf of SN3 (the source address is the address (S2) of SGW2).

When receiving an aggregate joining message from an SGW, in step S25, the UC establishes a binding cache entry to record location information of an SN and multicast group of its interest. This binding cache entry indicates sensor node ID of the SN, the associated SGW, and the multicast group of interest.

As a designated multicast router, the UC will join a multicast routing architecture (multicast transmission tree) based on the multicast group into which the SN is interested and the associated SGW. Correspondingly, in step S26 (S26a and S26b), the UC will establish an appropriate multicast forwarding state in its interface.

After multicast data traffic arrives at the UC, the UC forwards the multicast data traffic based on the multicast forwarding state in the binding cache entry. For example, the multicast data traffic of G1 will be forwarded to SGW1 , and the multicast data traffic of G2 will be forwarded to SGW2, as shown in steps S27a and S27b in Fig. 2, respectively. The binding cache entry is shown in Fig. 4.

In step S28, at an SGW, the multicast data traffic from the UC will arrive at an interface assigned to a set of access links. Because currently most SNs do not support multicast, the SGW will forward the data traffic to the corresponding SN through unicast. For example, SGW1 forwards the data traffic to SN1 and SN2 through unicast, and SGW2 forwards the data traffic to SN3 through unicast, as shown in S28a, S28b, and S28c in Fig.2, respectively. Location Management

An SGW is responsible for detecting that an SN moves to an access link and away from the access link, and is responsible for updating its location to UC. Therefore, even if an SN moves, the SGW also maintains a multicast state, which does not need the SN to initialize to rejoin a multicast group.

Further, in a USN, the number of SNs is considerable. It may be predicted that the number of SNs under a single SGW can easily exceed hundreds, or even more. If the SGW individually updates location information and rejoins the multicast group of interest for each mobile SN, it will cause inrush of signaling traffic and increase network load. Thus, a new location management solution is needed to reduce signaling overheads.

This section describes the proposed location management process, where it is supposed that SN1 and SN2 in multicast group G1 move from SGW1 to SGW2. Fig. 3 shows a location management process in a multicast-enabled USN.

Fig. 3 immediately follows Fig. 2 in temporal sequence. As shown in Fig. 2, SN1 and SN2 originally accessed to SGW1 . When the SNs move, they will receive a beacon periodically transmitted by a SGW, wherein the beacon comprises EUI and PAN ID of the SGW. For example, SN 1 and SN2 receive a beacon from SGW2, wherein the beacon comprises the EUI and PAN ID of SGW2, as shown in S301 a and S301 b in Fig. 3, respectively.

An SN performs mobility check by comparing a PAN ID in the beacon sent from a new SGW and that from the old SGW. If the PAN ID in the beacon from the new SGW is identical to the PAN ID in the beacon from the old SGW, then the SN knows that it still moves within the same SGW. If the PAN ID in the beacon from the new SGW is different from the PAN ID in the beacon from the old SGW, then the SN knows that it has moved into the new SGW. In this embodiment, SN1 and SN2 find that the PAN IDs in the beacons from their respective old SGWs are different from those from their respective new SGWs, then SN1 and SN2 determine that they have moved into the governance of the new SGWs, as shown in S302a and S302b in Fig. 3, respectively.

When an SN determines that it has moved into a new PAN, it sends an association request message to the new SGW from which it receives the beacon. The association request message comprises sensor node ID of the SN. Besides, the association request message has a standard IEEE 802.15.4 MAC command frame format. For example, SN 1 sends an association request comprising the sensor node ID1 to SGW2, as shown in S303a in Fig. 3; SN2 sends an association request comprising the sensor node ID2 to SGW2, as shown in S303b in Fig. 3. After receiving the association request message, the new SGW responds with an association response message. The association response message has a standard I EEE 802.15.4 MAC command frame format. For example, after receiving association request messages sent from SN1 and SN2, SGW2 sends an association response message to SN1 and SN2, respectively, as shown in S304a and S304b in Fig. 3, respectively. After an SGW receives an association request message comprising a sensor node ID as sent by an SN, because the SGW has no old information of the SN, it knows that the SN is new. In this case, the SGW sends a usual first binding update message to the UC. In the first binding update message, the value of "C" tag is set to 0, and the mobility option field contains sensor node ID of the SN. For example, when SGW2 determines that SN1 is new to it, it sends a first binding update message to the UC, wherein "C" tag is set to 0, and the mobility option field contains the sensor node ID1 , as shown in S305 in Fig. 3. After receiving a binding update message from an SGW, the UC sends a first binding confirmation message to the SGW. Through querying a binding cache entry, the UC knows which multicast group the sensor node ID from the binding update message belongs to. Thus, in order to support multicast handoff and group location management, the "C" tag is set to 1 , and the mobility option field contains a multicast group address and all sensor node IDs belonging to the same multicast group in the binding confirmation message. For example, in the binding confirmation message sent from the UC to SGW2, the value of "C" tag is set to 1 , and the mobility option field contains the multicast group address G 1 related to the sensor node I D1 and complete sensor node I Ds belonging to G1 (i.e., sensor node ID 1 , sensor node ID2, sensor node ID4, sensor node ID5, and etc.), as shown in S306 in Fig. 3.

An SGW maintains a timer for group location management. When it receives an association request message from an SN, it initiates the timer. All newly associated SNs during this period of time will be considered by the SGW to be located in a same multicast group. Therefore, the SGW merely sends a binding update message to the UC, wherein the binding update message contains a sensor node ID. After receiving a binding confirmation message from the UC, the SGW knows which sensor node IDs belong to this multicast group. For example, when SGW2 receives the binding confirmation message from the UC, it knows that the sensor node ID1 and sensor node ID2 belong to G1 , as shown in S307 in Fig. 3. An SGW performs group location management for sensor node IDs belonging to a same multicast group: the SGW sends an extended binding update message to the UC, wherein the "C" tag is set to 1 , and the mobility option field contains a multicast group address and sensor node IDs of newly accessed SNs belonging to the multicast group. For sensor node IDs that do not belong to the same multicast group, the SGW performs a usual location management (to step S305). For example, when SGW2 knows that the sensor node ID1 and sensor node ID2 belong to G 1 , it sends an extended second binding update message to the UC, wherein the "C" tag is set to 1 , and the mobility option field contains G1 , sensor node ID1 , and sensor node ID2, as shown in S308 in Fig. 3.

After receiving an extended binding update message from an SGW, the UC updates its binding cache entry based on the multicast group address and the sensor node IDs in the mobility option field. For example, the UC updates its binding cache entry to ensure that the sensor node ID1 and the sensor node ID2 are under SGW2, as shown in S309 in Fig. 3. After location update, the UC sends a binding confirmation message to an SGW, wherein the "C" tag is set to 1 , and the mobility option field contains a multicast group address and related sensor node IDs. For example, after location update, the UC sends a second binding confirmation message to SGW2, wherein the "C" tag is set to 1 , and the mobility option field contains G1 , the sensor node ID1 and sensor node ID2, as shown in S310 in Fig. 3.

In order to validate the correctness of the multicast group as joined, an SGW will aggregate the multicast members and join the UC on behalf of the SNs. For example, SGW2 aggregates the sensor node ID1 and the sensor node ID2 and joins the UC, wherein the source address is the address (S2) of SGW2, as shown in S31 1 in Fig. 3.

For SNs, the UC will establish a multicast tunnel (M tunnel) for data traffic transfer between the UC and an SGW. In the tunnel multicast packet forwarded by the UC, the source address and the destination address of an inner IPv6 header (packet header) are multicast source address and multicast group address, and the source address and the destination address of an outer IPv6 header (tunnel header) are the address of the UC and the address of the SGW, respectively. For example, in the multicast packet sent from the UC to SGW2, the source address and the destination address of the inner IPv6 header (packet header) are S (multicast source address) and G1 , and the source address and the destination address of the outer IPv6 header (tunnel header) are the address of the UC and the address of SGW2, respectively, as shown in S312 in Fig. 3.

After a successful location management, the data traffic will be forwarded to a new SGW through multicast and then forwarded to an SN through unicast. For example, the data traffic of G 1 is forwarded by the UC to SGW2 through multicast and then forwarded by SGW2 to SN 1 and SN2 through unicast, respectively (because these steps are similar to steps S27 and S28 in Fig. 2, so not shown in Fig. 3).

It should be noted that the M tunnel can be dynamically established with the multicast state. It will maintain active till the last SGW ends its multicast state. Of course, the M tunnel can be pre-established during the initiation (registration) phase of the SGW. Besides, the M tunnel is SGW-based, instead of being SN-based. In other words, it is shared by all SNs accessing to the SGW.

In order to avoid or minimize the packet loss during handoff, an old SGW will buffer the multicast data packet and forwards it to a new SGW. It comprises the following procedures: The UC sends a binding update message to the old GSW which is just SGW1 in Fig. 3. In the binding update message, the value of "C" tag is set to 0, and the mobility option field contains sensor node ID of an SN and address of a new SGW. For example, the UC sends a binding update message to SGW1 , wherein the value of "C" tag is set to 0, and the mobility option field contains sensor node ID1 , sensor node ID2, and address (S2) of SGW2, as shown in S313 in Fig. 3.

After receiving the binding update message, the old SGW returns a binding confirmation message, wherein the value of "C" tag is set to 0, and the mobility option field contains sensor node ID of the SN and address of the new SGW. For example, SGW1 sends a binding confirmation message to the UC, wherein the value of "C" tag is set to 0, and the mobility option field contains sensor node ID1 , sensor node ID2, and address (S2) of SGW2, as shown in S314 in Fig. 3.

The old SGW records the address of the new SGW and establishes an SGW tunnel with the new SGW to forward the buffered multicast data, thereby avoiding or minimizing data loss. For example, SGW1 establishes a tunnel from SGW1 to SGW2 so as to forward the buffered multicast data traffic to be sent to the sensor node ID1 and the sensor node ID2, wherein the source address and destination address of the SGW tunnel are the address of SGW1 and the address of SGW2, respectively, as shown in S315 of Fig. 3. With Multicast Extended Binding Update and Binding Confirmation Message Formats.

I n order to support the proposed network-based multicast solution for a USN, the present embodiment introduces two new messages: an extended binding update message, and an extended binding confirmation message. The extended binding update message and the extended binding confirmation message are used for signaling between an SGW and a UC, as previously mentioned.

In this embodiment, the proposed extended binding update message is an extension to the proxy binding update message as defined in RFC5213. Fig. 5 shows an exemplary format of the extended binding update message. Compared with the proxy binding update message, a new "C" tag is introduced specifically for multicast extension. The remaining portions of the extended binding update message are still identical to those as defined in RFC3775. The further "R," "M," and "P" tags are defined in RFC3963, RFC4140, and RFC5213, respectively. The extended binding confirmation message is an extension to the proxy binding confirmation message as defined in RFC 5213. Fig. 6 shows a format of the extended binding confirmation message. Compared with the proxy binding confirmation message, a new "C" tag is introduced to specifically for multicast extension. The remaining portions of the extended binding confirmation message are identical to those as defined in RFC3775. The further "R" and "P" tags are defined in RFC3963 and RFC5213, respectively.

The "C" tag in the extended binding update message and extended binding confirmation message is merely for multicast extension of a USN.

When the "C" tag is not contained in the extended binding update message or extended binding confirmation message (the value of "C" tag is 0), the mobility option field is as defined in RFC3963. For the multicast-enabled USN, the mobility option domain contains a sensor node ID. In other words, C=0 indicates that the datagram is a common datagram.

When the "C" tag is contained in the extended binding update message or extended binding confirmation message (the value of "C" tag is 1 ), the mobility option field contains a multicast group address record. The multicast group address record contains a multicast group address and sensor node IDs belonging to the multicast group. In other words, C=1 indicates that the datagram is for multicast. It should be noted that the mobility option field can simultaneously contain a plurality of multicast group address records. In this case, the mobility option field format can borrow the MLD report message format as defined in RFC3810.

Fig. 7 shows block diagrams of apparatuses according to one embodiment of the present invention.

The first apparatus 10 as shown in Fig. 7 is located in a sensor network gateway, and the second apparatus 20 is located in a sensor network controller.

The first apparatus 10 comprises a first sending module 100, a first receiving module 101 , a first determining module 102, and an establishing module 103.

The second apparatus 20 comprises a second receiving module 200, a second determining module 201 , a second sending module 202, an updating module 203 and a multicast channel establishing module 204.

After receiving an association request from a sensor node governed by the sensor network gateway, the first sending module 100 send a first binding update message to the sensor network controller, wherein the first binding update message comprises an identifier of the sensor node. Then, the second receiving module 200 of the second apparatus 200 receives the first binding update message from the sensor network gateway, wherein the first binding update message comprises the identifier of the sensor node. Next, the second determining module 201 of the second apparatus 20 determines whether the sensor node is a member of a multicast group based on the identifier of the sensor node.

Then, the second sending module 202 of the second apparatus 20 sends a first binding update confirmation message to the sensor network gateway when the sensor node is a member of a multicast group, wherein the first binding update confirmation message includes indication information that indicates that the sensor node belongs to the multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group. Next, the first receiving module 101 of the first module 10 receives the first binding update confirmation message from the sensor network controller, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to the multicast group, the multicast address of the multicast group, and the identifier of each member sensor node of the multicast group.

Then, the first determining module 102 determines whether each sensor node governed by the sensor network gateway comprises a member sensor node of the multicast group based on the first binding update confirmation message. Next, the first sending module 100 sends a second binding update message to the sensor network controller if sensor nodes governed by the sensor network gateway comprises a member sensor node of the multicast group, the second binding update message comprises the multicast address of the multicast group, and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

Then, the second receiving module 200 of the second apparatus 20 further receives the second binding update message from the sensor network gateway, the second binding update message including the multicast address of the multicast group and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

Next, the updating module 203 of the second apparatus 20 updates correspondence relationship between a corresponding multicast group member sensor node and a sensor network gateway in a binding cache entry based on the second binding update message. Then, the second sending module 202 of the second apparatus 20 sends a second binding update confirmation message to the sensor network gateway, the second binding update confirmation message including the multicast address of the multicast group and the identifier of the member sensor node of the multicast group governed by the sensor network gateway. Then, the first receiving module 101 receives the second binding update confirmation message as sent from the second sending module 202 of the sensor network controller, the second binding update confirmation message including the multicast address of the multicast group and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

Next, the first sending module 100 sends a multicast joining request message to the sensor network controller, the multicast joining request message being for requesting to have the sensor network gateway join the multicast group, wherein the multicast joining request message comprises the address of the sensor network gateway, the multicast address of the multicast group, and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

The second receiving module 200 of the second apparatus 20 receives the multicast joining request message from the sensor network gateway, wherein the multicast joining request message comprises the address of the sensor network gateway, the multicast address of the multicast group, and the identifier of the member sensor node of the multicast group governed by the sensor network gateway. Then, the multicast channel establishing module 204 of the second apparatus establishes a multicast channel between the sensor network controller and the sensor network gateway based on the multicast joining request message.

Next, the second sending module 202 sends a third binding update message to the sensor network gateway, the third binding update message including an address of a target sensor network gateway and an identifier of a mobile sensor node, wherein the mobile sensor node belongs to the multicast group to indicate the sensor network gateway to send to the target sensor network gateway data destined to the mobile sensor node. Then, the first receiving module 101 receives the third binding update message from the sensor network controller, the third binding update message comprising the address of the target sensor network gateway and the identifier of the mobile sensor node, wherein the mobile sensor node belongs to the multicast group. Next, the first sending module 100 sends a third binding update confirmation message to the sensor network controller, the third binding update confirmation message comprising the address of the target sensor network gateway and the identifier of the mobile sensor node, wherein the mobile sensor node belongs to the multicast group. Then, the establishing module of the first apparatus 10 establishes a tunnel with the target sensor network gateway, for transferring data buffered in the present sensor network gateway and to be sent to the mobile sensor node. Although various embodiments of the present invention have been described in detail, it should be understood that the legal scope of the present invention is defined by the wording in the appended claims. The detailed description should be interpreted merely as illustrative, instead of exhausting each possible embodiment of the present invention, because it is impractical, even possible to exhaust each possible embodiment. By using current technologies or technologies which will be developed after the filing date of the present patent, various alternative embodiments can be implemented, which still fall within the scope of the claims of the present invention.

Although the present disclosure has described preferred embodiments, the present invention is not limited by the provided examples, but covers all contents as defined within the scope and spirit of the appended claims.

Claims

What Is Claimed Is:

1. A method of supporting multicast in a sensor network gateway, comprising the following steps:

A. after receiving an association request from a sensor node governed by the sensor network gateway, sending a first binding update message to a sensor network controller, wherein the first binding update message comprises an identifier of the sensor node;

B. receiving a first binding update confirmation message from the sensor network controller, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to a multicast group, a multicast address of the multicast group, and an identifier of each member sensor node of the multicast group;

C. determining whether each sensor node governed by the sensor network gateway comprises a member sensor node of the multicast group based on the first binding update confirmation message;

D. sending a second binding update message to the sensor network controller if sensor nodes governed by the sensor network gateway comprises a member sensor node of the multicast group, the second binding update message comprising the multicast address of the multicast group, and an identifier of the member sensor node of the multicast group governed by the sensor network gateway.

2. The method according to claim 1 , wherein after step D, the method further comprises:

E. receiving a second binding update confirmation message from the sensor network controller, wherein the second binding update confirmation message comprises the multicast address of the multicast group and the identifier of the member sensor node of the multicast group governed by the sensor network gateway;

F. sending a multicast joining request message to the sensor network controller, the multicast joining request message being for requesting to have the sensor network gateway join into the multicast group, wherein the multicast joining request message comprises an address of the sensor network gateway, the multicast address of the multicast group, and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

3. The method according to claim 1 , wherein after step F, the method further comprises:

G. receiving a third binding update message from the sensor network controller, the third binding update message comprising an address of a target sensor network gateway and an identifier of a mobile sensor node, wherein the mobile sensor node belongs to the multicast group;

H. sending a third binding update confirmation message to the sensor network controller, the third binding update confirmation message comprising the address of the target sensor network gateway and the identifier of the mobile sensor node, wherein the mobile sensor node belongs to the multicast group; I. establishing a tunnel with the target sensor network gateway, for transferring data as buffered in the present sensor network gateway and to be sent to the mobile sensor node.

4. The method according to claim 1 , wherein the second binding update message further comprises information indicating multicast, and the first binding update confirmation message further comprises information indicating multicast.

5. The method according to claim 2, wherein the second binding update confirmation message further comprises information indicating multicast.

6. A method of controlling multicast to a sensor node in a sensor network controller, comprising the following steps:

I. receiving a first binding update message from a sensor network gateway, wherein the first binding update message comprises an identifier of the sensor node;

II. determining whether the sensor node is a member of a multicast group based on the identifier of the sensor node;

III. sending a first binding update confirmation message to the sensor network gateway when the sensor node is a member of the multicast group, wherein the first binding update confirmation message comprises indication information that indicates that the sensor node belongs to the multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group.

7. The method according to claim 6, wherein after step III, the method further comprises:

IV. receiving a second binding update message from the sensor network gateway, the second binding update message including the multicast address of the multicast group and an identifier of a member sensor node of the multicast group governed by the sensor network gateway;

V. updating correspondence relationship between a corresponding multicast group member sensor node and a sensor network gateway in a binding cache entry based on the second binding update message;

VI. sending a second binding update confirmation message to the sensor network gateway, wherein the second binding update confirmation message comprises the multicast address of the multicast group and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

8. The method according to claim 7, wherein after step VI, the method further comprises:

VII. receiving a multicast joining request message from the sensor network gateway, wherein the multicast joining request message comprises an address of the sensor network gateway, the multicast address of the multicast group, and the identifier of the member sensor node of the multicast group governed by the sensor network gateway; VIII. establishing a multicast channel between the sensor network controller and the sensor network gateway based on the multicast joining request message.

9. The method according to claim 8, wherein after step VIII, the method further comprises:

- sending a third binding update message to the sensor network gateway, the third binding update message including an address of a target sensor network gateway and an identifier of a mobile sensor node, wherein the mobile sensor node belongs to the multicast group, so as to indicate the sensor network gateway to send to the target sensor network gateway data destined to the mobile sensor node.

10. A first apparatus for supporting multicast in a sensor network gateway, comprising:

a first sending module configured to send a first binding update message to a sensor network controller after receiving an association request from a sensor node governed by the sensor network gateway, wherein the first binding update message comprises an identifier of the sensor node;

a fist receiving module configured to receive a first binding update confirmation message from the sensor network controller, the first binding update confirmation message comprising indication information that indicates that the sensor node belongs to a multicast group, a multicast address of the multicast group, and an identifier of each member sensor node of the multicast group;

a first determining module configured to determine whether each sensor node governed by the sensor network gateway comprises a member sensor node of the multicast group based on the first binding update confirmation message;

wherein the first sending module is further configured to send a second binding update message to the sensor network controller if sensor nodes governed by the sensor network gateway comprises a member sensor node of the multicast group, the second binding update message comprises the multicast address of the multicast group, and an identifier of the member sensor node of the multicast group governed by the sensor network gateway.

1 1 . The first apparatus according to claim 1 0, wherein the first receiving module is further configured to receive a second binding update confirmation message from the sensor network controller, wherein the second binding update confirmation message comprises the multicast address of the multicast group and the identifier of the member sensor node of the multicast group governed by the sensor network gateway;

the first sending module is further configured to send a multicast joining request message to the sensor network controller, the multicast joining request message being for requesting to have the sensor network gateway join into the multicast group, wherein the multicast joining request message comprises an address of the sensor network gateway, the multicast address of the multicast group, and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

12. The first apparatus according to claim 1 1 , wherein the first receiving module is further configured to receive a third binding update message from the sensor network controller, the third binding update message comprising an address of a target sensor network gateway and an identifier of a mobile sensor node, wherein the mobile sensor node belongs to the multicast group; the first sending module is further configured to send a third binding update confirmation message to the sensor network controller, the third binding update confirmation message comprising the address of the target sensor network gateway and the identifier of the mobile sensor node, wherein the mobile sensor node belongs to the multicast group;

the first apparatus further comprises an establishing module configured to establish a tunnel with the target sensor network gateway, for transferring data as buffered in the present sensor network gateway and to be sent to the mobile sensor node.

13. A second apparatus for controlling multicast to a sensor node in a sensor network controller, comprising:

a second receiving module configured to receive a first binding update message from a sensor network gateway, wherein the first binding update message comprises an identifier of the sensor node;

a second determining module configured to determine whether the sensor node is a member of a multicast group based on the identifier of the sensor node;

a second sending module configured to send a first binding update confirmation message to the sensor network gateway when the sensor node is a member of the multicast group, wherein the first binding update confirmation message comprises indication information that indicates that the sensor node belongs to the multicast group, a multicast address of the multicast group, and an identifier of each member sensor node in the multicast group.

14. The second apparatus according to claim 13, wherein the second receiving module is further configured to receive a second binding update message from the sensor network gateway, the second binding update message including the multicast address of the multicast group and an identifier of the member sensor node of the multicast group governed by the sensor network gateway;

an updating module configured to update correspondence relationship between a corresponding multicast group member sensor node and a sensor network gateway in a binding cache entry based on the second binding update message;

wherein the second sending module is further configured to send a second binding update confirmation message to the sensor network gateway, wherein the second binding update confirmation message comprises the multicast address of the multicast group and the identifier of the member sensor node of the multicast group governed by the sensor network gateway.

15. The second apparatus according to claim 14, wherein the second receiving module is further configured to receive a multicast joining request message from the sensor network gateway, wherein the multicast joining request message comprises an address of the sensor network gateway, the multicast address of the multicast group, and the identifier of the member sensor node of the multicast group governed by the sensor network gateway;

wherein the second apparatus further comprises a multicast channel establishing module configured to establish a multicast channel between the sensor network controller and the sensor network gateway based on the multicast joining request message;

the second sending module is further configured to send a third binding update message to the sensor network gateway, the third binding update message including an address of a target sensor network gateway and an identifier of the mobile sensor node, wherein the mobile sensor node belongs to the multicast group, so as to indicate the sensor network gateway to send to the target sensor network gateway data destined to the mobile sensor node.