Patent Description:
A peer aware communication (PAC) network is a fully distributed communication network that allows direct communication among the PAC devices (PDs). A PAC device is an electronic device that has communication capability. Additionally, The PAC device can also have ranging capability. The PAC device may be referred to as a ranging device (RDEV), or an enhanced ranging device (ERDEV), or a secure ranging device (SRDEV) or any other similar name. RDEV, ERDEV, or SRDEV can be a part of an access point (AP), a station (STA), an eNB, a gNB, a UE, or any other communication node with ranging capability as defined in IEEE standard specification. PAC networks may employ several topologies like mesh, star, etc. to support interactions among the PDs for various services. Document <NPL>, discloses protocol and compatible interconnection for data communication devices using low data-rate, low-power, and low-complexity short-range radio frequency (RF) transmissions in a wireless personal area network (WPAN). Another document <NPL>, discloses enhanced ultra wide band physical layers and associated ranging techniques.

Embodiments of the present disclosure provide frameworks and methods for specifying receiver enable times in UWB communication and ranging systems.

In one embodiment, a network entity in a wireless communication system supporting ranging capability is provided. The network entity comprises a transceiver. The network entity further comprises a processor operably connected to the transceiver, the processor configured to: identify a medium access control (MAC) sublayer management entity-receive-enable request (MLME-RX-ENABLE. request) primitive including a list of ranging scheduling time unit (RSTU) counter (RxOnTime) values and a number of RSTUs (RxOnDuration), wherein the MLME-RX-ENABLE. request primitive is sent to a MAC layer from a higher layer; in response to identifying the MLME-RX-ENABLE. request primitive, identify a value of a MAC RSTU counter (MAC RSTU_COUNTER); determine whether the value of the MAC RSTU_COUNTER is set to an RxOnTime value included in the list of the RxOnTime values of the MILME-RX-ENABLE. request primitive; increase the value of the MAC RSTU_COUNTER; determine whether the transceiver receives, from another network entity, a frame based on the value of the MAC RSTU_COUNTER; and in response to determining that the transceiver receives the frame, generate a MAC common part sublayer indication (MCPS-DATA. indication) primitive.

In another embodiment, a method of a network entity in a wireless communication system supporting ranging capability is provided. The method comprises: identifying a medium access control (MAC) sublayer management entity-receive-enable request (MLME-RX-ENABLE. request) primitive including a list of ranging scheduling time unit (RSTU) counter (RxOnTime) values and a number of RSTUs (RxOnDuration), wherein the MLME-RX-ENABLE. request primitive is sent to a MAC layer from a higher layer; in response to identifying the MLME-RX-ENABLE. request primitive, identifying a value of a MAC RSTU counter (MAC RSTU_COUNTER); determining whether the value of the MAC RSTU_COUNTER is set to an RxOnTime value included in the list of the RxOnTime values of the MLME-RX-ENABLE. request primitive; increasing the value of the MAC RSTU_COUNTER; determining whether a frame is received from another network entity based on the value of the MAC RSTU_COUNTER; and in response to determining that the frame is received, generating a MAC common part sublayer indication (MCPS-DATA. indication) primitive.

In yet another embodiment, a non-transitory computer-readable medium comprising program code, that when executed by at least one processor, causes a network entity to in a wireless communication system supporting ranging capability is provided. The non-transitory computer-readable medium causes the network entity to configure to: identify a medium access control (MAC) sublayer management entity-receive-enable request (MLME-RX-ENABLE. request) primitive including a list of ranging scheduling time unit (RSTU) counter (RxOnTime) values and a number of RSTUs (RxOnDuration), wherein the MLME-RX-ENABLE. request primitive is sent to a MAC layer from a higher layer; in response to identifying the MLME-RX-ENABLE. request primitive, identify a value of a MAC RSTU counter (MAC RSTU_COUNTER); determine whether the value of the MAC RSTU_COUNTER is set to an RxOnTime value included in the list of the RxOnTime values of the MLME-RX-ENABLE. request primitive; increase the value of the MAC RSTU_COUNTER; determine whether a transceiver receives, from another network entity, a frame based on the value of the MAC RSTU_COUNTER; and in response to determining that the transceiver receives the frame, generate a MAC common part sublayer indication (MCPS-DATA. indication) primitive.

The term "ranging," as well as derivatives thereof, mean that the fundamental measurements for ranging between devices are achieved by a transmission and a reception of one or more messages. The term "controller" means any device, system, or part thereof that controls at least one operation. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.

The following documents and standards descriptions are related prior art: IEEE Standard for Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Peer Aware Communications, IEEE Std <NUM>. <NUM>, <NUM>; IEEE Standard Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs), Amendment <NUM>: Add Alternative PHYs, IEEE Std <NUM>. 4a (<NUM>); IEEE Standard for Low-Rate Wireless Networks, IEEE Std <NUM>. <NUM> (<NUM>); and IEEE <NUM>.

Aspects, features, and advantages of the disclosure are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and implementations, including the best mode contemplated for carrying out the disclosure. The disclosure is also capable of other and different embodiments, and its several details can be modified in various obvious respects, all without departing from the scope of the disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive. The disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

<FIG> below describe various embodiments implemented in wireless communications systems and with the use of orthogonal frequency division multiplexing (OFDM) or orthogonal frequency division multiple access (OFDMA) communication techniques. The descriptions of <FIG> are not meant to imply physical or architectural limitations to the manner in which different embodiments may be implemented. Different embodiments of the present disclosure may be implemented in any suitably arranged communications system.

Other embodiments of the wireless network <NUM> could be used without departing from the scope of the present disclosure.

As shown in <FIG>, the wireless network includes a gNB <NUM> (e.g., base station (BS)), a gNB <NUM>, and a gNB <NUM>. The gNB <NUM> communicates with the gNB <NUM> and the gNB <NUM>. The gNB <NUM> also communicates with at least one network <NUM>, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network.

