Title of Invention	A METHOD FOR INTER OR INTRA MESH FORWARDING OF A DATA FRAME
Abstract	The present invention describes a method for inter or intra mesh forwarding of a data frame. In case of intra mesh forwarding, if a transmitting node is unaware of the destination of a data frame, it forwards the data frame to its parent node as a new frame type, data-to-root-node (instead of dropping the data frame). This data frame further gets forwarded to the root node. The root node on receiving the frame checks whether the destination is within the mesh or not. In case the destination is within the mesh, the root node forwards the data frame to the destination with another new frame type, intra-mesh data frame. The destination on receiving the frame triggers on-demand routing protocol to determine the best path to the source. Once this best path has been discovered, further data frame transfers take place along this best path. However, if the transfer is inter mesh, the root on receiving the data frame sends a single multicast frame to all the MPP's (mesh portal).The MPP to which the destination is connected, triggers on-demand routing protocol to determine the best path. For subsequent transmissions, data frames are routed to the source via MPP rather than through the root node, and hence are not required to be encapsulated.

Title of Invention

A METHOD FOR INTER OR INTRA MESH FORWARDING OF A DATA FRAME

Abstract

The present invention describes a method for inter or intra mesh forwarding of a data frame. In case of intra mesh forwarding, if a transmitting node is unaware of the destination of a data frame, it forwards the data frame to its parent node as a new frame type, data-to-root-node (instead of dropping the data frame). This data frame further gets forwarded to the root node. The root node on receiving the frame checks whether the destination is within the mesh or not. In case the destination is within the mesh, the root node forwards the data frame to the destination with another new frame type, intra-mesh data frame. The destination on receiving the frame triggers on-demand routing protocol to determine the best path to the source. Once this best path has been discovered, further data frame transfers take place along this best path. However, if the transfer is inter mesh, the root on receiving the data frame sends a single multicast frame to all the MPP's (mesh portal).The MPP to which the destination is connected, triggers on-demand routing protocol to determine the best path. For subsequent transmissions, data frames are routed to the source via MPP rather than through the root node, and hence are not required to be encapsulated.

