Method and apparatus for bitmap-based block scheduling in ultra wideband wireless network system

Abstract

A method and an apparatus for bitmap-based block scheduling in an ultra wideband wireless network system are disclosed. The method according to one embodiment of the present disclosure may comprise steps in which a first device: generates a scheduling information element (IE) including an extended bitmap length field and a bitmap field; and transmits the scheduling IE to a second device. The length of the bitmap field can be based on the value of the extended bitmap length field. The extended bitmap length field can include a bitmap length field having a bit size that exceeds 2.

Description

Bitmap-based block scheduling method and device in an ultra-wideband wireless network system

[0001] The present disclosure relates to a bitmap-based block scheduling method and device in an ultra-wideband wireless network system.

[0002] Low-rate (LR) wireless networks can support low-data-rate connectivity between fixed or mobile devices with limited battery consumption requirements. For example, LR wireless networks can be applied to wireless personal area networks (WPANs). The Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard defines various techniques for the physical layer (PHY) and radio access control (MAC) sublayer for LR wireless networks. For example, the IEEE 802.15.4 standard defines various modes that support precise ranging.

[0003] Ultra-wideband (UWB) wireless networks can support transmitting large amounts of information at low power over a very wide bandwidth (e.g., frequency bands of 3.1 GHz to 10.6 GHz). For example, UWB technology can support converting digitally encoded information into impulse signals with very short time durations, such as sub-nanoseconds, and transmitting them wirelessly. The IEEE 802.15.4z standard defines ultra-wideband (UWB) technology related to ranging technology. For example, the IEEE 802.15.4z standard includes high-rate pulse frequency (HRP) PHY technology, which supports high-speed data communications (e.g., 27-31 Mbps) and accurate two-way ranging and positioning, and high-rate pulse frequency (LRP) PHY technology, which supports various modes for low-speed data communications (e.g., Radio Frequency Identification (RFID) applications). Furthermore, the IEEE 802.15.4z standard includes UWB PHY technology that improves the integrity and accuracy of ranging measurements, and MAC technology that supports the exchange of ranging-related information between devices participating in ranging and the control of time-of-flight (TOF) ranging procedures. Recently, the IEEE 802.15.4ab standard is under discussion for the advancement of UWB PHY / MAC, which includes improvements to wireless network technology based on the IEEE 802.15.4z standard.

[0004] The technical problem of the present disclosure is to provide a bitmap-based block scheduling method and device in a UWB wireless network system.

[0005] An additional technical problem of the present disclosure is to provide a method and apparatus for reducing overhead in bitmap-based block scheduling supporting a hyper block-based mode in a UWB wireless network system.

[0006] The technical problems to be achieved in the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person having ordinary skill in the technical field to which the present disclosure belongs from the description below.

[0007] A method according to one aspect of the present disclosure may include: generating, by a first device, a scheduling information element (IE) including an extended bitmap length field and a bitmap field; and transmitting, by the first device, a control message including the scheduling IE to a second device. The length of the bitmap field may be based on a value of the extended bitmap length field. The extended bitmap length field may include a bitmap length field having a size greater than 2 bits.

[0008] A method according to an additional aspect of the present disclosure may include receiving, by a second device from a first device, a control message including a scheduling information element (IE) including an extended bitmap length field and a bitmap field; and performing, by the second device, signal transmission or reception in a block scheduled to the second device based on a bitmap of the bitmap field. The length of the bitmap field may be based on a value of the extended bitmap length field. The extended bitmap length field may include a bitmap length field having a size greater than 2 bits.

[0009] According to the present disclosure, a bitmap-based block scheduling method and device can be provided in a UWB wireless network system.

[0010] According to the present disclosure, a method and apparatus for reducing overhead in bitmap-based block scheduling supporting a hyper block-based mode in a UWB wireless network system can be provided.

[0011] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned will be clearly understood by a person having ordinary skill in the art to which the present disclosure pertains from the description below.

[0012] The accompanying drawings, which are incorporated in and are part of the detailed description to aid in understanding the present disclosure, provide embodiments of the present disclosure and, together with the detailed description, describe the technical features of the present disclosure.

[0013] FIG. 1 illustrates a block diagram of a wireless communication device according to one embodiment of the present disclosure.

[0014] FIG. 2 is a diagram for explaining an HRP UWB PPDU format to which the present disclosure can be applied.

[0015] FIG. 3 is a diagram for explaining the setup of an HRP UWB PPDU STS packet structure to which the present disclosure can be applied.

[0016] FIG. 4 is a diagram for explaining two-way ranging techniques to which the present disclosure can be applied.

[0017] FIG. 5 is a diagram for explaining examples of formats of RMI IE, RCPCS IE, RRMC IE, and RRTI IE to which the present disclosure can be applied.

[0018] FIG. 6 illustrates an example message sequence chart for SS-TWR applying deferred response time results to which the present disclosure may be applied.

[0019] FIG. 7 illustrates an example message sequence chart for SS-TWR applying embedded response time results to which the present disclosure may be applied.

[0020] FIG. 8 illustrates an example of a message sequence chart for SS-TWR using SP3 packets to which the present disclosure may be applied.

[0021] FIG. 9 illustrates an example of a message sequence chart for a DS-TWR to which delayed response time information to which the present disclosure may be applied.

[0022] FIG. 10 illustrates an example of a message sequence chart for DS-TWR to which embedded ranging time information to which the present disclosure may be applied.

[0023] FIG. 11 is a diagram illustrating the role of a device in a ranging procedure to which the present disclosure can be applied.

[0024] Figure 12 shows examples of ARC IE, RDM IE, RBU IE, RR IE, and SRRE IE formats to which the present disclosure can be applied.

[0025] FIG. 13 is a diagram for explaining a ranging block structure and ranging phase to which the present disclosure can be applied.

[0026] FIG. 14 illustrates examples of timing diagrams for various multi-device ranging to which the present disclosure may be applied.

[0027] FIG. 15 shows a time diagram in an example of a block-based mode to which the present disclosure can be applied.

[0028] FIG. 16 is a diagram illustrating examples of various transmission offsets to which the present disclosure can be applied.

[0029] FIG. 17 illustrates an example of a message sequence chart for a one-to-many SS-TWR to which the present disclosure may be applied.

[0030] FIG. 18 illustrates an example of a message sequence chart for an SP3 one-to-many SS-TWR to which the present disclosure may be applied.

[0031] FIG. 19 illustrates an example of a time structure in a hyper block-based mode according to the present disclosure.

[0032] FIG. 20 is a diagram showing an example of the HBS IE format according to the present disclosure.

[0033] FIG. 21 is a diagram showing an example of a scheduling IE format according to the present disclosure.

[0034] FIG. 22 is a drawing for explaining the operation of the first device according to the present disclosure.

[0035] FIG. 23 is a drawing for explaining the operation of a second device according to the present disclosure.

[0036] FIG. 24 is a diagram showing various examples of scheduling list elements within a scheduling IE according to the present disclosure.

[0037] FIG. 25 is a diagram illustrating an example of an operation using a bitmap-based block scheduling IE in a hyper block-based mode according to the present disclosure.

[0038] FIG. 26 is a diagram illustrating an example of an operation using a bitmap-based block scheduling IE in a block-based mode according to the present disclosure.

[0039] Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. The detailed description set forth below, together with the accompanying drawings, is intended to explain exemplary embodiments of the present disclosure and is not intended to represent the only embodiments in which the present disclosure may be practiced. The following detailed description includes specific details to provide a thorough understanding of the present disclosure. However, one of ordinary skill in the art will appreciate that the present disclosure may be practiced without these specific details.

[0040] In some cases, to avoid obscuring the concepts of the present disclosure, known structures and devices may be omitted or illustrated in block diagram form focusing on the core functions of each structure and device.

[0041] In the present disclosure, when a component is said to be "connected," "coupled," or "connected" to another component, this may include not only a direct connection but also an indirect connection in which another component exists between them. Furthermore, the terms "comprises" or "has" in the present disclosure specify the presence of the mentioned features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0042] In this disclosure, terms such as “first,” “second,” etc. are used only to distinguish one component from another and are not used to limit the components, and do not limit the order or importance between the components unless specifically stated otherwise. Accordingly, within the scope of this disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, a second component in one embodiment may be referred to as a first component in another embodiment.

[0043] The terminology used herein is for the purpose of describing particular embodiments and is not intended to limit the scope of the claims. As used in the description of the embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The term "and / or" as used herein may refer to any one of the associated enumerated items, or is meant to refer to and encompass any and all possible combinations of two or more of them. Furthermore, the use of " / " between words in this disclosure has the same meaning as "and / or" unless otherwise stated.

[0044] The examples of the present disclosure can be applied to various wireless communication systems. For example, the examples of the present disclosure can be applied to a wireless network based on the IEEE 802.15 standard (e.g., Zigbee, Bluetooth, etc.). In particular, the examples of the present disclosure can be applied to a wireless network based on the IEEE 802.15.4 standard, and further, can be applied to a newly proposed IEEE 802.15.4ab standard-based UWB wireless network, or a next-generation UWB wireless network after IEEE 802.15.4ab. The wireless communication system to which the examples of the present disclosure are applied is not limited to a wireless network of the IEEE 802.15 series, and can be applied to a wireless local area network (WLAN) technology or Wi-Fi technology of the IEEE 802.11 series, or can be applied to a cellular wireless communication system (e.g., a technology of the Long Term Evolution (LTE) series of the 3rd Generation Partnership Project (3GPP) standard, and 5G New Radio (NR), etc.).

[0045] The IEEE 802.15.4ab standard, which includes techniques to further enhance the UWB PHY / MAC, is under discussion. For example, the IEEE 802.15.4ab standard includes: additional coding, preamble, and modulation techniques to support improved link budget and / or reduced airtime; additional channels and operating frequencies; interference mitigation techniques to support higher device density and higher traffic use cases; improvements to the accuracy, precision, reliability, and interoperability of high-integrity ranging; techniques to reduce complexity and power consumption; definition of hybrid operation with narrowband signaling to assist UWB; improved native discovery and connection setup mechanisms; sensing capabilities to support presence detection and environment mapping; mechanisms to support high data-rate streaming, allowing throughputs of at least 50 Mbps, as well as low-power, low-latency streaming; Support for peer-to-peer, peer-to-multipeer, station-to-infrastructure protocols and infrastructure synchronization mechanisms is being discussed.

[0046] Below, technical features to which examples of the present disclosure can be applied are described.

[0047] FIG. 1 illustrates a block diagram of a wireless communication device according to one embodiment of the present disclosure.

[0048] The first device (100) and the second device (200) illustrated in FIG. 1 may be replaced with various terms such as a terminal, a wireless device, a WTRU (Wireless Transmit Receive Unit), a UE (User Equipment), an MS (Mobile Station), a UT (user terminal), an MSS (Mobile Subscriber Station), an MSS (Mobile Subscriber Unit), an SS (Subscriber Station), an AMS (Advanced Mobile Station), a WT (Wireless terminal), or simply a user. In addition, the first device (100) and the second device (200) may be replaced with various terms such as an access point (AP), a BS (Base Station), a fixed station, a Node B, a BTS (Base Transceiver System), a network, an AI (Artificial Intelligence) system, an RSU (road side unit), a repeater, a router, a relay, a gateway, etc.

[0049] If the devices (100, 200) illustrated in FIG. 1 support ranging, they may be referred to as RDEV (ranging-capable device) or ERDEV (enhanced ranging-capable device). For example, the devices (100, 200) illustrated in FIG. 1 may be referred to by various terms, such as a transmitting device, a receiving device, a transmitting RDEV, a receiving RDEV, a transmitting ERDEV, and a receiving ERDEV. For example, the devices (110, 200) may be referred to as an initiator, a responder, an originator, a recipient, a controller, a controlee, and the like, depending on their roles in ranging operations. The role of a device is not fixed, but may be relatively determined based on its relationship with other devices. When a device interacts with multiple devices, the device may perform multiple roles.

[0050] Referring to FIG. 1, a first device (100) and a second device (200) can transmit and receive wireless signals through various UWB wireless network technologies (e.g., IEEE 802.15.4 series). The first device (100) and the second device (200) can include interfaces for a medium access control (MAC) layer and a physical layer (PHY) that follow the provisions of the IEEE 802.15.4 standard. The IEEE 802.15.4-based PHY and MAC are included in a UWB subsystem, and the UWB subsystem can further include a UWB command interface (UCI) corresponding to an interface between a UWB controller and a host. The UWB subsystem can exchange messages with a host system through the UCI.

[0051] In addition, the first device (100) and the second device (200) may additionally support various communication standards (e.g., standards of the IEEE 802.15 series, IEEE 802.11 series, 3GPP LTE series, 5G NR series, etc.) other than the UWB wireless network technology. In addition, the device of the present disclosure may be implemented as various devices such as a mobile phone, a vehicle, a personal computer, an AR (Augmented Reality) device, a VR (Virtual Reality) device, etc. In addition, the device of the present specification may support various communication services such as voice calls, video calls, data communications, autonomous driving, MTC (Machine-Type Communication), M2M (Machine-to-Machine), D2D (Device-to-Device), and IoT (Internet-of-Things).

[0052] A first device (100) includes one or more processors (102) and one or more memories (104), and may further include one or more transceivers (106) and / or one or more antennas (108). The processor (102) controls the memories (104) and / or the transceivers (106), and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in the present disclosure. For example, the processor (102) may process information in the memories (104) to generate first information / signals, and then transmit a wireless signal including the first information / signals via the transceivers (106). Furthermore, the processor (102) may receive a wireless signal including second information / signals via the transceivers (106), and then store information obtained from signal processing of the second information / signals in the memory (104). The memory (104) may be connected to the processor (102) and may store various information related to the operation of the processor (102). For example, the memory (104) may perform some or all of the processes controlled by the processor (102), or may store software code including instructions for performing the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in the present disclosure. Here, the processor (102) and the memory (104) may be part of a communication modem / circuit / chip designed to implement UWB wireless network technology (e.g., IEEE 802.15.4 series). The transceiver (106) may be connected to the processor (102) and may transmit and / or receive wireless signals via one or more antennas (108). The transceiver (106) may include a transmitter and / or a receiver. The transceiver (106) may be used interchangeably with an RF (Radio Frequency) unit. In the present disclosure, a device may also mean a communication modem / circuit / chip.

