Patent Abstract:
A cognitive MANET system is disclosed that uses TDD (Time Division Duplexing) and TDMA MAC to maintain routes that allow delivery of adequate bandwidth for applications resulting in an efficient way of maintaining information on neighboring wireless terminals and access points by using a routing protocol that has a built in slot reservation algorithm.

Full Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    The present application claims the benefit of previously filed co-pending Provisional Patent Application, Ser. No. 61/545,940 filed Oct. 11, 2011. 
     
    
     FIELD OF THE INVENTION 
       [0002]    This invention applies to the field of cognitive radio systems and describes a cognitive MANET system that uses TDD (Time Division Duplexing) and TDMA MAC to maintain routes that allow delivery of adequate bandwidth for applications resulting in an efficient way of maintaining information on neighboring wireless terminals and access points by using a routing protocol that has a built in slot reservation algorithm. 
       BACKGROUND OF THE INVENTION 
       [0003]    A Mobile Ad-Hoc Network (MANET) is a distributed system that consists of mobile nodes that can organize in an Ad-Hoc manner. These types of networks have been historically implemented for tactical and commercial use. 
         [0004]    Recent developments in 4G and beyond technologies are helping to integrate different wireless and wired systems using Internet Protocol (IP). The IP protocol allows a core network to maintain compatibility even when transport layers evolve. The same IP based networking approach can be effectively used to create wireless networks that form when devices are in proximity. These types of networks do not necessary need infrastructure as they are created when intelligent mobile devices cooperatively create a network on their own. 
         [0005]    The traditional MANET technology can be improved by combining it with a Cognitive Radio (CR) technology. Cognitive MANET networks use cognitive radio terminals to relay traffic. These types of systems can intelligently decide on what frequencies they are operating, and can modify operating parameters dynamically. 
         [0006]    This invention describes a cognitive MANET system that uses TDD (Time Division Duplexing) and TDMA MAC. To maintain routes that allow delivery of adequate bandwidth for applications a cognitive MANET system needs an efficient way of maintaining information on neighboring wireless terminals and access points. A cognitive system can intelligently decide on what band and frequency in a band to use. The radio channel varies dynamically and terminals can suffer from interference due to hidden and exposed terminal phenomena. This problem is mitigated using a routing protocol that has a built in slot reservation algorithm. 
       BRIEF SUMMARY OF THE INVENTION 
       [0007]    This invention describes a cognitive MANET system that uses TDD (Time Division Duplexing) and TDMA MAC to maintain routes that allow delivery of adequate bandwidth for applications resulting in an efficient way of maintaining information on neighboring wireless terminals and access points by using a routing protocol that has a built in slot reservation algorithm. 
         [0008]    For a fuller understanding of the nature and objects of the invention, reference should be made to the following detailed description taken in connection with the accompanying drawings. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0009]    For a fuller understanding of the nature and objects of the invention, reference should be made to the accompanying drawings, in which: 
           [0010]      FIG. 1  is a diagram showing the super-frame structure. 
           [0011]      FIG. 2  is a diagram showing devices communicating. 
           [0012]      FIG. 3  is a diagram showing a system topography. 
           [0013]      FIG. 4  is a diagram showing possible frame allocation. 
           [0014]      FIG. 5  is a diagram showing another system topography. 
           [0015]      FIG. 6  is a diagram showing possible frame allocation. 
           [0016]      FIG. 7  is a diagram showing an Ad-Hoc network. 
           [0017]      FIG. 8  is a diagram showing an Ad-Hoc network route request. 
           [0018]      FIG. 9  is a diagram showing an Ad-Hoc network route request. 
           [0019]      FIG. 10  is a diagram showing a system topography with a route break. 
           [0020]      FIG. 11  is a diagram showing a system topography with a route break. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0021]    An xMax Network is a rapidly deployable communication network that allows the network to provide wireless voice and broadband data services to their subscribers/end-users. The overall network architecture is similar to a typical cellular network, however, it is also flexible enough to provide both a smaller footprint and network coverage as well as agile enough to provide Mobile Ad-Hoc Networking. 
         [0022]    The network is comprised of the following network elements:
       Mobile Switching Center (xMSC)—Core Network that acts as the gateway to the Public Internet.   Base Stations (BSN) or Access Points (AP)—Bridges the wireless network to the Core Network.   xMax Modems (xMod)—Mobile devices that the End-Users use to connect their smart phones or other computing devices to the xMax network via a Wi-Fi or other industry standard interface.       
 
         [0026]    The terminology in this document loosely follows the terminology used in AODV routing proposal, RFC 3561 [Perkins, et. al. July 2003] as follows: 
         [0027]    Active route. A route towards a destination that has a routing table entry that is marked as valid. Only active routes can be used to forward data packets. 
         [0028]    Broadcast. Broadcasting means transmitting to the broadcast MAC address, FF:FF:FF:FF:FF. A broadcast packet may not be blindly forwarded, but broadcasting is useful to enable dissemination of AODV messages throughout the ad hoc network. 
         [0029]    Destination. A MAC address to which data packets are to be transmitted. Same as “destination node”. A node knows it is the destination node for a typical data packet when its address appears in the appropriate field of the MAC header. Routes for destination nodes are supplied by action of the AODV protocol, which carries the MAC address of the desired destination node in route discovery messages. 
         [0030]    Forwarding node. A node that agrees to forward packets destined for another node, by retransmitting them to a next hop that is closer to the unicast destination along a path that has been set up using routing control messages. 
         [0031]    Forward route. A route set up to send data packets from a node originating a Route Discovery operation towards its desired destination. 
         [0032]    Invalid route. A route that has expired, denoted by a state of invalid in the routing table entry. An invalid route is used to store previously valid route information for an extended period of time. An invalid route cannot be used to forward data packets, but it can provide information useful for route repairs, and also for future RREQ messages. 
         [0033]    Originating node. A node that initiates an AODV route discovery message to be processed and possibly retransmitted by other nodes in the ad hoc network. For instance, the node initiating a Route Discovery process and broadcasting the RREQ message is called the originating node of the RREQ message. 
         [0034]    Reverse route. A route set up to forward a reply (RREP) packet back to the originator from the destination or from an intermediate node having a route to the destination. 
         [0035]    Sequence number. A monotonically increasing number maintained by each originating node. In AODV routing protocol messages it is used by other nodes to determine the freshness of the information contained from the originating node. 
         [0036]    Valid route. See active route. 
         [0037]    To create an Ad-Hoc network mobile terminal devices have to be able to exchange data directly with each other. To do this mobile terminals and infrastructure devices (APs) need to be able to dynamically discover each other and dynamically establish links that can be used for data transfer. Typically Ad-Hoc networking protocols are symmetric, i.e. terminals appear similar to any other device in a network. For example, CSMA/CA MAC protocol that is used in 802.11a/b/g/n allows any device to reserve a channel thus making it straightforward to add Ad-Hoc networking on it. 
         [0038]    The rigid coordination of TDD MAC makes TDD Ad-Hoc networking challenging because the network consists of master and slave devices, i.e. base station type devices that control the channel access and slave devices that operate according to scheduling instructions established by the base station devices. The Ad-Hoc protocol of this disclosure (xMax Ad-Hoc protocol) solves the problem by creating a super frame consisting of two frame times, allowing symmetric configuration, i.e. each device can be both master and slave. Additionally each of the frame times can communicate on different channels thus increasing network capacity. In CSMA systems the use of different channels is complicated due to the uncoordinated nature of the network, i.e. devices cannot tune to different channels because they do not know ahead of time when a data packet can be transmitted to them. 
         [0039]    The TDD Ad-Hoc networking protocol can be divided into three major parts; the routing engine, neighbor discovery, and the frame and slot allocation system. The routing engine is based on AODV while neighbor discovery, frame and slot allocation methods are unique to the disclosed system. 
         [0040]    The switching (“L2 routing”) is based on Ad-Hoc On-Demand Distance Vector (AODV) due to its scalability. This protocol is described, for example, in RFC 3561 [Perkins, et. al. July 2003]. 
         [0041]    Routing protocols can be classified depending on the way routes are discovered and also depending on when routes are discovered. For example, link state and distance vector based algorithms use different algorithms to find routes. Additionally algorithms can be divided to proactive and on-demand (reactive) algorithms. Proactive algorithms establish routes before they are needed while reactive (on-demand) algorithms establish routes when they are needed. 
         [0042]    Route discovery is based on query and reply cycles. Route information is stored in all intermediate nodes along the route in the form of route table entries. AODV uses many control packets, including a routing request message (RREQ) that is broadcast by a node requiring a route to another node, and a routing reply message (RREP) that is sent back to the source of RREQ. A route error message (RERR) is sent to notify other nodes of the loss of the link. 
         [0043]    AODV is reactive, i.e. when a source node needs a route to a destination for which it does not have a route it transmits a RREQ (Route Request) across the network. Nodes receiving this packet update their information for the source node and set up a backward index to the source node in the routing table. A node that receives a RREQ sends a RREP (Route Reply) if it is the destination or if it has a route with a greater sequence number to the destination. Otherwise the node retransmits the RREQ. The sequence number scheme is critical in making sure that routing loops are not created. 
         [0044]    The framing protocol structure of this disclosure adds a concept of framing and channelization to the routing algorithm. Route request and reply messages have additional fields for frame type and channel information that is used by nodes to allocate TDD frames and to select channels. A node can be master or slave, i.e. coordinate or be coordinated regarding time slot allocations. A node that is a master coordinates channel access over an area that can be determined based on range of hello messages received. For this reason TDD information in the system is processed for two hops, i.e. previous and next nodes. 
         [0045]    The routing table contains the following information: 
         [0046]    Destination MAC address; 
         [0047]    Next hop MAC address; 
         [0048]    TDD framing, channel information for destination; 
         [0049]    Number of hops; 
         [0050]    Destination sequence number; 
         [0051]    Active neighbors for this route; 
         [0052]    Expiration time for this route table entry; and, 
         [0053]    List of precursor nodes for each Destination. 
         [0054]    The neighbor table contains: 
         [0055]    Neighbor MAC address; 
         [0056]    RF channel; 
         [0057]    TDD framing information, channel information; and, 
         [0058]    Metric (available capacity based on neighbors using same master). 
         [0059]    When a route is not available for the destination, a route request message (RREQ) is sent using an expanding ring technique throughout the network. The message contains an additional TDD info field for frame timing and available channels at the request node. The list is ordered so that the first element proposes the most desired frame timing, i.e. master/slave mode, most desirable channel followed by potential master/slave and channel combinations. At a minimum the TDD info contains at least one element when sent by an original requestor and a minimum of two elements when forwarded, i.e. one for the node forwarding and one for the hop before. 
         [0060]    The TDD info is: 
         [0061]    Element 1: Master/slave information, frame type ( 1 , 2 ), Desired channel. 
         [0062]    Element 2: Master/slave information, frame type ( 1 , 2 ), Desired channel. 
         [0063]    Element 3 prey: Master/slave information, frame type ( 1 , 2 ), Desired channel for ONE HOP earlier. 
         [0064]    Element 4 prey: Master/slave information, frame type ( 1 , 2 ), Desired channel for ONE HOP earlier. 
         [0065]    If a node is the destination, or has a valid route to the destination, it unicasts a route reply message (RREP) back to the source. This message has an additional TDD info that contains a list of possible Master/slave information of frame type ( 1 ,  2 ) and desired channel combinations for the node that forwarded the message back. This may or may not be the same as the destination node. 
         [0066]    Hello messages are used to detect neighboring nodes. These messages are transmitted using a random interval and slot in a frame that is not used by the frame for any other purpose. Any device that is not transmitting a hello packet on that frame shall be listening for hello messages from other devices. Note: the preferred embodiment frame uses a special slot (last CBT in xMax frame) for transmitting and receiving hello slots. The Hello message has a GPS flag for assisting with network synchronization. When a device is locked to a GPS timing source beacon hello messages set the GSP flag to ‘1’. A HELLO message may contain TDD information. For example if a node is a slave and does not use frame for master operation it may add this with a list of channels that are not used in its neighborhood. 
         [0067]    In a TDD system a device discovers neighbors by listening for super frame beacons. After finding a master a device transmits BEACON messages by periodically using random access slots as defined in the physical layer. If a device cannot find any beacons on a channel then it can become a master and start transmitting beacons on that channel. 
         [0068]    When device is slave and is connected to a master it can request a “proxy hello” from a master, i.e. list of all devices that are connected to master. Any device on this list is a potential next hop. An important part of the proxy hello message is to get information on what frequencies the devices are communicating. The list of devices with associated frequency information allows a fast method to find any beacons sent on those channels by neighboring devices. If the device is a slave then a proxy hello message can be used to trigger transmission of a beacon on a channel that is specified in the message. 
         [0069]    A SCAN message is used to inform slave devices by a master that the master is not communicating for the following N frame times. For example a device that wants to scan for beacons in a neighborhood or another channel can send a SCAN message to terminals connected to it allowing terminals to know that links did not break. 
         [0070]    A node sends a RREQ when it determines that it needs a route to a destination node and does not have one available. This can happen also if TDD frame and channel allocation needs to be changed for any reason. The TDD info field in a RREQ message contains desired frame type and channel configurations, followed by other less desired combinations in descending order. These are used by receiving nodes to compute the potential for them to relay traffic. For example, a node may indicate that it wants to be master in frame  2  on channel  3  and creates this as a first entry. Two nodes may receive a request and one node may be able to accommodate this combination without impact while the other does not. 
         [0071]    When a reverse route is created or updated the node adds its available framing and timing into TDD info list on routing reply message (RREP) and removes information from the list that is for nodes before the sender of the message. (i.e., more than 1 hop earlier). 
         [0072]    Once created, the RREP is unicast to the next hop toward the originator of the RREQ, as indicated by the route table entry for that originator. 
         [0073]    The TDD info computation is done for each available channel for next and previous hops. The channel is marked to not be used for frame  1 , 2  or either as slave or master. 
         [0074]    The allocation rules for channel, frame tuple are:
       Rule 1: Channel and frame combination cannot be used if neighbor detects traffic on it above a threshold RSSI and neighbor is not master nor slave. A typical threshold for RSSI is −62 dBm.   Rule 2: Channel and frame combination can be slave only if neighbor is a slave and node itself is not master.   Rule 3: Channel and frame combination can be slave only to neighbor N if neighbor N is master.   Rule 4: Channel and frame combination that is used by a previous node to a neighbor where neighbor is not master cannot be used. If neighbor is master then it is covered by rule 3.       
 
         [0079]    An intermediate is a node that receives messages and updates the forward route. The intermediate node also adds its available framing and timing into the TDD info list allowing the next node to compute TDD framing. 
         [0080]    Due to the TDD framework the system has to dynamically change the frame assignment to operate in an Ad-Hoc network. The disclosed super frame is divided into two 20 ms frames. During a pure infrastructure mode the super frame consists of two downlink and two uplink parts. When Ad-Hoc relaying is done the system can reconfigure the second frame with inversed operation, i.e. able to transmit when next hop device is receiving. This effectively allows a mobile terminal to become a simultaneous mobile terminal and Access Point. 
         [0081]    The super frame as shown in  FIG. 1  is 40 ms long in time and is logically divided into two 20ms segments. The smallest unit of time from a scheduling perspective is one symbol period (approx. 86 us). 
         [0082]    Nodes synchronize to either a GPS signal or to median timing of master devices they can receive. If a device is locked to a GPS signal a special GPS flag bit is set in the beacon or hello messages it transmits. When receiving the device can use the GPS bit to decide what timing information is reliable. If a device receives any messages with GPS bit set then only those messages can be used to establish timing. If no message has the GPS timing bit set then all beacon and hello messages are used for timing estimates. A node can determine connectivity by listening for packets from its set of neighbors. Whenever a node receives a Hello message from a neighbor, the node should make sure that it has an active route to the neighbor, and create one if necessary. 
         [0083]      FIG. 2  shows different types of devices communicating. A device type defines whether a device behaves as master or slave and on what part of the super frame. 
         [0084]    The system of the preferred embodiment can consist of up to four types of logical devices: Access Point, Mobile Station and type 1 or type 2 relays. Type 1 and 2 relays behave as a mobile station on one-half of the super frame (i.e. one up-down frame time) and as an AP for the second half. Type 1 has the first part as master while type 2 has the second part as master. The routing protocol has to decide the timing of the mobile station by choosing if the station is type 1 or 2 based on available neighbors and routes. 
         [0085]    The benefit of the described system is that the capacity does not degrade over a large number of hops after the first hop. The structure can handle real-time traffic; however, it does not dynamically adjust to up-down link load differences as ½ of the time is always up or down link time. The system can use multiple channels thus having high capacity when a single wide channel is not available. 
         [0086]    To find a route to a destination the system uses expanding ring search. The expanding ring search is done in two phases. When a source requires a route to a destination a RREQ is sent to the “best” AP on a channel that has the “best metric” based on throughput estimate, i.e. available unused capacity. The route request is sent only to neighbors identified based on information from HELLO and proxy HELLO messages. 
         [0087]    If an AP does not return RREP in a predetermined time the system switches to an Ad-Hoc mode. In Ad-Hoc mode devices are either type 1 or type 2 devices or APs. A device can choose which type device it is based on routing RREPs. AP type devices can operate only if there is a backhaul capability on another band or wired connection available for them. 
         [0088]      FIG. 3  illustrates a simple topology where 3 stations are communicating with a root node.  FIG. 4  shows one possible frame allocation for the topology. 
         [0089]    Another topology is shown in  FIG. 5 . One of the leaf nodes is of a different type so that it can directly communicate with the root node. 
         [0090]    Each device can choose the type of operation for each of the individual parts of the super frame. This allows the leaf nodes to communicate directly in the  FIG. 5 .  FIG. 5  shows a situation where there is a potential interference with TDD systems if the protocol does not handle channelization properly.  FIG. 6  shows one possible frame allocation for the topology. The system uses information in RREQ to choose frame and channel. For example, if node D is joining last then it sends RREQ with available channels and framing. It has both the frames  1  and  2  available and can be slave on CH 1  based on receiving HELLO messages from the neighborhood. 
         [0091]    For neighbor discovery a special slot can be introduced into the xMax frame. This slot allows terminals and access points to transmit special HELLO messages. 
         [0092]    Hello messages are transmitted periodically using a random interval, typically 100-500 ms. Stations transmit messages, and, when not transmitting during a specific frame, then receive. The neighbor table is populated based on received messages. 
         [0093]    The routing system shall always choose a route from equivalent routes that minimizes the amount of frame timing changes or allocations. If the throughput requirement is not met then the system shall send a route request with bandwidth flag B set to try to allocate a route using another channel or frame timing. 
         [0094]      FIG. 7  illustrates an AD-Hoc network with  5  nodes and  2  available channels. Node C needs a route to node A. Node C has detected HELLO from node D and B but cannot receive HELLO from any other node. 
         [0095]    Node C neighbor table contain the following information:
   B CH 2 , slave  1 , frame  2  not used   D CH 1 , master  1 , frame  2  not used   
 
         [0098]    Node C fills the route request TDD info field with possible channels,
   CH 1  frame  1     CH 2  frame  1     
 
         [0101]    Node C tunes to CH 1  and synchronizes with D and sends RREQ. It then sends a WAIT message with N large enough so that it can send another RREQ to B without waiting for RREP from D. Node C sends another RREQ to node B in a HELLO slot and waits until it gets a RREP. 
         [0102]    As shown in  FIGS. 8 and 9  the important difference in accessing B and D is that there is more capacity to access D as it is master while B, that is slave, can only use Hello slots. This also explains why RREQ has to contain complete MAC addresses as Hello slots contain broadcast messages only. Node C learns frame timing from node B as it detects HELLO messages from B. 
         [0103]    The RREP from node B contains: 
         [0000]    
       
         
               
               
               
               
               
               
               
               
             
           
               
                   
               
             
             
               
                 Type 
                 Flags 
                 Source 
                 Destina- 
                 Destination 
                 Hop 
                 Life 
                 TDD 
               
               
                 2 
                   
                 MAC 
                 tion MAC 
                 sequence 
                 count 
                 time 
                 info 
               
               
                   
                   
                 address 
                 address 
                 number 
               
               
                   
               
             
          
         
       
       
         Source MAC: B 
         Destination MAC: C 
         Hop count:  2   
         TDD info: CH 1  frame  1  traffic, CH 1  frame  2  not used, CH 2  frame  2  not used, CH 2  frame  1  slave 
         TDD prey info: CH 1  frame  1  traffic, CH 1  frame  2  not used, CH 2  frame  1  master, CH 2  frame  2  not used 
       
     
         [0109]    The message indicates that one frame in two channels were available in the previous hop and is also available for the next hop. Node C accesses node D and receives the following RREP:
   Source MAC: D   Destination MAC: C   Hop count:  2     TDD info: CH 1  frame  1  traffic, CH 1  frame  2  not used, CH 2  frame  1  not used, CH 2  frame  2  not used   TDD prey info: CH 1  frame  1  slave, CH 1  frame  2  not used, CH 2  frame  1  slave, CH 2  frame  2  not used.   
 
         [0115]    The RREP message from node D indicates that node D has no information about node B because it has not received HELLO or beacons from B. 
         [0116]    Node C can now compute next hop for the route by first combining the messages per channel and applying the following rules:
       Rule 1: Channel and frame combination cannot be used if neighbor detects traffic on it above a threshold RSSI and neighbor is not master nor slave. Rule 2: Channel and frame combination can be slave only if neighbor is slave and node itself is not master.   Rule 3: Channel and frame combination can be slave only to neighbor N if neighbor N is master.   Rule 4: Channel and frame combination that is used by a previous node to a neighbor where neighbor is not master cannot be used. If neighbor is master then it is covered by rule 3.       
 
         [0120]    Process node B info first:
       CH 1  frame  1 : Neighbor B detects traffic, cannot be used. (Rule 1).   CH 1  frame  2 : Not used by B, No traffic Detected. Can be used.   CH 2  frame  1 : Node B is slave, C can be only slave in CH 2  frame  1  if it is not master on it already. (Rule 2).   CH 2  frame  2 : Not used by B, No traffic detected. Can be used.       
 
         [0125]    Process node D:
       CH 1  frame  1 : Neighbor D is master. Can be slave only to D. (Rule 3).   CH 1  frame  2 : Not used by D, No traffic detected: Can be used.   CH 2  frame  1 : Previous node to D is slave, cannot be used. (Rule 4).   CH 2  frame  2 : Not used by B, No traffic detected. Can be used.       
 
         [0130]    The optimum route would be either through B or D. The algorithm shall first create a link with minimum changes to frame allocation, which in this case is to route through D. This preserves the connectivity. Combining information the node C can choose channel and framing combinations:
       CH 1  frame  1 : Node C can be slave only to communicate with D.   CH 1  frame  2 : Node C can be slave or master.   CH 2  frame  1 : Node C cannot be used.   CH 2  frame  2 : Node C can be slave or master.       
 
         [0135]    A topology of an Ad-Hoc network can change when a node becomes inaccessible or a new “better” relay node is discovered the routing. The most time critical operation is to re-establish an active route after link breaks. In a TDD system reaction may include changing the frame configuration, RF channel, or both. 
         [0136]      FIG. 10  illustrates topology when one of the routes breaks. Letters M and S indicate master and slave frames. Node A is master on frame  1  and slave on frame  2  while node B is slave on frame  1  and master on frame  2 . Each super frame consists of two frames, i.e. frame  1  and  2 . 
         [0137]    In the figure both nodes A and E are expected to have a route to the final destination that nodes C and D want to reach. If a link between A and B breaks how does node B find a new route? 
         [0138]    After detecting a loss on node A the node B will have to inform C and D that the link is broken. After this B has to start scanning both type 1 and type 2 devices. Node B has already sent a virtual HELLO message to node A at some time while it still had link to node A and has neighbor table containing MAC addresses and RF channels and device types of all the devices node A has information about in the direct communication range. Additionally, node B has received beacons from devices in the neighborhood. The device has, however, received a beacon from node E because both are same type, i.e. are receiving and transmitting at the same time. When node B starts scanning for beacons on both frames during a super frame it will receive a beacon from E in less than 40 milliseconds and the neighbor table will get updated. To scan B has to inform C and D that it is scanning for N super frames. The node B has to send a SCAN N frames message to nodes C and D to avoid C and D to send data to B and not getting response thus detecting false link breakage. At this point the routing system will send a route request to node E because there is an entry in the neighbor table. 
         [0139]    However, the issue is that both E and B are same type and one node needs to change its type. Also, node B has frame  2  operating as master on blue channel while E is frame  2  master on red channel as illustrated in  FIG. 11 . 
         [0140]    After scanning the node B finds node E on the red channel. It can become slave on frame  2  to communicate with node E. However it was using the blue channel on frame  2  and was master on it. To solve the problem B needs to change C and D to type  1  while it can maintain communications on blue channel. 
         [0141]    The TDD info field in route request and route reply contains framing and channel information allowing nodes to choose the “best” route. 
         [0142]    In summary the following are the key aspects of this invention:
       1) A routing algorithm where each node has a routing table that contains TDD frame and channel information for all associated destinations.   2) A routing algorithm where each node has a neighbor table that contains TDD frame and channel information for all potential or used destinations.   3) A routing algorithm that uses route request message with a TDD info field that contains available frame timing and frequency channels at the requesting node. The list is ordered so that first element proposes the most desired frame timing, i.e. master/slave mode, most desirable channel followed by potential master/slave and channel combinations. At minimum the TDD info contains at least one element when sent by original requestor and minimum of two elements when forwarded, i.e. one for the node forwarding and one for the hop before.   4) A TDMA TDD framing protocol that consists of two frames where one frame can be in a master (Base station) mode while the other frame can be in a terminal or relay mode, i.e. the order of transmit and receive parts of the frame can be changed depending on the node a device is communicating with.   5) The TDMA TDD framing in 4 contains a HELLO slot where HELLO (Beacon) message is sent to detect neighboring terminals. This slot is broadcast and can use CSMA-CA or Aloha multiple access protocol.   6) A routing algorithm that uses Proxy HELLO messages. When a device is slave (i.e. the order of TDD RX and TX is the same as it would be for a terminal that communicates with a Base Station or Access Point) and when a node is associated to a master it can request a “proxy hello” from a master device. Proxy Hello is a response to a request containing a list of all the devices that are connected to the master. This allows for a reduction of search for potential neighbors, specifically when multiple channels are used by devices. Any device on this list is a potential next hop. An important part of the proxy hello message is to get information on what frequencies devices are communicating. The list of devices with associated frequency information allows a fast method to find any beacons sent on those channels by neighboring devices. If a device is only a slave then a proxy hello message can be used to trigger transmission of a beacon on a channel that is specified in the message.   7) A routing protocol that includes a message to stop link communications for a period of time. This message is called a SCAN message. The SCAN message is used to inform slave devices by a master that the master is not communicating for the following N frames or seconds. For example, a device that wants to scan for beacons in neighborhood or another channel can send a SCAN message to terminals connected to it allowing terminals to know that links did not break.   8) A routing algorithm with a Route Request Processing method that adds its available framing and timing into TDD info list and removes information from the list that is for nodes before the sender of the message. (i.e. more than 1 hop earlier).   9) A routing and slot allocation method for TDD system where TDD allocation rules for Route Reply processing are the following:
           a) The node adds its available framing and timing into TDD info list allowing the next node to compute TDD framing.   b) The TDD info computation is done for each available channel for next and previous hops.   c) The channel is marked to not be used for frame  1 ,  2 , or either as slave or master.   
               
 
         [0155]    The allocation rules for channel, frame tuple are:
       Rule 1: Channel and frame combination cannot be used if neighbor detects traffic on it above a threshold RSSI and neighbor is not master nor slave. Threshold RSSI is approx. −62 dBm.   Rule 2: Channel and frame combination can be slave only if neighbor is slave and node itself is not master.   Rule 3: Channel and frame combination can be slave only to neighbor N if neighbor N is master.   Rule 4: Channel and frame combination that is used by a previous node to a neighbor where neighbor is not master cannot be used.       
 
         [0160]    TDD frame timing and channel allocation is as follows: A node computes its framing and timing for the communication with node that is going to receive a route reply message. The node adds this information into TDD info in RREP message. There may be multiple solutions available and the node receiving RREP has to send RELAYTYPE message if the first solution on the list is not acceptable. 
         [0161]    Since certain changes may be made in the above described system and method for a cognitive TDD mobile ad-hoc network without departing from the scope of the invention herein involved, it is intended that all matter contained in the description thereof or shown in the accompanying figures shall be interpreted as illustrative and not in a limiting sense.

Technology Classification (CPC): 7