Method and apparatus for initializing ranging session in ultra-wideband wireless network system

Abstract

A method and an apparatus for initializing a ranging session in an ultra-wideband wireless network system are disclosed. A method according to an embodiment of the present disclosure may include the steps of: transmitting a first frame including a first variable-length field to a second device by a first device; and receiving a second frame responding to the first frame from the second device by the first device. On the basis of the first frame additionally including a second variable-length field, the first variable-length field may be located consecutively with the second variable-length field within the first frame. The first variable-length field may include a first length field and a first content field.

Description

Method and device for initializing a ranging session in an ultra-wideband wireless network system

[0001] The present disclosure relates to a method and device for initializing a ranging session 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 method and device for transmitting or receiving based on an efficient format of a public advertising poll frame in the initialization of a ranging session in a UWB wireless network system.

[0005] 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 can be clearly understood by a person having ordinary skill in the technical field to which the present disclosure belongs from the description below.

[0006] A method according to one aspect of the present disclosure may include: transmitting, by a first device, a first frame including a first variable-length field to a second device; and receiving, by the first device, a second frame from the second device in response to the first frame. Based on the first frame additionally including a second variable-length field, the first variable-length field may be positioned consecutively with the second variable-length field within the first frame. The first variable-length field may be composed of a first length field and a first content field.

[0007] A method according to an additional aspect of the present disclosure may include receiving, by a second device, a first frame from a first device, the first frame including a first variable-length field; and transmitting, by the second device, a second frame responsive to the first frame to the first device. Based on the first frame additionally including a second variable-length field, the first variable-length field may be positioned consecutively with the second variable-length field within the first frame. The first variable-length field may be composed of a first length field and a first content field.

[0008] According to the present disclosure, a method and device for transmitting or receiving based on an efficient format of a public advertising poll frame in a ranging session initialization in a UWB wireless network system can be provided.

[0009] 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.

[0010] 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.

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

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

[0013] FIG. 3 is a diagram showing the RMARKER position according to the STS packet setting in the HRP-ERDEV PPDU format to which the present disclosure can be applied.

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

[0015] 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.

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

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

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

[0019] 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.

[0020] 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.

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

[0022] 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.

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

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

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

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

[0027] 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.

[0028] 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.

[0029] FIG. 19 is a diagram showing an example of an MMS packet to which the present disclosure can be applied.

[0030] FIG. 20 is a diagram illustrating additional examples of MMS packets to which the present disclosure may be applied.

[0031] FIG. 21 is a diagram illustrating additional examples of MMS packets to which the present disclosure may be applied.

[0032] FIG. 22 illustrates examples of NBA-MMS-UWB ranging control phase, ranging phase, and measurement reporting phase to which the present disclosure can be applied.

[0033] FIG. 23 is a diagram illustrating ranging session initialization and setup to which the present disclosure can be applied.

[0034] FIG. 24 is a diagram showing an example of an AP transmission and reception operation to which the present disclosure can be applied.

[0035] FIG. 25 and FIG. 26 are diagrams showing examples of AP transmission and reception operations in multiple RANs to which the present disclosure can be applied.

[0036] FIG. 27 is a diagram showing examples of an advertising message format and a response message format according to the present disclosure.

[0037] FIG. 28 is a diagram showing examples of message exchanges between an initiator and a responder according to the present disclosure.

[0038] FIG. 29 illustrates an example of concurrent ranging session and exchange of channel usage coordination information between devices belonging to different RANs according to the present disclosure.

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

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

[0041] FIG. 32 illustrates an example of a private address-based advertising poll packet format according to the present disclosure.

[0042] FIG. 33 illustrates an example of a private address-based advertising response packet format according to the present disclosure.

[0043] FIG. 34 illustrates an example of a private address-based ranging start packet format according to the present disclosure.

[0044] FIG. 35 illustrates an example of a poll packet format for public advertising according to the present disclosure.

[0045] FIG. 36 illustrates an example of a response packet format for public advertising according to the present disclosure.

[0046] FIG. 37 illustrates an example of a ranging start packet format for public advertising according to the present disclosure.

[0047] FIG. 38 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0048] FIG. 39 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0049] FIG. 40 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0050] FIG. 41 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0051] FIG. 42 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0052] FIG. 43 illustrates a poll packet format for public advertising based on a security level according to the present disclosure.

[0053] FIG. 44 illustrates a poll packet format for public advertising based on a security mode according to the present disclosure.

[0054] FIG. 45 is a diagram showing an example of a method for distinguishing frames by ID in a ranging operation according to the present disclosure.

[0055] FIG. 46 is a diagram illustrating exemplary formats of a public-poll frame, a public-response frame, and a public-report frame according to the present disclosure.

[0056] FIG. 47 is a diagram showing an example of a method for distinguishing frames by address type in a ranging operation according to the present disclosure.

[0057] FIG. 48 is a diagram showing exemplary formats of a poll frame, a response frame, and a report frame according to the present disclosure.

[0058] Figure 49 is a drawing showing an example of a method for distinguishing frames by subtype according to the present disclosure.

[0059] FIG. 50 illustrates an example of finding a peripheral device based on secure advertising according to the present disclosure.

[0060] FIG. 51 illustrates an example of access control of multiple devices based on insecure advertising according to the present disclosure.

[0061] FIG. 52 illustrates an example of a purchasing process via an arbitrary device based on unsecured advertising according to the present disclosure.

[0062] Figure 53 shows examples of compact frame related formats to which the present disclosure can be applied.

[0063] FIG. 54 is a diagram showing examples of advertising data field formats according to the present disclosure.

[0064] FIG. 55 is a diagram illustrating other examples of advertising data field formats according to the present disclosure.

[0065] FIG. 56 is a diagram illustrating other examples of advertising data field formats according to the present disclosure.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.).

[0072] 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.

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

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

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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).

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] Ranging Measurement

[0089] 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).

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

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] In FIG. 2(g), modulation is applied to the SHR, PHR, and PHY payload fields, and the PPDU encoding procedure is terminated. A basic coding rate may be applied to the SHR field. The PHR field may have a format including data rate (2 bits), frame length (7 bits), ranging (1 bit), reserve (1 bit), preamble duration (2 bits), and SECDED (6 bits) for the base pulse repetition frequency (BRFP) mode, or may have a format including A1 (1 bit), A0 (1 bit), PHY payload length (10 bits), ranging (1 bit), and SECDED (6 bits) for the higher pulse repetition frequency (HPRF) mode. The A1 and A0 fields may also indicate the size of an additional gap between the payload and the STS. For the PHR field, in the BPRF mode, BPM-BPSK (burst position modulation-binary phase shift keying) with a coding rate of 850 kb / s or 6.8 Mb / s may be applied, in the HPRF mode, modulation with a coding rate of 3.9 Mb / s, 7.8 Mb / s, 15.6 Mb / s, or 31.2 Mb / s may be applied, and in other cases, BPM-BPSK with a coding rate of 850 kb / s or 110 kb / s may be applied. For the PHY payload field, in the HPRF mode, modulation with a coding rate of 6.8 Mb / s, 7.8 Mb / s, 27.2 Mb / s, or 31.2 Mb / s may be applied, and in other cases, BPM-BPSK with a coding rate indicated in the PHR may be applied.

[0098] FIG. 3 is a diagram showing the RMARKER position according to the STS packet setting in the HRP-ERDEV PPDU format to which the present disclosure can be applied.

[0099] 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.

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

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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. -20 is defined as and is approximately 0.9537 ps.

[0108] 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 a recipient can activate the ranging capability using the MLME-RX-ENABLE.request primitive.

[0109] Ranging and Localization Methods

[0110] The 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.

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

[0112] 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.

[0113] 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.

[0114]

[0115] 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:

[0116]

[0117] 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.

[0118] 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.

[0119] 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.

[0120]

[0121] 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.

[0122] 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 fixed nodes synchronized in a predetermined manner can be compared. Typically, the message transmitted by the mobile device can be 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 fixed synchronized nodes, the difference in the arrival times of the blinks in the first case, or the difference in the 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.

[0123] 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).

[0124] 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.

[0125] Setup procedure before ranging exchange

[0126] 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.

[0127] Finish-up procedure after ranging exchange

[0128] 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).

[0129] 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.

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

[0131] 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).

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

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

[0139] 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.

[0140] 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).

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

[0142] 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).

[0143] 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.

[0144] 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.

[0145] 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.

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

[0147] 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.

[0148] 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).

[0149] 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.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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.

[0154] Basic ranging exchange

[0155] 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.

[0156] 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.

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

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

[0159] 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.

[0160] 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).

[0161] 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.

[0162] Ranging Procedure

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

[0164] 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.

[0165] 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.

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

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

[0168] 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.

[0169] 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)).

[0170] 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.

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

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

[0173] 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.

[0174] 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.

[0175] 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.

[0176] 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.

[0177] 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.

[0178] 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.

[0179] 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.

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

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

[0182] 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.

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

[0184] 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.

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

[0186] 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).

[0187] 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.

[0188] 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.

[0189] 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.

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

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

[0192] 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.

[0193] 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.

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

[0195] 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.

[0196] 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.

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

[0198] 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.

[0199] 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.

[0200] 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.

[0201] 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.

[0202] 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.

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

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

[0205] 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.

[0206] 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.

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

[0208] 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.

[0209] 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)).

[0210] 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.

[0211] 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.

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

[0213] 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.

[0214] 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.

[0215] Multi-node ranging

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

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

[0218] 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.

[0219] 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).

[0220] 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.

[0221] 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.

[0222] 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.

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

[0224] 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.

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

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

[0227] 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

[0228] 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

[0229] 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)).

[0230] 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.

[0231] 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.

[0232] 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.

[0233] 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.

[0234] 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.

[0235] 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.

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

[0237] 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).

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

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

[0240] 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.

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

[0242] 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.

[0243] 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.

[0244] 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.

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

[0246] 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.

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

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

[0249] 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.

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

[0251] 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.

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

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

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

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

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

[0257] 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.

[0258] 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.

[0259] 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.

[0260] 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.

[0261] 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.

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

[0263] 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.

[0264] 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.

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

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

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

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

[0269] 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.

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

[0271] Ranging block and round structure

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

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

[0274] 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.

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

[0276] 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.

[0277] 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.

[0278] 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.

[0279] 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.

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

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

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

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

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

[0285] 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.

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

[0287] 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.

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

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

[0290] 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.

[0291] Below we will explain the ranging mode.

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

[0293] 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.

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

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

[0296] 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.

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

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

[0299] 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.

[0300] 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.

[0301] Below we will explain indexing.

[0302] 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.

[0303] 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.

[0304] 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.

[0305] 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.

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

[0307] 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.

[0308] 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.

[0309] One-to-many ranging procedure

[0310] 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.

[0311] 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.

[0312] 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.

[0313] 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.

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

[0315] 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.

[0316] 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.

[0317] 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.

[0318] 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).

[0319] 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.

[0320] 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.

[0321] 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.

[0322] 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.

[0323] 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.

[0324] narrowband assisted (NBA)-UWB

[0325] From a MAC perspective, NBA-UWB can be viewed as an umbrella feature encompassing several semi-independent features. All of these features share some common principles, the most important of which is tight clock synchronization between narrowband (NB) and UWB. The NB PHY and UWB PHY should be driven by the same clock, thus eliminating the need for additional work to determine their relative accuracy. If the NB PHY and UWB PHY do not share the same clock, explicit requirements for relative clock drift / accuracy between different PHYs / radios may be necessary. Based on the tight coupling between NB and UWB, the following features can be considered for UWB:

[0326] - Initialization Channel: The initialization channel may correspond to an NB channel used for UWB channel discovery. NB radio technology may be used as a pilot to provide additional CCA modes for UWB to the IEEE 802.15.4 family of standards. Meanwhile, the control channel is distinct from the initialization channel, and approximately 300 NB channels may be defined for the control channel.

[0327] - MMS (multi-millisecond) UWB (including secure MMS): In MMS-UWB, data exchange and acquisition of carrier frequency offset (CFO) / sampling frequency offset (SFO) can be offloaded to the NB PHY. This can enable improved ToF accuracy and improved link budget.

[0328] - NBA-TDOA: Link budget improvement and energy saving can also be applied to NBA-TDOA.

[0329] - NBA-sensing: NB can be applied to data exchange required for multi-static sensing.

[0330] There may be some common elements that can be reused across these features, while each feature may have unique requirements. Given that NBA-UWB systems may operate in dense multi-user scenarios, it is important to support coexistence / interference for both NB and UWB. Relevant NB radio requirements may include duty-cycle optimization, channelization, frequency hopping, blocked channel list agreement, and listen-before-talk (LBT) techniques. Ranging session definitions and PHY-level parameters also need to be specified. The MAC service provides an open interface to communicate schedules, initial timing, and frequency synchronization, and to convey configuration information acquired from secondary NBs to UWB operations. The MAC can be defined to provide a clear and generic baseline for various use cases. Since each application may have different requirements, it may be desirable to focus on common elements across specific applications rather than trying to find a one-size-fits-all solution.

[0331] The PHY may include additional and / or enhanced technologies to enable NBA-UWB-based features defined by the MAC. In particular, the IEEE 802.15.4 family of standards for offset-quadrature phase shift keying (O-QPSK), UWB, etc., may include some modifications and enhancements to the PHY aspects of NBA-UWB. Alternatively, PHYs different from O-QPSK may also support UWB by utilizing open interfaces provided by the MAC service.

[0332] O-QPSK can provide a very good baseline for the NB aspect of UWB, as it supports a good link budget and efficient implementation. The 250 kbps mode (or 250 kbps mode) can be applied as a key element in relatively optimized airtime. Exemplary improvements to O-QPSK include:

[0333] - In addition to the 2450MHz band defined in the existing IEEE 802.15.4 standard, new bands such as UNII (Unlicensed National Information Infrastructure)-3 and UNII-5 can be used.

[0334] Channelization for these bands could enable reduced airtime for frequency hopping and other services, thereby reducing preamble length and increasing data rates.

[0335] - Requirements for clock accuracy can be defined.

[0336] - Convolutional channel coding using a predefined generator polynomial is applied, and LDPC (low-density parity-check code) coding can also be optionally applied.

[0337] Regarding clock accuracy, additional NB modes can be aligned with UWB. The carrier frequency and chip rate frequency of HRP UWB should be derived from the same reference oscillator and should have an accuracy of +20 ppm to -20 ppm or better. A similar optional mode for O-QPSK can be defined to take advantage of the features of NBA-UWB.

[0338] As a PPDU format based on O-QPSK, PPDU configuration (config)-1, PPDU configuration-2, and PPDU configuration-3 can be applied. As described with reference to FIGS. 2 and 3, a PPDU can basically include a preamble, SFD, PHR, and payload. PPDU configuration-1 provides a baseline of a data rate of 250 kbps, and other PPDU configurations can be optionally defined for an optimized trade-off between air time and link budget. In addition, 1 chip has a duration of 0.5 us, and 1 symbol can carry 4 bits (for example, 4 bits can correspond to coded bits when FEC (forward error correction) is applied). Meanwhile, the number of chips in 1 symbol can be referred to as SF (spreading factor).

[0339] For example, for a PSDU payload of 10 bytes in size, the data rate and length of each field according to the PPDU setting are as follows.

[0340] - PPDU Setting-1: Data rate = 250kbps, Preamble length = 128us, SFD length = 32us, PHR length = 32us, Payload length = 320us, Total packet duration = 512us

[0341] - PPDU Setting-2: Data rate = 500kbps, Preamble length = 64us, SFD length = 32us, PHR length = 28us, Payload length = 172us, Total packet duration = 296us (Rate-1 / 2 convolution code is applied to both PHR and payload, PHR has 28(=(8+6)*2) coded bits, Payload has 172(=(80+6)*2) coded bits)

[0342] - PPDU Setting-3: Data rate = 1000kbps, Preamble length = 64us, SFD length = 32us, PHR length = 28us, Payload length = 80us, Total packet duration = 204us

[0343] Both out-of-band (OOB) signaling and in-band signaling can be used to indicate NB configuration. For OOB signaling, the SFD can have the format shown in the table below.

[0344] Bit: 0123456711100101

[0345] For in-band signaling, SFDs can be used to indicate different NB configurations as shown in the table below.

[0346] SFDNB setting #, data rate1 1 1 0 0 1 0 1#1, 250 kbps1 0 0 0 1 0 1 0#2, 500 kbps0 1 0 0 1 0 0 1#3, 1000 kbps0 0 1 0 1 0 1 1#4, 250 kbps1 0 1 0 0 0 0 1#5, 1000 kbps

[0347] The NBA-UWB PHY can serve as a starting point for the UWB PHY. For example, a non-data packet format has already been defined to improve link budget. MMS UWB may include extensions to non-data packets to further improve link budget and ToF contextualization. In this packet format, short fragments with a start-to-start spacing of at least milliseconds may exist, and the entire packet may span multiple fragments. One millisecond may correspond to 499,200 chips.

[0348] An MMS UWB packet may contain multiple fragments, which are divided into two types: ranging sequence fragment (RSF) and ranging integrity fragment (RIF).

[0349] First, let me explain RSF.

[0350] - Each RSF may contain repetitions of a selected MMS Ranging Sequence (MMRS). A single common MMRS may be used across all RSFs.

[0351] - 16 length-128 complementary sets-based MMRS sequences can be defined. Each of the elements of the sequence can be represented by + or -. Code indices 33, 34, ..., 48 can be assigned to each of the 16 MMRS sequences. Each MMRS sequence can be split into two parts [A, B]. A and B can each have length 64. A gap G consisting of 0 to 64 zero values ​​can be added to construct a gapped MMRS such as [A, G, B, G].

[0352] - As MMRS, ternary codes of length-91 and length-127 (e.g., codes defined in the IEEE 802.15.4z standard) may optionally be applied. The use of such ternary codes may cause more interference to surrounding legacy devices compared to the aforementioned length-128 MMRS.

[0353] - For MMRS with or without gaps before repetition within one RSF, a spreading factor L=4 can be applied.

[0354] Next, we will explain RIF.

[0355] - Each RIF can carry a waveform of pseudo-randomly modulated pulses to ensure ranging integrity. Existing STSs can be applied as a baseline for these waveforms.

[0356] - A RIF may contain one STS segment with spreading factor L=4. Each STS segment may have the same length.

[0357] - The polarity of all STS pulses in all RIFs within one MMS UWB packet can be generated using a deterministic random bit generator (DRBG) based on AES-128 in counter mode.

[0358] FIG. 19 is a diagram showing an example of an MMS packet to which the present disclosure can be applied.

[0359] The example in Fig. 19 illustrates an example of a generic MMS packet with or without NB assistance applied. The allowed settings for X, Y, and Z shown in Fig. 19 are described in detail below.

[0360] In each RSF, an MMRS symbol is first generated, and then the MMRS symbol can be repeated N_MSR times. One MMRS symbol can be generated as follows.

[0361] When MMRS is used based on the complementary set, in step-1, an MMRS without gaps, i.e., [A, B] (where A and B are each a sequence of length 64), is determined; in step-2, a gap G is determined to obtain an MMRS with gaps, i.e., S=[A, G, B, G]; and in step-3, by applying spreading using a spreading factor L=4, an MMRS symbol S'=[A', G', B', G'] can be obtained.

[0362] When using the Ipatov sequence for MMRS, the Ipatov sequence S is determined in step-1, and the MMRS symbol S' can be obtained by applying spreading using a spreading factor L=4 in step-2.

[0363] Within each RSF, the number of MMRS repetitions N_MSR can be set to one of the set {32, 40, 48, 64, 128, 256}. A small value of N_MSR can be advantageous for coexistence due to short active transmissions, while a large value of N_MSR can facilitate overall energy utilization without a high-performance PA (power amplifier). The value of N_MSR can be the same for all RSFs within an MMS packet.

[0364] FIG. 20 is a diagram illustrating additional examples of MMS packets to which the present disclosure may be applied.

[0365] The RSF-only MMS packet format of Fig. 20(a) can enable efficient and fast generation of channel impulse response (CIR) by utilizing MMS coherent combining. In the mixed MMS packet format for ranging integrity of Fig. 20(b), RIFs can follow RSFs.

[0366] For the RSF-only MMS packet of Fig. 20(a), the following numerology can be applied to increase processing gain.

[0367] The number of preamble fragments X can be set to one of the set {1, 2, 4, 8, 16}. RSF-RMARKER can be defined as the peak of the first pulse of the first RSF.

[0368] In the mixed MMS packet for ranging integrity of Fig. 20(b), if NB is used to assist timing / frequency synchronization, the following numerology may be applied.

[0369] Additional RIF-RMARKERs can be defined as the peak of the first pulse and the peak of the last pulse of each RSF. RIF-RMARKER y corresponds to the peak of the first pulse of RIF-y, and RIF-RMARKER y' corresponds to the peak of the last pulse of RIF-y. To increase the gain, the number of RFSs X can be set to one value from the set {0, 1, 2, 4, 8}, and the number of RIFs Y can be set to one value from the set {1, 2, 4, 8}. X=0 can imply a RIF-only MMS packet.

[0370] For example, a first mode with X = Y = 1, 2, 4, 8 and a second mode with X = 1 and Y = 2, 4, 8 can be defined as baselines. Additionally, other combinations of X and Y values ​​can be optionally applied.

[0371] For Z=2, an additional 1ms gap between RSFs and RIFs can provide additional time budget before starting to process fragments for integrity verification.

[0372] FIG. 21 is a diagram illustrating additional examples of MMS packets to which the present disclosure may be applied.

[0373] Fig. 21(a) shows an example of a UWB-only mixed MMS packet containing RSFs when X>0, and Fig. 21(b) shows an example of a UWB-only mixed MMS packet containing only RIFs when X=0 and Y>0.

[0374] If NB is not used to report timing / frequency synchronization, the following numerology may be applied to mixed MMS packets for ranging integrity.

[0375] As in the examples in Fig. 21, SYNC and SFD can be included in an MMS packet.

[0376] Additional RIF-RMARKERs can be defined as the peak of the first pulse and the peak of the last pulse in each RIF.

[0377] X is set to one of the set {0, 1, 2, 4, 8} and Y can be set to one of the set {0. 1, 2, 4, 8}. Here, Y=0 can be allowed if ranging integrity is not provided. X=0 and Y=1 can be defined as default settings to facilitate interoperability. For X>0, an additional 1ms gap between RSFs and RIFs when Z=2 can provide additional time budget before starting to process fragments for integrity verification.

[0378] Further improvements for better interference detection and ranging performance for NBA-UWB techniques and techniques that utilize only UWB wireless technology to achieve improved link budget compared to existing MMS ranging can be applied.

[0379] NBA-UWB Ranging

[0380] First, we describe the NBA-MMS-UWB ranging measurement cycle.

[0381] In NBA-MMS-UWB ranging, the ERDEV role can be referred to as either an initiator or a responder. For example, during an NBA-MMS-UWB ranging cycle, the initiator may act as a controller, and the responder may act as a controlee. However, this does not exclude the case where the initiator is a controlee and the responder is a controller.

[0382] In NBA-MMS-UWB ranging, the ranging block and ranging round structures described in FIGS. 13 and 15 can be applied, and a block-based mode can be applied. The ranging block structure for NBA-MMS-UWB can be set up by specifying a ranging block duration, a ranging round duration, and a ranging slot duration.

[0383] The time unit for specifying the duration of a ranging block and ranging round is RSTU. Ranging devices can implement a ranging block structure such that the tolerance of the ranging block duration with respect to the PHY clock is within +100 ppm to -100 ppm. A ranging round corresponds to a period of duration sufficient to complete one complete ranging measurement cycle. The initiator and responder may use one or more ranging rounds starting from the first ranging block of a ranging session, and may repeat the same ranging round usage pattern in subsequent ranging blocks. Round hopping may be applied in an NBA-MMS-UWB ranging session, and a transmit offset may not be applied.

[0384] As an extension of the existing slot-based ranging mode, multiple consecutive MMS ranging slots can be allocated for a single packet transmission. The ranging slot duration, ranging round duration, and ranging block duration can be selected as integer multiples of 300 RSTU (i.e., 250 us).

[0385] A ranging measurement cycle can be uniquely identified by a ranging block index and a ranging round index. In NBA-MMS-UWB ranging, a ranging measurement cycle can include a ranging control phase, a ranging phase, and a measurement reporting phase (in-band / OOB).

[0386] Among the ranging control phase, ranging phase, and measurement report phase included in the ranging round of FIG. 13(b), the ranging control phase and the ranging phase are essential for the NBA-MMS-UWB ranging measurement cycle. The measurement report phase may be optionally supported via in-band wireless technology (e.g., NB, UWB) or via out-of-band (OOB). When provided in-band, the ranging round length may be set to include the ranging control phase, ranging phase, and measurement report phase. When provided OOB, the ranging round length may be set to include the ranging control phase and the ranging phase.

[0387] Describes the control and reporting messages used in the NBA-MMS-UWB ranging measurement cycle.

[0388] - A poll message is an NB message transmitted by the initiator in the first slot of a ranging round to initiate a ranging measurement cycle within the ranging round.

[0389] - A response (RESP) message is an NB message transmitted by the responder at the start of a subsequent ranging slot after the first ranging slot in response to a received poll message.

[0390] - The Report (RPRT) message is an NB message sent by either the initiator or the responder to report ranging measurements to the peer.

[0391] As a default for transmitting control and reporting messages, NB O-QPSK 250kbps PHY may be applied. Other NB and UWB PHYs may be optionally supported.

[0392] FIG. 22 illustrates examples of NBA-MMS-UWB ranging control phase, ranging phase, and measurement reporting phase to which the present disclosure can be applied.

[0393] Figure 22(a) shows an example of an NBA-MMS-UWB ranging control phase.

[0394] The NBA-MMS-UWB ranging control phase is performed at the beginning of an NBA-MMS-UWB ranging measurement cycle and may include two or more ranging control slots.

[0395] An initiator may initiate an NBA-MMS-UWB ranging control phase by transmitting a poll message to a responder at the beginning of the first ranging slot of a ranging round. If LBT is not enabled, or if not, depending on NBA LBT, the initiator may extend the transmission of the poll for up to the duration of RcpPollSlot. A responder that successfully receives the poll message may transmit a response message to the initiator in a ranging slot following RcpPollSlot from the beginning of the ranging control phase. If LBT is not enabled, or if not, depending on NBA LBT, the responder may extend the transmission of the response for up to the duration of RcpResponseSlot. A responder that successfully transmits a response message may continue the NBA-MMS-UWB ranging measurement cycle and enter the ranging phase. An initiator that successfully receives a response message may also continue the NBA-MMS-UWB ranging measurement cycle and enter the ranging phase.

[0396] A poll message can provide carrier frequency coherence from the initiator to the responder device. Additionally, control information can be transmitted from the initiator to the responder via the poll message. For example, the poll message can include information requesting the responder to report the recommended number of fragments (RNF) during the measurement reporting phase.

[0397] The response message may provide carrier frequency coherence from the responder to the initiator device. Additionally, control information may be transmitted from the responder to the initiator via the response message.

[0398] If LBT is enabled prior to transmission in the corresponding operating band, the transmitting device may perform LBT prior to the start of the expected transmission. If the performed LBT does not permit transmission at the start of the ranging slot, the transmitting device may not initiate further transmissions for the remainder of the ranging round.

[0399] The initiator may discontinue an NBA-MMS-UWB ranging measurement cycle if one or more of the following conditions are met:

[0400] - If LBT does not allow transmission of poll messages;

[0401] - if the initiator does not receive a response message in the expected ranging slot; or

[0402] - If all ERDEVs request to skip ranging for the current ranging block during the ranging control phase.

[0403] A responder may abort an NBA-MMS-UWB ranging measurement cycle if one or more of the following conditions are met:

[0404] - If a poll message is not received at the start of an expected ranging round;

[0405] - if LBT does not permit transmission of a response message; or

[0406] - If all ERDEVs request to skip ranging for the current ranging block during the ranging control phase.

[0407] If a ranging measurement cycle is terminated before completion, the participating ERDEVs may stop NB and UWB transmissions until the next ranging measurement cycle.

[0408] Figure 22(b) shows an example of an NBA-MMS-UWB ranging phase.

[0409] The NBA-MMS-UWB ranging phase can start when the NBA-MMS-UWB ranging control phase ends.

[0410] The initiator may enter the ranging phase and start transmitting the first UWB RSF fragment after RpInitiatorRsfOffset slots. The initiator may continue to transmit up to X UWB RSF fragments at regular intervals of 1200 RSTU. The initiator may enter the ranging phase and start transmitting the first UWB RIF fragment after RpInitiatorRifOffset slots. The initiator may continue to transmit up to Y UWB RSF fragments at regular intervals of 1200 RSTU.

[0411] The initiator may enter the ranging phase and start transmitting the first UWB RSF fragment after RpResponderRsfOffset slots. The initiator may continue to transmit up to X UWB RSF fragments at regular intervals of 1200 RSTU. The initiator may enter the ranging phase and start transmitting the first UWB RIF fragment after RpResponderRifOffset slots. The initiator may continue to transmit up to Y UWB RSF fragments at regular intervals of 1200 RSTU.

[0412] The total duration of the ranging phase can correspond to RpDuration slots.

[0413] After an ERDEV, either an initiator or a responder, has completed receiving all UWB fragments during the ranging phase, it may generate a ranging measurement report if required to transmit the measurement report to its peer. Accordingly, the value of RpDuration may be set to allow sufficient time until the subsequent measurement report phase.

[0414] When the in-band NBA-MMS-UWB measurement reporting phase is enabled for a ranging measurement cycle, an ERDEV that has completed the ranging phase can enter the measurement reporting phase based on the following conditions:

[0415] - If a measurement report is required to be sent to the other party during the measurement report phase and the measurement report is successfully generated; or

[0416] - If you expect to receive a measurement report from the other party during the measurement report phase.

[0417] If the NBA-MMS-UWB measurement report phase is not included in the NBA-MMS-UWB ranging measurement cycle, the participating ERDEVs may end the ranging measurement cycle after completing the ranging phase. An ERDEV required to transmit a measurement report to the other party may forward the measurement report to the next higher layer, or request that the next higher layer transmit the measurement report to the other party.

[0418] Figure 22(c) shows an example of an NBA-MMS-UWB measurement reporting phase.

[0419] In-band measurement reports may be transmitted during the optional measurement reporting phase. If enabled, the in-band measurement reporting phase may begin at the same time as the ranging phase.

[0420] In the following description, the in-band measurement reporting phase may be referred to as the reporting phase.

[0421] A reporting phase may include one or more packet slots. The duration of the first slot of the reporting phase may be MrpFirstSlot slots. The duration of the second slot of the reporting phase may be MrpSecondSlot slots.

[0422] If the reporting phase contains only one packet slot, either the initiator or the responder can transmit a measurement report packet in that slot. Whether the device transmitting the report packet is the initiator or the responder can be determined by the reporting mode.

[0423] If the reporting phase includes two packet slots, the responder may send the reporting packet in the first slot and the initiator may send the reporting packet in the second slot.

[0424] The measurement reporting phase may include unidirectional or bidirectional report exchanges. Transmission of report packets may be scheduled in the first two ranging slots of the measurement reporting phase, depending on the configuration mode below:

[0425] Report Mode Device transmitting in the first report slot Device transmitting in the second report slot One-way, responder only Responder-one-way, initiator only Initiator-two-way, initiator first Responder-initiator

[0426] For bidirectional reporting, the transmission of reports can be performed independently in the first and second slots of the measurement reporting phase. In particular, the responder can transmit its measurement report in the second slot, regardless of whether it received the initiator's report in the first slot.

[0427] Report messages can primarily provide ranging measurement results obtained during the ranging phase. Report messages can also be used for other purposes. For example, if the responder receives a recommended number of fragments (RNF) request from the initiator during the control phase, the report message sent by the responder can include the RNF report. The initiator can use the RNF to determine the updated number of fragments to be used in subsequent rounds.

[0428] If ERDEV fails to transmit a measurement report during its allocated slot in the measurement report phase, it may defer or retry using higher layers or using out-of-band (OOB) radio technology operations. If ERDEV fails to receive a measurement report during its allocated slot in the measurement report phase, it may request retransmission using higher layers or using OOB radio technology operations until the start of the next MMS ranging cycle in the subsequent ranging block.

[0429] NBA-MMS-UWB Initialization and Setup

[0430] An NBA-MMS-UWB ranging session can be established by a set of parameters for PHY and MAC. The set of PHY parameters can include NB and UWB channels, modulation, and data rates used in the control phase, ranging phase, and measurement reporting phase. The set of MAC parameters can include slot, round, and block configurations for the control phase, ranging phase, and measurement reporting phase.

[0431] To initiate an NBA-MMS-UWB ranging session, a pair of initiator devices and responder devices may engage in negotiation of ranging settings different from the default parameter set during the initialization and setup phase. Out-of-band (OOB) communication may be used to set up session parameters or change the initialization channel and modulation, and this may also be performed prior to the initialization and setup phase.

[0432] FIG. 23 is a diagram illustrating ranging session initialization and setup to which the present disclosure can be applied.

[0433] Let's first explain the ranging session initialization.

[0434] Before entering the ranging control phase, ERDEVs may participate in the initialization and setup phase. The initialization and setup phase may provide time synchronization for the first poll packet to be transmitted by the initiator during the upcoming ranging control phase. Furthermore, ranging session configuration may be modified by exchanging two-way handshake packets between ERDEVs. Unless otherwise agreed upon during the initialization and setup phase, default ranging configuration parameters may be used for the ranging session. Alternatively, ranging session configuration may be established by the out-of-band (OOB) radio technology.

[0435] To establish in-band initialization, ERDEVs may opportunistically transmit and receive on a dedicated initialization channel and PHY modulation as determined by the ranging session setup. The initiator may opportunistically transmit advertising poll (ADV-POLL) packets at times and intervals it deems appropriate, as supported by higher-layer functionality. Similarly, the responder may opportunistically listen for incoming ADV-POLL packets.

[0436] After transmitting an ADV-POLL on the initialization channel, the initiator may attempt to receive an incoming advertising response packet (ADV-RESP) in the subsequent ranging slot. If the responder receives the ADV-POLL, it may transmit an ADV-RESP in the subsequent ranging slot. If the responder transmits an ADV-RESP, it may attempt to receive a start of ranging (SOR) packet in the ranging slot following the ADV-RESP packet. If the initiator receives an ADV-RESP packet, it may transmit a SOR packet in the ranging slot following the ADV-RESP packet.

[0437] After transmitting the SOR packet, the initiator may enter the ranging control phase. During the ranging control phase, after the initiator confirms receipt of the RESP from the responder, and unless additional ERDEV initialization is required, the initiator may abort ranging initialization and stop transmitting ADV-POLL packets.

[0438] For the initial setup handshake, the responder (or controlee) can request ranging session setup via ADV-RESP. The initiator (or control) can receive the request from the responder via ADV-RESP, set up the session setup, and send the session setup to the responder via SOR.

[0439] For ranging session setup, a ranging block structure and a ranging measurement cycle can be set before an NBA-MMS-UWB ranging session starts. The ranging parameters may not be changed during ranging setup, or default parameters may be applied to the ranging session setup by the next higher layer. During an NBA-MMS-UWB ranging session, some parameters for the ranging block structure and the ranging measurement cycle may be updated by the next higher layer. For each parameter update, the next higher layer may indicate the index of the ranging block where the new parameters become valid.

[0440] Initiators and responders may use parameters set or updated by their respective next higher layers as long-term operating parameters.

[0441] The initiator may overwrite the long-term operating parameters of a ranging measurement cycle by specifying a new set of short-term parameters during the ranging control phase. The short-term parameters are valid only for the immediate ranging measurement cycle. The long-term operating parameters may resume to be valid in the next ranging measurement cycle unless they are overwritten again during the ranging control phase.

[0442] During the ranging control phase, the responder may request short-term operating parameters for the next ranging measurement. The initiator may provide or ignore the parameters at the responder's request in the next ranging cycle.

[0443] General parameters for an NBA-MMS-UWB ranging session may include default values ​​and configurable value ranges or options for initialization channel, allowed list of control and reporting channels, UWB control channel and preamble, PHY rate, NB LBT channel, whether round hopping is applied, channel switching method, etc. Block structure parameters may include default values ​​and configurable value ranges or options for ranging block duration, ranging round duration, ranging slot duration, etc. Ranging measurement cycle parameters include RcpPollSlot, RcpResponseSlot for ranging control phase; Number of RSF fragments (X) for ranging phase, number of RIF fragments (Y), RpDuration, RpInitiatorRsfOffset, RpResponderRsfOffset, RpInitiatorRifOffset, RpResponderRifOffset, RSF code index, RSF complement set, RIF fragment length in 512-chip units, N_MSR; may include default values ​​and ranges of configurable values ​​or options for in-band reporting, reporting mode, MrpFirstSlot, MrpSecondSlot, etc. for measurement reporting.

[0444] NBA-MMS-UWB Control Channel Message

[0445] Existing PSDU formats defined for each of the various PHYs can be applied to NBA-MMS-UWB control channel messages. When NB is used for control messages, report messages, and initialization messages, a compressed PSDU format can be used.

[0446] The compressed PSDU format can be defined as containing only a 1-octet header containing a message ID. All remaining PSDU contents can be determined according to the message ID. Examples of compressed PSDU formats for messages used during the initialization phase, setup phase, control phase, and reporting phase are shown in the table below. A compressed PSDU message can be encapsulated in a header IE of a data field of a specific type.

[0447] PhaseMessageOctet 0 (Message ID)Octet 1-NControlPOLL0x00[...,CRC16]ControlRESP0x01[...,CRC16]ControlPOLL2Unspecified[...,NbaChannelMap, CRC16]MeasurementReportRPRT (from Responder)0x02[...,CRC16]MeasurementReportRPRT (from Initiator)0x03[...,CRC16]MeasurementReportRPRT2Unspecified[...,NbaChannelMap, CRC16]InitializeADV-POLL0x20[...,CRC16]InitializeADV-RESP0x21[...,CRC16]InitializeSOR0x22[...,CRC16]

[0448] Among the messages in the control phase, the POLL message may correspond to a poll message for qualification, and the RESP message may correspond to a response message for qualification. The POLL2 message requires that, after receiving the NbaChannelMap from the initiator, the responder be able to determine the NbaChannelAllowList and apply the list to allocate NB channels for each ranging. Various other poll messages may also be defined.

[0449] Among the messages in the measurement reporting phase, the RPRT message from the responder and the RPRT message from the initiator are defined to have distinct message IDs, and the RPRT2 message may be a message used in the session control process. The values ​​0x04 to 0x1f of the message ID may be reserved for the session control and reporting phases.

[0450] Among the messages in the initialization phase, values ​​0x23 to 0x2f of the message ID may be reserved for out-of-session use.

[0451] Other message ID values ​​0x7f to 0xff are defined for vendor specific message content and may correspond to a 128x256 PSDU with a 2-byte message ID.

[0452] Among the compressed PSDU message fields, the CRC16 field is defined as 16 bits long and may correspond to a 2-octet long frame check sequence (FCS). The ADDR field may correspond to an address field. The compressed PSDU message may also include various other fields.

[0453] Adjust UWB channel usage

[0454] To reduce mutual interference between adjacent UWB transmitters and support good coexistence, coordination of UWB channel (CH) usage can be applied. The types of UWB transceivers can include NBA-UWB transceivers and UWB standalone transceivers. For example, coordination of UWB channel usage between NBA UWB transceivers can be performed through a mirroring (or initialization) channel. Below, a UWB channel usage coordination method applicable to both NBA UWB transceivers and standalone UWB transceivers is described.

[0455] Unless otherwise stated in the following description, a UWB transceiver refers to an NBA UWB transceiver, a standalone UWB transceiver, or both types. Signaling for coordinating UWB channel usage may be required to be decoupled from other UWB sessions on the UWB transceiver. Such UWB channel usage coordinating may be mandatory or optional in the UWB transceiver. For example, transmitting coordinating signaling may be mandatory / optional, and acting on information received via coordinating signaling may also be mandatory / optional.

[0456] FIG. 24 is a diagram showing an example of an AP transmission and reception operation to which the present disclosure can be applied.

