Method and apparatus for generating and operating a privacy-protected address in an uwband

Abstract

A method and apparatus for generating and operating a privacy-preserving address in an ultra wide band (UWB) wireless network system are disclosed. A method performed by a first device in a UWB wireless network system according to one embodiment of the present disclosure may comprise the steps of: broadcasting a public-based advertisement polling frame; receiving a public-based advertisement response frame from the second device in response to the public-based advertisement polling frame; sending the public-based SOR frame to a second device; and performing a ranging session process with the plurality of second devices after an initialization process according to the public-based advertisement polling frame, the public-based advertisement response frame, and the public-based SOR frame. Here, a polling message broadcasted during a ranging session process can include a private address based on identification information representing a device related to the ranging session process or IRK information generated using a predefined specific value.

Description

Technical Field

[0001] This disclosure relates to a method and apparatus for generating and manipulating privacy-preserving addresses in an ultra-wideband (UWB) wireless network system. Background Technology

[0002] Low-rate (LR) wireless networks support low-data-rate connectivity between fixed or mobile devices with limited battery consumption requirements. For example, LR wireless networks can be used in Wireless Personal Area Networks (WPANs). The Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard defines various technologies for the Physical Layer (PHY) and Media Access Control (MAC) sublayers of LR wireless networks. For example, the IEEE 802.15.4 standard defines various modes supporting precise ranging.

[0003] Ultra-wideband (UWB) wireless networks can support the transmission of massive amounts of information with low power over extremely wide bands (e.g., 3.1 GHz–10.6 GHz). For example, UWB technology can support the wireless transmission of digital signage information by converting digital signage information into pulse signals for a duration of less than nanoseconds. The IEEE 802.15.4z standard defines an ultra-wideband (UWB) technology related to ranging techniques. For example, the IEEE 802.15.4z standard includes High Rate Pulse Frequency (HRP) PHY technology, which supports high-speed data communication (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 communication (e.g., radio frequency identification (RFID) applications). Furthermore, the IEEE 802.15.4z standard includes UWB PHY technology that refines the integrity and accuracy of ranging measurements, as well as MAC technology that supports the exchange of ranging-related information between participating devices and the control of the time-of-flight (TOF) ranging process. Recently, the IEEE 802.15.4ab standard, which includes further refinements to UWB PHY / MAC for wireless network technologies based on the IEEE 802.15.4z standard, is under discussion. Summary of the Invention

[0004] Technical issues

[0005] The technical problem of this disclosure is to provide a method and apparatus for generating and manipulating privacy-preserving addresses in a UWB wireless network system.

[0006] Specifically, the technical problem of this disclosure is to provide a method and apparatus for generating and manipulating privacy-preserving addresses in a ranging session after public initialization in a UWB wireless network system.

[0007] The technical objectives achieved through this disclosure are not limited to those described above, and those skilled in the art will clearly understand from the following description other technical objectives not described herein.

[0008] Technical solution

[0009] A method performed by a first device in an ultra-wideband (UWB) wireless network system according to one aspect of this disclosure may include: broadcasting a public-based announcement polling frame; receiving a public-based announcement response frame from a second device in response to the public-based announcement polling frame; sending a public-based ranging start (SOR) frame to the second device; and, after an initialization process based on the public-based announcement polling frame, the public-based announcement response frame, and the public-based SOR frame, performing a ranging session process with a plurality of second devices. Here, the polling message broadcast during the ranging session process may include a private address based on identity resolution key (IRK) information generated using identification information representing the device associated with the ranging session process or a predefined specific value.

[0010] A method performed by a second device in an ultra-wideband (UWB) wireless network system according to an additional aspect of this disclosure may include: receiving a public-based announcement polling frame from a first device; sending a public-based announcement response frame to the first device in response to the public-based announcement polling frame; receiving a public-based ranging start (SOR) frame from the first device; and, after an initialization process based on the public-based announcement polling frame, the public-based announcement response frame, and the public-based SOR frame, performing a ranging session procedure with the first device. Here, the polling messages broadcast during the ranging session procedure may include private addresses based on identity resolution key (IRK) information generated using identification information of the device associated with the ranging session procedure or predefined specific values.

[0011] Beneficial effects

[0012] According to this disclosure, a method and apparatus for generating and manipulating privacy-preserving addresses in a UWB wireless network system can be provided.

[0013] According to this disclosure, in addressing the technical problem of this disclosure, a method and apparatus for generating and manipulating privacy-preserving addresses in a ranging session following public initialization in a UWB wireless network system can be provided.

[0014] The effects achievable by this disclosure are not limited to those described above, and those skilled in the art can clearly understand other effects not described herein through the following description. Attached Figure Description

[0015] The accompanying drawings, included as part of the detailed description for understanding this disclosure, provide embodiments of the disclosure and describe the technical features of the disclosure through detailed description.

[0016] Figure 1 The figure shows a block configuration diagram of a wireless communication device according to an embodiment of the present disclosure.

[0017] Figure 2 This is a diagram used to describe the HRP UWB PPDU format to which this disclosure can be applied.

[0018] Figure 3 This is a diagram showing the RMARRER location in the HRP-ERDEV PPDU format configured according to the STS group, which can be applied according to the present disclosure.

[0019] Figure 4 This is a diagram used to describe the two-way ranging techniques that can be applied to this disclosure.

[0020] Figure 5 This is a diagram illustrating examples of formats for which the RMI IE, RCPCS IE, RRMC IE, and RRTI IE of this disclosure can be applied.

[0021] Figure 6 An example of a message sequence diagram for applying the delayed response time results that can be applied to this disclosure is shown.

[0022] Figure 7 An example of a message sequence diagram for applying the embedded response time results that can be applied to this disclosure is shown.

[0023] Figure 8 An example of a message sequence diagram for SS-TWR using SP3 packets, to which this disclosure can be applied, is shown.

[0024] Figure 9 An example of a message sequence diagram for a DS-TWR to which the delayed response time information of this disclosure can be applied is shown.

[0025] Figure 10 An example of a message sequence diagram for a DS-TWR to which embedded ranging time information of this disclosure can be applied is shown.

[0026] Figure 11 This is a diagram used to illustrate the role of the device to which this disclosure can be applied in the ranging process.

[0027] Figure 12 Examples of the ARC IE, RDM IE, RBU IE, RR IE and SRRE IE formats that can be applied to this disclosure are shown.

[0028] Figure 13 It is a diagram used to describe the ranging block structure and ranging stage to which this disclosure can be applied.

[0029] Figure 14 Examples of timing diagrams for various multi-device ranging methods to which this disclosure can be applied are shown.

[0030] Figure 15 A timing diagram is shown in an example of a block-based pattern that can be applied to this disclosure.

[0031] Figure 16 This is a diagram illustrating examples of various transport offsets to which this disclosure can be applied.

[0032] Figure 17 An example of a message sequence diagram for one-to-many SS-TWR that can be applied according to this disclosure is shown.

[0033] Figure 18 An example of a message sequence diagram for SP3 one-to-many SS-TWR that can be applied according to this disclosure is shown.

[0034] Figure 19 This is a diagram illustrating an example of the MMS grouping that can be applied to this disclosure.

[0035] Figure 20 This is a diagram illustrating additional examples of MMS grouping that can be applied to this disclosure.

[0036] Figure 21 This is a diagram illustrating additional examples of MMS grouping that can be applied to this disclosure.

[0037] Figure 22 Examples of the NBA-MMS-UWB ranging control phase, ranging phase, and measurement reporting phase that can be applied according to this disclosure are provided.

[0038] Figure 23 It is a diagram used to describe the initialization and setup of a ranging session that can be applied to this disclosure.

[0039] Figure 24 This is a diagram illustrating examples of AP transmit and receive operations that can be applied using this disclosure.

[0040] Figure 25 and Figure 26 This diagram illustrates examples of AP transmit and receive operations that can be applied in various RANs according to this disclosure.

[0041] Figure 27 This is a diagram illustrating examples of the notification message format and response message format according to this disclosure.

[0042] Figure 28 This is a diagram illustrating an example of message exchange between an initiator and a responder according to this disclosure.

[0043] Figure 29 This illustrates an example of concurrent exchange of coordination information and ranging sessions between devices belonging to different RANs according to this disclosure.

[0044] Figure 30 This represents an example of a private address-based polling grouping format according to this disclosure.

[0045] Figure 31 This represents an example of a private address-based notification response packet format according to this disclosure.

[0046] Figure 32 This represents an example of a grouping format based on private address ranging according to this disclosure.

[0047] Figure 33 This represents an example of a polling grouping format for public announcements according to this disclosure.

[0048] Figure 34 This represents an example of a response grouping format for public announcements according to this disclosure.

[0049] Figure 35 This is an example of a distance measurement start grouping format for public announcements according to this disclosure.

[0050] Figure 36 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0051] Figure 37 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0052] Figure 38 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0053] Figure 39 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0054] Figure 40 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0055] Figure 41 The diagram illustrates a polling grouping format for public announcements based on security levels, according to this disclosure.

[0056] Figure 42 The diagram illustrates a polling grouping format for public announcements based on security modes, according to this disclosure.

[0057] Figure 43This is a diagram illustrating an example of a method for distinguishing frames by ID in ranging operations according to this disclosure.

[0058] Figure 44 This is a diagram illustrating exemplary formats of public polling frames, public response frames, and public report frames according to this disclosure.

[0059] Figure 45 This is a diagram illustrating an example of a method for distinguishing frames by address type in ranging operations according to this disclosure.

[0060] Figure 46 This is a diagram illustrating an exemplary format of polling frames, response frames, and report frames according to this disclosure.

[0061] Figure 47 This is a diagram illustrating an example of a method for distinguishing frames by subtype according to this disclosure.

[0062] Figure 48 This is a diagram illustrating various examples of the notification polling and notification response formats according to this disclosure.

[0063] Figure 49 This represents an example of initialization and setup operations based on random delay according to this disclosure.

[0064] Figure 50 This is a diagram illustrating various formats of specific frames sent by an initiator / notifier / controller that receives a public notice response frame, according to this disclosure.

[0065] Figure 51 This illustrates an example of initialization and setup operations according to this disclosure, including sending / receiving a common SOR frame containing a response code for error handling.

[0066] Figure 52 This illustrates an example of initialization and setup operations according to this disclosure, including sending / receiving a public notification confirmation frame containing a response code for error handling.

[0067] Figure 53 The diagram is based on common initialization and setup operations.

[0068] Figure 54 The diagram illustrates the public initialization handshake process and operations in the protected ranging session according to this disclosure.

[0069] Figure 55 The diagram illustrates a privacy-protected address grouping format according to this disclosure.

[0070] Figure 56 The diagram illustrates a privacy-preserving address-based grouping format according to this disclosure.

[0071] Figure 57The diagram illustrates the grouping format in a ranging session protected by this disclosure.

[0072] Figure 58 This is a diagram used to describe the operation of the first device according to this disclosure.

[0073] Figure 59 This is a diagram used to describe the operation of the second device according to this disclosure.

[0074] Figure 60 The diagram illustrates a public notice polling grouping format with group ID information according to this disclosure.

[0075] Figure 61 The diagram illustrates the grouping format in a protected one-to-many ranging session according to this disclosure.

[0076] Figure 62 This is a diagram used to describe the operation of the first device according to this disclosure.

[0077] Figure 63 This is a diagram used to describe the operation of the first device according to this disclosure. Detailed Implementation

[0078] In the following, embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. The detailed description disclosed with reference to the drawings is intended to describe exemplary embodiments of the present disclosure and not to represent the only embodiments in which the present disclosure may be practiced. The following detailed description includes specific details to provide a complete understanding of the present disclosure. However, those skilled in the art will recognize that the present disclosure may be practiced without these specific details.

[0079] In some cases, known structures and devices may be omitted, or they may be shown in block diagram form based on the core functions of each structure and device in order to prevent ambiguity of the concepts in this disclosure.

[0080] In this disclosure, when an element is referred to as “connected,” “combined,” or “linked” to another element, it can include both indirect and direct connections where another element exists therebetween. Furthermore, in this disclosure, the terms “comprising” or “having” specify the presence of the mentioned features, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, stages, operations, components, elements, and / or groups thereof.

[0081] In this invention, terms such as "first" and "second" are used only to distinguish one element from another and are not used to limit the elements. Unless otherwise stated, they do not limit the order or importance of the elements. Therefore, within the scope of this disclosure, a first element in one embodiment may be referred to as a second element in another embodiment, and similarly, a second element in one embodiment may be referred to as a first element in another embodiment.

[0082] The terminology used in this disclosure is for the purpose of describing particular embodiments and not for limiting the claims. As used in the description of the embodiments and the appended claims, the singular forms are intended to include the plural forms unless the context clearly indicates otherwise. The term “and / or” as used in this disclosure may refer to one of the associated enumerations, or is intended to refer to and include any and all possible combinations of two or more of them. Furthermore, unless otherwise stated, the “ / ” between words in this disclosure has the same meaning as “and / or”.

[0083] The examples disclosed herein can be applied to various wireless communication systems. For example, the examples disclosed herein can be applied to wireless networks based on the IEEE 802.15 standard (e.g., Zipline, Bluetooth, etc.). In particular, the examples disclosed herein can be applied to wireless networks based on the IEEE 802.15.4 standard, and further, can be applied to newly proposed UWB wireless networks based on the IEEE 802.15.4ab standard, or next-generation UWB wireless networks after IEEE 802.15.4ab. The wireless communication systems to which the examples disclosed herein are applied are not limited to IEEE 802.15 series wireless networks, but can also be applied to IEEE 802.11 series wireless local area network (WLAN) technologies or Wi-Fi technologies, and can be applied to cellular wireless communication systems (e.g., 3GPP standards and 5G New Radio (NR) Long Term Evolution (LTE) series technologies).

[0084] The IEEE 802.15.4ab standard, which includes technologies to further advance 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 budgets and / or reduced air interface time; additional channels and operating frequencies; interference cancellation techniques to support higher device density and higher service use cases; improvements in accuracy, precision, reliability, and interoperability for high-integrity ranging; techniques to reduce complexity and power consumption; hybrid operation using narrowband signaling to support UWB definitions; refined native discovery and connection establishment mechanisms; awareness capabilities to support presence detection and environment mapping; mechanisms to support high data rate streaming with a minimum throughput of 50 Mbps, as well as low-power and low-latency streaming; and support for peer-to-peer, peer-to-multi-peer, station-to-infrastructure protocols, and infrastructure synchronization mechanisms.

[0085] The technical features that can be applied to examples of this disclosure will be described below.

[0086] Figure 1 The figure shows a block diagram of a wireless communication device according to an embodiment of the present disclosure.

[0087] Figure 1 The first device 100 and the second device 200 illustrated in the diagram can be replaced by various terms, such as terminal, wireless device, wireless transceiver unit (WTRU), user equipment (UE), mobile station (MS), user terminal (UT), mobile subscriber station (MSS), mobile subscriber unit (MSU), subscriber station (SS), advanced mobile station (AMS), wireless terminal (WT), or simple user, etc. Furthermore, the first device 100 and the second device 200 can include access point (AP), base station (BS), fixed station, node B, base transceiver system (BTS), and network. It can be replaced by various terms such as artificial intelligence (AI) system, roadside unit (RSU), repeater, router, relay, and gateway.

[0088] when Figure 1 When devices 100 and 200 in the diagram support ranging, they can be referred to as Ranging Capability Devices (RDEVs) or Enhanced Ranging Capability Devices (ERDEVs). For example, Figure 1 The devices 100 and 200 illustrated in the diagram can be referred to by various terms such as transmitting device, receiving device, transmitting RDEV, receiving RDEV, transmitting ERDEV, receiving ERDEV, etc. For example, depending on their role in the ranging operation, devices 110 and 200 can be called initiator, responder, originator, receiver, controller, controlleree, etc. A device's role is not fixed but is determined relatively based on its relationship with other devices. When a device interacts with multiple devices, it can play multiple roles.

[0089] refer to Figure 1The first device 100 and the second device 200 can transmit and receive wireless signals via various UWB wireless network technologies (e.g., IEEE 802.15.4 series). The first device 100 and the second device 200 may include interfaces for the Media Access Control (MAC) layer and Physical Layer (PHY) conforming to the IEEE 802.15.4 standard. The IEEE 802.15.4-based PHY and MAC layers are included in the UWB subsystem, and the UWB subsystem may further include a UWB Command Interface (UCI) corresponding to the interface between the UWB controller and the host. The UWB subsystem can exchange messages with the host system via the UCI.

[0090] Furthermore, the first device 100 and the second device 200 can additionally support various communication standards (e.g., IEEE 802.15 series, IEEE 802.11 series, 3GPP LTE series, 5G NR series standards, etc.) besides UWB wireless network technology. Additionally, the devices disclosed herein can be implemented in various devices such as mobile phones, vehicles, personal computers, augmented reality (AR) devices, virtual reality (VR) devices, etc. Furthermore, the devices of this specification can support various communication services such as voice calls, video calls, data communication, autonomous driving, machine-type communication (MTC), machine-to-machine (M2M), device-to-device (D2D), and IoT (Internet of Things).

[0091] The first device 100 may include one or more processors 102 and one or more memories 104, and may additionally include one or more transceivers 106 and / or one or more antennas 108. The processor 102 may control the memory 104 and / or the transceiver 106 and may be configured to implement the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor 102 may transmit a wireless signal including the first information / signal via the transceiver 106 after generating a first information / signal by processing information in the memory 104. Additionally, the processor 102 may receive a wireless signal including a second information / signal via the transceiver 106, and then store information obtained through signal processing of the second information / signal in the memory 104. The memory 104 may be connected to the processor 102 and may store various information relating to the operation of the processor 102. For example, the memory 104 may store software code including instructions for performing all or part of the processes controlled by the processor 102 or for performing the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. Here, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to implement UWB wireless network technology (e.g., LTE 802.15.4 series). Transceiver 106 may be connected to processor 102 and may transmit and / or receive wireless signals via one or more antennas 108. Transceiver 106 may include a transmitter and / or a receiver. Transceiver 106 may be used with an RF (radio frequency) unit. In this disclosure, "device" may refer to a communication modem / circuit / chip.

[0092] The second device 200 may include one or more processors 202 and one or more memories 204, and may additionally include one or more transceivers 206 and / or one or more antennas 208. The processor 202 may control the memory 204 and / or the transceiver 206 and may be configured to implement the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure. For example, the processor 202 may generate third information / signals by processing information in the memory 204, and then transmit a wireless signal including the third information / signals via the transceiver 206. Additionally, the processor 202 may receive wireless signals including fourth information / signals via the transceiver 206, and then store information obtained through 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 store software code including instructions for performing all or part of the processes controlled by the processor 202 or for performing the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure. Here, processor 202 and 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). Transceiver 206 may be connected to processor 202 and may transmit and / or receive wireless signals via one or more antennas 208. Transceiver 206 may include a transmitter and / or a receiver. Transceiver 206 may be used with an RF unit. In this disclosure, "device" may refer to a communication modem / circuit / chip.

[0093] The hardware components of devices 100 and 200 will be described in more detail below. However, they are not limited thereto, but one or more protocol layers may be implemented by one or more processors 102 and 202. For example, one or more processors 102 and 202 may implement one or more layers (e.g., functional layers such as PHY and MAC). One or more processors 102 and 202 may generate one or more PDUs (Protocol Data Units) and / or one or more SDUs (Service Data Units) according to the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102 and 202 may generate messages, control information, data, or information according to the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102 and 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the functions, processes, proposals, and / or methods disclosed in this disclosure to provide them to one or more transceivers 106 and 206. One or more processors 102, 202 may receive signals (e.g., baseband signals) from one or more transceivers 106, 206 and obtain PDUs, SDUs, messages, control information, data, or information in accordance with the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this disclosure.

[0094] One or more processors 102, 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102, 202 may be implemented by hardware, firmware, software, or a combination thereof. In examples, one or more ASICs (Application-Specific Integrated Circuits), one or more DSPs (Digital Signal Processors), one or more DSPDs (Digital Signal Processing Devices), one or more PLDs (Programmable Logic Devices), or one or more FPGAs (Field-Programmable Gate Arrays) may be included in one or more processors 102, 202. The descriptions, functions, processes, proposals, methods, and / or operation flowcharts included in this disclosure may be implemented using firmware or software, and the firmware or software may be implemented to include modules, processes, functions, etc. Firmware or software configured to execute the descriptions, functions, processes, proposals, methods, and / or operation flowcharts included in this disclosure may be included in one or more processors 102, 202 or may be stored in one or more memories 104, 204 and driven by one or more processors 102, 202. The descriptions, functions, processes, proposals, methods, and / or operation flowcharts included in this invention may be implemented by firmware or software in the form of code, commands, and / or command sets.

[0095] One or more memories 104, 204 may be connected to one or more processors 102, 202 and are capable of storing data, signals, messages, information, programs, code, instructions, and / or commands in various forms. One or more memories 104, 204 may be configured with ROM, RAM, EPROM, flash memory, hard disk drive, registers, cache memory, computer-readable storage media, and / or combinations thereof. One or more memories 104, 204 may be located internally and / or externally to one or more processors 102, 202. Furthermore, one or more memories 104, 204 may be connected to one or more processors 102, 202 via various technologies such as wired or wireless connections.

[0096] One or more transceivers 106, 206 can transmit user data, control information, wireless signals / channels, etc., mentioned in the methods and / or operation flowcharts of this disclosure to one or more other devices. One or more transceivers 106, 206 can receive user data, control information, wireless signals / channels, etc., mentioned in the descriptions, functions, processes, proposals, methods, and / or operation flowcharts included in this disclosure from one or more other devices. For example, one or more transceivers 106, 206 can be connected 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. Furthermore, one or more processors 102, 202 can control one or more transceivers 106, 206 to receive user data, control information, or wireless signals from one or more other devices. Furthermore, one or more transceivers 106, 206 may be connected to one or more antennas 108, 208, and the one or more transceivers 106, 206 may be configured to transmit and receive user data, control information, wireless signals / channels, etc., mentioned in the descriptions, functions, processes, proposals, methods, and / or operation flowcharts included in this disclosure via one or more antennas 108, 208. In this invention, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). The one or more transceivers 106, 206 may process the received wireless signals / channels, etc., by converting them from RF band signals to baseband signals using one or more processors 102, 202. The one or more transceivers 106, 206 may convert the user data, control information, wireless signals / channels, etc., processed by using one or more processors 102, 202 from baseband signals to RF band signals. Therefore, the one or more transceivers 106, 206 may include (analog) oscillators and / or filters.

[0097] For example, Figure 1 The transceivers 106 and 206 can perform transmission and reception operations of signals (e.g., packet or physical layer protocol data units (PPDUs) conforming to IEEE 802.15.4, etc.). Furthermore, in this disclosure, the operations of generating transmission / reception signals or performing data processing or calculations on transmission / reception signals in advance by various devices can be performed by… Figure 1 Processors 102 and 202 execute this. Examples of operations that generate transmit / receive signals or perform prior data processing or calculations on transmit / receive signals may include: 1) determining / acquiring / configuring / calculating / decoding / encoding bit information of fields included in the PPDU; 2) determining / configuring / acquiring time or frequency resources for fields included in the PPDU; 3) determining / configuring / acquiring a specific sequence of fields included in the PPDU action; 4) power control operations and / or power-saving operations applied to the device; and 5) operations related to determining / acquiring / configuring / calculating / encoding the ACK signal. Additionally, in the following examples, various information used by various devices to determine / acquiring / configuring / calculating / decoding / encoding transmit and receive signals (e.g., information related to fields / subfields / control fields / parameters / power, etc.) may be stored... Figure 1 In memory 104 and 204.

[0098] In the UWB band, devices can perform medium access based on a Carrier Sense Multiple Access (CSMA / CA) mechanism with collision avoidance. The CSMA / CA mechanism performs idle channel assessment (CCA), which senses the wireless channel or medium for a predetermined duration before the device begins transmission. For example, sensing can be performed using an energy detection (ED) method based on a predetermined threshold. As a result of the sensing, if the medium is determined to be idle, transmission begins through the corresponding medium. On the other hand, if the medium is detected to be occupied or busy, the device can set a delay period (e.g., a random backoff period) for medium access without initiating transmission and wait before attempting transmission. By applying a random backoff period, multiple devices are expected to attempt transmission after waiting for different periods, thus minimizing collisions.

[0099] Additionally, when a superframe structure is applied, the time-slotted CSMA-CA mechanism can be used for data transmission during the Contention-Access Period (CAP) of the active portion between the active and inactive portions of the interval between beacons. The CSMA-CA mechanism cannot be used for data transmission during the active portion or the Contention-Free Period (CFP). When a superframe structure is not applied, the non-time-slotted CSMA-CA mechanism can be used for the transmission of all data frames excluding ACK frames used for data request commands.

[0100] Distance measurement

[0101] Distance measurement involves measuring the distance between two devices, and devices with distance measurement capabilities can be called distance-capable devices (RDEV) or enhanced distance-capable devices (ERDEV).

[0102] Figure 2 This is a diagram used to describe the HRP UWB PPDU format to which this disclosure can be applied.

[0103] Figure 2 (a) to Figure 2 (g) illustrates the encoding process of an HRP UWB PPDU. The encoding process generates an HRP UWB PPDU with a format including a Synchronization Header (SHR), a PHY Header (PHR), and a PHY Payload field.

[0104] Figure 2 (a) shows a PHY Service Data Unit (PSDU) received from the MAC via the PHY Service Access Point (SAP). The PSDU may include the MAC PDU.

[0105] exist Figure 2 In (b), Reed-Solomon coding can be applied to PSDU to generate the PHY payload field. Figure 2 The PHY payload field in (b) is non-expanded and corresponds to the state before the application of convolutional encoding.

[0106] exist Figure 2 In (c), the PHR field can be appended before the PHY payload field. The PHR field can be 19 bits in size, from bit 0 to bit 18. For example, bits 0-1 can correspond to the data rate field, bits 2-8 to the frame length field, bit 9 to the ranging field, bit 10 can be reserved, bits 11-12 to the preamble duration field, and bits 13-18 to the single error correction, double error detection (SECDED) field. The data rate field indicates the data rate value applied to the PHY payload field. The frame length field indicates the length of the PSDU. The ranging field indicates whether the corresponding frame is a ranging frame (RFRAME). The preamble duration field indicates the length (in symbolic units) of the SYNC field of the SHR.

[0107] exist Figure 2 In (d), convolutional coding can be applied to generate the encoded PHY payload field, and... Figure 2 In (e), the extension can be applied to the PHY payload field.

[0108] exist Figure 2In (f), the SHR can be added before the PHR. The SHR field can include the SYNC field (or preamble) and the Start of Frame Delimiter (SFD) field.

[0109] exist Figure 2 In (g), modulation is applied to the SHR, PHR, and PHY payload fields, and the PPDU encoding process is terminated. The basic coding rate can be applied to the SHR field. The PHR field can have a format including the data rate (2 bits), frame length (7 bits), ranging (1 bit), reservation (1 bit), preamble duration (2 bits), and SECDED (6 bits) for the Basic Pulse Repetition Frequency (BRFP) mode, or it can 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 can also indicate the size of the additional gap between the payload and the STS. For the PHR field, in BPRF mode, burst position modulation-binary phase shift keying (BPM-BPSK) with a coding rate of 850 kb / s or 6.8 Mb / s can be applied, and in 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 can be applied, and in other cases, BPM-BPSK with a coding rate of 850 kb / s or 110 kb / s can be applied. For the PHY payload field, in 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 can be applied, and in other cases, BPM-BPSK with the coding rate indicated in the PHR can be applied.