Full Text	FIELD OF THE INVENTION The present invention relates to wireless communication systems. In particular, the invention describes a method for inter or intra mesh forwarding of a data frame. More particularly the present invention relates to a method for inter or intra mesh forwarding of a data frame. DESCRIPTION OF RELATED ART The PCT application no. WO2004114690A1 describes a method to find an optimal path between two nodes in a wireless communication network. The optimal path is chosen, based on the value of a defined metric which takes number of hops, data rate between the nodes, quality of link etc. as the factors for metric calculation. The application however does not explicitly mention forwarding a data frame by a node to its parent (for the frame to be sent to root) in case the node is unaware of the destination or transmitting a single multicast frame to all MPP's instead of multiple unicast frames in case of inter mesh transfer. The application further does not explicitly state using new frame types in order to avoid encapsulation while transmitting data frames. SUMMARY OF THE INVENTION The present invention relates to wireless communication systems. In particular, the invention describes a method for inter or intra mesh forwarding of a data frame. In case of intra mesh forwarding, if a transmitting node is unaware of the destination of a data frame, it forwards the data frame to its parent node as a new frame type, data-to-root-node (instead of dropping the data frame).This data frame further gets forwarded to the root node. The root node on receiving the frame checks whether the destination is within the mesh or not. In case the destination is within the mesh, the root node forwards the data frame to the destination with another new frame type, intra-mesh data frame. The destination on receiving the frame triggers on-demand routing protocol to determine the best path to the source. Once this best path has been discovered, further data frame transfers take place along this best path. However, if the transfer is inter mesh, the root on receiving the data frame sends a single multicast frame to all the MPP's (mesh portal).The MPP to which the destination is connected, triggers on-demand routing protocol to determine the best path. For subsequent transmissions, data frames are routed to the source via MPP rather than through the root node, and hence are not required to be encapsulated. These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 depicts the mesh described with respect to the invention. DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. This patent proposes to use methods to avoid encapsulation of MAC frames in cases where it can be done and thus avoid processing overhead at sender and receiver of the Mac frames and better utilization of available bandwidth. Existing protocol In a mesh network when tree based routing is enabled, the nodes will send the frames with unknown destination address to the Root node with special target address set to Roots MAC address. The Root is basically a portal point with uplinks to other type of MAC or mesh network. The Root node knows entire tree. And it will have information of list of MPPs with uplinks which are part of mesh. If the destination to which the data frame is addressed does not exist with in the mesh, Root node tries to upstream the same frame. In addition the Root node floods the frame to all MPPs with uplinks in the mesh. With four addresses format also there is no way to forward this frame to the Root node, so that it will take care of re-forwarding the same. One way is to encapsulate the frame. But it has some following disadvantages. 1. Encapsulation and de-capsulation are considered to be over burden at Mac layer both for the frame size and processing requirement. In addition, it will consume lot of time if the frame is fragmented (because the encapsulation header will have to be added for every frame and the same has to be decapsulated) 2. If the destination is outside the mesh and can be reachable via one of the MPPs apart from Root, the path to reach the destination will be via Root, MPP and then to the destination. This path is to be followed for all the data frames and there is no best path finding involved. If the destination is outside the mesh, the data frame need to be encapsulated and sent to all the MPPs with uplinks, which is an overhead. Referring to Figure 1: • Once the topology converges, every node in the mesh knows the path to A, the Root node. • Suppose a data frame need to be sent to E from D, D can send the data-to-root frame with actual destination set to A, the immediate next hop to reach Root from D is C (which is set in addr2 in the MAC header). When the frame reaches C, C initially looks at addr3 which is E directly reachable can send frame directly to E, which can not be done if the frame is encapsulated. Even if a special target address field is used it will add more bytes, and frame will differ from normal data frame. • Suppose the data frame need to be sent to G which is out side mesh, the same data-to-root frame type will set and sent to C from D. C on checking addr3, should verify if the frame is data-to-root and then pass it to B who is next hop to reach Root node. Root also will not have any information about G, So it encapsulates and sends the frame to all MPPs in the mesh. In the above scenario it is only F. F on receiving this frame can trigger on demand routing protocol on behalf G. From then, the data frames from D to G take the D-C-F-G instead of D-C-B-A-F-G. 1) Main Inventive Concept 1. Introducing new frame types to avoid encapsulation while sending frames to the Root node. 2. Introducing the way to find best path to reach the MPP with uplink for up-streaming the data traffic. 3. Introducing a way to avoid sending multiple encapsulated unicast frames to all MPPs. Define new frame type data-to-root-node. 1. Any mesh point if has data to send to an unknown destination will form the frame as it is, except that it will use the new frame type. In a mesh network if tree based routing is enabled, every node knows the best path to reach to the Root node. 2. In the existing mesh protocol, in any forwarding node, if it does not know the path to the destination will drop the frame. The idea here is to forward the frame to its parent if it does not know the path to the destination and the frame type is set to data-to-root-node. 3. Root node on receiving this frame, will check if the destination is present inside mesh. If so it will send the frame to the destination with one another new frame type intra-mesh-data frame. The destination on receiving this frame will trigger on-demand routing protocol to discover the best path to the source. Once the route is established through on-demand protocol, the sender uses the best path to send further data to the particular destination. Triggering on-demand protocol from MPP with uplink which has the best path to reach the destination: 1. In the case the destination is outside mesh, and reachable via one of the MPP with uplink, it is better to send the further traffic to the MPP rather than to the Root node. 2. MPP on receiving encapsulated data frame, need to trigger on-demand routing protocol to the source and discover the best path to reach source Use new frame type data-to-mpps and use new multicast ALL_MPPS Mac address: 1. Instead of sending multiple encapsulated unicast frames to the MPPs with uplinks, define all MPPs multicast address and send one multicast frame to all MPPs and set the frame type to data-to-mpps. The final destination must be set to actual destination. Encapsulation and de-capsulation are considered to be over burden at Mac layer both for the frame size and processing requirement. In addition, the overhead is more if the frame is fragmented. A new data-to-root-node data type is used instead of encapsulating data frame to Root node as said in the SEE-MESH protocol specification. If the topology building is enabled in the mesh, each and every node in the mesh knows the Root node and path to the Root. So the frames with unknown destination can be sent to the Root node by setting data-to-root-node. All the middle nodes forward this to the default Roots path. Data-to-root-node on receiving at the Root node will send it to the destination. If the destination is with in the mesh, the data type will be reset to intra-mesh-data. This will trigger the destination node to initiate on-demand route discovery to the source node. After the route discovery is done the data frames will take the best path discovered via on-demand routing protocol with data type set to default wlan-mesh-data. If the Root does not find the destination inside the mesh, the data frame will be encapsulated and sent to all MPPs. Intermesh routing, on-demand route discovery in hybrid routing: In the hybrid wireless mesh protocol, best path discovery will be initiated by destination node to the source, if both them are located in the same mesh. This route discovery will be initiated by the Root node by setting intra mesh flag in the data frame specifying that the source is with in the mesh. The destination node will trigger AODV and discover the best path. But in case of inter-mesh data forwarding, Root node can not set intra mesh flag. In this case, Root will encapsulate the data frame and flood to all MPPs. The idea here is to initiate on-demand route discovery on seeing this encapsulated frame. So that further frames need not traverse through the Root node and need not be encapsulated. If the data is to be transmitted through the mesh, the source can be attached to one another MPP with uplink. As the MPP to whos uplink the destination is attached sends the RREQ, source MPP to which the source node is connected will reply with RREP. So that the best path though mesh will be discovered between source and destinations. Avoid Encapsulation in MESH MAC protocol through multicast MPPs address. The flooding to all mpps need to be done one by one by scrolling through the list captured during portal announcements. Instead, a "all Mesh MPPs" multi cast mac address can be reserved and the same can be used for flooding, any MP receiving this frame must simply re-forward this frame, MPP should process the frame along with re-forwarding. This will first reduce the network congestion by reducing multiple unicast traffic and secondly at the source node or Root node it need not be encapsulated and yet the same time need not de-capsulated at the destination. Only that immediate hop needs to be addressed to ALL-MESH-MPPs address. Advantages: 1. If the frame is not encapsulated, Any forwarding node, if it finds the destination to be directly connected child can forward the frame directly to the destination. 2. By triggering on-demand protocol at MPP through which the destination can be reachable in a better path, The frame can be directly sent to the MPP, instead of traversing on the tree to the Root, and get encapsulated for sending to multiple MPP's with uplinks in the mesh. 3. By adding new frame type data-to-mpps, and using multicast address for sending the frame to all MPP's in the mesh, can avoid encapsulation over head at sending node, and no decapsulation at the receiving node. The MPP receiving this frame can trigger on-demand routing protocol for discovering the best path as proposed in the (2). This will avoid encapsulation for multiple times. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from. GLOSSARY OF TERMS AND DEFINITIONS THEREOF WLAN Mesh: A WLAN Mesh is an IEEE 802.11-based WDS which is part of a DS, consisting of a set of two or more Mesh Points interconnected via IEEE 802.11 links and communicating via the WLAN Mesh Services. A WLAN Mesh may support zero or more entry points (Mesh Portals), automatic topology learning and dynamic path selection (including across multiple hops). Mesh Point (MP): Any IEEE 802.11 entity that contains an IEEE 802.11-conformant Medium Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM), that is within a WLAN Mesh, and that supports WLAN Mesh Services. Mesh Portal (MPP): A point at which MSDUs exit and enter a WLAN Mesh to and from other parts of a DS or to and from a non-802.11 network. A Mesh Portal can be collocated with an IEEE 802.11 portal. We Claim 1. A method for inter or intra mesh forwarding of a data frame wherein the said method involves introducing new frame types to avoid encapsulation while sending frames to the Root node and finding the best path to reach the MPP with uplink for up-streaming the data traffic and a way to avoid sending multiple encapsulated unicast frames to all MPPs. 2. A method as claimed in claim 1 wherein in intra mesh forwarding, if a transmitting node is unaware of the destination of a data frame, it forwards the data frame to its parent node as a new frame type, data-to-root-node. 3. A method as claimed in claim 2 wherein the data frame further gets forwarded to the root node where the root node on receiving the frame checks whether the destination is within the mesh or not. 4. A method as claimed in claim 3 wherein if the destination is within the mesh, the root node forwards the data frame to the destination with another new frame type, intra-mesh data frame. 5. A method as claimed in claim 4 wherein the destination on receiving the frame triggers on-demand routing protocol to determine the best path to the source and once the best path has been discovered, further data frame transfers take place along the best path. 6. A method as claimed in claim 1 wherein if the transfer is inter mesh, the root on receiving the data frame sends a single multicast frame to all the MPP's 7. A method as claimed in claim 6 wherein the MPP to which the destination is connected, triggers on-demand routing protocol to determine the best path. 8. A method as claimed in claim 7 wherein for subsequent transmissions, data frames are routed to the source via MPP. 9. A method for inter or intra mesh forwarding of a data frame substantially described particularly with reference to the accompanying drawings.