[0457] As shown in the example of Fig. 24(a), an initiator, which is a UWB transceiver, can periodically transmit an acquisition packet (UWB-AP) on a predefined UWB discovery channel. The UWB-AP can contain information that can be used to determine all future UWB channel usage of the initiator. The UWB transceiver can discover the initiator by receiving the UWB-AP. The UWB-AP interval can be set to an appropriate value (e.g., depending on the use case). Among the periodically transmitting UWB-APs, some UWB-APs may be skipped due to ranging overlap. In the example of Fig. 24(a), n, n+1, n+2, ... may correspond to NBA-UWB ranging block indices.

[0458] As shown in the example of Fig. 24(b), UWB-AP scanning of a UWB receiver (Rx) for an NBA UWB transceiver can be optimized. An NBA UWB initiator can periodically transmit NB-APs on a predefined NB discovery channel. The NB-AP can contain information that can be used to determine the occurrence of the next UWB-AP. The NB-AP can contain information that can be used to determine all future UWB channel usage of the initiator. The NB-AP interval can be associated with the UWB-AP interval. For example, the NB-AP interval can be the same as the UWB-AP interval, and the time interval between the NB-AP transmission time and the UWB-AP transmission time can be dT1. Among the periodically transmitting NB-APs, some NB-APs may be skipped due to overlapping ranging.

[0459] FIG. 25 and FIG. 26 are diagrams showing examples of AP transmission and reception operations in multiple RANs to which the present disclosure can be applied.

[0460] In the examples of FIGS. 25 and 26, RAN (ranging area network) 1 is assumed to include one initiator (RAN1 initiator) and one or more responders (RAN1 responders) and is currently in ranging operation. RAN2 is assumed to include one initiator (RAN2 initiator) and one or more responders (RAN2 responders) and is assumed to be start-up or in operation.

[0461] In the example of FIG. 25, the RAN1 initiator can periodically transmit NB-AP and UWB-AP on the NB discovery channel and UWB discovery channel. Accordingly, the RAN1 responder can be activated and perform ranging operations in the first ranging round of each ranging block on the UWB channel determined based on the information contained in the NB-AP and UWB-AP.

[0462] The RAN2 initiator can receive the NB-AP and UWB-AP transmitted by the RAN1 initiator. For example, the RAN2 initiator can receive the NB-AP transmitted by the RAN1 initiator during the NB ScanWin, and subsequently receive the UWB-AP transmitted by the RAN1 initiator during the UWB ScanWin. Accordingly, the RAN2 initiator can obtain / extract RAN1 information (e.g., information per UWB session). For example, the RAN1 information can include information about ranging blocks, rounds, slot durations, information about RF channel and preamble usage, information about synchronization parameters, etc. Based on this RAN1 information, the RAN2 initiator can start its ranging session and advertising session at a time point that does not overlap with that of RAN1. Accordingly, the RAN2 initiator can periodically transmit the NB-AP and UWB-AP.

[0463] In the example of Figure 26, the RAN1 initiator can periodically transmit NB-APs on NB discovery. Accordingly, the RAN1 responder can be activated and perform ranging operations in the first ranging round of each ranging block on a UWB channel determined based on information contained in the NB-AP.

[0464] The RAN2 initiator can receive the NB-AP transmitted by the RAN1 initiator. For example, the RAN2 initiator can receive the NB-AP transmitted by the RAN1 initiator during the NB scanning window (NB ScanWin). Accordingly, the RAN2 initiator can obtain / extract RAN1 information (e.g., information on the active section of the RAN). For example, the information on the active section of RAN1 can include information on the remaining time until the start of the active section (or active round) (e.g., dT2), information on the duration of the active round, etc. Based on this RAN1 information, the RAN2 initiator can select an idle section that does not overlap with the active section of RAN1 to start its new session. Accordingly, the RAN2 initiator can periodically transmit the NB-AP.

[0465] The NB-AP format and UWB-AP format are described below.

[0466] Both the NB-AP format and the UWB-AP format may include an SHR field, a PHR field, and a PHY payload field (i.e., PSDU) as described with reference to FIG. 2. The PHR field may indicate the length of the PSDU, for example, within a range of 0 to 127 bytes. The PSDU may include an MHR (MAC header) field, a MAC payload field, and an MFR (MAC footer) field. The NB-AP packet type may apply O-QPSK, and the UWB-AP packet type may apply BPRF.

[0467] An NB-AP may have a compact frame format corresponding to a compressed PSDU. A compact frame may include a 3-bit frame type field, a 5-bit compact frame ID field, and a variable-sized compact frame content field. A compact frame (or acquisition compact frame) format for an AP may include a 3-octet address field, a 1-octet message control field, a variable-sized message content field, and a 2-octet FCS field.

[0468] The MHR field of an AP can contain the following information:

[0469] MHR BitByte Value (Example) DescriptionFrame controlFrame type321DataSecurity enabled10Security disabledFrame pending10No additional frames to be transmittedAR10ACK frame not requiredPAN ID compression11Frame version specific address / PAN ID (personal area network identifier) ​​presenceRFU10ReservedSequence number suppression11Sequence number compression appliedIE Present10IE not presentDestination addressing mode23EUI-64 (64-bit extended unique identifier) ​​addressFrame version22802.15.4-2020Source addressing mode23EUI-64 addressDestination address648FF FF FF FF FF FF FF FF FFBroadcast addressSource address648Variable local MAC address

[0470] The MAC payload field of a UWB-AP may contain the following information:

[0471] MAC Payload Bits Bytes Description Common Info field AP type 3 10: Coordination UWB-AP 1-8: Reserved RFU 5 Reserved Per-session Info field Block duration 2 43 RSTU units Session channel 5 1 UWB channel used by the session Hop mode 1 0: No hopping 1: Hopping (the hopping sequence does not need to be known to all devices) RFU 2 Reserved Preamble code 8 1 Preamble code used by the session

[0472] The per-session info field can exist in a single coordinated UWB-AP. The initiator of a new RAN can minimize conflicts with existing RANs by selecting different values ​​for one or more parameters in the per-session info field.

[0473] The MAC payload field of the NB-AP may contain the following information:

[0474] MAC Payload Bits Bytes Description Common Info field AP type 3 10: Coordination NB-AP 1: Compressed coordination NB-AP 2-8: Reserved UWB-AP present 10: No UWB-AP following NB-AP 1: UWB-AP following NB-AP RFU 4 Reserved UWB-AP Info field Delta T 163 Remaining time (in RSTU units) from the start of the current packet until the start of the next UWB-AP UWB channel 5 1 UWB channel number on which the UWB-AP occurring after Delta T (dT1) is transmitted RFU 3 Reserved Preamble code 8 1 Preamble code used by the UWB-AP

[0475] Compressed coordinated NB-AP packets do not include per-session information fields. Coordinated NB-APs may include per-session information field(s). The per-session information field(s) may overlap with those of coordinated UWB-APs. The UWB-AP information field is included in the NB-AP if the value of the UWB-AP presence field is 1, and is not included in the NB-AP if the value is 0.

[0476] Referring back to Figure 25, the time length (dT1) from the start of the NB-AP to the start of the UWB-AP can be indicated by the value of the Delta T parameter of the UWB-AP information field of the NB-AP. Additionally, on which UWB channel the UWB-AP transmits after the time dT1 can be indicated by the value of the UWB channel parameter of the UWB-AP information field.

[0477] An NB-AP may or may not include a UWB session information field. Whether an NB-AP includes a UWB session information field and what information is included in the UWB session information field can be indicated by the UWB per session info type field of the NB-AP. The UWB session information field can be present in the NB-AP regardless of whether the UWB-AP transmits. Four types can be applied to the UWB session information field.

[0478] If the value of the UWB Session-Per-Information Type field is 0, the UWB session information field does not exist in the NB-AP.

[0479] If the value of the UWB Session-Per-Information Type field is 1, the NB-AP has a UWB session information field and may contain the following minimum set of session information.

[0480] MAC Payload Bits Bytes Description Per-session Info field Block duration 2 4 3 RSTU units Session channel 5 1 UWB channel used by the session Hop mode 1 0: No hopping 1: Hopping (the hopping sequence does not need to be known to all devices) RFU 2 Reserved Preamble code 8 1 Preamble code used by the session

[0481] If the value of the UWB Session-Per-Information Type field is 2, the NB-AP has a UWB session information field and may include information about the start time and duration of the active period.

[0482] MAC Payload Bits Bytes Description Per-session Info field Delta T 2 4 3 Time remaining until the start of the active period (in RSTU units) UWB channel 5 1 UWB channel number used by the UWB session RFU 3 Reserved Preamble code 8 1 Preamble code used by the UWB session Active period duration 2 4 3 Duration of the active period of the UWB session

[0483] Referring back to Figure 25, the time length (dT2) from the start of the NB-AP to the start of the active interval can be indicated by the value of the Delta T parameter in the per-session information field of the NB-AP. The duration from the start to the end of the active interval can be indicated by the value of the active interval duration field in the per-session information field of the NB-AP.

[0484] If the value of the UWB Session-Per-Information Type field is 3, the NB-AP has a UWB Session Information field and may contain information about the start time and duration for active rounds in the block.

[0485] MAC Payload Bits Bytes Description Per-session Info field Delta T 2 43 Time remaining until the start of the block (in RSTUs) UWB channel 5 1 UWB channel number used by the session Hop mode 1 0: No hopping 1: Hopping (the hopping sequence does not need to be known to all devices) RFU 2 Reserved Preamble code 8 1 Preamble code used by the session Round duration 2 48 Round duration of a block of the UWB session Number of rounds in a block 8 1 Number of rounds in a block Active rounds 2 43 Bitmap indicating the index of the active round

[0486] Referring back to FIG. 25, the length of time (dT2) from the start of the NB-AP to the start of the block can be indicated by the value of the Delta T parameter of the per-session information field of the NB-AP. In addition, the position of the active round and the duration of the round are indicated by the index of the active round in a bitmap of the length according to the number of rounds included in one block (Number of rounds in a block parameter), and after the duration (Round duration parameter) equal to the number of inactive rounds (0 in the example of FIG. 25) between the start of the block and the start of the active round has elapsed, the active round can be started.

[0487] Initialize setup and adjust channel usage

[0488] As mentioned above, NBA-UWB can provide technologies such as mirroring (or initialization) channel, NBA-MMS-UWB, NBA TDoA, NBA-sensing, etc. NBA-UWB can support UWB operation by using NB (e.g., 2.5MHz bandwidth) channel in bands such as UNII-3 and UNII-5. Specific features for NB can correspond to in-band technologies defined by the IEEE 802.15.4 family of standards.

[0489] As previously mentioned for NBA-MMS-UWB, NB channels can be used to improve the link budget of UWB. In an NBA-MMS-UWB ranging round, the in-band measurement reporting phase (MRP) can be defined as an optional configuration, and accordingly, the ranging round can include a ranging control phase (RCP) and a ranging phase (RP) as mandatory components. In addition, the frames / packets and durations exchanged between devices in the RCP, RP, and MRP are as described with reference to FIG. 22.

[0490] As described above with reference to FIG. 23 for NBA-MMS-UWB initialization and setup, time synchronization information may be provided in the first poll packet transmitted by the initiator in the RCP. Furthermore, to initiate an NBA-MMS-UWB ranging session, the initiator and responder are required to perform a discovery (or initialization) and setup process to negotiate ranging settings other than the default parameter set.

[0491] For UWB native discovery (or initialization) and setup process, the initiator may periodically broadcast ADV-POLL packets on the discovery (or initialization) channel as described above. The discovery (or initialization) channel on which ADV-POLL is broadcast may be an NB channel for devices with NBA-UWB capability, and may be a UWB channel for devices that do not support NBA-UWB.

[0492] Additionally, in the UWB channel usage adjustment described with reference to FIGS. 24 to 26, similar to the NBA-MMS-UWB discovery (or initialization) and setup process, an AP (acquisition packet) containing network scheduling information may be periodically broadcast on the discovery (or initialization) channel.

[0493] As described in the examples of FIGS. 24 and 25, a UWB-AP may be advertised after an NB-AP including a UWB Info field is transmitted. The UWB Info field may include information such as the UWB channel on which the UWB-AP operates, delta T (i.e., the remaining time until the next UWB-AP advertisement based on the current packet), and the preamble code used by the UWB-AP. The UWB-AP may include a per-session info field (e.g., UWB channel usage adjustment information) to inform other controllers.

[0494] Unlike the examples of FIGS. 24 and 25 for UWB channel usage coordination using UWB-APs, in the example of FIG. 26 which uses only NB-APs and not UWB-APs, since UWB-APs are not broadcast, the NB-APs do not include a UWB-AP Info field, but may include a per-session info field (e.g., UWB channel usage coordination information) to inform other controllers.

[0495] Although ADV-POLL used in the aforementioned discovery (or initialization) and setup, and AP used in channel usage coordination have different purposes, they are commonly broadcast on the discovery (or initialization) channel. Since the number of NB discovery (or initialization) channels and / or UWB discovery (or initialization) channels is limited (e.g., 1 or 2), the possibility of broadcast packet collisions may increase as the number of UWB devices performing discovery (or initialization) and setup operations and channel usage coordination operations simultaneously increases. If broadcast packets are not properly delivered to the required receiving devices due to collisions, the performance of the discovery (or initialization) and setup operations and / or channel usage coordination operations may degrade. A new method is required to prevent this performance degradation problem.

[0496] Various examples of the present disclosure that optimize discovery (or initialization) and setup operations and channel usage adjustment operations are described below.

[0497] In some embodiments of the present disclosure, a new response message (e.g., an ADV-RESP message) may be defined to support requesting Channel Usage Information (CUI) during discovery (or initialization) and setup processes. The new response message may correspond to a response to an advertising message (e.g., an ADV-POLL message).

[0498] FIG. 27 is a diagram showing examples of an advertising message format and a response message format according to the present disclosure.

[0499] Fig. 27(a) shows an example of an ADV-POLL payload (PSDU) packet format (e.g., NB O-QPSK case). The ADV-POLL packet format may include a 1-octet ID field (e.g., ID=0x20 (see Table 11)), a 2-octet address (ADDR) field, a 1-octet RFU (i.e., reserved) field, and a 2-octet CRC field. The ADV-POLL message may include an address (ADDR) field to indicate the presence of a device broadcasting it. If the address information of the device transmitting the ADV-POLL is included in the header, the ADDR field may be omitted from the PSDU, thereby reducing the ADV-POLL size.

[0500] Fig. 27(b) illustrates an example of an ADV-POLL IE format (e.g., for a UWB case). The UWB header IE packet format may include a 7-bit length field, an 8-bit element ID field, a 1-bit type field, a 2-octet ADDR field, and a 1-octet RFU field. For example, the element ID may be set to a value corresponding to ADV-POLL (e.g., one of 0x80 to 0xFF, e.g., 0x80). The type field may be set to 0.

[0501] The ADV-POLL message / packet in these discovery / initialization and setup can be broadcast on the NB discovery / initialization channel or the UWB discovery / initialization channel. In addition, the AP (acquisition packet) in the channel usage coordination can also be broadcast on the NB / UWB discovery / initialization channel. The AP message / packet can be broadcast to inform other controllers of the scheduling information of the RAN to which the initiator belongs, and can include fields such as those in Tables 13 to 17 described above.

[0502] Due to channel congestion and collisions that occur when ADV-POLL and AP broadcast on the same NB / UWB discovery / initialization channel, performance degradation is expected not only during the discovery / initialization and setup processes but also during the channel usage coordination process. To prevent these issues, improvements to the UWB advertising packet that support concurrent ranging session initiation and channel usage coordination can be considered. Examples of improving response messages (e.g., ADV-RESP) to advertising messages are described below.

[0503] By receiving the ADV-POLL broadcast by the initiator during the discovery (or initialization) and setup process, the responder can become aware of the initiator's presence. After the responder receives the ADV-POLL, a two-way handshake process can be performed. The responder sends an ADV-RESP in response to the ADV-POLL, and the initiator, upon receiving the ADV-RESP, sends an SOR, allowing the responder to participate in the ranging session. By utilizing this two-way handshake process, advertising packets can be used not only for discovery (or initialization) and setup, but also for channel usage coordination. For example, the initialization of a ranging session can be performed or channel usage information can be requested depending on the information contained in the ADV-RESP sent by the responder.

[0504] FIG. 27(c) illustrates an example of an ADV-RESP payload (PSDU) packet format (e.g., NB O-QPSK case). The ADV-RESP packet format may include a 1-octet ID field (e.g., ID=0x21 (see Table 11)), a 2-octet address (ADDR) field, a 1-octet request mode field, and a 2-octet CRC field. The ADDR field may be set to the address value of the responder. If the address information of the device transmitting the ADV-RESP is included in the header, the ADDR field may be omitted from the PSDU, thereby reducing the ADV-RESP size. Here, unlike the existing ADV-RESP format where 1 octet is reserved (RFU) between the ADDR field and the CRC field, the ADV-RESP format according to the present disclosure includes a new request mode field.

[0505] Fig. 27(d) illustrates an example of an ADV-RESP IE format (e.g., UWB case). The UWB header IE packet format may include a 7-bit length field, an 8-bit element ID field, a 1-bit type field, a 2-octet ADDR field, a 1-octet request mode field, and a 1-octet RFU field. For example, the element ID may be set to a value corresponding to ADV-RESP (e.g., one of 0x80 to 0xFF, e.g., 0x81). The type field may be set to 0. Here, unlike the existing ADV-RESP format where the 2 octets following the ADDR field are reserved (i.e., RFU), the ADV-RESP format according to the present disclosure includes a new request mode field.

[0506] The request mode field included in the aforementioned ADV-RESP may include information indicating whether the responder is requesting a ranging session setup or information for channel usage coordination. An initiator (i.e., an advertising device) receiving an ADV-RESP including this request mode field may transmit an SOR or a CUI based on the value of the request mode field, and a subsequent frame exchange sequence may be performed.

[0507] For example, the Request Mode field may be defined as 2 bits in size. When the Request Mode field is set to a first value (e.g., 00), this may indicate that a ranging session is requested. When the Request Mode field is set to a second value (e.g., 01), this may indicate that Channel Usage Adjustment Information (CUI) is requested. The third value (e.g., 10) and the fourth value (e.g., 11) of the Request Mode field may be defined or reserved for other purposes.

[0508] Alternatively, the Request Mode field may be defined as 1 bit in size. When the Request Mode field is set to a first value (e.g., 0), this may indicate that a ranging session is requested. When the Request Mode field is set to a second value (e.g., 1), this may indicate that Channel Usage Adjustment Information (CUI) is requested.

[0509] In some embodiments of the present disclosure, a message exchange between an initiator and a responder based on a response message including a request mode field may be defined.

[0510] FIG. 28 is a diagram showing examples of message exchanges between an initiator and a responder according to the present disclosure.

[0511] Figure 28(a) illustrates an example of a two-way handshake procedure when the value of the Request Mode field included in the ADV-RESP transmitted by the responder in response to the ADV-POLL transmitted by the initiator is the first value. Since the Request Mode field having the first value indicates that the responder is requesting a ranging session setup, the initiator may transmit a SOR message. Subsequent operations on the ranging channel may be performed as described with reference to Figure 23.

[0512] Figure 28(b) illustrates an example of a two-way handshake procedure when the value of the Request Mode field included in the ADV-RESP transmitted by the responder in response to the ADV-POLL transmitted by the initiator is the second value. Since the Request Mode field having the second value indicates a request for the initiator's Channel Usage Information (CUI), the initiator may transmit a CUI message. For example, the CUI message may include some or all of the information exemplified in Tables 13 to 17 described above.

[0513] Here, the responder may belong to the same RAN as the initiator, or may belong to a different RAN from the RAN to which the initiator belongs. For example, the initiator in FIG. 28(b) may correspond to initiator 1 in RAN1, and the responder in FIG. 28(b) may correspond to initiator 2 in RAN2. The responder (or initiator 2 in RAN2) may request channel usage information from the initiator (e.g., initiator 1 in RAN1) for collision avoidance.

[0514] Fig. 28(c) illustrates an example of an initiator broadcasting a CUI message. For example, the initiator may broadcast a CUI message considering its own status (e.g., resource status, etc.), channel status, etc., so that other surrounding devices may obtain information about its channel usage. The other device that obtains the CUI may be an initiator of another RAN. For example, a CUI related to RAN1 broadcasted by initiator 1 belonging to RAN1 may be obtained by a device belonging to another RAN (or starting or operating another RAN) (e.g., initiator 2 belonging to RAN2, and / or initiator 3 belonging to RAN3), and may be utilized for RAN configuration of the other device.

[0515] For example, if the value of the request mode field included in the ADV-RESP transmitted by the responder (or the initiator 2 of another RAN) in response to the ADV-POLL transmitted by the initiator 1 is the second value, the initiator 1 can broadcast the CUI. Accordingly, not only the responder that transmitted the response message, but also other devices in the vicinity (e.g., the initiator 3) can obtain the CUI of the initiator 1. Specifically, the initiator 3 can opportunistically scan the CUI message from the initiator 1. In this way, even if the initiator 3 does not perform the two-way handshake procedure through receiving the ADV-POLL and responding to the ADV-RESP, the initiator 3 can obtain the CUI information related to the other initiator (or the other RAN) and utilize it when starting up the RAN3 or changing the channel of the operating RAN3. For example, initiator 3 may select / decide on a channel associated with RAN3, avoiding (i.e., not overlapping) a channel associated with initiator 1 (or RAN1).

[0516] For example, initiator 2 and initiator 3 can obtain the CUI of the same initiator 1 and use it to select / decide the channel associated with their RAN (or avoid the channel associated with initiator 1 / RAN1). In this case, if initiators 2 and 3 do not know each other's channel information, they may attempt to access the same UWB medium at the same time. Such collision problems can be avoided or reduced using back-off timers, random delay timers, etc. For example, a device attempting to access a channel selected based on (or avoiding) a CUI broadcast by another device can select a back-off / random delay timer based on a predetermined rule, and perform access to the channel when the timer expires.

[0517] FIG. 29 illustrates an example of concurrent ranging session and exchange of channel usage coordination information between devices belonging to different RANs according to the present disclosure.

[0518] In the example of Figure 29, it is assumed that initiator 1, responder 1, and responder 2 belonging to RAN1 are in ranging operation, and responder 3 is performing UWB scanning. It is also assumed that there is another RAN (e.g., RAN2) initiator 2 that is started or operating.

[0519] Initiator 1 belonging to RAN1 is conducting a ranging session with Responder 1 and Responder 2 (on the ranging channel) and may periodically broadcast ADV-POLL messages on the discovery (or initialization) channel.

[0520] Responder 3 may perform scanning on a discovery (or initialization) channel to participate in a ranging session of RAN1. Responder 3, which discovers / receives an ADV-POLL transmitted from initiator 1 during the scanning process, may transmit an ADV-RESP to initiator 1. Here, the value of the request mode field included in the ADV-RESP transmitted by responder 3 may be set to a first value (i.e., a ranging session is requested). When initiator 1 receives ADV-RESP from responder 3 and the request mode field indicates the first value (i.e., a ranging session is requested), it may transmit an SOR to responder 3 in response thereto. Responder 3, which receives the SOR, may participate in a ranging session in the next ranging block. For example, responder 3 can know that ranging round 1 is the active round in ranging block n+1 from the time offset, ranging channel information, etc. included in the SOR, and can start participating in RAN1 in slot 3 among active slots 1, 2, and 3 within the active ranging round.

[0521] Initiator 2, which is attempting to start or is operating RAN2, may scan the discovery (or initialization) channel for channel usage coordination. Initiator 2, which discovers / receives ADV-POLL transmitted by initiator 1 through scanning, may transmit ADV-RESP to initiator 1. Here, the value of the request mode field included in the ADV-RESP transmitted by initiator 2 may be set to a second value (i.e., channel usage information (CUI) is requested). When initiator 1 receives ADV-RESP from initiator 2 and the request mode field indicates the second value (i.e., CUI is requested), in response, it may transmit CUI to initiator 2. Initiator 2, which receives the CUI, may schedule / configure the ranging session and ranging channel of RAN2 so as not to overlap with RAN1 and start RAN2. For example, initiator 2 can obtain scheduling information of RAN1 (e.g., ranging round duration, number of rounds, active rounds, etc.). Initiator 2 can configure its own channel (or RAN2) so as not to overlap with the channel associated with initiator 1 (or RAN1). Initiator 2 can also periodically broadcast its ADV-POLL on the discovery (or initialization) channel so as not to overlap with the channel associated with initiator 1.

[0522] In the conventional UWB system, the channel information of the RAN cannot be shared with other devices during the discovery (or initialization) and setup process, and is only provided through a channel usage adjustment procedure via an NB-AP or UWB-AP. In contrast, in the present disclosure, a ranging session request or a channel usage information request can be simultaneously performed through a response message to an advertising message (e.g., ADV-POLL), and other devices that have not transmitted the response message can also obtain the channel usage information of the advertising device. Therefore, participation in a ranging session and / or sharing of channel usage information is supported more quickly and efficiently, and accordingly, a new effect of reducing collisions through channel avoidance between devices belonging to different RANs can be achieved.

[0523] Discovery / initialization and setup based on various advertising-related packet formats

[0524] Below, we describe various packet format-based advertising applicable to native discovery / initialization and setup for NBA-MMS-UWB.

[0525] As described above, for discovery / initialization, the initiator advertises itself, and the responder can perform scanning to discover it. The responder can then set up a ranging session based on the advertising information it acquires. Various options for these discovery / initialization and session setup use cases can be considered, such as when advertising that supports device privacy (i.e., private advertising) is required, and when public advertising is required. Accordingly, discovery / initialization and setup can be supported in-band (i.e., NB channels / UWB channels) (i.e., without exchanging information via OOB).

[0526] To this end, it is necessary to define private advertising messages or public advertising messages (e.g., advertising poll frames, advertising response frames, SOR frames, etc.). Various examples of the present disclosure for performing discovery / initialization and setup processes based on such various advertising messages are described below.

[0527] FIG. 30 is a drawing for explaining an example of the operation of the first device according to the present disclosure.

[0528] In the examples of FIGS. 30 and 31, the first device may correspond to an initiator or controller, and the second device may correspond to a responder or controlled party.

[0529] In step S3010, the first device can transmit a first frame to the second device, the first frame including a first variable-length field, or including a first variable-length field and a second variable-length field.

[0530] For example, a first frame may include a first variable-length field and may additionally include a second variable-length field or may not include a second variable-length field. When the first frame includes the first variable-length field and the second variable-length field, the first variable-length field may be positioned consecutively with the second variable-length field within the first frame. The first variable-length field and the second variable-length field may be included within a message content field of the first frame. The second variable-length field may be positioned at the end of the message content field.

[0531] The first variable-length field may include a first length field and a first content field. For example, the first variable-length field may be composed of a first length field and a first content field. For example, the first variable-length field may be composed in a length-value (LV) format without including other fields such as a type field. The first length field may indicate the number of octets included in the first content field. The first length field may be defined as having a size of 1 octet.

[0532] The message content field may include a bit indicating the presence or absence of a second variable-length field. The bit indicating the presence or absence of the second variable-length field may be positioned before the first variable-length field and the second variable-length field within the message content field. For example, a field indicating the length of the second variable-length field may not be included in the first frame. The length of the second variable-length field may be based on other information, such as the value of a frame length field included in a PHY header of a PPDU including the first frame. For example, the length of the second variable-length field may be indicated / determined from the value of a frame length field of the PHY header. The bit indicating the presence or absence of the first variable-length field may not be included in the first frame. For example, the first variable-length field is always present, and if there is no content of the first variable-length field, the value of the first length field may be set to 0.

[0533] The message content field may include an initialization slot duration field, a cap duration field, a group ID field, the aforementioned first variable-length field (e.g., an advertising data field), and the aforementioned second variable-length field (e.g., an SMC TLVs field). For example, if the first variable-length field is an advertising data field, the first length field of the first variable-length field may be an advertising data length field, and the first content field may be an advertising data content field.

[0534] In step S3020, the first device can receive a second frame responding to the first frame from the second device.

[0535] The first frame may be a public advertising poll compact frame. The second frame may be a public advertising response compact frame. Based on this, a ranging session initialization process using a public address may be performed on an initialization channel (e.g., an NB channel or a UWB channel). After transmitting and receiving the second frame, a SOR frame may be transmitted from the first device to the second device, thereby initiating a UWB MMS ranging session.

[0536] Although not shown in FIG. 30, an advertising confirmation frame may be transmitted from the first device to the second device before transmitting the SOR frame after receiving the advertising response frame. For example, if the advertising confirmation frame is a public advertising confirmation frame, the advertiser address included in the public advertising confirmation frame may be the same as the advertiser address included in the public advertising poll frame, the same as the advertiser address included in the public advertising response frame, and the same as the advertiser address included in the public SOR frame.

[0537] The public addresses described through the example of FIG. 30 (e.g., a public address randomly generated by the first device and a public address randomly generated by the second device) may not change for public advertising poll frames, public advertising response frames, and public SOR frames (and public advertising acknowledgement frames) while the first device and the second device are in a ranging session.

[0538] In addition, for each of one or more of the advertising poll frame, advertising response frame, SOR frame, and advertising confirmation frame described through the example of FIG. 30, multiple frame formats (or packet formats) may be defined in relation to whether a public address is used. Furthermore, for each of one or more of the poll frame, response frame, and report frame transmitted or received in the ranging session, multiple frame formats (or packet formats) may be defined in relation to whether a public address is used. That is, a frame format that uses a public address and a frame format that does not use a public address (or uses a private address) may be defined. These frame formats distinguished according to whether a public address is used may be distinguished by a message ID (or frame identifier), by an address type, or by the same message ID (or frame identifier) ​​and a distinct subtype (or extended identifier).

[0539] For example, if distinguished by a frame identifier, the frame formats can be distinguished as follows. For example, if multiple advertising poll frames are defined in relation to whether a public address is used, the frame identifier field included in the advertising poll frame can be set to different values ​​for the multiple advertising poll frames. For example, if multiple advertising response frames are defined in relation to whether a public address is used, the frame identifier field included in the advertising response frame can be set to different values ​​for the multiple advertising response frames. For example, if multiple SOR frames are defined in relation to whether a public address is used, the frame identifier field included in the SOR frames can be set to different values ​​for the multiple SOR frames. For example, if multiple advertising confirmation frames are defined in relation to whether a public address is used, the frame identifier field included in the advertising confirmation frame can be set to different values ​​for the multiple advertising confirmation frames.

[0540] The advertising poll frame, advertising response frame, SOR frame, and advertising confirmation frame described through the example of Fig. 30 can be transmitted or received on an NB (narrowband) channel or an UWB channel. Furthermore, the poll frame, response frame, and report frame in a ranging session can be transmitted or received on an NB channel or an UWB channel.

[0541] A (public) advertising poll frame, a (public) advertising response frame, a (public) advertising acknowledgement frame, a (public) SOR frame, a (public) poll frame in a ranging session, a (public) response frame in a ranging session, and a (public) report frame in a ranging session according to various examples of the present disclosure may be included in a UWB PPDU (e.g., a PPDU including an SHR, a PHR, and a PHY payload, as described with reference to FIGS. 2 and 3). Alternatively, the (public) advertising poll frame, the (public) advertising response frame, the (public) advertising acknowledgement frame, the (public) SOR frame, the (public) poll frame in a ranging session, the (public) response frame in a ranging session, and the (public) report frame in a ranging session according to various examples of the present disclosure may be included in an O-QPSK-based PPDU in the NB (e.g., a PPDU including the aforementioned preamble, SFD, PHR, and payload). For example, the (public) advertising poll frame, the (public) advertising response frame, the (public) advertising acknowledgement frame, the (public) SOR frame, the (public) poll frame in a ranging session, the (public) response frame in a ranging session, and the (public) report frame in a ranging session may be included in the PHY payload of the UWB / NB PPDU.

[0542] As a specific example of the operation of the first device, broadcasting of an advertising packet may be initiated according to a command from a higher layer, such as a MAC layer of the first device. The first device (i.e., advertiser) may generate a secure / private advertising packet or an insecure / public advertising packet according to security-related information (e.g., security level, security mode, etc.) of the higher layer. The first device may broadcast the generated advertising packet according to a predetermined time interval. If the higher layer commands to stop broadcasting, the advertising packet transmission operation may be terminated.

[0543] The method described in the example of FIG. 30 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 transmit a first frame including a first variable-length field and a second variable-length field to a second device (200) via one or more transceivers (106), and receive a second frame responsive to the first frame from the second device (200) 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. 30 or the examples described below when executed by one or more processors (102).

[0544] FIG. 31 is a drawing for explaining an example of the operation of a second device according to the present disclosure.

[0545] In step S3110, the second device may receive a first frame from the first device, the first frame including a first variable-length field, or including a first variable-length field and a second variable-length field.

[0546] In step S3120, the second device can transmit a second frame responding to the first frame to the first device.

[0547] In the example of Fig. 31, the specific descriptions of the first frame, the second frame, the first variable-length field within the first frame, and the second variable-length field are the same as those described with reference to Fig. 30, so redundant descriptions are omitted.

[0548] As a specific example of the operation of the second device, the second device may initiate a scanning operation according to a command from a higher layer. The second device (i.e., the scanner) may periodically scan the discovery / initialization channel to find advertising packets broadcast from the first device (i.e., the advertiser). If it is confirmed that an advertising packet is included in a PPDU discovered through scanning, a postprocessing step for processing according to the security level / security mode may be performed based on security-related information (e.g., security level, security mode, etc.) included in the advertising packet. In the postprocessing step, an operation of interpreting / parsing the security area of ​​the secured / private advertising poll frame according to the security level / security mode may be performed. If the scanner has information for interpreting / parsing the secure area, it can obtain the necessary information (e.g., private address) within the secure area and perform a two-way handshake operation (e.g., transmitting an advertising response frame) for setting up a ranging session. If it cannot obtain the necessary information, it cannot use the received advertising poll frame and can continue the scanning operation until a command to stop scanning is provided by the upper layer. If the discovered / received advertising packet corresponds to an insecure / public advertising poll frame, the scanner can interpret / parse the frame and perform a two-way handshake operation for setting up a ranging session.

[0549] The method described in the example of FIG. 31 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 first frame including a first variable-length field and a second variable-length field from the first device (100) via one or more transceivers (206), and transmit a second frame responsive to the first frame to the first device (100) via one or more transceivers (206). A message / packet received via the transceiver (206) may be stored in the memory (204). The processor (202) may perform decoding on the message / packet stored in the memory (204). The processor (202) may obtain control information included in the message / packet, and store the obtained control information in the memory (204). The processor (202) can remove noise and interference through amplification and filtering, and convert the signal into binary data through sampling, demodulation, and decoding processes. 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-Solomon decoding, etc. can be performed. The restored data can be used to extract the original information transmitted from the transmitter. This process can include various error correction and data recovery techniques to confirm that the transmitted data has been correctly 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) may transmit information about the decoded data field to a higher layer (e.g., a MAC layer) and, in response, perform subsequent operations when the higher layer instructs the PHY layer to generate a signal. Furthermore, one or more memories (204) of the second device (200) may store commands for performing the method described in the example of FIG. 31 or the examples described below when executed by one or more processors (202).

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

[0551] The advertising poll packet format, advertising response packet format, and SOR packet format for NBA-MMS-UWB proposed in the present disclosure can be defined as in the following examples.

[0552] Example 1

[0553] The present embodiment relates to a method for defining an advertising poll packet format, an advertising response packet format, and a SOR packet format related to private advertising.

[0554] For clarity of explanation, the poll packet format associated with private advertising is referred to as the ADV-POLL packet format, the response packet format associated with private advertising is referred to as the ADV-RESP packet format (e.g., Advertising Response Compact frame), and the SOR packet format associated with private advertising is referred to as the SOR packet format.

[0555] Static addresses in message headers can allow unintended users to track your mobile device.

[0556] To protect against such tracking, in the case of private advertising, an address for privacy protection (i.e., a privacy protected address) may be used.

[0557] For example, a resolveable private address (RPA) can be used for private advertising. A public address can be information known only to the initiator and respondent(s).