[0110] Figure 3 This is a diagram showing the RMARRER location in the HRP-ERDEV PPDU format configured according to the STS group, which can be applied according to the present disclosure.

[0111] The Scrambling Timestamp Sequence (STS) field can include a sequence of pseudo-random pulses. For example, an STS can include a sequence of pseudo-random pulses based on Advanced Encryption Standard (AES)-128 and can be used for precise positioning in positioning techniques based on spread spectrum technology in UWB communication.

[0112] The PPDU STS grouping structure configuration can vary depending on whether the STS field is included and its location.

[0113] Figure 3(a) shows the format corresponding to STS group configuration 0 (i.e., the STS field does not exist in the PPDU). This format can be defined in a forced manner.

[0114] Figure 3 (b) shows the format corresponding to STS group configuration 1 (i.e., the STS field is immediately after the SFD field and before the PHR field). This format can be defined in a mandatory manner.

[0115] Figure 3 (c) shows the format corresponding to STS group configuration 2 (i.e., the STS field follows the PHY payload field). This format can be defined optionally.

[0116] Figure 3 (d) shows the format corresponding to STS group configuration 3 (i.e., the STS field is immediately following the SFD field, the PHR field is absent, and the data field (i.e., the PHY payload field) is absent). This format can be defined in a forced manner.

[0117] picture Figure 3 The PPDU format, similar to the example in the example, can be called the HRP-ERDEV PPDU format. Figure 3 In the diagram, arrows indicate the reference position of the distance marker (RMARKER) in each format. The RMARKER can be a reference used for timestamp measurements or distance counters.

[0118] For example, RMARKER can be defined as the starting point of the first symbol of the SFD following RFRAME, which is at the local antenna time. The next higher layer can estimate the relative clock offset between the local reference clocks on the remote transmitter and receiver based on the report of the SRMARKER ranging counter value of at least one STS segment.

[0119] The ranging counter supported by RDEV corresponds to a set of behavioral attributes and capabilities of the RDEV used to calculate the ranging counter value. The ranging counter value is an unsigned integer and can be defined as having a length of at least 32 bits. For HRP UWBPHY, the unit of the ranging counter is defined as 2^499.2 MHz chipping period. -7 And approximately 15.65 picoseconds (ps); and for LRP UWB PHY, the unit of the ranging counter is defined as 20 times the basic chip rate of 1 MHz. -20 And it is approximately 0.9537 ps.

[0120] In RDEV, ranging capabilities can be enabled using the MAC Common Part Sublayer (MCPS) -DATA.request primitive and the MAC Sublayer Management Entity (MLME) -RX-ENABLE.request primitive. A primitive can refer to a set of instructions or parameters exchanged between sublayer entities or layers within a device. For example, a source can request ranging capabilities using the MCPS-DATA.request primitive, and a receiver can enable ranging capabilities using the MLME-RX-ENABLE.request primitive.

[0121] Distance measurement and positioning methods

[0122] Ranging and positioning methods supported by RDEV and ERDEV can be based on timestamp capabilities. As time-based technologies, one-way two-way ranging (SS-TWR), two-way two-way ranging (DS-TWR), and one-way ranging / time difference of arrival (OWR / TDOA) will be described below.

[0123] Figure 4 This is a diagram used to describe the two-way ranging techniques that can be applied to this disclosure.

[0124] exist Figure 4 In the example of (a), SS-TWR includes measuring the round-trip latency of a single message from one device to another, as well as 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.

[0125] Each device precisely measures the send and receive times of message frames, and accordingly, T_round and T_reply can be calculated by simple subtraction. The resulting TOF can be estimated as ^T_prop using the following equation.

[0126] [Equation 1]

[0127] When a device can estimate the relative clock offset between itself and a remote device, the accuracy of Time of Flight (TOF) can be improved using the following equation.

[0128] [Equation 2]

[0129] Here, C_offs corresponds to the value obtained after the receiver of device A measures the relative clock offset between itself and the transmitter of remote device B.

[0130] exist Figure 4In the example of (b), DS-TWR corresponds to an extension of SS-TWR, and the two round-trip times can be used and combined to calculate the TOF result by reducing the error for cases with long response delays but uncorrected clock frequency offsets. Device A initiates the first round-trip time measurement, and device B responds to it, and then device B initiates the second round-trip time measurement, and device A responds to it, allowing the entire DS-TWR exchange to be completed. T_prop corresponds to the propagation time of the RMARKER between the devices.

[0131] Each device precisely measures the send and receive times of message frames, and accordingly, T_round and T_reply can be calculated by simple subtraction. The resulting TOF can be estimated as ^T_prop using the following equation.

[0132] [Equation 3]

[0133] Figure 4 Example (c) corresponds to the following: Figure 4 In (b), DS-TWR reduces the number of messages from four to three. In other words, the response to the first round-trip time measurement can be used as the initiation message for the second round-trip time measurement.

[0134] Next, the TDOA method is described. TDOA corresponds to a technique for locating wireless devices (e.g., radio frequency identification (RFID) devices) based on the relative arrival times of one or more messages. OWR can be used for TDOA. There are two cases of TDOA. In one case, the mobile device periodically broadcasts messages, and the arrival times of the broadcast messages at multiple fixed nodes synchronized in a predetermined manner can be compared. Typically, the message sent by the mobile device can be referred to as a blink. In the other case, multiple synchronized nodes broadcast messages sequentially based on known transmission time offsets between each other. For any pair of fixed synchronized nodes, the difference in arrival times of the blink in the first case, or the difference in arrival times of the broadcast messages received by the mobile device in the second case, locates the mobile device on a hyperboloid. By combining the results from multiple such pairs, the intersection points between the sets of hyperboloids can be derived, and accordingly, the location of the mobile device can be specified. In the second case, transmission offsets can be considered when calculating the arrival time differences of messages from synchronized nodes.

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

[0136] Synchronization of fixed nodes can be performed via wired distribution of clock signals, and wireless synchronization techniques can also be applied. UWB messages (along with known / predictable Time of Shift) transmitted between fixed nodes can be used to calculate the relative clock frequency offset and drift between them. This information can be used to correct the arrival time of flashing messages based on common time, thus making the TDOA data meaningful.

[0137] Setup process before ranging exchange

[0138] To reduce power consumption, disabling ranging can be defined as the default state. Enabling ranging in all RDEVs participating in TWR switching can be performed at a higher layer. Additionally, when using optional capabilities, it can be assumed that pre-arranged coordination for preamble and channel selection is performed prior to TWR switching.

[0139] The completion process after ranging exchange

[0140] After the TWR exchange is completed, each device can have transmit (TX) and receive (RX) ranging counter values ​​related to the round-trip time measurement or response time. All of these values ​​are needed in the node performing the calculation to calculate the TOF. This can be achieved using out-of-band (OOB) signaling, custom messages, ranging measurement information (RMI) information elements (IE), etc.

[0141] Figure 5 This is a diagram illustrating examples of formats for which the RMI IE, RCPCS IE, RRMC IE, and RRTI IE of this disclosure can be applied.

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

[0143] RMI IE can be used to send at least one ranging-related measurement to at least one device. RMI IE content fields can have... Figure 5 The example in (a) has the same format.

[0144] 1. The presence of a response time field indicates the existence of an RX to TX (or TX to RX) response time field in each RMI list element, while a value of 0 indicates its absence. The RX to TX (or TX to RX) response time can correspond to a time range specified by a reference. Figure 4 The description of T_reply.

[0145] 1. The presence value of the round-trip time field indicates the existence of the TX to RX round-trip time field in each RMI list element, while a value of 0 indicates its absence. The TX to RX round-trip time can be correlated with the reference... Figure 4The T_round described.

[0146] 1. The TOF field value indicates the presence of the TOF field in each RMI list element, and a value of 0 indicates its absence.

[0147] 1. The value of the AOA azimuth field indicates that the AOA azimuth field exists in each RMI list element, and a value of 0 indicates that it does not exist.

[0148] 1. The value of the AOA elevation angle field indicates the presence of the AOA elevation angle field in each RMI list element, and a value of 0 indicates that it does not exist.

[0149] 1. The AOA quality factor (FOM) field has a value that indicates whether the AOA azimuth field exists in each RMI list element when the AOA azimuth field exists, and whether the AOA elevation field exists in each RMI list element. A value of 0 indicates that the AOA azimuth field or the AOA elevation field does not exist.

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

[0151] 0, the value of the delay mode field, can indicate that the corresponding RMI IE is embedded in the RFRAME, and a value of 1 can indicate that the corresponding RMI IE is included in the delay message sent in the next measurement reporting phase.

[0152] The RMI list length field specifies the number of elements in the RMI list field. The fields included in the RMI list field are as follows: Figure 5 As shown in (a).

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

[0154] The Ranging Channel and Preamble Selection (RCPCS) IE can be used to indicate channel selection and / or TX / RX preamble selection for Dynamic Preamble and Channel Selection (DPS). DPS may include altering the length of the preamble to prevent attacking devices from intercepting the ranging. The RCPCS IE content fields can have... Figure 5 (b) has the same format as the example.

[0155] 1. The value of the CCI Existence (CCIP) field indicates that the CCI field exists, and a value of 0 indicates that it does not exist.

[0156] 1. The value of the DPS Duration Existence (DDP) field indicates whether the DPS Duration Existence field exists, and a value of 0 indicates that it does not exist.

[0157] 1. The value of the Preamble Selection Presence (PSP) field can indicate the presence of the preamble selection fields, i.e., the TX preamble field, the RX preamble field, and the Preamble Symbol Repetition (PSR) field, and a value of 0 can indicate that they do not exist.

[0158] The channel number field can indicate the UWB channel number used for the upcoming ranging exchange.

[0159] The Channel Configuration Interval (CCI) field specifies the channel configuration interval. The channel configuration interval corresponds to the time in Ranging Scheduling Time Units (RSTUs) between the transmission and reconfiguration of the corresponding IE for the specified channel.

[0160] For HRP UWB PHY, RSTU corresponds to 416 chips (approximately 833.33 ns) (416 chips = 416 / 499.2). 10 6 For LRP UWB PHY, RSTU corresponds to 1 microsecond (µs) (= 1 chip at a basic chip rate of 1 MHz).

[0161] The DPS duration field specifies the effective duration of the DPS. For ERDEV, the duration can be specified in RSTU, and for non-ERDEV, the duration can be specified in symbols.

[0162] The TX preamble field can indicate the DPS preamble that will be used during the upcoming ranging exchange on the side sending the corresponding IE.

[0163] The RX preamble field can indicate the DPS preamble that will be used during the upcoming ranging exchange on the side sending the corresponding IE.

[0164] The PSR field can indicate the number of times the preamble symbol will be repeated for each RFRAME to be used in the upcoming ranging exchange.

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

[0166] Basic ranging exchange

[0167] The receiver can enable or activate ranging in the MAC on the receiver side based on the MLME-RX-ENABLE.request primitive from the next higher layer.

[0168] After ranging is enabled in the MAC layer on the receiver side (i.e., after receiving the MLME-RX-ENABLE.request primitive), all received RFRAMEs can generate TX / RX ranging counters.

[0169] The sender can send data to the receiver based on the MCPS-DATA.request primitive.

[0170] The receiver can generate ranging reports for all RFRAMEs and send ACK frames to the transmitter.

[0171] The source can enable Tx to Rx switching (i.e., repeating data transmission and ACK reception) by receiving ACK frames from the receiver. At this point, the next higher layer may not be addressed.

[0172] Ranging reports can include the issuance of the MCPS-DATA.confirm primitive on the transmitter side (i.e., reporting the result of calling the MCPS-DATA.request primitive) and the issuance of the MCPS-DATA.indication primitive on the receiver side (i.e., indicating the reception of data from the transmitter, or indicating that ranging information is available based on the reception of packets from the transmitter).

[0173] Before ranging is disabled, the receiver's ranging report can be repeatedly generated, an ACK can be sent to the source, Tx to Rx switching and ranging report can be enabled based on the received ACK frame from the source.

[0174] Distance measurement process

[0175] First, the control of the ranging and the transmission (transmission) of the results are described.

[0176] Measurements can be exchanged between RDEVs to complete Time-of-Flight (ToF) calculations. This can be achieved by controlling the Time-of-War (TWR) via information elements and exchanging ranging data between RDEVs.

[0177] Specifically, information elements can be used to control the transmission of ranging data between the TWR and the RDEVs participating in the ranging exchange. For various ranging methods, depending on the required use case, the measurement results of two devices can be combined to complete the TOF calculation between the RDEVs participating in the ranging exchange. In other words, one device can send its ranging measurement results to another device. Information elements can be specified to provide a mechanism for controlling the TWR and to support the transmission of ranging information between devices participating in the ranging exchange. To ensure the integrity of the corresponding information transmission, secure private data communication capabilities can be used.

[0178] The following describes the ranging procedure of SS-TWR used to apply delayed response time results.

[0179] Figure 6 An example of a message sequence diagram for applying the results of delayed response time (SS-TWR) disclosed herein is shown.

[0180] In the message sequence diagram used for ranging exchange, RRMC IE(0) can 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 acknowledgment request (AR) field in the MAC header can indicate whether an ACK is requested.