Full Text

FIELD OF THE INVENTION
The present invention relates to wireless communication systems. In particular, the invention describes a method for inter or intra mesh forwarding of a data frame. More particularly the present invention relates to a method for inter or intra mesh forwarding of a data frame.
DESCRIPTION OF RELATED ART
The PCT application no. WO2004114690A1 describes a method to find an optimal path between two nodes in a wireless communication network. The optimal path is chosen, based on the value of a defined metric which takes number of hops, data rate between the nodes, quality of link etc. as the factors for metric calculation. The application however does not explicitly mention forwarding a data frame by a node to its parent (for the frame to be sent to root) in case the node is unaware of the destination or transmitting a single multicast frame to all MPP's instead of multiple unicast frames in case of inter mesh transfer. The application further does not explicitly state using new frame types in order to avoid encapsulation while transmitting data frames.
SUMMARY OF THE INVENTION
The present invention relates to wireless communication systems. In particular, the invention describes a method for inter or intra mesh forwarding of a data

frame. In case of intra mesh forwarding, if a transmitting node is unaware of the destination of a data frame, it forwards the data frame to its parent node as a new frame type, data-to-root-node (instead of dropping the data frame).This data frame further gets forwarded to the root node. The root node on receiving the frame checks whether the destination is within the mesh or not. In case the destination is within the mesh, the root node forwards the data frame to the destination with another new frame type, intra-mesh data frame. The destination on receiving the frame triggers on-demand routing protocol to determine the best path to the source. Once this best path has been discovered, further data frame transfers take place along this best path. However, if the transfer is inter mesh, the root on receiving the data frame sends a single multicast frame to all the MPP's (mesh portal).The MPP to which the destination is connected, triggers on-demand routing protocol to determine the best path. For subsequent transmissions, data frames are routed to the source via MPP rather than through the root node, and hence are not required to be encapsulated.
These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 depicts the mesh described with respect to the invention.

DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
This patent proposes to use methods to avoid encapsulation of MAC frames in cases where it can be done and thus avoid processing overhead at sender and receiver of the Mac frames and better utilization of available bandwidth.
Existing protocol
In a mesh network when tree based routing is enabled, the nodes will send the frames with unknown destination address to the Root node with special target address set to Roots MAC address. The Root is basically a portal point with uplinks to other type of MAC or mesh network.

The Root node knows entire tree. And it will have information of list of MPPs with uplinks which are part of mesh.
If the destination to which the data frame is addressed does not exist with in
the mesh, Root node tries to upstream the same frame.
In addition the Root node floods the frame to all MPPs with uplinks in the
mesh.
With four addresses format also there is no way to forward this frame to the Root node, so that it will take care of re-forwarding the same. One way is to encapsulate the frame. But it has some following disadvantages.
1. Encapsulation and de-capsulation are considered to be over burden at Mac layer both for the frame size and processing requirement. In addition, it will consume lot of time if the frame is fragmented (because the encapsulation header will have to be added for every frame and the same has to be decapsulated)
2. If the destination is outside the mesh and can be reachable via one of the MPPs apart from Root, the path to reach the destination will be via Root, MPP and then to the destination. This path is to be followed for all the data frames and there is no best path finding involved. If the destination is outside the mesh, the data frame need to be encapsulated and sent to all the MPPs with uplinks, which is an overhead.
Referring to Figure 1:

