User Tools

Site Tools


proposal_for_routing_manager_through_the_heterogeneous_network_transports

Proposal for Routing Manager through the heterogeneous network transports

This proposal is to have a seamless communication between IoTivity devices over Heterogeneous transports. The requirement is to send IoTivity messages between client and server even though they are not directly connected or on the same transport.

We are proposing to handle the requirements in two phases.
In the first phase, client and server which are reachable via single hop are handled.
In the second phase, client and server which are at multi hop distance are handled.

Phase 1) Routing Manager - Single Hop ( Message Switching )

In the current IoTivitiy design, an OIC client can discover and communicate with any resource hosted by OIC server in the same network. For Ex: OIC Client can detect light resource on an OIC server when both are in the same IP/BT/BLE network.

In the new proposal, if any Intermediary gateway device has multiple transports for ex: IP and BT networks it can forward the request and responses so that resources on different network can be discovered and communicated. This allows OIC clients to communicate with resource even though they are not in the same transport. For ex: An OIC client who is on IP network can discover a resource available on BT network if any intermediary gateway node having IP and BT network can forward the messages.

In the initial proposal, we want to make use of the existing COAP header option to intimate about the request generator and response generator without having much complex of routing mechanisms.


To achieve the functionality, we propose to add a new CoAP option with details as follows:

Option Number: 65524 (Experimental, needs expert review before using vendor-specific option number)

Option Max Data Length: 128

Option Data Format: Binary

1 byte 'len_src' bytes 1 byte 'len_dest' bytes 2 bytes
len_src source_address len_dest destination_address hop_Count

Find below a complete sequence of steps for Find resource and Unicast request.

1) Find Resource (Multicast Request, Uni-cast Response) :

   a.End device (A) sends multicast find resource with an empty "MS" option. (Empty "MS" option is added to
     notify Gateway devices to forward the request across hops). 
   b.Gateway receives the multicast packet (as its listening to all multicast in the nw).
   c.Gateway adds source address = address of End Device A in "MS" CoAP option in the received packet and sends
     modified packet as multicast to all transports except the one for incoming packet. 
   d.End device (B) receives the multicast packet on appropriate adapter and passes it to CA.
   e.CA layer parses the 'MS' CoAP option to get source address and updates the RemoteEndPoint struct with
     dest_addr = src_addr, which is address of original sender (End Device A). (Now RemoteEndPoint has 2
     addresses, one is gateway address, another is actual destination address (dest_addr).
   f.RI Layer, sends the response using CASendResponse() API with same RemoteEndPoint as it was passed in 
     step 'e' along with response info.
   g.CA Layer, makes the CoAP packet with adding "MS" CoAP option with destination address from the
     RemoteEndPoint and sends it to Gateway.
   h.Upon receiving the uni-cast response, Gateway device parse "MS" option to get destination address and
     realizes that packet is not destined for itself.
   i.Gateway devices adds the source address = address of End Device B; and sends the packet to End Device A.

2) Unicast Request :

   a.End device (A) sends unicast request with dest_addr = address of End Device B (address found using Above 
     Find Resource Procedure).
   b.Gateway receives the unicast packet and realizes that packet is not destined for itself 
    (dest_addr != GW addr).
   c.Gateway adds the source address to "MS" option in the received packet and sends modified packet as a 
     unicast to End Device (B). 
   d.End device (B) receives the unicast packet on appropriate adapter and passes it to CA.
   e.CA layer parses the "MS" option and updates the RemoteEndPoint struct with dest_addr = src_addr which 
     is address of original sender  (End Device A). 
     (Now RemoteEndPoint has 2 addresses, one is gateway address, another is actual destination address
     (dest_addr).
   f.RI Layer, sends the response using CASendResponse() API with same RemoteEndPoint as it was passed in step 
     'e' along with response info.
   g.CA Layer, makes the CoAP packet with adding destination address to "MS" option from the RemoteEndPoint and 
     sends it to Gateway.
   h.Upon receiving the uni-cast response, Gateway device reads the destination address and realizes that 
     packet is not destined for itself.
   i.Gateway devices adds the src_addr = address of End Device B; and sends the packet to End Device A.

Phase 2) Routing Manager - Multi Hop

Gateway executes following steps:

1) Create “oic/gateway” resource.

2) Search for “oic/gateway” resource over all active transports.

 >> For ex: “GW 1” sends “GET” over both IP subnets and BT.

3) Immediate neighbor gateways responds for the GET request and inform there presence to neighbors.

 >> For ex: “GW 2” and “GW 3”  responds to request by “GW 1”. While only “GW 1” responds to requests by “GW 2”
    and “GW 3”.

4) On receiving response, each gateway sends OBSERVE request to neighbor gateways.

5) On detecting a new end device, a gateway updates its routing table and send notification to neighbor gateways notifying that a device is available via it.

 >> For ex: On detecting “ED 2”,  “GW 2” sends a notification to “GW 1” which updates its routing table.

6) Gateway then forwards this information to other neighbor gateways.

 >> For ex: “GW 1” then notifies “GW 3” that “Ed 2” is reachable via me with 2 hopes.

7) Gateways can be configured to send periodic “confirmable requests” to check on the availability of neighbor nodes. On detection of a non-responsive node, the information gets propagated same way as done for “addition of new node”.

proposal_for_routing_manager_through_the_heterogeneous_network_transports.txt · Last modified: 2015/06/15 14:04 by Abhishek Sharma