[0181] The next higher layer of the initiator receives an RMI IE each time (e.g., Figure 5 (a) may have sufficient information for calculating the TOF between devices by using the above equations.

[0182] The initiator can call the MCPS-DATA.request primitive to request ranging response time information and send a ranging frame that includes a ranging request measurement and control (RRMC) information element, where the RRMC information element includes a ranging control information field.

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

[0184] The RRMC IE can send a ranging request and include information to control the ranging process.

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

[0186] The ranging control information field can indicate that when the value is 0, the corresponding frame is a ranging start message for SS-TWR; when the value is 1, the corresponding frame is a response to a ranging start message for SS-TWR; when the value is 2, the corresponding frame is a ranging start message for DS-TWR; and when the value is 3, the corresponding frame is continuing DS-TWR and initiating a second round-trip time measurement.

[0187] The Address Size field specifies the size of the addresses used in the RRMC Address List field. When the Address Size field is 0, all addresses in the RRMC Address List element correspond to short addresses. When the Address Size field is 1, all addresses in the RRMC Address List element correspond to extended addresses.

[0188] The RRMC address list length field indicates the number of addresses in the RRMC address list. The RRMC address list length field can be omitted when no address is provided (e.g., for unicast ranging where the target device can be identified by the destination address in the MAC header (MHR).

[0189] When the RRMC IE is a broadcast message, and when the transmitter wants to receive responses to ranging requests from all devices, the RRMC address list length field and the RRMC address list field can be omitted. Alternatively, when the transmitter wants to receive responses to ranging requests from specific devices (or a set of devices), the RRMC address list length field and the RRMC address list field can be used to select the set of devices to receive the responses.

[0190] For SS-TWR, since the initiator typically calculates the Time of F (TOF), the responder can request the TOF result by setting the TOF request field of the RRMC IE included in the response message.

[0191] For DS-TWR, since the responder typically calculates the Time of Flight (TOF), the initiator can request the TOF result by including the RRMC IE in one of the two messages sent to perform the DS-TWR exchange.

[0192] When an initiator requests different information from multiple responders, multiple RRMCIEs can be included in a single broadcast message.

[0193] The RRMC address list field can include a list of addresses that RRMC IE can access.

[0194] Regarding the ranging report (or response ranging frame), the initiator side can perform round-trip time measurement, and the MCPS-DATA.confirm primitive can provide the initiator side with a ranging report that defines the round-trip time. On the receiver side, the MCPS-DATA.indication primitive can provide the responder with a ranging report that defines the response time used for round-trip time measurement.

[0195] Figure 5 (d) shows an example of the distance response time instantaneous (RRTI) IE format.

[0196] Associated with at least one frame containing an RRMC IE in which the Response Time Request field is set to 1, an RRTIIE can be included in the corresponding response frame to send the response time of the response frame.

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

[0198] [Table 1]

[0199] The RRTI list length field indicates the number of elements in the RRTI list field. The RRTI list field can include RRTI list elements.

[0200] The RX to TX response time field of the RRTI list field can be set to indicate the time when the response RFRAME, including the RRTI IE, was sent, compared to a reference time specified by a higher layer (e.g., ...). Figure 4 The difference between T_reply and T_reply in example (a). The reference time may correspond to the reception time (based on RMARKER) of the RFRAME, including the RRMC IE where the reply time request field is set to 1.

[0201] The address field of the RRTI list field can be set to the address of the device that sent the request response time in the RRMC IE. The address field can be omitted in unicast ranging. In scheduled multi-node ranging, the address field can be omitted when the response times of other RDEVs are negotiated in advance and the order is determined.

[0202] The following describes the ranging procedure of SS-TWR for applying embedded response time results.

[0203] Figure 7 An example of a message sequence diagram for SS-TWR used to apply embedded response time results of this disclosure is shown.

[0204] For SS-TWR using response time results, ranging exchange can be initiated by a ranging frame requesting ranging response time information and including an RRMC IE in which the ranging control information field is set to 0. The responding device can complete the round-trip measurement by sending a response frame including an embedded ranging response time instantaneous (RRTI) IE. When the device has the capability to generate an RRTI IE, the number of messages required for ranging measurement can be minimized, thus saving power. However, calculating the arrival time of the received ranging message and preparing the RRTI IE value can be time-consuming. In some cases, this time can be known prior in an OOB manner, and the ranging response time negotiation (RRTN) IE can provide the device with a mechanism that indicates the preferred response time, i.e., the time required to prepare a frame including the RRTI IE. When this time is known, the ranging initiating device can anticipate a response message after a specific time and can save energy by delaying the receiver's activation until then. This can be applied to both SS-TWR and DS-TWR ranging exchanges.

[0205] exist Figure 7 In this context, RRMC IE(0) represents an RRMC IE that includes a ranging control information field with a value of 0. Communication of RRTN IEs within the dashed box can be performed at any convenient time before ranging exchange is initiated, or the preferred response time information can be known in advance or exchanged via OOB. When the MCPS-DATA.indication primitive, which includes the responder's RRTI IE, is received, the next higher layer of the initiator may have sufficient information to calculate the TOF between the two devices according to the above equation.

[0206] The following describes the ranging procedure for using a fixed response time (SS-TWR).

[0207] Figure 8 An example of a message sequence diagram for SS-TWR using SP3 (Scrambled Timestamp Sequence Grouping Configuration Option 3) that can be applied to this disclosure is shown.

[0208] When the responding device has precise control over the time between the transmission of its response message and the arrival of the ranging initiation message, the response time (i.e., Treply) can have a fixed, known value agreed upon between the devices participating in the ranging exchange. In this case, it may not be necessary to embed the Treply into the response message, or to send it separately in an additional message. The resulting ranging accuracy may depend on the responding device's precise control over the transmission time of its response message. For example, each 1 ns error in TOF may correspond to a ranging error of approximately 30 cm.

[0209] HRP-ERDEV PPDU format SP3 can be used to fix response times.

[0210] exist Figure 8 In the example, the startup message indicated by the dashed line in the box can represent communication used to agree on and coordinate all other parameters required to allow communication and the use of SP3 packets between devices. Figure 8 In the example, only a single message is indicated, but for protocols involving all parameters, there might be a series of messages in each direction. For example, RRNT IE could be used to agree on a fixed response time.

[0211] Within each device, the next higher layer can configure the SP3 packet format across all devices and can appropriately configure operations using the MLME-STS.request primitive to set Personal Area Network Information Base (PIB) attributes (e.g., phyHrpUwbStsKey, phyHrpUwbStsVCounter, phyHrpUwbStsVUpper96, etc.). When a higher layer selects the SP3 packet configuration, subsequent MCPS-DATA primitives will be associated with SP3 packets until the higher layer uses the MLME-STS.request primitive to change the packet configuration.

[0212] The MCPS-DATA.request primitive can be used to initiate ranging exchange, in which the PPDU may not transmit MAC data. Although not shown, it can be assumed that calling the MLME-RXENABLE.request primitive at the appropriate time enables the receiver to receive the PPDU. Because the PHY is configured for SP3 packets, the PHY can notify the MAC layer of PPDU reception at the end of the scrambled timestamp sequence (STS), and similarly recognize that the SP3-configured MAC can deliver the RxRangingCounter value of the RangeReportDescriptor parameter of the MCPS-DATA.indication primitive. Additionally, when it is assumed that the RangeStsFom of the RangeReportDescriptor is acceptable, higher layers can initiate a response by calling the MCPS-DATA.request primitive specifying the RangeTxTime, based on an agreed fixed response time.

[0213] When an SP3 packet response is received in the initiating device, and again assuming that the RangeingStsFom parameter of the MCPS-DATA.indication primitive is acceptable, the initiator side may have sufficient information to calculate the Time of Response (TOF) between the devices according to the above equation based on the known fixed response time.

[0214] Ranging exchanges can be repeated multiple times until higher layers agree. To resume PHY and MAC data interaction, the next higher layer can use the MLME-STS.request primitive to restore the STS packet configuration to a value that allows such data interaction. This is in Figure 8 The box indicated by the last dashed line is shown in the middle.

[0215] LRP-ERDEV can also support challenge-response ranging with fixed response times, so as to remove the need for data messages that require a response time.

[0216] The following describes the DS-TWR ranging process that applies delayed response time information.

[0217] Figure 9 An example message sequence diagram of a DS-TWR in which the delayed response time information of this disclosure can be applied is shown.

[0218] DS-TWR may primarily consist of the completion of SS-TWR exchanges initiated in each device and the combination of their results. DS-TWR can be initiated by the next higher layer that sends a ranging data frame that transmits an RRMC IE (i.e., RRMC IE(2)) in which the value of the ranging control information field is set to 2. This frame and its ACK can define the first round-trip time measurement. The delivery of the RRMC IE in the MCPS-DATA.indication primitive can notify the next higher layer to initiate a second round-trip time measurement by sending a data frame in the other direction. This data frame may include an RRMC IE (i.e., RRMC IE(3)) in which the value of the ranging control information field is set to 3 to indicate continued exchange, and both the response time request field and the round-trip time request field can be set to 1 to request the response time and the result of the first round-trip time measurement. An ACK to this message completes the second round-trip time measurement. Subsequent messages from the initiator can deliver the result of the first round-trip time measurement and the response time of the second round-trip time measurement via an RMIIE. Upon receiving the MCPS-DATA.indication primitive (including the RMI IE), the responder can have sufficient information to calculate the Time-of-Flight (TOF) between the devices according to the above equation. Subsequent reporting of ranging results to the initiator side can be performed based on the value of the TOF request field that initiated the RRMC IE, using the RMI IE.

[0219] The following describes the DS-TWR ranging process that uses embedded ranging time information.

[0220] Figure 10 An example of a message sequence diagram for a DS-TWR to which embedded ranging time information of this disclosure can be applied is shown.

[0221] Regarding the above Figure 4 (c) The 3-message DS-TWR exchange requires that the initiator side can embed the response time as part of the completion of the second round-trip time measurement. Figure 10 In the example, DS-TWR can be initiated by transmitting an RFRAME of RRMC IE (i.e., RRMC IE (2)), where the TOF request field is set to 0 (i.e., the initiator side does not request a ranging report) and the ranging control information field is set to 2.

[0222] The responder can complete the first round-trip time measurement and initiate a second measurement by transmitting an RFRAME in which the ranging control information field is set to 3 to indicate the continuation of the exchange (i.e., RRMC IE (3)). In this RRMC IE, both the response time request field and the round-trip time request field are set to 1, so the result of the first round-trip time measurement and the response time for the second round-trip time measurement can be requested. The initiator can complete the exchange by sending a final RFRAME that includes the result of the first round-trip time measurement in the RMI IE and the response time for the second round-trip time measurement in the RRTI IE.

[0223] When the responder receives the MCPS-DATA.indication primitive as a higher-level primitive, it can have sufficient information to calculate the Time-of-Flight (TOF) between devices according to the above equation. When the initiator of the ranging exchange wants the corresponding result, it can set the TOF request field of the initiating RRMC IE to request the responder to send the value of the result in the RMI IE of a subsequent message at the end of the exchange.

[0224] The different processes used for coordination of RDEV and ERDEV will be described below.

[0225] For successful interoperability of HRP-ERDEV when using STS, the transmitter and receiver need to prepare a seed (i.e., the STS key and data value V), which is used in the generation of the STS in the transmitter and in the generation of sequences associated with the STS received in the receiver. To coordinate these values, secure private data communication capabilities can be used, and the seed can be sent between devices using a ranging STS key and data (RKSD) IE. The counter value in the RSKD IE can be associated with the current packet or a future packet, as indicated by the Current Packet (CP) field of the corresponding IE. Higher layers can use the received RSKD IE information and appropriately configure the STS seed for sending and receiving future packets (e.g., via PIB attributes such as phyHrpUwbStsKey, phyHrpUwbStsVUpper96, phyHrpUwbStsVCounter, etc.). The header IE version of the RSKD IE can be used to synchronize the STS generator using information sent along with the secure payload IE and data.

[0226] When a frame containing an RSKD IE header (IE) is received, the corresponding IE can be delivered to the next higher layer to generate appropriate setting attributes for the STS, such as phyHrpUwbStsKey, phyHrpUwbStsVUpper96, phyHrpUwbStsVCounter, etc. When a frame containing an RSKD IE header fails to pass the incoming security processing, for example, when the receiver does not have a key to verify the Message Integrity Code (MIC), the RSKD IE can be delivered to the next higher layer via the HeaderIeList parameter of the MLME-COMM-STATUS.indication primitive.

[0227] Multi-node ranging

[0228] Multi-node ranging can include ranging between at least two devices. Each device can play a role in multi-node ranging.

[0229] Figure 11 This is a diagram used to describe the role of the device in the ranging process to which this disclosure can be applied.

[0230] A controller can correspond to an ERDEV that sends a Ranging Control Message (RCM) and defines ranging parameters. An RCM can correspond to a data frame that includes an Advanced Control (ARC) IE. A slave can correspond to an ERDEV that uses the ranging parameters provided by the controller via the RCM. An initiator corresponds to an ERDEV that sends the first ranging message after the RCM and initiates a ranging exchange; either the controller or the slave can be an initiator. A responder corresponds to an ERDEV that responds to a ranging initiation message received from the initiator; either the controller or the slave can be a responder.

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

[0232] For example, Figure 11 (a) shows an example in which the controller that sends the ranging control message (RCM) is the initiator that sends the ranging start message in the ranging exchange and the controller that receives the RCM is the responder that receives the ranging start message in the ranging exchange and sends the ranging response message. Figure 11 (b) shows an example in which the controller that sends the RCM is a responder that receives the ranging initiation message and sends the ranging response message in the ranging exchange, and the controller that receives the RCM is an initiator that sends the ranging initiation message in the ranging exchange.

[0233] A ranging session can be defined as a group of ERDEVs participating in a continuous ranging process configured by an initial ranging parameter set. A ranging session may consist of only one controller and at least one initiator. The controller can configure the initial ranging parameters and update the parameters during the ranging session.

[0234] Figure 12 Examples of the ARC IE, RDM IE, RBU IE, RR IE, and SRRE IE formats that can be applied to this disclosure are shown.

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

[0236] The controller can use ARC IE to send ranging configuration information to the controlled devices. ARC IE can be sent to one controller via unicast frames and to multiple controllers via broadcast frames.

[0237] The controller can use ARC IE to send its preferred ranging parameters along with a ranging change request (RCR) IE to the controller.

[0238] Each field in ARC IE can be defined as follows.

[0239] [Table 2]

[0240] [Table 3]

[0241] [Table 4]

[0242] [Table 5]

[0243] Contention-based ranging corresponds to a method where the controller is unaware of the presence or number of subjects, and accordingly, ERDEV performs ranging in a contention-based manner. Conflicts may occur, thus requiring filtering of incorrect or erroneous ranging results from higher layers. Initiators or responders can compete to perform transmissions in the appropriate time slots. When initiators and responders compete, a Ranging Contention Phase Structure (RCPS) IE can be added to the ARC IE to specify different phases in the RCM (e.g., distinguished by time slot indexes). When the RCM is received, the subject can know that it has been selected to participate in the ranging round. Time-scheduled ranging corresponds to a method where the controller is aware of all subjects and specifies the exact schedule of ranging transmissions. The controller can select participating devices, assign ranging roles (i.e., initiator or responder), and allocate time slots via a Ranging Device Management (RDM) IE. If the device roles and transmission scheduling are pre-specified via OOB signaling methods, the RDM IE can be omitted.

[0244] [Table 6]

[0245] [Table 7]

[0246] The RCM Valid Rounds field indicates the number of consecutive ranging rounds controlled by the RCM, and can be used to define the set of ranging rounds. The Multiple Message Receive Acknowledgment Request (MMRCR) field indicates whether multiple message receive acknowledgment is requested.

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

[0248] The RBD field can indicate the duration of the distance measuring block (RSTU units).

[0249] The RRD field can indicate the duration of a ranging round (range time slot unit, i.e., the number of ranging time slots in a ranging round).

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

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

[0252] When the ranging block structure is the same as the previously specified duration, at least one of the duration fields (e.g., RBD field, RRD field, RSD field) may not be present in the current RCM's ACI IE. Even in this case, other fields (e.g., scheduling mode field, STS group configuration field, etc.) can be used to update the corresponding ranging parameters.

[0253] Figure 12 (b) shows an example of the Ranging Device Management (RDM) IE format.

[0254] For a set of ranging rounds specified in the RCM using the same controller, the RDM IE can be used to exchange scheduling information between ERDEVs.

[0255] The Slot Index Use (SIU) field indicates whether the slot index of an RDM list element is used. When its value is 0, the RDM IE can be used to assign a ranging role (i.e., initiator or responder) to a controller for contention-based ranging. When its value is 1, the RDM IE can be used to allocate slots and assign a ranging role to a controller for scheduling-based ranging.

[0256] The address size field indicates the size of the address used in the RDM list field, and 0 indicates the use of a short address (16 bits), while 1 indicates the use of an extended address (64 bits).

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

[0258] The ranging role field in the RDM list can indicate whether it is an initiator or a responder. The ranging slot index field in the RDM list can indicate the slot index assigned to the device at the corresponding address. The address field in the RDM list can indicate the address of each device participating in the ranging.

[0259] Figure 12 (c) shows an example of the Ranging Block Update (RBU) IE format.

[0260] The controller can use the RBU IE to notify the controlled device of the updated ranging block structure.

[0261] The relative ranging block index field can indicate the number of ranging blocks remaining before switching to a new configuration, based on the current configuration.

[0262] The updated block duration field can indicate the duration (RSTU units) of the new ranging block.

[0263] The updated ranging round duration field can indicate the ranging round duration value, which is an integer multiple of the ranging time slot duration within the new ranging block structure.

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

[0265] Figure 12 (d) shows an example of the distance measurement rounds (RR) IE format.

[0266] The range block index field indicates the index of the range block.

[0267] The jump mode field can indicate whether jump modes are supported for the ranging block.

[0268] The round index field can indicate the round index within the ranging block.

[0269] The transmission offset field indicates the transmission offset value (RSTU units) for the ranging round within a block. The transmission offset can have a maximum value obtained by subtracting the packet duration from the maximum value of the time slot duration.

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

[0271] For the next ranging round (i.e., the ranging round in the next ranging block with block index i+1), when the controller sends the last message of the current ranging round (i.e., the ranging block with block index i) to the controlled device, RR IE can be sent in the last message to indicate the ranging round information for the ranging block with block index i+1.

[0272] When the controller sends the last message in the current ranging cycle (i.e., the ranging block with block index i), it can send RR IE in the RCM of the next ranging block with block index i+1 to indicate the ranging cycle information for the ranging block with block index i+2.

[0273] In this scenario, the RCM in the ranging block with block index i+1 can include two RR IEs. One RRIE can be applied to the ranging round of the ranging block with block index i+1, and the other RR IE can be applied to the ranging round of the ranging block with block index i+2.

[0274] Figure 12 (e) shows an example of the SP3 Ranging Request Report (SRRR) IE format.

[0275] SRRR IE can be used to request reports on AOA and / or response time and / or round-trip time measurements from the requester to the provider.

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

[0277] The Reporting in AOA (RAOA) field can indicate whether a report about AOA is requested.

[0278] The Report on Response Time (RRT) field indicates whether a report on the response time is requested.

[0279] The Round-Trip Time Report (RRTT) field indicates whether a report on round-trip times is requested.

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

[0281] The requester address field can be set to the address of the device that sends the signal to measure the AOA or initiates the ranging.

[0282] The provider address field can be set to the address of the device measuring the AOA.

[0283] Ranging block and ranging wheel structure

[0284] Figure 13 It is a diagram used to describe the ranging block structure and ranging stage to which this disclosure can be applied.

[0285] exist Figure 13 In (a), a ranging block is the duration for which ranging is performed, and a ranging block may include N ranging rounds.

[0286] The ranging round corresponds to the time it takes for the ERDEV used to participate in ranging exchange to complete the ranging measurement cycle, and a ranging round can include M ranging time slots.

[0287] The ranging time slot can correspond to a time sufficient to transmit at least one RFRAME.

[0288] The duration of a time slot and the number of time slots included in a ranging cycle may vary between different ranging cycles. Therefore, the controller can send an RCM (Regulatory Message) to the controlled device to change the ranging cycle configuration.

[0289] The ranging control message (RCM) is the first message sent by the controller and can be sent in the first time slot of a ranging cycle. The RCM may include configuration information for ranging parameters.

[0290] The Ranging Control Update Message (RCUM) corresponds to a message sent by the controller in the last time slot of the ranging round specified by the RCM, to update the ranging parameters for the next ranging round. IEs included in the RCM for updating ranging parameters can be included in the RCUM.

[0291] The Ranging Interval Update (RIUM) message corresponds to a message sent by the controller to update the interval between ranging blocks and to facilitate synchronization between participating ERDEVs. RIUM can include the scheduling time of the first RIUM, and RIUM can include the scheduling time of the next RIUM (if used) before the start of the next ranging block.

[0292] Figure 13 (b) Describe the stages in the ranging process.

[0293] The ranging control phase (RCP) corresponds to the phase in which the controller sends the RCM.

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

[0295] RIP corresponds to the phase in which the initiator sends a ranging initiation message to the responder.

[0296] RRP corresponds to the phase in which the responder sends a response message to the initiator.

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

[0298] The Measurement Reporting (MRP) phase corresponds to the phase in which ERDEV, which participates, exchanges service information related to ranging measurements.

[0299] The Ranging Control Update Phase (RCUP) corresponds to the phase in which the controller sends the RCUM. When an RCUP is present, the corresponding phase may be located in the last time slot of the set of ranging rounds specified by the RCM.

[0300] The Ranging Interval Update (RIUP) phase corresponds to the phase in which the controller sends the RIUM.

[0301] Figure 14 Examples of timing diagrams for various multi-device ranging methods to which this disclosure can be applied are shown.

[0302] Figure 14 (a) An example corresponding to OWR, Figure 14 (b) Example corresponding to SS-TWR, Figure 14(c) An example corresponding to the combination of RCP and RIP in SS-TWR, Figure 14 (d) Example corresponding to DS-TWR, Figure 14 (e) corresponds to an example of many-to-many SS-TWR, and Figure 14 (b) Example corresponding to many-to-many DS-TWR.

[0303] The ranging modes are described below.

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

[0305] In block-based mode, the average time of a ranging round is constant. In other words, in block-based mode, ranging blocks with the same duration can be executed repeatedly.

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

[0307] Figure 15 A timing diagram is shown as an example of a block-based pattern that can be applied to this disclosure.

[0308] In block-based mode, the ranging block structure can use a structured timeline. Setting up the ranging block structure can include specifying the ranging block duration (RBD), ranging round duration (RRD), and ranging slot duration (RSD) using corresponding fields based on ARC IE.

[0309] The number of ranging rounds corresponds to the value obtained by dividing the ranging block duration by the ranging round duration.

[0310] The number of ranging time slots corresponds to the value obtained by dividing the duration of the ranging round by the duration of the ranging time slot.

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

[0312] The controller can repeatedly send the ranging block structure for each RCM (e.g., via an ARC IE). When the ranging block structure needs to be changed or updated (i.e., a new ranging block duration, ranging round duration, and / or ranging slot duration), the controller can send an RBU IE for the new configuration. The RBU IE can be sent via the ranging message sequence or the last data frame in the RCM. Each time an RBU IE is sent, the controller can decrement the relative ranging block index one by one until it becomes 0. Therefore, it can be indicated whether the new configuration will be used in the next block and whether the RCM ARC IE for the next block includes the new configuration.

[0313] The index is described below.

[0314] For a ranging block, the block index of the first ranging block is given as 0, and the relative block index is determined for the remaining ranging blocks by using block index 0 as a reference.

[0315] For a ranging round, when N ranging rounds are included in a ranging block, the round index of the first ranging round in the current ranging block is given as 0, and the relative round index (e.g., 1, ..., M-1) is determined for the remaining N-1 ranging rounds by using block index 0 as a reference.

[0316] For a ranging time slot, when M ranging time slots are included in a ranging round, the time slot index of the first ranging time slot in the current ranging round is given as 0, and the relative time slot index (e.g., 1, ..., M-1) is determined for the remaining M-1 time slots by using time slot index 0 as a reference.

[0317] A new ranging message exchange can be sent / received as the first RCM in the ranging time slot of the ranging round with index 0 in the ranging block with index 0. In other words, the RCM packet can be sent at the beginning of the first ranging time slot of the first ranging round. The RCM may include RR IE to notify information associated with the ranging round within the current ranging block.

[0318] Figure 16 This is a diagram illustrating examples of various transport offsets to which this disclosure can be applied.

[0319] The RR IE included in the RCM can include transmission offset information as information associated with the ranging round within the current ranging block. In subsequent ranging rounds, the controller can initiate transmission in each time slot based on different transmission offsets. The transmission offset can be a value obtained by subtracting the UWB packet duration from the ranging time slot duration. The transmission offset can be expressed as a multiple of the RSTU.

[0320] Transmission offsets can be applied to ranging rounds. In other words, the same transmission offset can be applied to all packet transmissions included in the same ranging round. At a higher level below the controller, the transmission offset can be selected and communicated to all other devices via the RR IE. The controller can also adjust the transmission offset for each ranging round based on power reduction for interference.

[0321] One-to-many ranging process

[0322] Figure 17 An example of a message sequence diagram for one-to-many SS-TWR that can be applied to this disclosure is shown.

[0323] In ranging operations used for one-to-many TWRs, ranging exchanges can be initiated by the initiator that sends an RRMC IE, and the RRMC IE can be included in a ranging initiation message broadcast to multiple responders.

[0324] The RRMC IE with the ranging control information field set to 0 (i.e., RRMC IE (0)) can be sent as an SS-TWR ranging initiation message. The response time request field of the RRMC IE can be set to 1 to request a response time from the ERDEV response.

[0325] Each RRMC IE delivered via the MCPS-DATA.indication primitive from Responder-1 to Responder-N can signal to the next higher layer that a ranging response must be performed. Each responder can insert the RequestRrtiTxList parameter into the RRTI IE (as a response to the time request of the RRMC IE) and send the RRMC IE with the ranging control information field set to 1 (i.e., RRMC IE (1)) to the initiator. Here, the RFRAME of the response can be sent to the initiator in a unicast manner.

[0326] When the initiator receives each ranging response frame, the initiator may have enough information to calculate the Time of Frame (TOF) of the corresponding responder.

[0327] The final message broadcast by the initiator may include at least one RMI IE for measurement reporting (when an RRMC IE is requested). Multiple RMI IEs can be distinguished by the device associated with the address field. 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. When multiple responders request the same set of information as a TOF, a measurement report from the initiator can be executed through one RMI IE within the final data message.

[0328] Figure 18 An example of a message sequence diagram for SP3 one-to-many SS-TWR that can be applied according to this disclosure is shown.

[0329] At the start of a ranging round, RCM can send ranging configuration information and its associated IE. When responder-1 requests AOA and round-trip time from the initiator, SRRR IE(I, R_1) can set the RAOA and RRTT fields to 1.

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

[0331] The RDM IE in RCM can include information on allocating time slots and device roles within a ranging round. The ARC IE can specify the ranging procedure and SP3 grouping format so that the next higher layer of ERDEV can identify the start and end of the SP3 ranging phase and invoke MLME-STS primitives to enable / disable SP3 grouping before / after the ranging phase.

[0332] The RSKD IE, used to exchange a portion of the STS seed generated for initializing STS among participating ERDEVs, can be included in the RCM. Based on the ranging transmission scheduling information, the STS counter values ​​of the participating ERDEVs can be appropriately set to send and receive SP3 packets.

[0333] During the SP3 ranging phase, the next higher layer can select the SP3 grouping format by appropriately setting operations on both sides using MLME-STS.request, and can set the correct values ​​for the phyHrpUwbStsKey, phyHrpUwbStsVUpper96, and phyHrpUwbStsVCounter attributes. Because the ranging schedule is specified by the RCM preceding the SP3 ranging, the device already knows the participants. Each time slot can be assigned to a specific (E)RDEV.

[0334] During the measurement reporting phase, the initiator can send the AOA and round-trip time to the responder-1 via an RMI IE. The responder-1 can then embed the requested response time into the RMI IE sent to the initiator.

[0335] For example, in the SP3 ranging phase of a message sequence used for SP3 one-to-many DS-TWR, after receiving an SP3 frame as a ranging response message from each responder, the initiator can send an SP3 frame as a ranging completion message to each responder, with the local value of its initiator's TxRangingCounter delivered to each responder. In the measurement reporting phase, the initiator can send an RMI IE including the response time and round-trip time to the responders, and for this purpose, each responder can send an RMI IE including the AOA to the initiator.

[0336] Narrowband Assist (NBA) - UWB

[0337] In terms of MAC, NBA-UWB can be viewed as an umbrella feature comprising several semi-independent features. All these features share some common principles, and among them, the most important is strict clock synchronization between the narrowband (NB) and UWB. The NB PHY and UWB PHY should be driven by the same clock, and accordingly, no additional work is needed to determine relative accuracy. When the same clock is not applied to the NB PHY and UWB PHY, explicit requirements for relative clock drift / accuracy between the different PHYs / radios may be necessary. Based on the tight coupling between NB and UWB, the following various features can be considered for UWB.

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

[0339] - Multi-millisecond (MMS) UWB (including Secure MMS): In MMS-UWB, data exchange and the acquisition of carrier frequency offset (CFO) / sampling frequency offset (SFO) can be offloaded to the NB PHY. This enables refinement of ToF accuracy and link budget.

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

[0341] - NBA - Sensing: NB can be used for the data exchange required for multiple static sensing.

[0342] There may be some common elements that can be reused for these features, and additionally, there may be unique requirements for each feature. Given that the NBA-UWB system may operate in dense, multi-user scenarios, supporting coexistence / interference for both NB and UWB is important. Matters related to NB radio technology may include duty cycle optimization, channelization, frequency hopping, blocking channel list negotiation, and Listen-After-Talk (LBT) technology. Ranging session definitions and PHY parameters also need to be specified. The MAC service can provide an open interface to deliver scheduling, initial timing, and frequency synchronization, and to deliver configuration information obtained from the auxiliary NB to UWB operations. The MAC can be defined to provide a clear and general baseline for various use cases. Because each application may have different requirements, it may be desirable to focus on common elements across specific applications rather than trying to find a solution applicable to all situations.

[0343] The PHY may include additional and / or refined techniques to enable NBA-UWB-based features defined in the MAC. Specifically, details of O-QPSK (Offset Quadrature Phase Shift Keying) for IEEE 802.15.4 series standards, UWB, etc., may include some modifications and refinements to the NBA-UWB PHY. Alternatively, a PHY other than O-QPSK may also be used to assist UWB by utilizing open interfaces provided by MAC services.

[0344] Because O-QPSK supports good link budgets and efficient implementation, it can provide a very good benchmark for the NB aspect of UWB. The 250kbps mode (or 250k mode) can be applied as a key element for relatively optimized airtime. An exemplary refinement for O-QPSK is as follows.

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

[0346] Channelization of this band can reduce airtime for frequency hopping and other services. It can reduce preamble length and increase data rate.

[0347] - You can define the requirements for clock accuracy.

[0348] - Convolutional channel coding using predefined generator polynomials can be applied, and low-density parity-check (LDPC) coding can also be applied optionally.

[0349] For clock accuracy, an additional NB mode can be configured in the case of UWB. The carrier frequency and chip rate frequency of HRP UWB must be derived from the same reference oscillator and must have an accuracy of +20ppm to -20ppm or better. Similar optional modes can be defined for O-QPSK to utilize the characteristics of NBA-UWB.

[0350] As an O-QPSK-based PPDU format, PPDU configuration (config)-1, PPDU configuration-2, or PPDU configuration-3 can be applied. (See reference...) Figure 2 and Figure 3 The PPDU essentially includes a preamble, SFD, PHR, and payload. PPDU configuration-1 can provide a baseline for a data rate of 250 kbps, and other PPDU configurations can be optionally defined to optimize the trade-offs between air time and link budget. Additionally, a chip can have a duration of 0.5 μs, and a symbol can carry 4 bits (e.g., when forward error correction (FEC) is applied, 4 bits can correspond to coded bits). The number of chips within a symbol can be referred to as the spreading factor (SF).

[0351] For example, for a PSDU payload of size 10 bytes, the data rate is as follows, depending on the PPDU configuration and the length of each field.

[0352] - PPDU Configuration-1: Data rate = 250kbps, preamble length = 128us, SFD length = 32us, PHR length = 32us, payload length = 320us, total packet duration = 512us

[0353] - PPDU Configuration-2: Data rate = 500kbps, preamble length = 64us, SFD length = 32us, PHR length = 28us, payload length = 172us, total packet duration = 296us (a convolutional code at half rate is applied to the PHR and payload, the PHR carries 28 (= (8+6)). 2) encoded bits, and the payload carries 172 (= (80+6)). 2) Encoded bits.

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

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

[0356] [Table 8]

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

[0358] [Table 9]

[0359] The starting point for NBA-UWB PHY can be UWB PHY. For example, a dataless packet format for refining the link budget has been defined. MMS UWB can include extensions to the dataless format for further refining the link budget and Time-of-Flight (ToF) accuracy. In the corresponding packet format, short segments with a start-to-start interval of at least 1 millisecond can exist, and the entire packet can have a length spanning multiple segments. 1 millisecond can correspond to 499,200 chips.

[0360] MMS UWB packets can include multiple fragments divided into two types: ranging sequence fragments (RSF) and ranging integrity fragments (RIF).

[0361] First, the RSF is described.

[0362] Each RSF may include a repetition of the selected MMS ranging sequence (MMRS). A common MMRS can be used across all RSFs.

[0363] - Sixteen MMRS sequences based on complementary sets can be defined, each with a length of 128. Each element of the sequence can be indicated as + or -. Code indices 33, 34, ..., 48 can be assigned to each of the 16 MMRS sequences. Each MMRS sequence can be separated into two parts [A, B]. A and B can each have a length of 64. A gap G consisting of 0 to 64 zero values ​​can be added to configure MMRS sequences with gaps such as [A, G, B, G].

[0364] - Ternary codes of length 91 and 127 (e.g., codes defined in the IEEE 802.15.4z standard) can be optionally applied as MMRS. Using these ternary codes may cause more interference to nearby legacy equipment compared to the 128-length MMRS described above.

[0365] - In cases where there is or is not a gap before the repetition within an RSF, the expansion factor L=4 can be applied to MMRS.

[0366] Next, RIF will be described.

[0367] Each RIF can carry a waveform of pulses modulated in a pseudo-random manner for ranging integrity. Existing STS can be applied as a baseline for this waveform.

[0368] - The RIF can include an STS segment to which an expansion factor of L=4 is applied. Each STS segment can have the same length.

[0369] - The polarity of all STS pulses of all RIFs within an MMS UWB group can be generated in counter mode using an AES-128-based deterministic random bit generator (DRBG).

[0370] Figure 19 This is a diagram illustrating an example of MMS grouping that can be applied using this disclosure.

[0371] Figure 19 The examples in the text represent generic MMS packets with and without NB assistance. (For...) Figure 19 The permissible configurations of X, Y, and Z as indicated in the diagram are described in detail below.

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

[0373] When using MMRS based on complementary sets, the MMRS without gaps can be determined in step-1, i.e., [A, B] (where A and B are sequences of length 64 respectively); the MMRS with gaps G determined and including gaps can be obtained in step-2, i.e., S=[A, G, B, G]; and the MMRS symbol S'=[A',G', B', G' can be obtained by applying an expansion factor L=4 in step-3.

[0374] When the Ipatov sequence is used in MMRS, the MMRS symbol S' can be obtained by determining the Ipatov sequence S in step-1 and applying an expansion factor of L=4 in step-2.

[0375] N_MSR, the number of MMRS repetitions within each RSF, can be configured as a value from the set {32, 40, 48, 64, 128, 256}. Smaller values ​​of N_MSR may be advantageous due to the coexistence of short active transmissions, while larger values ​​of MSR may be advantageous for overall energy usage even without a high-performance power amplifier (PA). The value of N_MSR can be the same across all RSFs within an MMS packet.

[0376] Figure 20 This is a diagram illustrating additional examples of MMS grouping that can be applied to this disclosure.

[0377] Figure 20 The RSF-only MMS packet format in (a) can achieve efficient and fast channel impulse response (CIR) generation by using MMS coherent combining. Figure 20 In the hybrid MMS grouping format for ranging integrity in (b), the RIF can follow the RSF.

[0378] for Figure 20 The RSF-only MMS grouping in (a) can be augmented with the following set of parameters to increase processing gain.

[0379] The number of preamble fragments, X, can be configured as a value from the set {1, 2, 4, 8, 16}. The RSF-RMARKER can be defined as the peak value of the first pulse of the first RSF.

[0380] exist Figure 20 In the hybrid MMS grouping for ranging integrity in (b), the following set of parameters can be applied when the NB is used to assist in timing / frequency synchronization.

[0381] The additional RIF-RMARKER can be defined as the peak value of the first pulse and the peak value of the last pulse for each RSF. RIF-RMARKER y corresponds to the peak value of the first pulse of RIF-y, and RIF-RMARKER y' corresponds to the peak value of the last pulse of RIF-y. To increase gain, the number of RSFs X can be configured as a value from the set {0, 1, 2, 4, 8}, and the number of RIFs Y can be configured as a value from the set {1, 2, 4, 8}. X=0 may implicitly indicate MMS grouping of only RIFs.

[0382] For example, a first pattern with X=Y=1, 2, 4, 8 and a second pattern with X=1 and Y=2, 4, 8 can be defined as a baseline. Alternatively, other combinations of X and Y values ​​can be applied.

[0383] If Z=2, the additional 1ms gap between RSF and RIF can provide extra time before starting to process the fragment for integrity verification.

[0384] Figure 21 This is a diagram illustrating additional examples of MMS grouping that can be applied to this disclosure.

[0385] Figure 21 (a) represents an example of a UWB-only mixed MMS packet that includes RSF if X>0, and Figure 21 (b) represents an example of a UWB-only mixed MMS grouping that includes only RIF if X=0 and Y>0.

[0386] When the NB is not used to report timing / frequency synchronization, the following set of parameters can be applied to hybrid MMS packets for ranging integrity.

[0387] As in Figure 21 As in the example, SYNC and SFD can be included in the MMS group.

[0388] The additional RIF-RMARKER can be defined as the peak value of the first pulse and the peak value of the last pulse for each RIF.

[0389] X can be configured as a value from the set {0, 1, 2, 4, 8}, and Y can be configured as a value from the set {0, 1, 2, 4, 8}. Here, Y=0 is allowed when ranging integrity is not provided. X=0 and Y=1 can be defined as the default configuration to facilitate interoperability. If X>0, an additional 1ms interval between the RSF and RIF if Z=2 can provide additional time before starting to process the fragment for integrity verification.

[0390] Further refinement methods can be applied to compare with existing MMS ranging, which are used to achieve link budget refinement for better interference detection and ranging performance for NBA-UWB technology and for UWB wireless technology alone.

[0391] NBA-UWB Distance Measurement

[0392] First, the NBA-MMS-UWB ranging measurement cycle is described.

[0393] 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 can operate as a controller, and the responder can operate as a controlled device. However, it does not exclude the possibility that the initiator is a controlled device and the responder is a controller.

[0394] In NBA-MMS-UWB ranging, applications such as Figure 13 and Figure 15 The structure of the ranging blocks and ranging cycles described herein can be applied using a block-based pattern. The ranging block structure for NBA-MMS-UWB can be set up by specifying the ranging block duration, ranging cycle duration, and ranging time slot duration.

[0395] The time unit used to specify the duration of ranging blocks and ranging rounds is RSTU. The ranging device can implement a ranging block structure to ensure that the tolerance for the ranging block duration used for the PHY clock is between +100ppm and -100ppm. A ranging round corresponds to a period of time sufficient to complete a full ranging measurement cycle. Initiators and responders can use one or more ranging rounds from the first ranging block of a ranging session and can repeat the same ranging round usage pattern in subsequent ranging blocks. Round transitions can be applied in NBA-MMS-UWB ranging sessions, but transmission offsets cannot be applied.

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

[0397] The ranging measurement cycle can be uniquely identified by the ranging block index and the ranging round index. In NBA-MMS-UWB ranging, the ranging measurement cycle may include the ranging control phase, the ranging phase, and the measurement reporting phase (in-band / out-of-band).

[0398] exist Figure 13 (b) Of the ranging rounds comprising the ranging control phase, ranging phase, and measurement reporting phase, the ranging control phase and the ranging phase are mandatory in the NBA-MMS-UWB ranging measurement cycle. The measurement reporting phase can be optionally supported via in-band wireless technology (e.g., NB, UWB) or OBB. When provided via in-band, the ranging round length can be configured to include the ranging control phase, the ranging phase, and the measurement reporting phase. When provided via OBB, the ranging round length can be configured to include both the ranging control phase and the ranging phase.

[0399] The control and reporting messages used in the NBA-MMS-UWB ranging measurement cycle are described.

[0400] - The polling message is an NB message sent by the initiator in the first time slot of the ranging round to initiate the ranging measurement cycle within the ranging round.

[0401] - A response (RESP) message is an NB message sent by the responder at the beginning of a subsequent ranging slot after the first ranging slot in response to a received polling message.

[0402] - A Report (RPRT) message is an NB message sent by one of the initiators or responders to report ranging measurement results to a peer.

[0403] The NB O-QPSK 250kbps PHY can be used as the default for sending control and report messages. Other NB and UWB PHYs can be optionally supported.

[0404] Figure 22 Examples of the NBA-MMS-UWB ranging control phase, ranging phase, and measurement reporting phase that can be applied according to this disclosure are provided.

[0405] Figure 22 (a) represents an example of the NBA-MMS-UWB ranging control phase.

[0406] The NBA-MMS-UWB ranging control phase can be executed at the beginning of the NBA-MMS-UWB ranging measurement cycle and can include at least two ranging control time slots.

[0407] The initiator can initiate the NBA-MMS-UWB ranging control phase by sending a polling message to the responder at the beginning of the first ranging time slot of the ranging round. When LBT is not enabled or otherwise compliant with the NBA LBT, the initiator can extend the polling transmission to the maximum extent possible during the duration of RcpPollSlot. A responder that successfully receives the polling message can send a response message to the initiator from the ranging time slot following RcpPollSlot after the start of the ranging control phase. When LBT is not enabled or otherwise compliant with the NBA LBT, the responder can extend the response transmission to the maximum extent possible during the duration of RcpResponseSlot. A responder that successfully sends a response message can enter the ranging phase by continuing the NBA-MMS-UWB ranging measurement cycle. An initiator that successfully receives a response message can enter the ranging phase by continuing the NBA-MMS-UWB ranging measurement cycle.

[0408] Polling messages can provide carrier frequency coherence from the initiator to the responder device. Additionally, control information can be sent from the initiator to the responder via polling messages. For example, a polling message may include information requesting the responder to report the number of recommended segments (RNF) during the measurement reporting phase.

[0409] Response messages can provide carrier frequency coherence from the responder to the initiator device. Additionally, control information can be sent from the responder to the initiator via response messages.

[0410] When LBT is enabled before a transmission in the corresponding working band, the transmitting device may perform LBT before the expected transmission begins. If the performed LBT does not allow transmission at the beginning of the ranging time slot, the transmitting device may not initiate additional transmissions during the remaining time period of the ranging round.

[0411] The initiator may terminate the NBA-MMS-UWB ranging measurement cycle when at least one of the following conditions is met: - When LBT does not allow the transmission of polling messages; - When the initiator does not receive a response message in the expected ranging time slot; or - When all ERDEVs request to skip ranging of the current ranging block during the ranging control phase.

[0412] The responder can terminate the NBA-MMS-UWB ranging measurement cycle when at least one of the following conditions is met: - When no polling message is received at the start of the expected ranging round; - When LBT does not allow the transmission of response messages; or - When all ERDEVs request to skip ranging for the current ranging block during the ranging control phase.

[0413] When terminated before the ranging measurement cycle is completed, the ERDEV involved may stop NB and UWB transmissions until the next ranging measurement cycle.

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

[0415] The NBA-MMS-UWB ranging phase can begin when the NBA-MMS-UWB ranging control phase is terminated.

[0416] The initiator can enter the ranging phase and begin transmitting the first UWB RSF segment after the RpInitiatorRsfOffset time slot. The initiator can continue transmitting at regular intervals of 1200 RSTUs until X UWB RSF segments are transmitted. The initiator can enter the ranging phase and begin transmitting the first UWB RIF segment after the RpInitiatorRifOffset time slot. The initiator can continue transmitting at regular intervals of 1200 RSTUs until Y UWB RSF segments are transmitted.

[0417] The initiator can enter the ranging phase and begin transmitting the first UWB RSF segment after the RpResponderRsfOffset time slot. The initiator can continuously transmit up to X UWB RSF segments at regular intervals of 1200 RSTU. The initiator can also enter the ranging phase and begin transmitting the first UWB RIF segment after the RpResponderRifOffset time slot. The initiator can continue transmitting up to Y UWB RSF segments at regular intervals of 1200 RSTU.

[0418] The duration of the entire ranging phase can correspond to RpDuration time slots.

[0419] After an ERDEV, acting as either an initiator or a responder, completes the reception of all UWB segments during the ranging phase, a ranging measurement report can be generated when the corresponding ERDEV is requested to send a measurement report to the peer. Therefore, the value of RpDuration can be set to allow sufficient time before the subsequent measurement reporting phase.

[0420] When the in-band NBA-MMS-UWB measurement reporting phase is enabled for the ranging cycle, ERDEVs that have completed the ranging phase can enter the measurement reporting phase based on the following conditions: - When a measurement report needs to be sent to a peer during the measurement reporting phase and the measurement report is successfully generated; or - When it is expected that a measurement report will be received from a peer during the measurement reporting phase.

[0421] When the NBA-MMS-UWB ranging report cycle is not included in the NBA-MMS-UWB ranging measurement cycle, the relevant ERDEV can end the ranging measurement cycle after completing the ranging phase. ERDEVs that need to send measurement reports to peers can either forward the reports to the next higher level or request the next higher level to send the reports to the peer.

[0422] Figure 22 (c) represents an example of the NBA-MMS-UWB measurement reporting phase.

[0423] In-band measurement reports can be sent during an optional measurement reporting phase. When enabled, the in-band measurement reporting phase can be initiated at the start of the ranging phase.

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

[0425] The reporting phase may include at least one packet time slot. The duration of the first time slot in the reporting phase may be the duration of MrpFirstSlot. The duration of the second time slot in the reporting phase may be the duration of MrpSecondSlot.

[0426] When the reporting phase includes only one packet slot, the initiator or responder can send a measurement report packet in the corresponding slot. The reporting mode can be configured to determine whether the device sending the report packet is an initiator or a responder.

[0427] When the reporting phase includes two packet slots, the responder can send the report packet in the first slot, and the initiator can send the report packet in the second slot.

[0428] The measurement reporting phase may include one-way or two-way report exchange. The transmission of report packets can be scheduled in the first two ranging time slots of the measurement reporting phase, depending on the following configuration mode: [Table 10]

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

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

[0431] If an ERDEV fails to send a measurement report during its allocated time slot in the measurement reporting phase, it may delay or retry the transmission by using a higher layer or by using OOB radio technology. If an ERDEV does not receive a measurement report during its allocated time slot in the measurement reporting phase, it may request a retransmission by using a higher layer or by using OOB radio technology until the start of the next MMS ranging cycle in the subsequent ranging block.

[0432] NBA-MMS-UWB Initialization and Setup

[0433] The NBA-MMS-UWB ranging session can be configured using a set of parameters for the PHY and MAC. The PHY parameter set can include NB and UWB channels, modulation, data rate, etc., used during the control, ranging, and measurement reporting phases. The MAC parameter set can include time slots, rounds, and block configurations used during the control, ranging, and measurement reporting phases.

[0434] To initiate an NBA-MMS-UWB ranging session, a pair of initiator and responder devices may be involved in negotiating a ranging configuration that differs from the default parameter set used in the initialization and setup phases. OOB communication can be used to set session parameters or change the initialization channel and modulation, which can be performed even before the initialization and setup phases.

[0435] Figure 23 It is a diagram used to describe the initialization and setup of a ranging session that can be applied to this disclosure.

[0436] First, the initialization of the ranging session is described.

[0437] Before entering the ranging control phase, ERDEVs can be involved in the initialization and setup phases. The initialization and setup phases provide time synchronization for the first polling packets to be sent by the initiator during the upcoming ranging control phase. Additionally, the ranging session configuration can be changed by exchanging bidirectional handshake packets between ERDEVs. Unless negotiated during initialization and setup, default ranging configuration parameters can be used for the ranging session. Alternatively, the ranging session configuration can be set up using OOB radio technology.

[0438] To establish in-band initialization, ERDEV can opportunistically perform transmit and receive operations on a dedicated initialization channel and PHY modulation, as given by the ranging session configuration. The initiator can opportunistically send Advertisement Polling (ADV-POLL) packets at times and intervals it deems appropriate, as supported by higher-layer functions. Similarly, the responder can opportunistically listen for incoming ADV-POLL packets.

[0439] After sending an ADV-POLL packet on the initialization channel, the initiator can listen for incoming Advertisement Response Packets (ADV-RESP) in subsequent ranging slots. When the responder receives an ADV-POLL, it can send an ADV-RESP in a subsequent ranging slot. When the responder sends an ADV-RESP, it can listen for Start of Ranging (SOR) packets in the ranging slot following the ADV-RESP packet. When the initiator receives an ADV-RESP packet, it can send an SOR packet in the ranging slot following the ADV-RESP packet.

[0440] After sending the SOR packet, the initiator can enter the ranging control phase. During the ranging control phase, after the initiator acknowledges receipt of the RESP packet from the responder, and unless additional ERDEV needs to be initialized, the initiator can abort ranging initialization and stop transmitting ADV-POLL packets.

[0441] For the initial handshake setup, the responder (or controller) can request ranging session configuration in ADV-RESP. The initiator (or controller) can receive the request from the responder through ADV-RESP, set up the session configuration, and send the corresponding session configuration to the responder via SOR.

[0442] For ranging session configuration, the ranging block structure and ranging measurement period can be configured before the NBA-MMS-UWB ranging session begins. During ranging setup, ranging parameters cannot be changed, or a higher-level layer can apply default parameters to the ranging session configuration. During the NBA-MMS-UWB ranging session, a higher-level layer can update some parameters used for the ranging block structure and ranging measurement period. For each parameter update, the higher-level layer can instruct the new parameters to become the index of a valid ranging block.

[0443] Initiators and responders can use parameters set or updated by each next higher layer as long-term operating parameters.

[0444] The initiator can rewrite the long-term operating parameters of the ranging measurement cycle during the ranging control phase by indicating a new set of short-term parameters. Short-term parameters can be effectively applied only to the immediate ranging measurement cycle. Unless rewritten again during the ranging control phase, the long-term operating parameters can likely be effectively restored in the next ranging measurement cycle.

[0445] The responder can request short-term operating parameters for the next ranging measurement during the ranging control phase. The initiator can provide or ignore the parameters in the next ranging cycle based on the responder's request.

[0446] Common parameters for NBA-MMS-UWB ranging sessions may include a range or options and default values ​​for configurable values ​​used to initialize channels, allowed lists for control and reporting channels, UWB control channels and preambles, PHY rate, NBLBT channels, whether to apply round transitions, channel switching methods, etc. Block structure parameters may include a range or options and default values ​​for configurable values ​​for ranging block duration, ranging round duration, ranging time slot duration, etc. The ranging measurement cycle parameters may include a range or options and default values ​​for configurable values ​​of RcpPollSlot and RcpResponseSlot for the ranging control phase; the number of RSF segments (X), the number of RIF segments (Y), RpDuration, RpInitiatorRsfOffset, RpResponderRsfOffset, RpInitiatorRifOffset, RpResponderRifOffset, RSF code index, RSF complement set, RIF segment length in 512-chip units, N_MSR; and for the measurement report, in-band reporting, reporting mode, MrpFirstSlot, MrpSecondSlot, etc.

[0447] NBA-MMS-UWB Control Channel Messages

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

[0449] A compressed PSDU format can be defined to include only a 1-8 byte header, which includes a message ID. All remaining PSDU content can be determined from the message ID. The table below shows examples of compressed PSDU formats used during the initialization, setup, control, and reporting phases. Compressed PSDU messages can be encapsulated within a header IE of a specific data field type.

[0450] [Table 11]

[0451] In the control phase messages, the POLL message can correspond to a polling message used for qualifying, and the RESP message can correspond to a response message used for qualifying. For the POLL2 message, after receiving the NbaChannelMap from the initiator, the responder must be able to determine the NbaChannelAllowList and can apply the corresponding list to allocate NB channels for each ranging. Various other polling messages can be further defined.

[0452] In the measurement reporting phase, RPRT messages from the responder and the initiator are defined with different message IDs, and the RPRT2 message can be used during the session control process. Message ID values ​​from 0x04 to 0x1f can be reserved for both the session control and reporting phases.

[0453] In the initialization phase messages, message ID values ​​0x23 to 0x2f can be reserved for out-of-session purposes.

[0454] Define additional message ID values ​​0x7f to 0xff for vendor-specific message content, and additional message ID values ​​0x7f to 0xff can correspond to 128x256 PSDUs with 2-byte message IDs.

[0455] In the compressed PSDU message fields, the CRC16 field is defined as 16 bits in length and can correspond to a Frame Check Sequence (FCS) of 2-8 bytes in length. The ADDR field can correspond to the address field. The compressed PSDU message may also include various other fields.

[0456] UWB Channel Usage Coordination

[0457] To reduce mutual interference between adjacent UWB transmitters and support good coexistence, coordination of UWB channel (CH) usage can be applied. UWB transceivers can be of various types, including NBA-UWB transceivers and UWB standalone transceivers. For example, coordination of UWB channel usage between NBA UWB transceivers can be performed by mirroring (or initializing) the channel. The following describes a method for coordinating UWB channel usage that can be applied to both NBA UWB transceivers and UWB standalone transceivers.

[0458] Unless otherwise stated in the description below, UWB transceivers refer to NBA UWB transceivers, UWB standalone transceivers, or both. Signaling for UWB channel usage coordination may need to be decoupled from other UWB sessions on the corresponding UWB transceiver. This UWB channel usage coordination may be substantially or optionally supported in the UWB transceiver. For example, transmitting coordination signals may be substantially / optionally, and operating based on information received via coordination signaling may also be substantially / optionally.

[0459] Figure 24 This is a diagram illustrating examples of AP transmit and receive operations that can be applied using this disclosure.

[0460] As in Figure 24In the example of (a), the initiator, acting as a UWB transceiver, can periodically transmit UWB-acquire packets (APs) on a predefined UWB discovery channel. The UWB-APs can include information that can be used to determine all future UWB channel usage for the corresponding initiator. A UWB transceiver can discover the corresponding initiator by receiving UWB-APs. The UWB-AP interval can be configured to an appropriate value (e.g., depending on the use case). During the periodically transmitted UWB-APs, some UWB-APs may be skipped due to ranging overlap. Figure 24 In example (a), n, n+1, n+2, ... can correspond to the NBA-UWB ranging block index.

[0461] As in Figure 24 In the example of (b), the UWB receiver (Rx) can optimize its UWB-AP scanning of the NBA UWB transceiver. The NBA UWB initiator can periodically transmit NB-APs on a predefined NB discovery channel. NB-APs can include information that can be used to determine the occurrence of an immediate UWB-AP. NB-APs can also include information that can be used to determine all future UWB channel usage for the corresponding 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. During the periodically transmitted NB-APs, some NB-APs may be skipped due to ranging overlap.

[0462] Figure 25 and Figure 26 This diagram illustrates examples of AP transmit and receive operations that can be applied in various RANs according to this disclosure.

[0463] exist Figure 25 and Figure 26 In the example, it is assumed that the ranging area network (RAN)1 includes an initiator (RAN1 initiator) and at least one responder (RAN1 responder), and is currently in ranging operation. It is assumed that RAN2 includes an initiator (RAN2 initiator) and at least one responder (RAN2 responder), and is either starting up or in operation.

[0464] exist Figure 25 In the example, the RAN1 initiator can periodically transmit NB-AP and UWB-AP on the NB discovery channel and the UWB discovery channel. Therefore, the RAN1 responder can perform ranging operations on the UWB channel determined based on the information included in the NB-AP and UWB-AP by being enabled in the first round of ranging in each ranging block.

[0465] The RAN2 initiator can receive NB-APs and UWB-APs transmitted by the RAN1 initiator. For example, the RAN2 initiator can receive NB-APs transmitted by the RAN1 initiator during the NB ScanWin window and subsequently receive UWB-APs transmitted by the RAN1 initiator during the UWB ScanWin window. Therefore, the RAN2 initiator can obtain / retrieve RAN1 information (e.g., per-session information). For example, RAN1 information may include information about ranging blocks, rounds, and slot durations; information about RF channel and preamble usage; information about synchronization parameters, etc. Based on this RAN1 information, the RAN2 initiator can begin its ranging and advertising sessions at times that do not overlap with RAN1. Therefore, the RAN2 initiator can periodically transmit NB-APs and UWB-APs.

[0466] exist Figure 26 In the example, the RAN1 initiator can periodically send an NB-AP upon NB discovery. Therefore, the RAN1 responder can perform ranging operations on the UWB channel determined based on the information contained in the NB-AP by being enabled in the first round of ranging in each ranging block.

[0467] The RAN2 initiator can receive NB-APs sent by the RAN1 initiator. For example, the RAN2 initiator can receive NB-APs sent by the RAN1 initiator during the NB ScanWin window. Accordingly, the RAN2 initiator can obtain / retrieve RAN1 information (e.g., information about the RAN's active periods). For example, information about RAN1's ​​active periods may include information about the remaining time (e.g., dT2) before the start of an active period (or active round), information about the duration of an active round, etc. Based on this RAN1 information, the RAN2 initiator can select an idle period that does not overlap with the RAN1's ​​active periods to start its new session. Accordingly, the RAN2 initiator can periodically send NB-APs.

[0468] The NB-AP and UWB-AP formats are described below.

[0469] Both NB-AP and UWB-AP formats can include, as referenced... Figure 2 The SHR, PHR, and PHY payload fields (i.e., PSDU) are described. The PHR field can indicate the length of the PSDU, for example, a value in the range of 0 to 127 bytes. The PSDU may include the MAC header (MHR) field, the MAC payload field, and the MAC footer (MFR) field. O-QPSK can be applied to the NB-AP packet type, and BPRF can be applied to the UWB-AP packet type.

[0470] NB-APs can have a compact frame format corresponding to compressed PSDUs. A compact frame may include a 3-bit frame type field, a 5-bit compact frame ID field, and a variable-size compact frame content field. The compact frame (or compact frame acquisition) format used for the AP may include a 3-octet address field, a 1-octet message control field, a variable-size message content field, and a 2-octet FCS field.

[0471] The MHR field of an AP can include the following information.

[0472] [Table 12]

[0473] The MAC payload field of a UWB-AP can include the following information.

[0474] [Table 13]

[0475] A per-session information field can exist in a coordinated UWB-AP. The initiator of a newly launched RAN can minimize conflicts with existing RANs by selecting at least one parameter of the per-session information field as a different value.

[0476] The MAC payload field of an NB-AP can include the following information.

[0477] [Table 14]

[0478] Compressed coordinated NB-AP packets do not include a per-session information field. Coordinated NB-AP may include a per-session information field. The per-session information field may overlap with the information field of coordinated UWB-AP. When the value of the UWB-AP presence field is 1, the UWB-AP information field is included in the NB-AP, and when its value is 0, the UWB-AP information field is not included in the NB-AP.

[0479] Refer again Figure 25 The Delta T parameter in the UWB-AP information field of the NB-AP indicates the time length (dT1) from the start of the NB-AP to the start of the UWB-AP. Additionally, the UWB channel parameter in the UWB-AP information field indicates the UWB channel on which the UWB-AP is transmitted after time dT1.

[0480] The UWB session information field may or may not be included in the NB-AP. Whether the UWB session information field is included in the NB-AP and what information is included in the UWB session information field can be indicated by the UWB per session information type field of the NB-AP. The UWB session information field can exist in the NB-AP regardless of whether UWB-AP is being transmitted. Four types can be applied to the UWB session information field.

[0481] When the value of the UWB per session information type field is 0, the UWB session information field does not exist in NB-AP.

[0482] When the value of the UWB per session information type field is 1, the NB-AP can contain a UWB session information field and can include the minimum set of session information as shown below.

[0483] [Table 15]

[0484] When the value of the UWB per session information type field is 2, the UWB session information field can exist, and information about the start time and duration of the activity period can be included in the NB-AP.

[0485] [Table 16]

[0486] Refer again Figure 25 The length of time (dT2) from the start of the NB-AP session to the start of the activity period 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 activity period can be indicated by the value of the Activity Period Duration field in the Per Session Information field of the NB-AP.

[0487] When the value of the UWB per-session information type field is 3, the UWB session information field can exist, and information about the start time and duration of the active rounds in the block can be included in the NB-AP.

[0488] [Table 17]

[0489] Refer again Figure 25The time length (dT2) from the start of NB-AP to the start of a block can be indicated by the value of the Delta T parameter in the per-session information field of NB-AP. Additionally, for the position and duration of active rounds, the active round can be indicated by the index of the active round in a bitmap based on the length of the number of rounds included in a block (the number of rounds in the block parameters) and the number of inactive rounds between the start of the block and the start of the active round (in...). Figure 25 In the example, it starts after the same amount of time (round duration parameter) elapses (0 in the example).

[0490] Initial setup and channel usage coordination

[0491] As mentioned above, NBA-UWB can provide technologies such as mirroring (or initialization) channels, NBA-MMS-UWB, NBA TDoA, and NBA-sensing. NBA-UWB can use NB (e.g., 2.5MHz bandwidth) channels in bands such as UNII-3 and UNII-5 to assist UWB operation. The specific characteristics of the NB correspond to the in-band technologies defined by the IEEE 802.15.4 series of standards.

[0492] As described above for NBA-MMS-UWB, the NB channel can be used to improve the link budget of UWB. In NBA-MMS-UWB ranging rounds, the in-band measurement report phase (MRP) can be defined as an optional configuration, and correspondingly, the ranging rounds can include a ranging control phase (RCP) and a ranging phase (RP) as required configurations. Furthermore, the frames / packets and durations exchanged between devices in RCP, RP, and MRP are related to the reference... Figure 22 The same as described in [the text].

[0493] If passed Figure 23 As described for NBA-MMS-UWB initialization and setup, time synchronization information for the first polling packet sent by the initiator in RCP can be provided. Additionally, to begin an NBA-MMS-UWB ranging session, the initiator and responder need to perform discovery (or initialization) and setup procedures to negotiate a ranging configuration different from the default parameter set.

[0494] For the UWB native discovery (or initialization) and setup process described above, the initiator can periodically broadcast ADV-POLL packets on the discovery (or initialization) channel. In the case of devices with NBA-UWB capability, the discovery (or initialization) channel for broadcasting ADV-POLL can be an NB channel, and in the case of devices that do not support NBA-UWB, the discovery (or initialization) channel for broadcasting ADV-POLL can be a UWB channel.

[0495] In addition, for passing Figures 24 to 26 The described UWB channel uses coordination, similar to the NBA-MMS-UWB discovery (or initialization) and setup process, and can periodically broadcast APs (acquired packets) including network scheduling information on the discovery (or initialization) channel.

[0496] As in Figure 24 and Figure 25 As described in the example, the UWB-AP can be advertised after the NB-AP sends a message including a UWB information field. The UWB information field may include information such as the UWB channel in which the UWB-AP operates, delta T (i.e., the remaining time until the next UWB-AP advertisement based on the current packet), the preamble used by the UWB-AP, and so on. The UWB-AP may also include a per-session information field (e.g., coordination information used by the UWB channel) to be notified to other controllers.

[0497] Coordinated use of UWB channels with UWB-AP Figure 24 and Figure 25 The examples are different, in Figure 26 In the example, the UWB-AP is not broadcast, and it does not use the NB-AP, but only the NB-AP. Therefore, the NB-AP does not include the UWB-AP information field, but it may include a per-session information field (e.g., the UWB channel uses coordination information) to be notified to other controllers.

[0498] The ADV-POLL used in the discovery (or initialization) and setup operations, as well as the AP used in channel usage coordination, serve different purposes but are typically broadcast on the discovery (or initialization) channel. Because the number of NB discovery (or initialization) channels and / or UWB discovery (or initialization) channels is limited (e.g., 1 or 2), broadcast packets may be more prone to collisions when more UWB devices simultaneously perform discovery (or initialization) and setup operations and channel usage coordination operations. The performance of discovery (or initialization) and setup operations and / or channel usage coordination operations may degrade when broadcast packets fail to be correctly delivered to the desired receiving device due to collisions. A new method is needed to prevent this performance degradation.

[0499] The following describes various examples of this disclosure of optimization discovery (or initialization) and setup operations, as well as channel usage coordination operations.

[0500] In some embodiments of this disclosure, a new response message (e.g., an ADV-RESP message) may be defined that supports requests for Channel Usage Information (CUI) during discovery (or initialization) and setup. The new response message may correspond to a response to an announcement message (e.g., an ADV-POLL message).

[0501] Figure 27 This is a diagram illustrating examples of the notification message format and response message format according to this disclosure.

[0502] Figure 27 (a) An example of the 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 indicating the presence of the device broadcasting it. When the address information of the device sending the ADV-POLL is included in the header, the ADDR field can be omitted from the PSDU, and the ADV-POLL size can be reduced accordingly.

[0503] Figure 27 (b) An example of the ADV-POLL IE format (e.g., UWB case). The UWB header IE block 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, such as 0x80). The type field may be set to 0.

[0504] ADV-POLL messages / packets during discovery / initialization and setup can be broadcast on the NB discovery / initialization channel or the UWB discovery / initialization channel. Additionally, Acquisition packets (AP) during channel usage coordination can also be broadcast on the NB / UWB discovery / initialization channel. AP messages / packets can be broadcast to notify other controllers of the scheduling information of the RAN to which the initiator belongs, and can include fields as shown in Tables 13 to 17 above.

[0505] Due to channel congestion and collisions when ADV-POLL and AP are broadcast on the same NB / UWB discovery / initialization channel, performance degradation is expected during the channel usage coordination process, as well as during discovery / initialization and setup. To prevent this problem, refinement of UWB advertisement packets supporting concurrent ranging session initiation and channel usage coordination can be considered. An example of refining response messages (e.g., ADV-RESP) to advertisement messages is described below.

[0506] A responder can become aware of an initiator's presence by receiving an ADV-POLL packet broadcast by the initiator during the discovery (or initialization) and setup processes. After receiving the ADV-POLL, a two-way handshake can be performed. The responder can send an ADV-RESP to the ADV-POLL, the initiator receiving the ADV-RESP can send an SOR, and the responder can participate in a ranging session. By utilizing this two-way handshake, the notification packet is not limited to discovery (or initialization) and setup, but can also be used for channel usage coordination. For example, based on the information included in the ADV-RESP sent by the responder, a ranging session can be initialized or channel usage information can be requested.

[0507] Figure 27 (c) An example of the 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 can be set to the address value of the responder. When the address information of the device sending the ADV-RESP is included in the header, the ADDR field can be omitted from the PSDU, and correspondingly, the ADV-RESP size can be reduced. Here, unlike the existing ADV-RESP format in which one octet is reserved between the ADDR field and the CRC field, the ADV-RESP format according to this disclosure includes a new request mode field.

[0508] Figure 27 (d) shows an example of the ADV-RESP IE format (e.g., the 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 the ADV-RESP (e.g., one of 0x80 to 0xFF, such as 0x81). The type field may be set to 0. Here, unlike the existing ADV-RESP format in which the two octets following the ADDR field are reserved (i.e., RFU), the ADV-RESP format according to this disclosure includes a new request mode field.

[0509] The request mode field included in the ADV-RESP described above may include information indicating whether the responder requests the establishment of a ranging session or information for channel usage coordination. The initiator (i.e., the advertising device) that receives the ADV-RESP including this request mode field may send a SOR or CUI based on the value of the request mode field and may execute a subsequent frame exchange sequence.

[0510] For example, the request mode field can be defined to have a size of 2 bits. When the request mode field is set to the first value (e.g., 00), it can indicate a request for a ranging session. When the request mode field is set to the second value (e.g., 01), it can indicate a request for channel use of Coordination Information (CUI). The third value (e.g., 10) and the fourth value (e.g., 11) of the request mode field can be defined or reserved for other purposes.

[0511] Alternatively, the request mode field can be defined as having a size of 1 bit. When the request mode field is set to a first value (e.g., 0), it can indicate a request for a ranging session. When the request mode field is set to a second value (e.g., 1), it can indicate a request for channel use of Coordination Information (CUI).

[0512] In some embodiments of this disclosure, message exchange between an initiator and a responder can be defined based on response messages that include a request pattern field.

[0513] Figure 28 This is a diagram illustrating an example of message exchange between an initiator and a responder, based on this disclosure.

[0514] Figure 28 (a) illustrates an example of a two-way handshake process when the value of the request mode field included in the ADV-RESP sent by the responder in response to an ADV-POLL sent by the initiator is the first value. When the request mode is the first value, it indicates that the responder is requesting the establishment of a ranging session, and therefore the initiator can send an SOR message. Operations can be performed on subsequent ranging channels, such as via a reference. Figure 23 As described.

[0515] Figure 28 (b) illustrates an example of a two-way handshake process when the value of the request mode field included in the ADV-RESP sent by the responder in response to an ADV-POLL message sent by the initiator is the second value. When the request mode is the second value, it indicates a request for the initiator's Channel Usage Information (CUI), so the initiator can send a CUI message. For example, the CUI message may include some or all of the information illustrated in Tables 13 to 17 above.

[0516] Here, the responder can belong to the same RAN as the initiator, or it can belong to a different RAN. For example, Figure 28 The initiator in (b) can correspond to initiator 1 of RAN1, and Figure 28 The responder in (b) can correspond to initiator 2 of RAN2. The responder (or initiator 2 of RAN2) can request channel usage information from the initiator (e.g., initiator 1 of RAN1) to avoid collisions.

[0517] Figure 28 (c) represents an example where an initiator broadcasts a CUI message. For example, an initiator may broadcast a CUI message taking into account its state (e.g., resource state, etc.), channel state, etc., to allow other neighboring devices to obtain its channel usage information. The other devices that obtain the CUI may be initiators in another RAN. For example, a CUI related to RAN1 broadcast by initiator 1 belonging to RAN1 may be obtained by devices belonging to another RAN (or another RAN that is starting up or operating) (e.g., initiator 2 belonging to RAN2 and / or initiator 3 belonging to RAN3) and may be used for the RAN configuration of the other device.

[0518] For example, when the value of the request mode field included in the ADV-RESP sent by a responder (or initiator 2 of another RAN) in response to an ADV-POLL sent by initiator 1 is the second value, initiator 1 can broadcast a CUI. Therefore, other neighboring devices (e.g., initiator 3) and the responder that sent the response message may also obtain the CUI of initiator 1. Specifically, initiator 3 can opportunistically scan for CUI messages from initiator 1. In this way, even without performing a two-way handshake process by receiving an ADV-POLL message and responding to an ADV-RESP message, initiator 3 can obtain CUI information associated with another initiator (or another RAN) and use it to change the channel of RAN3 that is starting or operating RAN3. For example, initiator 3 can select / determine the channel associated with RAN3 by avoiding (i.e., avoiding overlap) the channel associated with initiator 1 (or RAN1).

[0519] For example, initiator 2 and initiator 3 may obtain the same CUI from initiator 1 and use it to select / determine channels associated with their respective RANs (or by avoiding channels associated with initiator 1 / RAN1). In this case, when initiator 2 and initiator 3 do not have information about each other's channels, they may attempt to access the same UWB medium simultaneously. This conflict can be avoided or reduced using backoff timers, random delay timers, etc. For example, a device attempting to access a channel selected based on a CUI broadcast by another device (or by avoiding a CUI broadcast by another device) can select a backoff / random delay timer based on predetermined rules and perform access to the corresponding channel when the timer expires.

[0520] Figure 29 This illustrates an example of concurrent exchange of coordination information and ranging sessions between devices belonging to different RANs according to this disclosure.

[0521] exist Figure 29 In the example, it is assumed that initiator 1, responder 1, and responder 2, belonging to RAN1, are in ranging operations, and responder 3 is performing a UWB scan. Additionally, it is assumed that there is an initiator 2 that is starting or operating another RAN (e.g., RAN2).

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

[0523] Responder 3 can perform a scan on the discovery (or initialization) channel to participate in the ranging session of RAN1. During the scan, responder 3, upon discovering / receiving an ADV-POLL sent from initiator 1, can send an ADV-RESP to initiator 1. Here, the value of the request mode field included in the ADV-RESP sent by responder 3 can be set to a first value (i.e., requesting a ranging session). When initiator 1 receives the ADV-RESP from responder 3 and the request mode field indicates the first value (i.e., requesting a ranging session), it can send a SOR to responder 3 in response. Responder 3, upon receiving the SOR, can participate in the ranging session in the next ranging block. For example, responder 3 can determine that ranging round 1 is an active round in ranging block n+1 based on the time offset, ranging channel information, etc., included in the SOR, and can begin participating in RAN1 in time slot 3 among active time slots 1, 2, and 3 within the active ranging round.

[0524] Initiator 2, which is initiating or operating RAN2, can scan and discover (or initialize) channels for channel usage coordination. Initiator 2, having discovered / received an ADV-POLL sent by Initiator 1, can send an ADV-RESP to Initiator 1. Here, the value of the Request Mode field included in the ADV-RESP sent by Initiator 2 can be set to a second value (i.e., Request Channel Usage Information (CUI)). When Initiator 1 receives an ADV-RESP from Initiator 2 and the Request Mode field indicates the second value (i.e., Request CUI), it can send a CUI to Initiator 2 in response. Upon receiving the CUI, Initiator 2 can schedule / configure the ranging session and ranging channels of RAN2 to avoid overlap with RAN1 and begin RAN2. For example, Initiator 2 can obtain the scheduling information of RAN1 (e.g., ranging round duration, number of rounds, number of active rounds, etc.). Initiator 2 can configure its (or RAN2's) channels to avoid channel overlap with those associated with Initiator 1 (or RAN1). Additionally, Initiator 2 can periodically broadcast its ADV-POLL to avoid overlapping with Initiator 1 on the discovery (or initialization) channel.

[0525] Unlike existing UWB systems where RAN channel information cannot be shared with other devices during discovery (or initialization) and setup and is only provided through channel usage coordination processes via NB-AP or UWB-AP, in this disclosure, ranging session requests or channel usage information requests can be executed simultaneously through response messages to advertisement messages (e.g., ADV-POLL), and other devices that do not send response messages can also obtain the channel usage information of the advertising device. Therefore, ranging session participation and / or channel usage information sharing can be supported more quickly and efficiently, and correspondingly, a new effect of reducing collisions can be achieved by avoiding channels between devices belonging to different RANs.

[0526] Discovery / initialization and establishment based on various notification-related grouping formats

[0527] The following describes various grouping formats that can be applied to native discovery / initialization and setup for NBA-MMS-UWB.

[0528] As described above, for discovery / initialization, the initiator can perform an announcement to introduce itself, and the responder can perform a scan to discover it. The responder can then perform ranging session establishment based on the acquired announcement information. Various options can be considered for different use cases for this discovery / initialization and session establishment, such as cases where announcements supporting device privacy are required (i.e., private announcements) and cases where public announcements are required. Therefore, discovery / initialization and establishment can be supported in-band (i.e., NB channel / UWB channel) (i.e., without exchanging information via OOB).

[0529] Therefore, it is necessary to define private or public announcement messages (e.g., announcement polling frames, announcement response frames, SOR frames, etc.). Various examples of this disclosure are described below for performing discovery / initialization and setup processes based on such announcements.

[0530] The notification polling grouping format, notification response grouping format, and SOR grouping format for NBA-MMS-UWB proposed in this disclosure can be defined as shown in the examples below.

[0531] First, a method is described for defining the announcement polling grouping format, announcement response grouping format, and SOR grouping format associated with private announcements.

[0532] For clarity, the polling packet format associated with a private announcement is referred to as the ADV-POLL packet format, the response packet format associated with a private announcement is referred to as the ADV-RESP packet format (e.g., announcement response compact frame), and the SOR packet format associated with a private announcement is referred to as the SOR packet format.

[0533] A static address in the message header can enable unintentional users to track mobile devices.

[0534] To prevent such tracking, private announcements can use a privacy-protected address (i.e., a privacy-protected address).

[0535] For example, resolvable private addresses (RPAs) can be used for private announcements. Public addresses can be information that only the initiator and responder need to know.

[0536] In this regard, the advertiser (announcer) broadcasting the announcement packet and the scanner scanning it can have predefined resolution lists. These predefined resolution lists can be used before the advertiser and scanner communicate with each other (e.g., a two-way handshake, communication after link establishment, etc.). Therefore, a method can be provided to exchange them by implementing type methods. As an example, a table for the advertiser address resolution list can be defined in advance, and a general distribution method can be used.

[0537] After discovery is performed by at least two devices through broadcast and scanning processes, address verification to determine if the discovered address matches the found address can be performed during the session setup phase, etc. Random addresses can be periodically changed via the announcer, and the changed values ​​can be generated based on key pairs in the resolution list.

[0538] A private address can consist of a private address and a private salt (e.g., AES-128-ECB (key = PublicAddress, data = (padding || PrivateSalt))). For example, a polling packet format or an announcement polling packet format can be configured by including a 3-octet private address field (PrivAddr) and a 3-octet private salt field (PrivSalt), and another narrowband (NB) packet format can be configured by including a 3-octet private address field.

[0539] (ADV-POLL grouping format)

[0540] Figure 30 This represents an example of a private address-based polling grouping format according to this disclosure.

[0541] refer to Figure 30 The ADL-POLL packet format based on private addresses 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.

[0542] For example, the message ID field can indicate that the corresponding packet has the ADV-POLL packet format.

[0543] Regarding the private address and private salt fields, both the advertiser broadcasting the announcement packet and the scanner scanning it can have predefined resolution lists. These predefined resolution lists can consist of local resolution key pairs and peer resolution key pairs. The resolution lists can be used before communication between the advertiser and scanner (e.g., two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging them through implementation types can be provided. As an example, a table for the advertiser address resolution list can be predefined, and a general distribution method can be used.

[0544] After at least two devices have performed discovery through the announcement and scanning processes, address verification to determine if the discovered address matches the actual address can be performed during the session setup phase, etc. The announcer can periodically change random addresses, and the changed values ​​can be generated based on key pairs in the resolution list.

[0545] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

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

[0547] (ADV-RESP grouping format)

[0548] Figure 31 This represents an example of a private address-based notification response packet format according to this disclosure.

[0549] refer to Figure 31 The ADV-RESP packet format based on private addresses can include a message ID field, a private address (e.g., RPA hash) field, a message control field, and a message content field. In this respect, information about private salts (e.g., RPA Prands) can be obtained through the ADV-POLL packet format.

[0550] For example, the message ID field can indicate that the corresponding packet has an ADV-RESP packet format (e.g., the value "0x21").

[0551] Regarding the private address field, both the advertiser broadcasting the broadcast packet and the scanner scanning it can have a predefined resolution list. The predefined resolution list can consist of a local resolution key pair and a peer resolution key pair. The resolution list can be used before the advertiser and scanner communicate with each other (e.g., a two-way handshake, communication after the link is established, etc.). Therefore, a method can be provided for exchanging them through implementation types. As an example, a table for the advertiser address resolution list can be defined beforehand, and a general distribution method can be used.

[0552] After discovery is performed by at least two devices through broadcast and scanning processes, address verification to determine if the discovered address matches the found address can be performed during the session setup phase, etc. The announcer can periodically change the random address and can generate the changed value based on key pairs in the resolution list.

[0553] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0554] The message content format (e.g., setup request) corresponding to "0x01" indicated by the message control field may include 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. A CRC field (e.g., CRC16) may be added to the corresponding format. In this regard, other values ​​indicated by the message control field (e.g., values ​​"0x00", values ​​"0x02 to ff") may be defined as reserved.

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

[0556] [Table 18]

[0557] For example, UWB PHY configuration fields can be defined based on Table 19.

[0558] [Table 19]

[0559] For example, UWB MAC configuration fields can be defined based on Table 20.

[0560] [Table 20]

[0561] For example, NB PHY configuration fields can be defined based on Table 21.

[0562] [Table 21]

[0563] For example, NB MAC configuration fields can be defined based on Table 22.

[0564] [Table 22]

[0565] (SOR grouping format)

[0566] Figure 32 This represents an example of a private address-based ranging start grouping format according to this disclosure (e.g., the start of a ranging compact frame).

[0567] refer to Figure 32 The SOR packet format based on private addresses can include a message ID field, a private address field, a message control field, and a message content field. Information about the private salt can be obtained through the ADV-POLL packet format.

[0568] For example, the message ID field can indicate that the corresponding packet has a SOR packet format (e.g., the value "0x22").

[0569] Regarding the private address field, both the advertiser broadcasting the announcement packet and the scanner scanning it can have predefined resolution lists. These predefined resolution lists can consist of local resolution key pairs and peer resolution key pairs. The resolution lists can be used before communication between the advertiser and scanner (e.g., two-way handshake, communication after link establishment, etc.). Therefore, a method for exchanging these lists through implementation-type approaches can be provided. For example, a table for the advertiser address resolution list can be predefined, and a general distribution method can be used.

[0570] After at least two devices have performed discovery through the announcement and scanning processes, address verification to determine if the discovered address matches the actual address can be performed during the session setup phase, etc. The announcer can periodically change random addresses and generate the changed values ​​based on key pairs in the resolution list.

[0571] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0572] The message content format corresponding to "0x01" indicated by the message control field (e.g., set up) includes the NB channel selection field, UWB PHY configuration field, UWB MAC configuration field, NB PHY configuration field, and NB MAC configuration field, similar to the ADV-RESP packet format described above (e.g., Figure 31 The format is the same as in the previous format, and the time offset field and channel seed field can be added before the corresponding format. Here, the time offset field indicates the time between the SOR packet and the polling packet of the first ranging block, and can be assigned in the range of 0-65535µs. The channel seed field can be defined to initialize the channel switching function. For the corresponding format, a CRC field (e.g., CRC16) can be added. In this regard, other values ​​indicated by the message control field (e.g., values ​​"0x00", values ​​"0x02 to ff") can be defined as reserved.

[0573] Based on the above description, ADV-POLL, ADV-RESP, and SOR packet formats can be defined for private announcements.

[0574] In this regard, private addresses and private salts can be controlled at the start time of each ranging block to prevent the initiator from tracking the device via the PSDU header address. As an example, a private address can be generated using the device MAC address (e.g., an IEEE 802.15.4-based device MAC address), PAN ID, source short address, and destination short address. Additionally, the message control field can define various message content formats to activate sub-functions for each message (e.g., future-proof handshaking). Furthermore, the handshake setup protocol enables in-band NBA-MMS-UWB configuration and the initiation of the ranging session.

[0575] Next, a method for defining the announcement polling grouping format, announcement response grouping format, and SOR grouping format related to public announcements is described.

[0576] Advertisement polling (ADV_POLL) can be broadcast on the discovery / initialization channel. In use cases where privacy must be guaranteed, it is necessary to securely broadcast to individual devices or groups of devices that have been previously verified through processes such as authentication. Alternatively, in use cases where ranging sessions need to be established / permitted with an unspecified number of persons, a public (i.e., non-privacy) / insecure advertisement method is necessary to allow arbitrary devices to interpret advertisement packets such as advertisement polling.

[0577] New IDs can be assigned / defined, i.e., new message / group IDs, to support grouping formats for non-secure / public announcements such as those mentioned above.

[0578] For clarity, the polling packet format associated with public notices is called the ADV-POLL2 packet format, the response packet format associated with public notices is called the ADV-RESP2 packet format, and the SOR packet format associated with public notices is called the SOR2 packet format.

[0579] (ADV-POLL2 grouping format)

[0580] Figure 33 This represents an example of a polling grouping format for public announcements according to this disclosure (e.g., an announcement polling compact frame).

[0581] refer to Figure 33 The ADV-POLL2 packet format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0582] For example, the message ID field can indicate that the corresponding packet has the ADV-POLL2 packet format (e.g., the value "0x23").

[0583] The announcer address field indicates the address of the announcer, and the announcer address field can be omitted when the corresponding address is specified / included in the header.

[0584] Public addresses or random addresses can be used as advertiser addresses. Public addresses correspond to the addresses assigned to devices and can be based on short or extended addresses. Random addresses can correspond to addresses arbitrarily generated by the advertiser to prevent the public address from being directly exposed, and the rules for generating random addresses can be as follows.

[0585] For example, when the advertiser is a controller, it can generate random addresses as any short address, any extended address, or other forms. In this case, the controller can select a unique value from the addresses used within the ranging area network (RAN).

[0586] When using random addresses, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After device discovery is performed via a broadcast / scanning process, an advertiser corresponding to the controller manages the random addresses and may also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may have been changed, and therefore the corresponding address may no longer be in use. Additionally, resolution lists such as IRKs can be exchanged according to trusted device authentication processes (e.g., mutual authentication during a two-way handshake). In this case, the resolution key pairs within the resolution list can be used to extract / store information such as resolvable private addresses.

[0587] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0588] For example, the message content format corresponding to "0x00" indicated by the message control field can consist of a length field and a supported version list (SSVL) field. A CRC field (e.g., CRC16) can be added for the corresponding format. In this respect, other values ​​indicated by the message control field (e.g., values ​​"0x01 to ff") can be defined as reserved.

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

[0590] (ADV-RESP2 grouping format)

[0591] Figure 34 This represents an example of a response grouping format for public announcements according to this disclosure (e.g., an announcement response compact frame).

[0592] refer to Figure 34 The ADV-RESP2 packet format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0593] For example, the message ID field can indicate that the corresponding packet has the ADV-RESP2 packet format (e.g., a value of "0x24").

