KR20070023597A - Timing synchronization and beacon generation for mesh points operating in a wireless mesh network - Google Patents

Abstract

The present invention provides a method used by mesh point 115, comprising: receiving one of a beacon and a probe response from another mesh point (310, 410); Set the state regarding whether the mesh point is already synchronized with one or more peers to true (325), and beacon timing synchronization function when the mesh point is in an asynchronous state and the other mesh point requests synchronization from the peer point. Performing (335); Adding an identity of the other mesh point to a database of beacon senders maintained by the mesh point (450) and performing a beacon timing synchronization function when both the mesh point and the other mesh point are synchronized (460) ; And providing (235) the mesh point supporting synchronization, requesting synchronization from a peer mesh point and providing instructions as to whether it is already synchronized with one or more peers. will be.

Mesh Point, Beacon, and Probe Responses, Database

Description

Timing synchronization and beacon generation for mesh points operating in a wireless mesh network

1 is a system diagram illustrating an electronic device operating in a mesh cluster and an infrastructure network in accordance with some embodiments of the present invention.

2 is a flow diagram illustrating a non-AP MP beacon generation procedure in accordance with some embodiments of the present invention.

3 is a flow diagram illustrating the operation of a non-AP MP after receiving a beacon or probe response while in an asynchronous state in accordance with some embodiments of the present invention.

4 is a flow chart describing the operation of a non-AP MP after receiving a beacon or probe response while in sync.

In the filing of the present invention, the IEEE 802.11 standard defines two mechanisms for providing timing synchronization to stations. In the infrastructure operating mode, the access point (AP) is the timing master of the basic service set (BSS), and stations always accept timing synchronization information of beacons sent by the AP. However, in the Independent Basic Service Set (IBSS) mode of operation, the Timing Synchronization Function (ISF) is performed by all stations in a distributed manner, with the stations of the IBSS having any beacon or probe response with a TSF later than its own TSF timer. Adapt the timing received from the.

The variety of devices available in the mesh poses an important challenge in synchronization and beacon generation because it is difficult to perform precise classification of certain mesh devices. While wireless local area network (WLAN) meshes are expected to reuse concepts from BSS based on AP beaconing and IBSS station beaconing, they include 802.11-compliant MAC and PHY interfaces for wireless media providing mesh services. Particular attention needs to be given to devices such as a mesh point (MP), which may be a wireless device, and a mesh access point (MAP), which is an access point, which is an MP and supports BSS and mesh interface functions. Beacon collisions between packets of multiple MAPs transmitting in the presence of power saving (PS) MPs occur between the minority regions that need to be addressed.

SUMMARY OF THE INVENTION An object of the present invention is to solve the above problems and to efficiently perform timing synchronization and beacon generation for mesh points operating in a wireless mesh network.

The proposed beacon generation algorithm for mesh networking includes elements of the IEEE 802.11 standard. For example, MAP follows an infrastructure mode beacon generation algorithm. This selects the BSS parameters of the MAP itself, allows the MAP to transmit a beacon at each beacon interval, and provides the MAP with enough flexibility to prevent frequent synchronization of the MAP with other MPs. On the other hand, non-AP mesh devices follow an IBSS mode of operation for generating beacons that are synchronized with other MPs.

1 is a system diagram illustrating an electronic device operating in the mesh cluster 110 and the infrastructure network 105 in accordance with some embodiments of the present invention. MAP 130, and a number of basic service set stations (s1, ... s4), where s4 is denoted as 125, may be legacy stations (legacy stations may be referred to herein as STAs). It operates within 105. Multiple mesh devices, including MP1 115, MP2 135 and MP3 140, operate within mesh cluster 110. It will be appreciated that mesh cluster 110 and infrastructure network 105 may include substantially more connected devices than shown in FIG. 1. Conceptually, a MAP, such as MAP 130, may be considered as the root of a tree, where associated stations, such as STA 125, may be considered as branches. Non-AP MP mesh devices 115, 135, 140 (mesh points that are not access points) form their own cluster of peer to peer MPs in mesh cluster 110. Non-AP MP may be associated with one or more MAP devices. This may be seen as a tree connecting to a peer to peer cluster through a gateway MP such as MP1 115.

Embodiments of the present invention provide a method for timing synchronization and beacon generation for mesh points operating in a wireless network, described by way of example as a WLAN mesh network. A non-AP mesh point implemented in accordance with the present invention includes the following subfields: a subfield indicating whether it supports synchronization, a subfield indicating whether it requires synchronization from peer MPs, and A mesh point (MP) synchronization capability field may be sent to a beacon that includes one or more of the subfields indicating that it is already synchronized with one or more peer MPs. Non-AP MP indicates that it can be synchronized with peers by setting bits in the MP Synchronization Capability field indicating whether it supports synchronization, and also indicates that it requires synchronization from peers. If two or more non-AP MPs that support synchronization and one or more of these MPs require synchronization are associated with their peers, these MPs will be generated by synchronizing the beacons using the IBSS synchronization and beacon generation features in the IEEE 802.11 standard. will be. If neither of the MPs announce that the MPs support synchronization from peers, the MPs may implement TSF independent of each other and use the beacon generation function specified in the IEEE 802.11 standard during infrastructure mode to generate beacons. Can be generated. The MP, which allows peers that require support for PS services to be associated, can support synchronization, and the MP refuses to associate with a peer operating in PS mode if the MP does not indicate that the MP supports synchronization services. can do.

MAP Features

The MAP never switches to PS mode and must not be synchronized with other MPs. The MAP independently selects the beacon interval (BI) and transmit traffic indication map (DTIM) periods according to its BSS needs, and starts the TSF regardless of any concurrently initiated MAP. The MAP will handle any associated MP operating in the same PS mode as the legacy stations (STAs), which will cause the MP to handle the DTIM beacon of the MAP in PS operations (operations that ensure direct and broadcast traffic is timely delivered). MAP assumes that it wakes up.

Non-AP MP Features

When synchronization is enabled, non-AP MPs can be seen as simple STAs operating in IBSS mode with added mesh services. In other words, the non-AP MP selects its BI independently and can start the TSF regardless of any concurrently started MP.

It is optional for the MP to support power saving and synchronization. If the MP announces that the MP supports synchronization and requires synchronization with peers, the MP generates beacons and synchronizes with other non-AP MPs as if operating in IBSS mode as described below. In other words, an MP that announces support for synchronization but is not associated with peers that require synchronization may select its BI independently and start the TSF independently of any concurrently initiated MP.

Any MP associated with the MAP and transitioning to the PS mode must wake up the DTIM beacon of the MAP and additional beacons that the MP needs to receive based on the system interval negotiated with the MAP. If the MP is associated with more than one MAP, the MP must wake up the DTIM beacons for each MAP in addition to any mesh TBTTs that may be scheduled for synchronized MP neighbors. The MP, which allows peers requiring support for PS services to be associated, will support synchronization, and the MP may refuse to associate with the peer to operate in the PS mode if it cannot provide synchronization services.

Lightweight MP Features

One type of mesh point currently defined as a proposal for mesh networks is lightweight MP (LW-MP). The beacon generation and synchronization procedure for the LW-MP follows the IBSS mode of beacon generation and timing synchronization. If the LW-MP is associated with MAP and switched to PS mode, the LW-MP must wake up at least the DTIM beacon of the MAP in addition to any mesh TBTT for IBSS operation. Optionally, the lightweight MP may be associated with the MAP as a simple STA if it switches to the PS mode. For most purposes of this document, lightweight mesh points may be considered non-AP mesh points. The lightweight MP should send a sync capability field to the beacon indicating that it supports synchronization and also requires synchronization of its peers.

Non-AP MPs may include an MP Synchronization Capability field of the WLAN Mesh Capability element of all transmitted beacon and probe response frames indicating when it may support synchronization. The new "MP Synchronization Capability" field in the WLAN mesh capability element, Table 1, indicates that if a non-AP MP can support synchronization, if timing synchronization is required for the peer MP, and if the MP is already synchronized with another peer MP. Used to announce. It may also be included in beacons sent by non-AP MPs and in probe response messages.

field Value / Description ID T.B.D Length variable version One Active protocol ID Path selection protocol in use Active Metric ID Path Selection Metrics In Use Peer capacity Peer capacity value Power saving ability Supports power saving behavior and current power saving state Channel priority Channel procedure value Synchronization ability If synchronization is supported by these MPs

Table 1: WLAN Mesh Capability Element Fields

The format of the synchronization capability field is described in Table 2.

Bits: 0 One 2 3-7 Support sync Sync request from peer Synchronized with Peer MP reservation

Table 2-Synchronization Capability Fields

The "Sync Support" subfield indicates when the non-AP mesh point supports timing synchronization with peer MPs. The "Request Synchronization from Peer" subfield indicates when this mesh point requires non-AP MP peers that attempt to associate with it to synchronize with the Timing Synchronization Function (TSF). The “synchronized with peer MP” subfield indicates whether a non-AP MP is currently associated with another MP and whether two MPs have associated TSFs.

At a given time, the non-AP MP may operate in either of the following two states.

동기화된 상태(Synch): 이러한 Synch 상태는 MP가 적어도 하나의 피어 MP와 동기되는 상태이거나 또는 MP는 피어 MP들과의 동기를 요구하거나 또는 이들 둘다를 행한다.

Synch state: This Synch state is where the MP is in sync with at least one peer MP or the MP requires synchronization with peer MPs or both.

비동기 상태(Unsynch): MP가 어떤 피어 MP와 동기되지 않고 MP가 피어 MP들과의 동기를 요구하지 않는 경우에, MP는 UnSynch 상태에 있다.

Unsynch: If the MP is not synchronized with any peer MP and the MP does not require synchronization with peer MPs, the MP is in UnSynch state.

The operation of the UnSynch state is similar to that of the legacy AP. However, the MP can switch from a synchronous state to an asynchronous state (reversible) according to its synchronization requirements. For example, if the MP in sync has not received a beacon with a "sync request from peer" set for an extended period of time, the MP may switch itself back to an asynchronous state, indicating that it is synchronized to the peer MP indicator. Set to false This period is referred to herein as "RETURN_TO_UNSYNCH_PERIOD". The value of this period is a system parameter and is selected based on the number of MPs in the mesh, network dynamics and traffic conditions.

The timing synchronization function (TSF) keeps clocks of the non-AP MP synchronized with other MPs. TSF of non-AP MP may be implemented through a distributed algorithm. Non-AP MP in the WLAN mesh may transmit beacons according to the algorithm described herein. The non-AP MP synchronized in the WLAN mesh is from any beacon or probe response with a TSF value later than its TSF timer when its Sync Request from Peer or Synchronize with Peer MP Indicator is set to true in the Synchronization Capability field. The received timing can be adapted.

In any WLAN mesh where MPs are associated with peers, the non-AP MP may adapt the timing and may also be transmitted by MPs that are members of the same mesh, not beacon or probe responses sent from the associated MP. Adapt any other relevant information sent in beacons or probe responses.

When MPs are implemented according to embodiments of the invention described herein, the MAP should not be synchronized with other MPs. Instead, it should select beacon intervals and transport traffic information map (DTIM) cycles independently and also start its TSF regardless of any concurrent start MAP. MAPs never go into power saving (PS) mode and thus do not need to be synchronized with other MPs. Since the MAP is not synchronized with the MPs that require synchronization from peers, the MAP will handle any associated MP operation that operates in the same PS mode as the legacy stations (STAs), which means that the MP is responsible for PS operations (direct and broadcast). Means that the MAP assumes that it wakes up the DTIM beacon of the MAP in operations that allow timely transmission of traffic.

Stay in sync-beacon generation

2 illustrates a flow chart describing a non-AP MP beacon generation procedure in accordance with some embodiments of the present invention. This procedure is also applicable to lightweight mesh points.

The beacon (and probe response) generation procedure adapted by the non-AP MP depends on the state type (Synch or Unsynch) determined in step 215. In the following, reference numerals for beacons may be interpreted as reference numerals for beacons or probe responses. The synchronized MP (determined in step 215) that attempts to transmit a beacon or probe response is a beacon backoff similar to the access procedure described for the IBSS operation in the 802.11-1999 standard (section 11.1.2.2) and 8.2.11e draft. Use the function (steps 220 and 225. In particular, the MP receiving the beacon after the target beacon transmission time (TBTT) (measured in step 210) from the other MP and before transmitting itself; And if the MP requires synchronization from peers or synchronization with the peer MP flag in the synchronization capability field is set to true (determined in step 225 from the expression "IS (SYNCPEERS∥SYNCREG)") and optionally If a beacon is received from the associated MP (determined in step 225 from "IS_ASSOCIATED_WITH (BEACON SENDER)"), delete the beacon transmission (step 230). In particular, the following rules apply for beacon transmission.

a. Stop decrementing backoff timers for any non-beacon traffic.

b. Compute twice the random delay and aCWmin X aSlot time (aCWmin X aSlot time is a system-specified period) uniformly distributed in zero range.

c. Wait for a random delay period and decrease the random delay timer using the same algorithm for backoff (step 220).

d. If the beacon arrives before the random delay timer expires, the Sync Request from Peers or Synchronize with Peer MP Flag in the Beacon's Sync Capability field is set to true and optionally the received beacon is from the associated MP. If received, the remaining random timer delay and pending beacon transmissions are discarded (step 230).

e. Delay period from any MP when the random delay ends and if the beacon is associated with the Peer MP flag in the Sync Request or Peer Capability field from the peer is set to true and optionally if the received beacon is received from the associated MP If not reached, send a beacon (step 235).

If the non-AP MP announces that it supports synchronization or requires synchronization with peers, the non-AP MP generates beacons and the non-AP MP as if operating in IBSS mode as described above. Can be synchronized with. Alternatively, the non-AP MP can select its beacon interval (BI) independently and can start the TSF independently of any TSF of the other MP. In the following case, the beacon generation method follows the procedure described in IEEE 802.11 infrastructure mode operation. In some WLAN meshes where the MP is associated with peers, the non-AP MP may be received from a synchronized peer MP where the beacon is not associated with the non-AP MP if the MP transmitting the beacon is a member of the same mesh. When beacon transmission can be deleted.

Acquire sync

Non-AP MP is a medium access control (MAC) sublayer management entity (MLME) -SCAN. It can operate in either active scanning mode or passive scanning mode depending on the current value of the scan mode parameter of the request primitive.

MLME-SCAN. Upon receipt of the request primitive, the non-AP MP may perform scanning. The mesh identity (ID) parameter indicates to the WLAN mesh which is scanning. To be a member of a particular mesh using passive scanning, the non-AP MP scans beacon frames containing the WLAN mesh ID, so that the mesh description of the corresponding MLME-SCAN. Confirm primitive with the appropriate bits in the capability information field. It can return all beacon frames that match the proper mesh ID of the set parameter. To actively scan, the non-AP MP may send probe frames that include the appropriate mesh ID. Upon completion of scanning, the MLME-SCAN. Acknowledgment is typically sent by the MLME indicating all of the received WLAN mesh information.

Initially, the non-AP MP may decide to operate in a synchronous or asynchronous state. The asynchronous MP selects its own set of BSS parameters after receiving the MLME-START request. However, it may choose additional methods to prevent beacon collision and select its own BSS parameters and TBTT offset based on beacons received from the BI and DTIM periods of other MPs. 3 illustrates a flow diagram describing the operation of a non-AP MP after receiving a beacon or probe response while in an asynchronous state in accordance with some embodiments of the present invention. The procedure is also applicable to lightweight mesh points. In step 310, a beacon or probe response is received by the non-AP MP. The non-AP MP adapts the beacon timing parameters in step 335, the beacon timestamp is greater than the clock of the non-AP MP in step 330 and the SYNCHREQ state is true in step 320 and (optionally) in step ( In step 325 the value SYNCHPEERS is stored when the non-AP-MP determines that it is associated with the beacon sender at 315. When selection step 315 is used and determines that a non-AP MP is not associated with a beacon sender, it does not perform steps 320, 325, 330, 335. When the non-AP MP determines that the SYNCHREQ state is not true, the non-AP MP does not perform steps 320, 325, 330. If the non-AP MP determines that the beacon timestamp is not longer than the clock of the non-AP MP (step 330), the non-AP MP does not perform step 335.

If it is determined that a non-AP MP that is asynchronous is operating in a synchronous state, it adapts the set of IBSS parameters received from the synchronous and optionally associated MP. In the latter case, the non-AP MP may generate beacons as described above.

If non-AP MP scanning does not occur when retrieving a mesh using the appropriate mesh ID and the appropriate type, or does not occur when retrieving any mesh, the non-AP MP is deactivated upon receipt of the MLME-START. You can start your own mesh.

Adjust timers

In response to the MLME-START. Request, the non-AP MP may initialize the TSF timer to zero and send a beacon or probe response until it hears a beacon or probe response from a member of the WLAN mesh with the matching mesh ID. Should not.

4 is a flow chart describing the operation of a non-AP MP after receiving a beacon or probe response while in sync. All beacon or probe response frames should carry timestamp fields. A synced MP that receives a frame from another MP (step 415) of the WLAN mesh with the same ID (step 410) when the sync request from the peer or the peer MP flag in the Sync Capability field of the other MP is set to true. ("IS (SYNCHREQ || SYNCHPEER)? Expressed (step 420))) In step 455, the TSF time and its own timestamp can be compared. Optionally, in step 415, the other MP must be the associated MP. If the timestamp field of the received frame is later than its TSF time, the MP will adapt all beacon timing parameters included in the beacon frame in step 460. Moreover, if the synchronized MP is in step 420 If it is a different MP that receives a beacon from another MP that has a "Request Sync from Peer" set to false and only requests sync, then the MP can be passed in step 440 through steps 425, 430 and 435. Have the option to switch from synchronous to asynchronous, optionally, the other MP should be the associated MP (step 415).

MP Operation at Power Saving

A non-AP MP that allows peers that require support for PS services to be associated may support synchronization, and the non-AP MP may associate with a peer that has operated in PS mode if it cannot provide synchronization services. You can refuse.

A non-AP MP associated with MAP and switched to PS mode must wake up the DTIM beacon of the MAP and any additional beacons that need to be received based on the listened interval negotiated with the MAP. If the MP is associated with more than one MAP, the MP must wake up the DTIM and listening interval beacons for each MAP. This adds to any mesh TBTT and associated non-AP MP neighbors that can be scheduled for synchronization. Thus, any MP operating in power saving mode and associated with a MAP must track the offset between the announced TSF and the interval TSF of any MAP with which it is associated with the DTIM and beacon intervals of the MAPs. Here, the offset value is equal to the difference between the announced TSF and the inner TSF of any MAP associated with it. This may update the offset value for the neighbor MAP in all TBTTs of the neighbor MAP.

Advantages

Embodiments of the present invention described herein are conventional because the MP implemented in accordance with embodiments of the present invention is synchronized with non-AP mesh points when one or more of the non-AP mesh points require synchronization. Is distinguished from. The present invention allows members of a mesh to predict when other members operating in power saving mode receive direct and broadcast traffic without requiring an MPA to synchronize with other MPs. One of the advantages of the embodiments is that the proposed beacon generation and synchronization scheme simply implements and uses existing mechanisms. Embodiments do not require complex calculations or processing by the MP. Embodiments protect the MAP, stations and MP associated with the MAP from MP, which may be undesirable due to incomplete compensation for temperature or aging or detrimental operation of the MP crystal oscillator. These undesirable MPs can interfere with the entire mesh instead of one small segment. The proposed embodiments provide flexibility for non-AP MP to share beaconing responsibilities or to control these functions individually. For example, it is desirable for one segments of the mesh to achieve timing synchronization and power savings while allowing another segment to limit the operations.

Aspects of some methods of embodiments

2 and the foregoing detailed description, the method is used by a mesh point, which is one of an access point mesh point, a non-access mesh point, and a lightweight mesh point. The method includes formatting a synchronization capability field of one of a beacon and a probe response. The synchronization capability field may include an indication (SynchSupp) as to whether the mesh point supports synchronization; An instruction as to whether the mesh point requires synchronization from the peer mesh point (SynchReq); And an indication (SynchPeers) as to whether the mesh point is already synchronized with one or more peers. The present invention provides a method comprising: initiating a beacon backoff function upon expiration of a target beacon transmission timer when the mesh point is one of a non-access point mesh point and a lightweight access point, when SynchReq and SynchPeers of the mesh point are true; And canceling the beacon backoff function when one of a beacon and a probe response from another mesh point is received that at least one of SynchReq and SynchPeers of another mesh point is true.

Referring to FIG. 3 and the foregoing detailed description, the method is used by a mesh point, which is one of a non-access point mesh point and a lightweight mesh point. The method includes receiving one of a beacon and a probe response from another mesh point; Determining whether the mesh point is in an asynchronous state; Determining from the indicator in one of the beacon and probe responses whether another mesh point requires synchronization from a peer mesh point SynchReq; And setting a state (SynchPeers) as true about whether the mesh point is already synchronized with one or more peers, and performing a beacon timing synchronization function when the mesh point is in an asynchronous state and both SynchReqs of other mesh points are true. It includes.

Referring to FIG. 4 and the foregoing detailed description, the method is used by a mesh point, which is one of a non-access point mesh point and a lightweight mesh point. The method includes receiving one of a beacon and a probe response from another mesh point; Determining if the mesh point is in sync; Determining whether another mesh point is synchronized from one or more indicators in one of the beacon and probe response; And adding an identity of another mesh point to the database of beacon senders derived by the mesh point, and performing a beacon timing synchronization function when both the mesh point and the other mesh point are synchronized.

Embodiments of the invention described herein may include one or more processors that control one or more processors to implement some, most, or all of the functions of timing synchronization and beacon generation described herein in connection with certain non-processor circuits. It may be comprised of conventional processors and unique stored program instructions. Non-processor circuits may include, but are not limited to, a wireless receiver, a wireless transmitter, signal drivers, clock circuits, power source circuits, and user input devices. Likewise, these functions can be interpreted as steps of a method of performing timing synchronization and beacon generation. Alternatively, some or all of the functions may be implemented by a state machine in which no program instructions are stored, or by one or more application specific integrated circuits (ASICs) in which any combination of each of the functions or functions is implemented as a conventional logic device. have. Of course, a combination of the two methods could be used. Thus, methods and means for these functions have been described herein. In addition, those skilled in the art will appreciate that the software instructions and when guided by the concepts and principles described herein, for example, despite the time available, considerable effort motivated by current technology and boundary conditions, and many design choices. It is anticipated that programs and ICs can be easily generated with minimal experimentation.

The present invention has the effect of efficiently performing timing synchronization and beacon generation for mesh points operating in a wireless mesh network.

Claims (12)

In the method used by the mesh point, Formatting a synchronization capability field of one of a beacon and a probe response, wherein the synchronization capability field comprises: An indication as to whether the mesh point supports synchronization (SynchSupp); An instruction SynchReq as to whether the mesh point requires synchronization from a peer mesh point; And A method for use by a mesh point, comprising an indication (SynchPeers) whether the mesh point is already synchronized with one or more peers. The method of claim 1, Wherein the mesh point is one of an access point, a non-access point, and a lightweight mesh point. The method of claim 1, When the mesh point is one of a non-access point mesh point and a lightweight access point, Initiating a beacon backoff function upon expiration of a target beacon transmission timer when at least one of SynchReq and SynchPeers of the mesh point is true; And Canceling the beacon backoff function when one of the beacons and probe responses from the other mesh point is received that at least one of the SynchReq and SynchPeers of the other mesh point is true. . A method used by a mesh point that is one of a non-access point mesh point and a lightweight mesh point, Receiving one of a beacon and a probe response from another mesh point; Determining whether the mesh point is in an asynchronous state; And Determining from the indicator SynchReq in one of the beacon and probe responses whether the other mesh point requires synchronization from a peer mesh point; And Set the state SynchPeers to true if the mesh point is already synchronized with one or more peers, and perform beacon timing synchronization when both the asynchronous state of the mesh point and SynchReq of the other mesh point are true The method used by the mesh point comprising a step. The method of claim 4, wherein Setting the state of the SynchPeers to true or performing the beacon timing synchronization function is not performed when the mesh point is not associated with the other mesh point. The method of claim 4, wherein Wherein the mesh point is in an asynchronous state when both SynchReq and SynchPeers of the mesh point are false. The method of claim 4, wherein The setting state further includes adding an identity of the other mesh point to a database of mesh points that are beacon senders maintained by the non-access point mesh point. A method used by a mesh point that is one of a non-access point mesh point and a lightweight mesh point, Receiving one of a beacon and a probe response from another mesh point; Determining if the mesh point is in sync; Determining from the one or more indicators in one of the beacon and probe responses whether the other mesh point is synchronized; And Adding an identity of the other mesh point to a database of beacon senders maintained by the mesh point, and performing a beacon timing synchronization function when both the mesh point and the other mesh point are synchronized. Used method. The method of claim 8, The one or more indicators in one of the beacons and probe response, SynchReq indicating whether the other mesh point requires synchronization from a peer mesh point; And SynchPeers indicating whether the other mesh point is already synchronized with one or more peers, And the other mesh point is synchronized when at least one of SynchReq and SynchPeers of the other mesh point is true. The method of claim 8, Wherein the adding of the identity of the other mesh point and performing the beacon timing function are also dependent on the mesh point and the other mesh point associated with it. The method of claim 8, Determining if the other mesh point is an access point; And Storing the difference between the timing synchronization function of the other mesh point and the timing synchronization function of the mesh point as a beacon offset value, when the other access point is an access point mesh point and the other mesh point is not in a synchronized state, Storing the transport traffic indication map and beacon intervals. The method of claim 8, Determining whether the other mesh point is an access point mesh point; And When the other mesh point is a non-access point mesh point and the other mesh point is not in sync, deleting the identity of the other mesh point from the database of beacon senders maintained by the mesh point. The method used by the mesh point.

Images