The gNB <NUM> provides wireless broadband access to the network <NUM> for a first plurality of user equipments (UEs) within a coverage area <NUM> of the gNB <NUM>. The first plurality of UEs includes a UE <NUM>, which may be located in a small business (SB); a UE <NUM>, which may be located in an enterprise (E); a UE <NUM>, which may be located in a WiFi hotspot (HS); a UE <NUM>, which may be located in a first residence (R); a UE <NUM>, which may be located in a second residence (R); and a UE <NUM>, which may be a mobile device (M), such as a cell phone, a wireless laptop, a wireless PDA, or the like. The gNB <NUM> provides wireless broadband access to the network <NUM> for a second plurality of UEs within a coverage area <NUM> of the gNB <NUM>. The second plurality of UEs includes the UE <NUM> and the UE <NUM>. In some embodiments, one or more of the gNBs <NUM>-<NUM> may communicate with each other and with the UEs <NUM>-<NUM> using <NUM>, LTE, LTE-A, WiMAX, WiFi, or other wireless communication techniques.

Depending on the network type, the term "base station" or "BS" can refer to any component (or collection of components) configured to provide wireless access to a network, such as transmit point (TP), transmit-receive point (TRP), an enhanced base station (eNodeB or eNB), a <NUM> base station (gNB), a macrocell, a femtocell, a WiFi access point (AP), or other wirelessly enabled devices. Base stations may provide wireless access in accordance with one or more wireless communication protocols, e.g., <NUM> 3GPP new radio interface/access (NR), long term evolution (LTE), LTE advanced (LTE-A), high speed packet access (HSPA), Wi-Fi <NUM>. 11a/b/g/n/ac, etc. For the sake of convenience, the terms "BS" and "TRP" are used interchangeably in this patent document to refer to network infrastructure components that provide wireless access to remote terminals. Also, depending on the network type, the term "user equipment" or "UE" can refer to any component such as "mobile station," "subscriber station," "remote terminal," "wireless terminal," "receive point," or "user device. " For the sake of convenience, the terms "user equipment" and "UE" are used in this patent document to refer to remote wireless equipment that wirelessly accesses a BS, whether the UE is a mobile device (such as a mobile telephone or smartphone) or is normally considered a stationary device (such as a desktop computer or vending machine).

As described in more detail below, one or more of the UEs <NUM>-<NUM> include circuitry, programing, or a combination thereof, for utilizing a framework for specifying receiver enable times in UWB communication and ranging systems. In certain embodiments, and one or more of the gNBs <NUM>-<NUM> includes circuitry, programing, or a combination thereof, for utilizing a framework for specifying receiver enable times in UWB communication and ranging systems.

However, gNBs come in a wide variety of configurations, and <FIG> does not limit the scope of the present disclosure to any particular implementation of a gNB.

The controller/processor <NUM> can include one or more processors or other processing devices that control the overall operation of the gNB <NUM>. For example, the controller/processor <NUM> could control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceivers 210a-210n, the RX processing circuitry <NUM>, and the TX processing circuitry <NUM> in accordance with well-known principles. The controller/processor <NUM> could support additional functions as well, such as more advanced wireless communication functions.

For instance, the controller/processor <NUM> could support beam forming or directional routing operations in which outgoing signals from multiple antennas 205a-205n are weighted differently to effectively steer the outgoing signals in a desired direction. Any of a wide variety of other functions could be supported in the gNB <NUM> by the controller/processor <NUM>.

However, UEs come in a wide variety of configurations, and <FIG> does not limit the scope of the present disclosure to any particular implementation of a UE.

The processor <NUM> is also capable of executing other processes and programs resident in the memory <NUM>, such as processes for CSI reporting on uplink channel. The processor <NUM> can move data into or out of the memory <NUM> as required by an executing process. In some embodiments, the processor <NUM> is configured to execute the applications <NUM> based on the OS <NUM> or in response to signals received from gNBs or an operator. The processor <NUM> is also coupled to the I/O interface <NUM>, which provides the UE <NUM> with the ability to connect to other devices, such as laptop computers and handheld computers. The I/O interface <NUM> is the communication path between these accessories and the processor <NUM>.

<FIG> is a high-level diagram of transmit path circuitry. For example, the transmit path circuitry may be used for an orthogonal frequency division multiple access (OFDMA) communication. <FIG> is a high-level diagram of receive path circuitry. For example, the receive path circuitry may be used for an orthogonal frequency division multiple access (OFDMA) communication. In <FIG> and <FIG>, for downlink communication, the transmit path circuitry may be implemented in a base station (gNB) <NUM> or a relay station, and the receive path circuitry may be implemented in a user equipment (e.g., user equipment <NUM> of <FIG>). In other examples, for uplink communication, the receive path circuitry <NUM> may be implemented in a base station (e.g., gNB <NUM> of <FIG>) or a relay station, and the transmit path circuitry may be implemented in a user equipment (e.g., user equipment <NUM> of <FIG>).

Transmit path circuitry comprises channel coding and modulation block <NUM>, serial-to-parallel (S-to-P) block <NUM>, Size N Inverse Fast Fourier Transform (IFFT) block <NUM>, parallel-to-serial (P-to-S) block <NUM>, add cyclic prefix block <NUM>, and up-converter (UC) <NUM>. Receive path circuitry <NUM> comprises down-converter (DC) <NUM>, remove cyclic prefix block <NUM>, serial-to-parallel (S-to-P) block <NUM>, Size N Fast Fourier Transform (FFT) block <NUM>, parallel-to-serial (P-to-S) block <NUM>, and channel decoding and demodulation block <NUM>.

At least some of the components in <FIG> <NUM> and <FIG> <NUM> may be implemented in software, while other components may be implemented by configurable hardware or a mixture of software and configurable hardware. In particular, it is noted that the FFT blocks and the IFFT blocks described in the present disclosure document may be implemented as configurable software algorithms, where the value of Size N may be modified according to the implementation.

Furthermore, although the present disclosure is directed to an embodiment that implements the Fast Fourier Transform and the Inverse Fast Fourier Transform, this is by way of illustration only and may not be construed to limit the scope of the present disclosure. It may be appreciated that in an alternate embodiment of the present disclosure, the Fast Fourier Transform functions and the Inverse Fast Fourier Transform functions may easily be replaced by discrete Fourier transform (DFT) functions and inverse discrete Fourier transform (IDFT) functions, respectively. It may be appreciated that for DFT and IDFT functions, the value of the N variable may be any integer number (i.e., <NUM>, <NUM>, <NUM>, <NUM>, etc.), while for FFT and IFFT functions, the value of the N variable may be any integer number that is a power of two (i.e., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.).