[0594] The announcer address included in the announcer address field may be abbreviated as AdvAddr, or the initiator address included in the announcer address field may be abbreviated as InitiatorAddr. Similarly, the responder address included in the responder address (or scanner address) field may be abbreviated as RespAddr, or the scanner address included in the responder address field may be abbreviated as ScannerAddr. In this disclosure, the announcer / initiator address is primarily referred to as the abbreviation AdvAddr, but the scope of this disclosure is not limited thereto, and it may be replaced with other abbreviations. Furthermore, in this disclosure, the responder / scanner address is primarily referred to as the abbreviation RespAddr, but the scope of this disclosure is not limited thereto, and it may be replaced with other abbreviations.

[0595] The AdvAddr field of an ADV-RESP2 frame can be set to the same value as the address obtained from ADV-POLL2 (or a public announcement polling frame, or a public announcement polling compact frame) (i.e., the value of the advertiser address field included in the ADV-POLL2 frame). Alternatively, the AdvAddr field of an ADV-RESP2 frame can be the destination address of the ADV-RESP2 frame. The AdvAddr field can be omitted if the destination address is specified / included in the header.

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

[0597] For example, when the advertiser is a controller, it can generate random addresses such as arbitrary short addresses, arbitrary extended addresses, or other forms of random addresses. In this case, the controller can select a unique value from the addresses used within the ranging area network (RAN).