[0053] The second device (200) includes one or more processors (202), one or more memories (204), and may further include one or more transceivers (206) and / or one or more antennas (208). The processor (202) controls the memories (204) and / or the transceivers (206), and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in the present disclosure. For example, the processor (202) may process information in the memory (204) to generate third information / signals, and then transmit a wireless signal including the third information / signals via the transceivers (206). Furthermore, the processor (202) may receive a wireless signal including fourth information / signals via the transceivers (206), and then store information obtained from signal processing of the fourth information / signals in the memory (204). The memory (204) may be connected to the processor (202) and may store various information related to the operation of the processor (202). For example, the memory (204) may perform some or all of the processes controlled by the processor (202), or may store software code including instructions for performing the descriptions, functions, procedures, proposals, methods and / or operation flowcharts disclosed in the present disclosure. Here, the processor (202) and the memory (204) may be part of a communication modem / circuit / chip designed to implement UWB wireless network technology (e.g., IEEE 802.15.4 series). The transceiver (206) may be connected to the processor (202) and may transmit and / or receive wireless signals via one or more antennas (208). The transceiver (206) may include a transmitter and / or a receiver. The transceiver (206) may be used interchangeably with an RF unit. In the present disclosure, a device may also mean a communication modem / circuit / chip.

[0054] Hereinafter, the hardware elements of the device (100, 200) will be described in more detail. Although not limited thereto, one or more protocol layers may be implemented by one or more processors (102, 202). For example, one or more processors (102, 202) may implement one or more layers (e.g., functional layers such as PHY, MAC). One or more processors (102, 202) may generate one or more Protocol Data Units (PDUs) and / or one or more Service Data Units (SDUs) according to the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in the present disclosure. One or more processors (102, 202) may generate messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in the present disclosure. One or more processors (102, 202) can generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data or information according to the functions, procedures, proposals and / or methods disclosed in the present disclosure, and provide the signals to one or more transceivers (106, 206). One or more processors (102, 202) can receive signals (e.g., baseband signals) from one or more transceivers (106, 206) and obtain PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed in the present disclosure.

[0055] One or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, or a microcomputer. One or more processors (102, 202) may be implemented by hardware, firmware, software, or a combination thereof. For example, one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), one or more Digital Signal Processing Devices (DSPDs), one or more Programmable Logic Devices (PLDs), or one or more Field Programmable Gate Arrays (FPGAs) may be included in one or more processors (102, 202). The descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in this disclosure may be implemented using firmware or software, and the firmware or software may be implemented to include modules, procedures, functions, etc. The descriptions, functions, procedures, proposals, methods and / or operation flowcharts disclosed in this disclosure may be implemented using firmware or software configured to perform one or more processors (102, 202) or stored in one or more memories (104, 204) and driven by one or more processors (102, 202). The descriptions, functions, procedures, proposals, methods and / or operation flowcharts disclosed in this disclosure may be implemented using firmware or software in the form of codes, instructions and / or sets of instructions.

[0056] One or more memories (104, 204) may be coupled to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, codes, instructions, and / or commands. The one or more memories (104, 204) may be configured as ROM, RAM, EPROM, flash memory, hard drives, registers, cache memory, computer-readable storage media, and / or combinations thereof. The one or more memories (104, 204) may be located internally and / or externally to the one or more processors (102, 202). Additionally, the one or more memories (104, 204) may be coupled to the one or more processors (102, 202) via various technologies, such as wired or wireless connections.

[0057] One or more transceivers (106, 206) can transmit user data, control information, wireless signals / channels, etc., as mentioned in the methods and / or flowcharts of the present disclosure, to one or more other devices. One or more transceivers (106, 206) can receive user data, control information, wireless signals / channels, etc., as mentioned in the descriptions, functions, procedures, proposals, methods and / or flowcharts of the present disclosure, from one or more other devices. For example, one or more transceivers (106, 206) can be coupled to one or more processors (102, 202) and can transmit and receive wireless signals. For example, one or more processors (102, 202) can control one or more transceivers (106, 206) to transmit user data, control information, or wireless signals to one or more other devices. Additionally, one or more processors (102, 202) may control one or more transceivers (106, 206) to receive user data, control information, or wireless signals from one or more other devices. Additionally, one or more transceivers (106, 206) may be coupled to one or more antennas (108, 208), and one or more transceivers (106, 206) may be configured to transmit and receive user data, control information, wireless signals / channels, or the like, as referred to in the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in the present disclosure, via one or more antennas (108, 208). In the present disclosure, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). One or more transceivers (106, 206) can convert received user data, control information, wireless signals / channels, etc. from RF band signals to baseband signals in order to process the received user data, control information, wireless signals / channels, etc. using one or more processors (102, 202).One or more transceivers (106, 206) may convert user data, control information, wireless signals / channels, etc. processed by one or more processors (102, 202) from baseband signals to RF band signals. For this purpose, one or more transceivers (106, 206) may include an (analog) oscillator and / or filter.

[0058] For example, the transceiver (106, 206) of FIG. 1 can perform transmission and reception operations of signals (e.g., packets or PPDUs (Physical layer Protocol Data Units) according to IEEE 802.15.4, etc.). In addition, in the present disclosure, operations in which various devices generate transmission and reception signals or perform data processing or calculations in advance for transmission and reception signals can be performed in the processor (102, 202) of FIG. 1. For example, an example of an operation for generating a transmission / reception signal or performing data processing or operation in advance for a transmission / reception signal may include an operation for determining / obtaining / configuring / computing / decoding / encoding bit information of field(s) included in a PPDU, an operation for determining / configuring / obtaining time resources or frequency resources, etc. used for field(s) included in a PPDU, an operation for determining / configuring / obtaining a specific sequence, etc. used for field(s) included in a PPDU, an operation for determining / configuring / obtaining a power control operation and / or a power saving operation applied to a device, and an operation for determining / obtaining / configuring / computing / decoding / encoding an ACK signal. Additionally, in the examples below, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various devices for determining / acquiring / configuring / operating / decoding / encoding transmission / reception signals can be stored in the memory (104, 204) of FIG. 1.

[0059] In the UWB band, devices can perform medium access based on the CSMA / CA (Carrier Sense Multiple Access with Collision Avoidance) mechanism. The CSMA / CA mechanism can perform CCA (Clear Channel Assessment), which senses the wireless channel or medium for a predetermined period of time before the device begins transmitting. Sensing can be performed, for example, using an energy detection (ED) method based on a predetermined threshold. If the sensing result indicates that the medium is idle, the device initiates transmission through the medium. Conversely, if the medium is detected to be occupied or busy, the device may not initiate transmission but wait for a delay period (e.g., a random backoff period) for medium access before attempting transmission. By applying a random backoff period, multiple devices are expected to wait for different periods of time before attempting transmission, thereby minimizing collisions.

[0060] In addition, when a superframe structure is applied, a slotted CSMA-CA mechanism may be applied to data transmission in the CAP (contention access period) of the active portion among the active portion and the inactive portion of the interval between beacons. The CSMA-CA mechanism may not be applied to data transmission within the active portion and in the CFP (contention free period). When a superframe structure is not applied, an unslotted CSMA-CA mechanism may be applied to transmission of all data frames except for an ACK frame for a data request command.

[0061] Ranging Measurement

[0062] Ranging involves measuring the distance between two devices, and a device with ranging capability may be referred to as a ranging-capable device (RDEV) or enhanced ranging-capable device (ERDEV).

[0063] FIG. 2 is a diagram for explaining an HRP UWB PPDU format to which the present disclosure can be applied.

[0064] Figures 2(a) to 2(g) illustrate the encoding process of an HRP UWB PPDU. Through the encoding process, an HRP UWB PPDU having a format including a synchronization header (SHR), a PHY header (PHR), and a PHY payload field can be generated.

[0065] Figure 2(a) shows a PSDU (PHY service data unit) received from MAC through a PHY SAP (service access point). The PSDU may include a MAC PDU.

[0066] In Fig. 2(b), Reed-Solomon encoding can be applied to the PSDU to generate a PHY payload field. The PHY payload field in Fig. 2(b) is non-spread and corresponds to a state before convolution encoding is applied.

[0067] In Fig. 2(c), a PHR field may be added before the PHY payload field. The PHR field may have a size of 19 bits, from bits 0 to 18. For example, bits 0-1 may correspond to a data rate field, bits 2-8 may correspond to a frame length field, bit 9 may correspond to a ranging field, bit 10 may correspond to a reserved field, bits 11-12 may correspond to a preamble duration field, and bits 13-18 may correspond to a SECDED (single error correct, double error detect) field. The data rate field may indicate a data rate value applied to the PHY payload field. The frame length field may indicate the length of a PSDU. The ranging field may indicate whether the corresponding frame is a RFRAME (ranging frame). The preamble duration field may indicate the length (in symbol units) of the SYNC field of the SHR.

[0068] In Fig. 2(d), convolution encoding is applied to generate a coded PHY payload field, and in Fig. 2(e), spreading can be applied to the PHY payload field.

[0069] In Fig. 2(f), an SHR may be added before the PHR. The SHR field may include a SYNC field (or preamble code) and a start-of-frame delimiter (SFD) field.

[0070] In FIG. 2(g), modulation is applied to the SHR, PHR, and PHY payload fields, and the PPDU encoding procedure is terminated. The basic coding rate may be applied to the SHR field. BPM-BPSK (burst position modulation-binary phase shift keying) with a coding rate of 850 kb / s or 110 kb / s may be applied to the PHR field. BPM-BPSK with a coding rate indicated in the PHR may be applied to the PHY payload field. For example,

[0071] FIG. 3 is a diagram for explaining the setup of an HRP UWB PPDU STS packet structure to which the present disclosure can be applied.

[0072] The STS (Scrambled Timestamp Sequence) field may contain a sequence of pseudo-randomized pulses. For example, the STS may contain a sequence of pseudo-random pulses based on AES (Advanced Encryption Standard)-128, and may be utilized for accurate positioning in spread spectrum-based positioning technology in UWB communications.

[0073] The PPDU STS packet structure settings may vary depending on whether the STS field is included and its location.

[0074] Figure 3(a) shows the format corresponding to STS packet setting 0 (i.e., no STS field exists in the PPDU). This format can be defined as mandatory.

[0075] Figure 3(b) shows the format corresponding to STS packet setup 1 (i.e., the STS field is located immediately after the SFD field and before the PHR field). This format can be defined mandatorily.

[0076] Figure 3(c) shows the format corresponding to STS packet setup 2 (i.e., the STS field is located after the PHY payload field). This format may be defined as optional.

[0077] Figure 3(d) shows the format corresponding to STS packet setup 3 (i.e., the STS field is located immediately after the SFD field, there is no PHR field, and there is no Data field (i.e., the PHY payload field)). This format can be defined mandatorily.

[0078] PPDU formats such as those in the examples in Fig. 3 may also be referred to as HRP-ERDEV PPDU formats. In Fig. 3, arrows indicate the RMARKER (ranging marker) reference locations in each format. The RMARKER can be a reference for timestamp measurement or a ranging counter.

[0079] For example, RMARKER can be defined as the time at the local antenna of the start of the first symbol following the SFD of RFRAME. The next higher layer can estimate the relative clock offset between the local reference clocks of the remote transmitter and receiver based on the reporting of the SRMARKER receive ranging counter value for one or more STS segments.

[0080] The ranging counter supported by RDEV corresponds to a set of behavioral properties and capabilities of RDEV that produce ranging counter values. The ranging counter value is an unsigned integer and can be defined to be at least 32 bits long. The unit of the ranging counter is 2 of a 499.2 MHz chip period for the HRP UWB PHY. -7 is defined as approximately 15.65 picoseconds (ps), which is 20 times the base chipping rate of 1 MHz for the LRP UWB PHY. -20is defined as and is approximately 0.9537 ps.

[0081] The ranging capability can be enabled in the RDEV using the MCPS (MAC common part sublayer)-DATA.request primitive and the MLME (MAC sublayer management entity)-RX-ENABLE.request primitive. A primitive can mean a set of commands or parameters exchanged between layers or sublayer entities within a device. For example, an originator can request the ranging capability using the MCPS-DATA.request primitive, and the ranging capability can be enabled at the recipient using the MLME-RX-ENABLE.request primitive.

[0082] Ranging and Localization Methods

[0083] Ranging and localization methods supported by RDEVs and ERDEVs can be based on time-stamping capabilities. Time-based techniques such as single-sided two-way ranging (SS-TWR), double-sided two-way ranging (DS-TWR), and one-way ranging / time difference of arrival (OWR / TDOA) are described below.

[0084] FIG. 4 is a diagram for explaining two-way ranging techniques to which the present disclosure can be applied.

[0085] In the example of Figure 4(a), SS-TWR includes the measurement of the round-trip delay of a single message from one device to another and the response sent to the sending device. Device A initiates the message exchange, device B sends the response, and T_prop corresponds to the propagation time of the RMARKER between the devices.

[0086] Each device precisely measures the transmission and reception times of message frames, allowing it to calculate T_round and T_reply through simple subtraction. The resulting TOF can be estimated as ^T_prop using the formula below.

[0087]

[0088] If the device can estimate the relative clock offset between itself and the remote device, the accuracy of TOF can be improved by the following formula:

[0089]

[0090] Here, C_offs corresponds to the value measured by the receiver of device A relative clock offset between itself and the transmitter of remote device B.

[0091] In the example of Fig. 4(b), DS-TWR corresponds to an extension of SS-TWR, and two round trip times are used and combined to produce a TOF result by reducing errors in the case where an uncorrected clock frequency offset exists even if the response delay is long. Device A initiates the first round trip time measurement, device B responds to it, and then device B initiates the second round trip time measurement, and device A responds to it, thereby completing the entire DS-TWR exchange. T_prop corresponds to the propagation time of the RMARKER between devices.

[0092] Each device precisely measures the transmission and reception times of message frames, allowing it to calculate T_round and T_reply through simple subtraction. The resulting TOF can be estimated as ^T_prop using the formula below.

[0093]

[0094] The example in Fig. 4(c) corresponds to reducing the DS-TWR through the four messages in Fig. 4(b) to three messages. That is, the response to the first round-trip time measurement can be used as the initiation message for the second round-trip time measurement.

[0095] Next, we describe the TDOA method. TDOA is a technique for locating wireless devices (e.g., radio frequency identification (RFID) devices) based on the relative arrival times of a single message or multiple messages. OWR can be used for TDOA. There are two cases for TDOA. In one case, a message is periodically broadcast by a mobile device, and the arrival times of the broadcast messages at multiple stationary nodes synchronized in a predetermined manner can be compared. Typically, the message transmitted by the mobile device is referred to as a blink. In the other case, multiple synchronized nodes can sequentially broadcast messages according to a known transmission time offset. For any pair of stationary synchronized nodes, the difference in arrival times of the blinks in the first case, or the difference in arrival times of the broadcast messages received by the mobile device in the second case, positions the mobile device on a hyperbolic surface. By combining the results from multiple such pairs, the intersection point between the sets of hyperbolic surfaces can be derived, thereby determining the location of the mobile device. In a second case, the transmission offset can be taken into account when calculating the difference in arrival times of messages from synchronized nodes.

[0096] RFID devices typically use the shortest possible blink message (e.g., a multipurpose frame) to reduce power consumption. A multipurpose frame can be 12 octets long and include a short frame control field, a sequence number field, and may not include a destination address field, an extended source address field, or a frame check sequence (FCS).

[0097] Synchronization of fixed nodes can be achieved by distributing clock signals over a wire, or wireless synchronization techniques can be applied. Using UWB messages transmitted between fixed nodes (and known / pre-measured TOF), the relative clock frequency offset and drift between fixed nodes can be calculated. This information can be used to correct the arrival times of blink messages to a common time base, making TDOA data meaningful.

[0098] Setup procedure before ranging exchange

[0099] To reduce power consumption, ranging can be defined as disabled by default. Enabling ranging on all RDEVs participating in a TWR exchange can be performed by a higher layer. Furthermore, if optional capabilities are used, some coordination of the preamble and channel selection can be assumed prior to the TWR exchange.

[0100] Finish-up procedure after ranging exchange

[0101] At the end of a TWR exchange, each device can maintain transmit (TX) and receive (RX) ranging counter values ​​related to round-trip time measurements or response times. To calculate TOF, all of these values ​​are required at the node where the calculation is performed. This can be accomplished using out-of-band (OOB) signaling, custom messages, and ranging measurement information (RMI) information elements (IEs).

[0102] FIG. 5 is a diagram for explaining examples of formats of RMI IE, RCPCS IE, RRMC IE, and RRTI IE to which the present disclosure can be applied.

[0103] Figure 5(a) shows an example of the RMI IE format.

[0104] The RMI IE can be used to send one or more ranging-related measurements to one or more devices. The RMI IE content field can have a format similar to the example in Figure 5(a).

[0105] A value of 1 in the reply time present field may indicate that an RX-to-TX (or TX-to-RX) reply time field is present in each RMI list element, and a value of 0 may indicate that it is not present. The RX-to-TX (or TX-to-RX) reply time may correspond to T_reply described with reference to FIG. 4.

[0106] A value of 1 in the round-trip time present field may indicate that a TX-to-RX round-trip time field exists in each RMI list element, and a value of 0 may indicate that it does not exist. The TX-to-RX round-trip time may correspond to T_round described with reference to FIG. 4.

[0107] A value of 1 in the TOF presence field may indicate that the TOF field exists in each RMI list element, and a value of 0 may indicate that it does not exist.

[0108] A value of 1 in the AOA azimuth present field may indicate that the AOA azimuth field is present in each RMI list element, and a value of 0 may indicate that it is not present.

[0109] A value of 1 in the AOA elevation present field may indicate that the AOA elevation field is present in each RMI list element, and a value of 0 may indicate that it is not present.

[0110] A value of 1 in the AOA FOM (figure of merit) presence field indicates that an AOA azimuth FOM field exists in each RMI list element if an AOA azimuth field exists, and that an AOA elevation FOM field exists in each RMI list element if an AOA elevation field exists, and a value of 0 may indicate that neither an AOA azimuth FOM field nor an AOA elevation FOM field exists.

[0111] The address size specifier field can specify the size of the addresses used in the RMI list field (e.g., 2 or 8).

[0112] A value of 0 in the deferred mode field may indicate that the corresponding RMI IE is embedded in the RFRAME, and a value of 1 may indicate that the corresponding RMI IE is included in the deferred message transmitted in the next measurement report phase.

[0113] The RMI list length field can specify the number of elements in the RMI list field. The fields included in the RMI list field are as shown in Fig. 5(a).

[0114] Figure 5(b) shows an example of the RCPCS IE format.

[0115] The RCPCS (ranging channel and preamble code selection) IE can be used to indicate channel selection and / or TX / RX preamble code selection for dynamic preamble code and channel selection (DPS). DPS can include modifying the long preamble to protect against attacking devices intercepting ranging. The RCPCS IE content field can have a format similar to the example in FIG. 5(b).

[0116] A value of 1 in the CCIP (CCI present) field indicates that the CCI field exists, and a value of 0 indicates that it does not exist.

[0117] A value of 1 in the DDP (DPS Duration Present) field may indicate that the DPS duration field exists, and a value of 0 may indicate that it does not exist.

[0118] A value of 1 in the PSP (preamble sequence selection present) field indicates that the preamble sequence selection fields, i.e., the TX preamble code field, the RX preamble code field, and the PSR (preamble symbol repetitions) field, are present, and a value of 0 may indicate that they are not present.

[0119] The channel number field may indicate the UWB channel number for an upcoming ranging exchange.

[0120] The CCI (channel configuration interval) field can specify a channel configuration interval. The channel configuration interval can correspond to the time in RSTU (ranging scheduling time units) between the transmission of the corresponding IE and the reconfiguration of the specified channel.

[0121] RSTU is 416 chips (approximately 833.33ns) for HRP UWB PHY (416 chips = 416 / 499.2*10 6 ) corresponds to 1 microsecond (us) for LRP UWB PHY (= 1 chip at 1MHz base chip rate).

[0122] The DPS Duration field can specify the effective time duration of the DPS. The duration can be specified in RSTU units for ERDEV and in symbol units for non-ERDEV.

[0123] The TX Preamble Code field may indicate the DPS preamble code to be used for transmission during an upcoming ranging exchange by the transmitting side of the IE.

[0124] The RX Preamble Code field may indicate the DPS preamble code that the transmitting side of the IE will use for reception during an upcoming ranging exchange.

[0125] The PSR field may indicate the number of preamble symbol repetitions to be used for the SYNC of each RFRAME of the upcoming ranging transmission.

[0126] The MLMR-DPS.request and MLME-DPS.confirm primitives can be applied to the optional DPS mode of ranging. The ConfigTime parameter of the MLME-DPS.request primitive can be used to specify a future point in time at which the preamble code and / or channel number will be applied. The time at which the DPS change will be applied can be exchanged via the CCI field of the RCPCS IE.

[0127] Basic ranging exchange

[0128] The recipient may turn on or enable ranging in the MAC on the recipient side based on the MLME-RX-ENABLE.request primitive from the next higher layer.

[0129] After ranging is turned on at the receiver side MAC (i.e., by receiving the MLME-RX-ENABLE.request primitive), all received RFRAMEs can generate TX / RX ranging counters.

[0130] An originator can send data to a recipient based on the MCPS-DATA.request primitive.

[0131] The receiver can generate a ranging report for all RFRAMEs and send an ACK frame to the sender.

[0132] A sender can activate Tx-to-Rx turnaround (i.e., repeat data transmission and ACK reception) by receiving an ACK frame from the receiver. The next higher layer may not be involved in this.

[0133] Ranging reporting may include the issue of an MCPS-DATA.confirm primitive on the sender side (i.e., reporting the result of an MCPS-DATA.request primitive invoke), and an MCPS-DATA.indication primitive on the receiver side (i.e., indicating the receipt of data from the sender, or indicating that ranging information is available upon receipt of a packet from the sender).

[0134] Until ranging is disabled, the receiver may generate ranging reports and transmit ACKs to the sender, activate Tx-to-Rx turnaround based on receiving the sender's ACK frame, and repeat the ranging reports.

[0135] Ranging Procedure

[0136] First, we explain the control of ranging and the transfer of results.

[0137] Measurements can be exchanged between RDEVs to complete ToF calculations. To this end, the TWR can be controlled through information elements, and ranging data can be exchanged between RDEVs.

[0138] Specifically, the information elements can be used to transmit ranging data between RDEVs participating in ranging exchange and to control TWR. For various ranging methods, depending on the required use case, the measurement results from both devices can be combined to complete the TOF calculation between RDEVs participating in ranging exchange. That is, one device can transmit its ranging measurement results to another device. The information elements can be specified to provide a mechanism for controlling TWR and to support the transmission of ranging information between devices participating in ranging exchange. To ensure the integrity of the information transmission, a secure private data communication capability can be used.

[0139] Below, we describe the ranging procedure for SS-TWR that applies the deferred response time results.

[0140] FIG. 6 illustrates an example message sequence chart for SS-TWR applying deferred response time results to which the present disclosure may be applied.

[0141] In the message sequence diagram for ranging exchange, RRMC IE(0) may represent an RRMC IE that includes a ranging control information field with a value of 0 (i.e., a ranging initiation message for SS-TWR). The AR (Acknowledgment Request) field in the MAC header may indicate whether an ACK is requested.

[0142] The next higher layer of the initiator may have sufficient information to calculate the TOF between devices using the formula described above at the time of receiving the RMI IE (e.g., FIG. 5(a)).

[0143] An initiator may initiate a ranging exchange by issuing an MCPS-DATA.request primitive to request ranging response time information and transmit a ranging frame containing a Ranging Request Measurement and Control (RRMC) information element that includes a ranging control information field.

[0144] Figure 5(c) shows an example of the RRMC IE format.

[0145] The RRMC IE transmits a ranging request and may include information that controls the ranging procedure.

[0146] The response time request, round trip time request, TOF request, AOA azimuth request, and AOA elevation request fields in the RRMC IE format can indicate that the corresponding information is requested if the value is 1, and that the corresponding information is not requested if the value is 0.

[0147] The ranging control information field may have a value of 0 to indicate that the frame is a ranging initiation message for SS-TWR, a value of 1 to indicate that the frame is a response to a ranging initiation message for SS-TWR, a value of 2 to indicate that the frame is a ranging initiation message for DS-TWR, and a value of 3 to indicate that the frame is a continuing DS-TWR and initiates a second round trip time measurement.

[0148] The address size field can specify the size of the addresses used in the RRMC address list field. If the value of the address size field is 0, all addresses in the RRMC address list element can correspond to short addresses. If the value of the address size field is 1, all addresses in the RRMC address list element can correspond to extended addresses.