In transmit path circuitry <NUM>, channel coding and modulation block <NUM> receives a set of information bits, applies coding (e.g., LDPC coding) and modulates (e.g., quadrature phase shift keying (QPSK) or quadrature amplitude modulation (QAM)) the input bits to produce a sequence of frequency-domain modulation symbols. Serial-to-parallel block <NUM> converts (i.e., de-multiplexes) the serial modulated symbols to parallel data to produce N parallel symbol streams where N is the IFFT/FFT size used in BS <NUM> and UE <NUM>. Size N IFFT block <NUM> then performs an IFFT operation on the N parallel symbol streams to produce time-domain output signals. Parallel-to-serial block <NUM> converts (i.e., multiplexes) the parallel time-domain output symbols from Size N IFFT block <NUM> to produce a serial time-domain signal. Add cyclic prefix block <NUM> then inserts a cyclic prefix to the time-domain signal. Finally, up-converter <NUM> modulates (i.e., up-converts) the output of add cyclic prefix block <NUM> to RF frequency for transmission via a wireless channel. The signal may also be filtered at baseband before conversion to RF frequency.

The transmitted RF signal arrives at the UE <NUM> after passing through the wireless channel, and reverse operations to those at the gNB <NUM> are performed. Down-converter <NUM> down-converts the received signal to baseband frequency and remove cyclic prefix block <NUM> removes the cyclic prefix to produce the serial time-domain baseband signal. Serial-to-parallel block <NUM> converts the time-domain baseband signal to parallel time-domain signals. Size N FFT block <NUM> then performs an FFT algorithm to produce N parallel frequency-domain signals. Parallel-to-serial block <NUM> converts the parallel frequency-domain signals to a sequence of modulated data symbols. Channel decoding and demodulation block <NUM> demodulates and then decodes the modulated symbols to recover the original input data stream.

Each of gNBs <NUM>-<NUM> may implement a transmit path that is analogous to transmitting in the downlink to user equipment <NUM>-<NUM> and may implement a receive path that is analogous to receiving in the uplink from user equipment <NUM>-<NUM>. Similarly, each one of user equipment <NUM>-<NUM> may implement a transmit path corresponding to the architecture for transmitting in the uplink to gNBs <NUM>-<NUM> and may implement a receive path corresponding to the architecture for receiving in the downlink from gNBs <NUM>-<NUM>.

A peer aware communication (PAC) network is a fully distributed communication network that allows direct communication among the PAC devices (PDs). A wireless personal area network (WPAN) or simply a personal area network (PAN) may be a fully distributed communication network. A WPAN or PAN is communication network that allows wireless connectivity among the PAN devices (PDs). PAN devices and PAC devices may be interchangeably used as PAC network is also a PAN network and vice versa.

PAC networks may employ several topologies like mesh, star, and/or peer-to-peer, etc. to support interactions among the PDs for various services. While the present disclosure uses PAC networks and PDs as an example to develop and illustrate the present disclosure, it is to be noted that the present disclosure is not confined to these networks. The general concepts developed in the present disclosure may be employed in various type of networks with different kind of scenarios.

<FIG> illustrates an example electronic device <NUM> according to embodiments of the present disclosure. The embodiment of the electronic device <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation.

PDs can be an electronic device that may have communication and ranging capability. The electronics device may be referred to as a ranging device (RDEV), or an enhanced ranging device (ERDEV), or a secure ranging device (SRDEV) or any other similar name in accordance with the IEEE standard specification. RDEV, ERDEV, or SRDEV can be a part of an access point (AP), a station (STA), an eNB, a gNB, a UE, or any other communication node with ranging capability.

According to an embodiment, the electronic device <NUM> may include a processor <NUM>, memory <NUM>, an input device <NUM>, a sound output device <NUM>, a display device <NUM>, an audio <NUM>, a sensor <NUM>, an interface <NUM>, a haptic <NUM>, a camera <NUM>, a power management <NUM>, a battery <NUM>, a communication interface <NUM>, a subscriber identification module (SIM) <NUM>, or an antenna <NUM>. In some embodiments, at least one (e.g., the display device <NUM> or the camera <NUM>) of the components may be omitted from the electronic device <NUM>, or one or more other components may be added in the electronic device <NUM>. For example, the sensor <NUM> (e.g., a fingerprint sensor, an iris sensor, or an illuminance sensor) may be implemented as embedded in the display device <NUM> (e.g., a display).

The processor <NUM> may execute, for example, software (e.g., a program <NUM>) to control at least one other component (e.g., a hardware or software component) of the electronic device <NUM> coupled with the processor <NUM> and may perform various data processing or computation. According to one embodiment of the present disclosure, as at least part of the data processing or computation, the processor <NUM> may load a command or data received from another component (e.g., the sensor <NUM> or the communication interface <NUM>) in volatile memory <NUM>, process the command or the data stored in the volatile memory <NUM>, and store resulting data in non-volatile memory <NUM>.

According to an embodiment of the present disclosure, the processor <NUM> may include a main processor <NUM> (e.g., a central processing unit (CPU) or an application processor (AP)), and an auxiliary processor <NUM> (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) that is operable independently from, or in conjunction with, the main processor <NUM>.

The auxiliary processor <NUM> may control at least some of functions or states related to at least one component (e.g., the display device <NUM>, the sensor <NUM>, or the communication interface <NUM>) among the components of the electronic device <NUM>, instead of the main processor <NUM> while the main processor <NUM> is in an inactive (e.g., sleep) state, or together with the main processor <NUM> while the main processor <NUM> is in an active state (e.g., executing an application). According to an embodiment, the auxiliary processor <NUM> (e.g., an image signal processor or a communication processor) may be implemented as part of another component (e.g., the camera <NUM> or the communication interface <NUM>) functionally related to the auxiliary processor <NUM>.

The memory <NUM> may store various data used by at least one component (e.g., the processor <NUM> or the sensor <NUM>) of the electronic device <NUM>.

The input device <NUM> may receive a command or data to be used by other components (e.g., the processor <NUM>) of the electronic device <NUM>, from the outside (e.g., a user) of the electronic device <NUM>.

The display device <NUM> may include, for example, a display, a hologram device, or a projector and control circuitry to control a corresponding one of the displays, hologram device, and projector.

The audio <NUM> may convert a sound into an electrical signal and vice versa. According to an embodiment, the audio <NUM> may obtain the sound via the input device <NUM>, or output the sound via the sound output device <NUM> or a headphone of an external electronic device (e.g., an electronic device <NUM>) directly (e.g., using wired line) or wirelessly coupled with the electronic device <NUM>.