[0598] When a random address is used, it can be changed periodically (e.g., every 5 minutes) to prevent tracking by unspecified devices. After device discovery is performed via a broadcast / scanning process, an advertiser corresponding to the controller manages the random address and may also temporarily manage the session. In this case, when the session ends, the address value obtained when the scanner discovers the advertiser may have been changed, and the corresponding address may no longer be used. Additionally, resolution lists such as IRKs can be exchanged according to trusted device authentication processes (e.g., mutual authentication during a two-way handshake). In this case, the resolution key pairs within the resolution list can be used to extract / store information such as resolvable private addresses.

[0599] The responder address can be the source address of the ADV-RESP2 frame. The RespAddr field can be omitted if the source address is specified / included in the header. Specifically, the responder address included in the RespAddr can be generated by the responder. That is, the responder can 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. The RespAddr can be generated as a 2-octet short address or an 8-octet address as described above, or it can be generated as an address with a different length (e.g., 3-octets) than 2-octet and 8-octet addresses, as described below. The generated RespAddr can also be configured as the source address. The RespAddr field can be omitted when the source address is included in the MAC header (MHR).

[0600] Message control fields can be defined to set the content of subsequent messages. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0601] The message content format configuration in the ADV-RESP2 packet format can be the same as or similar to the message content format configuration in the ADV-RESP packet format described above (for example, see...). Figure 33 ).

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

[0603] (SOR2 grouping format)

[0604] Figure 35 This represents an example of a ranging start grouping format for public announcements according to this disclosure (e.g., the start of a ranging compact frame).

[0605] refer to Figure 35 The SOR grouping format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0606] For example, the message ID field can indicate that the corresponding packet has an SOR2 packet format (e.g., the value "0x25").

[0607] The advertiser address (AdvAddr) field of the SOR2 frame can be set to the same value as the address obtained from ADV-RESP2 (i.e., the value of the AdvAddr field in the ADV-RESP2 frame). Alternatively, when the advertiser uses a random / common address, the same value included in the advertiser address in the ADV-POLL2 frame, which serves as the start of the initial two-way handshake, can be used as the value of the AdvAddr field in the SOR2 frame. AdvAddr can be the source address of the SOR2 frame.

[0608] The Responder / Scanner Address (RespAddr) field of the SOR2 frame can be set to the same value as the address obtained from ADV-RESP2 (i.e., the value of the RespAddr field in the ADV-RESP2 frame). RespAddr can be the destination address of the SOR2 frame. The RespAddr field can be omitted when the destination address is included in the header. SOR2 frames cannot be sent if the responder addresses of ADV-RESP2 overlap on the network.

[0609] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0610] The message content format configuration in the SOR2 packet format can be the same as or similar to the message content format configuration in the SOR packet format described above (for example, see...). Figure 32 ).

[0611] For example, the message content format corresponding to "0x00" indicated by the message control field (e.g., set) includes the NB selection field, UWB PHY configuration field, UWB MAC configuration field, NB PHY configuration field, and NB MAC configuration field, like the ADV-RESP grouping format mentioned above (e.g., Figure 31The format is the same as in the previous format, and the time offset field and channel seed field can be added before the corresponding format. Here, the time offset field indicates the time between the SOR packet and the polling packet of the first ranging block, and can be assigned in the range of 0-65535. The channel seed field can be defined to initialize the channel switching function. For the corresponding format, a CRC field (e.g., CRC16) can be added. In this regard, other values ​​indicated by the message control field (e.g., values ​​"0x01 to ff") can be defined as reserved.

[0612] In the example above, when session initialization is complete, the advertiser address (AdvAddr) and responder address (RespAddr) pair can be stored identically in the advertiser and responder / scanner, and can be used without change when maintaining the session.

[0613] (Additional Example 1 of ADV-POLL2 grouping format)

[0614] Additionally, in the ADV-POLL2 grouping format of the above embodiment 2-1 (i.e., Figure 33 In the ADV-POLL2 packet format shown in the diagram, the advertiser address can be defined to use a public address or a random address.

[0615] In this respect, the advertiser can determine the form / type of the address (e.g., a public address or a random address) and broadcast an advertisement packet based on this. In this case, the scanner that receives the corresponding packet may need a method to determine the form / type of the address.

[0616] To provide information about the address type, an ADV-POLL2 packet format that takes additional consideration of message control can be defined, i.e., the value of the message control field (i.e., the new message content format).

[0617] Figure 36 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0618] refer to Figure 36 The ADV-POLL2 packet format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0619] In this case, other fields are... Figure 35 The ADV-POLL2 packet format is the same, and the message content that can be indicated through the message control field can be added to indicate information for address type (AT).

[0620] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0621] For example, the message content format corresponding to "0x00" indicated by the message control field can consist of a length field and a supported version list (SSVL) field. Similarly, the message content format corresponding to "0x01" indicated by the message control field can consist of a length field, a supported version list field, and an address type (AT) field.

[0622] Here, the address type field indicates the address type applied to the advertised address, and the value of the corresponding field can be defined as shown in Table 23.

[0623] [Table 23]

[0624] (Additional Example 2 of ADV-POLL2 grouping format)

[0625] For ADV-POLL2 packets used for public announcements, collisions are highly likely to occur when a scanner requests / sends ADV-RESP2 packets to an announcer in an environment where there is congestion between the announcer and multiple scanners (i.e., ADV-RESP2 packets during the bidirectional handshake process for ADV-POLL2 packets). Therefore, methods to avoid such collisions may be necessary.

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

[0627] The random delay field can be used by the advertiser during the two-way handshake to send announcement packets such as ADV-POLL2 packets, and by the responder to receive announcement packets such as corresponding ADV-POLL2 packets to determine the response time of announcement packets such as ADV-RESP2 packets. In other words, the random delay field is related to the response time of announcement packets such as ADV-POLL2 packets and announcement response packets such as ADV-RESP2 packets during the two-way handshake.

[0628] When the random delay field is 0, the responder can send a response packet immediately after receiving an advertisement packet. When the random delay field is not 0, the responder can delay sending the response packet (e.g., an ADV-RESP2 packet) based on the corresponding value using methods such as random delay backoff within a certain range. For example, in the public advertisement approach, random delay can be applied to avoid collisions of response packets in congested environments with a large number of potential responders. 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 ranging scheduling time units (RSTU), or it can be set to a value optimized for application requirements.

[0629] Regarding the supply / delivery of the aforementioned random delay field, an ADV-POLL2 packet format that additionally considers message control can be defined, i.e., the value of the message control field (i.e., the new message content format).

[0630] Figure 37 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0631] refer to Figure 37 The ADV-POLL2 packet format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0632] In this case, other fields are... Figure 36 The ADV-POLL2 grouping format is the same, and the field used to indicate random delay (RD) information can be added to specific message content.

[0633] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0634] For example, the message content format corresponding to "0x00" indicated by the message control field can consist of a length field and a supported version list (SSVL) field. Similarly, the message content format corresponding to "0x01" indicated by the message control field can consist of a length field, a supported version list field, an address type (AT) field, and a random delay (RD) field.

[0635] As described above, the corresponding random delay field can be used to determine the response time of announcement packets such as ADV-POLL2 and announcement response packets such as ADV-RESP2 during the two-way handshake process. When the value of the random delay field is 0, the responder can send a response packet immediately after receiving the announcement packet. When the value of the random delay field is not 0, the responder can delay and send a response packet (e.g., an ADV-RESP2 packet) based on the corresponding value by giving a random delay within a certain range (e.g., by means of methods such as random delay backoff).

[0636] For example, in public announcement methods, random delays can be applied to avoid collisions in response packets in congested environments with a large number of potential responders. 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 ranging scheduling time units (RSTU), or it can be set to a value optimized for the requirements from the application.

[0637] (Additional Example 3 of ADV-POLL2 grouping format)

[0638] For ADV-POLL2 packets used for public announcements, since they are broadcast in the channel to an unspecified number of people for discovery / initialization, the corresponding packets may need to include information such as the purpose of the ADV-POLL2 packet.

[0639] The corresponding information can be referred to as Advertisement Data (ADV Data, AdvData). When multiple announcers are present, the scanner that receives the ADV-POLL2 packet has the technical effect of selecting the advertisement packet it needs based on the corresponding information.