• Once the topology converges, every node in the mesh knows the path to A, the Root node.
• Suppose a data frame need to be sent to E from D, D can send the data-to-root frame with actual destination set to A, the immediate next hop to reach Root from D is C (which is set in addr2 in the MAC header). When the frame reaches C, C initially looks at addr3 which is E directly reachable can send frame directly to E, which can not be done if the frame is encapsulated. Even if a special target address field is used it will add more bytes, and frame will differ from normal data frame.
• Suppose the data frame need to be sent to G which is out side mesh, the same data-to-root frame type will set and sent to C from D. C on checking addr3, should verify if the frame is data-to-root and then pass it to B who is next hop to reach Root node. Root also will not have any information about G, So it encapsulates and sends the frame to all MPPs in the mesh. In the above scenario it is only F. F on receiving this frame can trigger on demand routing protocol on behalf G. From then, the data frames from D to G take the D-C-F-G instead of D-C-B-A-F-G.
1) Main Inventive Concept
1. Introducing new frame types to avoid encapsulation while sending frames to the Root node.
2. Introducing the way to find best path to reach the MPP with uplink for up-streaming the data traffic.

3. Introducing a way to avoid sending multiple encapsulated unicast frames to all MPPs.
Define new frame type data-to-root-node.
1. Any mesh point if has data to send to an unknown destination will form the frame as it is, except that it will use the new frame type. In a mesh network if tree based routing is enabled, every node knows the best path to reach to the Root node.
2. In the existing mesh protocol, in any forwarding node, if it does not know the path to the destination will drop the frame. The idea here is to forward the frame to its parent if it does not know the path to the destination and the frame type is set to data-to-root-node.
3. Root node on receiving this frame, will check if the destination is present inside mesh. If so it will send the frame to the destination with one another new frame type intra-mesh-data frame. The destination on receiving this frame will trigger on-demand routing protocol to discover the best path to the source. Once the route is established through on-demand protocol, the sender uses the best path to send further data to the particular destination.
Triggering on-demand protocol from MPP with uplink which has the best path to reach the destination:

1. In the case the destination is outside mesh, and reachable via one of the MPP with uplink, it is better to send the further traffic to the MPP rather than to the Root node.
2. MPP on receiving encapsulated data frame, need to trigger on-demand routing protocol to the source and discover the best path to reach source
Use new frame type data-to-mpps and use new multicast ALL_MPPS Mac address:
1. Instead of sending multiple encapsulated unicast frames to the MPPs with uplinks, define all MPPs multicast address and send one multicast frame to all MPPs and set the frame type to data-to-mpps. The final destination must be set to actual destination. Encapsulation and de-capsulation are considered to be over burden at Mac layer both for the frame size and processing requirement. In addition, the overhead is more if the frame is fragmented. A new data-to-root-node data type is used instead of encapsulating data frame to Root node as said in the SEE-MESH protocol specification. If the topology building is enabled in the mesh, each and every node in the mesh knows the Root node and path to the Root. So the frames with unknown destination can be sent to the Root node by setting data-to-root-node. All the middle nodes forward this to the default Roots path. Data-to-root-node on receiving at the Root node will send it to the destination. If the destination is with in the mesh, the data type will be reset to intra-mesh-data.

This will trigger the destination node to initiate on-demand route discovery to the source node. After the route discovery is done the data frames will take the best path discovered via on-demand routing protocol with data type set to default wlan-mesh-data. If the Root does not find the destination inside the mesh, the data frame will be encapsulated and sent to all MPPs.
Intermesh routing, on-demand route discovery in hybrid routing:
In the hybrid wireless mesh protocol, best path discovery will be initiated by destination node to the source, if both them are located in the same mesh. This route discovery will be initiated by the Root node by setting intra mesh flag in the data frame specifying that the source is with in the mesh. The destination node will trigger AODV and discover the best path. But in case of inter-mesh data forwarding, Root node can not set intra mesh flag. In this case, Root will encapsulate the data frame and flood to all MPPs. The idea here is to initiate on-demand route discovery on seeing this encapsulated frame. So that further frames need not traverse through the Root node and need not be encapsulated. If the data is to be transmitted through the mesh, the source can be attached to one another MPP with uplink. As the MPP to whos uplink the destination is attached sends the RREQ, source MPP to which the source node is connected will reply with RREP. So that the best path though mesh will be discovered between source and destinations.
Avoid Encapsulation in MESH MAC protocol through multicast MPPs address.