The sensor <NUM> may detect an operational state (e.g., power or temperature) of the electronic device #<NUM> or an environmental state (e.g., a state of a user) external to the electronic device <NUM>, and then generate an electrical signal or data value corresponding to the detected state. According to an embodiment, the sensor <NUM> may include, for example, a gesture sensor, a gyro sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

The interface <NUM> may support one or more specified protocols to be used for the electronic device <NUM> to be coupled with the external electronic device (e.g., the electronic device <NUM>) directly (e.g., using wired line) or wirelessly. According to an embodiment of the present disclosure, the interface <NUM> may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.

The haptic <NUM> may convert an electrical signal into a mechanical stimulus (e.g., a vibration or a movement) or electrical stimulus which may be recognized by a user via his tactile sensation or kinesthetic sensation. According to an embodiment, the haptic <NUM> may include, for example, a motor, a piezoelectric element, or an electric stimulator.

The camera <NUM> may capture a still image or moving images. According to an embodiment of the present disclosure, the camera <NUM> may include one or more lenses, image sensors, image signal processors, or flashes.

The power management <NUM> may manage power supplied to the electronic device <NUM>. According to one embodiment, the power management <NUM> may be implemented as at least part of, for example, a power management integrated circuit (PMIC).

The communication interface <NUM> may support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device <NUM> and the external electronic device (e.g., the electronic device <NUM>, the electronic device <NUM>, or the server <NUM>) and performing communication via the established communication channel. The communication interface <NUM> may include one or more communication processors that are operable independently from the processor <NUM> (e.g., the application processor (AP)) and supports a direct (e.g., wired) communication or a wireless communication.

According to an embodiment of the present disclosure, the communication interface <NUM> may include a wireless communication interface <NUM> (e.g., a cellular communication interface, a short-range wireless communication interface, or a global navigation satellite system (GNSS) communication interface) or a wired communication interface <NUM> (e.g., a local area network (LAN) communication interface or a power line communication (PLC)). A corresponding one of these communication interfaces may communicate with the external electronic device via the first network <NUM> (e.g., a short-range communication network, such as Bluetooth, wireless-fidelity (Wi-Fi) direct, ultra-wide band (UWB), or infrared data association (IrDA)) or the second network <NUM> (e.g., a long-range communication network, such as a cellular network, the Internet, or a computer network (e.g., LAN or wide area network (WAN)).

These various types of communication interfaces may be implemented as a single component (e.g., a single chip), or may be implemented as multi components (e.g., multi chips) separate from each other. The wireless communication interface <NUM> may identify and authenticate the electronic device <NUM> in a communication network, such as the first network <NUM> or the second network <NUM>, using subscriber information (e.g., international mobile subscriber identity (IMSI)) stored in the subscriber identification module <NUM>.

The antenna <NUM> may transmit or receive a signal or power to or from the outside (e.g., the external electronic device) of the electronic device <NUM>. According to an embodiment, the antenna <NUM> may include an antenna including a radiating element composed of a conductive material or a conductive pattern formed in or on a substrate (e.g., PCB). According to an embodiment, the antenna <NUM> may include a plurality of antennas. In such a case, at least one antenna appropriate for a communication scheme used in the communication network, such as the first network <NUM> or the second network <NUM>, may be selected, for example, by the communication interface <NUM> (e.g., the wireless communication interface <NUM>) from the plurality of antennas. The signal or the power may then be transmitted or received between the communication interface <NUM> and the external electronic device via the selected at least one antenna. According to an embodiment, another component (e.g., a radio frequency integrated circuit (RFIC)) other than the radiating element may be additionally formed as part of the antenna <NUM>.

At least some of the above-described components may be coupled mutually and communicate signals (e.g., commands or data) there between via an inter-peripheral communication scheme (e.g., a bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)).

According to an embodiment of the present disclosure, commands or data may be transmitted or received between the electronic device <NUM> and the external electronic device <NUM> via the server <NUM> coupled with the second network <NUM>. For example, if the electronic device <NUM> may perform a function or a service automatically, or in response to a request from a user or another device, the electronic device <NUM>, instead of, or in addition to, executing the function or the service, may request the one or more external electronic devices to perform at least part of the function or the service. The one or more external electronic devices receiving the request may perform the at least part of the function or the service requested, or an additional function or an additional service related to the request and transfer an outcome of the performing to the electronic device <NUM>.

According to an embodiment of the present disclosure, the electronic devices are not limited to those described above.

According to an embodiment of the present disclosure, a method according to various embodiments of the present disclosure may be included and provided in a computer program product.

According to various embodiments of the present disclosure, each component (e.g., a module or a program) of the above-described components may include a single entity or multiple entities. In such a case, according to various embodiments, the integrated component may still perform one or more functions of each of the plurality of components in the same or similar manner as one or more functions are performed by a corresponding one of the plurality of components before the integration.

A ranging block is a time period for ranging. Each ranging block includes an integer multiple of ranging rounds, where a ranging round is the time period to complete of one entire range-measuring cycle involving the set of RDEV participating in the ranging measuring. Each ranging round is further subdivided into an integer number of ranging slots, where a ranging slot is a period of time of sufficient length for the transmission of at least one RFRAME.

<FIG> illustrates an example ranging configuration <NUM> according to embodiments of the present disclosure. The embodiment of the ranging configuration <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the ranging configuration <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the ranging configuration <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

<FIG> shows the ranging block Structure, with the ranging block divided into N ranging rounds, each consisting of M ranging slots.

The general ranging round structure includes a ranging control period in which a ranging control message is transmitted to configure the ranging rounds. It is followed by one or more ranging periods and data periods. These data periods usually include transmission of ranging related data using certain information elements (IE) defined within the standard. The most generic ranging round structure is as shown in <FIG>.

<FIG> illustrates an example general ranging round structure <NUM> according to embodiments of the present disclosure. The embodiment of the general ranging round structure <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the general ranging round structure <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the general ranging round structure <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

In the present disclosure, following nomenclature is used: controller: a ranging device that defines and controls the ranging parameters by sending ranging control message in ranging control period; controlee: a Ranging device that utilizes the ranging parameters received from the controller; initiator: a ranging device that initiates a ranging exchange by sending the first message of the exchange or the device that send ranging ancillary data (in payload)/data; and responder: a ranging device that receives ranging ancillary data (in payload)/data and/or responds to the message received from the initiator.

<FIG> illustrates an example ranging controller, controlee, initiator, and responder <NUM> according to embodiments of the present disclosure. The embodiment of the ranging controller, controlee, initiator, and responder <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation.

A relevant IE for this is the advanced ranging control IE as shown in that is usually transmitted during the ranging control period. The advanced ranging control IE (ARC IE) is used by a controller to send the ranging configuration <NUM> information to a controlee (in a unicast frame) or multiple controlees (in multicast/broadcast frame). The content field of the ARC IE maybe formatted as shown in <FIG>.

<FIG> illustrates an example advanced ranging control IE as defined in <NUM>. 4z <NUM> according to embodiments of the present disclosure. The embodiment of the advanced ranging control IE as defined in <NUM>. 4z <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the advanced ranging control IE as defined in <NUM>. 4z <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the advanced ranging control IE as defined in <NUM>. 4z <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

Ranging mode values are shown in TABLE <NUM>. Other details of the ARC IE can be found in the IEEE standard specification.

Alternative structure of the advanced ranging control IE in <NUM>. 4z based on revisions is as shown in <FIG>.

<FIG> illustrates an example advanced ranging control IE content field format as defined in <NUM>. 4z <NUM> according to embodiments of the present disclosure. The embodiment of the advanced ranging control IE content field format as defined in <NUM>. 4z <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the advanced ranging control IE content field format as defined in <NUM>. 4z <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the advanced ranging control IE content field format as defined in <NUM>. 4z <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

For the scheduling-based ranging with multiple devices, the ranging scheduling (RS) IE can be used to convey the resource assignment, which includes the field of RS table and RS table length as illustrated in <FIG>. The field of RS table length indicates the number of rows in the RS table.

<FIG> illustrates an example ranging scheduling IE <NUM> according to embodiments of the present disclosure. The embodiment of the ranging scheduling IE <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the ranging scheduling IE <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the ranging scheduling IE <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

<FIG> illustrates an example row of ranging scheduling table <NUM> according to embodiments of the present disclosure. The embodiment of the row of ranging scheduling table <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the row of ranging scheduling table <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the row of ranging scheduling table <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

Each row of The RS table includes a slot index field for a time slot, an address field of the device assigned to this slot, and a device type field to indicate the role of the assigned device as illustrated in <FIG>. Depending on device capability and vendor specification, different types of address can be used. If a device type for a specific address is <NUM>, the device is a responder. Otherwise, the device is an initiator.

<FIG> illustrates example service primitives <NUM> according to embodiments of the present disclosure. The embodiment of the service primitives <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the service primitives <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the service primitives <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

The services of a layer are the capabilities the layer offers to the user in the next higher layer or sublayer by building the layer' functions on the services of the next lower layer. This concept is illustrated in <FIG>, showing the service hierarchy and the relationship of the two correspondent users and their associated layer (or sublayer) peer protocol entities.

The services are specified by describing the information flow between the N-user and the N-layer. This information flow is modeled by discrete, instantaneous events, which characterize the provision of a service. Each event consists of passing a service primitive from one layer to the other through a layer service access point (SAP) associated with an N-user. Service primitives convey the required information by providing a particular service. These service primitives are an abstraction because These service primitives specify only the provided service rather than the means by which the service is provided. This definition is independent of any other interface implementation. A service is specified by describing the service primitives and parameters that characterize it.

A primitive can be one of four generic types: (<NUM>) Request: the request primitive is used to request that a service is initiated; (<NUM>) Indication: the indication primitive is used to indicate to the user an internal event; (<NUM>) Response: the response primitive is used to complete a procedure previously invoked by an indication primitive; and (<NUM>) Confirm: the confirm primitive is used to convey the results of one or more associated previous service requests.

The MAC sublayer provides an interface between the next higher layer and the PHY. The MAC sublayer conceptually includes a management entity called the MLME. This entity provides the service interfaces through which layer management may be invoked. The MLME is also responsible for maintaining a database of managed objects pertaining to the MAC sublayer. This database is referred to as the MAC sublayer PIB.

<FIG> illustrates an example MAC sublayer reference model <NUM> according to embodiments of the present disclosure. The embodiment of the MAC sublayer reference model <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the MAC sublayer reference model <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the MAC sublayer reference model <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

The MAC sublayer provides two services, accessed through two SAPs: (<NUM>) the MAC data service, accessed through the MAC common part sublayer (MCPS) data SAP (MCPS-SAP); and (<NUM>) the MAC management service, accessed through the MAC layer management entity SAP (MLME-SAP).

These two services provide the interface between the next higher layer and the PHY. In addition to these external interfaces, an implicit interface also exists between the MLME and the MCPS that allows the MLME to use the MAC data service.

The MLME-RX-ENABLE. request primitive allows the next higher layer to request that the receiver is either enabled for a finite period of time or disabled. The receiver is enabled or disabled exactly once per primitive request. The MLME-RX-ENABLE. confirm primitive reports the results of the attempt to enable or disable the receiver.

In one embodiment, primitives for specifying the receiver enable time are provided.

These primitives are used to enable or disable a device's receiver at a given time. In such embodiment, schemes to enable or disable the receiver multiple times through a single primitive request are provided. While the description here follows the duration of a ranging round duration, it does not preclude other durations like superframe duration, frame duration, beacon interval, inter frame duration, etc..

In one example S1, MLME-RANGING-ROUND-RX-ENABLE. request by specifying receiver ON times and durations is provided.

The next higher layer can request that the receiver is either enabled for a finite period of time or disabled multiple times in a ranging round through a single primitive request using MLME-RANGING-ROUND-RX-ENABLE.

The semantics of this primitive are as follows:
<IMG>.

The primitive parameters are defined in TABLE <NUM>.

The MI,ME-RANGING-ROUND-RX-ENABLE. request primitive is generated by the next higher layer and issued to the MLME to enable the receiver for fixed durations, at times relative to the start of the current or next ranging round. This primitive may also be generated to cancel a previously generated request to enable the receiver. The receiver is enabled based on the times in the unit of RSTU specified by the list of integers in RxOnTimes and disabled after the corresponding duration chronologically specified by the list of integers in RxOnDurations. The length of the list of integers specified in RxOnTimes and RxOnDurations may be the same.

The MLME may treat the request to enable or disable the receiver as secondary to other responsibilities of the device (e.g., GTSs, coordinator beacon tracking, or beacon transmissions). When the primitive is issued to enable the receiver, the device may enable the device's receiver until either the device has a conflicting responsibility, or the time specified by RxOnDuration has expired. In the case of a conflicting responsibility, the device may interrupt the receive operation. After the completion of the interrupting operation, the RxOnDuration may be checked to determine whether the time has expired. If so, the operation is complete. If not, the receiver is re-enabled until either the device has another conflicting responsibility, or the time specified by RxOnDuration has expired. When the primitive is issued to disable the receiver, the device may disable the device' receiver unless the device has a conflicting responsibility.

Before attempting to enable the receiver, the MLME first determines whether each of the corresponding (RxOnTimes + RxOnDurations) is less than the number of RSTUs spanning the ranging round duration, as defined by the previous ranging control message. If those of the corresponding (RxOnTimes + RxOnDurations) is not less than the ranging round duration, the MLME issues the MLME-RXENABLE. confirm primitive with a Status of ON_TIME_TOO_LONG.

The MLME then determines whether the receiver can be enabled in the current ranging round. If the current time measured from the start of the ranging round is less than each of the (RxOnTimes), the MLME attempts to enable the receiver in the current ranging round. If the current time measured from the start of the ranging round is greater than or equal to one or more of the (RxOnTimes) and DeferPermit is equal to TRUE, the MLME defers until the next ranging round and attempts to enable the receiver in that ranging round. Otherwise, if the MLME cannot enable the receiver in the current ranging round and is not permitted to defer the receive enable operation until the next ranging round, the MLME issues the MI,ME-RX-ENABLE. confirm primitive with a status of PAST_TIME. If the RxOnDuration parameter is equal to zero, the MLME requests that the PHY disable a receiver.

In one example S2, MLME-RANGING-ROUND-RX-ENABLE. request via bitmap specification is provided.

The next higher layer can request that the receiver is either enabled for a finite period of time or disabled multiple times in a ranging round through a single primitive request using MLME-RANGING-ROUND-RX-ENABLE. request via bitmap specification. Each ranging round is made up of multiple ranging scheduling time units (RSTUs). The RxOnTimes bitmap with number of bits equal to the number of RSTUs in the ranging round, conveys whether the receiver may be enabled or disabled for the respective RSTUs. This does not preclude using other durations or nomenclatures for RSTUs (e.g., slot, frame, etc.) and for ranging round (e.g., superframe, beacon interval, etc.) It also does not preclude specifying the receiver enable or disable primitives using bitmap or similar discretized notations and/or indicators for any discretized intervals of time (including when the successive intervals of time are of unequal duration).

When RxOnTimes is conveyed through a bitmap with each bit indicates the receiver ON or OFF status per RSTU conveys the RxOnDurations information. However, specifying this is not precluded under this scheme.

In one embodiment, primitives for confirming the receiver enable time is provided.

In one example S3, MLME-RANGING-ROUND-RX-ENABLE. confirm via enumeration is provided.

The MLME-RANGING-ROUND-RX-ENABLE. confirm primitive reports the results of the attempt to enable or disable the receiver.

The MLME- RANGING-ROUND-RX-ENABLE confirm primitive is generated by the MLME and issued to a next higher layer in response to an MLME-RANGING-ROUND-RX-ENABLE. request primitive. This primitive returns a Status of either SUCCESS, if the request to enable or disable the receiver was successful, or the appropriate error code for each of the enable and disable request in MLME-RANGING-ROUND-RX-ENABLE.

In one example S4, MLME-RANGING-ROUND-RX-ENABLE confirm via bitmap is provided.

The MLME-RANGING-ROUND-RX-ENABLE. confirm primitive reports the results of the attempt to enable or disable the receiver.

The MLME- RANGING-ROUND-RX-ENABLE. confirm primitive is generated by the MLME and issued to a next higher layer in response to an MLME-RANGING-ROUND-RX-ENABLE. request primitive. This primitive returns a bitmap specifying whether the attempt to enable or disable the receiver in each RSTU was successful. The length of the bitmap (number of bits in the bitmap) corresponds to the number of RSTUs or the number of discretized time durations or intervals used to specify receiver enable or disable times. This does not preclude using other durations or nomenclatures for RSTUs (e.g., slot, frame, etc.) and for ranging round (e.g., superframe, beacon interval, etc.) It also does not preclude specifying the receiver enable or disable primitives using bitmap or similar discretized notations and/or indicators for any discretized intervals of time (including when the successive intervals of time are of unequal duration).

In one embodiment, message sequence charts illustrating primitives for receiver enable request and confirm is provided.

Example message charts for MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm for controller and controlee are shown in <FIG>, and <FIG>, respectively.

<FIG> illustrates an example MLME-RANGING-ROUND-RX-ENABLE. request and NILME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> according to embodiments of the present disclosure. The embodiment of the MLME-RANGING-ROUND-RX-ENABLE request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the MLME-RANGING-ROUND-RX-ENABLE. request and NILNM-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

<FIG> illustrates an example MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> according to embodiments of the present disclosure. The embodiment of the MLME-RANGING-ROUND-RX-ENABLE request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the MLME-RANGING-ROUND-RX-ENABLE. request and NILNM-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

<FIG> illustrates an example MLME-RANGING-ROUND-RX-ENABLE. request and NILNM-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> according to embodiments of the present disclosure. The embodiment of the MLME-RANGING-ROUND-RX-ENABLE request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the MLME-RANGING-ROUND-RX-ENABLE. request and NILNM-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

In one embodiment, primitives for request the start of the ranging round is provided.

The next higher layer uses the MLME-RANGING-ROUND-START. request to indicate the timing of start of the ranging round. Since the time structure of ranging round is managed by the next higher layer, this primitive enables the indication and alignment of MAC timing structure.

MLME-RANGING-ROUND-START. request is generated by the next higher layer and issued to the MLME at the exact instant of the start of the ranging round to indicate the start of the ranging round and align the MAC timing structure. All the MAC timing counters and durations of the MLME-RANGING-ROUND-RX-ENABLE. request primitive are with respect to the MLME-RANGING-ROUND-START. request primitive.

<FIG> illustrates an example MLME-RANGING-ROUND-START request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> according to embodiments of the present disclosure. The embodiment of the MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

<FIG> illustrates an example MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE confirm message sequence charts for controller <NUM> according to embodiments of the present disclosure. The embodiment of MLME-RANGING-ROUND-START request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controller <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

<FIG> illustrates an example MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controlee <NUM> according to embodiments of the present disclosure. The embodiment of the MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE confirm message sequence charts for controlee <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE confirm message sequence charts for controlee <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the MLME-RANGING-ROUND-START request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm message sequence charts for controlee <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

Example message charts for MLME-RANGING-ROUND-START. request, MLME-RANGING-ROUND-RX-ENABLE. request and MLME-RANGING-ROUND-RX-ENABLE. confirm for controller and controlee are shown in <FIG>, and <FIG>, respectively. MLME-RANGING-ROUND- START. request is sent by the next higher layer at the beginning of the ranging round for both controller and controlee. This indicates the beginning of the ranging round. For the controller, the MLME-RANGING-ROUND-RX-ENABLE. request is sent to the MAC by the next higher layer after the controller's next higher layer has set the configurations for the ranging round including the schedule for the ranging round. This can be either after the next higher layer conveys the RCM to the MAC as shown in <FIG> or may be before the controller conveys the RCM to the MAC as shown in <FIG>, either of which is decided by implementation choice. For the controlee, the MLME-RANGING-ROUND-RX-ENABLE. request is sent to the MAC by the next higher layer after the RCM and the schedule information (ARC IE and RDM IE) are received as shown in <FIG>.

In one embodiment, a receiver Enabling time reference for enhanced ranging devices (ERDEVs) is provided.

4z standard specifies ERDEVs. Receiver enable, such as MLME-RX-ENABLE. request is a primitive conveyed by the next higher layer to the MAC of ERDEVs to enable the receiver. This primitive specifies the time and the duration for enabling the receiver. The time to enable is with respect to a reference. If the device is an ERDEV, and if the device is beacon enabled, the beacon is chosen as the time reference. If the device is an ERDEV and if the device is not beacon enabled, then the TimeStamp parameter of the MCPS-Data. indication primitive that conveys the value of the RSTU counter to the next higher layer is used as the reference to convey the receiver enable time and durations in terms of RSTUs. Further details as elaborated in other embodiments.

In one embodiment, primitives for Rx-Enable using Beacon or TimeStamp parameter is provided.

In one example S4, primitive using NILNM-RX-ENABLE. request is provided.

In the case of non-Beacon enabled ERDEVs, the next higher layer may directly specify the RSTU counter value to specify the RxOnTime. When TxTimeSpecified parameter of MCPS-DATA. indication is set to RSTU_TIME, the next higher layer may use the TimeStamp parameter of the most recent RCM as a reference for the RSTU counter values to specify the RxOnTime. The next higher layer may use the TimeStamp parameter of MCPS-DATA. indication from any other message to maintain synchronization. When the RSTU counter value for RxOnTime is lesser than the current RSTU value, the RxOnTime may be interpreted as referring the RSTUs for the counter values following the wraparound when DeferPermit is TRUE.

For beacon enabled ERDEVs, when TxTimeSpecified parameter of MCPS-DATA. indication is set to RSTU TIME, the next higher layer may use the TimeStamp parameter of the most recent beacon (enhanced beacon frame) as a reference for the RSTU counter values to specify the RxOnTime.

The primitive parameters are defined in Table <NUM>.

The next higher layer of ERDEVs may request that the receiver is either enabled for a finite duration or disabled, multiple times in a ranging round by through a single MLME-RX-ENABLE. request primitive. This is done by configuring the RxOnTime and RxOnDuration parameters as a list of integers as shown in TABLE <NUM> with other parameters as shown in TABLE <NUM>.

The MLME-RX-ENABLE. request primitive is generated by the next higher layer and issued to the MLME to enable the receiver for fixed durations, at times specified using the RSTU counter values. This primitive may also be generated to cancel a previously generated request to enable the receiver. The receiver is enabled based on the times in the unit of RSTU specified by the list of integers in RxOnTime and disabled after the corresponding duration chronologically specified by the list of integers in RxOnDuration. The length of the list of integers specified in RxOnTime and RxOnDuration may be the same.

The MLME may treat the request to enable or disable the receiver as secondary to other responsibilities of the device (e.g., GTSs, coordinator beacon tracking, or beacon transmissions). When the primitive is issued to enable the receiver, the device may enable a receiver until either the device has a conflicting responsibility, or the time specified by RxOnDuration has expired. In the case of a conflicting responsibility, the device may interrupt the receive operation. After the completion of the interrupting operation, the RxOnDuration may be checked to determine whether the time has expired. If so, the operation is complete. If not, the receiver is re-enabled until either the device has another conflicting responsibility, or the time specified by RxOnDuration has expired. When the primitive is issued to disable the receiver, the device may disable a receiver unless the device has a conflicting responsibility.

The MLME then determines whether the receiver can be enabled for the specified RSTU counters. If the current RSTU counter value is lower than the specified counter value for RxOnTime, the MLME attempts to enable the receiver in the current ranging round. If the current RSTU counter value is higher than the specified counter value for RxOnTime and DeferPermit is equal to TRUE, the MLME defers until the RSTU counter wraparound and attempts to enable the receiver in that ranging round. Otherwise, if the MLME cannot enable the receiver in the current ranging round and is not permitted to defer the receive enable operation until after the wraparound, the MLME issues the MLME-RX-ENABLE. confirm primitive with a Status of PAST_TIME.

If the RxOnDuration parameter is equal to zero, the MLME requests that the PHY disable a receiver.

In one embodiment, primitives for receive enable confirm with beacon or TimeStamp is provided.

In one example S5, MLME-RX-ENABLE. confirm is provided.

The MLME-RX-ENABLE. confirm primitive reports the results of the attempt to enable or disable the receiver.

The primitive parameters are defined in TABLE <NUM> and TABLE <NUM> for vector corresponding to MLME-RX-ENABLE. request vector parameters for ERDEV.

The MLME-RX-ENABLE. confirm primitive is generated by the MLME and issued to a next higher layer in response to an MLME-RX-ENABLE. request primitive. This primitive returns a Status of either SUCCESS, if the request to enable or disable the receiver was successful, or the appropriate error code, for each of the enable and disable request in MLME-RX-ENABLE.

In one embodiment, primitives for indicating non-receipt of a frame is provided.