[0640] Regarding the supply / delivery of the aforementioned notification data, an ADV-POLL2 grouping format can be defined, which additionally considers message control, i.e., the value of the message control field (i.e., the new message content format).

[0641] Figure 38 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0642] refer to Figure 38 The ADV-POLL2 packet format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0643] In this case, other fields are... Figure 39 The ADV-POLL2 grouping format is the same, and the field used to indicate that the notification data (AdvData) can be added to a specific message content.

[0644] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0645] For example, the message content format corresponding to "0x00" indicated by the message control field can consist of a length field and a supported version list (SSVL) field. Similarly, the message content format corresponding to "0x01" indicated by the message control field can consist of a length field, a supported version list field, an address type (AT) field, a random delay (RD) field, and an announcement data (AdvData) field.

[0646] The notification data fields can include information that the announcer wants to announce. For example, the corresponding fields can include a list of services supported by the announcer, and this information can be defined in various forms. As an example, a method for defining / representing services in a unique way, such as a UUID, can be applied. Alternatively, the corresponding fields can include the announcer's friendly name, the type of device, scheduling information such as the notification interval, and vendor-specific data desired by the announcer.

[0647] As described above, the notification data fields / format can be recursively configured based on a length-type-value format to include various types of information. As an example, the notification data format can be configured in the order of length field, first type field, first value field, ..., length field, Nth type field, and Nth value field. Alternatively, the notification data fields / format can be configured based on a type-length-value format. As an example, the notification data format can be configured in the order of first type field, length field, first value field, ..., Nth type field, length field, and Nth value field. Alternatively, the notification data format can be configured in a format other than length-type-value or type-length-value (e.g., length + notification data (length + AdvData) format).

[0648] Additionally, when assuming a packet airtime of 1ms for narrowband (NB), the advertised data field / format may not exceed the remaining size obtained by excluding other fields (e.g., SSVL, AT, RD, etc.) from the 24-byte (PDSU maximum size).

[0649] (Additional Example 4 of ADV-POLL2 grouping format)

[0650] In the ADV-POLL2 packet format described above, the announcer address can be defined to use only random addresses to prevent unwanted user tracking by using public addresses. In this case, the Address Type (AT) field included in the message content can be omitted. Alternatively, the Address Type (AT) field can be omitted even when defined to use only public addresses.

[0651] The corresponding methods can also be applied to other embodiments of this disclosure (e.g., Figure 33 ADV-POLL2 field format, Figure 36 ADV-POLL2 field format, Figure 37 ADV-POLL2 field format and Figure 40 (ADV-POLL2 field format in the document).

[0652] Figure 39 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0653] refer to Figure 39 The ADV-POLL2 packet format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0654] For example, the message ID field can indicate that the corresponding packet has the ADV-POLL2 packet format (e.g., a value of "0x23").

[0655] The announcer address field indicates the address of the announcer, and the announcer address field can be omitted when the corresponding address is specified / included in the header.

[0656] Random addresses can be used as advertiser addresses. These random addresses can correspond to arbitrarily generated addresses by the advertiser to prevent direct exposure of public addresses, and the rules for generating random addresses can be as follows.

[0657] For example, when the advertiser is a controller, a random address can be generated as any short address, any extended address, or other form of address. In this case, the controller can select a unique value from the addresses used in the ranging area network (RAN).

[0658] When using random addresses, tracking by unspecified devices can be prevented by periodically changing them (e.g., every 5 minutes). After device discovery is performed via a broadcast / scanning process, an advertiser corresponding to the controller manages the random addresses and may also temporarily manage sessions. In this case, when the session ends, the value of the address obtained when the scanner discovers the advertiser may have been changed, and thus the corresponding address may no longer be used. Additionally, resolution lists such as IRKs can be exchanged based on trusted device authentication processes (e.g., mutual authentication during a two-way handshake). In this case, the resolution key pairs within the resolution lists can be used to extract / store information such as resolvable private addresses.

[0659] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0660] For example, the message content format corresponding to "0x00" indicated by the message control field can consist of a length field and a supported version list (SSVL) field. Conversely, the message content format corresponding to "0x01" indicated by the message control field can consist of a length field, a supported version list field, a random delay (RD) field, and an announcement data (AdvData) field.

[0661] The random delay field can be used by the advertiser during the two-way handshake process to send announcement packets such as ADV-POLL2 packets, and by the responder to receive announcement packets such as the corresponding ADV-POLL2 packets to determine the response time of announcement packets such as ADV-RESP2 packets. In other words, the random delay field can be associated with the response time of announcement packets such as ADV-POLL2 packets and announcement response packets such as ADV-RESP2 packets during the two-way handshake process.

[0662] When the random delay field is 0, the responder can send a response packet immediately after receiving an advertisement packet. When the random delay field is not 0, the responder can delay sending a response packet (e.g., an ADV_RESP2 packet) based on the response value by giving a random delay within a range (e.g., through methods such as random delay backoff). For example, in the public advertisement method, a random delay can be applied to avoid collisions of response packets in a congested environment with a large number of potential responders. 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 ranging scheduling time units (RSTU), or it can be set to a value optimized for requirements from the application.

[0663] The notification data fields can include information that the announcer wants to announce. For example, the corresponding fields can include a list of services supported by the announcer, and this information can be defined in various forms. As an example, a method of defining / expressing services in a form such as a UUID can be applied. Alternatively, the corresponding fields can include the announcer's friendly name, the type of device, scheduling information such as the notification interval, and vendor-specific data desired by the announcer.

[0664] As described above, the notification data fields / format can be recursively configured based on a length-type-value format to include various types of information. As an example, the notification data format can be configured in the order of length field, first type field, first value field, ..., length field, Nth type field, and Nth value field. Alternatively, the notification data fields / format can be configured based on a type-length-value format. As an example, the notification data format can be configured in the order of first type field, length field, first value field, ..., Nth type field, length field, and Nth value field. Alternatively, the notification data format can be configured in a form other than the length-type-value or type-length-value format (e.g., length + notification data (length + AdvData) format).

[0665] Additionally, when assuming a packet air-time of 1ms for narrowband (NB), the announcement data field / format can be no larger than the remaining size obtained by excluding other fields (such as SSVL, RD, etc.) from 24 bytes (the maximum size of PDSU).

[0666] Alternatively, alternative locations could also be considered from... Figure 39 The random delay field is omitted in the ADV-POLL2 packet format shown in the diagram. In this case, the message content format corresponding to "0x01" can consist of the length field of the supported setup version list (SSVL), the supported setup version list field, and the announcement data (AdvData) field.

[0667] (Additional Example 5 of ADV-POLL2 grouping format)

[0668] For ADV-POLL2 packets used for public announcements, collisions are highly likely to occur when a scanner requests / sends an ADV-RESP2 packet to the announcer in an environment where the announcer and multiple scanners are congested (i.e., during the bidirectional handshake process for ADV-POLL2 packets). Therefore, methods to avoid such collisions may be necessary.

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

[0670] The random delay field can be used by the announcer during the two-way handshake process to send announcement packets such as ADV-POLL2 packets, and by the responder to receive announcement packets such as the corresponding ADV-POLL2 packets to determine the response time of announcement packets such as ADV-RESP2 packets. In other words, the random delay field can be associated with the response time of announcement packets such as ADV-POLL2 packets and announcement response packets such as ADV-RESP2 packets during the two-way handshake process.

[0671] When the random delay field is 0, the responder can send a response packet immediately after receiving an advertisement packet. When the random delay field is not 0, the responder can delay and send the response packet based on the corresponding value using methods such as random delay backoff within a range (e.g., ADV-RESP2 packets). For example, in the public advertisement approach, random delay can be applied to avoid collisions of response packets in congested environments with a large number of potential responders. 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 ranging scheduling time units (RSTU), or it can be set to a value optimized for requirements from the application.

[0672] Regarding the supply / delivery of the aforementioned random delay field, the ADV-POLL2 packet format can be defined, which also takes into account message control, i.e., the value of the message control field (i.e., the new message content format).

[0673] Figure 40 This represents another example of a polling grouping format for public announcements according to this disclosure.

[0674] refer to Figure 40 The ADV-POLL2 packet format used for public announcements may include a message ID field, an announcer address field, a message control field, and a message content field.

[0675] For example, the message ID field can indicate that the corresponding packet has the ADV-POLL2 packet format (e.g., the value "0x23").

[0676] The announcer address field indicates the address of the announcer, and the announcer address field can be omitted when the corresponding address is specified / included in the header.

[0677] The announcer address field indicates the address of the announcer, and the announcer address field can be omitted when the corresponding address is specified / included in the header.

[0678] Public addresses or random addresses can be used as advertiser addresses. Public addresses correspond to the addresses assigned to devices and can be based on short or extended addresses. Random addresses can correspond to addresses arbitrarily generated by the advertiser to prevent public addresses from being directly exposed, and the rules for generating random addresses can be as follows.

[0679] For example, when the advertiser is a controller, a random address can be generated as any short address, any extended address, or other form of address. In this case, the controller can select a unique value from the addresses used within the ranging area network (RAN).

[0680] When a random address is used, it can be periodically changed (e.g., every 5 minutes) to prevent tracking by unspecified devices. After device discovery is performed via a broadcast / scanning process, an advertiser corresponding to the controller manages the random address and can also temporarily manage sessions. In this case, when the session ends, the value of the address obtained when the scanner discovers the advertiser may have been changed, and the corresponding address may no longer be used. Additionally, resolution lists such as IRKs can be exchanged according to trusted device authentication processes (e.g., mutual authentication during a two-way handshake). In this case, key pairs resolved within the resolution list can be used to extract / store information such as resolvable private addresses.

[0681] Message control fields can be defined to set the content of messages placed subsequently. Each field in the message content, defined by message control fields, can be included or omitted individually.

[0682] For example, the message content format corresponding to "0x00" indicated by the message control field can consist of a length field of the supported version list (SSVL) and a supported version list field. Similarly, the message content format corresponding to "0x01" indicated by the message control field can consist of a length field of the supported version list (SSVL), a supported version list field, and a random delay (RD) field.

[0683] The random delay field can be used by the advertiser during the two-way handshake to send announcement packets such as ADV-POLL2 packets, and by the responder to receive announcement packets such as corresponding ADV-POLL2 packets to determine the response time of announcement packets such as ADV-RESP2 packets. In other words, the random delay field can be associated with the response time of announcement packets such as ADV-POLL2 packets and announcement response packets such as ADV-RESP2 packets during the two-way handshake.

[0684] When the random delay field is 0, the responder can send a response packet immediately after receiving an advertisement packet. When the random delay field is not 0, the responder can delay sending a response packet (e.g., an ADV-RESP2 packet) based on the corresponding value by giving a random delay within a range (e.g., through methods such as random delay backoff). For example, in the public advertisement approach, a random delay can be applied to avoid collisions of response packets in congested environments with a large number of potential responders. 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 ranging scheduling time units (RSTU), or it can be set to a value optimized for requirements from the application.