The flooding to all mpps need to be done one by one by scrolling through the list captured during portal announcements. Instead, a "all Mesh MPPs" multi cast mac address can be reserved and the same can be used for flooding, any MP receiving this frame must simply re-forward this frame, MPP should process the frame along with re-forwarding. This will first reduce the network congestion by reducing multiple unicast traffic and secondly at the source node or Root node it need not be encapsulated and yet the same time need not de-capsulated at the destination. Only that immediate hop needs to be addressed to ALL-MESH-MPPs address.
Advantages:
1. If the frame is not encapsulated, Any forwarding node, if it finds the destination to be directly connected child can forward the frame directly to the destination.
2. By triggering on-demand protocol at MPP through which the destination can be reachable in a better path, The frame can be directly sent to the MPP, instead of traversing on the tree to the Root, and get encapsulated for sending to multiple MPP's with uplinks in the mesh.
3. By adding new frame type data-to-mpps, and using multicast address for sending the frame to all MPP's in the mesh, can avoid encapsulation over head at sending node, and no decapsulation at the receiving node. The MPP receiving this frame can trigger on-demand routing protocol

for discovering the best path as proposed in the (2). This will avoid encapsulation for multiple times.
It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device.
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from.

GLOSSARY OF TERMS AND DEFINITIONS THEREOF
WLAN Mesh: A WLAN Mesh is an IEEE 802.11-based WDS which is part of a DS, consisting of a set of two or more Mesh Points interconnected via IEEE 802.11 links and communicating via the WLAN Mesh Services. A WLAN Mesh may support zero or more entry points (Mesh Portals), automatic topology learning and dynamic path selection (including across multiple hops).
Mesh Point (MP): Any IEEE 802.11 entity that contains an IEEE 802.11-conformant Medium Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM), that is within a WLAN Mesh, and that supports WLAN Mesh Services.
Mesh Portal (MPP): A point at which MSDUs exit and enter a WLAN Mesh to and from other parts of a DS or to and from a non-802.11 network. A Mesh Portal can be collocated with an IEEE 802.11 portal.

We Claim
1. A method for inter or intra mesh forwarding of a data frame wherein the said method involves introducing new frame types to avoid encapsulation while sending frames to the Root node and finding the best path to reach the MPP with uplink for up-streaming the data traffic and a way to avoid sending multiple encapsulated unicast frames to all MPPs.
2. A method as claimed in claim 1 wherein in intra mesh forwarding, if a transmitting node is unaware of the destination of a data frame, it forwards the data frame to its parent node as a new frame type, data-to-root-node.
3. A method as claimed in claim 2 wherein the data frame further gets forwarded to the root node where the root node on receiving the frame checks whether the destination is within the mesh or not.
4. A method as claimed in claim 3 wherein if the destination is within the mesh, the root node forwards the data frame to the destination with another new frame type, intra-mesh data frame.
5. A method as claimed in claim 4 wherein the destination on receiving the frame triggers on-demand routing protocol to determine the best path to the source and once the best path has been discovered, further data frame transfers take place along the best path.

6. A method as claimed in claim 1 wherein if the transfer is inter mesh, the root
on receiving the data frame sends a single multicast frame to all the MPP's
7. A method as claimed in claim 6 wherein the MPP to which the destination is
connected, triggers on-demand routing protocol to determine the best path.
8. A method as claimed in claim 7 wherein for subsequent transmissions, data
frames are routed to the source via MPP.
9. A method for inter or intra mesh forwarding of a data frame substantially
described particularly with reference to the accompanying drawings.

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=juPn7tahTyGAYogZW8CnVQ==&loc=egcICQiyoj82NGgGrC5ChA==

« Previous Patent

Next Patent »

Patent Number

272290

Indian Patent Application Number

2235/CHE/2007

PG Journal Number

14/2016

Publication Date

01-Apr-2016

Grant Date

29-Mar-2016

Date of Filing

04-Oct-2007

Name of Patentee

SAMSUNG R&D INSTITUTE INDIA-BANGALORE PRIVATE LIMITED

Applicant Address

#2870 ORION BUILDING BAGMANE CONSTELLATION BUSINESS PARK OUTER RING ROAD DODDANEKUNDI CIRCLE MARATHAHALLI POST BANGALORE 560037

Inventors:

#	Inventor's Name	Inventor's Address
1	JAYABHARATHI RACHAMADUGU	BAGMANE LAKEVIEW, BLOCK 'B'. NO. 66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE-560093, KARNATAKA , INDIA

PCT International Classification Number

H04B 7/005

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA