RMA generation
By using devices that perform timing synchronization in the wireless LAN to generate random media access control addresses before and after association in the wireless LAN, the user privacy and tracking risks are solved, and user experience and network compatibility are improved.
Patent Information
- Application Number
- CN202280096592.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-31
- Publication Date
- 2025-01-10
AI Technical Summary
The prior art cannot effectively solve the problem of randomization of MAC addresses of non-AP STAs before and after association in wireless LANs, resulting in user privacy risks and tracking risks, and frequent MAC address rotations may reduce user experience and increase management frame overhead.
By performing timing synchronization between the first device and the second device, a first random media access control address (RMA) is generated in the first time instance according to the rule configuration information, and a second RMA is generated in the second time instance. The rule configuration information includes time Instructions ensure that the generation of RMA is associated with timing information, and support periodicity and correlation randomization of MAC address before and after the two phases.
It realizes that the MAC address can be changed without termination of the connection, reduces signaling messages and manages frame overhead, ensures network compatibility, improves user experience, and supports the normal operation of the MAC layer and upper-level services.
Smart Images

Figure CN119301913A_ABST
Abstract
Description
Technical Field
[0001] Example embodiments of the present disclosure relate generally to the field of communications, and in particular to devices, methods, apparatuses, and computer-readable storage media for random media access control (MAC) addresses, random MAC address (RMA) determination. Background Art
[0002] Today, the evolution of wireless systems, driven by user demand and General Data Protection Regulation (GDPR) requirements, has brought privacy issues to the forefront. The global wireless industry faces a growing need to protect users’ personally identifiable information from increasingly sophisticated user tracking and user profiling activities while continuing to improve wireless services and user experience. Summary of the invention
[0003] Example embodiments of the present disclosure provide an apparatus, method, device, and computer-readable storage medium for RMA generation.
[0004] In a first aspect, a method is provided. In the method, a first device performs timing synchronization with a second device. The first device generates a first random media access control address (RMA) for communicating with the second device according to rule configuration information at a first time instance. In addition, the first device generates a second RMA for communicating with the second device according to the rule configuration information at a second time instance. The rule configuration information includes a time instruction, which includes information corresponding to the first time instance and information about a time period starting from the first time instance and ending at the second time instance.
[0005] In a second aspect, a device is provided, the device comprising at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to perform timing synchronization with a second device. The device is also configured to generate a first random media access control address RMA for communicating with the second device according to rule configuration information at a first time instance. In addition, the device is configured to generate a second RMA for communicating with the second device according to the rule configuration information at a second time instance. The rule configuration information includes a time instruction, which includes information corresponding to the first time instance, and information about a time period starting from the first time instance and ending at the second time instance.
[0006] In a third aspect, an apparatus is provided, the apparatus comprising means for performing the method according to the first aspect.
[0007] In a fourth aspect, a computer-readable storage medium is provided, the computer-readable storage medium comprising program instructions stored thereon, wherein the instructions, when executed by a processor of a device, cause the device to perform the method according to the first aspect.
[0008] It should be understood that the invention summary is not intended to identify the key or essential features of the exemplary embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Some example embodiments will now be described with reference to the accompanying drawings, in which:
[0010] Figure 1 illustrates an example environment in which example embodiments of the present disclosure may be implemented;
[0011] Figure 2 A flow chart of an example method 200 is illustrated according to some example embodiments of the present disclosure.
[0012] Figure 3 illustrates a signaling flow between a first device and a second device according to some example embodiments of the present disclosure;
[0013] Figure 4 illustrates an example process for periodic RMA generation according to some example embodiments of the present disclosure;
[0014] Figure 5 illustrates an example process of STA-triggered RMA generation according to some example embodiments of the present disclosure;
[0015] Figure 6 illustrates an example process of AP-triggered RMA generation according to some example embodiments of the present disclosure; and
[0016] Figure 7 A simplified block diagram of a device suitable for implementing an example embodiment of the present disclosure is illustrated.
[0017] Throughout the drawings, the same or similar reference numerals refer to the same or similar elements. DETAILED DESCRIPTION
[0018] The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these example embodiments are described only for illustrative purposes and to help those skilled in the art understand and implement the present disclosure without any limitation to the scope of the present disclosure. The disclosure described herein can be implemented in various ways different from the ways described below.
[0019] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.
[0020] As used herein, the term "network device" refers to a device via which a service can be provided to a terminal device in a communication network. For example, a network device may include a base station. As used herein, the term "base station" (BS) refers to a network device via which a service can be provided to a terminal device in a communication network. A base station may include any suitable device via which a terminal device or UE can access a communication network. Examples of base stations include relays, access points (APs), transmission points (TRPs), node Bs (NodeBs or NBs), evolved NodeBs (eNodeBs or eNBs), new radio (NR) NodeBs (gNBs), remote radio modules (RRUs), radio headers (RHs), remote radio heads (RRHs), low power nodes (such as femto, micro), etc.
[0021] As used herein, the term "terminal device" or "user equipment" (UE) refers to any terminal device capable of wireless communication with each other or with a base station. Communication may involve sending and / or receiving wireless signals using electromagnetic signals, radio waves, infrared signals, and / or other types of signals suitable for transmitting information in the air. In some example embodiments, the UE may be configured to send and / or receive information without direct human interaction. For example, the UE may send information to the base station according to a predetermined schedule, when triggered by an internal or external event, or in response to a request from the network side.
[0022] Examples of UE include, but are not limited to, smartphones, wireless-enabled tablets, laptop embedded devices (LEEs), laptop mounted devices (LMEs), wireless customer premises equipment (CPEs), sensors, metering devices, personal wearable devices (such as watches), and / or vehicles capable of communication. For the purposes of discussion, some example embodiments will be described with reference to UE as an example of a terminal device, and the terms "terminal device" and "user equipment" (UE) may be used interchangeably in the context of the present disclosure.
[0023] For example, a terminal device may include a station (STA), which is a logical entity that includes a physical layer interface for MAC and wireless communication. STA includes AP and non-AP STA. A mobile terminal operated by a user corresponds to a non-AP STA in STA. If simply referred to as STA, STA may correspond to a non-AP STA. Non-AP STA may be called by another name, such as a terminal, a wireless transmission / reception unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile terminal, a mobile subscriber unit, etc.
[0024] As used herein, the term "circuitry" may refer to one or more or all of the following:
[0025] (a) hardware circuit implementation only (such as implementation only in analog and / or digital circuitry), and
[0026] (b) a combination of hardware circuitry and software such as (where applicable):
[0027] (i) a combination of analog and / or digital hardware circuits and software / firmware, and
[0028] (ii) any portion of hardware processor(s) (including digital signal processor(s)) with software, software and memory(s) that work together to enable a device (such as a mobile phone or server) to perform various functions, and
[0029] (c) Hardware circuits and / or processor(s), such as microprocessor(s) or portions of microprocessor(s), that require software (e.g., firmware) to operate, but where the software may not be present, the software may be absent.
[0030] This definition of circuitry applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or process and its accompanying software and / or firmware. For example, and if applicable to a particular claim element, the term circuitry also covers a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular base station, or other computing or base station.
[0031] As used herein, the singular forms "a", "an", and "the" shall also include the plural forms unless the context clearly indicates otherwise. The term "including" and its variations shall be understood as open terms, meaning "including but not limited to". The term "based on" shall be understood as "based at least in part on". The terms "one embodiment" and "embodiment" shall be understood as "at least one embodiment". The term "another embodiment" shall be understood as "at least one other embodiment". Other explicit and implicit definitions may be included below.
[0032] As used herein, the terms "first", "second", etc. may be used to describe various elements, which should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, without departing from the scope of the exemplary embodiments, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.
[0033] As used herein, the term "rule configuration information" may be used in connection with information useful for (or used to establish) (ie, configure) a rule based on which an RMA is to be generated.
[0034] As used herein, the term "pre-association phase" refers to before an association between two parties is initiated. The term "post-association" is after an association between two parties is completed and a security context is established. The term "during association" refers to the association phase during an authentication or (re)association request / response exchange.
[0035] In the 3rd Generation Partnership Project (3GPP), there are some discussions about MAC address determination. In the 802.11 standard, STA uses a fixed, unencrypted MAC address in the frame header, which causes security issues because other parties are allowed to track the STA based on its MAC address. In order to prevent STAs from being tracked and improve the privacy of the Institute of Electrical and Electronics Engineers (IEEE) 802.11, the recent 802.11aq amendment defines the MAC address randomization behavior of non-AP STAs. According to IEEE802.11aq, non-AP STAs should periodically change their MAC addresses to random values while not associated with a basic service set (BSS), which is also called pre-association randomization of MAC addresses. Non-AP STAs maintain a single MAC address while connected to an enhanced service set (ESS). In other words, non-AP STAs can change their MAC addresses before connecting to a BSS / ESS, but must not change their MAC addresses during the connection. For example, in the pre-association phase (e.g., the discovery phase), STAs can send probe request frames with different RMAs. However, when the STA is to connect with the AP for the association / authorization process and data connection, the STA may retain a single RMA.
[0036] However, the privacy protection capability of IEEE 802.11aq is limited, and detailed mechanisms are not defined. In addition, some randomized and constantly changing MAC address (RCM) implementations are vendor-specific, such as how often a non-AP STA should change its MAC address. In addition, the use of STA MAC addresses in IEEE 802.11aq opens the door to a variety of attack possibilities and privacy risks. For example, maintaining a constant MAC address over a long period of time and associating it with a specific network allows the correlation of information to be achieved, such as the correlation between data generated by home devices, physically observable events, and the identification of the device (e.g., MAC address), which may lead to the leakage of private data about user behavior. In addition, maintaining a constant MAC address over a long period of time and associating it with a specific network allows the presence of a MAC address in the network to be correlated with the presence of the user in a certain place, thereby tracking user movement.
[0037] To address these challenges posed by RCM, the IEEE 802 Local Area Network (LAN) / Metropolitan Area Network (MAN) Standards Committee established two standardization projects within the IEEE 802.11 Wireless LAN Working Group, namely IEEE P802.11bh and IEEE P802.11bi. IEEE P802.11bh considers specific issues related to 802.11 MAC address randomization and intends to develop modifications to IEEE 802.11 to address these issues. The goal is to maintain the efficiency of existing services (which may otherwise be limited), such as network support, diagnostics and troubleshooting, and reliably detect that devices have arrived in a trusted network environment. IEEE P802.11bh also intends to design mechanisms to optimize the user experience when the MAC address of a device is changing. IEEE P802.11bi considers privacy issues beyond MAC address randomization from a broader and longer-term perspective. It aims to address and standardize privacy solutions to prevent tracking of user location and movement.
[0038] Currently, IEEE 802.11bh focuses on non-AP STA identification through MAC randomization in the pre-association stage, and non-AP STAs still do not change their MAC addresses after association (i.e., post-association) as in 802.11aq. On the other hand, IEEE 802.11bi intends to address privacy issues as part of its work and seeks to address the situation where non-AP STAs can also change their MAC addresses after association, for example, by implementing post-association randomization of MAC addresses for device identification. In addition, IEEE 802.11bi proposes an over-the-air rotation MAC address solution to address this issue.
[0039] In summary, the previously defined IEEE 802.11aq suggests that non-AP STAs can change their MAC addresses. However, its implementation is limited and mostly vendor-specific. STAs can only change their MAC addresses before association, and for security reasons, no further details are proposed. Although IEEE 802.11bh attempts to address the problems faced by 802.11aq and extends it to more reliable and secure principles, it still focuses on pre-association MAC randomization. For both IEEE 802.11aq and its enhanced successor IEEE 802.11bh, the MAC address remains unchanged while the STA remains associated with the ESS (e.g., while maintaining a data connection with the AP or roaming between APs in the ESS). In other words, even if a non-AP STA can frequently change its MAC address before association and can be successfully identified by the AP, it must maintain the same MAC address as long as it is associated with the AP. However, the continuous use of the same MAC address after association may cause user privacy risks.
[0040] In order to reduce the risk of being tracked, IEEE 802.11bi attempts to address privacy issues from a broader and longer-term perspective, in which non-AP STAs can also change their MAC addresses after association. It is suggested that a direct solution is to reduce the time that the MAC address is used, such as frequent MAC address rotation. However, frequent MAC address rotation may require non-AP STAs to frequently disassociate / reassociate to change their MAC addresses, and frequent attempts to change MAC addresses may cause some potential problems. For example, since the STA may need to disassociate / reassociate to change its MAC address, the user experience may be reduced due to connection interruption. In addition, the management frame overhead may also increase, because excessive disassociation / reassociation operations may result in an increase in the number of management frame exchanges.
[0041] Furthermore, to date, there does not appear to be an effective method that addresses both the privacy and device identification issues of MAC address randomization that is applicable to both 802.11bh and 802.11bi requirements. There does not appear to be an effective method that enables a non-AP STA to randomize its MAC address before or after association where device identification and privacy are guaranteed.
[0042] An example embodiment of the present disclosure provides an RMA generation scheme. Through this scheme, a device (referred to as a first device) performs timing synchronization with another device (referred to as a second device). The first device generates a first random media access control address RMA for communicating with the second device according to rule configuration information at a first time instance. In addition, the first device generates a second RMA for communicating with the second device according to the rule configuration information at a second time instance. The rule configuration information includes a time instruction, which includes information corresponding to the first time instance, and information about a time period starting from the first time instance and ending at the second time instance.
[0043] This solution improves the user experience, at least because there is no need to terminate the connection to change the MAC address. The solution can also reduce overhead because there is no need to send excessive signaling messages, such as disassociation / reassociation frames to change the MAC address, and there is no need to send specific management / data frames to identify the STA. In addition, since the solution can be used both before and after association, network compatibility is ensured. Therefore, it allows the support of services between the MAC layer and the upper layer.
[0044] Figure 1 An example environment 100 is illustrated in which example embodiments of the present disclosure may be implemented.
[0045] Environment 100, which may be part of a communication network, includes two devices 110 and 120 that communicate with each other or with other devices via each other. For discussion purposes, devices 110 and 120 may be referred to as first device 110 and second device 120, respectively.
[0046] The first device 110 and the second device 120 may be implemented by any suitable device in the communication network. In some example embodiments, the first device 110 may be implemented by a terminal device, and the second device 120 may be implemented by a network device, or vice versa. In some other example embodiments, both the first device 110 and the second device 120 may be implemented by a terminal device or a network device. For discussion purposes only, in some example embodiments, the terminal device will be taken as an example of the first device 110, and the network device will be taken as an example of the second device 120, while in some other example embodiments, the network device will be taken as an example of the first device 110, and the terminal device will be taken as an example of the second device 120.
[0047] It should be understood that two devices are shown in environment 100 for illustration purposes only and do not present any limitation on the scope of the present disclosure. In some example embodiments, environment 100 may include additional devices for communicating with first device 110 and / or second device 120.
[0048] Communications in environment 100 may follow any suitable communications standards or protocols that already exist or will be developed in the future, such as Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Advanced LTE (LTE-A), Fifth Generation (5G) New Radio (NR), Wireless Fidelity (Wi-Fi), and Worldwide Interoperability for Microwave Access (WiMAX) standards, and employ any suitable communications technology, including, for example, Multiple Input Multiple Output (MIMO), Orthogonal Frequency Division Multiplexing (OFDM), Time Division Multiplexing (TDM), Frequency Division Multiplexing (FDM), Code Division Multiplexing (CDM), Bluetooth, ZigBee, and Machine Type Communications (MTC), Enhanced Mobile Broadband (eMBB), Massive Machine Type Communications (mMTC), Ultra-Reliable Low Latency Communications (URLLC), Carrier Aggregation (CA), Dual Connectivity (DC), and New Radio Unlicensed (NR-U) technologies.
[0049] Figure 2 2 is a flowchart of an example method 200 according to some example embodiments of the present disclosure. The method 200 may be performed by: Figure 1 For the purpose of discussion, reference will be made to the first device 110. Figure 1 Method 200 is described. In some example embodiments, the first device 110 may be implemented by a terminal device such as a STA, and the second device 120 communicating with the first device 110 may be implemented by a network device such as an AP. In some other example embodiments, the first device 110 may be implemented by a network device such as an AP, and the second device 120 communicating with the first device 110 may be implemented by a terminal device such as a STA.
[0050] In some example embodiments, capability information associated with RMA generation may be determined for first device 110 or second device 120. For example, the capability information may include at least one of: at least one rule for RMA generation, or at least one indication of supported timing synchronization methods.
[0051] For example, the timing synchronization method may include implementing timing synchronization by synchronizing with a time obtained from another device (such as Internet time). As another example, the timing synchronization method may be associated with timing synchronization function (TSF) information. For example, the first device 110 may obtain TSF information from the second device 120.
[0052] The rules for RMA generation can be determined in a variety of ways. For example, the rules for RMA generation can be associated with at least timing information to allow synchronization of changes in RMA at the first device 110 and the second device 120 for device identification. In some example embodiments, the rule can be defined to associate RMA generation with timing information. For example, the RMA at a time instance (e.g., t) at which the RMA is generated for a given rule can be generated based on a given random function, using the time instance t at which the RMA is generated as an input parameter, i.e., RMA (t) = rule (t). For example, at a time instance (also referred to as a first time instance), the RMA can be calculated by using the first time instance as an input parameter (which can be expressed as rule (first time instance)), and then at a later time instance (also referred to as a second time instance), the RMA can be calculated by using the second time instance as an input parameter (which can be expressed as rule (second time instance)).
[0053] For example, the RMA may be generated based on the random function shown in the following equation (1):
[0054] RMA(t)=randi(imax, [1, n], "seed", t) (1)
[0055] where randi(imax, [1, n], "seed", t) is used to create a 1-by-n co-distributed vector of uniformly distributed random integers in the range defined by imax, and the seed used for the randomization operation is specified by the time instance t at which the RMA is generated. For example, imax and n can be set to 255 and 6, respectively, to generate the RMA. In addition, each integer in the vector can correspond to a byte of the RMA.
[0056] As another example, a MAC address pool including a set of candidate MAC addresses may be used to generate an RMA. In this case, the RMA at the time instance (e.g., t) at which the RMA is generated may be randomly selected from the configured MAC address pool by using the time instance at which the RMA is generated as a random seed for RMA generation, for example, as shown in the following equation (2):
[0057] RMA(t)=MAC_POOL(randi(imax, 1, 'seed', t) (2)
[0058] where randi(imax, 1, "seed", s) is used to create uniformly distributed random integers in the range defined by imax, and the seed for the randomization operation is specified by the time instance t at which the RMA was generated. For example, imax can be the number of MAC addresses in a MAC address pool, and the seed for the randomization operation can be specified by the time instance t at which the RMA was generated.
[0059] In some other example implementations, the rule may be defined to associate RMA generation with timing information and at least one reference identifier. For example, the reference identifier may be an RMA, a public key, a private key, a shared key generated by a time key (TK), a pairwise transient key (PTK), or a pairwise master key (PMK) of both parties, a signature, a device identifier, or any identifier used for RMA generation and STA identification. In an embodiment where one of the first device 110 and the second device 120 is implemented by a STA and the other is implemented by an AP, the reference identifier may be a MAC address of the STA / AP carried in a MAC header, or an RMA determined when the STA first associates with the AP.
[0060] For example, the RMA at the time instance when the RMA is generated (e.g., t) can be generated based on a random function, with the time instance when the RMA is generated and the reference identifier ref_id(k) (k=1,...,K, where K is the number of identifiers) as input parameters (i.e., RMA(t)=rule(ref_id(1),...,ref_id(K),t)).
[0061] For example, it can be assumed that the reference identifier is the MAC address of the STA in the MAC header, and the RMA at the timing point t at which the RMA is generated (e.g., RMA(t)) can be generated based on the most recent RMA of the STA in the MAC header (e.g., RMA(t-1)). In this case, the following two example rule definitions can be given:
[0062] RMA(t)=RMA(t-1)+1 (3)
[0063] RMA(t)=RMA(t-1)+X(t) (4)
[0064] Where X(t) is a random MAC address generated based on the timing information.
[0065] For example, two reference identifiers may be configured for RMA generation. In an embodiment where one of the first device 110 and the second device 120 is implemented by a STA and the other is implemented by an AP, the first reference identifier may be the RMA of the STA determined when the STA first associates with the AP, and the second identifier may be the MAC address of the AP. In this case, the rules may be defined as follows:
[0066] STA(t)'s RMA = STA(t-1)'s RMA + X(t, AP's MAC address) (5)
[0067] Where t represents the time instance at which the RMA is generated, and X is a random function used to generate the RMA based on the time instance t and the MAC address of the AP.
[0068] In some example embodiments, the rule(s) may be predefined in the specification.Alternatively or additionally, the rule(s) may be specified by rule configuration information, which will be described in detail below.
[0069] In some example embodiments, the first device 110 may receive, from the second device 120, capability information of the second device 120 associated with RMA generation.
[0070] For example, the second device 120 may actively notify the capability information, such as through a beacon frame, a detection frame, an association frame, or an action frame. For example, in an embodiment where the second device is implemented by a terminal device, the second device may send its capability information in a detection request frame. Alternatively, in an embodiment where the second device is implemented by a network device, the second device may notify the capability information in a detection response frame.
[0071] As another example, the first device 110 may send a request for capability information of the second device 120 to the second device 120. Then, in response, the second device 120 may send the capability information of the second device 120 to the first device 110. For example, the first device 110 may send an action frame to the second device 120 to request the capability information, and the second device 120 may send its capability information to the first device 110 through another action frame. Alternatively or additionally, the first device 110 may request and collect the capability information of the second device 120 in a secure mode, for example, through an integrated Extensible Authentication Protocol over LAN (EAPOL) frame or a (re)association frame.
[0072] Then, the first device 110 may determine rule configuration information for RMA generation based at least in part on the capability information of the second device 120. In addition, the first device 110 may send the rule configuration information to the second device 120.
[0073] In some other example embodiments, the first device 110 may send capability information of the first device 110 associated with RMA generation to the second device 120. Likewise, as described above, the first device 110 may actively notify the second device 120 of its capability information through a frame. Alternatively, the first device 110 may send its capability information to the second device 120 in response to a request from the second device 120 for capability information of the first device 110. Then, based at least in part on the received capability information of the first device 110, the second device 120 may determine rule configuration information for RMA generation. In addition, the second device 120 sends the rule configuration information to the first device.
[0074] For example, the rule configuration information may be sent via an action frame. As another example, the rule configuration information may be sent in a secure mode. For example, the rule configuration information may be sent via an EAPOL frame or a (re)association frame in a fast initial link setup (FILS) mode.
[0075] In some example embodiments, the rule configuration information may be updated. For example, the first device 110 or the second device 120 may initiate an update of the rule configuration information. For example, the first device 110 may receive a rule configuration update from the second device 120. Subsequently, the first device 110 may update the rule configuration information based on the rule configuration update. In this case, the first device 110 may trigger the receiver to generate an RMA based on the configured rules by a rule configuration update in which a trigger indication for RMA generation is activated. As another example, periodicity may be configured in the rule configuration information, and the first device 110 or the second device 120 may be triggered to periodically update the rule configuration.
[0076] For example, the rule configuration information may include at least one of the following:
[0077] - an indication of a rule determined from at least one supported rule for RMA generation;
[0079] - an indication of the applicable association phase, for indicating in which association phase the configured rule is applied, for example, at least one of the pre-association phase, the post-association phase, or the association period
[0080] One item;
[0081] - One or more reference identifiers for RMA generation and device identification, such as RMA, public key, private key, shared key between the parties and signature; or device identifier;
[0082] -Indication of timing synchronization mode;
[0083] - an indication associated with the activation of a determined rule;
[0084] - an indication of a trigger for RMA generation, for triggering the receiver to generate an RMA based on the configured rules; or
[0085] - Information on the time when the RMA was generated.
[0086] like Figure 2 As shown, at box 210, the first device performs timing synchronization with the second device 120. In an embodiment where the rule configuration information includes an indication of a timing synchronization method associated with the TSF information, the first device 110 can obtain the timing TSF information from the second device 120. Then, the first device 110 can perform timing synchronization with the second device 120 based on the TSF information. For example, the first device 110 can receive a beacon or / and a probe response from the second device, and then use the TSF information in these frames for timing synchronization. In an embodiment where the rule configuration information includes an indication of a timing synchronization method associated with the time from a third device, the first device 110 can obtain the time of the third device. In addition, the first device 110 can perform timing synchronization with the second device 120 based on the time of the third device. For example, the first device 110 and the second device 120 can respectively synchronize their own time with the Internet time.
[0087] Alternatively or additionally, the timing synchronization mode can be determined based at least on the collected capability information of the first device 110 or the second device 120. For example, whether there is the capability to synchronize the Internet time can be announced through the capability information. In this case, if both the first device 110 and the second device 120 can synchronize their own timers with the Internet time, and the synchronization requirement is very high, the Internet time can be selected as the baseline timer for timing synchronization. If neither the first device 110 nor the second device 120 can synchronize its timer with the Internet time, the TSF information can be considered for timing synchronization.
[0088] After performing timing synchronization with the second device 120, the first device 110 may generate an RMA based on the rule configuration information. Figure 2As shown, at box 220, the first device 110 generates a first RMA for communicating with the second device 120 according to the rule configuration information at a first time instance. Then, at box 230, the first device 110 generates a second RMA for communicating with the second device 120 according to the rule configuration information at a second time instance. In this case, the rule configuration information includes a time instruction, which includes information corresponding to the first time instance, and information about a time period starting from the first time instance and ending at the second time instance. In some example embodiments, the first RMA and the second RMA may be carried in different frames. For example, the first RMA may be carried in a probe request frame, and the second RMA may be carried in an authentication and (re)association frame.
[0089] For example, at least the timing information may be used as an input parameter for generating an RMA. In this case, the first device 110 may generate an RMA by using the timing information as an input parameter based on an indication of a determined rule included in the rule configuration information. In an example embodiment in which the rule configuration information also includes one or more reference identifiers (i.e., the determined rule is associated with the one or more reference identifiers and the timing information), the first device 110 may generate an RMA based on the timing information and the one or more reference identifiers. For example, the first device 110 may generate a first RMA by using a first time instance and the one or more reference identifiers as input parameters, and generate a second RMA by using a second time instance and the one or more reference identifiers as input parameters.
[0090] In some example embodiments, the first device 110 may generate an RMA periodically. In an example embodiment in which the rule configuration information includes time information for RMA generation (the time information indicates a start time instance and a time period for periodic RMA generation), the first device 110 may determine a time instance for RMA generation based on a start time instance and a time period for periodic generation of (multiple) subsequent RMAs. In addition, for example, the time instance for generating an RMA may also be used as a random seed for RMA generation. Similarly, the second device 120 may generate an RMA periodically. Therefore, in this case, since the first device 110 and the second device 120 are time synchronized, both the first device 110 and the second device 120 may generate and store an RMA periodically at the same time instance at which the RMA is generated based on the rule configuration information. For example, assuming that the start time is 1:00 a.m. and the time period is 20 minutes, the first device 110 and the second device 120 may generate an RMA at the 0th minute, the 20th minute, and the 40th minute every hour.
[0091] In some example embodiments, the second device 120 may send a trigger indication of RMA generation to the first device 110 by updating the rule configuration, for example, through an action frame or a beacon frame, to trigger the first device 110 to generate the RMA based on the configured rule. Then, in response, the first device 110 may generate the RMA accordingly.
[0092] Then, the first device 110 can communicate with the second device 120 using the current RMA. For example, the first device can receive a target RMA from the second device 120. Then, the first device 110 can identify the second device 120 based on a comparison between the current RMA and the target RMA. In an embodiment where the target RMA is determined based on at least one reference identifier and timing information, the first device 110 can identify the second device 120 based on a comparison between the current RMA and the target RMA and an association between the target RMA and the at least one reference identifier. In this case, in order to communicate with the first device 110, the second device 120 can determine the target RMA for the first device 110 based on a configured rule associated with the at least one reference identifier and the timing information. Then, the second device 120 can send the determined target RMA for communication to the first device 110. At the first device 110, it can compare the received target RMA with the current RMA generated at the first device 110, and based on the target RMA and the current RMA being the same, it can also identify the second device 120 based on an association between the target RMA and the at least one reference identifier.
[0093] In an embodiment where the first device 110 is implemented by an AP and the second device is implemented by a STA, the second device may use the last stored RMA as a source address (SA) / transmitter address (TA) for communication with the first device 110. And then, the first device 110 may check whether the SA / TA is the same as one of the stored RMAs. If so, the first device 110 may also identify which STA the RMA is associated with, otherwise, it may regard the second device 120 as an invalid STA.
[0094] In an embodiment where the first device 110 is implemented by a STA and the second device is implemented by an AP, the second device 120 may use the last stored RMA of the first device 110 as a destination address (DA) / receiver address (RA) for communication. Upon receiving a frame from the second device 120, the first device 110 may check whether the DA / RA in the frame is the same as one of the stored RMAs. If so, the first device 110 may consider it to be a valid unicast frame, otherwise, the first device 110 may consider it to be an invalid unicast frame.
[0095] In some example embodiments, both the first device 110 and the second device 120 may store multiple RMAs, and then the multiple RMAs may be applied to the above process. For example, after changing the RMA, the first device 110 may send a signaling to the second device 120 to indicate the change of the RMA. After the second device 120 confirms such a change, the first device 110 and the second device 120 may use the latest RMA stored in the multiple RMAs on each side for subsequent communication. That is, the second device 120 may send the latest RMA (also referred to as the target RMA) in the multiple RMAs stored at the second device 120 to the first device 110. Then, the first device 110 may compare the received target RMA with the latest locally generated RMA in the multiple RMAs stored at the first device 110. If the received target RMA is different from the latest locally generated RMA, the first device 110 may also compare the received target RMA with other RMAs in the multiple RMAs stored at the first device 110. And, if the received target RMA is the same as one of the plurality of RMAs stored at the first device 110, the first device 110 can communicate with the second device 120. In this case, even if there is an error in the timing synchronization between the first device 110 and the second device 120, the communication between the first device 110 and the second device 120 is not affected.
[0096] For example, for multi-AP operation in the same ESS, a STA within the ESS may switch from a serving AP to a target AP. The following example embodiments may be considered for timing synchronization between a STA and a target AP. In some example embodiments, rule configuration information may be shared between multiple APs within the same ESS, so if the configured rule is activated and a timing synchronization method associated with the TSF information is configured, the STA may use the TSF information of the target AP to generate an RMA for associating with the target AP. In some other embodiments, rule configuration information may be shared between multiple APs within the same ESS, and if the configured rule is activated and a timing synchronization method associated with Internet time is configured, the STA may use Internet time to generate an RMA for associating with the target AP. As an example embodiment, a distributed system (DS) may determine the rule configuration information and then share the rule configuration information between multiple APs within the ESS.
[0097] In this way, the user experience is improved because there is no need to terminate the connection to change the MAC address. In addition, it also allows to reduce overhead because there is no need to send excessive signaling messages, such as disassociation / reassociation frames to change the MAC address, and there is no need to send specific management / data frames to identify the STA. In addition, since the scheme is applicable to both before and after association, network compatibility is ensured. Therefore, it allows to support services between the MAC layer and the upper layer.
[0098] Figure 3 FIG. 3 illustrates a signaling flow 300 between a first device and a second device according to some example embodiments of the present disclosure. For discussion purposes, reference will be made to Figure 1 A signaling flow 300 is described. In this case, the first device 110 is implemented by a STA 301 and the second device 120 is implemented by an AP 303 .
[0099] like Figure 3 As shown, at 306, STA 301 notifies AP 303 of capability information including at least (multiple) rule-based mechanisms for RMA generation. Then, AP 303 can determine a configuration for RMA generation based at least on the collected capability information. For example, the configuration may include an indication of the determined rule (e.g., an indication that the determined rule is defined to associate RMA generation with timing information and a reference identifier), an indication of an applicable association phase (e.g., a post-association phase), a reference identifier, an indication of a timing synchronization mode (e.g., an indication of a timing synchronization mode associated with TSF information), and an indication associated with activation of the determined rule (e.g., an activation indication). At 308, AP 303 sends a configuration for RMA generation to STA301.
[0100] At 310, AP 303 transmits a beacon frame including TSF information to STA 301. Then, at 312, STA 301 performs timing synchronization with AP 303 based on the TSF information for timing synchronization with AP 301 in the beacon frame.
[0101] At 314, STA 301 generates an RMA using the reference identifier in the configuration and the TSF information as input parameters for RMA generation. Then, at 316, STA 301 transmits to AP 303 using the RMA. At 318, AP 303 identifies STA 301 based on the association between the RMA and the reference identifier in the configuration. Then, at 320, AP 303 transmits to STA 301 using the RMA.
[0102] As mentioned above Figure 2All operations and features described are also applicable to the signaling flow 300 and have similar effects. For simplicity, the details will be omitted.
[0103] Figure 4 An example process 400 for periodic RMA generation according to some example embodiments of the present disclosure is illustrated. For discussion purposes, reference will be made to Figure 1 The process 400 is described. In this case, the first device 110 is implemented by a STA 401 and the second device 120 is implemented by an AP 403.
[0104] like Figure 4 As shown, at 406, STA 401 may advertise its capability information, which includes at least a rule-based mechanism for RMA generation (eg, Rule 1 and Rule 2) and a capability for synchronizing Internet time (eg, not supported).
[0105] Based on the capability information collected from STA 401, AP 403 can determine rule configuration information, which includes an indication such as a determined rule (e.g., Rule 2), an indication of an applicable association phase (e.g., post-association phase), a reference identifier (e.g., RMA1), time information for RMA generation (e.g., a start time instance and interval for RMA generation, such as zero clock and 1 minute, respectively), an indication of a timing synchronization mode (e.g., an indication of a timing synchronization mode associated with TSF information), and an indication associated with activation of the determined rule (e.g., an activation indication).
[0106] At 408, AP 403 sends rule configuration information to STA 401 via EAPOL-KEY message 3 (Msg. 3) during the 4-way handshake. Upon receiving the rule configuration information, STA 401 can try to receive a beacon from the AP. And then, STA 401 can use the TSF in the beacon frame as a baseline timer for timing synchronization.
[0107] Afterwards, both STA 401 and AP 403 can simultaneously and periodically generate RMAs for communication after association according to the rule configuration information. For example, at 410, STA 401 first uses RMA1 to establish a connection with AP 403. After the time of generating RMA at 412, both STA 401 and AP 403 generate new RMAs (i.e., RMA2) to perform communication between them, as shown in 414.
[0108] As mentioned above Figure 2 All operations and features described are also applicable to process 400 and have similar effects. For simplicity, details will be omitted.
[0109] Figure 5 An example process 500 for STA-triggered RMA generation according to some example embodiments of the present disclosure is illustrated. For discussion purposes, reference will be made to Figure 1 The process 500 is described. In this case, the first device 110 is implemented by a STA 501 and the second device 120 is implemented by an AP 503 .
[0110] like Figure 5 As shown, at 506, STA 501 may advertise its capability information, which includes at least a rule-based mechanism for RMA generation (eg, Rule 1, Rule 2, and Rule 3) and a capability for synchronizing Internet time (eg, not supported).
[0111] Based on the capability information collected from STA 501, AP 503 can determine rule configuration information, which includes, for example, an indication of a determined rule (e.g., Rule 2), an indication of an applicable association phase (e.g., both a pre-association phase and a post-association phase), a reference identifier (e.g., RMA1), an indication of a timing synchronization mode (e.g., an indication of a timing synchronization mode associated with TSF information), and an indication associated with activation of the determined rule (e.g., an activation indication).
[0112] At 508, AP 503 sends rule configuration information to STA 501 via EAPOL-KEY Msg.3 during the 4-way handshake. Upon receiving the rule configuration information, STA 501 can try to receive a beacon from AP. And then, STA 501 can use the TSF in the beacon frame as a baseline timer for timing synchronization.
[0113] At 510, STA 501 sends a trigger indication of RMA generation to AP 503 by, for example, updating the rule configuration through an action frame, to trigger AP 503 to generate RMA based on the configured rules. Alternatively, the start time of RMA generation may also be specified in the updated rule configuration information to ensure that both STA 501 and AP 503 generate RMA at the same time according to the rule configuration information. For example, STA 501 may first establish a connection with AP 503 using RMA1. After STA 501 updates the rule configuration information to trigger RMA generation, both STA 501 and AP 503 may generate a new RMA (i.e., RMA2) at the specified start time of generating RMA to perform communication between them, as shown in 512.
[0114] As mentioned above Figure 2 All operations and features described are also applicable to process 500 and have similar effects. For simplicity, details will be omitted.
[0115] Figure 6 An example process 600 for AP-triggered RMA generation is illustrated according to some example embodiments of the present disclosure. For discussion purposes, reference will be made to Figure 1 The process 600 is described. In this case, the first device 110 is implemented by a STA 601 and the second device 120 is implemented by an AP 603.
[0116] like Figure 6 As shown, at 606, AP 603 may request STA 601 to report its capability information about the rule-based mechanism for RMA generation in an action frame. Upon receiving the request, STA 601 may announce its capability information, which includes at least the rule-based mechanism for RMA generation (e.g., rule 1, rule 2, and rule 3) and the capability for synchronizing Internet time (e.g., support).
[0117] Based on the capability information collected from STA 601, AP 603 can determine rule configuration information, which includes, for example, an indication of a determined rule (e.g., Rule 1), an indication of an applicable association phase (e.g., both a pre-association phase and a post-association phase), a reference identifier (e.g., an RMA in a MAC header), an indication of a timing synchronization method (e.g., an indication of a timing synchronization method associated with Internet time), and an indication associated with activation of the determined rule (e.g., an activation indication).
[0118] At 608, AP 603 sends rule configuration information to STA 601 via EAPOL-KEY Msg. 3 during the 4-way handshake. Upon receiving the rule configuration information, STA 601 can try to synchronize its timer with the Internet time to perform timing synchronization with AP 603.
[0119] At 610, AP 603 sends a trigger indication of RMA generation to STA 601, for example, by updating the rule configuration information through an action frame, to trigger STA 601 to generate RMA based on the configured rules. Alternatively, the start time of RMA generation may also be specified in the updated rule configuration information to ensure that both STA 601 and AP 603 generate RMA at the same time according to the rule configuration information. For example, STA 601 may first establish a connection with AP 603 using RMA1. After AP 603 updates the rule configuration information to trigger RMA generation, both STA 601 and AP 603 may generate a new RMA (i.e., RMA2) at the specified start time of generating RMA to perform communication between them, as shown in 612.
[0120] As mentioned above Figure 2All operations and features described are also applicable to process 600 and have similar effects. For simplicity, details will be omitted.
[0121] Figure 7 is a simplified block diagram of a device 700 suitable for implementing an example embodiment of the present disclosure. The device 700 may be implemented as follows: Figure 1 The illustrated first device 110 or second device 120 is implemented at or as a part thereof.
[0122] As shown, the device 700 includes a processor 710, a memory 720 coupled to the processor 710, a communication module 730 coupled to the processor 710, and a communication interface (not shown) coupled to the communication module 730. The memory 720 stores at least a program 740. The communication module 730 is used for two-way communication, for example, via multiple antennas. The communication interface can represent any interface necessary for communication.
[0123] Assume that program 740 includes program instructions that, when executed by associated processor 710, cause device 700 to operate in accordance with example embodiments of the present disclosure, as referred to herein. Figures 1 to 6 The example embodiments herein may be implemented by computer software executable by the processor 710 of the device 700, or by hardware, or by a combination of software and hardware. The processor 710 may be configured to implement various example embodiments of the present disclosure.
[0124] The memory 720 may be of any type suitable for the local technology network and may be implemented using any suitable data storage technology, such as non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory, as non-limiting examples. Although only one memory 720 is shown in the device 700, multiple physically distinct memory modules may be present in the device 700. The processor 710 may be of any type suitable for the local technology network and may include one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture, as non-limiting examples. The device 700 may have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock that synchronizes a main processor.
[0125] When the device 700 acts as the first device 110 or a part of the first device 110, the processor 710 and the communication module 730 may cooperate to implement the above-mentioned Figure 2 The method 200 described above. Figures 1 to 6 All operations and features described are also applicable to process 700 and have similar effects. For simplicity, details will be omitted.
[0126] In general, various example embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor, or other computing device. Although various aspects of the example embodiments of the present disclosure are illustrated and described as block diagrams, flow charts, or using some other illustrations, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof.
[0127] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer executable instructions, such as those included in a program module, which are executed in a device on a target real or virtual processor to perform the above referenced Figure 2 The method 200 described. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various example embodiments, the functionality of program modules can be combined or split between program modules as needed. The machine executable instructions of program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in both local and remote storage media.
[0128] The program code for executing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code, when executed by the processor or controller, enables the function / operation specified in the flow chart and / or block diagram to be realized. The program code can be executed completely on the machine, partially on the machine, executed as an independent software package, partially on the machine and partially on a remote machine, or completely on a remote computer or server.
[0129] In the context of the present disclosure, computer program codes or related data may be carried by any suitable carrier to enable a device, apparatus or processor to perform various processes and operations as described above. Examples of carriers include signals and computer-readable media.
[0130] Computer readable medium can be computer readable signal medium or computer readable storage medium.Computer readable medium can include but not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or equipment or any suitable combination of the foregoing.More specific examples of computer readable storage medium will include electrical connection with one or more wires, portable computer floppy disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), optical storage device, magnetic storage device or any suitable combination of the foregoing.
[0131] In addition, although the operations are described in a specific order, this should not be understood as requiring such operations to be performed in the specific order shown or in sequence, or requiring the execution of all the operations shown to obtain the desired result. In some cases, multitasking and parallel processing can be advantageous. Similarly, although several specific implementation details are included in the above discussion, these details should not be interpreted as limitations on the scope of the present disclosure, but can be interpreted as descriptions of features peculiar to specific example embodiments. Certain features described in the context of separate example embodiments may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple example embodiments individually or in any suitable sub-combination.
[0132] Although the disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
[0133] Various example embodiments of these techniques have been described. In addition to or as an alternative to the above, the following embodiments are described. Features described in any of the following examples can be used with any of the other examples described herein.
[0134] In some aspects, a method includes: performing timing synchronization at a first device with a second device; generating a first random media access control address (RMA) for communicating with the second device according to rule configuration information at a first time instance; generating a second RMA for communicating with the second device according to the rule configuration information at a second time instance. The rule configuration information includes a time instruction, the time instruction including information corresponding to the first time instance and information about a time period starting from the first time instance and ending at the second time instance.
[0135] In some example embodiments, the method further includes: sending capability information of the first device associated with RMA generation to the second device; and receiving rule configuration information from the second device, the rule configuration information determined by the second device based at least in part on the capability information of the first device.
[0136] In some example embodiments, the method further comprises receiving, from the second device, a request for capability information of the first device.
[0137] In some example embodiments, the method further includes: receiving capability information of the second device associated with RMA generation from the second device; determining rule configuration information based at least in part on the capability information of the second device; and sending the rule configuration information to the second device.
[0138] In some example embodiments, the method further comprises sending a request for capability information of the second device to the second device.
[0139] In some example embodiments, the method further comprises: receiving a rule configuration update from the second device; and updating the rule configuration information based on the rule configuration update.
[0140] In some example embodiments, the capability information comprises at least one of: at least one rule for RMA generation; or at least one indication of supported timing synchronization methods.
[0141] In some example embodiments, the rule configuration information also includes at least one of: an indication of a rule determined from at least one rule; an indication of an applicable association phase; one or more reference identifiers; an indication of a timing synchronization method; an indication associated with activation of a determined rule; or an indication of a trigger generated by an RMA.
[0142] In some example embodiments, the indication of the timing synchronization mode is associated with timing synchronization function TSF information, and performing timing synchronization with the second device includes: acquiring TSF information from the second device; and performing timing synchronization with the second device based on the TSF information.
[0143] In some example embodiments, the indication of the timing synchronization mode is associated with a time from a third device, and performing timing synchronization with the second device includes: obtaining the time from the third device; and performing timing synchronization with the second device based on the time obtained from the third device.
[0144] In some example embodiments, the indication of the applicable association phase includes at least one of: a pre-association phase; a post-association phase; or an association period.
[0145] In some example embodiments, the one or more reference identifiers include at least one of: an RMA; a public key; a private key; a shared key; a signature; or a device identifier.
[0146] In some example embodiments, the rule configuration information includes one or more reference identifiers, and generating a first RMA includes: generating the first RMA by using a first time instance and the one or more reference identifiers as input parameters; and generating a second RMA includes: generating the second RMA by using a second time instance and the one or more reference identifiers as input parameters.
[0147] In some example embodiments, the method further includes: receiving a target RMA from the second device; and identifying the second device based on a comparison between the current RMA and the target RMA.
[0148] In some example embodiments, the received target RMA is determined based at least on at least one reference identifier, and identifying the second device comprises identifying the second device based on a comparison between the current RMA and the target RMA and an association between the target RMA and the at least one reference identifier.
[0149] In some aspects, a device includes: at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to: perform timing synchronization with a second device; generate a first random media access control address RMA for communicating with the second device according to rule configuration information at a first time instance; and generate a second RMA for communicating with the second device according to the rule configuration information at a second time instance. The rule configuration information includes a time instruction, the time instruction including information corresponding to the first time instance, and information about a time period starting from the first time instance and ending at the second time instance.
[0150] In some example embodiments, the device is further configured to: send capability information of the device associated with RMA generation to a second device; and receive rule configuration information from the second device, the rule configuration information being determined by the second device at least in part based on the capability information of the device.
[0151] In some example embodiments, the device is further configured to receive a request for capability information of the device from a second device.
[0152] In some example embodiments, the device is further configured to: receive capability information of the second device associated with RMA generation from the second device; determine rule configuration information based at least in part on the capability information of the second device; and send the rule configuration information to the second device.
[0153] In some example embodiments, the device is further configured to send a request for capability information of the second device to the second device.
[0154] In some example embodiments, the device is further configured to: receive a rule configuration update from the second device; and update the rule configuration information based on the rule configuration update.
[0155] In some example embodiments, the capability information comprises at least one of: at least one rule for RMA generation; or at least one indication of supported timing synchronization methods.
[0156] In some example embodiments, the rule configuration information also includes at least one of: an indication of a rule determined from at least one rule; an indication of an applicable association phase; one or more reference identifiers; an indication of a timing synchronization method; an indication associated with activation of a determined rule; or an indication of a trigger generated by an RMA.
[0157] In some example embodiments, the indication of the timing synchronization mode is associated with timing synchronization function TSF information, and the device is caused to perform timing synchronization with the second device by: acquiring TSF information from the second device; and performing timing synchronization with the second device based on the TSF information.
[0158] In some example embodiments, the indication of the timing synchronization mode is associated with a time from a third device, and the device is caused to perform timing synchronization with the second device in the following manner: obtaining the time from the third device; and performing timing synchronization with the second device based on the time obtained from the third device.
[0159] In some example embodiments, the indication of the applicable association phase comprises at least one of: a pre-association phase; a post-association phase; or an association period.
[0160] In some example embodiments, the one or more reference identifiers include at least one of: an RMA; a public key; a private key; a shared key; a signature; or a device identifier.
[0161] In some example embodiments, the rule configuration information includes one or more reference identifiers, and the device is caused to generate a first RMA by using a first time instance and one or more reference identifiers as input parameters to generate the first RMA; and the device is caused to generate a second RMA by using a second time instance and one or more reference identifiers as input parameters to generate the second RMA.
[0162] In some example embodiments, the device is further configured to: receive a target RMA from the second device; and identify the second device based on a comparison between the current RMA and the target RMA.
[0163] In some example embodiments, the received target RMA is determined based at least on at least one reference identifier, and the device is caused to identify the second device by identifying the second device based on a comparison between the current RMA and the target RMA and an association between the target RMA and the at least one reference identifier.
[0164] In some aspects, an apparatus includes: means for performing timing synchronization with a second apparatus; means for generating, at a first time instance, a first random media access control address (RMA) for communicating with the second apparatus according to rule configuration information; means for generating, at a second time instance, a second RMA for communicating with the second apparatus according to the rule configuration information. The rule configuration information includes a time instruction including information corresponding to the first time instance and information about a time period starting at the first time instance and ending at the second time instance.
[0165] In some example embodiments, the apparatus further comprises: a component for sending capability information of the apparatus associated with RMA generation to a second apparatus; and a component for receiving rule configuration information from the second apparatus, the rule configuration information being determined by the second apparatus at least in part based on the capability information of the apparatus.
[0166] In some example embodiments, the apparatus further comprises means for receiving a request for capability information of the apparatus from a second apparatus.
[0167] In some example embodiments, the apparatus further comprises: a component for receiving capability information of the second apparatus associated with RMA generation from the second apparatus; a component for determining rule configuration information based at least in part on the capability information of the second apparatus; and a component for sending the rule configuration information to the second apparatus.
[0168] In some example embodiments, the method further comprises means for sending a request for capability information of the second device to the second device.
[0169] In some example embodiments, the method further includes: means for receiving a rule configuration update from the second device; and means for updating the rule configuration information based on the rule configuration update.
[0170] In some example embodiments, the capability information comprises at least one of: at least one rule for RMA generation; or at least one indication of supported timing synchronization methods.
[0171] In some example embodiments, the rule configuration information also includes at least one of: an indication of a rule determined from at least one rule; an indication of an applicable association phase; one or more reference identifiers; an indication of a timing synchronization method; an indication associated with activation of a determined rule; or an indication of a trigger generated by an RMA.
[0172] In some example embodiments, the indication of the timing synchronization mode is associated with timing synchronization function TSF information, and the component for performing timing synchronization with the second device includes: a component for obtaining TSF information from the second device; and a component for performing timing synchronization with the second device based on the TSF information.
[0173] In some example embodiments, the indication of the timing synchronization mode is associated with a time from a third device, and the component for performing timing synchronization with the second device includes: a component for obtaining the time from the third device; and a component for performing timing synchronization with the second device based on the time obtained from the third device.
[0174] In some example embodiments, the indication of the applicable association phase includes at least one of: a pre-association phase; a post-association phase; or an association period.
[0175] In some example embodiments, the one or more reference identifiers include at least one of: an RMA; a public key; a private key; a shared key; a signature; or a device identifier.
[0176] In some example embodiments, the rule configuration information includes one or more reference identifiers, and the component for generating a first RMA includes: a component for generating the first RMA by using a first time instance and one or more reference identifiers as input parameters; and the component for generating a second RMA includes: a component for generating the second RMA by using a second time instance and one or more reference identifiers as input parameters.
[0177] In some example embodiments, the apparatus further comprises: means for receiving a target RMA from the second apparatus; and means for identifying the second apparatus based on a comparison between the current RMA and the target RMA.
[0178] In some example embodiments, the received target RMA is determined based at least on at least one reference identifier, and the component for identifying the second device includes: a component for identifying the second device based on a comparison between the current RMA and the target RMA and an association between the target RMA and the at least one reference identifier.
[0179] In some aspects, a computer-readable storage medium includes program instructions stored thereon, which when executed by a processor of a device causes the device to perform methods according to some example embodiments of the present disclosure.
Claims
1. A method comprising: At the first device, performing timing synchronization with a second device; At a first time instance, generating a first random media access control address RMA for communicating with the second device according to the rule configuration information; at a second time instance, generating a second RMA for communicating with the second device according to the rule configuration information; The rule configuration information includes a time instruction, wherein the time instruction includes information corresponding to the first time instance and information about a time period starting from the first time instance and ending at the second time instance.
2. The method according to claim 1, further comprising: sending capability information of the first device associated with RMA generation to the second device; as well as The rule configuration information is received from the second device, the rule configuration information being determined by the second device based at least in part on the capability information of the first device.
3. The method according to claim 2, further comprising: A request for the capability information of the first device is received from the second device.
4. The method according to claim 1, further comprising: receiving, from the second device, capability information of the second device associated with RMA generation; determining the rule configuration information based at least in part on the capability information of the second device; as well as Send the rule configuration information to the second device.
5. The method according to claim 4, further comprising: A request for the capability information of the second device is sent to the second device.
6. The method according to claim 1, further comprising: receiving a rule configuration update from the second device; as well as The rule configuration information is updated based on the rule configuration update.
7. The method according to any one of claims 2 to 5, wherein the capability information comprises at least one of the following: at least one rule for RMA generation; or At least one indication of supported timing synchronization methods.
8. The method according to claim 7, wherein the rule configuration information further includes at least one of the following: an indication of a rule determined from the at least one rule; Indications for applicable association phases; one or more reference identifiers; Indication of timing synchronization mode; an indication associated with activation of said determined rule; or An indication of a trigger generated by the RMA.
9. The method of claim 8, wherein the indication of the timing synchronization mode is associated with timing synchronization function (TSF) information, and wherein performing timing synchronization with the second device comprises: Acquire the TSF information from the second device; as well as Timing synchronization is performed with the second device based on the TSF information.
10. The method of claim 8, wherein the indication of the timing synchronization mode is associated with a time from a third device, and wherein performing timing synchronization with the second device comprises: Acquire the time from the third device; as well as Timing synchronization is performed with the second device based on the time acquired from the third device.
11. The method according to any one of claims 8 to 10, wherein the indication of the applicable association phase comprises at least one of the following: Pre-association stage; Post-association phase; or During the association period.
12. The method according to any one of claims 8 to 11, wherein the one or more reference identifiers include at least one of the following: RMA; Public key; Private key; Shared secret key; Signature; or Device identifier.
13. The method according to any one of claims 8 to 12, wherein the rule configuration information comprises one or more reference identifiers, and wherein: Generating the first RMA includes: generating the first RMA by using the first time instance and the one or more reference identifiers as input parameters; and Generating the second RMA includes generating the second RMA by using the second time instance and the one or more reference identifiers as input parameters.
14. The method according to any one of claims 1 to 13, further comprising: receiving a target RMA from the second device; as well as The second device is identified based on a comparison between a current RMA and the target RMA.
15. The method of claim 14, wherein the received target RMA is determined based at least on at least one reference identifier, and wherein identifying the second device comprises: Based on the comparison between the current RMA and the target RMA, and the association between the target RMA and the at least one reference identifier, the second device is identified.
16. A device comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: performing timing synchronization with a second device; At a first time instance, generating a first random media access control address RMA for communicating with the second device according to the rule configuration information; at a second time instance, generating a second RMA for communicating with the second device according to the rule configuration information; The rule configuration information includes a time instruction, wherein the time instruction includes information corresponding to the first time instance and information about a time period starting from the first time instance and ending at the second time instance.
17. The device according to claim 16, further configured to: sending capability information of the device associated with RMA generation to the second device; and The rule configuration information is received from the second device, the rule configuration information being determined by the second device based at least in part on the capability information of the device.
18. The device according to claim 17, further configured to: A request for the capability information of the device is received from the second device.
19. The device according to claim 16, further configured to: receiving, from the second device, capability information of the second device associated with RMA generation; determining the rule configuration information based at least in part on the capability information of the second device; and Send the rule configuration information to the second device.
20. The device according to claim 19, further configured to: A request for the capability information of the second device is sent to the second device.
21. The device according to claim 16, further configured to: receiving a rule configuration update from the second device; and The rule configuration information is updated based on the rule configuration update.
22. The apparatus according to any one of claims 17 to 20, wherein the capability information comprises at least one of the following: at least one rule for RMA generation; or At least one indication of supported timing synchronization methods.
23. The device according to claim 22, wherein the rule configuration information further includes at least one of the following: an indication of a rule determined from the at least one rule; Indications for applicable association phases; one or more reference identifiers; Indication of timing synchronization mode; an indication associated with activation of said determined rule; or An indication of a trigger generated by the RMA.
24. The device according to claim 23, wherein the indication of the timing synchronization mode is associated with timing synchronization function (TSF) information, and wherein the device is caused to perform timing synchronization with the second device in the following manner: Acquire the TSF information from the second device; and Timing synchronization is performed with the second device based on the TSF information.
25. The device of claim 23, wherein the indication of the timing synchronization manner is associated with a time from a third device, and wherein the device is caused to perform timing synchronization with the second device by: Acquire the time from the third device; and Timing synchronization is performed with the second device based on the time acquired from the third device.
26. The apparatus of any one of claims 23 to 25, wherein the indication of the applicable association phase comprises at least one of: Pre-association stage; Post-association phase; or During the association period.
27. The apparatus of any one of claims 23 to 26, wherein the one or more reference identifiers include at least one of: RMA; Public key; Private key; Shared secret key; Signature; or Device identifier.
28. The apparatus according to any one of claims 23 to 27, wherein the rule configuration information comprises one or more reference identifiers, and wherein: The apparatus is caused to generate the first RMA by: generating the first RMA using the first time instance and the one or more reference identifiers as input parameters; and The apparatus is caused to generate the second RMA by using the second time instance and the one or more reference identifiers as input parameters to generate the second RMA.
29. The apparatus according to any one of claims 16 to 28, further configured to: receiving a target RMA from the second device; and The second device is identified based on a comparison between a current RMA and the target RMA.
30. The apparatus of claim 29, wherein the received target RMA is determined based at least on at least one reference identifier, and wherein the apparatus is caused to identify the second apparatus by: Based on the comparison between the current RMA and the target RMA, and the association between the target RMA and the at least one reference identifier, the second device is identified.
31. An apparatus comprising: means for performing timing synchronization with a second device; means for generating, at a first time instance, a first random media access control address RMA for communicating with a second device according to the rule configuration information; means for generating, at a second time instance, a second RMA for communicating with a second device based on the rule configuration information; The rule configuration information includes a time instruction, wherein the time instruction includes information corresponding to the first time instance and information about a time period starting from the first time instance and ending at the second time instance.
32. A computer-readable storage medium comprising program instructions stored thereon, which instructions, when executed by a processor of a device, cause the device to perform the method according to any one of claims 1 to 15.