[0558] In this regard, an advertiser that broadcasts advertising packets and a scanner that scans them may have a pre-defined resolving list. The pre-defined resolving list may be used before any communication between the advertiser and the scanner (e.g., a two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging them mutually through an implementation-specific manner may be provided. For example, a table for the advertiser address resolving list may be pre-defined, and a method for commonly distributing the list may be used.

[0559] After two or more devices have performed discovery through the advertising and scanning processes, address verification can be performed, such as during the session setup phase, to verify that the discovery results are identical. The random address can be changed periodically by the advertiser, and the changed value can be generated based on a key pair in the analysis list.

[0560] A private address can be composed of a private address and a private salt (e.g., AES-128-ECB(key=PublicAddress, data=(padding || PrivateSalt)). For example, a POLL packet format or an ADV-POLL packet format can be composed of a 3-octet private address field (PrivAddr) and a 3-octet private salt (PrivSalt), and other narrowband (NB) packet formats can be composed of a 3-octet private address field.

[0561] (Example 1-1. ADV-POLL packet format)

[0562] FIG. 32 illustrates an example of a private address-based advertising poll packet format according to the present disclosure.

[0563] Referring to FIG. 32, a private address-based ADV-POLL packet format may include a Message ID field, a Private Address (e.g., RPA Hash) field, a Private Salt (e.g., RPA Prand) field, a Message Control field, and a Message Content field.

[0564] For example, the Message ID field may indicate that the packet is in ADV-POLL packet format.

[0565] With respect to the private address field and private salt field, the advertiser broadcasting the advertising packet and the scanner scanning it may have a pre-defined resolving list. The pre-defined resolving list may consist of local and peer resolving key pairs. The resolving list may be used prior to any communication between the advertiser and the scanner (e.g., a two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging them mutually may be provided in an implementation-specific manner. For example, a table for the advertiser address resolving list may be pre-defined, and a common distribution method may be used.

[0566] After two or more devices have performed discovery through the advertising and scanning processes, address verification can be performed, such as during the session setup phase, to verify that the discovery results are identical. The random address can be changed periodically by the advertiser, and the changed value can be generated based on a key pair in the analysis list.

[0567] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0568] For example, a message content format corresponding to "0x00" indicated by the message control field may consist of a length field of a supported setup version list (SSVL) (e.g., Supported Message Control, SMC) and a supported setup version list field. For this format, a CRC field (e.g., CRC16) may be added. In this regard, other values ​​indicated by the message control field (e.g., values ​​from "0x01 to ff") may be defined as reserved.

[0569] (Example 1-2. ADV-RESP packet format)

[0570] FIG. 33 illustrates an example of a private address-based advertising response packet format according to the present disclosure.

[0571] Referring to FIG. 33, the ADV-RESP packet format based on a private address may include a Message ID field, a Private Address (e.g., RPA Hash) field, a Message Control field, and a Message Content field. In this regard, information about a private salt (e.g., RPA Prand) may be obtained through the ADV-POLL packet format.

[0572] For example, the Message ID field may indicate that the packet is in ADV-RESP packet format (e.g., a value of "0x21").

[0573] With respect to the private address field, the advertiser broadcasting the advertising packet and the scanner scanning it may have a pre-defined resolving list. The pre-defined resolving list may consist of local and peer resolving key pairs. The resolving list may be used prior to any communication between the advertiser and the scanner (e.g., a two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging the resolving list may be provided in an implementation-specific manner. For example, a table for the advertiser address resolving list may be pre-defined, and a common distribution method may be used.

[0574] After two or more devices have performed discovery through the advertising and scanning processes, address verification can be performed, such as during the session setup phase, to verify that the discovery results are identical. The random address can be changed periodically by the advertiser, and the changed value can be generated based on a key pair in the analysis list.

[0575] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0576] A message content format (e.g., setup request) corresponding to "0x01" indicated by the message control field may be composed of an NB channel selection field, a UWB PHY configuration field, a UWB MAC configuration field, an NB PHY configuration field, and an NB MAC configuration field. For the corresponding format, a CRC field (e.g., CRC16) may be added. In this regard, other values ​​indicated by the message control field (e.g., a value of "0x00", a value of "0x02 to ff") may be defined as reserved.

[0577] For example, the NB channel selection field can be defined based on Table 18.

[0578] Field Bit Length Description NB Channel Selection 16 bits 0-1: UNII-3 border channel exclusion {0, 1, 3, 7} Bits 2-4: UNII-5 low-side channel excusion {0, 1, 3, 7, 15, 31, 63, 127} Bits 5-7: UNII-5 high-side channel excusion {0, 1, 3, 7, 15, 31, 63, 127} Bits 8-12: low-side channel start offset {0-31} Bits 13-15: Channel skip length {0, 1, 3, 7, 15, 31, 63, 127}

[0579] For example, the UWB PHY configuration field can be defined based on Table 19.

[0580] Field Bit Length Description UWB PHY Configuration 16 bits 0-3: RSF Code Index {33, ..., 48} Bits 4-10: RSF complementary set zeros Code Index {0, ..., 64} Bits 11-13: N_MSR {32, 40, 48, 64, 128, 256} Bits 14-15: STS Segment Length x512 {32, 64, 128, 256}

[0581] For example, the UWB MAC configuration field can be defined based on Table 20.

[0582] Field Bit Length Description UWB MAC Setting 8 bits 0-2: {0, 1, 2, 4, 8, 16} X RSFs Bits 3-5: {0, 1, 2, 4, 8} Y RIFs Bit 6: {1ms / 2ms} Z RSF-to-RIF gap Bit 7: Reserved

[0583] For example, the NB PHY configuration field can be defined based on Table 21.

[0584] Field Bit Length Description NB PHY Setting 8 Set O-QPSK PHY #1-#10 in section 1.2.3 {#1: 250k uncoded, ..., #10} Bits 0-3: NB Control Phase Bits 4-7: NB Report Phase

[0585] For example, the NB MAC configuration field can be defined based on Table 22.

[0586] Field Bit Length Description NB MAC Configuration 64 bits 0-4: UWB Channel {1, ..., 32} bits 5-7: Ranging Slot Duration {300, 600, ..., 2400} RSTUs bits 8-15: Ranging Round Duration 0-255 ranging slots bits 16-23: Ranging Block Duration 0-255 ranging rounds bits 24: Channel Switching: 0 = Disabled, 1 = Blockwise bit 25: Measurement Report Request: 0 = No, 1 = Yes bits 26-31: Reserved bits 32-35: RcpPollSlots = 0-15 bits 36-39: RcpResponseSlots = 0-15 bits 40-51: RpDuration = 0-4095 bits 52-55: RpOffset = 0-15 bits 56-59: MrpFirstSlots = 0-15 bits 60-63: MrpSecondSlots = 0-15

[0587] (Example 1-3. SOR Packet Format) FIG. 34 shows an example of a private address-based ranging start packet format (e.g., Start of Ranging Compact Frame) according to the present disclosure.

[0588] Referring to Figure 34, a private address-based SOR packet format may include a Message ID field, a Private Address field, a Message Control field, and a Message Content field. In this regard, information about the private salt can be obtained through the ADV-POLL packet format.

[0589] For example, the Message ID field may indicate that the packet is in SOR packet format (e.g., a value of "0x22").

[0590] With respect to the private address field, the advertiser broadcasting the advertising packet and the scanner scanning it may have a pre-defined resolving list. The pre-defined resolving list may consist of local and peer resolving key pairs. The resolving list may be used prior to any communication between the advertiser and the scanner (e.g., a two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging the resolving list may be provided in an implementation-specific manner. For example, a table for the advertiser address resolving list may be pre-defined, and a common distribution method may be used.

[0591] After two or more devices have performed discovery through the advertising and scanning processes, address verification can be performed, such as during the session setup phase, to verify that the discovery results are identical. The random address can be changed periodically by the advertiser, and the changed value can be generated based on a key pair in the analysis list.

[0592] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0593] The message content format (e.g., setup) corresponding to "0x01" indicated by the message control field includes an NB channel selection field, a UWB PHY configuration field, a UWB MAC configuration field, an NB PHY configuration field, and an NB MAC configuration field, similar to the above-described ADV-RESP packet format (e.g., the format of FIG. 33), and a time offset field and a channel seed field may be added to the front of the format. Here, the time offset field indicates the time between the SOR packet and the poll packet of the first ranging block, and may be allocated within the range of 0-65535us. The channel seed field may be defined to be able to initialize a channel switching function. For the format, a CRC field (e.g., CRC16) may be added. In this regard, other values ​​indicated by the message control field (e.g., values ​​"0x00", "0x02 to ff") may be defined as reserved.

[0594] Based on the above description, ADV-POLL packet format, ADV-RESP packet format, and SOR packet format for private advertising can be defined.

[0595] In this regard, the private address and private salt can be controlled at the beginning of each ranging block to prevent the initiator from tracking the device(s) through the PSDU header address. For example, the device MAC address (e.g., an IEEE 802.15.4-based device MAC address), PAN ID, source short address, and destination short address can be used to generate the private address. Additionally, the message control field can define various message content formats to enable sub-features (e.g., future-proof handshaking) on ​​a per-message basis. Additionally, the handshake setup protocol can enable in-band NBA-MMS-UWB configuration and initiation of a ranging session.

[0596] Example 2

[0597] The present embodiment relates to a method for defining an advertising poll packet format, an advertising response packet format, and a SOR packet format related to public advertising.

[0598] Advertising polls (ADV_POLL) can be broadcast on discovery / initialization channels. In use cases where privacy must be guaranteed, secure advertising is required to a single device or group of devices that have been previously verified through a process such as authentication. Alternatively, in use cases where establishing ranging sessions with an unspecified number of users is required / allowed, a public (i.e., non-private) / insecure advertising method is required, allowing any device to interpret advertising packets such as advertising polls.

[0599] To support packet formats for advertising such as the aforementioned unsecured / public, new IDs, i.e. new message / packet IDs, can be assigned / defined.

[0600] For clarity of explanation, the poll packet format related to public advertising is referred to as the ADV-POLL2 packet format, the response packet format related to public advertising is referred to as the ADV-RESP2 packet format, and the SOR packet format related to public advertising is referred to as the SOR2 packet format.

[0601] (Example 2-1. ADV-POLL2 packet format)

[0602] FIG. 35 illustrates an example of a poll packet format (e.g., Advertising Poll Compact frame) for public advertising according to the present disclosure.

[0603] Referring to FIG. 35, the ADV-POLL2 packet format for public advertising may include a Message ID field, an advertiser address field, a Message Control field, and a Message Content field.

[0604] For example, the Message ID field may indicate that the packet is in ADV-POLL2 packet format (e.g., a value of "0x23").

[0605] The advertiser address field indicates the address of the advertiser, and if the address is specified / included in the header, the advertiser address field may be omitted.

[0606] As the advertiser address, a public address or a random address can be used. The public address corresponds to the address assigned to the device and may be based on a short address or an extended address. The random address may correspond to an address randomly generated by the advertiser to prevent direct exposure of the public address. The rules for generating the random address may be as follows.

[0607] For example, if the advertiser is a controller, the random address can be generated as an arbitrary short address, an arbitrary extended address, or another form of address. In this case, the controller can select a unique value from among the addresses used within the ranging area network (RAN).

[0608] When random addresses are used, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After discovery between devices is performed through the advertising / scanning process, the advertiser, which is the controller, manages the random address and can also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may change, so the address may no longer be used. Additionally, a resolving list, such as IRK, can be exchanged according to a trusted device verification procedure (e.g., mutual verification during a two-way handshake). In this case, resolving key pairs within the resolving list can be utilized to extract / store information, such as analyzable private addresses.

[0609] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0610] For example, a message content format corresponding to "0x00" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL) and a supported setup version list field. For this format, a CRC field (e.g., CRC16) may be added. In this regard, other values ​​indicated by the message control field (e.g., values ​​from "0x01 to ff") may be defined as reserved.

[0611] Additionally, messages used in the two-way handshake with ADV-POLL2 for public (non-private) advertising can be defined as ADV-RESP2 packets and SOR2 packets.

[0612] (Example 2-2. ADV-RESP2 packet format)

[0613] FIG. 36 illustrates an example of a response packet format (e.g., Advertising Response Compact frame) for public advertising according to the present disclosure.

[0614] Referring to FIG. 36, the ADV-RESP2 packet format for public advertising may include a Message ID field, an Advertiser Address field, a Message Control field, and a Message Content field.

[0615] For example, the Message ID field may indicate that the packet is in ADV-RESP2 packet format (e.g., a value of "0x24").

[0616] The advertiser address included in the advertiser address field may be expressed by the abbreviation AdvAddr, or the initiator address included in the advertiser address field may be expressed by the abbreviation InitiatorAddr. In addition, the responder address included in the responder address (or scanner address) field may be expressed by the abbreviation RespAddr, or the scanner address included in the responder address field may be expressed by the abbreviation ScannerAddr. In the present disclosure, the advertiser / initiator address is mainly referred to by the abbreviation AdvAddr, but the scope of the present disclosure is not limited thereto and may be replaced with an abbreviation of another expression. In addition, in the present disclosure, the responder / scanner address is mainly referred to by the abbreviation RespAddr, but the scope of the present disclosure is not limited thereto and may be replaced with an abbreviation of another expression.

[0617] The AdvAddr field of the ADV-RESP2 frame may be set to the same value as the address obtained from the ADV-POLL2 (or public advertising poll frame, or public advertising poll compact frame) (i.e., the value of the Advertiser Address field included in the ADV-POLL2 frame). Additionally, the AdvAddr field of the ADV-RESP2 frame may be the destination address of the ADV-RESP2 frame. If the destination address is specified / included in the header, the AdvAddr field may be omitted.

[0618] The RespAddr field of the ADV-RESP2 frame indicates the address of the responder / scanner. If the address is specified / included in the header, the RespAddr field may be omitted. The responder address may be a public address or a random address. The public address corresponds to the address assigned to the device and may be based on a short address or an extended address. The random address may correspond to an address randomly generated by the advertiser to prevent the public address from being directly exposed, and the rules for generating the random address may be as follows.

[0619] For example, if the advertiser is a controller, the random address can be generated as an arbitrary short address, an arbitrary extended address, or another form of address. In this case, the controller can select a unique value from among the addresses used within the ranging area network (RAN).

[0620] When random addresses are used, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After discovery between devices is performed through the advertising / scanning process, the advertiser, which is the controller, manages the random address and can also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may change, so the address may no longer be used. Additionally, a resolving list, such as IRK, can be exchanged according to a trusted device verification procedure (e.g., mutual verification during a two-way handshake). In this case, resolving key pairs within the resolving list can be utilized to extract / store information, such as analyzable private addresses.

[0621] The responder address can be the source address of ADV-RESP2. If the source address is specified / included in the header, the RespAddr field may be omitted. Specifically, the responder address included in RespAddr may be generated by the responder. That is, the responder may generate a RespAddr (e.g., a public address randomly generated by the responder) to be included in the responder address field of the ADV-RESP2 frame. RespAddr may be generated as a 2-octet short address or an 8-octet address as described above, or as an address of another length (e.g., 3-octet) distinct from 2-octets and 8-octets as described below. The generated RespAddr may be set as the source address. If the source address is included in the MAC header (MHR), the RespAddr field may be omitted.

[0622] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0623] The message content format configuration in the ADV-RESP2 packet format may be the same as / similar to the message content format configuration in the aforementioned ADV-RESP packet format (e.g., see FIG. 33).

[0624] For example, a message content format (e.g., setup request) corresponding to "0x00" indicated by the message control field may be composed of an NB channel selection field, a UWB PHY configuration field, a UWB MAC configuration field, an NB PHY configuration field, and an NB MAC configuration field. For the corresponding format, a CRC field (e.g., CRC16) may be added. In this regard, other values ​​indicated by the message control field (e.g., values ​​"0x01 to ff") may be defined as reserved.

[0625] (Example 2-3. SOR2 packet format)

[0626] FIG. 37 illustrates an example of a ranging start packet format (e.g., Start of Ranging Compact Frame) for public advertising according to the present disclosure.

[0627] Referring to FIG. 37, the SOR packet format for public advertising may include a Message ID field, an Advertiser Address field, a Message Control field, and a Message Content field.

[0628] For example, the Message ID field may indicate that the packet is in SOR2 packet format (e.g., a value of "0x25").

[0629] The Advertiser Address (AdvAddr) field of the SOR2 frame may be set to the same value as the address obtained from ADV-RESP2 (i.e., the value of the AdvAddr field of the ADV-RESP2 frame). Additionally, if the advertiser uses a random / public address, the same value included as the advertiser address in the ADV-POLL2 frame, which is the start of the initial two-way handshake, may be used as the value of the AdvAddr field of the SOR2 frame. AdvAddr may be the source address of the SOR2 frame.

[0630] The Responder / Scanner Address (RespAddr) field of the SOR2 frame may be set to the same value as the address obtained from ADV-RESP2 (i.e., the value of the RespAddr field of the ADV-RESP2 frame). RespAddr may be the destination address of the SOR2 frame. If the destination address is included in the header, the RespAddr field may be omitted. If the responder address of ADV-RESP2 is duplicated on the network, the SOR2 frame may not be transmitted.

[0631] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0632] The message content format configuration in the SOR2 packet format may be the same as / similar to the message content format configuration in the aforementioned SOR packet format (e.g., see FIG. 34).

[0633] For example, a message content format (e.g., setup) corresponding to "0x00" indicated by the message control field includes an NB channel selection field, a UWB PHY configuration field, a UWB MAC configuration field, an NB PHY configuration field, and an NB MAC configuration field, similar to the above-described ADV-RESP packet format (e.g., the format of FIG. 33), and a time offset field and a channel seed field may be added to the front of the format. Here, the time offset field indicates the time between the SOR packet and the poll packet of the first ranging block, and may be allocated within the range of 0-65535us. The channel seed field may be defined to be able to initialize a channel switching function. For the format, a CRC field (e.g., CRC16) may be added. In this regard, other values ​​indicated by the message control field (e.g., values ​​"0x01 to ff") may be defined as reserved.

[0634] In the examples described above, when session initialization is completed, a pair of advertiser address (AdvAddr) and responder address (RespAddr) is stored identically in the advertiser and responder / scanner, and can be used without change while maintaining the session.

[0635] (Example 2-4. Additional example 1 of ADV-POLL2 packet format)

[0636] Additionally, in the ADV-POLL2 packet format in the aforementioned embodiment 2-1 (i.e., the ADV-POLL2 packet format illustrated in FIG. 35), the advertiser address can be defined to use a public address or a random address.

[0637] In this regard, the advertiser can determine the address format / type (e.g., public address or random address) and broadcast an advertising packet based on this. At this time, a scanner receiving the packet may need a method to determine the address format / type.

[0638] In order to provide information about the address type, an ADV-POLL2 packet format can be defined that additionally takes into account message control, i.e. the value of the message control field (i.e. a new message content format).

[0639] FIG. 38 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0640] Referring to FIG. 38, the ADV-POLL2 packet format for public advertising may include a Message ID field, an advertiser address field, a Message Control field, and a Message Content field.

[0641] At this time, other fields are the same as the ADV-POLL2 packet format in FIG. 35, and message content that can be indicated by the message control field can be added to indicate information about the address type (AT).

[0642] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0643] For example, the message content format corresponding to "0x00" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL) and a supported setup version list field. Additionally, the message content format corresponding to "0x01" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL), a supported setup version list field, and an address type (AT) field.

[0644] Here, the address type field indicates the address type applied to the advertising address, and the value of the field can be defined as in Table 23.

[0645] Address Type Description Bits: 00 = Public Address, 1 = Random Address Bits: 1-7 Reserved

[0646] (Example 2-5. Additional example 2 of ADV-POLL2 packet format) In the case of ADV-POLL2 packet for public advertising, in a congested environment where advertisers and multiple scanners exist, there may be a high probability of collision when a scanner requests / sends an ADV-RESP2 packet (i.e., an ADV-RESP2 packet in the two-way handshake process for an ADC-POLL2 packet) to the advertiser. Accordingly, a method to avoid such collision may be required.

[0647] To avoid such collisions, a random delay (RD) field can be defined and utilized.

[0648] The random delay field may be used by an advertiser to send an advertising packet, such as an ADV-POLL2 packet, and by a responder that receives an advertising packet, such as an ADV-POLL2 packet, during a two-way handshake process to determine a response time to an advertising packet, such as an ADV-RESP2 packet. In other words, the random delay field may be related to the response time of an advertising packet, such as an ADV-POLL2, and an advertising response packet, such as an ADV-RESP2, during a two-way handshake process.

[0649] When the value of the random delay field is 0, the responder can send a response packet immediately after receiving the advertising packet. When the value of the random delay field is not 0, the responder can defer and send a response packet (e.g., an ADV_RESP2 packet) by using a method such as a random delay backoff within a range based on the value. For example, in a public advertising method, a random delay can be applied to avoid collisions of response packets in a congested environment with many potential responders. The value of the random delay field can be determined by a higher layer. For example, the unit of the value of the random delay field can be RSTU (ranging scheduling time unit), and can be set to a value optimized for the requirements of the application.

[0650] In connection with the provision / delivery of the aforementioned random delay field, an ADV-POLL2 packet format can be defined that additionally takes into account message control, i.e., the value of the message control field (i.e., a new message content format).

[0651] FIG. 39 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0652] Referring to FIG. 39, the ADV-POLL2 packet format for public advertising may include a Message ID field, an advertiser address field, a Message Control field, and a Message Content field.

[0653] At this time, other fields are the same as the ADV-POLL2 packet format in FIG. 38, and a field for indicating random delay (RD) information may be added to specific message content.

[0654] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0655] For example, a message content format corresponding to "0x00" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL) and a supported setup version list field. Additionally, a message content format corresponding to "0x01" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL), a supported setup version list field, an address type (AT) field, and a random delay (RD) field.

[0656] As described above, the random delay field can be used to determine the response time of an advertising packet such as ADV-POLL2 and an advertising response packet such as ADV-RESP2 during a two-way handshake process. When the value of the random delay field is 0, the responder can transmit a response packet immediately after receiving the advertising packet. When the value of the random delay field is not 0, the responder can defer and transmit a response packet (e.g., an ADV_RESP2 packet) by applying a random delay within a range based on the value (e.g., through a method such as a random delay backoff).

[0657] For example, in public advertising, a random delay can be applied to avoid collisions of response packets in a congested environment with many potential respondents. The value of the random delay field can be determined by a higher layer. For example, the unit of the random delay field value can be RSTU (ranging scheduling time unit), and it can be set to a value optimized for the application's requirements.

[0658] (Example 2-6. Additional example 3 of ADV-POLL2 packet format)

[0659] For ADV-POLL2 packets for public advertising, since they are packets broadcast to an unspecified number of people on a channel for discovery / initialization, it may be necessary to include information about the purpose of the ADV-POLL2 packet, etc.

[0660] This information can be referred to as advertising data (ADV Data, AdvData). When multiple advertisers are present in the vicinity, a scanner receiving an ADV-POLL2 packet can utilize this information to select the advertising packets that best suit its intended purpose.

[0661] In connection with the provision / delivery of the aforementioned advertising data, an ADV-POLL2 packet format can be defined that additionally takes into account message control, i.e., the value of the message control field (i.e., a new message content format).

[0662] FIG. 40 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0663] Referring to FIG. 40, the ADV-POLL2 packet format for public advertising may include a Message ID field, an advertiser address field, a Message Control field, and a Message Content field.

[0664] At this time, other fields are the same as the ADV-POLL2 packet format in FIG. 39, and a field for indicating advertising data (AdvData) can be added to specific message content.

[0665] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0666] For example, a message content format corresponding to "0x00" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL) and a supported setup version list field. Additionally, a message content format corresponding to "0x01" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL), a supported setup version list field, an address type (AT) field, a random delay (RD) field, and an advertising data (AdvData) field.

[0667] The advertising data field may contain information that the advertiser wishes to announce. For example, this field may include a list of services supported by the advertiser, and this information may be defined in various forms. For example, a method of defining / expressing a service in a form such as a UUID to uniquely represent the service may be applied. Additionally or alternatively, this field may include the advertiser's friendly name, device type, scheduling information such as the advertising interval, and vendor-specific data desired by the advertiser.

[0668] As described above, the advertising data field / format may be recursively structured based on a length-type-value format to include various types of information. For example, the advertising data format may be structured in the following order: Length field, first type field, first value field, ..., Length field, Nth type field, Nth value field. Alternatively, the advertising data field / format may be structured based on a type-length-value format. For example, the advertising data format may be structured in the following order: first type field, Length field, first value field, ..., Nth type field, Length field, Nth value field. Alternatively, the advertising data format may be in a format other than length-type-value or type-length-value (e.g., length + AdvData).

[0669] Additionally, assuming a packet air-time of 1ms for narrowband (NB), the advertising data field / format may not exceed the maximum size of a PDSU of 24 bytes minus other fields (e.g., SSVL, AT, RD, etc.).

[0670] (Example 2-7. Additional example 4 of ADV-POLL2 packet format)

[0671] In the ADV-POLL2 packet format described in Example 2-6 described above, to prevent tracking by unwanted users using public addresses, the advertiser address may be defined to use only random addresses. In this case, the Address Type (AT) field included in the message content may be omitted. Additionally or alternatively, even when defining that only public addresses are used, the Address Type (AT) field may be omitted.

[0672] The method can be equally applied to other embodiments of the present disclosure (e.g., ADV-POLL2 field format in FIG. 35 of Embodiment 2-1, ADV-POLL2 field format in FIG. 38 of Embodiment 2-4, ADV-POLL2 field format in FIG. 39 of Embodiment 2-5, ADV-POLL2 field format in FIG. 42 of Embodiment 2-8).

[0673] FIG. 41 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0674] Referring to FIG. 41, the ADV-POLL2 packet format for public advertising may include a Message ID field, an advertiser address field, a Message Control field, and a Message Content field.

[0675] For example, the Message ID field may indicate that the packet is in ADV-POLL2 packet format (e.g., a value of "0x23").

[0676] The advertiser address field indicates the address of the advertiser, and if the address is specified / included in the header, the advertiser address field may be omitted.

[0677] A random address can be used as the advertiser address. The random address can be an address randomly generated by the advertiser to prevent direct exposure of the public address. The rules for generating the random address can be as follows:

[0678] For example, if the advertiser is a controller, the random address can be generated as an arbitrary short address, an arbitrary extended address, or another form of address. In this case, the controller can select a unique value from among the addresses used within the ranging area network (RAN).

[0679] When random addresses are used, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After discovery between devices is performed through the advertising / scanning process, the advertiser, which is the controller, manages the random address and can also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may change, so the address may no longer be used. Additionally, a resolving list, such as IRK, can be exchanged according to a trusted device verification procedure (e.g., mutual verification during a two-way handshake). In this case, resolving key pairs within the resolving list can be utilized to extract / store information, such as analyzable private addresses.

[0680] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0681] For example, a message content format corresponding to "0x00" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL) and a supported setup version list field. Additionally, a message content format corresponding to "0x01" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL), a supported setup version list field, a random delay (RD) field, and an advertising data (AdvData) field.

[0682] The random delay field may be used by an advertiser to send an advertising packet, such as an ADV-POLL2 packet, and by a responder that receives an advertising packet, such as an ADV-POLL2 packet, during a two-way handshake process to determine a response time to an advertising packet, such as an ADV-RESP2 packet. In other words, the random delay field may be related to the response time of an advertising packet, such as an ADV-POLL2, and an advertising response packet, such as an ADV-RESP2, during a two-way handshake process.

[0683] When the value of the random delay field is 0, the responder can send a response packet immediately after receiving the advertising packet. When the value of the random delay field is not 0, the responder can defer and send a response packet (e.g., an ADV_RESP2 packet) by applying a random delay within a range based on the value (e.g., through a method such as a random delay backoff). For example, in a public advertising method, a random delay can be applied to avoid collisions of response packets in a congested environment with many potential responders. The value of the random delay field can be determined by a higher layer. For example, the unit of the value of the random delay field can be RSTU (ranging scheduling time unit), and can be set to a value optimized for the requirements of the application.

[0684] The advertising data field may contain information that the advertiser wishes to announce. For example, this field may include a list of services supported by the advertiser, and this information may be defined in various forms. For example, a method of defining / expressing a service in a form such as a UUID to uniquely represent the service may be applied. Additionally or alternatively, this field may include the advertiser's friendly name, device type, scheduling information such as the advertising interval, and vendor-specific data desired by the advertiser.

[0685] As described above, the advertising data field / format may be recursively structured based on a length-type-value format to include various types of information. For example, the advertising data format may be structured in the following order: Length field, first type field, first value field, ..., Length field, Nth type field, Nth value field. Alternatively, the advertising data field / format may be structured based on a type-length-value format. For example, the advertising data format may be structured in the following order: first type field, Length field, first value field, ..., Nth type field, Length field, Nth value field. Alternatively, the advertising data format may be in a format other than length-type-value or type-length-value (e.g., length + AdvData).

[0686] Additionally, assuming a packet air-time of 1ms for narrowband (NB), the advertising data field / format may not exceed the maximum size of a PDSU of 24 bytes minus other fields (e.g., SSVL, RD, etc.).

[0687] Additionally or alternatively, it may be considered that the random delay field is omitted from the ADV-POLL2 packet format illustrated in FIG. 41. In this case, the message content format corresponding to "0x01" may consist of a length field of a supported setup version list (SSVL), a supported setup version list field, and an advertising data (AdvData) field.

[0688] (Example 2-8. Additional example 5 of ADV-POLL2 packet format)

[0689] For ADV-POLL2 packets for public advertising, in a congested environment with advertisers and multiple scanners, collisions may occur when a scanner requests / sends an ADV-RESP2 packet (i.e., an ADV-RESP2 packet during the two-way handshake for an ADC-POLL2 packet) to the advertiser. Therefore, a method to avoid such collisions may be required.

[0690] To avoid such collisions, a random delay (RD) field can be defined and utilized.

[0691] The random delay field may be used by an advertiser to send an advertising packet, such as an ADV-POLL2 packet, and by a responder that receives an advertising packet, such as an ADV-POLL2 packet, during a two-way handshake process to determine a response time to an advertising packet, such as an ADV-RESP2 packet. In other words, the random delay field may be related to the response time of an advertising packet, such as an ADV-POLL2, and an advertising response packet, such as an ADV-RESP2, during a two-way handshake process.

[0692] When the value of the random delay field is 0, the responder can send a response packet immediately after receiving the advertising packet. When the value of the random delay field is not 0, the responder can defer and send a response packet (e.g., an ADV_RESP2 packet) by using a method such as a random delay backoff within a range based on the value. For example, in a public advertising method, a random delay can be applied to avoid collisions of response packets in a congested environment with many potential responders. The value of the random delay field can be determined by a higher layer. For example, the unit of the value of the random delay field can be RSTU (ranging scheduling time unit), and can be set to a value optimized for the requirements of the application.

[0693] In connection with the provision / delivery of the aforementioned random delay field, an ADV-POLL2 packet format can be defined that additionally takes into account message control, i.e., the value of the message control field (i.e., a new message content format).

[0694] FIG. 42 illustrates another example of a poll packet format for public advertising according to the present disclosure.

[0695] Referring to FIG. 42, the ADV-POLL2 packet format for public advertising may include a Message ID field, an advertiser address field, a Message Control field, and a Message Content field.

[0696] For example, the Message ID field may indicate that the packet is in ADV-POLL2 packet format (e.g., a value of "0x23").

[0697] The advertiser address field indicates the address of the advertiser, and if the address is specified / included in the header, the advertiser address field may be omitted.

[0698] The advertiser address field indicates the address of the advertiser, and if the address is specified / included in the header, the advertiser address field may be omitted.

[0699] As the advertiser address, a public address or a random address can be used. The public address corresponds to the address assigned to the device and may be based on a short address or an extended address. The random address may correspond to an address randomly generated by the advertiser to prevent direct exposure of the public address. The rules for generating the random address may be as follows.

[0700] For example, if the advertiser is a controller, the random address can be generated as an arbitrary short address, an arbitrary extended address, or another form of address. In this case, the controller can select a unique value from among the addresses used within the ranging area network (RAN).

[0701] When random addresses are used, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After discovery between devices is performed through the advertising / scanning process, the advertiser, which is the controller, manages the random address and can also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may change, so the address may no longer be used. Additionally, a resolving list, such as IRK, can be exchanged according to a trusted device verification procedure (e.g., mutual verification during a two-way handshake). In this case, resolving key pairs within the resolving list can be utilized to extract / store information, such as analyzable private addresses.

[0702] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0703] For example, a message content format corresponding to "0x00" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL) and a supported setup version list field. Additionally, a message content format corresponding to "0x01" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL), a supported setup version list field, and a random delay (RD) field.

[0704] The random delay field may be used by an advertiser to send an advertising packet, such as an ADV-POLL2 packet, and by a responder that receives an advertising packet, such as an ADV-POLL2 packet, during a two-way handshake process to determine a response time to an advertising packet, such as an ADV-RESP2 packet. In other words, the random delay field may be related to the response time of an advertising packet, such as an ADV-POLL2, and an advertising response packet, such as an ADV-RESP2, during a two-way handshake process.

[0705] When the value of the random delay field is 0, the responder can send a response packet immediately after receiving the advertising packet. When the value of the random delay field is not 0, the responder can defer and send a response packet (e.g., an ADV_RESP2 packet) by applying a random delay within a range based on the value (e.g., through a method such as a random delay backoff). For example, in a public advertising method, a random delay can be applied to avoid collisions of response packets in a congested environment with many potential responders. The value of the random delay field can be determined by a higher layer. For example, the unit of the value of the random delay field can be RSTU (ranging scheduling time unit), and can be set to a value optimized for the requirements of the application.

[0706] The various packet formats described above in the present disclosure (i.e., the packet formats illustrated in FIGS. 35, 38, 39, 40, 41, and 42) may each be defined as packet formats. Additionally or alternatively, the various packet formats described above in the present disclosure (i.e., the packet formats illustrated in FIGS. 35, 38, 39, 40, 41, and 42) may also be defined in a manner of configuring message content by message control ID by adding a message control ID to one packet format.

[0707] Example 3

[0708] Advertising poll packets can be broadcast on the discovery / initialization channel, distinguishing between private advertising and public (non-private) advertising based on the message / packet ID (e.g., ADV-POLL, ADV-POLL2).

[0709] In this regard, for use cases where privacy must be guaranteed, secure advertising is required for a single device or group of devices that have been previously verified through a process such as authentication. Alternatively, for use cases where establishing ranging sessions with an unspecified number of users is required or permitted, a public / unsecured advertising method is required, allowing any device to interpret advertising packets, such as advertising polls.

[0710] Example 3-1

[0711] To support various advertising messages such as the above-mentioned secure / private or unsecured / public, advertising packets based on security levels can be constructed and scanner operations can be defined accordingly.

[0712] Security levels can be defined as follows:

[0713] Level 1: No security

[0714] Level 2: Association with a single device (peer-to-peer)

[0715] Level 3: Purpose of association with device groups

[0716] Level 1 may be used when advertising ADV_POLL to an unspecified number of people. In use cases such as access control in public spaces and payment for public transportation, ADV_POLL is required to be easily transmitted and interpreted by an unspecified number of people, rather than supporting privacy, thereby effectively facilitating ranging session setup. In this case, ADV_POLL may be unencrypted, allowing any scanner / responder to obtain it and establish a ranging session through a two-way handshake.

[0717] Level 2 may apply to cases where ADV_POLL is advertised encrypted so that it can only be acquired by a single device. For example, use cases such as finding a smartphone family accessory device through a ranging session setup between a personal smartphone and a smartphone family accessory device identified through a pre-authentication method may be considered. In this case, sufficient privacy must be guaranteed, so a method is required to perform the advertising in a secure manner and to establish the ranging session based on it. In this case, the address included in ADV_POLL (i.e., the advertiser's address) may be configured in a form similar to a private MAC address. Furthermore, ADV_POLL (or a portion of it) may be encrypted in a specific manner, and key provisioning or key exchange algorithms, such as public key infrastructure (PKI), may be used to ensure that only the intended advertiser and scanner can transmit and receive ADV_POLL while ensuring privacy.

[0718] Level 3 may be used to advertise ADV_POLL encrypted so that it is only available to a specific group of devices. Use cases include measuring the location and distance of surrounding devices and constructing a device map based on the distance measurements of multiple devices, such as between a personal smartphone and multiple smartphone family accessory devices identified through a pre-authentication process, or between a smartphone and home appliance devices identified through a pre-authentication process. In this case, sufficient privacy must be guaranteed, so that advertising is performed in a secure manner and ranging session setup is performed based on this. The address included in ADV_POLL (i.e., the advertiser's address) may be configured in a format similar to a private MAC address. Additionally, ADV_POLL (or some area within ADV_POLL) may be encrypted in a specific manner, and a key provisioning or key exchange algorithm, such as public key infrastructure (PKI), may be used to ensure that only the intended advertiser and scanner(s) can send and receive ADV_POLL while ensuring privacy.

[0719] The ADV-POLL packet format used for the aforementioned discovery / initialization can be defined as in Fig. 43 by applying a security level (SL).

[0720] FIG. 43 illustrates a poll packet format for private / public advertising based on security level according to the present disclosure.

[0721] Referring to FIG. 43, the ADV-POLL2 packet format for public advertising may include a Message ID field, a Security Level (SL) field, an Advertiser Address field, a Message Control field, and a Message Content field.

[0722] For example, the Message ID field may indicate that the packet is in ADV-POLL packet format (e.g., a value of "0x20", a value of "0x21") or in ADV-POLL2 packet format (e.g., a value of "0x23").

[0723] The security level field can be defined to indicate a security level as shown in Table 24 below.

[0724] Security Level Description Bit: 0 No security Bit: 1 Purpose of association with a single device (peer-to-peer) Bit: 2 Purpose of association with a group of devices Bit: 3 Reserved

[0725] The advertiser address field indicates the address of the advertiser, and if the address is specified / included in the header, the advertiser address field may be omitted.

[0726] If the value indicated by the security level field is 1 or 2 (i.e., level 2 or 3 as described above), a private address may be used as the advertiser address. That is, the advertiser address field may be composed of private address information and private salt information.

[0727] In this regard, an advertiser that broadcasts advertising packets and a scanner that scans them may have a pre-defined resolving list. The pre-defined resolving list may be used before any communication between the advertiser and the scanner (e.g., a two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging them mutually through an implementation-specific manner may be provided. For example, a table for the advertiser address resolving list may be pre-defined, and a method for commonly distributing the list may be used.

[0728] After two or more devices perform discovery through the advertising process and scanning process, address verification can be performed to check whether the discovery result is the same as the discovery result, such as during the session setup phase. The random address can be changed periodically by the advertiser, and the changed value can be generated based on the key pair in the analysis list. The private address can be composed of a private address and a private salt (e.g., AES-128-ECB(key=PublicAddress, data=(padding || PrivateSalt)).

[0729] Alternatively, if the value indicated by the security level field is 0 (i.e., in the case of level 1 described above), a public address or a random address may be used as the advertiser address. The public address corresponds to the address assigned to the device and may be based on a short address or an extended address. The random address may correspond to an address randomly generated by the advertiser to prevent the public address from being directly exposed, and the rules for generating the random address may be as follows.

[0730] For example, if the advertiser is a controller, the random address can be generated as an arbitrary short address, an arbitrary extended address, or another form of address. In this case, the controller can select a unique value from among the addresses used within the ranging area network (RAN).

[0731] When random addresses are used, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After discovery between devices is performed through the advertising / scanning process, the advertiser, which is the controller, manages the random address and can also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may change, so the address may no longer be used. Additionally, a resolving list, such as IRK, can be exchanged according to a trusted device verification procedure (e.g., mutual verification during a two-way handshake). In this case, resolving key pairs within the resolving list can be utilized to extract / store information, such as analyzable private addresses.

[0732] A message control field may be defined to set the message content that is subsequently placed. Each field of the message content distinguished by the message control field may be included or omitted.

[0733] For example, a message content format corresponding to "0x00" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL) and a supported setup version list field. Additionally, a message content format corresponding to "0x01" indicated by the message control field may be composed of a length field of a supported setup version list (SSVL), a supported setup version list field, an address type (AT) field, a random delay (RD) field, and an advertising data (AdvData) field.

[0734] The address type field indicates the address type applied to the advertising address and can be defined based on Table 23 described above.

[0735] The random delay field may be used by an advertiser to send an advertising packet, such as an ADV-POLL2 packet, and by a responder that receives an advertising packet, such as an ADV-POLL2 packet, during a two-way handshake process to determine a response time to an advertising packet, such as an ADV-RESP2 packet. In other words, the random delay field may be related to the response time of an advertising packet, such as an ADV-POLL2, and an advertising response packet, such as an ADV-RESP2, during a two-way handshake process.

[0736] When the value of the random delay field is 0, the responder can send a response packet immediately after receiving the advertising packet. When the value of the random delay field is not 0, the responder can defer and send a response packet (e.g., an ADV_RESP2 packet) by applying a random delay within a range based on the value (e.g., through a method such as a random delay backoff). For example, in a public advertising method, a random delay can be applied to avoid collisions of response packets in a congested environment with many potential responders. The value of the random delay field can be determined by a higher layer. For example, the unit of the value of the random delay field can be RSTU (ranging scheduling time unit), and can be set to a value optimized for the requirements of the application.

[0737] The advertising data field may contain information that the advertiser wishes to announce. For example, this field may include a list of services supported by the advertiser, and this information may be defined in various forms. For example, a method of defining / expressing a service in a form such as a UUID to uniquely represent the service may be applied. Additionally or alternatively, this field may include the advertiser's friendly name, device type, scheduling information such as the advertising interval, and vendor-specific data desired by the advertiser.

[0738] As described above, the advertising data field / format may be recursively structured based on a length-type-value format to include various types of information. For example, the advertising data format may be structured in the following order: Length field, first type field, first value field, ..., Length field, Nth type field, Nth value field. Alternatively, the advertising data field / format may be structured based on a type-length-value format. For example, the advertising data format may be structured in the following order: first type field, Length field, first value field, ..., Nth type field, Length field, Nth value field. Alternatively, the advertising data format may be in a format other than length-type-value or type-length-value (e.g., length + AdvData).

[0739] Additionally, assuming a packet air-time of 1ms for narrowband (NB), the advertising data field / format may not exceed the maximum size of a PDSU of 24 bytes minus other fields (e.g., SSVL, AT, RD, etc.).

[0740] Example 3-2

[0741] To support various advertising messages such as the above-mentioned secure / private or unsecured / public, advertising packets based on security mode can be configured and scanner operations can be defined accordingly.

[0742] Security modes can be defined as follows:

[0743] Mode 0: no security

[0744] Mode 1: For association with a single device (peer-to-peer) or with a group of devices.

[0745] Mode 0, similar to Level 1 of Example 1-1, may be used to advertise ADV_POLL to an unspecified number of people. In use cases such as access control in public places and payment for public transportation, ADV_POLL is required to be easily transmitted and interpreted by an unspecified number of people, rather than supporting privacy, to effectively support ranging session setup. In this case, ADV_POLL may be unencrypted, and any scanner / responder can obtain the ADV_POLL and perform ranging session setup through a two-way handshake operation.

[0746] Mode 1 may correspond to a case where ADV_POLL is advertised encrypted so that it is only acquired by one device / group of devices, similar to Level 2 and / or Level 3 of Embodiment 1-1. For example, use cases may be considered, such as measuring the location and distance of surrounding device(s) based on distance measurements of (multiple) devices through ranging session setup between a personal smartphone and a smartphone family accessory device(s) identified through a pre-authentication method, or between a smartphone and a home appliance device(s) identified through a pre-authentication method, and constructing a device map. In this case, sufficient privacy needs to be guaranteed, so that advertising is performed in a secure manner and ranging session setup is performed based on the advertising. The address included in ADV_POLL (i.e., the address of the advertiser) may be configured in a form such as a private MAC address. Additionally, ADV_POLL (or some area within ADV_POLL) may be encrypted in a specific manner, and a key provisioning or key exchange algorithm, such as public key infrastructure (PKI), may be used to ensure that only the intended advertiser and scanner(s) can send and receive ADV_POLL while ensuring privacy.

[0747] The ADV-POLL packet format used for the aforementioned discovery / initialization can be defined as in FIG. 44 by applying the security mode (SM).

[0748] FIG. 44 illustrates a poll packet format for private / public advertising based on a security mode according to the present disclosure.

[0749] Referring to FIG. 44, the ADV-POLL2 packet format for public advertising may include a Message ID field, a Security Mode (SM) field, an Advertiser Address field, a Message Control field, and a Message Content field.

[0750] Except for the security mode field and the advertiser address field, other fields are the same as in the packet format illustrated in FIG. 43, and therefore, a detailed description of the fields is omitted in the description of FIG. 44.

[0751] The security mode field can be defined to indicate the security mode as shown in Table 25 below.

[0752] Security Mode Description 0 No security 1 Intended for use with a single device (peer-to-peer) or association with a group of devices

[0753] The advertiser address field indicates the address of the advertiser, and if the address is specified / included in the header, the advertiser address field may be omitted.

[0754] When the security mode is 1, a private address can be used as an advertiser address. That is, the advertiser address field can be composed of private address information and private salt information.

[0755] In this regard, an advertiser that broadcasts advertising packets and a scanner that scans them may have a pre-defined resolving list. The pre-defined resolving list may be used before any communication between the advertiser and the scanner (e.g., a two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging them mutually through an implementation-specific manner may be provided. For example, a table for the advertiser address resolving list may be pre-defined, and a method for commonly distributing the list may be used.

[0756] After two or more devices perform discovery through the advertising process and scanning process, address verification can be performed to check whether the discovery result is the same as the discovery result, such as during the session setup phase. The random address can be changed periodically by the advertiser, and the changed value can be generated based on the key pair in the analysis list. The private address can be composed of a private address and a private salt (e.g., AES-128-ECB(key=PublicAddress, data=(padding || PrivateSalt)).

[0757] Alternatively, when the security mode is set to 0, a public address or a random address can be used as the advertiser address. The public address corresponds to the address assigned to the device and may be based on a short address or an extended address. The random address may correspond to an address randomly generated by the advertiser to prevent direct exposure of the public address. The rules for generating the random address may be as follows.

[0758] For example, if the advertiser is a controller, the random address can be generated as an arbitrary short address, an arbitrary extended address, or another form of address. In this case, the controller can select a unique value from among the addresses used within the ranging area network (RAN).

[0759] When random addresses are used, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After discovery between devices is performed through the advertising / scanning process, the advertiser, which is the controller, manages the random address and can also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may change, so the address may no longer be used. Additionally, a resolving list, such as IRK, can be exchanged according to a trusted device verification procedure (e.g., mutual verification during a two-way handshake). In this case, resolving key pairs within the resolving list can be utilized to extract / store information, such as analyzable private addresses.

[0760] The security level (SL) and security mode (SM) in this embodiment can also be applied to advertising poll packets of various formats described above in this disclosure (i.e., the formats of FIGS. 35, 38, 39, 40, 41, and 42).

[0761] Additionally, rather than distinguishing the security type by including a security level field or a security mode field within the same message, the format of the advertising poll packet may be assigned / applied based on the security level or security mode.

[0762] For example, for security levels 1, 2, and 3 (i.e., values ​​0, 1, and 2 of the security level field), an ADV-POLL packet format (e.g., the format of FIG. 32), an ADV-POLL2 packet format (e.g., the formats of FIGS. 35, 38, 39, 40, 41, and 42), and an ADV-POLL2 packet format (e.g., the formats of FIGS. 35, 38, 39, 40, 41, and 42) may be provided. Alternatively, the ADV-POLL packet format (e.g., the format of FIG. 32) may be granted for security level 1 (i.e., the value 0 of the security level field), and the ADV-POLL2 packet format (e.g., the formats of FIGS. 35, 38, 39, 40, 41, and 42) may be granted for security level 2 or 3 (i.e., the value 1 or 2 of the security level field). In addition, the ADV-POLL packet format (e.g., the format of FIG. 32) and the ADV-POLL2 packet format (e.g., the formats of FIGS. 35, 38, 39, 40, 41, and 42) may be granted for security modes 0 and 1.

[0763] Security levels or security modes can be specified / assigned through applications, etc., and depending on the security level or security mode value, the controller can determine whether to perform private advertising or public advertising. In this regard, a scanner receiving advertising packets can select the appropriate ones (i.e., packets in a manner deemed appropriate between private advertising and public advertising) based on the security level or security mode value.

[0764] Additionally, in the examples described in this disclosure, each field included in the message content may be omitted or included.

[0765] Example 4

[0766] This embodiment relates to various frame formats (or packet formats) depending on whether a public address is used for poll frames, response frames, and report frames transmitted or received in an MMS ranging operation (i.e., a ranging session after initialization / session setup through an advertising operation).

[0767] Whether a public address or a private address is used may be distinguished by the message ID (or frame identifier), by the address type, or by the same message ID (or frame identifier) ​​and subtype (or extended ID).

[0768] Example 4-1

[0769] This embodiment relates to a method for distinguishing between a frame format using a public address and a frame format using a private address by a message ID (or frame identifier).

[0770] For example, after the advertiser and scanner / responder establish a session during the MMS initialization and session setup phase (e.g., after the public advertising poll frame, public advertising response frame, and public SOR frame exchange phase is completed), during the ranging phase, the initiator and responder may exchange public-poll frames, public-response frames, and public-reporting initiator / responder frames.

[0771] FIG. 45 is a diagram illustrating an example of a method for distinguishing frames by ID in a ranging operation according to the present disclosure. For example, the messages / frames in FIG. 45 may correspond to SS-TWR NBA-UWB MMS public messages / frames, and the value of the message control field may be set to 0x00 (e.g., corresponding to unencrypted SS-TWR NBA-UWB MMS, version 0). For example, a public-poll frame and a non-public (e.g., private) poll frame may correspond to different message ID (frame identifier) ​​values. For example, a public-response frame and a non-public (e.g., private) response frame may correspond to different message ID (frame identifier) ​​values. For example, a public-report initiator / responder frame and a non-public (e.g., private) report initiator / responder frame may correspond to different message ID (frame identifier) ​​values.

[0772] The address field may include the address and address type of the advertiser. The address field may be divided into a source address and a destination address. The source address and destination address may be an address pair of the counterparty's address and its own address exchanged during the two-way handshake process between the advertiser / initiator and the scanner / responder during the MMS initialization and setup process. The address pair may be temporarily managed by the initiator. The address size may be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / type (e.g., 3 octets).

[0773] FIG. 46 is a diagram illustrating exemplary formats of a public-poll frame, a public-response frame, and a public-report frame according to the present disclosure.

[0774] Figure 46(a) shows an example of the packet format of a public-poll frame (e.g., message control = 0x00).

[0775] The Message ID (or Frame Identifier) ​​field is 1 octet in size and may be set to a value indicating a public-poll frame.

[0776] The Source Address (SrcAddr) field may be set to the initiator's address value. If the source address is specified in the header, the source address field may be omitted in the example frame format.

[0777] The DestAddr field may be set to the responder's address value. If the destination address is specified in the header, the destination address field may be omitted in the frame format example.

[0778] The source and destination addresses can be configured as address pairs established between the advertiser / initiator and the scanner / responder during the session setup process. The source and destination addresses can also be managed by the initiator. The address size can be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / format (e.g., 3 octets).

[0779] The message control field may be set to a value indicating the subsequent message content.

[0780] For example, fields to be included or omitted from the message content may be distinguished based on the value of the message control field. For example, if the value of the message control field is 0x00, the message content field may include two bytes of 0x00 and 0x00 for CFO removal.

[0781] The CRC16 field can be 2 bytes in size.

[0782] All of the fields described in the format of the public-poll frame described above may be included, or some may be omitted depending on the purpose.

[0783] Figure 46(b) shows an example of the packet format of a public-response frame (e.g., message control = 0x00).

[0784] The Message ID (or Frame Identifier) ​​field is 1 octet in size and may be set to a value indicating a public-response frame.

[0785] The Source Address (SrcAddr) field may be set to the responder's address value. If the source address is specified in the header, the Source Address field may be omitted in the example frame format.

[0786] The DestAddr field may be set to the initiator's address value. If the destination address is specified in the header, the destination address field may be omitted in the example frame format.

[0787] The source and destination addresses can be configured as address pairs determined between the advertiser / initiator and the scanner / responder during the session setup process. The source and destination addresses can also be managed by the initiator. The address size can be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / format (e.g., 3 octets).

[0788] The message control field may be set to a value indicating the subsequent message content.

[0789] For example, fields to be included or omitted in the message content may be distinguished based on the value of the message control field. For example, if the value of the message control field is 0x00, the message content field may include 5 bytes of 0x00, 0x00, 0x00, 0x00, 0x00 for CFO removal.

[0790] The CRC16 field can be 2 octets in size.

[0791] All of the fields described in the format of the public-response frame described above may be included, or some may be omitted depending on the purpose.

[0792] Figure 46(c) shows an example of the packet format of a public-report initiator frame (e.g., message control = 0x00).

[0793] The Message ID (or Frame Identifier) ​​field is 1 octet in size and may be set to a value indicating a public-reporting initiator frame.

[0794] The Source Address (SrcAddr) field may be set to the initiator's address value. If the source address is specified in the header, the source address field may be omitted in the example frame format.

[0795] The DestAddr field may be set to the responder's address value. If the destination address is specified in the header, the destination address field may be omitted in the frame format example.

[0796] The source and destination addresses can be configured as address pairs determined between the advertiser / initiator and the scanner / responder during the session setup process. The source and destination addresses can also be managed by the initiator. The address size can be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / format (e.g., 3 octets).

[0797] The message control field may be set to a value indicating the subsequent message content.

[0798] For example, fields to be included or omitted in the message content may be distinguished depending on the value of the message control field. For example, if the value of the message control field is 0x00, the message content field may include a 5-byte round trip time (RTT) field, a 1-byte pass-through (PT) length field, and a PT data field with a length corresponding to the value of the PT length field. Data may be stored in a piggyback manner in the PT length field and the PT data field.

[0799] The CRC16 field can be 2 bytes in size.

[0800] All of the fields described in the format of the public-report initiator frame described above may be included, or some may be omitted depending on the purpose.

[0801] Figure 46(d) shows an example of the packet format of a public-report responder frame (e.g., message control = 0x00).

[0802] The Message ID (or Frame Identifier) ​​field is 1 octet in size and may be set to a value indicating a public-reporting responder frame.

[0803] The Source Address (SrcAddr) field may be set to the responder's address value. If the source address is specified in the header, the Source Address field may be omitted in the example frame format.

[0804] The DestAddr field may be set to the initiator's address value. If the destination address is specified in the header, the destination address field may be omitted in the example frame format.

[0805] The source and destination addresses can be configured as address pairs determined between the advertiser / initiator and the scanner / responder during the session setup process. The source and destination addresses can also be managed by the initiator. The address size can be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / format (e.g., 3 octets).

[0806] The message control field may be set to a value indicating the subsequent message content.

[0807] For example, fields to be included or omitted in the message content may be distinguished depending on the value of the message control field. For example, if the value of the message control field is 0x00, the message content field may include a 5-byte turn-around time (TAT) field, a 1-byte pass-through (PT) length field, and a PT data field with a length corresponding to the value of the PT length field. Data may be stored in a piggyback manner in the PT length field and the PT data field.

[0808] The CRC16 field can be 2 bytes in size.

[0809] All of the fields described in the format of the public-reporting respondent frame described above may be included, or some may be omitted depending on the intended use.

[0810] Example 4-2

[0811] This embodiment is about a method for distinguishing between a frame format using a public address and a frame format using a private address by applying an address type by message ID (or frame identifier).

[0812] For example, after the advertiser and scanner / responder establish a session during the MMS initialization and session setup phase (e.g., after completing the exchange phase of advertising poll frames, advertising response frames, and SOR frames), during the phase of performing operations such as ranging, the initiator and responder may exchange poll frames, response frames, and reporting initiator / responder frames.

[0813] FIG. 47 is a diagram illustrating an example of a method for distinguishing frames by address type in a ranging operation according to the present disclosure. For example, the messages / frames in FIG. 47 may correspond to SS-TWR NBA-UWB MMS messages / frames, and the value of the message control field may be set to 0x00 (e.g., corresponding to unencrypted SS-TWR NBA-UWB MMS, version 0). For example, a public-poll frame and a non-public (e.g., private) poll frame may correspond to the same message ID (frame identifier) ​​value. For example, a public-response frame and a non-public (e.g., private) response frame may correspond to the same message ID (frame identifier) ​​value. For example, a public-report initiator / responder frame and a non-public (e.g., private) report initiator / responder frame may correspond to the same message ID (frame identifier) ​​value.

[0814] The address field may include the advertiser's address and address type. If the address type is included, it may include information that distinguishes between privacy-protected addresses, public addresses, random addresses, etc. If the address is privacy-protected, RPA may be used, and a Prand (pseudo random) field may also be included in the address field for poll frames. If the address is not privacy-protected, the address pair of the counterparty's address and its own address exchanged between the advertiser / initiator and the scanner / responder during MMS initialization and setup may be included as the source address and destination address. The address size may be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / type (e.g., 3 octets).

[0815] FIG. 48 is a diagram showing exemplary formats of a poll frame, a response frame, and a report frame according to the present disclosure.

[0816] Figure 48(a) shows an example of a packet format of a poll frame (e.g., message control = 0x00).

[0817] The Message ID (or Frame Identifier) ​​field is 1 octet in size and can be set to a value indicating a poll frame.

[0818] The AT (address type) field is 1 octet in size and can be set to a value that distinguishes an address type such as a privacy-protected address, a public address, or a random address. The address type may indicate a privacy-protected address if the value of bits 0-1 is 0, a public address if the value is 1, a random address if the value is 2, and bits 2-7 may be reserved. The scope of the present disclosure is not limited to these examples, and the address type may be defined in other ways. Two bits out of one octet of the AT field are used to indicate the address type, and the remaining bits may be used for other purposes such as content control.

[0819] The address field may contain the address of the advertiser / initiator. If the address type is a privacy-protected address, RPA and PRAND may be included together in the address field. If the address type is not a privacy-protected address, the address field may contain a source address and a destination address. In this case, the source address may be set to the initiator's address, and the destination address may be set to the responder's address. The source address and destination address may be composed of an address pair determined between the advertiser / initiator and the scanner / responder during the session setup process. The source address and destination address may also be managed by the initiator. The address size may be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / type (e.g., 3 octets).

[0820] The message control field, message content field, and CRC16 field can be set identically to the corresponding fields in Fig. 46(a).

[0821] All of the fields described in the format of the aforementioned poll frame may be included, or some may be omitted depending on the purpose.

[0822] Figure 48(b) shows an example of the packet format of a response frame (e.g., message control = 0x00).

[0823] The Message ID (or Frame Identifier) ​​field is 1 octet in size and can be set to a value indicating a response frame.

[0824] The AT (address type) field is identical to the description of the AT field in Figure 48(a).

[0825] The address field may contain the address of the advertiser / initiator. If the address type is a privacy-protected address, RPA may be used in the address field. If the address type is not a privacy-protected address, the address field may contain a source address and a destination address. In this case, the source address may be set to the address of the responder, and the destination address may be set to the address of the initiator. The source address and destination address may be composed of an address pair determined between the advertiser / initiator and the scanner / responder during the session setup process. The source address and destination address may also be managed by the initiator. The address size may be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / type (e.g., 3 octets).

[0826] The message control field, message content field, and CRC16 field can be set identically to the corresponding fields in Fig. 46(b).

[0827] All of the fields described in the format of the response frame described above may be included, or some may be omitted depending on the purpose.

[0828] Figure 48(c) shows an example of the packet format of a report initiator frame (e.g., message control = 0x00).

[0829] The Message ID (or Frame Identifier) ​​field is 1 octet in size and may be set to a value indicating the reporting initiator frame.

[0830] The AT (address type) field is identical to the description of the AT field in Figure 48(a).

[0831] The address field may contain the address of the advertiser / initiator. If the address type is a privacy-protected address, RPA may be used in the address field. If the address type is not a privacy-protected address, the address field may contain a source address and a destination address. In this case, the source address may be set to the initiator's address, and the destination address may be set to the responder's address. The source address and destination address may be composed of an address pair determined between the advertiser / initiator and the scanner / responder during the session setup process. The source address and destination address may also be managed by the initiator. The address size may be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / type (e.g., 3 octets).

[0832] The message control field, message content field, and CRC16 field can be set identically to the corresponding fields in Fig. 46(c).

[0833] All of the fields described in the format of the aforementioned report initiator frame may be included, or some may be omitted depending on the purpose.

[0834] Figure 48(d) shows an example of the packet format of a report responder frame (e.g., message control = 0x00).

[0835] The Message ID (or Frame Identifier) ​​field is 1 octet in size and may be set to a value indicating a Report Responder frame.

[0836] The AT (address type) field is identical to the description of the AT field in Figure 48(a).

[0837] The address field may contain the address of the advertiser / initiator. If the address type is a privacy-protected address, RPA may be used in the address field. If the address type is not a privacy-protected address, the address field may contain a source address and a destination address. In this case, the source address may be set to the address of the responder, and the destination address may be set to the address of the initiator. The source address and destination address may be composed of an address pair determined between the advertiser / initiator and the scanner / responder during the session setup process. The source address and destination address may also be managed by the initiator. The address size may be a short address (i.e., 2 octets), an extended address (i.e., 8 octets), or an address of a different size / type (e.g., 3 octets).

[0838] The message control field, message content field, and CRC16 field can be set identically to the corresponding fields in Fig. 46(d).

[0839] All of the fields described in the format of the aforementioned report respondent frame may be included, or some may be omitted depending on the purpose.

[0840] Example 4-3

[0841] This embodiment is about a method for distinguishing between a frame format using a public address and a frame format using a private address by subtype (or extended ID) for each message ID (or frame identifier).

[0842] For example, a public-poll frame and a non-public (e.g., private) poll frame may correspond to the same Message ID (frame identifier) ​​value but different subtype (or extended ID) values. For example, a public-response frame and a non-public (e.g., private) response frame may correspond to the same Message ID (frame identifier) ​​value but different subtype (or extended ID) values. For example, a public-report initiator / responder frame and a non-public (e.g., private) report initiator / responder frame may correspond to the same Message ID (frame identifier) ​​value but different subtype (or extended ID) values.

[0843] FIG. 49 is a diagram illustrating an example of a method for distinguishing frames by subtype according to the present disclosure. For example, the messages / frames in FIG. 49 may correspond to SS-TWR NBA-UWB MMS messages / frames, and the value of the message control field may be set to 0x00 (e.g., corresponds to unencrypted SS-TWR NBA-UWB MMS, version 0).

[0844] The Message ID (or Frame Identifier) ​​field is 1 octet in size and may be set to a value indicating a poll frame, a response frame, or a report initiator / responder frame.

[0845] The subtype (or extended ID) field is 1 octet in size and can be set to a value representing either a private or public type.

[0846] For fields of the poll frame, response frame, and report initiator / responder frame corresponding to the private subtype or corresponding to the public subtype, the descriptions for those fields in the examples described above may be applied.

[0847] Example 4-4

[0848] In the examples described above, for the advertising poll frame, the advertising response frame, the SOR frame, the poll frame in the ranging session, the response frame in the ranging session, the report initiator frame in the ranging session, and the report responder frame in the ranging session, examples of defining and distinguishing between public purposes / types and non-public (e.g., private) purposes / types are described, for example, by message ID (or frame identifier), by address type, and by subtype (or extended ID).

[0849] These examples can be applied to the use of public addresses not only for the aforementioned messages / frames, but also for other messages using privacy-protected addresses related to NBA-UWB MMS. For example, advertising confirmation (ADV-CONF), POLL-SPN (short-term parameters for next ranging cycle), RESP-SPN, one-to-many POLL, one-to-many RESP, REPORT-SPN from responder, REPORT on one-to-many ranging from responder, REPORT on one-to-many ranging from initiator, etc. (and also for newly defined messages for public initiation / session setup and session operation for messages using privacy-protected addresses defined in the future related to NBA-UWB MMS), the same examples of distinguishing by message ID (or frame identifier), by address type, and by subtype (or extended ID) can be equally applied as a way to define and distinguish between private and public formats / types.

[0850] For example, the advertising confirmation (ADV-CONF) message can be defined and used to defer SOR transmission. Specifically, when coordination is enabled, the initiator can determine ranging session setup based on UWB channel usage information that can be determined from acquisition packets (APs) from other initiators. For coordination, the initiator can scan the NB's initialization channel and the UWB default channel before transmitting the SOR. In order to perform scanning for coordination, it is necessary to defer the SOR transmission, and for this purpose, the initiator can transmit ADV-CONF after receiving ADV-RESP, and the ADV-CONF can include information about the time offset between the ADV-CONF packet and the start of the SOR packet.

[0851] These ADV-CONF frames may be defined as public ADV-CONF frames (e.g., public advertising confirmation compact frame) and non-public (i.e., private) ADV-CONF frames (e.g., advertising confirmation compact frame).

[0852] For example, a public ADV-CONF frame and a non-public (i.e., private) ADV-CONF frame may correspond to different message ID (frame identifier) ​​values. For example, an ADV-CONF frame with a public ADV-CONF frame identifier value may include an Advertiser Address field that is set to a public address value randomly generated by the advertiser. For example, an ADV-CONF frame with a non-public ADV-CONF frame identifier value may include an RPA hash field.

[0853] Alternatively, a public ADV-CONF frame and a non-public (i.e., private) ADV-CONF frame may correspond to the same message ID (frame identifier) ​​value and include an address type field. For example, if the address type field indicates a private address, the ADV-CONF frame may include an RPA hash field. For example, if the address type field indicates a public address, the ADV-CONF frame may include an advertiser address field that is set to a public address value randomly generated by the advertiser.

[0854] Alternatively, a public ADV-CONF frame and a non-public (i.e., private) ADV-CONF frame may correspond to the same message ID (frame identifier) ​​value and different subtypes (or extended IDs). For example, if the subtype field indicates a private type, the ADV-CONF frame may include an RPA hash field. For example, if the subtype field indicates a public type, the ADV-CONF frame may include an advertiser address field that is set to a public address value randomly generated by the advertiser.

[0855] Example 5

[0856] In this embodiment, examples of discovery / initialization and setup operations based on secure / private advertising packets or unsecured / public advertising packets defined in Embodiments 1 to 4, and ranging operations after session setup are described.

[0857] FIG. 50 illustrates an example of finding a peripheral device based on secure advertising according to the present disclosure.

[0858] When broadcasting advertising packets to find personal devices and peripheral devices owned by individuals, or to find friends, protecting personal information may be required, so secure advertising may be applied. In this case, if an unspecified number of people can receive and interpret the advertising packets, information such as the personal device's MAC address and session setup information, which can be considered a fingerprint, may be exposed. To prevent this, secure advertising may be applied.

[0859] The example in Fig. 50 is an example of a procedure for finding a smartphone and nearby devices or finding nearby friends using secure advertising.

[0860] Referring to FIG. 50, a user device (e.g., a smartphone), a known private device 1 (e.g., earbuds), and a known private device 2 (e.g., a laptop) are illustrated.

[0861] Smartphones can broadcast secure advertising packets on NB / UWB discovery channels.

[0862] The earbuds can scan NB / UWB discovery channels, receive advertising packets, and use IRK and prand to interpret the advertising packets to establish a ranging session. This allows the ranging (e.g., distance) and direction between the smartphone and the earbuds to be measured.

[0863] The laptop can scan NB / UWB discovery channels, receive advertising packets, and use IRK and prand to interpret the advertising packets to establish a ranging session. This allows the ranging (e.g., distance) and direction between the smartphone and laptop to be measured.

[0864] That is, as mentioned above, the known private devices, the laptop and the earbuds, can scan the NB / UWB discovery channel, find the secure advertising packet, and interpret the private MAC address using information such as IRK and prand.

[0865] Accordingly, a known peripheral device can perform a ranging session setup according to a two-way handshake procedure after discovering an advertising packet, measure ranging and AOA (angle of arrival), etc. to determine the distance and direction, and inform the user of the location of the smartphone and peripheral device.

[0866] An unknown user device attempts to scan on the NB / UWB channel, but cannot establish a ranging session with the smartphone because it cannot find a valid address in the advertising packet.

[0867] In the example of Figure 50, the advertising packet broadcast by the smartphone may include the following information:

[0868] Field Content Description Frame ID ADV-POLL Indicates that this is an advertising packet Protocol Version IEEE 802.15.4ab-2024 The protocol version is 4ab Security Mode 1 Usage for association with a single device (peer-to-peer) or a group of devices RDP 0 No random delay applied Secure Information Information related to secure advertising Private MAC address (generated using IRK and prand) CRCCRC-

[0869] FIG. 51 illustrates an example of access control of multiple devices based on insecure advertising according to the present disclosure.

[0870] The example in Figure 51 is an example of a procedure for controlling access of an unspecified number of customers visiting a public place (e.g., a hospital, a bus fare payment place, etc.) by using insecure advertising.

[0871] Devices installed in public locations (e.g., main controller devices installed in hospitals) can broadcast insecure advertising packets containing their public MAC addresses on NB / UWB discovery channels.

[0872] Among an unspecified number of unknown user devices, when a user (e.g., Mr. LEE) enters a hospital with a smartphone, the customer's smartphone can scan the NB / UWB discovery channel. The customer's smartphone can detect an unsecured advertising packet on the NB / UWB discovery channel and establish a ranging session with the hospital's main controller device.

[0873] Accordingly, based on the ranging and AOA measurement results between the hospital's main controller device and the customer's smartphone, the hospital's main controller device can determine additional information about the customer who owns the smartphone, and based on this, determine that the customer (i.e., Mr. Lee) has entered the hospital.

[0874] To this end, the advertising packet broadcast by the main controller device may contain the following information:

[0875] Field Content Description Frame ID ADV-POLL Indicates that this is an advertising packet Protocol Version IEEE 802.15.4ab-2024 The protocol version is 4ab Security Mode 0 No security RDP 1 Random Delay Applied Random Delay 500 A random value less than or equal to 500 RSTU is applied as the response time to the advertising packet ADV Data Advertising Data Service ID (e.g., access control to public places) CRCCRC-

[0876] FIG. 52 illustrates an example of a purchasing process via an arbitrary device based on unsecured advertising according to the present disclosure.

[0877] The example in Figure 52 is an example of a process for mobile payments (e.g., payment for goods in a store) by an unspecified number of customers using unsecured advertising.

[0878] Point of sale (POS) devices installed in stores can broadcast unsecured advertising packets on NB / UWB discovery channels.

[0879] One customer among a large number of customers may run a payment app on their smartphone. The app scans the smartphone to detect advertising packets, and a ranging session is set up between the POS device and the smartphone. This allows the ranging to be measured, and if the distance is less than 1 meter, the payment can be processed. In other words, if the distance between the customer's device and the POS device is less than 1 meter, payment information for the product recognized by the POS device can be transmitted to the payment app on the customer's smartphone. Once the customer confirms the payment information and finalizes the payment, the payment can proceed.

[0880] To this end, the advertising packet broadcast by the POS device may contain the following information:

[0881] Field Content Description Frame ID ADV-POLL Indicates that this is an advertising packet Protocol Version IEEE 802.15.4ab-2024 The protocol version is 4ab Security Mode 0 No security RDP 1 Random Delay Applied Random Delay 200 A random value less than 200 RSTU is applied as the response time to the advertising packet ADV Data Advertising Data Service ID (e.g., mobile payment) CRCCRC-

[0882] Examples in Tables 26 to 28 illustrate a case where the frame ID of the advertising poll frame is set to ADV-POLL and the security mode field indicates that it is a private or public advertising packet. However, the frame ID field in Table 26 may be set to ADV-POLL (i.e., a value indicating that it is a private advertising packet), and the frame ID fields in Tables 27 and 28 may be set to ADV-POLL2 (i.e., a value indicating that it is a public advertising packet).

[0883] In the various examples of the present disclosure described above, in the native discovery / initialization and setup procedures for NBA-MMS-UWB, a secure / private or unsecured / public advertising scheme related to a security level / mode can be defined and applied. That is, according to the present disclosure, in relation to the advertising process for an advertiser to announce itself for discovery / initialization, the scanning process for a scanner to discover the advertiser, and the procedure for establishing a ranging session setup after discovery, privacy-ensuring advertising or public advertising can be appropriately applied to the situation, so that efficient discovery / initialization and setup can be supported only with in-band UWB.

[0884] Format of the Advertising Data (AdvData) field

[0885] In the examples of FIGS. 40, 41, 43, and 44 described above, additional examples of the present disclosure regarding the format of the advertising data (AdvData) field are described below.

[0886] The AdvData field can have a type-length-value (TLV) format, a length-type-value (LTV) format, or a length-value (LV) format to contain various types of information.

[0887] For example, the Advertising Data (AdvData) field can be defined in the following format:

[0888] AdvData = {Length, [AD Structure #1, AD Structure #2, ..., AD Structure #N]}

[0889] Length can indicate the total length of the entire advertising data content. The advertising data content can include AD Structure(s) of a length corresponding to Legnth (or N). When the AdvData field is included in a compact frame such as the public advertising poll frame described below, the presence of a variable-length field and the length of the variable-length field can be indicated / determined based on the frame length field included in the PHY header of a PPDU such as Q-QPSK, which can correspond to the format of a compressed PSDU, and the Length field in the Adv Data field.

[0890] When multiple AD Structures are included, each AD Structure may be defined in TLV format. For example, the nth AD Structure (AD structure #n) may be defined in the following TLV format.

[0891] AD Structure #n = {Type[n], Length[n], Value[n]}

[0892] The Type field and Length field are each defined as having a size of 1 octet, and the Value field can be defined as having a variable size.

[0893] Alternatively, the Advertising Data (AdvData) field may be defined in the following format:

[0894] AdvData = {AD Structure #1, AD Structure #2, ..., AD Structure #N}

[0895] When multiple AD Structures are included, each AD Structure may be defined in LTV format. A Length value of 0 for an AD Structure may indicate that the iteration has ended for that AD Structure.

[0896] For example, the nth AD structure (AD structure #n) can be defined in the following LTV format.

[0897] AD Structure #n = {Length[n], Type[n], Value[n]}

[0898] The Length field and the Type field are each defined as having a size of 1 octet, and the Value field may be defined as having a variable size. That is, unlike the example described above, this example may not include the Length field, which corresponds to the length of the entire advertising data content.

[0899] In the examples described above, the Type field can be defined to indicate / specify the type of advertising data content, such as service representation, friendly name, advertising interval, vendor specific information, etc.

[0900] As another example, the Advertising Data (AdvData) field may be defined in LV format.

[0901] For example, the format of the Adv Data field may include a 1-octet Advertising Data Length field and a variable-length Advertising Data Value (or Advertising Data Content) field. The Advertising Data Length field may indicate the number of octets contained in the Advertising Data Value (or Content) field. The Advertising Data Value (or Content) field may contain various data of variable length (i.e., a length corresponding to the value of the Advertising Data Length field) determined by the upper application layer of the initiator. The various data may include a service representation, a friendly name, vendor-specific information, etc., announced by the initiator. When an AdvData field is included in a compact frame such as a public advertising poll frame described below, the presence of a variable-length field and the length of the variable-length field can be indicated / determined based on a frame length field included in a PHY header of a PPDU such as Q-QPSK, which may correspond to the format of a compressed PSDU, and a Length field in the Adv Data field.

[0902] As an additional example of the PUBLIC-ADV-POLL examples described above, it can also be defined in the form of a compressed PSDU or compact frame. This requires specifying the entire format of the advertising poll frame, including the address. Furthermore, the message content can be structured in various formats depending on the value of the message control field.

[0903] Additionally, a response frame to a public advertising poll compact frame may have the format of a public advertising response compact frame.

[0904] Figure 53 shows examples of compact frame related formats to which the present disclosure can be applied.

[0905] Figure 53(a) illustrates the format of a typical compact frame. This format can be commonly applied to various compact frames, including public advertising poll frames in the form of compact frames.

[0906] The value of the compact frame ID field of a public advertising poll frame in the form of a compact frame may be, for example, 12. In this case, the compact frame content field of the public advertising poll frame may have a format as shown in FIG. 53(b).

[0907] For example, the value of the message control field can be defined as 0x00, 0x10, 0x20, 0x21, 0x30, etc. When the value of the message control field is 0x00, the message content field can be empty. Fig. 53(c) shows an exemplary format of the message content field when the value of the message control field is 0x10. Fig. 53(d) shows an exemplary format of the message content field when the value of the message control field is 0x20. Fig. 53(e) shows an exemplary format of the message content field when the value of the message control field is 0x21. Fig. 53(f) shows an exemplary format of the message content field when the value of the message control field is 0x30.

[0908] As described above, various formats of frames containing Adv Data fields can be defined, and a specific format of the Adv Data field can be defined for each format. Furthermore, in cases where variable-length fields (e.g., the Adv Data field and the SMC TLVs field) are arranged consecutively within a frame, a method for distinguishing the variable-length fields from each other may be required.

[0909] In the case of a single variable-length field, the presence of the variable-length field and the length of the variable-length field can be obtained based on a frame length field included in a PHY header of a PPDU, such as Q-QPSK, which may correspond to the format of a compressed PSDU. If there are multiple variable-length fields in the frame, or they can be arranged consecutively and may be omitted, it may be difficult to distinguish the variable-length fields from each other, which may cause ambiguity in decoding. To solve this problem, examples of the present disclosure that specify the Adv Data format are described below.

[0910] In the examples of FIG. 53(e) and FIG. 53(f), two variable-length fields, an SMC TLVs field and an Adv Data field, can be included in a single frame. The two fields may or may not be used, and the use of each field may be independent of each other. If not used, the field(s) may be omitted (i.e., the length may be 0 octets). If a field is omitted, it may be difficult to distinguish between the two fields or indicate / determine the length of a field based solely on the frame length field of the PHY header.

[0911] FIG. 54 is a diagram showing examples of advertising data field formats according to the present disclosure.

[0912] The example of Fig. 54(a) shows a case where the Adv Data field of Fig. 53(e) is defined in LV format, and the example of Fig. 54(b) shows a case where the Adv Data field of Fig. 53(f) is defined in LV format. Furthermore, these examples show a case where the Adv Data field is placed before other variable-length fields (e.g., SMC TLVs).

[0913] Accordingly, the location / time point where Adv Data (i.e., advertising data content) ends can be clearly indicated / determined from the value of the Adv Data length field.

[0914] FIG. 55 is a diagram illustrating other examples of advertising data field formats according to the present disclosure.

[0915] The example of Fig. 55(a) illustrates a case where the Adv Data field of Fig. 53(e) is placed in front of another variable-length field (e.g., the SMC TLVs field) and an Adv Data presence field is added. The example of Fig. 55(b) illustrates a case where the Adv Data field of Fig. 53(f) is placed in front of another variable-length field (e.g., the SMC TLVs field) and an Adv Data presence field is added.

[0916] If the value of the Adv Data presence field is 0, it may indicate that another variable-length field other than the Adv Data field (e.g., the SMC TLVs field) exists immediately following the octets of the presence field.

[0917] If the value of the Adv Data presence field is 1, it can be indicated / determined that the Adv Data field is present immediately following the octets of the presence field. In this case, if the Adv Data field is defined in LV format, the length of the entire Adv Data field (e.g., including the advertising data content) can be indicated / determined based on the value of the Adv Data Length field. Accordingly, it can be indicated / determined that another variable-length field (e.g., the SMC TLVs field) is present following the entire length of the Adv Data field.

[0918] FIG. 56 is a diagram illustrating other examples of advertising data field formats according to the present disclosure.

[0919] Figure 56 shows examples of defining presence fields that explicitly indicate the presence or absence of variable length fields.

[0920] For example, the example of Fig. 56(a) shows a case where the SMC TLVs presence field is added after the Adv Data presence field of Fig. 55(a). The example of Fig. 56(b) shows a case where the SMC TLVs presence field is added after the Adv Data presence field of Fig. 55(b). If another variable-length field can be included, a presence field can be defined for each of all variable-length fields. Accordingly, the decoding complexity of the responder can be reduced.

[0921] Although the examples described above assume the SMC TLVs field as an example of a variable-length field other than the Adv Data field, the examples of the present disclosure can be equally applied to a case where other variable-length fields other than the SMC TLVs field can be included in a frame together with the Adv Data field. When multiple variable-length fields are included in a frame, the multiple variable-length fields can all be located at the last part of the frame. A length field and / or presence field associated with each variable-length field can also be included in the frame. When the PHY header includes a field indicating the length of the entire frame (e.g., a frame length field), the length and / or presence field for the variable-length field located at the very end of the frame may be omitted.

[0922] In the examples of the present disclosure described above, when a format is defined in which a plurality of variable-length fields can be included in one frame, a length field may be defined for a first variable-length field (e.g., an Adv Data field) positioned in front, and a presence field may be defined for a second variable-length field (e.g., an SMC TLVs field) positioned behind (or at the end). Alternatively, a presence field may be defined for a first variable-length field (e.g., an Adv Data field) positioned in front, and a presence field may be defined for a second variable-length field (e.g., an SMC TLVs field) positioned behind (or at the end). Alternatively, a length field may be defined for a first variable-length field (e.g., an Adv Data field) positioned in front, and a length field may be defined for a second variable-length field (e.g., an SMC TLVs field) positioned behind (or at the end). Alternatively, a presence field may be defined for a first variable length field (e.g., an Adv Data field) positioned ahead, and a length field may be defined for a second variable length field (e.g., an SMC TLVs field) positioned after (or at the end). Alternatively, a length field and presence field may be defined for a first variable length field (e.g., an Adv Data field) positioned ahead, and a presence field and length field may be defined for a second variable length field (e.g., an SMC TLVs field) positioned after (or at the end).

[0923] 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.

[0924] 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 thereof. 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.

[0925] 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.

[0926] 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 transmitting, by a first device, a first frame including a first variable-length field to a second device; and A step of receiving, by the first device, a second frame in response to the first frame from the second device, Based on the first frame additionally including a second variable-length field, the first variable-length field is positioned consecutively with the second variable-length field within the first frame, A method, wherein the first variable-length field comprises a first length field and a first content field.

2. In paragraph 1, The first length field indicates the number of octets included in the first content field, A method wherein the first length field is defined as having a size of 1 octet.

3. In paragraph 1, A method, wherein the first variable-length field and the second variable-length field are included within a message content field of the first frame.

4. In paragraph 3, A method wherein the second variable-length field is located at the end of the message content field.

5. In paragraph 3, A method wherein the message content field includes a bit indicating the presence or absence of a second variable-length field.

6. In paragraph 5, A method wherein the bit indicating the presence or absence of the second variable-length field is positioned before the first variable-length field and the second variable-length field in the message content field.

7. In paragraph 3, A method wherein the length of the second variable-length field is based on the value of the frame length field included in the physical layer (PHY) header of a PPDU ((physical layer protocol data unit)) including the first frame.

8. In paragraph 3, A method according to claim 1, wherein the message content field further includes an initialization slot duration field, a cap duration field, and a group ID field.

9. In paragraph 1, The above first frame is a public advertising pole compact frame, A method wherein the second frame is a public advertising response compact frame.

10. In paragraph 1, The above first variable-length field is an advertising data field, A method wherein the second variable-length field is an SMC TLVs (supported message control tag length values) field.

11. In Article 10, The first length field of the first variable-length field is an advertising data length field, A method, wherein the first content field of the first variable-length field is an advertising data content field.

12. In paragraph 1, The above first device is an initiator or controller, The second device is a respondent or a controllable device, the method.

13. In paragraph 1, A method wherein the first frame and the second frame are transmitted on a narrowband (NB) channel or an ultra-wideband (UWB) channel.

14. 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: Transmitting a first frame including a first variable-length field to another device; and A second frame responsive to the first frame is set to be received from the other device, Based on the first frame additionally including a second variable-length field, the first variable-length field is positioned consecutively with the second variable-length field within the first frame, A device, wherein the first variable-length field comprises a first length field and a first content field.

15. A step of receiving, by a second device, a first frame including a first variable-length field from a first device; and A step of transmitting a second frame responsive to the first frame to the first device by the second device, Based on the first frame additionally including a second variable-length field, the first variable-length field is positioned consecutively with the second variable-length field within the first frame, A method, wherein the first variable-length field comprises a first length field and a first content field.

16. 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 a first frame including a first variable-length field from another device; and and is set to transmit a second frame responding to the first frame to the other device, Based on the first frame additionally including a second variable-length field, the first variable-length field is positioned consecutively with the second variable-length field within the first frame, A device, wherein the first variable-length field comprises a first length field and a first content field.

17. 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 13 based on execution by said one or more processors.

18. One or more non-transitory computer-readable media storing one or more instructions that are executed by one or more processors to control performing a method according to any one of claims 1 to 13.

Images