[0685] The various grouping formats described above in this disclosure (i.e., Figure 33 , 36 The grouping formats illustrated in Figures 37, 38, 39, and 40 can each be defined as grouping formats. Alternatively, the various grouping formats described above in this disclosure (i.e., Figure 33 , 36 The grouping formats shown in Figures 37, 38, 39, and 40 can also be defined by adding a message control ID to a grouping format and configuring the message content for each message control ID.

[0686] Advertisement polling packets can be broadcast on the discovery / initialization channel to distinguish between private and public (non-private) advertisements based on message / packet IDs (e.g., ADV-POLL, ADV-POLL2).

[0687] In this regard, in use cases where privacy must be guaranteed, it is necessary to securely announce to individual devices or groups of devices that have been confirmed in advance through a process such as authentication. Alternatively, in use cases where ranging sessions need to be established / permitted with an unspecified number of people, a public / insecure announcement method is necessary to allow any device to interpret announcement groups such as announcement polling.

[0688] To support the various secure / private or insecure / public announcement messages mentioned above, announcement grouping based on security level can be configured, and scanner operations can be defined accordingly.

[0689] Security levels can be defined as follows.

[0690] Level 1: No security

[0691] Level 2: Use associated with a single device (point-to-point)

[0692] Level 3: Use in association with device groups

[0693] Level 1 corresponds to situations where ADV_POLL is broadcast to a large number of unspecified individuals. In use cases such as access control in public places and public transportation payments, ADV_POLL is needed to effectively support ranging session establishment because it is easily delivered and interpreted by a large number of unspecified individuals, rather than for privacy. In this case, ADV_POLL may not be encrypted, and any scanner / responder can obtain the corresponding ADV_POLL and perform ranging session establishment via a two-way handshake.

[0694] Level 2 can correspond to the scenario where the ADV_POLL is encrypted and advertised to be obtained only from one device. For example, consider use cases such as locating a smartphone accessory device by establishing a ranging session between a personal smartphone and a smartphone accessory device verified through methods such as pre-authentication. In this case, because sufficient privacy is required, a method is needed to ensure that the broadcast is performed securely and that the ranging session is established accordingly. In this case, the address included in the ADV_POLL (i.e., the address of the advertiser) can be configured in the form of a private MAC address. Furthermore, the ADV_POLL (or some areas within the ADV_POLL) can be encrypted in a specific manner, and only authorized advertisers and scanners can be supported to send and receive the ADV_POLL while ensuring privacy through key supply or key exchange algorithms such as Public Key Infrastructure (PKI).

[0695] Level 3 can correspond to situations where the ADV_POLL is encrypted and broadcast to ensure that the ADV_POLL is only obtained from a specific group of devices. Consider use cases such as measuring the location and distance of peripheral devices based on distance measurements from multiple devices and configuring device mapping between a personal smartphone and multiple smartphone accessory devices authenticated through methods such as pre-authentication, or establishing a ranging session with a personal smartphone and a home appliance device authenticated through methods such as pre-authentication. In this case, because sufficient privacy is required, the address included in the ADV_POLL (i.e., the address of the announcer) can be configured in the form of a private MAC address to ensure secure announcement and the establishment of the ranging session based on this. Additionally, the ADV_POLL (or some areas within the ADV_POLL) can be encrypted in a specific manner, and only authorized announcers and scanners can be supported to send and receive the ADV_POLL while ensuring privacy through key supply or key exchange algorithms such as Public Key Infrastructure (PKI).

[0696] The ADV-POLL grouping format used for the above discovery / initialization can be applied as follows: Figure 43 The security level (SL) shown in the diagram is used to define it.

[0697] Figure 41 The diagram illustrates a polling grouping format for private / public announcements based on security levels, according to this disclosure.

[0698] refer to Figure 41 The ADV-POLL2 packet format used for public announcements may include a message ID field, a security level (SL) field, an announcer address field, a message control field, and a message content field.

[0699] For example, the message ID field can indicate that the corresponding packet has an ADV-POLL packet format (e.g., value "0x20", "0x21") or an ADV-POLL2 packet format (e.g., value "0x23").

[0700] The security level field can be defined to indicate the security level shown in Table 24 below.

[0701] [Table 24]

[0702] The announcer address field indicates the address of the announcer, and the announcer address field can be omitted when the corresponding address is specified / included in the header.

[0703] A private address can be used as an advertiser address when the value indicated by the security level field is 1 or 2 (i.e., level 2 or 3 as mentioned above). In other words, the advertiser address field can consist of private address information and private salt information.

[0704] In this regard, the advertiser (announcer) broadcasting the announcement packet and the scanner scanning it can have predefined resolution lists. These predefined resolution lists can be used before the advertiser and scanner communicate with each other (e.g., a two-way handshake, communication after the link is established, etc.). Therefore, a method can be provided for exchanging them through implementation-type methods. As an example, a table for the advertiser address resolution list can be defined beforehand, and a general distribution method can be used.

[0705] After discovery is performed by at least two devices through the announcement and scanning processes, address verification to determine if the discovered address matches the actual address can be performed during the session setup phase, etc. The announcer can periodically change random addresses and can generate changed address values ​​based on key pairs in the resolution list. Private addresses can consist of a private address and a private salt (e.g., AES-128-ECB (key = PublicAddress, data = (padding || PrivateSalt))).

[0706] Conversely, when the value indicated by the security level field is 0 (i.e., level 1 above), 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 can be based on a short address or an extended address. The random address can correspond to an address arbitrarily generated by the advertiser to prevent the public address from being directly exposed, and the rules for generating the random address can be as follows.

[0707] For example, when the advertiser is a controller, a random address can be generated as any short address, any extended address, or other form of address. In this case, the controller can select a unique value from the addresses used within the ranging area network (RAN).

[0708] When a random address is used, it can be changed periodically (e.g., every 5 minutes) to prevent tracking by unspecified devices. After device discovery is performed via a broadcast / scanning process, an advertiser corresponding to the controller manages the random address and can also temporarily manage sessions. In this case, when the session ends, the value of the address obtained when the scanner discovers the advertiser may have changed, and therefore the corresponding address may no longer be used. Additionally, resolution lists such as IRKs can be exchanged according to a trusted device authentication process (e.g., mutual authentication during a two-way handshake). In this case, the resolution key pairs within the resolution list can be used to extract / store information such as resolvable private addresses.

[0709] Message control fields can be defined to set the content of subsequent messages. Each field in the message content defined by the message control fields can be included or omitted individually.

[0710] For example, the message content format corresponding to "0x00" indicated by the message control field can consist of a length field and a supported version list (SSVL) field. Similarly, the message content format corresponding to "0x01" indicated by the message control field can consist of a length field, a supported version list field, an address type (AT) field, a random delay (RD) field, and an announcement data (AdvData) field.

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

[0712] The random delay field can be used by the advertiser during the two-way handshake process to send announcement packets such as ADV-POLL2 packets, and by the responder to receive announcement packets such as corresponding ADV-POLL2 packets to determine the response time of announcement packets such as ADV-RESP2 packets. In other words, the random delay field can be associated with the response time of announcement packets such as ADV-POLL2 packets and announcement response packets such as ADV-RESP2 packets during the two-way handshake process.

[0713] When the random delay field is 0, the responder can send a response packet immediately after receiving an advertisement packet. When the random delay field is not 0, the responder can delay and send response packets (e.g., ADV_RESP2 packets) based on the corresponding value by giving a random delay within a certain range (e.g., through methods such as random delay backoff). For example, in the public advertisement method, a random delay can be applied to avoid collisions of response packets in a congested environment with a large number of potential responders. 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 ranging scheduling time units (RSTU), or it can be set to a value optimized for application requirements.

[0714] The notification data fields can include information that the announcer wants to announce. For example, the corresponding fields can include a list of services supported by the announcer, and this information can be defined in various forms. As an example, a method for defining / representing services in a unique way, such as a UUID, can be applied. Alternatively, the corresponding fields can include the announcer's friendly name, the type of device, scheduling information such as the notification interval, and vendor-specific data desired by the announcer.

[0715] As described above, the notification data fields / format can be recursively configured based on a length-type-value format to include various types of information. As an example, the notification data format can be configured in the order of length field, first type field, first value field, ..., length field, Nth type field, and Nth value field. Alternatively, the notification data fields / format can be configured based on a type-length-value format. As an example, the notification data format can be configured in the order of first type field, length field, first value field, ..., Nth type field, length field, and Nth value field. Alternatively, the notification data format can be configured in a format other than length-type-value or type-length-value (e.g., length + notification data (length + AdvData) format).

[0716] Additionally, when assuming a packet airtime of 1ms for narrowband (NB), the advertised data field / format may not exceed the remaining size obtained by excluding other fields (e.g., SSVL, AT, RD, etc.) from the 24-byte (PDSU maximum size).

[0717] To support the various secure / private or insecure / public announcement messages mentioned above, announcement groups based on security modes can be configured, and scanner operations can be defined accordingly.

[0718] Safe mode can be defined as follows.

[0719] Mode 0: No security

[0720] Mode 1: Use associated with a single device (point-to-point) or a group of devices.

[0721] Mode 0 corresponds to the situation where ADV_POLL is broadcast to an unspecified number of people in a manner similar to Level 1 above. In use cases such as access control in public places and public transportation payments, ADV_POLL needs to effectively support ranging session establishment because it is easily delivered and interpreted by many unspecified individuals, rather than supporting privacy. In this case, ADV_POLL may not be encrypted, and any scanner / responder can obtain the corresponding ADV_POLL and perform ranging session establishment via a two-way handshake.

[0722] Mode 1 can correspond to a situation where ADV_POLL is encrypted and advertised in a manner similar to Level 2 and / or Level 3 described above to ensure it is obtained only from one device / group of devices. For example, consider the following use case: measuring the location and distance of peripheral devices based on distance measurements of (multiple) devices, and configuring device mapping between a personal smartphone and a series of smartphone accessory devices verified through methods such as pre-authentication, via a ranging session with the smartphone and the home appliance device verified through methods such as pre-authentication. In this case, because sufficient privacy is required, the address included in ADV_POLL (i.e., the address of the advertiser) can be configured in the form of a private MAC address to ensure secure advertising, and the ranging session establishment is performed based on this. The address included in ADV_POLL (i.e., the address of the advertiser) can be configured in the form of a private MAC address. Additionally, ADV_POLL (or some areas within ADV_POLL) can be encrypted in a specific way, and only permitted announcers and scanners can be supported to send and receive ADV_POLL while ensuring privacy through key supply or key exchange algorithms such as Public Key Infrastructure (PKI).

[0723] The ADV-POLL packet format used for the above discovery / initialization can be applied as follows: Figure 44 The security mode (SM) shown is used to define it.

[0724] Figure 42 The diagram illustrates a polling grouping format for private / public announcements based on a security mode, according to this disclosure.

[0725] refer to Figure 42 The ADV-POLL2 packet format used for public announcements may include a message ID field, a security mode (SM) field, an announcer address field, a message control field, and a message content field.

[0726] Because, excluding the security mode field and the announcer address field, the other fields are... Figure 41 The grouping format shown in the diagram is the same, so in Figure 42 The description of the corresponding fields is omitted.

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

[0728] [Table 25]

[0729] The announcer address field indicates the address of the announcer, and the announcer address field can be omitted when the corresponding address is specified / included in the header.

[0730] When security mode is 1, the private address can be used as the advertiser address. In other words, the advertiser address field can consist of private address information and private salt information.

[0731] In this regard, the advertiser (announcer) broadcasting the announcement packet and the scanner scanning it can have predefined resolution lists. These predefined resolution lists can be used before the advertiser and scanner communicate with each other (e.g., a two-way handshake, communication after the link is established, etc.). Therefore, a method can be provided for exchanging them through implementation-type methods. As an example, a table for the advertiser address resolution list can be defined beforehand, and a general distribution method can be used.

[0732] After discovery is performed by at least two devices through the announcement and scanning processes, address verification to determine if the discovered address matches the actual address can be performed during the session setup phase, etc. The announcer can periodically change random addresses and can generate changed address values ​​based on key pairs in the resolution list. Private addresses can consist of a private address and a private salt (e.g., AES-128-ECB (key = PublicAddress, data = (padding || PrivateSalt))).

[0733] Conversely, when security mode is 0, either 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 can be based on a short address or an extended address. The random address can correspond to an address arbitrarily generated by the advertiser to prevent the public address from being directly exposed, and the rules for generating the random address can be as follows.

[0734] For example, when the advertiser is a controller, a random address can be generated as any short address, any extended address, or other form of address. In this case, the controller can select a unique value from the addresses used within the ranging area network (RAN).

[0735] When a random address is used, it can be changed periodically (e.g., every 5 minutes) to prevent tracking by unspecified devices. After device discovery is performed via a broadcast / scanning process, an advertiser corresponding to the controller manages the random address and can also temporarily manage sessions. In this case, when the session ends, the value of the address obtained when the scanner discovers the advertiser may have changed, and therefore the corresponding address may no longer be used. Additionally, resolution lists such as IRKs can be exchanged according to a trusted device authentication process (e.g., mutual authentication during a two-way handshake). In this case, the resolution key pairs within the resolution list can be used to extract / store information such as resolvable private addresses.

[0736] The security level (SL) and security mode (SM) in this embodiment can also be applied to the various formats described above in this disclosure (i.e., Figure 33 , 36 The notification polling group (in the formats of 37, 38, 39 and 40) is used.

[0737] Alternatively, instead of distinguishing security types by including a security level field or a security mode field within the same message, a format for giving / applying notification polling groups can be provided based on the security level or security mode.

[0738] For example, for security levels 1, 2, and 3 (i.e., security level field values ​​of 0, 1, and 2), the ADV-POLL grouping format can be given (e.g., Figure 30 (in the format of ADV-POLL2 grouping format) Figure 33 , 36 The formats in 37, 38, 39, and 40) and the ADV-POLL2 grouping format (e.g., Figure 33 , 36 The formats in 37, 38, 39, and 40 are acceptable. Alternatively, for security level 1 (i.e., the security level field value is 0), the ADV-POLL grouping format can be given (e.g., ...). Figure 30(in the format), and for security levels 2 or 3 (i.e., security level field values ​​are 1 or 2), the ADV-POLL2 grouping format can be given (e.g., Figure 33 , 36 (Formats in 37, 38, 39, and 40). Additionally, for security modes 0 and 1, the ADV-POLL grouping format can be given (e.g., Figure 30 The format in (in the format) and ADV-POLL2 grouping format (e.g., Figure 33 , 36 (The formats in 37, 38, 39 and 40).

[0739] Security levels or security modes can be specified / assigned by applications, and the controller can determine whether to execute a private or public announcement based on the security level or security mode value. In this regard, the scanner receiving the announcement packet can select the appropriate packet based on the security level or security mode value (i.e., a packet that is deemed appropriate between private and public announcements).

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

[0741] Next, we describe the various frame formats (or packet formats) of polling frames, response frames, and report frames that are sent or received in MMS ranging operations (i.e., ranging sessions after initialization / session setup via announcement operations) depending on whether a public address is used.

[0742] Whether public and private addresses are used can be distinguished by message ID (or frame identifier), by address type, or by the same message ID (or frame identifier) ​​and subtype (or extended ID).

[0743] This describes a method for distinguishing between frame formats that use public addresses and frame formats that use private addresses by using a message ID (or frame identifier).

[0744] For example, after the announcer and scanner / responder establish a session during the MMS initialization and session setup steps (e.g., after the exchange of common announcement polling frames, common announcement response frames, and common report initiator / responder frames is completed), during the steps for performing operations such as ranging, the initiator and responder may exchange common polling frames, common response frames, and common report initiator / responder frames.

[0745] Figure 43 This is a diagram illustrating an example of a frame differentiation method by ID in ranging operations according to this disclosure. For example, Figure 43The messages / frames in the MMS can correspond to SS-TWR NBA-UWB MMS public messages / frames, and the value of the message control field can be set to 0x00 (e.g., corresponding to unencrypted SS-TWR NBA-UWB MMS, version 0). For example, public polling frames and non-public (e.g., private) polling frames can correspond to different message ID (frame identifier) ​​values. For example, public response frames and non-public (e.g., private) response frames can correspond to different message ID (frame identifier) ​​values. For example, public report initiator / responder frames and non-public (e.g., private) report initiator / responder frames can correspond to different message ID (frame identifier) ​​values.

[0746] The address field may include the announcer's address and / or address type. The address field can be divided into a source address and a destination address. The source address and destination address can be the address of the peer and its address pairs exchanged during the bidirectional handshake process between the announcer / initiator and the scanner / responder during MMS initialization and setup. Address pairs can be temporarily 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 / shape (e.g., 3 octets).

[0747] Figure 44 This is a diagram illustrating exemplary formats of public polling frames, public response frames, and public report frames according to this disclosure.

[0748] Figure 44 (a) An example of the packet format for a common polling frame (e.g., message control = 0x00).

[0749] The message ID (or frame identifier) ​​field has a size of 1 to 8 bytes and can be set to a value that represents a common polling frame.

[0750] The source address (SrcAddr) field can be set to the address value of the initiator. In the example frame format, the source address field can be omitted when the source address is specified in the header.

[0751] The Destination Address (DestAddr) field can be set to the address value of the responder. In the example frame format, the Destination Address field can be omitted when the destination address is specified in the header.

[0752] The source and destination addresses can consist of 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. Address sizes can be short addresses (i.e., 2 octets), extended addresses (i.e., 8 octets), or addresses of different sizes / shapes (e.g., 3 octets).

[0753] The message control field can be set to a value that indicates the content of subsequent messages.

[0754] For example, the value of the message control field can be used to distinguish which fields should be included or omitted in the message content. For instance, when the value of the message control field is 0x00, the message content field can include the two bytes of 0x00 and 0x00 removed by the CFO.

[0755] A CRC16 field can be 2 bytes in size.

[0756] Depending on the usage, all fields described in the format of the above common polling frame may be included, or some may be omitted.

[0757] Figure 44 (b) An example of the packet format for a common response frame (e.g., message control = 0x00).

[0758] The message ID (or frame identifier) ​​field has a size of 1 to 8 bytes and can be set to a value that represents a common response frame.

[0759] The source address (SrcAddr) field can be set to the address value of the responder. When the source address is specified in the header, the source address field can be omitted in the frame format examples.

[0760] The Destination Address (DestAddr) field can be set to the address value of the initiator. When specifying the destination address in the header, the Destination Address field can be omitted in the frame format examples.

[0761] The source and destination addresses can consist of 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. Address sizes can be short addresses (e.g., 2 octets), extended addresses (e.g., 8 octets), or other sizes / shapes (e.g., 3 octets).

[0762] The message control field can be set to a value that indicates the content of subsequent messages.

[0763] For example, the value of the message control field can be used to distinguish which fields in the message content should be included or omitted. For instance, when the value of the message control field is 0x00, the message content field can include five bytes of 0x00, 0x00, 0x00, 0x00, and 0x00 for CFO elimination.

[0764] CRC16 fields can be 2 to 8 bytes in size.

[0765] Depending on the usage, all fields described in the format of the above common response frame may be included, or some may be omitted.

[0766] Figure 44 (c) An example of the packet format for a public report initiator frame (e.g., message control = 0x00).

[0767] The message ID (or frame identifier) ​​field has a size of 1 to 8 bytes and can be set to a value representing a public report initiator frame.

[0768] The source address (SrcAddr) field can be set to the address value of the initiator. In the frame format example, the source address field can be omitted when specifying the source address in the header.

[0769] The Destination Address (DestAddr) field can be set to the address value of the responder. In the frame format example, the Destination Address field can be omitted when specifying the destination address in the header.

[0770] The source and destination addresses can consist of 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. Address sizes can be short addresses (e.g., 2 octets), extended addresses (e.g., 8 octets), or other sizes / shapes (e.g., 3 octets).

[0771] The message control field can be set to a value that indicates the content of subsequent messages.

[0772] For example, the value of the message control field can be used to distinguish which fields should be included or omitted in the message content. For instance, when the message control field value is 0x00, the message content fields can include a 5-byte round-trip time (RTT) field, a 1-byte pass-through (PT) length field, and a PT data field of the corresponding length. Data can be piggybacked into the PT length field and the PT data field.

[0773] A CRC16 field can be 2 bytes in size.

[0774] Depending on the usage, all fields described in the format of the above public report initiator frame may be included or some may be omitted.

[0775] Figure 44 (d) represents an example of the grouping format of a common report responder frame (e.g., message control = 0x00).

[0776] The message ID (or frame identifier) ​​field has a size of 1 to 8 bits and can be set to a value that represents a common report responder frame.

[0777] The source address (SrcAddr) field can be set to the address value of the responder. When the source address is specified in the header, the source address field can be omitted in the frame format examples.

[0778] The Destination Address (DestAddr) field can be set to the address value of the initiator. When the destination address is specified in the header, the Destination Address field can be omitted in the frame format examples.

[0779] The source and destination addresses can consist of 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. Address sizes can be short addresses (e.g., 2 octets), extended addresses (e.g., 8 octets), or other sizes / shapes (e.g., 3 octets).

[0780] The message control field can be set to a value that indicates the content of subsequent messages.

[0781] For example, the values ​​of message control fields can be used to distinguish which fields should be included or omitted in the message content. For instance, when the message control field value is 0x00, the message content fields may include a 5-byte turnaround time (TAT) field, a 1-byte pass-through (PT) length field, and a PT data field of the corresponding length. Data can be stored in the PT length field and the PT data field using a piggybacking method.

[0782] A CRC16 field can be 2 bytes in size.

[0783] Depending on the usage, all fields described in the format of the above public report responder frame may be included, or some may be omitted.

[0784] This describes a method for distinguishing between frame formats that use public addresses and frame formats that use private addresses by applying an address type to each message ID (or frame identifier).

[0785] For example, after the announcer and scanner / responder establish a session during the MMS initialization and session setup steps (e.g., after the exchange of announcement polling frames, announcement response frames, and SOR frames is completed), the initiator and responder may exchange polling frames, response frames, and report initiator / responder frames during the steps for performing operations such as ranging.

[0786] Figure 45 This is a diagram illustrating an example of a method for distinguishing frames by address type in ranging operations according to this disclosure. For example, Figure 45The messages / frames in the message control field can correspond to SS-TWR NBA-UWB MMS messages / frames, and the value of the message control field can be set to 0x00 (e.g., corresponding to unencrypted SS-TWR NBA-UWB MMS, version 0). For example, public polling frames and non-public (e.g., private) polling frames can correspond to the same message ID (frame identifier) ​​value. Similarly, public response frames and non-public (e.g., private) response frames can correspond to the same message ID (frame identifier) ​​value. Likewise, public report initiator / responder frames and non-public (e.g., private) report initiator / responder frames can correspond to the same message ID (frame identifier) ​​value.

[0787] The address field may include the advertiser's address and / or address type. When the address type is included, it may include information distinguishing privacy-preserving addresses, public addresses, random addresses, etc. If it is a privacy-preserving address, RPA can be used, and for polling frames, a pseudo-random (Prand) field may also be included in the address field. When it is a privacy-preserving address, the address of the peer exchanged between the advertiser / initiator and the scanner / responder during the MMS initialization and setup process, along with address pairs of their addresses, may be included as source and destination addresses. The address size may be a short address (e.g., 2 octets), an extended address (e.g., 8 octets), or an address of a different size / shape (e.g., 3 octets).

[0788] Figure 46 This is a diagram illustrating the exemplary format of polling frames, response frames, and report frames according to this disclosure.

[0789] Figure 46 (a) An example of the packet format for a polling frame (e.g., message control = 0x00).

[0790] The message ID (or frame identifier) ​​field has a size of 1 to 8 bytes and can be set to a value representing a polling frame.

[0791] The Address Type (AT) field has a size of 1 to 8 bits and can be set to a value used to distinguish address types such as privacy-protected addresses, public addresses, random addresses, etc. When bits 0-1 are 0, the address type indicates a privacy-protected address; a value of 1 indicates a public address; and a value of 2 indicates a random address. Bits 2-7 can be reserved. The scope of this disclosure is not limited to these examples, and the address type can be defined in other ways. Two bits of the 1 octet of the AT field can be used to indicate the address type, and the remaining bits can be used for other purposes such as content control.

[0792] The address field can include the address of the advertiser / initiator. When the address type is a privacy-protected address, RPA and PRAND can be included together in the address field. When the address type is not a privacy-protected address, the source address and destination address can be included in the address field. In this case, the source address can be set to the address of the initiator, and the destination address can be set to the address of the responder. The source address and destination address can consist of address pairs determined by the advertiser / initiator and the scanner / responder during the session setup process. The source address and destination address can also be managed by the initiator. The address size can be a short address (e.g., 2 octets), an extended address (e.g., 8 octets), or an address of a different size / shape (e.g., 3 octets).

[0793] The message control field, message content field, and CRC16 field can be set to the same as... Figure 44 The corresponding fields in (a) are the same.

[0794] Depending on the usage, all fields described in the above polling frame format can be included, or some can be omitted.

[0795] Figure 46 (b) An example of the packet format for a response frame (e.g., message control = 0x00).

[0796] The message ID (or frame identifier) ​​field has a size of 1 to 8 bits and can be set to a value that represents a response frame.

[0797] The Address Type (AT) field can be used with... Figure 46 The AT field described in (a) is the same.

[0798] The address field can include the address of the advertiser / initiator. RPA can be used in the address field when the address type is a privacy-protected address. When the address type is not a privacy-protected address, the source and destination addresses can be included in the address field. In this case, the source address can be set to the address of the responder, and the destination address can be set to the address of the initiator. The source and destination addresses can consist of address pairs determined by 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 / shape (e.g., 3 octets).

[0799] The message control field, message content field, and CRC16 field can be set to the same as... Figure 44 The corresponding fields in (b) are the same.

[0800] Depending on the usage, all fields described in the above response frame format may be included, or some may be omitted.

[0801] Figure 46 (c) indicates an example of the packet format of the report initiator frame (e.g., message control = 0x00).

[0802] The message ID (or frame identifier) ​​field has a size of 1 to 8 bits and can be set to a value that represents the report initiator frame.

[0803] The Address Type (AT) field can be used with... Figure 46 The AT field described in (a) is the same.

[0804] The address field can include the address of the advertiser / initiator. RPA can be used in the address field when the address type is a privacy-protected address. When the address type is not a privacy-protected address, the source and destination addresses can be included in the address field. In this case, the source address can be set to the initiator's address, and the destination address can be set to the responder's address. The source and destination addresses can consist of address pairs determined by 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 / shape (e.g., 3 octets).

[0805] The message control field, message content field, and CRC16 field can be set to the same as... Figure 44 The corresponding fields in (c) are the same.

[0806] Depending on the usage, all fields described in the format of the above report initiator frame may be included, or some may be omitted.

[0807] Figure 46 (d) represents an example of the grouping format of the report responder frame (e.g., message control = 0x00).

[0808] The message ID (or frame identifier) ​​field has a size of 1 to 8 bits and can be set to a value that represents the report responder frame.

[0809] The Address Type (AT) field can be used with... Figure 46 The AT field in (a) describes the same thing.

[0810] The address field can include the address of the advertiser / initiator. RPA can be used in the address field when the address type is a privacy-protected address. When the address type is not a privacy-protected address, the source and destination addresses can be included in the address field. In this case, the source address can be set to the address of the responder, and the destination address can be set to the address of the initiator. The source and destination addresses can consist of address pairs determined by 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 / shape (e.g., 3 octets).

[0811] The message control field, message content field, and CRC16 field can be set to the same as... Figure 44 The corresponding fields in (d) are the same.

[0812] Depending on the usage, all fields described in the format of the above report responder frame may be included, or some may be omitted.

[0813] Describes a method for distinguishing between frame formats using public addresses and frame formats using private addresses by using a subtype (or extended ID) for each message ID (or frame identifier).

[0814] For example, public polling frames and non-public (e.g., private) polling frames can correspond to the same message ID (frame identifier) ​​value, but can correspond to different subtype (or extended ID) values. Similarly, public response frames and non-public (e.g., private) response frames can correspond to the same message ID (frame identifier) ​​value, but can correspond to different subtype (or extended ID) values. Likewise, public report initiator / responder frames and non-public (e.g., private) report initiator / responder frames can correspond to the same message ID (frame identifier) ​​value, but can correspond to different subtype (or extended ID) values.

[0815] Figure 47 This is a diagram illustrating an example of a method for distinguishing frames by subtype according to this disclosure. For example, Figure 47 The message / frame in the message / frame can correspond to an SS-TWR NBA-UWB MMS message / frame, and the value of the message control field can be set to 0x00 (e.g., corresponding to an unencrypted SS-TWR NBA-UWB MMS, version 0).

[0816] The message ID (or frame identifier) ​​field has a size of 1 to 8 bytes and can be set to a value that represents a polling frame, a response frame, or a report initiator / responder frame.

[0817] Subtype (or extended ID) fields have a size of 1 to 8 bytes and can be set to values ​​representing private or public types.

[0818] The descriptions of the corresponding fields in the above examples can be applied to the fields of polling frames, response frames, and report initiator / responder frames corresponding to private or public subtypes.

[0819] In the above examples, the notification polling frame, notification response frame, SOR frame, polling frame in the ranging session, response frame in the ranging session, report initiator frame in the ranging session, and report responder frame in the ranging session are described as examples of methods for defining and distinguishing between public use / type and non-public (e.g., private) use / type, distinguished by message ID (or frame identifier), by address type, or by subtype (or extended ID).

[0820] These examples are applied not only to the messages / frames mentioned above, but also to other messages that use privacy-protected addresses associated with NBA-UWB MMS as public addresses. For example, even for announcement confirmations (ADV-CONF), short-term parameters for the next ranging cycle (POLL-SPN), RESP-SPN, one-to-many POLL, one-to-many RESP, REPORT-SPN from the responder, reports from the responder on one-to-many ranging, reports from the initiator on one-to-many ranging, etc. (as well as messages that establish new definitions for public initiation / sessions and session operations for using privacy-protected addresses defined in future NBA-UWB MMS), the examples mentioned above, distinguished by message ID (or frame identifier), by address type, or by subtype (or extended ID), can be applied similarly as a method for defining and distinguishing between private and public formats / types.

[0821] For example, an Advertisement Confirmation (ADV-CONF) message can be defined and used to delay SOR transmission. Specifically, when coordination is enabled, the initiator can determine the ranging session configuration based on UWB channel usage information, which can be confirmed from the Acquisition Packets (APs) of other initiators. For coordination, the initiator can scan the NB Initialization Packet and the UWB default channel before sending the SOR. To perform the scan for coordination, it is necessary to delay the SOR transmission, and for this purpose, the initiator can send ADV-CONF after receiving ADV-RESP, and information about the time offset between the start of the ADV-CONF packet and the start of the SOR packet can be included in the ADV-CONF.

[0822] This ADV-CONF frame can be defined as a public ADV-CONF frame (e.g., a public announcement confirmation compact frame) and a non-public (i.e., private) ADV-CONF frame (e.g., an announcement confirmation compact frame).

[0823] For example, public ADV-CONF frames and non-public (i.e., private) ADV-CONF frames can 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 announcer address field set to a public address value randomly generated by the announcer. For example, an ADV-CONF frame with a non-public ADV-CONF frame identifier value may include an RPA hash field.

[0824] Alternatively, public ADV-CONF frames and non-public (i.e., private) ADV-CONF frames can correspond to the same message ID (frame identifier) ​​value and include an address type field. For example, when the address type field indicates a private address, the ADV-CONF frame may include an RPA hash field. For example, when the address type field indicates a public address, the ADV-CONF frame may include an advertiser address field, which is set to a public address value randomly generated by the advertiser.

[0825] Alternatively, public ADV-CONF frames and non-public (i.e., private) ADV-CONF frames can correspond to the same message ID (frame identifier) ​​value but to different subtypes (or extended IDs). For example, when the subtype field indicates a private type, the ADV-CONF frame may include an RPA hash field. For example, when the subtype field indicates a public type, the ADV-CONF frame may include an advertiser address field set to a public address value randomly generated by the advertiser.

[0826] The two-way handshake process used for the public native discovery (or initialization) and session establishment process of the aforementioned NBA-UWB MMS can be summarized as follows: the initiator advertises / broadcasts a public ADV-POLL message on the NBA-UWB MMS initialization channel, the responder that discovers it responds to a public ADV-RESP message, and the initiator delivers information for session establishment to the responder via a public SOR message (or a public announcement confirmation message and an SOR message). In the example described below, the method based on message ID (or frame ID) is assumed to be one of the various methods used to distinguish whether the ADV-POLL / ADV-RESP / ADV-CONF / SOR frames described in the above example are private or public frames. However, this method can also be applied to other methods (e.g., address type-based methods, subtype-based methods, etc.).

[0827] For a common ADV-POLL frame announced / broadcast by the initiator, multiple ADV-RESP frames can be sent from multiple responders, and in this case, collisions may occur between the multiple ADV-RESPs. Collisions regarding time resources may occur when ADV-RESPs from different responders are sent at partially or completely overlapping times. Additionally, or separately, collisions regarding address resources may occur when the common addresses (responder addresses) randomly generated by each different responder are the same. To prevent or reduce such collisions, this disclosure specifically describes methods for accurately and efficiently applying random delays to ADV-RESP transmission time points and message exchange methods for resolving common address collisions among responders.

[0828] Describes the random delay (RD) applied to the notification response.

[0829] Figure 48 This is a diagram illustrating various examples of the notification polling and notification response formats according to this disclosure.

[0830] Figure 48 (a) indicates a situation where, in the examples of the various announcement polling packet formats described above, the common ADV-POLL packet consists of an ID, Address Type (AT), Message Control, Length, Supported Message Control List (SMCL), Random Delay (RD), AdvData, and CRC16 fields. When the value of the Message Control field is 0x20, it can correspond to a format that includes the RD field. The SMCL can be set to values ​​representing different values ​​of the Message Control fields supported by the initiator (e.g., 0x30-0x34 and 0x50-0x56). The other fields are the same as described above, and therefore overlapping descriptions are omitted. The scope of this disclosure is not limited to these exemplary formats, but includes cases where the announcement polling frame includes the RD field and the remaining fields include the same fields as in the other examples above or new fields.

[0831] The responder, having received an announcement packet such as PUBLIC-ADV-POLL during the two-way handshake process, can use RD as described above to determine the transmission time (i.e., response time) of a response packet such as PUBLIC-ADV-RESP. When the value of the RD field is 0, the responder can send a response packet such as PUBLIC-ADV-RESP immediately after receiving an announcement packet such as PUBLIC-ADV-POLL (i.e., without delay). When the RD field has a non-zero value, the transmission time of the response packet can be delayed based on a value randomly selected by the responder within a range of corresponding values ​​(i.e., a range greater than 0 and less than or equal to the value of the RD field).

[0832] For public announcements, in congested environments with a large number of responders, random delays can be applied to avoid collisions in response packet transmission time. The value of the random delay can be determined by a higher layer. The value of the random delay can be specified / calculated in RSTUs or in predefined time slots (e.g., defining 1 time slot = 10 RSTUs, or defining the time slot length as different values). Alternatively, the value of the random delay or its unit size can be applied as a value optimized for the application.

[0833] A scanner / responder that receives a public announcement polling frame including an RD field can generate a random value in the range of 0 to X-1 based on the value (X) of the RD field and send a public announcement response frame after a delay corresponding to the generated value.

[0834] To ensure that the initiator / announcer / controller of the PUBLIC-ADV-POLL and the responders / scanners / controlled devices receiving it both anticipate or calculate the range of random delays that can be applied, the unit of random delay must be defined equally between the initiator and the responders. Additionally, depending on the application, different unit sizes can be supported. Therefore, options (or candidates) for the unit of random delay can be defined or provided. To define this, the transmission time length of the public announcement response frame from one responder can be considered. To prevent / avoid collisions that occur when multiple responders receive public announcement polling frames from the initiator at the same / similar time and send public announcement response frames at that same or overlapping time, a responder intending to send its response frame with a random delay can define a unit of random delay to send its response frame after the transmission time length of another responder's response time has elapsed.

[0835] In this regard, Figure 48 (b) indicates the following situation: in the examples of the various notification response packet formats described above, the common ADV-RESP packet consists of ID, AT, RESP address, ADV address, message control, NB channel selection, UWB PHY configuration, UWB MAC configuration, NB PHY configuration, NB MAC configuration, and CRC16 fields. When the value of the message control field is 0x00, it can correspond to a notification response frame corresponding to the setup request. The other fields are the same as described above, and therefore overlapping descriptions are omitted. The scope of this disclosure is not limited to these exemplary formats, but includes cases where the notification response frame includes the RESP address field and the ADV address field and the remaining fields include the same fields as in the other examples described above or new fields.

[0836] As described above, the RESP address field can be set to a common address value randomly generated by the responder / controller / scanner. The ADV address field can be set to a common address value randomly generated by the advertiser / initiator / controller (i.e., the same value as the ADV address field included in the advertisement polling frame). Each of the RESP and ADV addresses can be a short address (i.e., 2-byte size), an extended address (i.e., 8-byte size), or an address of a different size (e.g., 3-byte size).

[0837] To account for the transmission time of the notification response frame, when assuming the AT field is omitted, we can assume that when the message content is 15 bytes, such as... Figure 48 The total size of the PSDU shown in (b) is 24 bytes (or 25 bytes). It can be assumed that the total PPDU packet size, including the PSDU, is 30 bytes (or 31 bytes), which is the sum of the 4 bytes leading, 1 byte SFD, 1 byte PHR, and 24 bytes (or 25 bytes) of PSDU.

[0838] Based on O-QPSK 250kbps, each symbol (i.e., 4 bits) takes 16µs (milliseconds), and one byte corresponds to a 32µs transmission time. Considering this, it can be assumed that sending a 30-byte (or 31-byte) announcement response frame takes 960µs (or 992µs). Taking into account the transmission time of this announcement response frame, the size of the unit for random delay can be defined.

[0839] For example, the unit of random delay can be RSTU 50 is defined as the default value, and multiples of 1 / 2, 2, 3, 4... of the default value are defined as additional options. Alternatively, the unit of random delay can be RSTU. 2400 is defined as the default value, and 1 / 2, 2, 3, 4... times the default value are defined as additional options.

[0840] The controller / initiator can dynamically allocate options among these random delay units based on proximity. For example, when there are a large number of responders, the likelihood of conflicts between responders can be reduced by increasing the size of the units and / or increasing the random delay value (i.e., specifying a range of values ​​that can be selected as random delays).

[0841] The size of the random delay unit (i.e., the RD option) can be defined to be larger or smaller depending on the application. In order to apply the random delay unit (i.e., the RD option) dynamically in this way, the notification polling frame can also be defined to further include the RD option field.

[0842] Figure 48(c) represents an example of a public notice polling frame format, which is in Figure 48 The example in (a) additionally includes an RD option field. The scope of this disclosure is not limited to these exemplary formats, and includes cases where the remaining fields excluding the RD option field and the RD field include the same fields as in the other examples above, or new fields.

[0843] The RD option field indicates one of the options (or candidates) for the unit of random delay, and these options can be defined as shown in Table 26 or Table 27.

[0844] [Table 26]

[0845] [Table 27]

[0846] The value of the random delay can indicate a range determined by the value of the RD unit indicated by the RD option. When the value of the RD unit is large (e.g., RSTU), 2400), the random delay value (i.e., the maximum value in the range from which the random delay is selected / calculated by the responder) increases (e.g., 255). RSTU 2400 = approximately 510ms), and correspondingly, the entire two-way handshake process takes longer, so the session setup process may take a long time. To avoid this, the range of random delay values ​​can be determined based on the application. For example, when the random delay range is 0-50 (i.e., the maximum value of the random delay range is 50), the responder can select / calculate delay values ​​up to 100ms.

[0847] Alternatively, the RD option can be defined differently depending on the characteristics of the application. For example, unlike the examples in Tables 26 and 27, the RD option can also indicate the actual time value of a random delay. The unit of the indicated actual time value can be either us or ms (milliseconds). This unit can be predefined and applied by the initiator and responder without separate signaling.

[0848] Figure 49 This represents an example of initialization and setup operations based on random delay according to this disclosure.

[0849] exist Figure 49 In the example, it is assumed that responder 1 and responder 2 simultaneously scan the initiator's public announcement polling frame. Additionally, it is assumed that the RD option field included in the public announcement polling frame is set to a value of 0 (e.g., according to the example in Table 27, it is assumed to be RSTU). The random delay unit size is 1200 (corresponding to the size of 1 time slot), and the RD field is set to a value of 8.

[0850] Assume that responder 2 generates a value of 0 randomly within the range of 0 to 7 based on the value of the RD field being 8, and responder 1 generates a value of 4 randomly within the same range.

[0851] Responder 2 can send a public announcement response frame to the initiator in the time slot immediately following the receipt of the public announcement polling frame. Responder 2 can receive a public SOR frame in the next time slot and initiate a session with the initiator in the ranging channel based on the time offset value included in the SOR frame.

[0852] After receiving the public announcement polling frame, responder 1 can... RSTU After a delay of 1200 seconds (i.e., 4 time slots), a common announcement response frame is sent to the initiator. Responder 1 can receive the common SOR frame in the next time slot and initiate a session with the initiator in the ranging channel based on the time offset value included in the SOR frame.

[0853] During the unoccupied intermediate idle time slots of the initialization channel, the initiator can (periodically) send public announcement polling frames.

[0854] Describe a method for resolving responder address conflicts.

[0855] When a responder sends a public announcement response frame after receiving a public announcement polling frame from the initiator during the NBA-UWB MMS initialization and session setup process, the responder's public address can be included as the source address in the public announcement response frame. Additionally, the destination address of the public announcement response frame can be set to the same as the announcer address included in the public announcement polling frame (i.e., the initiator / announcer's public address).

[0856] The public address of the responder can be a short address (2 bytes) or an extended address (8 bytes), or, as described above, an address of different lengths (e.g., 3 bytes). Here, unlike existing addresses assigned by the initiator / controller as unique values ​​for each device when configuring the network, the responder address included in the public announcement response frame can be randomly generated by the responder / controlled device. Unlike existing association request and response procedures where the sender address is included in the request message from the controlled device to the controller, according to this disclosure, the sender (i.e., responder) address can be included in the public announcement response frame from the responder receiving the public announcement request frame to the initiator. Furthermore, unlike existing association request and response procedures where the receiver address is included in the response message from the controller to the controlled device, according to this disclosure, the receiver (i.e., responder) address can be included in a specific frame (the public SOR frame or public announcement acknowledgment frame described below) from the initiator to the responder.

[0857] Specifically, the responder address included in the public announcement response frame is an address assigned / generated by the responder. The initiator can then operate based on whether the responder address included in the public announcement response frame is unique on the network.

[0858] For example, when the responder address is unique, the session setup process can be completed by sending a common SOR frame (or a common announcement acknowledgment frame and a common SOR frame) to the responder.

[0859] For example, when the responder address is not unique, the initiator cannot send a common SOR frame (or common announcement acknowledgment frame) to the responder, and accordingly, the responder can cancel the two-way handshake process and scan for new common announcement polling frames.

[0860] For example, when the responder address is not unique, the initiator can send a public SOR frame or a public announcement acknowledgment frame to the initiator, which includes the response code (and a new address based on the value of the response code).

[0861] The destination address field (or responder address field) of a specific frame (i.e., a public SOR frame or a public announcement acknowledgment frame) that includes a response code (and a new address) can be set to a responder address randomly generated by the responder (and overlapping with the public address of another device) included in the public announcement response frame. For example, even after sending a first public announcement response frame including a responder address randomly generated by responder 1 and receiving a first specific frame from the initiator to verify that the responder addresses do not overlap, if a responder address randomly generated by responder 2 is the same as the responder address already generated and verified by responder 1, responder 2 may not be aware of this and may therefore send a second public announcement response frame including an overlapping responder address. In this case, because responder 2's responder address overlaps with responder 1's responder address, the initiator can send a second specific frame including either a rejection or a new address. In this scenario, because the public SOR frame including a rejection or new address for responder 2 includes an overlapping responder address as the destination address (i.e., the responder address already generated and verified by responder 1), it can be received by both responder 1 and responder 2. Similarly, because the public announcement acknowledgment frame including a rejection or new address for responder 2 does not include the responder address field, it can also be received by both responder 1 and responder 2. Here, because responder 1 receives the first specific frame for the first public announcement response frame it sent, it can not anticipate the second specific frame for the second public announcement response frame for responder 2 (e.g., because session setup is complete, it can not attempt frame reception in the initialization channel itself, or it can only anticipate receiving the public SOR frame at the SOR offset time point specified by the public announcement acknowledgment frame corresponding to the first specific frame), or it can ignore it even when it receives another public SOR frame in which its responder address is included as the destination address (i.e., a public SOR frame received at a time point other than the SOR offset specified by the public announcement acknowledgment frame corresponding to the first specific frame). Therefore, the second specific frame can be received and decoded only by responder 2, not responder 1. Thus, the responder address of responder 1 cannot be replaced / overwritten by a new address provided by the initiator, and only the responder address of responder 2 can be replaced / overwritten by a new address provided by the initiator.

[0862] As an additional example, when the responder address randomly generated by responder 1 is the same as the responder address randomly generated by responder 2, and each of responders 1 and 2 sends first and second announcement response frames in different time slots, the initiator may send a specific frame that does not include the new address if it rejects the same responder address for both responders 1 and 2, and responders 1 and 2 may scan for new announcement polling frames after receiving a corresponding specific frame.

[0863] Alternatively, when the responder address randomly generated by responder 1 is the same as the responder address randomly generated by responder 2, and each of responders 1 and 2 sends the first and second public announcement response frames in the same or overlapping time slots, the initiator may wait for the specific frame for a predetermined period of time without sending the specific frame, because it may not be able to correctly receive or decode the first and second public announcement response frames, and responders 1 and 2 that fail to receive the specific frame may scan for new public announcement polling frames.

[0864] Figure 50 This is a diagram illustrating various formats of specific frames sent by an initiator / notifier / controller that receives a public notice response frame, according to this disclosure.

[0865] Figure 50 (a) and Figure 50 (b) represents an example of a specific frame that corresponds to a common SOR frame (or includes at least one field associated with a common SOR). Figure 50 (c) and Figure 50 (d) represents an example of a specific frame that corresponds to a public notice confirmation frame (or includes at least one field related to a public notice confirmation).

[0866] Figure 50 Example (a) illustrates the following: In the examples of the various SOR formats described above, the common SOR frame consists of an ID, ADV address, RESP address, response code, new address, and CRC16 field. When the value of the message control field is 0x21, it can correspond to the format corresponding to an error response. The format corresponding to a general setup response (e.g., Figure 35 Unlike other formats, the format corresponding to an error response may include a response code field, and depending on the value of the response code field, a new address field may be further included if necessary.

[0867] Figure 50 Example (b) illustrates the following situation, where, in the examples of the various SOR packet formats described above, the common SOR frame consists of the ID, ADV address, RESP address, message control, response code, new address, time offset, channel seed, NB channel selection, UWB PHY configuration, UWB MAC configuration, NB PHY configuration, NB MAC configuration, and CRC16 fields. When the value of the message control field is 0x00, it can correspond to the format corresponding to the established response. The response code and new address fields can be set, as per reference... Figure 50 (a) As stated above. Because the other fields are the same as described above (e.g., for...). Figure 35The description is omitted here, as overlapping descriptions are omitted. The scope of this disclosure is not limited to these exemplary formats, but includes cases where the SOR frame includes a response code field (or a response code field and a new address field) and the remaining fields include the same fields as in the other examples above or additional fields.

[0868] For example, a response code can be defined as 1 byte in size and can be set to response code values ​​as shown in Table 28 or Table 29. Of the 1 byte in the response code field, 2 or 3 bits can be used as the response code value, and the remaining 6 or 5 bits can be used or reserved to indicate other information such as content control.

[0869] [Table 28]

[0870] [Table 29]

[0871] The new address field can be included in the public SOR frame when the response code in Table 27 or Table 28 is set to 1. Except when the response code in Table 27 or Table 28 is set to 1, the new address field can be omitted from the public SOR frame in other cases. The new address corresponds to the responder address assigned as a unique value on the network by the initiator / controller and can be delivered to the responder / controlled device by being included in the public SOR frame. The new address can be defined as a short address (i.e., 2-byte size), an extended address (i.e., 8-byte size), or an address of other shapes / sizes (e.g., 3 bytes). The responder can randomly generate a new address to replace / overwrite the responder address included in the public announcement response frame. In other words, a responder / controlled device receiving a public SOR frame including the new address can discard its previously randomly generated 3-byte responder address and store and use the 3-byte new address assigned as its responder address by the initiator / controller. Therefore, the responder / controller can cancel the session setup process, rescan the public announcement polling frame, and send a public announcement response frame including the responder address assigned as the new address. Alternatively, the responder / controller can store the new address and complete the session setup based on the session setup information included in the public SOR frame, and establish a session with the initiator / controller on the ranging channel based on the new address and perform frame exchange.

[0872] Alternatively, when the error reason corresponds to rejection or address duplication, the responder / controller that receives the public SOR frame including the response code can cancel the session setup process, rescan the public announcement polling frame, and randomly generate a new responder address to send a public announcement response frame.

[0873] Alternatively, when the error reason indicated by the response code included in the common SOR frame is success, the responder / controller can complete the session establishment based on the session establishment information included in the common SOR frame, establish a session with the initiator / controller in the ranging channel, and perform frame exchange.

[0874] Figure 51 This illustrates an example of initialization and setup operations according to this disclosure, including sending / receiving a common SOR frame containing a response code for error handling.

[0875] exist Figure 51 In the example, a responder that receives a public announcement polling frame can send a public announcement response frame after a random delay determined based on the RD field (and RD option field) included in the public announcement polling frame. Although Figure 51 The examples disclosed illustrate the application of random delays, but cases where random delays are not applied (i.e., the RD field and RD option field are not included in the public announcement polling frame, and the responder sends a public announcement response frame without random delays) may also be included within the scope of this disclosure.

[0876] A responder address (e.g., a 3-byte public address) randomly generated by the responder can be included in the public announcement response frame. In this regard, the initiator can set the value of the response code based on whether the responder address included in the public announcement response frame overlaps with the responder address of another device, and send a public SOR frame including the response code field to the responder. When the value of the response code field simply indicates rejection or address duplication and the new address field is not included in the public SOR frame, the responder can send a public announcement response frame including the newly randomly generated responder address after receiving a new public announcement polling frame. Alternatively, when the value of the response code field indicates rejection or address duplication and the new address field is included in the public SOR frame, the responder can send a public announcement response frame including the responder address set to the same value as the new address assigned by the initiator after receiving a new public announcement polling frame. In this respect, after receiving a common SOR frame from the initiator that includes a response code indicating success or a common SOR frame that does not include a response code, the responder can establish a session with the initiator in the ranging channel and perform frame exchange after the time offset included in the common SOR frame.

[0877] Figure 50Example (c) illustrates the following situation where, among the examples of the various ADV-CONF formats described above, the common ADV-CONF frame consists of an ID, ADV address, message control, SOR time offset, and CRC16 fields. When the value of the message control field is 0x00, it corresponds to the common ADV-CONF format associated with the setup response. The SOR time offset field indicates the time interval between the transmission of the common ADV-CONF frame and the transmission of the common SOR frame.

[0878] like Figure 50 As shown in example (d), when the value of the message control field is 0x21, it can correspond to the common ADV-CONF format corresponding to error responses. In this case, with Figure 50 Compared to the example in (c), the common ADV-CONF frame may further include a response code field or may further include a response code field and a new address field.

[0879] The response codes included in the common ADV-CONF frame can be defined as shown in Table 27 or Table 28 above. A new address field can be included in the common ADV-CONF frame when the response code in Table 27 or Table 28 is set to 1. Except when the response code in Table 27 or Table 28 is set to 1, the new address field can be omitted from the common ADV-CONF frame.

[0880] The new address corresponds to the responder address, which is assigned as a unique value on the network by the initiator / controller, and can be delivered to the responder / controlled device by being included in a public ADV-CONF frame. The new address can be defined as a short address (i.e., 2-byte size), an extended address (i.e., 8-byte size), or an address of a different shape / size (e.g., 3 bytes). The responder can randomly generate a new address to replace / overwrite the responder address included in the public announcement response frame. In other words, a responder / controlled device that receives a public ADV-CONF frame including the new address can discard its previously randomly generated 3-byte responder address and store and use the new 3-byte address assigned as its responder address by the initiator / controller.

[0881] The time offset field can be included in the common ADV-CONF frame when the response code indicates success or rejection / address duplicate and the new address field is included in the ADV-CONF frame. The SOR time offset field can be omitted from the common ADV-CONF frame when the response code simply indicates rejection or address duplicate and the new address field is not included in the ADV-CONF frame.

[0882] For example, when the response code included in the public ADV-CONF frame indicates rejection or address duplication, and a new address field is included in the public ADV-CONF frame, the initiator / controller can send a public SOR frame to the responder / controlled device after the SOR time offset, containing a responder address set to the same value as the new address included in the public ADV-CONF. Therefore, the responder / controlled device that obtains the new address included in the public ADV-CONF frame and replaces / overwrites it with its responder address can complete session establishment based on the responder address (i.e., the new address) in the public SOR frame corresponding to its address, based on the information included in the public SOR frame.

[0883] Alternatively, when the error reason corresponds to rejection or address duplication and the new address field is not included in the public ADV-CONF frame, the responder / controller that receives the public ADV-CONF frame including the response code can cancel the session setup process, rescan the public announcement polling frame, and randomly generate a new responder address to send a public announcement response frame.

[0884] Figure 52 This illustrates an example of initialization and setup operations according to this disclosure, including sending / receiving a public notification confirmation frame containing a response code for error handling.

[0885] exist Figure 52 In the example, a responder that receives a public announcement polling frame can send a public announcement response frame after a random delay determined based on the RD field (and RD option field) included in the public announcement polling frame. Although Figure 52 The examples disclosed illustrate the application of random delay, but cases where random delay is not applied (i.e., the RD field and RD option field are not included in the public announcement polling frame and the responder sends a public announcement response frame without random delay) may also be included within the scope of this disclosure.

[0886] A responder address (e.g., a 3-byte public address) randomly generated by the responder can be included in the public announcement response frame. In this regard, the initiator can set the value of the response code based on whether the responder address included in the public announcement response frame overlaps with the responder address of another device and send a public ADV-CONF frame including the response code field to the responder. When the value of the response code field simply indicates rejection or address duplication and the new address field is not included in the public CONF frame, the responder can send a public announcement response frame including the newly randomly generated responder address after receiving a new public announcement polling frame. Alternatively, when the value of the response code field indicates rejection or address duplication and the new address field is included in the public ADV-CONF frame, the responder can receive a public SOR frame including the same new address as the responder address after the SOR time offset, and can establish a session with the initiator in the ranging channel and perform frame exchange after the time offset included in the public SOR frame.

[0887] Methods for generating and manipulating privacy-preserving addresses in ranging sessions following public initialization

[0888] For existing public-based initialization and setup procedures for NBA-UWB MMS (e.g., public local discovery and session setup for NBA-UWBMMS), after the public-based initialization and setup procedure is completed, the addresses used during the initialization and setup procedure are used as is in the ranging session.

[0889] Figure 53 The diagram is based on common initialization and setup operations.

[0890] refer to Figure 53 Regarding the public initialization handshake process, the initiator can announce the public announcement poll (PUBLIC-ADV-POLL) message via the NBA-UWB MMS initialization channel. The responder that discovers this can respond with a public announcement response (PUBLIC-ADV-RESP) message. Later, the initiator that receives the corresponding response can deliver information for session establishment to the responder via a public SOR (PUBLIC-SOR) message.

[0891] When the ranging session begins after the public initialization handshake is completed through the above process, the initiator and responder can maintain the ranging session while sending and receiving public polling (PUBLIC-POLL), public response (PUBLIC-RESP), and public report (PUBLIC-REPORT) messages using the public address.

[0892] In this regard, public polling (PUBLIC-POLL) messages, public response (PUBLIC-RESP) messages, and public report (PUBLIC-REPORT) messages can be based on the above-described provisions of this disclosure. Figure 43 Frame differentiation and Figure 44 The grouping format in [the context].

[0893] For example, the address fields included in public polling (PUBLIC-POLL) messages, public response (PUBLIC-RESP) messages, and public report (PUBLIC-REPORT) messages may include the announcer's address and / or address type. The address field can be divided into source address and destination address. The source address and destination address can be the peer's address and its key pair (or address pair) exchanged during the bidirectional handshake process between the announcer / initiator and scanner / responder during MMS initialization and setup. The key pair can be temporarily managed by the initiator. The address size can be a short address (e.g., 2 octets), an extended address (e.g., 8 octets), or an address of other sizes / shapes (e.g., 3 octets).

[0894] As mentioned above, when public messages using public addresses (i.e., addresses sent and received by the initiator and responder during the public session setup process) are used, these addresses may not be protected during the ranging session. For example, addresses used in the ranging session may be tracked by unknown devices, potentially triggering other forms of attacks. Furthermore, using two address fields for existing address combinations—namely, combinations of source and destination addresses—may increase the size of some messages. Additionally, new message definitions may be needed during the ranging session to use combinations of source and destination addresses, and correspondingly, a further message ID space may be required.

[0895] To address this issue, this disclosure proposes a method in which two devices (i.e., an initiator and a responder) establishing a ranging session via a public initialization handshake procedure use privacy-preserving addresses within the ranging session. The corresponding method can be adapted to a one-to-one ranging approach, wherein the initiator sends a polling message to a responder during the ranging session, performs UWB ranging upon receiving a response message, and then exchanges report messages with the corresponding responder.

[0896] In addition, unlike the one-to-one ranging method mentioned above, the operation format of polling messages may be different in the case of one-to-many ranging method.

[0897] For example, regarding one-to-many ranging methods, the ranging process for one-to-many SS-TWR using multi-millisecond ranging (MMR) can be considered. For one-to-many SS-TWR using MMR, two types can exist depending on whether a narrowband auxiliary method (e.g., NBA-UWB) is used.

[0898] As a concrete example, when using the narrowband-assisted method, the ranging control phase (i.e., sending and receiving ranging initiation messages and their response messages) and the measurement reporting phase (i.e., sending and receiving report messages) can be performed on the narrowband (NB) channel, and the ranging phase can be performed on the UWB channel. Conversely, when not using the narrowband-assisted method, all ranging control, ranging, and measurement reporting phases can be performed on the UWB channel.

[0899] In both of the above types, ranging exchange can be initiated by an initiator that broadcasts a ranging initiation message to multiple responders on the NB or UWB band / channel.

[0900] Additionally, configuration parameters for one-to-many ranging rounds can be included in the ranging initiation message. These parameters can be used to determine the initiator's method for performing ranging on multiple responders and dividing the ranging time slots within a ranging round into multiple access time slots, as well as the method for performing ranging operations with the corresponding responders. Each access time slot can consist of a continuous range of ranging time slots to ensure that the initiator completes the ranging control phase, ranging phase, and optional measurement reporting phase for a responder. Therefore, in scheduled one-to-many operations, the corresponding configuration may need to include a list of responders ranging by the initiator.

[0901] The ranging control phase, ranging phase, and measurement reporting phase in each access time slot can be the same as in one-to-one ranging using MMR. Specifically, in access time slot 0, the ranging initiation message can also perform time synchronization as a polling message. Additionally, when the measurement reporting phase is not included in the access time slot, the initiator may need to reserve a time slot at the end of the ranging round for performing the measurement reporting phase for all responders. Furthermore, a process where the responder resends the measurement report to the initiator and the initiator calculates the ranging can also be considered. Additionally, a process where the responder calculates the range after the initiator sends the measurement report to the responder can also be considered. This variation can be based on some of the configuration parameters.

[0902] As described above, for a one-to-many ranging method, the initiator can broadcast the first polling message of the ranging round to all responders in the participating network, and the corresponding polling message can include scheduling-related information. For a one-to-many ranging method, access slots can be allocated to each responder, and each polling message corresponding to the remaining responders (excluding the first polling message) based on the corresponding access slot can be sent at the beginning of the access slot. Alternatively, polling messages can be delivered sequentially during the control phase of the round, rather than sequentially within the access slots.

[0903] Therefore, since the initiator can send polling messages to multiple responders in a one-to-many ranging method, a different approach is needed than that used for using privacy-preserving addresses in a one-to-one ranging method.

[0904] The following sections describe, with specific examples, methods for using privacy-preserving addresses by considering one-to-one ranging methods and methods for using privacy-preserving addresses by considering one-to-many ranging methods.

[0905] For clarity, in the public initialization handshake process described below, the address of the announcer, i.e., the address of the initiator (e.g., the public address of the initiator), is referred to as AdvAddr, and the address of the responder (e.g., the public address of the responder) is referred to as RespAddr.

[0906] Example 1

[0907] This embodiment relates to a method for using privacy-preserving addresses by taking into account a one-to-one ranging method.

[0908] For a one-to-one ranging method, the address of the announcer (i.e., the initiator) (e.g., AdvAddr) and the address of the responder (e.g., RespAddr) can be used during the common initialization setup between the initiator and the responder to establish the handshake.

[0909] Figure 54 The diagram illustrates the operation in the public initialization handshake process and the protected ranging session according to this disclosure.

[0910] For clarity, this disclosure relates to a ranging session in which a ranging session is performed that utilizes a privacy-protected address for message exchange as a protection.

[0911] For example, refer to Figure 54 Initiators and responders that have gone through the public initialization handshake process can use messages with privacy-preserving addresses to maintain the ranging session.

[0912] For the public initialization handshake process, the initiator can periodically send PUBLIC-ADV-POLL (e.g., public announcement polling messages or public announcement polling compact frames) on the initialization channel. For example, the initiator can randomly generate a 3-octet advertisement address (AdvAddr) information included in the PUBLIC-ADV-POLL and assign a value of 62:EE;5B.

[0913] The responder can discover the PUBLIC-ADV-POLL by scanning the initiating channel and obtain the AdvAddr information within the corresponding PUBLIC-ADV-POLL. Additionally, the responder can assign the corresponding AdvAddr information to the destination address included in the PUBLIC-ADV-RESP (e.g., a public announcement response message or a public announcement response compact frame) and randomly generate a 3-8 bit response address (RespAddr) to obtain a value of 3F:0A:F8. The responder can then assign the obtained 3F:0A:F8 value to the source address included in the PUBLIC-ADV-RESP and send the corresponding PUBLIC-ADV-RESP to the initiator.

[0914] When the initiator receives a PUBLIC-ADV-RESP, it can obtain the AdvAddr and RespAddr information of the PUBLIC-ADV-RESP and determine whether the AdvAddr information is the same as its own. If the AdvAddr information is determined to be the same, the initiator can assign the AdvAddr information to the source address and the RespAddr information to the destination address to configure and send a PUBLIC-SOR (e.g., a public SOR message or a public SOR compact frame).

[0915] When the above process is successfully completed, the public initialization handshake process can be terminated, and the transition to the ranging session can be executed.

[0916] Regarding operations within a ranging session, when the ranging session begins, the initiator can send a polling message (POLL) using a privacy-preserving address (e.g., a polling compact frame) to the responder during the ranging session. When the responder receives the corresponding polling message, it can send a response message (RESP) (e.g., a response compact frame) to the initiator. After that, for UWB ranging, UWB fragments can be exchanged on the UWB channel. When the corresponding process is terminated, a report message (REPORT) (e.g., a report compact frame) using a privacy-preserving address (from the initiator) and a report message (REPORT) (e.g., a report compact frame) from the responder can be exchanged on the ranging channel.

[0917] In this regard, the packet format based on privacy-preserving addresses can be as follows: Figure 55 As shown in the image.

[0918] Figure 55 The diagram illustrates a privacy-protected address grouping format according to this disclosure.

[0919] refer to Figure 55 Privacy-protected addresses can consist of a hash value and a Prand value in a form similar to a resolvable private address (RPA). The hash value and Prand value can be based on forms other than 3-8 bits.

[0920] Specifically, the hash value can be included in all messages, and the Prand value can be included only in the polling message of the initial round. The Prand value can be changed in each round.

[0921] Specifically, the hash value of the privacy-protected address proposed in this disclosure can be generated based on the formula “hash[3] = AES-128-ECB(key=IRK

[16] , data)”.

[0922] In the corresponding formula, the Identity Resolution Key (IRK) can be a key value known to both the initiator and the responder. Data can be generated by padding the first 16-byte segments of the Prand value with 3-byte segments appended. The hash can be assigned by taking only the last 3-byte segments of the generated hash value.

[0923] In this regard, the hash value and the Prand value can have forms other than 3 bytes. A resolvable private address (RPA) can be generated by appending the generated hash value and a Prand value that can be randomly generated for each round (or alternatively, depending on the implementation, at different periods (e.g., once for each ranging session)), and by using the corresponding PRA, prevention of tracking by other devices can be implemented.

[0924] In a ranging session, the polling, response, and report packet formats (using the initiator / responder) can be used with privacy-preserving addresses. Figure 56 The same as shown.

[0925] Figure 56 The diagram illustrates a privacy-preserving address-based grouping format according to this disclosure.

[0926] refer to Figure 56 ,and Figure 43 The existing packet format described in the document differs from the one described in the document and may include privacy-preserving addresses (i.e., RPAs) instead of address fields.

[0927] Specifically, the polling packet format may include RPA hash information and RPA Prand information as privacy-preserving addresses, and the response packet format and report packet format (via initiator / responder) may include RPA hash information as privacy-preserving addresses.

[0928] The methods used to generate and utilize IRK are described in detail below regarding the RPA has...

Claims

1.A method performed by a first device in an ultra-wideband (UWB) wireless network system, the method comprising: broadcasting a common-based advertisement poll frame; receiving a common-based advertisement response frame from a second device in response to the common-based advertisement poll frame; transmitting a common-based start-of-range (SOR) frame to the second device; and performing a ranging session procedure with a plurality of second devices after an initialization procedure according to the common-based advertisement poll frame, the common-based advertisement response frame, and the common-based SOR frame, wherein a private address broadcast in the ranging session procedure includes a private address based on identity resolution key (IRK) information generated by using an identity information representing a device related to the ranging session procedure or a predefined specific value. 2.The method of claim 1, wherein: the IRK information is generated by using a value of the identity information based on the identity information being included in the common-based advertisement poll frame. 3.The method of claim 1, wherein: the IRK information is generated by using the predefined specific value based on the identity information not being included in the common-based advertisement poll frame. 4.The method of claim 1, wherein: the predefined specific value is a 0xFFFFFF value having a 3-octet size. 5.The method of claim 1, wherein: the IRK information is generated by concatenating the identity information or the predefined specific value to a common address for the first device. 6.The method of claim 5, wherein: the IRK information is generated by appending a zero padding to a front or a rear of the common address for the first device. 7.The method of claim 5, wherein: the common address for the first device is randomly generated by the first device and included in at least one of the common-based advertisement poll frame or the common-based SOR frame. 8.The method of claim 9, wherein: the common address for the first device, the identity information, and the predefined specific value each have a 3-byte size, and the zero padding has a 10-byte size. 9.The method of claim 1, wherein: the IRK information is generated by appending a zero padding to a front or a rear of the identity information or the predefined specific value. 10.The method of claim 1, wherein: a private address included in the broadcast poll frame includes a hash field and a Prand field based on the IRK information, and a private address included in a response frame and a report frame related to the broadcast poll frame includes the hash field based on the IRK information. 11.The method of claim 10, wherein: the Prand field is set to a value having a 3-byte size randomly generated by the first device. 12.The method of claim 1, wherein: the broadcast poll message corresponds to a first poll message among a plurality of poll messages within the ranging session procedure. ​ 13.The method of claim 12, wherein: a polling message subsequent to the broadcast polling message includes a private address based on IRK information generated by using a first public address for the first device and a second public address for a second device addressed to a corresponding polling message. 14.The method of claim 1, wherein: by the initialization procedure, list information including at least one of IRK information for the first device, IRK information for the second device, or IRK information for the devices related to the ranging session procedure is generated by the first device and the second device, respectively. 15.The method of claim 1, wherein: the first device is an initiator or a controller, and the second device is a responder or a controlee. 16.The method of claim 1, wherein: the initialization procedure is performed on a narrow band (NB) initialization channel or a UWB initialization channel, and the ranging session procedure is performed on a UWB ranging channel. 17.A first device apparatus in an ultra wide band (UWB) wireless network system, the apparatus comprising: at least one transceiver; and at least one processor connected to the at least one transceiver, wherein the at least one processor is configured to: broadcast a public-based advertisement polling frame; receive a public-based advertisement response frame from a second device in response to the public-based advertisement polling frame; transmit a public-based start of ranging (SOR) frame to the second device; and perform a ranging session procedure with a plurality of second devices after an initialization procedure according to the public-based advertisement polling frame, the public-based advertisement response frame, and the public-based SOR frame, wherein a polling message broadcast in the ranging session procedure includes a private address based on identity resolution key (IRK) information generated by using an identity information representing a device related to the ranging session procedure or a pre-defined specific value. 18.A method performed by a second device in an ultra wide band (UWB) wireless network system, the method comprising: receiving a public-based advertisement polling frame from a first device; transmitting a public-based advertisement response frame to the first device in response to the public-based advertisement polling frame; receiving a public-based start of ranging (SOR) frame from the first device; and performing a ranging session procedure with the first device after an initialization procedure according to the public-based advertisement polling frame, the public-based advertisement response frame, and the public-based SOR frame, wherein a polling message broadcast in the ranging session procedure includes a private address based on identity resolution key (IRK) information generated by using an identity information representing a device related to the ranging session procedure or a pre-defined specific value. 19.A second device apparatus in an ultra wide band (UWB) wireless network system, the apparatus comprising: at least one transceiver; and at least one processor connected to the at least one processor, ​ ​ ​ wherein the at least one processor is configured to: receive a public-based advertisement poll frame from a first device; in response to the public-based advertisement poll frame, transmit a public-based advertisement response frame to the first device; receive a public-based start-of-range (SOR) frame from the first device; and perform a ranging session procedure with the first device after an initialization procedure according to the public-based advertisement poll frame, the public-based advertisement response frame, and the public-based SOR frame, wherein a polling message broadcasted in the ranging session procedure includes a private address based on identity resolution key (IRK) information generated by using an identity information representing a device related to the ranging session procedure or a pre-defined specific value. 20.A processing apparatus configured to control a device in an ultra-wideband (UWB) wireless network system, the processing apparatus comprising: at least one processor; and at least one computer memory operatively connected to the at least one processor and storing instructions for execution by the at least one processor to perform a method according to any one of claims 1 to 16. 21.At least one non-transitory computer-readable medium storing at least one instruction, wherein: the at least one instruction, when executed by at least one processor, controls an apparatus to perform a method according to any one of claims 1 to 16 in an ultra-wideband (UWB) wireless network system.

Images