In one example S6, MLME-RX-ENABLE. indication is provided.

The MLME-RX-ENABLE. indication primitive for ERDEV reports a time-out if no frame was received for the duration specified by RxOnTime+RxOnDuration for each instance of RxOnTime.

<FIG> illustrates a flowchart <NUM> for MLME-RX-ENABLE. indication for ERDEV with RxAutoOff=TRUE according to embodiments of the present disclosure, as may be performed by a network entity. The embodiment of the flowchart <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the flowchart <NUM> may be used by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the flowchart <NUM> may be performed by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

As illustrated in <FIG>, a network entity identifies MLME-RX-ENABLE. request in ERDEV in step <NUM>. In step <NUM>, the network entity identifies MAC/MAC RSTU_Counter. In step <NUM>, the network entity determines whether RSTU_counter = = RxOn Time. In step <NUM>, if yes, the network entity in step <NUM> waits for a frame and increase MAC RSTU_counter. In step <NUM>, if no, the network entity performs step <NUM> again. In step <NUM>, the network entity determines whether a frame is received. In step <NUM>, if the frame is received, the network entity issues an appropriate indication primitive (e.g., MCPS-DATA. indication) and disables a receiver in step <NUM>. In step <NUM>, if the frame is not received, the network entity, in step <NUM>, determines whether RSTU_counter <= RxOnTime+RxOnDuration. In step <NUM>, if yes, the network entity performs step <NUM> again. In step <NUM>, if no, the network entity in step <NUM>, issues RX-ENABLE. indication with TimeStamp parameters.

<FIG> illustrates a flowchart of a method <NUM> for specifying receiver enable times according to embodiments of the present disclosure, as may be performed by a network entity. The embodiment of the method <NUM> illustrated in <FIG> is for illustration only. <FIG> does not limit the scope of the present disclosure to any particular implementation. In one embodiment, the method <NUM> may be performed by a controller, a controlee, an initiator, and/or responder as illustrated in <FIG>. In one embodiment, the method <NUM> may be used by a network entity (e.g., BS <NUM>-<NUM> as illustrated in <FIG>, terminal <NUM>-<NUM> as illustrated in <FIG>).

As illustrated in <FIG>, the method <NUM> begins at step <NUM>.

In step <NUM>, the network entity identifies a medium access control (MAC) sublayer management entity-receive-enable request (MLME-RX-ENABLE. request) primitive including a list of ranging scheduling time unit (RSTU) counter (RxOnTime) values and a number of RSTUs (RxOnDuration), wherein the MLME-RX-ENABLE. request primitive is sent to a MAC layer from a higher layer.

In one embodiment, in step <NUM>, the MLME-RX-ENABLE. indication primitive includes a time stamp (TimeStamp) parameter including a current value of the MAC RSTU_COUNTER and the MLME-RX-ENABLE. indication primitive is sent to the higher layer from the MAC layer.

In such embodiment, the current value of the MAC RSTU_COUNTER is determined based on the RxOnTime value and the RxOnDuration.

In such embodiment, the MLME-RX-ENABLE. request primitive further includes a receive auto-off (RxAutoOff) indicating a status of a transceiver that receives the frame.

In one embodiment, when the RxAutoOff is set to TRUE, the transceiver is disabled after receiving the frame; and when the RxAutoOff is set to FALSE, the transceiver remains enabled for the RxOnDuration.

In one embodiment, when the RxAutoOff is set to TRUE, the MCPS-DATA. indication primitive is sent to the higher layer from the MAC layer; and the MCPS-DATA. indication primitive includes an indication that a packet is received from the other network entity.

Subsequently, in step <NUM>, the network entity, in response to identifying the MLME-RX-ENABLE. request primitive, identifies a value of a MAC RSTU counter (MAC RSTU_COUNTER).

Subsequently, in step <NUM>, the network entity determines whether the value of the MAC RSTU_COUNTER is set to an RxOnTime value included in the list of the RxOnTime values of the MLME-RX-ENABLE. request primitive.

Subsequently, in step <NUM>, the network entity increases the value of the MAC RSTU_COUNTER.

Next, in step <NUM>, the network entity determines whether a frame is received from another network entity based on the value of the MAC RSTU_COUNTER.

Finally, in step <NUM>, the network entity, in response to determining that the frame is received, generates a MAC common part sublayer indication (MCPS-DATA. indication) primitive.

In one embodiment, the network entity disables a reception of the frame after generating the MCPS-DATA. indication primitive and the MCPS-DATA. indication primitive being sent to the higher layer from the MAC layer.

In one embodiment, the network entity, in response to determining that the frame is not received, determines whether the value of the MAC RSTU_COUNTER is less than or equal to a sum of the RxOnTime value and the RxOnDuration.

In one embodiment, the network entity generates a MLME-RX-ENABLE. indication primitive in response to determining that the value of the MAC RSTU_COUNTER is greater than the sum of the RxOnTime value and the RxOnDuration.

Claim 1:
A device in a wireless communication system supporting ranging capability, the device comprising:
a transceiver (<NUM>); and
a processor (<NUM>) operably connected to the transceiver (<NUM>) and configured to:
receive, in a medium access control, MAC, layer, a receive enable request, MLME-RX-ENABLE.request, from a higher layer, the MLME-RX-ENABLE.request, including an RxOnTime, an RxOnDuration and an RxAutoOff,
wherein the RxOnTime is a list of counter values indicating time information in ranging scheduling time units, RSTU, at which a receiver side of the transceiver (<NUM>) is to be enabled,
wherein the RxOnDuration is a corresponding list of values indicating durations for which the receiver side of the transceiver (<NUM>) is to be enabled, and
wherein the RxAutoOff is a list of booleans indicating whether the receiver side of the transceiver (<NUM>) is to be disabled,
perform operations related to enabling or disabling the receiver side of the transceiver (<NUM>), based on the RxOnTime, the RxOnDuration and the RxAutoOff; and
transmit, from the MAC layer to the higher layer, a receive enable confirm, MLME-RX-ENABLE. confirm, to report result information,
wherein in case that a value of the RxAutoOff is TRUE, the receiver side of the transceiver (<NUM>) is disabled immediately after reception of data; and
wherein in case that a value of the RxAutoOff is FALSE, the receiver side of the transceiver (<NUM>) remains enabled for a value of the RxOnDuration.