[0149] The RRMC Address List Length field can indicate the number of addresses in the RRMC Address List field. If no address is provided (e.g., in the case of unicast ranging where the target device can be identified by the destination address in the MHR (MAC header), the RRMC Address List Length field can be omitted.

[0150] If the RRMC IE is a broadcast message, and the sender wants to receive responses to the ranging request from all devices, the RRMC Address List Length and RRMC Address List fields may be omitted. Alternatively, if the sender wants to receive responses to the ranging request from specific devices (or a set of devices), the RRMC Address List Length and RRMC Address List fields may be used to select a set of devices for the response.

[0151] For SS-TWR, since the initiator generally calculates the TOF, the responder can request the TOF result by setting the TOF request field of the RRMC IE included in the response message.

[0152] For DS-TWR, since the responder typically computes the TOF, the initiator can request the TOF result by including the RRMC IE in the two messages it sends to perform the DS-TWR exchange.

[0153] If the initiator requests different information from multiple respondents, multiple RRMC IEs may be included in a single broadcast message.

[0154] The RRMC Address List field may contain a list of addresses to which the RRMC IE is directed.

[0155] With respect to the ranging report (or response ranging frame), the initiator side may complete the round-trip time measurement, and the MCPS-DATA.confirm primitive may provide a ranging report defining the round-trip time to the initiator side. On the receiver side, the MCPS-DATA.indication primitive may provide a response-side ranging report defining the response time for the round-trip time measurement.

[0156] Figure 5(d) shows an example of the RRTI (Ranging Reply Time Instantaneous) IE format.

[0157] In association with one or more frames containing an RRMC IE with the Response Time Request field set to 1, an RRTI IE may be included in the response frame to transmit the response time of the response frame.

[0158] The address size specifier field can be defined as shown in the table below.

[0159] The value of the address size specifier field is Address Size. 000 octets, address does not exist. 01 Reserved. 102 octets, short address (16 bits). 118 octets, extended address (64 bits).

[0160] The RRTI list length field can indicate the number of elements in the RRTI list field. The RRTI list field can contain RRTI list elements.

[0161] The RX-to-TX reply time field of the RRTI list field may be set to a value indicating the difference between the transmission time of the response RFRAME containing the RRTI IE and the reference time specified by the upper layer (i.e., T_reply in the example of Fig. 4(a)). The reference time may correspond to the reception time (based on RMARKER) of the RFRAME containing the RRMC IE with the response time request field set to 1.

[0162] The address field of the RRTI list field may be set to the address of the device sending the RRMC IE requesting the response time. In unicast ranging, the address field may be omitted. In scheduled multi-node ranging, the address field may be omitted if the response times of other RDEVs are negotiated in advance and the order is determined.

[0163] Below, we describe the ranging procedure for SS-TWR that applies embedded response time results.

[0164] FIG. 7 illustrates an example message sequence chart for SS-TWR applying embedded response time results to which the present disclosure may be applied.

[0165] For SS-TWR that applies the response time result, the ranging exchange can be initiated by a ranging frame that requests ranging response time information and includes an RRMC IE with the Ranging Control Information field set to 0. The responding device can complete the round-trip measurement by transmitting a response frame that includes an embedded RRTI (ranging reply time instantaneous) IE. If the device has the capability to generate the RRTI IE, the number of messages required for ranging measurement can be minimized, thus saving power. However, it may take time to calculate the arrival time of the received ranging message and prepare the RRTI IE value. In some cases, this time may be known a priori in an OOB manner, and the RRTN (ranging reply time negotiation) IE may provide a mechanism to indicate to the device a preferred response time, i.e., the time required to prepare a frame containing the RRTI IE. If this time is known, the ranging initiating device can expect a response message after a certain time and save energy by delaying turning on the receiver until then. This can be applied to both SS-TWR and DS-TWR ranging exchanges.

[0166] In Figure 7, RRMC IE(0) represents an RRMC IE containing a ranging control information field with a value of 0. The communication of the RRTN IE in the dotted box may be performed at any convenient time before the ranging exchange is initiated, or the preferred response time information may be known in advance or exchanged via OOB. Upon receiving the MCPS-DATA.indication primitive containing the responder's RRTI IE, the next higher layer of the initiator may have sufficient information to calculate the TOF between the two devices according to the formula described above.

[0167] Below, the ranging procedure for SS-TWR with fixed response time is described.

[0168] FIG. 8 illustrates an example of a message sequence chart for SS-TWR using a scrambled timestamp sequence packet configuration option three (SP3) packet to which the present disclosure may be applied.

[0169] If the responding device has precise control over the transmission time of its response message relative to the arrival time of the ranging initiation message, the response time (i.e., Treply) can have a fixed, known value agreed upon among the devices participating in the ranging exchange. In this case, it may not be necessary to embed the Treply in the response message or transmit it separately in an additional message. The resulting ranging accuracy may depend on how precisely the responding device controls the transmission time of its response message. For example, in TOF, a 1 ns error may correspond to a ranging error of approximately 30 cm.

[0170] HRP-ERDEV PPDU format SP3 can be used for fixed response times.

[0171] In the example of Figure 8, the initiation message in the dotted box may represent communication for agreement and coordination on the use of SP3 packets between devices and all other parameters necessary to allow ongoing communication. While only a single message is shown in the example of Figure 8, a series of messages in each direction may exist to agree on all parameters. For example, the RRNT IE may be used to agree on a fixed response time.

[0172] In each device, the next higher layer may use the MLME-STS.request primitive to configure the SP3 packet format across all devices and to set personal area network information base (PIB) attributes (e.g., phyHrpUwbStsKey, phyHrpUwbStsVCounter, phyHrpUwbStsVUpper96, etc.) to configure the behavior appropriately. Once the upper layer has selected the SP3 packet configuration, subsequent MCPS-DATA primitives relate to SP3 packets until the upper layer changes the packet configuration using the MLME-STS.request primitive.

[0173] The MCPS-DATA.request primitive can be used to initiate a ranging exchange, in which mode the PPDU may not convey MAC data. Although not shown, it can be assumed that the invocation of the MLME-RXENABLE.request primitive turns on the receiver at the appropriate time to receive the PPDU. Since the PHY is configured for SP3 packets, the PHY notifies the MAC layer of the receipt of the PPDU at the end of the scrambled timestamp sequence (STS), and similarly, the MAC, which is aware of the SP3 configuration, can deliver the RxRangingCounter value of the RangingReportDescriptor parameter of the MCPS-DATA.indication primitive. Furthermore, assuming that the RangingStsFom of the RangingReportDescriptor is acceptable, the upper layer can initiate the response by invoking the MCPS-DATA.request primitive specifying the RangingTxTime according to an agreed-upon fixed response time.

[0174] Assuming that the SP3 packet response is received at the initiating device and that the RangingStsFom of the RangingReportDescriptor parameter of the MCPS-DATA.indication primitive is acceptable, the initiating device may have sufficient information to compute the TOF between the devices according to the aforementioned formula based on the known fixed response time.

[0175] The ranging exchange may be repeated multiple times until the upper layers reach a mutual agreement. To resume PHY and MAC data interactions, the next upper layer can use the MLME-STS.request primitive to restore the STS packet settings to values ​​that allow such data interactions. This is illustrated in the last dotted box in Figure 8.

[0176] LRP-REDEV may also support challenge-response ranging with fixed response times, eliminating the need for data messages carrying response times.

[0177] Below, the DS-TWR ranging procedure to which delayed response time information is applied is described.

[0178] FIG. 9 illustrates an example of a message sequence chart for a DS-TWR to which delayed response time information to which the present disclosure may be applied.

[0179] A DS-TWR may essentially include the completion of a SS-TWR exchange initiated by each device, and the combination of their results. A DS-TWR may be initiated by the next higher layer transmitting a ranging data frame carrying a RRMC IE with the Ranging Control Information field set to 2 (i.e., RRMC IE(2)). This frame and its ACK may define a first round trip time measurement. Conveying the RRMC IE in the MCPS-DATA.indication primitive may notify the next higher layer to initiate a second round trip time measurement by transmitting a data frame in the other direction. This data frame may include an RRMC IE with the Ranging Control Information field set to 3 (i.e., RRMC IE(3)) to indicate a continuation of the exchange, and may request the result of the response time and the first round trip time measurement by having both the Response Time Request and Round Trip Time Request fields set to 1. An ACK for this message may complete the second round-trip time measurement. A subsequent message from the initiator may convey the result of the first round-trip time measurement and the response time of the second round-trip time measurement via the RMI IE. When the responder receives the second MCPS-DATA.indication primitive (containing the RMI IE), it may have sufficient information to calculate the TOF between the devices according to the formula described above. Subsequent reporting of the ranging result to the initiator using the RMI IE may be performed depending on the value of the TOF request field of the initiating RRMC IE.

[0180] Below, the DS-TWR ranging procedure that applies embedded ranging time information is described.

[0181] FIG. 10 illustrates an example of a message sequence chart for DS-TWR to which embedded ranging time information to which the present disclosure may be applied.

[0182] For the 3-message DS-TWR exchange of FIG. 4(c) described above, it is required that the initiator side can embed the response time as part of the completion of the second round trip time measurement. In the example of FIG. 10, the DS-TWR can be initiated by an RFRAME carrying an RRMC IE with the TOF Request field set to 0 (i.e., the initiator side does not request ranging reporting) and the Ranging Control Information field set to 2 (i.e., RRMC IE(2)).

[0183] The responder side may initiate the second measurement using an RFRAME carrying an RRMC IE (i.e., RRMC IE(3)) with the Ranging Control Information field set to 3 to indicate the continuation of the exchange after completing the first round trip timing measurement. In this RRMC IE, both the Response Time Request and Round Trip Time Request fields may be set to 1 to request the result of the first round trip timing measurement and the response time for the second round trip timing measurement. The initiator may complete the exchange by sending a final RFRAME containing the result of the first round trip timing in the RMI IE and the response time for the second round trip timing measurement in the RRTI IE.

[0184] When the responder receives the second MCPS-DATA.indication primitive, it may have sufficient information to calculate the TOF between the devices according to the formula described above. If the initiator of the ranging exchange wants to know the result, the initiator may set the TOF request field of the initiating RRMC IE to a value requesting that the responder send the result in the RMI IE of a subsequent message at the end of the exchange.

[0185] Below, we describe other procedures for adjusting RDEV and ERDEV.

[0186] For successful interoperability of HRP-ERDEV when STS is used, the transmitter and receiver need to be aligned with respect to the seeds (i.e., STS key and data values ​​V) used to generate the STS at the transmitter and to generate the sequence for correlating with the received STS at the receiver. For the coordination of these values, the Secure Private Data Communication capability can be used, and the seeds can be transmitted between devices using the Ranging STS Key and Data (RKSD) IE. The counter values ​​within the RSKD IE can relate to the current packet or future packets, as indicated by the current packet (CP) field of the IE. Upper layers can use the received RSKD IE information (e.g., via PIB attributes such as phyHrpUwbStsKey, phyHrpUwbStsVUpper96, phyHrpUwbStsVCounter) and set the STS seeds appropriately for future packet transmission and reception. The header IE version of the RSKD IE can be used to synchronize the STS generator using information transmitted with the secured payload IE and data.

[0187] When a frame containing an RSKD IE header IE is received, the IE may be passed to the next upper layer to set properties such as phyHrpUwbStsKey, phyHrpUwbStsVUpper96, and phyHrpUwbStsVCounter appropriately for STS generation. If a frame containing an RSKD IE header IE does not pass the encoding security processing, for example, if the receiver does not have a key to validate the message integrity code (MIC), the RSKD IE may be passed to the next upper layer via the HeaderIeList parameter of the MLME-COMM-STATUS.indication primitive.

[0188] Multi-node ranging

[0189] Multi-node ranging can involve ranging between two or more devices. Each device can perform a role in multi-node ranging.

[0190] FIG. 11 is a diagram illustrating the role of a device in a ranging procedure to which the present disclosure can be applied.

[0191] A controller may correspond to an ERDEV that sends a ranging control message (RCM) and defines ranging parameters. The RCM may correspond to a data frame containing an advanced control (ARC) IE. A controlee may correspond to an ERDEV that uses the ranging parameters provided by the controller through the RCM. An initiator corresponds to an ERDEV that sends the first ranging message after the RCM and initiates a ranging exchange, and the initiator may be either the controller or the controlee. A responder corresponds to an ERDEV that responds to a ranging initiation message received from the initiator, and the responder may be either the controller or the controlee.

[0192] The next higher layer of the controller can determine the ranging parameters and the role of the ERDEV participating in the ranging exchange (i.e., initiator or responder).

[0193] For example, in Fig. 11(a), an example is shown in which a controller transmitting a ranging control message (RCM) is an initiator transmitting a ranging initiation message in a ranging exchange, and a controllable receiving the RCM is a responder receiving the ranging initiation message in a ranging exchange and transmitting a ranging response message. In Fig. 11(b), an example is shown in which a controller transmitting an RCM is a responder receiving the ranging initiation message in a ranging exchange and transmitting a ranging response message, and a controllable receiving the RCM is an initiator transmitting a ranging initiation message in a ranging exchange.

[0194] A ranging session can be defined as a group of ERDEVs participating in a continuous ranging procedure established by an initial set of ranging parameters. A ranging session can include only one controller and one or more initiators. The controller can set the initial ranging parameters and update the parameters during the ranging session.

[0195] Figure 12 shows examples of ARC IE, RDM IE, RBU IE, RR IE, and SRRE IE formats to which the present disclosure can be applied.

[0196] Figure 12(a) shows an example of the ARC IE format.

[0197] A controller can use the ARC IE to transmit ranging configuration information to a controlled entity. The ARC IE can be transmitted to a single controller via a unicast frame or to multiple controllers via a broadcast frame.

[0198] The controlee can use the ARC IE to send its preferred ranging parameters to the controller along with the Ranging Change Request (RCR) IE.

[0199] Each field of ARC IE can be defined as follows:

[0200] Meaning of the value of the multi-node mode field 0 Single device to single device (unicast) 1 Multi-node one-to-many 2 Multi-node many-to-many 3 Reserved

[0201] Meaning of the value of the ranging round usage field 0 OWR (one-way ranging) 1 SS-TWR (single-sided two-way ranging) 2 DS-TWR (double-sided two-way ranging) 3 Ranging ancillary information exchange

[0202] The value of the STS packet config field. The resulting STS packet configuration. 0 The STS field is not included in the PPDU (Figure 3(a)). 1 STS packet structure #1 (Figure 3(b)). 2 STS packet structure #2 (Figure 3(c)). 3 STS packet structure #3 (Figure 3(d)).

[0203] The value of the schedule mode field is the selected ranging schedule mode and behavior. 0 Contention-based ranging is used for subsequent ranging rounds, and the RDM IE and RCPS IE are used for controlled participation. 1 Scheduled-based ranging is used for subsequent ranging rounds, and participation and time slot allocation for ranging is fixed or controlled through the use of the RDM IE.

[0204] The contention-based ranging type corresponds to a method in which the controller is unaware of the presence or number of controllees, and thus ERDEVs perform contention-based ranging. Because collisions can occur, filtering of incorrect or erroneous ranging results may be required at higher layers. The initiator or responder may compete to transmit within an appropriate time slot. If the initiator and responder compete, the ranging contention phase structure (RCPS) information element is added to the ARC information element to specify different phases (e.g., distinguished by slot index) in the RCM. Upon receiving the RCM, the controllee is informed that it has been selected to participate in a ranging round. The time-scheduled ranging type corresponds to a method in which the controller is aware of all controllees and specifies a precise schedule for ranging transmissions. The controller can select devices participating in ranging, assign them ranging roles (i.e., initiator or responder), and allocate time slots through the RDM (ranging device management) IE. If the device roles and transmission schedules are pre-specified, such as through OOB signaling, the RDM IE can be omitted.

[0205] Whether deferred mode is allowed in the measurement report. 0RRTI IE is embedded in the response frame so that the round-trip measurement is completed immediately. 1Round-trip time or response time is reported in the measurement reporting phase.

[0206] The value of the time structure indicator field. The selected ranging time structure behavior. 0 The time structure is interval-based, and the RIU IE is used to control ranging interval updates. 1 The time structure is block-based, and the RR IE is used to control ranging interval updates.

[0207] The RCM Validity Rounds field indicates the number of consecutive ranging rounds controlled by the RCM, which can be used to define a set of ranging rounds. The MMRCR (multiple message receipt confirmation request) field can indicate whether multiple message receipt confirmation is requested.

[0208] The content control field can indicate whether other fields are present in the ARC IE. Bits 0, 1, 2, and 3 of the content control field correspond to a field indicating the presence of a ranging block duration (RBD) field (i.e., RBDP), a field indicating the presence of a ranging round duration (RRD) field (i.e., RRDP), a field indicating the presence of a ranging slot duration (RSD) field (i.e., RSDP), and a field indicating the presence of a session ID field (i.e., SIP), respectively. Bits 4-7 of the content control field may be reserved.

[0209] The RBD field can indicate the duration (in RSTU units) of the ranging block.

[0210] The RRD field can indicate the duration of a ranging round (in units of ranging slots, i.e., the number of ranging slots within a ranging round).

[0211] The RSD field can indicate the duration (in RSTU units) of the ranging slot.

[0212] The SID field can indicate a unique identifier for each controller.

[0213] If the ranging block structure is identical to the previously specified duration, one or more of the duration fields (e.g., RBD field, RRD field, RSD field) may not be present in the ACI IE of the current RCM. In this case, other fields (e.g., Schedule Mode field, STS Packet Configuration field, etc.) may be used to update the corresponding ranging parameters.

[0214] Figure 12(b) shows an example of the RDM (ranging device management) IE format.

[0215] The RDM IE can be used by the controller to exchange scheduling information between ERDEVs for a set of ranging rounds specified in the same RCM.

[0216] The SIU (slot index usage) field can indicate whether the slot index of an RDM list element is used. If the value is 0, the RDM IE can be used to assign ranging roles (i.e., initiator or responder) to controllable parties for contention-based ranging. If the value is 1, the RDM IE can be used to allocate time slots and assign ranging roles to controllable parties for scheduling-based ranging.

[0217] The address size field indicates the size of the address used in the RDM list field, with 0 indicating that a short address (16 bits) is used and 1 indicating that an extended address (64 bits) is used.

[0218] The RDM list length field can indicate the number of RDM list elements.

[0219] The ranging role field in the RDM list can indicate the initiator or responder. The ranging slot index field in the RDM list can indicate the slot index assigned to the device with the corresponding address. The address field in the RDM list can indicate the address of each device participating in ranging.

[0220] Figure 12(c) shows an example of the RBU (ranging block update) IE format.

[0221] The RBU IE can be used by the controller to inform the controllable(s) of the updated ranging block structure.

[0222] The relative ranging block index field may indicate the number of remaining ranging blocks according to the current configuration before switching to a new configuration.

[0223] The updated block duration field may indicate the duration (in RSTU units) of the new ranging block.

[0224] The updated ranging round duration field may indicate a ranging round duration value that is an integer multiple of the ranging slot duration within the new ranging block structure.

[0225] The updated ranging slot duration can indicate the duration (in RSTU units) of a ranging slot within the new ranging block structure.

[0226] Figure 12(d) shows an example of the RR (Ranging Round) IE format.

[0227] The ranging block index field can indicate the index of a ranging block.

[0228] The hopping mode field can indicate whether hopping mode is supported for the ranging block.

[0229] The round index field can indicate a ranging round index within a ranging block.

[0230] The transmission offset field may indicate the transmission offset value (in RSTU units) of a ranging round within a block. The transmission offset may have a maximum value equal to the maximum slot duration minus the packet duration.

[0231] For the current ranging round (i.e., the ranging round in the ranging block with block index i), the RR IE may be included in the RCM of the ranging block with block index i. In this case, the RR IE may correspond to information that supports ERDEV synchronization for the block structure.

[0232] For the next ranging round (i.e., the ranging round in the next ranging block with block index i+1), when the last message of the current ranging round (i.e., the ranging block with block index i) is transmitted from the controller to the controlled party(ies), the RR IE may be transmitted within the final message to inform the ranging round information for the ranging block with block index i+1.

[0233] If the last message within the current ranging round (i.e., ranging block with block index i) is transmitted from the controllable, the controllable can transmit a RR IE in the RCM of the next ranging block with block index i+1 to inform the ranging round information for the ranging block with block index i+2.

[0234] In this case, the RCM in the ranging block with block index i+1 may contain two RR IEs. One RR IE may be applied to the ranging round of the ranging block with block index i+1, and the other RR IE may be applied to the ranging round of the ranging block with block index i+2.

[0235] Figure 12(e) shows an example of the SRRR (SP3 ranging request reports) IE format.

[0236] The SRRR IE can be used to request reporting of AOA and / or response time and / or round-trip time measurements from a requestor to a provider.

[0237] Each of the requester address size specifier field and the provider address size specifier field can have values ​​of 00, 01, 10, and 11 as shown in Table 1 above, and can indicate that the address does not exist, or that a short address (16 bits) or an extended address (64 bits) is used.

[0238] The RAOA (report of AOA) field can indicate whether a report on AOA is requested.

[0239] The RRT (report of reply time) field can indicate whether a report on the response time is requested.

[0240] The RRTT (report of round-trip time) field can indicate whether to request a report on the round-trip time.

[0241] The RTOF (report of TOF) field can indicate whether a report on TOF is requested.

[0242] The Requester Address field may be set to the address of the device transmitting the signal for which AOA is being measured or initiating ranging.

[0243] The Provider Address field can be set to the address of the device measuring AOA.

[0244] Ranging block and round structure

[0245] FIG. 13 is a diagram for explaining a ranging block structure and ranging phase to which the present disclosure can be applied.

[0246] In Fig. 13(a), a ranging block is a time interval for performing ranging, and one ranging block can include N ranging rounds.

[0247] A ranging round is a time sufficient for ERDEVs participating in a ranging exchange to complete a ranging measurement cycle, and one ranging round may include M ranging slots.

[0248] A ranging slot may correspond to a time sufficient for transmission of one or more RFRAMEs.

[0249] The slot duration, or the number of slots included in a ranging round, may vary between ranging rounds. To achieve this, the controller can send an RCM to the controlled party(ies) that changes the ranging round settings.

[0250] The RCM (ranging control message) is the first message transmitted by the controller and may be transmitted in the first slot of a ranging round. The RCM may include configuration information for ranging parameters.

[0251] RCUM (ranging control update message) is a message transmitted by the controller in the last slot of the ranging round(s) specified by the RCM to update ranging parameters for the next ranging round(s). The IE(s) included in the RCM for updating ranging parameters may be included in the RCUM.

[0252] A RIUM (ranging interval update message) is a message sent by the controller to update the interval between ranging blocks and to facilitate synchronization between participating ERDEVs. The RCUM contains the scheduled time of the first RIUM, and may contain the scheduled time of the next RIUM (if used) before the start of the next ranging block.

[0253] Figure 13(b) describes the phases in the ranging procedure.

[0254] RCP (ranging control phase) corresponds to the phase in which the controller transmits RCM.

[0255] RP (ranging phase) can include RIP (ranging initiation phase), RRP (ranging response phase), and RFP (ranging final phase).

[0256] RIP corresponds to the phase where the initiator sends ranging initiation message(s) to the responder(s).

[0257] RRP corresponds to the phase in which the responder(s) send response message(s) to the initiator.

[0258] RFP corresponds to the phase in which the initiator sends ranging final message(s) to the responder, and can only be used in DS-TWR.

[0259] MRP (measurement report phase) is the phase in which participating ERDEVs exchange service information related to ranging measurements.

[0260] RCUP (ranging control update phase) corresponds to the phase in which the controller transmits RCUM, and if RCUP exists, the phase can be located in the last slot of the set of ranging rounds specified by RCM.

[0261] RIUP (ranging interval update phase) corresponds to the phase in which the controller transmits RIUM.

[0262] FIG. 14 illustrates examples of timing diagrams for various multi-device ranging to which the present disclosure may be applied.

[0263] Fig. 14(a) is an example of OWR, Fig. 14(b) is an example of SS-TWR, Fig. 14(c) is an example of a combination of RCP and RIP in SS-TWR, Fig. 14(d) is an example of DS-TWR, Fig. 14(e) is an example of many-to-many SS-TWR, and Fig. 14(b) is an example of many-to-many DS-TWR.

[0264] Below we will explain the ranging mode.

[0265] In interval-based mode, the average time of ranging rounds is variable, and a time structure can be applied with adaptive spacing.

[0266] In block-based mode, the average duration of ranging rounds is constant. That is, ranging blocks with the same duration can be repeated in block-based mode.

[0267] Ranging mode selection can be determined based on the OOB mechanism or the time structure indicator field within the ARC IE.

[0268] FIG. 15 shows a time diagram in an example of a block-based mode to which the present disclosure can be applied.

[0269] In block-based mode, the ranging block structure can utilize a structured timeline. The ranging block structure setup can include specifying the ranging block duration (RBD), ranging round duration (RRD), and ranging slot duration (RSD) based on the corresponding fields in the ARC IE.

[0270] The number of ranging rounds is equal to the ranging block duration divided by the ranging round duration.

[0271] The number of ranging slots is equal to the ranging round duration divided by the ranging slot duration.

[0272] An ERDEV receiving an RCM can set up an associated timeline for ranging based on the initial ranging block structure and the values ​​of fields within the ARC IE. The ranging block structure can be set up and / or fixed by the next higher layer.

[0273] The ranging block structure can be repeatedly transmitted by the controller in every RCM (e.g., via the ARC IE). When a change or update of the ranging block structure (i.e., a new ranging block duration, ranging round duration, and / or ranging slot duration) is required, the controller can transmit an RBU IE for the new configuration. The RBU IE can be transmitted via the RCM or the final data frame in the ranging message sequence. Each time an RBU IE is transmitted, the controller can decrement the Relative Ranging Block Index by one until it becomes 0. This can indicate whether the new configuration is to be used in the next block and whether the RCM ARC IE of the next block includes the new configuration.

[0274] Below we will explain indexing.

[0275] For ranging blocks, the block index is given as 0 for the first ranging block, and relative block indices are determined for the remaining blocks using block index 0 as a reference.

[0276] For a ranging round, if one ranging block contains N ranging rounds, the round index is given as 0 for the first ranging round in the current ranging block, and relative round indices (e.g., 1, ..., M-1) are determined for the remaining N-1 rounds using round index 0 as a reference.

[0277] For ranging slots, if one ranging round includes M ranging slots, the slot index is given as 0 for the first ranging slot in the current ranging round, and relative slot indices (e.g., 1, ..., M-1) are determined for the remaining M-1 slots using slot index 0 as a reference.

[0278] A new ranging message exchange can be sent / received as the first RCM in the ranging slot with index 0 of the ranging round with index 0 of the ranging block with index 0. That is, the RCM packet can be sent at the beginning of the first ranging slot of the first ranging round. The RCM can include a RR IE to inform information related to the ranging rounds within the current ranging block.

[0279] FIG. 16 is a diagram illustrating examples of various transmission offsets to which the present disclosure can be applied.

[0280] The RR IE included in the RCM may include transmission offset information as information associated with the ranging round within the current ranging block. In subsequent ranging rounds, the controller may initiate transmission in each slot based on a different transmission offset. The transmission offset may have a value less than the ranging slot duration minus the UWB packet duration. The transmission offset may be expressed as a multiple of the RSTU.

[0281] Transmit offsets can be applied across ranging rounds. That is, the same transmit offset can be applied to all packet transmissions within the same ranging round. The next higher layer of the controller can select the transmit offset and communicate it to all other devices via the RR IE. The controller can also vary the transmit offset for each ranging round based on the power required to reduce interference.

[0282] One-to-many ranging procedure

[0283] FIG. 17 illustrates an example of a message sequence chart for a one-to-many SS-TWR to which the present disclosure may be applied.

[0284] In a ranging procedure for a one-to-many TWR, the ranging exchange is initiated by an initiator sending a RRMC IE, which may be included in a ranging initiation message that is broadcast to multiple responders.

[0285] An RRMC IE with the Ranging Control Information field set to 0 (i.e., RRMC IE(0)) may be sent as an SS-TWR Ranging Initiation message. The Response Time Request field of the RRMC IE may be set to 1 to request a response time from the response ERDEV.

[0286] The RRMC IE transmitted via the MCPS-DATA.indication primitive from each of Responder-1 to Responder-N may signal to the next higher layer that a ranging response should be performed. Each responder may insert the RequestRrtiTxList parameter into the RRTI IE (as a response to the response time request in the RRMC IE) and transmit an RRMC IE with the Ranging Control Information field set to 1 (i.e., RRMC IE(1)) to the initiator. Here, the response RFRAMEs may be transmitted in a unicast manner to the initiator.

[0287] When the initiator receives each ranging response frame, the initiator has enough information to compute the TOF of that responder.

[0288] The final message broadcast by the initiator may include one or more RMI IE(s) for measurement reporting (if requested by the RRMC IE). Multiple RMI IEs may be distinguished by their associated devices by their address fields. For example, Responder-1 may set the TOF Request field in the RRMC IE to 1, and Responder-N may set the Round Trip Time Request field in the RRMC IE to 1. If multiple responders request the same set of information, such as TOF, measurement reporting from the initiator may be performed via a single RMI IE in the final data message.

[0289] FIG. 18 illustrates an example of a message sequence chart for an SP3 one-to-many SS-TWR to which the present disclosure may be applied.

[0290] At the start of a ranging round, the RCM may send ranging configuration information and related IEs. The SRRR IE (I, R_1) may have the RAOA and RRTT fields set to 1 if the Responder-1 requests AOA and round-trip time from the Initiator.

[0291] Multi-node SP3 ranging can be based on scheduling specified by the next higher layer of the controller (i.e. each time slot is assigned to be used by a specific ERDEV).

[0292] The RDM IE within the RCM may contain information for allocating time slots and device roles within a ranging round. The ARC IE specifies the ranging procedure and the SP3 packet format so that the next upper layer of the ERDEV can recognize the start and end of the SP3 ranging phase and issue the MLME-STS primitive to enable / disable SP3 packets before / after the ranging phase.

[0293] An RSKD IE may be included to exchange portions of the STS seed to initiate STS generation between participating ERDEVs in RCM. Based on the scheduling information of the ranging transmission, the STS counter values ​​of the participating ERDEVs may be appropriately set for transmitting and receiving SP3 packets.

[0294] In the SP3 ranging phase, the next higher layer can use MLME-STS.request to select the SP3 packet format, configure the operation on both sides appropriately, and set the phyHrpUwbStsKey, phyHrpUwbStsVUpper96, and phyHrpUwbStsVCounter properties to the correct values. Since the ranging schedule is specified by the RCM preceding the SP3 ranging, the devices already know the participants. Each time slot can be assigned to a specific (E)RDEV.

[0295] In the measurement reporting phase, the initiator may send the AOA and round-trip time to Responder-1 via the RMI IE. Responder-1 to Responder-N may each embed the requested response time in the RMI IE they send to the initiator.

[0296] As another example, in the SP3 ranging phase of a message sequence for an SP3 one-to-many DS-TWR, after the initiator receives an SP3 frame as a ranging response message from each responder, the initiator may transmit an SP3 frame as a ranging complete message to each responder, through which the local value of the initiator's TxRangingCounter may be conveyed to each responder. In the measurement reporting phase, the initiator may transmit an RMI IE including the response time and round trip time to the responders, and in response, each responder may transmit an RMI IE including an AOA to the initiator.

[0297] Hyperblock-based mode

[0298] FIG. 19 illustrates an example of a time structure in a hyper block-based mode according to the present disclosure.

[0299] In the example of Fig. 19(a), a hyper block may correspond to a group of blocks. A hyper block-based mode may allow groups of blocks with different settings (e.g., block duration, round duration, slot duration, etc.). A hyper block may be executed based on an interval-based mode or a block-based mode. Different hyper blocks may have the same or different settings.

[0300] As in the example of Fig. 19(b), information about the settings for the hyper block structure can be repeatedly transmitted by the controller via the RCM (or the frame including the block allocation schedule information described above). For this purpose, an HBS (hyper block structure) IE can be defined. For example, the HBS IE can include an index of the corresponding block, a block duration for each of all blocks included in the hyper block, a list of controllables corresponding to each block, etc. A controllable that receives the HBS IE included in the RCM (or the frame including the block allocation schedule information described above) can know that the hyper block structure is applied / progressing, and can know in which block it is performing an operation.

[0301] For hyper block-based mode execution, the controller may transmit an RCM containing an HBS IE (or a frame containing the aforementioned block allocation schedule information) to the controllable(ies) to configure a hyper block. The message / frame containing the HBS IE may be transmitted at the time of transmitting the aforementioned block allocation schedule information. For block configuration, the RCM (or the frame containing the aforementioned block allocation schedule information) of the corresponding block may further include an ARC IE.

[0302] As described above, the hyper block-based mode can be performed based on the block-based mode or based on the interval-based mode. When performed based on the interval-based mode, the controller can use the RIU IE to specify the interval between the start times of blocks having the same index within each hyper block. For example, the controller can transmit an RCM (or a frame including the block allocation schedule information described above) including the RIU IE at the start time of the first block (i.e., block 0) of each hyper block (i.e., the start of slot 0 of round 0 of block 0). Since the RCM (or the frame including the block allocation schedule information described above) is transmitted at the start time of block 0 within hyper block K including the RIU IE, the block interval field of the RIU IE can indicate the remaining time until the start time of block 0 within hyper block K+1 including the RIU IE.

[0303] FIG. 20 is a diagram showing an example of the HBS IE format according to the present disclosure.

[0304] The HBS IE of FIG. 20(a) may include information about the duration of each ranging block (i.e., relative block) within a hyperblock. The HBS IE may include an associated ranging block index field and a ranging block description list field for all ranging blocks within the hyperblock. A controllable receiving the HBS IE through the RCM (or a frame including the aforementioned block allocation schedule information) may recognize the existence of a hyperblock.

[0305] In the example of Figure 20(a), the hyper block index field can indicate the index of the hyper block.

[0306] The content control field may include a ranging block duration unit field, a ranging round duration presence field within a ranging block description list element, and a ranging slot duration presence field within a ranging block description list element, as shown in FIG. 20(b).

[0307] The ranging block duration unit field of the content control field can indicate the size of the ranging block duration field as follows.

[0308] Meaning of the value of the ranging block duration unit field 00 The size of the ranging block duration field is 1 octet, and the unit of the ranging block duration field is the number of rounds 01 The size of the ranging block duration field is 2 octets, and the unit of the ranging block duration field is the number of slots 10 The size of the ranging block duration field is 3 octets, and the unit of the ranging block duration field is the number of RSTUs 11 Reserved

[0309] The Ranging Round Duration Existence field of the Content Control Field may indicate that the Ranging Round Duration field exists in the Ranging Block Description List element if its value is 1, and may indicate that it does not exist if its value is 0.

[0310] The Ranging Slot Duration Existence field of the Content Control Field may indicate that the Ranging Slot Duration field exists in the Ranging Block Description List element if its value is 1, and may indicate that it does not exist if its value is 0.

[0311] Referring again to FIG. 20(a), the ranging block description list length field may indicate the total number of ranging blocks belonging to the hyper block (and also the total number of block description list elements corresponding to the total number of ranging blocks).

[0312] The ranging block description list field may contain a list of description elements for each of the entire blocks belonging to the hyperblock.

[0313] FIG. 20(c) illustrates an example of the format of each of one or more elements included in the ranging block description list.

[0314] The relative block index field can indicate the index of a ranging block (i.e., a relative block) within a hyperblock. The index value of a ranging block within each hyperblock can start from 0.

[0315] The size of the ranging block duration field is determined according to the value of the ranging block duration unit field of the aforementioned content field, and can be set to an unsigned integer value indicating a ranging block duration value based on the unit.

[0316] The ranging round duration field can be set to an unsigned integer value corresponding to the number of ranging slots per ranging round.

[0317] The ranging slot duration field can be set to an unsigned integer value corresponding to the ranging slot duration in RSTU units.

[0318] Bitmap-based hyperblock scheduling

[0319] The scheduling IE can be used by the controller to schedule slots to be used by the intended device. For example, to enable the controlee to know the scheduling information of the hyperblock, the controller can send a control message to the controlee containing the scheduling IE (e.g., a scheduling IE with the scheduling list type field set to 5, i.e., corresponding to bitmap-based hyperblock scheduling) together with the HBS IE.

[0320] FIG. 21 is a diagram showing an example of a scheduling IE format according to the present disclosure.

[0321] Figure 21(a) shows an example of the content field format of the scheduling IE.

[0322] The scheduling list length field can indicate the number of elements contained in the scheduling list field. The elements contained in the scheduling list field can have a format according to the value of the scheduling list type field. The scheduling list type field can be defined as shown in Table 9. In the example of Table 9, Type 5 can be set for the hyper block-based mode described above.

[0323] Scheduling List Type Field Value Meaning 0 Per-slot scheduling 1 Consecutive slot scheduling 2 Bitmap-based scheduling 3 Periodic scheduling 4 Ranging sequence fragment (RSF) scheduling 5 Bitmap-based block scheduling 6-7 Reserved

[0324] The address size field can indicate the size of the sender address field, the receiver address field, or the addresses in the address list (in the case of block allocation scheduling). If the value of the receiver address present field is 1, the receiver address field is present, and if the value is 0, the receiver address field is not present.

[0325] Figure 21(b) shows an exemplary format of a scheduling list field when the value of the scheduling list type field is 5.

[0326] The block scheduling bitmap length (or hyper block scheduling bitmap length) field indicates the length of the block scheduling bitmap (or hyper block scheduling bitmap) field, and can be set as shown in Table 10.

[0327] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field 08 bits (i.e., 8-bit bitmap) 116 bits (i.e., 16-bit bitmap) 232 bits (i.e., 32-bit bitmap) 364 bits (i.e., 64-bit bitmap)

[0328] A block scheduling bitmap can enable a device using a single scheduling list element to schedule multiple blocks within a hyperblock. The bitmap within each scheduling list element can indicate a pattern of blocks scheduled to a single device. The index of a block description list element in an HBS IE can be matched with each bit. For example, the first element of the block description list in an HBS IE can be applied to the same block as the first bit of the bitmap. Accordingly, a device receiving an HBS IE and a scheduling IE (Type 5) can know the index and block duration of the block to be activated.

[0329] A sender address can represent each participating device.

[0330] A scheduling IE with a scheduling list type of 5 or a similar container for hyper-block scheduling may be transmitted in a control message at the same frequency as the HBS IE. If a scheduling IE (type 5) is not transmitted with the HBS IE, it may mean that it does not contain hyper-block scheduling information, or it may mean that the most recently received scheduling IE (type 5) remains unchanged. A scheduling IE (type 5) may be reused, or its information may have an expiration time.

[0331] Block-based bitmap scheduling using Scheduling IE (Type 5) can be applied not only to hyper block-based mode but also to general block-based mode (i.e., general block-based mode where hyper blocks are not defined). The bitmap size / length defined for block-based bitmap scheduling in hyper block-based mode and block-based mode can be defined as 8, 16, 32, or 64 bits, as shown in Table 10. The maximum number of blocks that can be scheduled through the bitmap for each device can be defined as 64. Meanwhile, in the existing 802.15.4z and 802.15.4ab technologies, the (relative) block index defined in hyper block-based mode and the block index defined in general block-based mode can be defined as 2 octets. The maximum number of blocks that can be allocated using this 2-octet block index field can be 256 or 65536. Thus, since the length of the bitmap of the currently defined scheduling IE (type 5) is at most 64 bits, it needs to be extended or changed to support up to 65536 blocks.

[0332] Therefore, an efficient method is required to minimize signaling overhead while supporting a large number of block indices when applying bitmap-based block scheduling in hyper block-based mode.

[0333] Various examples of the present disclosure for optimizing the bitmap size of the HBS IE and scheduling IE, including information that can maximize power saving of the device, by applying a hyper block-based mode and a block-by-block duty cycle, are described below.

[0334] FIG. 22 is a drawing for explaining the operation of the first device according to the present disclosure.

[0335] In the example of Fig. 22, the first device may correspond to a controller, and the second device may correspond to a controlee. Additionally, the first device and the second device may correspond to ERDEVs.

[0336] In step S2210, the first device may generate a scheduling IE including an extended bitmap length field and a bitmap field.

[0337] The length of the bitmap field of the scheduling IE may be based on the value of the extended bitmap length field.

[0338] For example, it can be assumed that the maximum number of applicable block index values ​​is 256 (or the maximum range of block index values ​​is 0-255, or the size of the block index field is 1 octet). In this case, the extended bitmap length field can be a bitmap length field having a size greater than 2 bits (e.g., 3 bits). The eight values ​​(e.g., 0-7) of the 3-bit bitmap length field can indicate eight different bitmap lengths, respectively. For example, the minimum value of the eight bitmap lengths can be 8 bits, and the maximum value can be 256 bits. For example, the eight bitmap lengths can be 8, 16, 32, 64, 96, 128, 192, and 256.

[0339] Alternatively, it can be assumed that the maximum number of applicable block index values ​​is 65536 (or the maximum range of block index values ​​is 0-65535, or the size of the block index field is 2 octets). In this case, the extended bitmap length field can be a bitmap length field with a size of 4 bits. The 16 values ​​(e.g., 0-15) of the 4-bit bitmap length field can indicate 16 different bitmap lengths, respectively.

[0340] Alternatively, the extended bitmap length field may support an extended length bitmap by using a bitmap length field having a size of 2 bits and a scaling factor having a size of 1 bit. Alternatively, the extended bitmap length field may support an extended length bitmap by using a bitmap length field having a size of 2 bits and a scaling factor having a size of 2 bits. Accordingly, an extended size bitmap length can be supported based on the value of the bitmap length field and the value of the scaling factor.

[0341] Additionally or alternatively, a more blocks bit / field may be added to the scheduling IE. The more blocks bit / field may indicate whether the number of scheduled blocks is greater than the number of blocks specified by the bitmap length.

[0342] The value of the scheduling list type field of this scheduling IE can be set to a value indicating bitmap-based block scheduling or 5. With respect to the hyperblock-based mode, each bit of the bitmap of the bitmap field can be applied to each block within one hyperblock.

[0343] In step S2220, the first device can transmit a control message including a scheduling IE to the second device.

[0344] A bit set to 1 in the bitmap of the bitmap field included in the scheduling IE may indicate that the corresponding block is scheduled to the second device, and a bit set to 0 in the bitmap may indicate that the corresponding block is not scheduled to the second device. Accordingly, a power saving operation may be performed by the second device in the unscheduled block.

[0345] The scheduling IE can be transmitted in the same ranging round as the HBS IE for block scheduling in hyperblock mode. For example, the size of the block index field in the ranging block description list of the HBS IE can be 1 octet or 2 octets.

[0346] In the example of FIG. 22, the control message including the scheduling IE and the HBS IE may be included in a narrowband PPDU according to the O-QPSK PHY as in FIG. 2, or may be included in a UWB PPDU as in FIG. 2 or FIG. 3.

[0347] As an additional or alternative example to the example of FIG. 22, a control message including a scheduling IE may be generated by the first device (or the transmitting device). The scheduling IE may include information about which block each device is active in (e.g., a block scheduling bitmap for a hyper block of a scheduling list element). If the number of blocks exceeds the maximum number of bitmap lengths (e.g., 64) or it is necessary to configure block scheduling information, the more blocks field may be set to 1. Otherwise, the more blocks field may be set to 0. An IE (e.g., an HBS IE, an RR IE, etc.) including information such as a block index and block duration may be transmitted together with the scheduling IE. An RCM including the scheduling IE generated in this way may be converted into a PPDU and transmitted to a receiving device (e.g., a second device).

[0348] The method described in the example of FIG. 22 may be performed by the first device (100) of FIG. 1. For example, one or more processors (102) of the first device (100) of FIG. 1 may be configured to generate a scheduling IE including an extended bitmap length field and a bitmap field, and transmit the scheduling IE to a second device via one or more transceivers (106). Furthermore, one or more memories (104) of the first device (100) may store commands for performing the method described in the example of FIG. 22 or the examples described below when executed by one or more processors (102).

[0349] For example, the processor (102) may construct a packet based on information stored in the memory (104). The packet generated by the processor (102) may have the format of the scheduling IE described in the present disclosure. The processor (102) may generate a transmission packet and store information about the transmission packet in the memory (104).

[0350] FIG. 23 is a drawing for explaining the operation of a second device according to the present disclosure.

[0351] In step S2310, the second device may receive a control message from the first device that includes a scheduling IE including an extended bitmap length field and a bitmap field.

[0352] In step S2320, the second device can perform signal transmission or reception in a block scheduled to the second device based on the bitmap of the bitmap field.

[0353] In the example of Fig. 23, the specific features of the scheduling IE, the features of the HBS IE included in the control message together with the scheduling IE, etc. are the same as those described in the example of Fig. 22, so redundant descriptions are omitted.

[0354] As an additional or alternative example to the example of FIG. 23, the second device (or receiving device) can obtain block scheduling information by decoding a control message / PPDU including a received scheduling IE. The second device can obtain the block scheduling information included in the second device and check the more blocks value included therein. If the more blocks value is 1, the second device can obtain current block information (e.g., block index, block duration, hyper block information, etc.) since more blocks are scheduled than the block scheduling bitmap length, and map the block scheduling bitmap and block scheduled index information based on the information of the current block. Accordingly, the second device can obtain information on the block(s) in which it is scheduled and determine a duty cycle. The second device can repeat active / sleep according to the duty cycle, and can attempt to receive RCM again when the multiple blocks duration (e.g., calculated based on the block scheduling bitmap length and block information) expires. Alternatively, if the value of the more block is 0, the second device can check the duration to determine whether to re-receive RCM if there is information that can derive the remaining duration, such as in hyper block mode, and if there is no information that can derive the remaining duration, such as in hyper block mode, the second device can attempt to receive RCM for each block until it receives scheduling information with a more block value of 1.

[0355] The method described in the example of FIG. 23 may be performed by the second device (200) of FIG. 1. For example, one or more processors (202) of the second device (200) of FIG. 1 may be configured to receive a control message including a scheduling IE including an extended bitmap length field and a bitmap field from the first device through one or more transceivers (206), and to perform signal transmission or reception through one or more transceivers (206) in a block scheduled to the second device based on a bitmap of the bitmap field. Furthermore, one or more memories (204) of the second device (200) may store commands for performing the method described in the example of FIG. 23 or the examples described below when executed by one or more processors (202).

[0356] For example, the processor (202) can perform decoding on the received packet. Specifically, noise and interference can be removed through amplification and filtering, and the signal can be converted into binary data through sampling, demodulation, and decoding. For example, a BPSK or O-QPSK demodulator can be used in the decoding process, and a process of mapping chips to symbols, convolution, Reed-Salomon decoding, etc. can be performed. The restored data can be used to extract the original transmitted information. This can include error correction, data recovery techniques, etc. to confirm that the transmitted data has been accurately received. In addition, the processor (202) can decode the data field of the packet received through the transceiver (206). In addition, the processor (202) can process the decoded data. For example, the processor (202) can perform a processing operation to transmit information about the decoded data field to a higher layer (e.g., a MAC layer). Additionally, if the generation of a signal is instructed from the upper layer to the PHY layer in response to data transmitted to the upper layer, subsequent operations can be performed.

[0357] The examples of FIGS. 22 and 23 may correspond to some of the various examples of the present disclosure. Below, various examples of the present disclosure, including the examples of FIGS. 22 and 23, are described in more detail.

[0358] Example 1

[0359] This embodiment is directed to a method for reducing signaling overhead associated with bitmap-based block scheduling.

[0360] Example 1-1

[0361] If the block index field is 2 octets in size, up to 65536 block indices can be supported. In this case, the maximum length of the bitmap of bitmap-based block scheduling (e.g., scheduling IE type 5) that maps to the number of blocks can be extended to support 65536. For example, the values ​​of the block scheduling bitmap length field and the length of the bitmap indicated by each value can be defined as in the table below.

[0362] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field 08-bit bitmap 116-bit bitmap 232-bit bitmap 364-bit bitmap 4128-bit bitmap 5256-bit bitmap 6512-bit bitmap 71024-bit bitmap 82048-bit bitmap 94096-bit bitmap 108192-bit bitmap 1116384-bit bitmap 1232768-bit bitmap 1365536-bit bitmap 14Reserved 15Reserved

[0363] Additionally or alternatively, to apply finer gradualness, the values ​​of the block scheduling bitmap length field and the length of the bitmap indicated by each value can be defined as in the table below.

[0364] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field 0 8-bit bitmap 1 16-bit bitmap 2 32-bit bitmap 3 64-bit bitmap 4 96-bit bitmap 5 128-bit bitmap 6 192-bit bitmap 7 256-bit bitmap 8 5 12-bit bitmap 9 1024-bit bitmap 10 2048-bit bitmap 1 1 4096-bit bitmap 1 28 192-bit bitmap 1 3 16 384-bit bitmap 1 4 32 768-bit bitmap 1 5 6 5 36-bit bitmap

[0365] When defining a block scheduling bitmap length field for a block-based mode as in the examples described above, a scheduling list element within a scheduling IE with a scheduling list type value set to 5 (or for bitmap-based block scheduling) can be defined as in Fig. 24(a). Embodiment 1-2

[0366] If the block index field is 1 octet in size, up to 256 block indices can be supported. In this case, the maximum length of the bitmap of bitmap-based block scheduling (e.g., scheduling IE type 5) that maps to the number of blocks can be extended to support 256. For example, the values ​​of the block scheduling bitmap length field and the length of the bitmap indicated by each value can be defined as in the table below.

[0367] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field 08-bit bitmap 116-bit bitmap 232-bit bitmap 364-bit bitmap 496-bit bitmap 5128-bit bitmap 6192-bit bitmap 7256-bit bitmap

[0368] When defining a block scheduling bitmap length field for block-based mode in this way, a scheduling list element within a scheduling IE with a scheduling list type value set to 5 (or for bitmap-based block scheduling) can be defined as in Fig. 24(b).

[0369] Example 1-3

[0370] An extended range of bitmap lengths may be supported while maintaining the original size and value of the block scheduling bitmap length field by applying a scaling factor to the value of the block scheduling bitmap length field.

[0371] For the case where the block index field is 2 octets in size, for example, when applying a 1-bit scaling factor, the scaling unit can be applied as 1024. In this case, bitmaps with extended lengths such as 8192, 16384, 32768, and 65538 can be supported. The scaling unit and scaling method can be defined in various ways to support various values ​​below the maximum value. The table below shows examples where the scaling unit is set to 0 and 1, and the default value of the bitmap size (i.e., the bitmap size when the scaling factor value is 0) is 8 to 32768.

[0372] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field (Scaling Factor 0) Size of the Block Scheduling Bitmap Field (Scaling Factor 1) 8-bit bitmap 16-bit bitmap 132-bit bitmap 64-bit bitmap 2128-bit bitmap 256-bit bitmap 3512-bit bitmap 1024-bit bitmap 42048-bit bitmap 4096-bit bitmap 58192-bit bitmap 16384-bit bitmap 632768-bit bitmap 65536-bit bitmap 7ReservedReserved

[0373] In the example of the above table, if the value of the scaling factor is 0, it corresponds to the case where no scaling is applied to the block scheduling bitmap length field value or a scaling of *1 (meaning 1x) is applied, and if the value of the scaling factor is 1, it corresponds to the case where a scaling of *2 (meaning 2x) ​​is applied to the block scheduling bitmap length field value. In this way, when defining the block scheduling bitmap length field for the block-based mode, the scheduling list element within the scheduling IE in which the value of the scheduling list type is set to 5 (or for bitmap-based block scheduling) can be defined as in Fig. 24(c).

[0374] Example 1-4

[0375] For cases where the block index field is 1 octet in size, a scaling factor may be applied to support bitmap lengths less than 256 values.

[0376] For example, while defining the size of the block scheduling bitmap length field as 2 bits, by applying a value of 0 or 1 for the scaling factor (e.g., a scaling of *1 or a scaling of *2), various bitmap lengths can be indicated depending on the combination. For example, bitmaps of various lengths can be supported as shown in the table below.

[0377] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field (Scaling Factor 0) Size of the Block Scheduling Bitmap Field (Scaling Factor 1) 8-bit bitmap 96-bit bitmap 116-bit bitmap 128-bit bitmap 232-bit bitmap 196-bit bitmap 364-bit bitmap 256-bit bitmap

[0378] When defining a block scheduling bitmap length field for block-based mode in this way, a scheduling list element within a scheduling IE with a scheduling list type value set to 5 (or for bitmap-based block scheduling) can be defined as in Fig. 24(d). Embodiment 1-5

[0379] For cases where the block index field is 2 octets in size, the unit or value of the scaling factor can be set to 0, 1, 2, or 3 to support various bitmap lengths as shown in the table below. A scaling factor value of 0 corresponds to a scaling of *1 (or no scaling), a scaling factor value of 1 corresponds to a scaling of *16, a scaling factor value of 2 corresponds to a scaling of *256, and a scaling factor value of 3 corresponds to a scaling of *4096.

[0380] Block Scheduling Bitmap Length Field ValueSize of the Block Scheduling Bitmap Field (Scaling Factor 0)Size of the Block Scheduling Bitmap Field (Scaling Factor 1)Size of the Block Scheduling Bitmap Field (Scaling Factor 2)Size of the Block Scheduling Bitmap Field (Scaling Factor 3)08-bit bitmap128-bit bitmap2048-bit bitmap32768-bit bitmap116-bit bitmap256-bit bitmap4096-bit bitmap65536-bit bitmap232-bit bitmap512-bit bitmap8192-bit bitmapReserved364-bit bitmap1024-bit bitmap16384-bit bitmapReserved

[0381] When defining a block scheduling bitmap length field for block-based mode in this way, a scheduling list element within a scheduling IE with a scheduling list type value set to 5 (or for bitmap-based block scheduling) can be defined as in Fig. 24(e).

[0382] Example 1-6

[0383] For cases where the block index field size is 2 octets, bitmap-based block scheduling can be applied, which can support up to 65536 blocks in hyperblock-based mode or block-based mode. As the number of supportable blocks increases, signaling overhead may also increase, so limiting the number of blocks (or bitmap length) that can be indicated in the scheduling IE of bitmap-based block scheduling (or Type 5) may be considered.

[0384] For example, if the maximum number of blocks is limited to 1024, the block scheduling bitmap length field can be set to 2-bit size and the scaling factor can be set to 1-bit size, thereby supporting a total of 8 block scheduling bitmap field lengths. For example, as shown in the table below, it can be defined that when the value of the scaling factor is 0, a scaling of *1 is applied, and when the value of the scaling factor is 1, a scaling of *16 is applied.

[0385] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field (Scaling Factor 0) Size of the Block Scheduling Bitmap Field (Scaling Factor 1) 8-bit bitmap 128-bit bitmap 116-bit bitmap 256-bit bitmap 232-bit bitmap 512-bit bitmap 364-bit bitmap 1024-bit bitmap

[0386] When defining a block scheduling bitmap length field for a block-based mode in this way, a scheduling list element in a scheduling IE in which the value of the scheduling list type is set to 5 (or for bitmap-based block scheduling) can be defined as in FIG. 24(d). The scope of the present disclosure is not limited to cases in which the size of the scaling factor is 1 bit or 2 bits, but can be extended to cases in which a scaling factor of 3 bits or more is applied. In addition, the size (or multiple) of the scaling signified by the value of the scaling factor is not limited to the examples described above, but can be defined as various values. For example, a 3-bit scaling factor field can be defined, and the values ​​of the 8 scaling factors can be defined to correspond to *1, *4, *8, *12, *16, *20, *24, and *28, respectively. The scaling multiples mapped to the values ​​of the scaling factors can also be defined in consideration of the scaling range according to the definition of the values ​​of the existing block scheduling bitmap field. Alternatively, in block-based mode, if bitmap-based block scheduling (or type 5 scheduling IE) is applied, it may only contain scheduling information for the current block. In this case, the block scheduling bitmap length field is set to 0 to indicate that an 8-bit bitmap is applied, and the block scheduling bitmap in this case can be 0x00000000 or 0x10000000.

[0387] Example 2

[0388] This embodiment is about improvement of bitmap size for bitmap-based block scheduling.

[0389] As the number of blocks increases, the size of the block scheduling bitmap of bitmap-based block scheduling (or Type 5 scheduling IE) increases. If the block index field is 2 octets in size, up to 65,536 blocks can be supported, and the maximum bitmap length may be 8,192 octets (= 65,536 bits). Examples of the present disclosure for reducing / improving such signaling overhead are described below.

[0390] First, the block scheduling bitmap length field is 2 bits in size and can be assumed to indicate the size of the block scheduling bitmap field as follows.

[0391] Block Scheduling Bitmap Length Field Value Size of the Block Scheduling Bitmap Field 08-bit bitmap 116-bit bitmap 232-bit bitmap 364-bit bitmap

[0392] To further reduce the size of the block scheduling bitmap length field, it can be defined as 1 bit in size, with a value of 0 indicating an 8-bit bitmap length and a value of 1 indicating a 16-bit bitmap length. Various other sizes and corresponding bitmap length candidates can also be defined. In this situation where the bitmap length candidates are limited, a bit called more blocks can be additionally defined to support scheduling for up to 65536 blocks. For example, a 1-bit more blocks field can be defined as shown in FIG. 24(f). The more blocks field can indicate whether the number of scheduled blocks is greater than the number of blocks specified in the block scheduling bitmap length.

[0393] A block scheduling bitmap may include a binary bitmap string. Each bit of the bitmap may be mapped to subsequent blocks, including the block in which the (Type 5) scheduling IE is transmitted. A bit value of 0 in the bitmap may mean that the corresponding block is not scheduled, and a bit value of 1 may mean that the corresponding block is scheduled. If the value of the more block field of a previously received (Type 5) scheduling IE is 1, the current block index in which the (Type 5) scheduling IE is transmitted becomes the base index, and each bit in the bitmap may be mapped by increasing by one from the base index.

[0394] A controllee receiving a (Type 5) scheduling IE can determine its duty cycle based on the information in the more block field and the block scheduling bitmap field. For example, it can be assumed that the total number of blocks to be scheduled is 67. In this case, if the value of the block scheduling bitmap length field is 3, a 64-bit bitmap can be applied according to Table 18. A controllee that first receives a (Type 5) scheduling IE with the more block field set to 1 can determine its duty cycle (i.e., be active only in scheduled blocks and sleep in unscheduled blocks) based on the block scheduling information indicated in the bitmap for blocks (e.g., block indexes 0 to 63) equal to the block scheduling bitmap length (i.e., 64). Even in the sleep state, the controllee can wake up after 64 block durations have elapsed and receive and decode a new (Type 5) scheduling IE through RCM. The value of the more block field included in the newly received (type 5) scheduling IE is 0, and the value of the block scheduling bitmap length is 0, which may mean an 8-bit bitmap according to Table 18. Accordingly, the controllable can obtain block scheduling information for the remaining 3 blocks (e.g., block indexes 64, 65, 66) among the total 67 blocks from the first 3 bits of the 8-bit bitmap. If the remaining blocks (e.g., 3 blocks) are less than the length of the block scheduling bitmap field (e.g., 8), the remaining bits (e.g., the remaining 5 bits excluding the first 3) may be ignored.

[0395] In case of hyper block-based mode, the hyper block duration can be known from the hyper block structure information such as HBS IE, so the controllee can determine the duty cycle accordingly. In case the upper level / unit structure of the block is not provided, such as block-based mode, if the value of the more block field is 0, the controllee can attempt to receive the scheduling IE (of type 5) included in the RCM of each block. In this case, since the controllee can obtain information on whether the controllee is scheduled for the corresponding block, the controllee can determine the duty cycle for the remaining sections other than the control phase within the block (for example, if scheduled for the corresponding block, it remains active, and if not scheduled for the corresponding block, it transitions to the sleep state).

[0396] Example 3

[0397] This embodiment provides examples using the extended bitmap-based scheduling IE.

[0398] FIG. 25 is a diagram illustrating an example of an operation using a bitmap-based block scheduling IE in a hyper block-based mode according to the present disclosure.

[0399] As in the example assumed in Embodiment 2, it is assumed that the total number of blocks to be scheduled is 67 and a 64-bit bitmap is applied. In the control message (e.g., RCM) of (1), controllee 1 and controllee 2 can receive a scheduling IE (of type 5) including a 64-bit bitmap and having the value of the more block field set to 1. The controllees can determine their duty cycles by applying scheduling information for 64 blocks corresponding to the bitmap length. Each controllee can operate in an active state in the block(s) corresponding to the bit set to 1 among the 64-bit bitmap, and can operate in a sleep state in the block(s) set to 0. After the time of the multi-block duration corresponding to block index 63 (which can be derived from information included in the HBS IE, etc.) has elapsed, the controllees can wake up and receive a scheduling IE (of type 5) containing an 8-bit bitmap in the control message (e.g., RCM) of (2) and having the value of the more block field set to 0. Accordingly, the controllees can obtain block scheduling information for the remaining three blocks (block indices 64, 65, 66). If the number of remaining blocks is smaller than the bitmap size, the remaining bits of the bitmap can be ignored. If in hyper block-based mode, the hyper block duration can be known from the structural information of the hyper block, such as the HBS IE, and the controllees can determine the duty cycle accordingly. For example, an 8-bit bitmap received at block index 64 of hyperblock K-1 may be applied as scheduling information for blocks 0, 1, 2, 3, and 4 of hyperblock K.

[0400] Although the example in FIG. 25 illustrates an example in which the same pattern of bitmap-based block scheduling is applied to hyperblock K-1 and hyperblock K, the scope of the present disclosure is not limited thereto, and different block scheduling may be applied to different hyperblock durations.

[0401] FIG. 26 is a diagram illustrating an example of an operation using a bitmap-based block scheduling IE in a block-based mode according to the present disclosure.

[0402] Let the total number of scheduled blocks be 8, and assume that the controllee receives a scheduling IE (e.g., of type 5) for bitmap-based block scheduling from the controller for every 8 blocks. In the control message (e.g., RCM) of (1), controllee 1 and controllee 2 can receive a scheduling IE (of type 5) in which the block scheduling bitmap length is set to 0 (i.e., the bitmap size is 8 bits) and the value of the more block field is 1. Accordingly, each controllee can determine its own duty cycle according to the 8-bit bitmap. Each controllee can operate in an active state in the block(s) corresponding to the bits set to 1 in the 8-bit bitmap, and operate in a sleep state in the block(s) set to 0. After the time corresponding to the multiple block durations corresponding to the block index 8 (which can be derived from the block duration information and the bitmap length (e.g., 8) included in the ARC IE, etc.), the controllees can wake up and receive a (Type 5) scheduling IE containing an 8-bit bitmap in the control message (e.g., RCM) of (2) and having the More Block field set to 0. In cases where the upper-level structure of blocks is not defined, such as block-based mode, the remaining bits can be ignored if the More Block field is 0 and the number of remaining blocks is smaller than the size of the Block Scheduling Bitmap field. Accordingly, the controllees can attempt to acquire the (Type 5) scheduling IE included in the RCM of each block. In this case, since the information on whether the block is scheduled can be acquired, the duty cycle can be determined for the remaining sections other than the control phase within the block.

[0403] In the case of scheduling other than the block bitmap method in the existing UWB wireless network system, the total number of block indices is not considered in scheduling, but in the block bitmap method scheduling, especially in the block bitmap-based scheduling method within the hyper block, since the block index starts from 0 for each hyper block, the bitmap needs to be configured by considering the total number of addressable blocks. According to the present disclosure, a scheduling IE format can be provided that reduces signaling overhead by defining bitmaps of various sizes that support up to 256 or 65536 blocks by extending the length of the bitmap that is conventionally supported only up to 64 bits.

[0404] The embodiments described above are combinations of components and features of the present disclosure in a predetermined form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented without being combined with other components or features. Furthermore, it is also possible to form embodiments of the present disclosure by combining some components and / or features. The order of operations described in the embodiments of the present disclosure may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is self-evident that claims that do not have an explicit citation relationship in the patent claims may be combined to form embodiments or incorporated as new claims through post-application amendments.

[0405] It will be apparent to those skilled in the art that the present disclosure may be embodied in other specific forms without departing from the essential characteristics of the present disclosure. Therefore, the above detailed description should not be construed as limiting in any respect, but rather as illustrative. The scope of the present disclosure should be determined by a reasonable interpretation of the appended claims, and all modifications within the scope of equivalents of the present disclosure are intended to be included within the scope of the present disclosure.

[0406] The scope of the present disclosure includes software or machine-executable instructions (e.g., an operating system, an application, firmware, a program, etc.) that cause operations according to the methods of various embodiments to be executed on a device or a computer, and a non-transitory computer-readable medium having such software or instructions stored thereon and executable on the device or computer. Instructions that can be used to program a processing system to perform the features described in the present disclosure can be stored on / in a storage medium or a computer-readable storage medium, and a computer program product including such a storage medium can be used to implement the features described in the present disclosure. The storage medium can include, but is not limited to, high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices, and can include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The memory optionally includes one or more storage devices remotely located from the processor(s). The memory or, alternatively, the non-volatile memory device(s) within the memory comprise a non-transitory computer-readable storage medium. The features described in this disclosure may be incorporated into software and / or firmware stored on any of the machine-readable media, which may control the hardware of the processing system and allow the processing system to interact with other mechanisms that utilize results according to embodiments of the present disclosure. Such software or firmware may include, but is not limited to, application code, device drivers, operating systems, and execution environments / containers.

[0407] The method proposed in this disclosure has been described with a focus on examples applied to IEEE 802.15.4-based systems, but can be applied to various UWB wireless networks or wireless communication systems in addition to IEEE 802.15.4-based systems.

Claims

1. A step of generating, by a first device, a scheduling information element (IE) including an extended bitmap length field and a bitmap field; and A step of transmitting a control message including the above scheduling IE to the second device by the first device, The length of the above bitmap field is based on the value of the above extended bitmap length field, A method wherein the extended bitmap length field includes a bitmap length field having a bit size greater than 2.

2. In paragraph 1, A method, wherein the extended bitmap length field includes a bitmap length field having a size of 3 bits.

3. In paragraph 1, The minimum value of the extended bitmap length field above corresponds to a bitmap of 8 bits in length.

4. In paragraph 1, The maximum value of the extended bitmap length field above corresponds to a bitmap of 256 bits in length.

5. In paragraph 1, The extended bitmap length field above has a value of one of eight candidate values, A method wherein the above bitmap field has a length of one of eight candidate lengths in the range of 8 to 256.

6. In paragraph 1, The above eight candidate values each correspond to the above eight candidate lengths, respectively.

7. In paragraph 6, The above eight candidate values are 0, 1, 2, 3, 4, 5, 6, and 7, The above eight candidate lengths are 8, 16, 32, 64, 96, 128, 192, and 256 bits.

8. In paragraph 6, A method wherein the above eight candidate values, 0, 1, 2, 3, 4, 5, 6, and 7, correspond (respectively) to the eight candidate lengths, 8, 16, 32, 64, 96, 128, 192, and 256, respectively.

9. In paragraph 1, A bit set to 1 in the bitmap of the above bitmap field indicates that the corresponding block is scheduled to the second device, A method wherein a bit set to 0 in the above bitmap indicates that the corresponding block is not scheduled to the second device.

10. In paragraph 9, A method wherein a power saving operation is performed by the second device in the above unscheduled block.

11. In paragraph 1, A method in which the value of the scheduling list type field of the above scheduling IE is set to a value indicating bitmap-based block scheduling or to 5.

12. In paragraph 1, The above scheduling IE is transmitted in the same ranging round as the HBS (hyper block structure) IE for block scheduling in hyper block mode.

13. In paragraph 1, A method wherein the size of the block index field of the ranging block description list of the above HBS IE is 1 octet.

14. In paragraph 1, A method in which each bit of the bitmap of the above bitmap field is applied to each block within one hyperblock.

15. In paragraph 1, The above first device corresponds to a controller, A method wherein the second device corresponds to a controlee.

16. In paragraph 1, A method, wherein the first device and the second device are enhanced ranging-capable devices (ERDEVs) operating in an ultra-wideband (UWB) wireless network system.

17. One or more transmitters / receivers; and comprising one or more processors coupled to said one or more transceivers; One or more of the above processors: Generating, by a first device, a scheduling information element (IE) including an extended bitmap length field and a bitmap field; and A control message including the above scheduling IE is set to be transmitted by the first device to the second device through the one or more transceivers, The length of the above bitmap field is based on the value of the above extended bitmap length field, A device wherein the extended bitmap length field includes a bitmap length field having a bit size greater than 2.

18. A step of receiving, by a second device from a first device, a control message including a scheduling information element (IE) including an extended bitmap length field and a bitmap field; and Including a step of performing signal transmission or reception by the second device in a block scheduled to the second device based on the bitmap of the bitmap field, The length of the above bitmap field is based on the value of the above extended bitmap length field, A method wherein the extended bitmap length field includes a bitmap length field having a bit size greater than 2.

19. One or more transmitters / receivers; and comprising one or more processors coupled to said one or more transceivers; One or more of the above processors: Receiving, by a second device from a first device, via one or more transceivers, a control message including a scheduling information element (IE) including an extended bitmap length field and a bitmap field; and In a block scheduled to the second device based on the bitmap of the bitmap field, signal transmission or reception is set to be performed by the second device through the one or more transceivers, The length of the above bitmap field is based on the value of the above extended bitmap length field, A device wherein the extended bitmap length field includes a bitmap length field having a bit size greater than 2.

20. One or more processors; and A processing device comprising one or more computer memories operatively connected to said one or more processors and storing instructions for performing a method according to any one of claims 1 to 17 based on execution by said one or more processors.

21. One or more non-transitory computer-readable media storing one or more instructions that are executed by one or more processors to control the performance of a method according to any one of claims 1 to 17.

Images