KR20210121004A - Ranging Unique MAC Service and PIB Attributes for IEEE 802.15.4Z - Google Patents

Abstract

A network entity and a method in which a network entity in a wireless communication system supports a ranging function are proposed. The network entity and its method include, by a higher layer of the network entity, the ranging response time node list (RrtiNodeList) for which ranging response time instantaneous information elements (RRTI IEs) indicate a list of neighboring network entities for which the received ranging counter values are requested. ) to identify; generating, by a higher layer of the network entity, a medium access control (MAC) common part sublayer (CPS) data request (MCPS-DATA.request) primitive including RrtiNodeList; transmitting the generated MCPS-DATA.request primitive to the MAC layer of the network entity; and sending MAC data including ranging information, RRTI, and ranging measurement information IEs (RMI IEs) to another network entity in the list of neighboring network entities.

Description

Ranging Unique MAC Service and PIB Attributes for IEEE 802.15.4Z

This disclosure relates generally to ranging operations in a wireless communication system. In particular, ranging unique MAC service and PIB attributes within a wireless communication network are presented.

A subject-aware communications (PAC) network is a fully distributed communications network that enables direct communication between PAC devices (PDs). PAC networks may use several topologies, such as mesh, star, etc., that support interaction between PDs for various services.

Ranging specific MAC service and PIB attributes are required within the wireless communication network.

Embodiments of the present disclosure provide ranging unique MAC service and PIB attributes within a wireless communication network.

For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings in which like reference numerals indicate like components.
1 illustrates an exemplary wireless network in accordance with embodiments of the present disclosure.
2 illustrates an example gNB according to embodiments of the present disclosure.
3 illustrates an example UE in accordance with embodiments of the present disclosure.
4A shows a high-level diagram of an orthogonal frequency division multiplexed access transmission path in accordance with embodiments of the present disclosure.
4B shows a high-level diagram of an orthogonal frequency division multiplexed access receive path in accordance with embodiments of the present disclosure.
5 illustrates an exemplary electronic device according to embodiments of the present disclosure.
6 illustrates an example many-to-many scenario in accordance with embodiments of the present disclosure.
7 illustrates exemplary single-sided two-way ranging in accordance with embodiments of the present disclosure.
8 illustrates an exemplary double-sided two-way ranging using three messages in accordance with embodiments of the present disclosure.
9 illustrates an exemplary ranging request response time IE content field format according to embodiments of the present disclosure;
10 illustrates an exemplary destination list content field format in accordance with embodiments of the present disclosure.
11 illustrates an exemplary ranging time-of-flight IE content field format in accordance with embodiments of the present disclosure.
12 illustrates an exemplary ranging round trip measurement IE content field format according to embodiments of the present disclosure.
13 illustrates an exemplary ranging response time instantaneous IE content field format according to embodiments of the present disclosure;
14 illustrates an exemplary ranging response time deferred IE content field format according to embodiments of the present disclosure;
15 illustrates an exemplary ranging angle of arrival deferral IE content field format according to embodiments of the present disclosure.
16 illustrates an exemplary ranging control single-sided TWR IE content field format according to embodiments of the present disclosure.
17 illustrates an exemplary ranging control both TWR IE content field format according to embodiments of the present disclosure.
18 illustrates example content fields of a contention period (CP) IE according to embodiments of the present disclosure.
19 shows an exemplary row of a CP table according to embodiments of the present disclosure.
20 illustrates example content fields of a ranging scheduling (RS) IE according to embodiments of the present disclosure.
21 shows an exemplary row of an RS table according to embodiments of the present disclosure.
22 illustrates an exemplary ranging next channel and preamble IE content field format according to embodiments of the present disclosure.
23 illustrates an exemplary ranging max retransmission IE content field format according to embodiments of the present disclosure.
24 shows exemplary three secure ranging PPDU formats according to embodiments of the present disclosure.
25 illustrates an exemplary MAC sublayer reference model according to embodiments of the present disclosure.
26 shows an exemplary time structure of a ranging round according to embodiments of the present disclosure.
27 illustrates another exemplary ranging device terminology-controller and controlee-according to embodiments of the present disclosure.
28 illustrates an exemplary ranging round structure according to embodiments of the present disclosure.
29 illustrates an exemplary ranging block structure according to embodiments of the present disclosure.
30 illustrates an exemplary ARC IE content field format according to embodiments of the present disclosure.
31 illustrates an exemplary RS IE content field format according to embodiments of the present disclosure.
32 shows an exemplary RS table element format according to embodiments of the present disclosure.
33 shows an exemplary message sequence diagram of a multicast DS-TWR in which the MAC layer may store timestamps and corresponding source addresses of received RFRAMEs, in accordance with embodiments of the present disclosure.
34 shows an exemplary message sequence diagram of a multicast DS-TWR in which the MAC layer is unable to store timestamps and corresponding source addresses of received RFRAMEs, in accordance with embodiments of the present disclosure.
35 shows an exemplary message sequence diagram for configuring multi-node ranging according to embodiments of the present disclosure.
36 illustrates an exemplary message sequence diagram for multi-node scheduling-based ranging configuration according to embodiments of the present disclosure.
37 shows an exemplary message sequence diagram for multi-node contention-based ranging configuration according to embodiments of the present disclosure.
38 shows a flowchart of a method for a secure ranging operation according to embodiments of the present disclosure.

In one embodiment, a network entity in a wireless communication system supporting a ranging function is proposed. A network entity is a ranging response time node list (RrtiNodeList) indicating a list of neighboring network entities for which ranging response time instantaneous information elements (RRTI IEs) are requested along with the received ranging counter values by a higher layer of the network entity. identify; generating, by a higher layer of the network entity, a medium access control (MAC) common part sublayer (CPS) data request (MCPS-DATA.request) primitive including an RrtiNodeList; and a processor configured to send the generated MCPS-DATA.request primitive to a MAC layer of the network entity. The network entity further comprises a transceiver operatively coupled to the processor, the transceiver sending ranging information, the RRTI, and ranging measurement information IEs (RMI IEs) to another network entity in the list of neighboring network entities. and is configured to transmit MAC data including The MAC layer of the network entity is further configured to send a MCPS-DATA.confirm primitive to an upper layer of the network entity.

In another embodiment, a method of a network entity in a wireless communication system supporting a ranging function is proposed. The method, by the upper layer of the network entity, ranging response time instantaneous information elements (RRTI IE), along with the received ranging counter values, a ranging response time node list (RrtiNodeList) indicating a list of requested neighboring network entities identifying; generating, by an upper layer of the network entity, a medium access control (MAC) common part sublayer (CPS) data request (MCPS-DATA.request) primitive including an RrtiNodeList; transmitting the generated MCPS-DATA.request primitive to the MAC layer of the network entity; and transmitting MAC data including ranging information, the RRTI, and ranging measurement information IEs (RMI IEs) to another network entity in the list of neighboring network entities. The MAC layer of the network entity is further configured to send a MCPS-DATA.confirm primitive to an upper layer of the network entity.

Other technical features will become apparent to those skilled in the art from the following drawings, detailed description and claims.

Before proceeding with the detailed description that follows, it is desirable to set forth definitions of certain words and phrases used throughout this patent document. The word "connects" and its derivatives refer to any direct or indirect communication between two or more components, whether or not they are in physical contact with each other. The terms "transmit", "receive", and "communicate", as well as their derivatives, include both direct and indirect communication. The terms "comprise" and "comprises" and their derivatives mean inclusive without limitation. The word "or" is an inclusive word that means "and/or connect to, combine with, can communicate with, cooperate with, intervene, juxtapose, approximate to, bind to, have, have the characteristics of, It means having a relationship with The term "controller" means any device, system, or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and/or firmware. Functions related to any particular controller can be centralized or distributed, either locally or remotely. The phrase "at least one" when used with a list of items means that different combinations of one or more of the listed items may be used, and that only one item in the list may be required. For example, “at least one of A, B, and C” includes any one of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.

In addition, various functions described below may be implemented or supported by one or more computer programs, each of which consists of computer readable program code and is implemented in a computer readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or portions thereof suitable for implementation of suitable computer readable program code. The term "computer readable program code" includes computer code of any type, including source code, object code, and executable code. The term "computer-readable medium" means a computer, such as read only memory (ROM), random access memory (RAM), hard disk drive, compact disk (CD), digital video disk (DVD), or any other type of memory. It includes all types of media that can be accessed by “Non-transitory” computer-readable media excludes wired, wireless, optical, or other communication links that transmit transitory electrical or other signals. Non-transitory computer-readable media includes media in which data can be permanently stored, and media in which data can be stored and later overwritten, such as a rewritable optical disk or a removable memory device.

Definitions for other certain words and phrases are provided throughout this patent document. Those skilled in the art will appreciate that in many, if not most cases, such definitions apply to both previous as well as subsequent uses of the words and phrases so defined.

1 to 38 discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document, are by way of example only and should not be construed as limiting the scope of the present disclosure in any way. Those skilled in the art will appreciate that the principles of the present disclosure may be implemented in any suitably configured system or apparatus.

The following documents and specifications are incorporated by reference into this disclosure as if set forth in their entirety herein: IEEE Standard for Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Object Aware Communication, IEEE Std (Standard) 802.15.8, 2017; and IEEE Standard of Wireless MAC and PHY Specifications for Low Speed Wireless Personal Area Networks (WPANs), IEEE Std 802.15.4, 2105.

Aspects, features and advantages of the present disclosure may become apparent from the following detailed description, by illustrating a number of specific embodiments and implementations, including the preferred embodiment contemplated for carrying out the present disclosure. The present disclosure may also accommodate other different embodiments, and its various details may be changed in various obvious respects without departing from the spirit and scope of the present disclosure. Accordingly, the drawings and content are to be regarded as illustrative in nature and not as limiting. The present disclosure is illustrated by way of example and is not limited to the form of the accompanying drawings.

1 to 4B below illustrate various embodiments implemented through the use of orthogonal frequency division multiplexing (OFDM) or orthogonal frequency division multiplexing access (OFDMA) communication techniques in a wireless communication system. 1-3 are not intended to imply physical or structural limitations on the manner in which other embodiments may be implemented. Other embodiments of the present disclosure may be implemented in any suitably configured communication systems.

1 illustrates an exemplary wireless network in accordance with embodiments of the present disclosure. The embodiment of the wireless network shown in FIG. 1 is for illustrative purposes only. Other embodiments of the wireless network 100 may be used without departing from the scope of the present disclosure.

As shown in FIG. 1 , a wireless network includes a gNB 101 (eg, a base station (BS)), a gNB 102 , and a gNB 103 . gNB 101 communicates with gNB 102 and gNB 103 . The gNB 101 also communicates with at least one network 130 , such as the Internet, a Private Internet Protocol (IP) network, or other data network.

The gNB 102 provides wireless broadband access to the network 130 to a first plurality of user equipments (UEs) within the coverage area 120 of the gNB 102 . The first plurality of UEs may include a UE 111 that may be located in a small business (SB); UE 112 , which may be located within enterprise E; UE 113 that may be located in a WiFi hotspot (HS); UE 114 that may be located in the first residence (R); UE 115 that may be located in a second residence (R); and UE 116 , which may be a mobile device M such as a cell phone, wireless laptop, wireless PDA, or the like. The gNB 103 provides wireless broadband access to the network 130 to a second plurality of UEs within the coverage area 125 of the gNB 103 . The second plurality of UEs includes a UE 115 and a UE 116 . In some embodiments one or more of the gNBs 101 - 103 may communicate with each other and with the UEs 111-116 using 5G, LTE, LTE-A, WiMAX, WiFi, or other wireless communication techniques. can

Depending on the type of network, the terms “base station” or “BS” refer to transmit point (TP), transmit/receive point (TRP), enhanced base station (eNodeB or eNB), 5G base station (gNB), macrocell, femtocell, WiFi access point may refer to any component (or collection of components) configured to provide wireless access to a network, such as (AP), or other wireless capable devices. Base stations may support one or more wireless communication protocols, such as 3GPP New Radio Interface/Access (NR), long term evolution (LTE), LTE Advanced (LTE-A), High-Speed Packet Access (HSPA), Wi-Fi 802.11a/b/ It can provide wireless access according to g/n/ac, etc. For the sake of convenience, the terms "BS" and "TRP" are used within this patent document to refer to the network infrastructure components that provide wireless access to remote terminals. Also, depending on the network type, “user equipment” or “UE” means any component such as “mobile station”, “subscriber station”, “remote terminal”, “wireless terminal”, “reception point”, or “user equipment” can be called For convenience, the terms "user equipment" and "UE" are used in this patent document, whether the UE is a mobile device (such as a mobile phone or smartphone) or generally considered a stationary device (such as a desktop computer or vending machine). , is used to refer to a remote wireless device that wirelessly accesses the BS.

The dashed lines show the approximate extent of the coverage areas 120 and 125 shown in approximate circle shape for purposes of illustration and description only. It will be clearly understood that coverage areas associated with gNBs, such as coverage areas 120 and 125 , may have other shapes including irregular shapes, depending on the configuration of the gNBs and variations in the wireless environment associated with natural and man-made obstacles. can

As described in more detail below, one or more of the UEs 111-116 include circuitry, programming, or a combination thereof for CSI reporting in an advanced wireless communication system. In certain embodiments, one or more of the gNBs 101 - 103 include circuitry, programming, or a combination thereof for CSI acquisition in an advanced wireless communication system.

Although FIG. 1 shows an example of a wireless network, various modifications may be made to FIG. 1 . For example, a wireless network may include any number of gNBs and any number of UEs with any suitable arrangement. The gNB 101 may also communicate directly with any number of UEs to provide them with wireless broadband access to the network 130 . Likewise, each gNB 102 - 103 may communicate directly with the network 130 to provide UEs with direct wireless broadband access to the network 130 . Additionally, gNBs 101 , 102 , and/or 103 may provide access to other or additional external networks, such as an external telephone network or other type of data network.

2 illustrates an example gNB 102 in accordance with embodiments of the present disclosure. The embodiment of the gNB 102 shown in FIG. 2 is only exemplary, and the gNBs 101 and 103 of FIG. 1 may have the same or similar configuration. However, gNBs come in a wide variety of configurations, and FIG. 2 does not limit the scope of the present disclosure to any particular implementation of the gNB.

As shown in Figure 2, gNB 102 includes multiple antennas 205a-205n, multiple RF transceivers 210a-210n, transmit (TX) processing circuitry 215, and receive (RX) processing circuitry ( 220). gNB 102 also includes a controller/processor 225 , memory 230 , and a backhaul or network interface 235 .

RF transceivers 210a - 210n receive incoming RF signals, such as signals transmitted by UEs in network 100 , from antennas 205a - 205n. RF transceivers 210a-210n down-convert incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to RX processing circuitry 220, which filters, decodes, and/or binarizes the baseband or IF signals to generate processed baseband signals. The RX processing circuitry 220 sends the processed baseband signals to the controller/processor 225 for further processing.

The TX processing circuitry 215 receives analog or digital data (such as voice data, web data, email, or interactive video game data) from the controller/processor 225 . TX processing circuitry 215 encodes, multiplexes, and/or binarizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceivers 210a-210n receive the processed outgoing baseband or IF signal from TX processing circuitry 215 and upstream the baseband or IF signals transmitted via antennas 205a-205n to RF signals. convert

The controller/processor 225 may include one or more processors or other processing devices that control the overall operation of the gNB 102 . For example, controller/processor 225 may receive and reverse channel signals forward by RF transceivers 210a-210n, RX processing circuitry 220, and TX processing circuitry 215 in accordance with well-known principles. It is possible to control the transmission of signals. The controller/processor 225 may also support additional functions such as more advanced wireless communication functions.

For example, the controller/processor 225 may support beamforming or directional routing operations that weight outgoing signals differently to effectively steer the outgoing signals from the various antennas 205a - 205n in a desired direction. Any of a wide variety of other functions may be supported within gNB 102 by controller/processor 225 .

Controller/processor 225 may also execute programs and other processes resident in memory 230, such as an OS. The controller/processor 225 may move data into or out of the memory 230 as required by an executing process.

The controller/processor 225 is also coupled to a backhaul or network interface 235 . The backhaul or network interface 235 allows the gNB 102 to communicate with other devices or systems over a backhaul connection or network. Interface 235 may support communication over any suitable wired or wireless connection(s). For example, when gNB 102 is implemented as a cellular communication system (such as a system that supports 5G, LTE, or LTE-A), interface 235 allows gNB 102 to communicate via a wired or wireless backhaul connection. Enables communication with gNBs. When the gNB 102 is implemented as an access point, the interface 235 allows the gNB 102 to communicate via a wired or wireless local area network, or via a wired or wireless connection to a larger network (such as the Internet). can Interface 235 includes any suitable structures that support communication over a wired or wireless connection, such as an Ethernet or RF transceiver.

Memory 230 is coupled to controller/processor 225 . Part of memory 230 may include RAM, and another part of memory 230 may include flash memory or other ROM.

Although FIG. 2 shows an example of a gNB 102 , various modifications may be made to FIG. 2 . For example, gNB 102 may include any number of each of the components shown in FIG. 2 . As a specific example, the access point may include multiple interfaces 235 and the controller/processor 225 may support routing functions to route data between different network addresses. As another specific example, although shown as including one instance of TX processing circuitry 215 and one instance of RX processing circuitry 220 , gNB 102 may include multiple instances for each (RF transceiver). one per, etc.). In addition, various components in FIG. 2 may be combined, further subdivided, or omitted, and additional components may be added according to specific needs.

3 illustrates an example UE 116 in accordance with embodiments of the present disclosure. The embodiment of the UE 116 shown in FIG. 3 is only exemplary, and the UEs 111-115 of FIG. 1 may have the same or similar configuration. However, UEs come in a wide variety of configurations, and FIG. 3 does not limit the scope of the present disclosure to any particular implementation of the UE.

As shown in FIG. 3 , the UE 116 includes an antenna 305 , a radio frequency (RF) transceiver 310 , a TX processing circuit 315 , a microphone 320 , and a receive (RX) processing circuit 325 . includes The UE 116 also includes a speaker 330 , a processor 340 , an input/output (I/O) interface (IF) 345 , a touchscreen 350 , a display 355 , and a memory 360 . The memory 360 includes an operating system (OS) 361 and one or more applications 362 .

The RF transceiver 310 receives, from the antenna 305 , an incoming RF signal transmitted by the gNB of the network 100 . The RF transceiver 310 down-converts an incoming RF signal to generate an intermediate frequency (IF) or baseband signal. The IF or baseband signals are sent to RX processing circuitry 325, which filters, decodes, and/or binarizes the baseband or IF signals to generate processed baseband signals. The RX processing circuit 325 transmits the processed baseband signal to the speaker 330 (in the case of voice data, etc.) or to the processor 340 (in the case of web browsing data).

TX processing circuitry 315 receives analog or digital voice data from microphone 320 , or other outgoing baseband data (web data, email or interactive video game data) from processor 340 . TX processing circuitry 315 encodes, multiplexes, and/or binarizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver 310 receives the processed outgoing baseband or IF signal from the TX processing circuitry 315 and up-converts the baseband or IF signal transmitted through the antenna 305 into an RF signal.

Processor 340 may include one or more processors or other processing devices, and may execute OS 361 stored in memory 360 to control the overall operation of UE 116 . For example, processor 340 controls reception of forward channel signals and transmission of reverse channel signals by RF transceiver 310 , RX processing circuitry 325 , and TX processing circuitry 315 according to well-known principles. can do. In some embodiments processor 340 includes at least one microprocessor or microcontroller.

Processor 340 may execute other processes and programs resident in memory 360 , such as processes for CSI reporting on an uplink channel. Processor 340 may move data into or out of memory 360 as required by an executing process. In some embodiments, processor 340 is configured to execute applications 362 based on OS 361 or in response to signals received from gNBs or an operator. The processor 340 is also coupled with an I/O interface 345 that provides the UE 116 with connectivity to other devices such as laptop computers and handheld computers. The I/O interface 345 is a communication path between these accessories and the processor 340 .

Processor 340 is also coupled with touch screen 350 and display 355 . An operator of the UE 116 may enter data into the UE 116 using the touch screen 350 . Display 355 may be a liquid crystal display, a light emitting diode display, or other display capable of rendering text and/or at least limited graphics from web sites or the like.

Memory 360 is coupled to processor 340 . A portion of the memory 360 may include random access memory (RAM), and another portion of the memory 360 may include a flash memory or other read-only memory (ROM).

Although FIG. 3 shows an example of a UE 116 , various modifications may be made to FIG. 3 . For example, various components in FIG. 3 may be combined, further subdivided, or omitted, and additional components may be added according to specific needs. As a specific example, processor 340 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, while FIG. 3 shows a UE 116 configured as a mobile phone or smartphone, the UEs may be configured to operate as other types of mobile or stationary devices.

4A is a high-level diagram of a transmission path circuit. For example, the transmit path circuitry may be used for orthogonal frequency division multiplexed access (OFDMA) communications. 4B is a high-level diagram of a receive path circuit. For example, the receive path circuitry may be used for orthogonal frequency division multiplexed access (OFDMA) communications. 4A and 4B , for downlink communication, the transmit path circuitry may be implemented in a base station (gNB) or a relay station, and the receive path circuitry may be implemented in a user equipment (eg, user equipment 116 in FIG. 1 ). . In other examples, for uplink communication, receive path circuitry 450 may be implemented in a base station (eg, gNB in FIG. 1 ) or a relay station, and transmit path circuitry may be implemented in a user equipment (eg, user equipment 116 in FIG. 1 ). ) can be implemented in

The transmission path circuitry comprises a channel coding and modulation block 405, a series-parallel (S-to-P) block 410, an inverse fast Fourier transform (IFFT) block of size N (415), a parallel-to-serial (P-to) block. -S) includes a block 420 , a cyclic prefix addition block 425 , and an up converter (UC) 430 . Receive path circuit 250 includes a down converter (DC) 455, a cyclic prefix removal block 460, a series-parallel (S-to-P) block 465, a fast Fourier transform (FFT) block of size N ( 470 , a parallel-to-serial (P-to-S) block 475 , and a channel decoding and demodulation block 480 .

At least some of the components of FIGS. 4A ( 400 ) and 4B ( 450 ) may be implemented through software, and other components may be implemented through configurable hardware or a mixture of software and configurable hardware. In particular, it should be noted that the FFT blocks and IFFT blocks described in this disclosure may be implemented as configurable software algorithms, where the value of size N may change depending on the implementation.

Also, although the present disclosure is directed to embodiments implementing Fast Fourier Transform and Inverse Fast Fourier Transform, this is merely an example and should not be construed as limiting the scope of the present disclosure. It will be appreciated that in another embodiment of the present disclosure the fast Fourier transform functions and the inverse fast Fourier transform functions can be easily replaced with discrete Fourier transform (DFT) functions and inverse discrete Fourier transform (IDFT) functions, respectively. . For the DFT and IDFT functions, it will be expected that the value of the N variable can be any integer (ie, 1, 4, 3, 4, etc.), and for the FFT and IFFT functions, the value of the N variable. It can be expected that can be any integer that is a power of 2 (ie, 1, 2, 4, 8, 16, etc.).

In transmit path circuitry 400, a channel coding and modulation block 405 receives a set of information bits, applies coding (eg, LDPC coding), and modulates the input bits (eg, Quadrature Phase Shift Keying (QPSK)). ) or QAM (Quadrature Amplitude Modulation)), and generates a sequence of frequency domain modulation symbols. Serial-parallel block 410 converts serially modulated symbols to parallel data to generate N parallel symbol streams, when N is the IFFT/FFT size used for BS 102 and UE 116 ( That is, demultiplexing). An IFFT block 415 of size N performs an IFFT operation on the N parallel symbol streams to generate time domain output signals. A parallel-to-serial block 420 transforms (multiplexes) the parallel time domain output symbols from an IFFT block 415 of size N to produce a serial time domain signal. The cyclic prefix addition block 425 inserts a cyclic prefix into the time domain signal. Finally, the up-converter 430 modulates (up-converts) the output of the periodic prefix addition block 425 to an RF frequency for transmission over a wireless channel. The signal may be filtered at baseband prior to conversion to RF frequency.

The transmitted RF signal arrives at the UE 116 after passing through the radio channel, and the reverse operations are performed with respect to the operations at the gNB 102 . Down converter 455 down-converts the received signal to a baseband frequency, and periodic prefix removal block 460 removes the periodic prefix to generate a serial time domain baseband signal. The serial-to-parallel block 465 converts the time domain baseband signal to parallel time domain signals. The size N FET block 470 performs an FFT algorithm to generate N parallel frequency domain signals. The parallel-to-serial block 475 converts the parallel frequency domain signals into a sequence of modulated data symbols. A channel decode and demodulate block 480 demodulates and decodes the modulated symbols to recover the original input data stream.

Each of the gNBs 101 - 103 may implement a transmit path similar to the downlink transmission to the user equipment 111-116 and may implement a receive path similar to the uplink reception from the user equipment 111-116 . Similarly, each of the user equipment 111-116 implements a transmission path corresponding to the structure for uplink transmission to the gNBs 101-103, and implements a structure for downlink reception from the gNBs 101-103. A corresponding receive path may be implemented.

A subject-aware communications (PAC) network is a fully distributed communications network that enables direct communication between PAC devices (PDs). PAC networks may use several topologies, such as mesh, star, etc., that support interaction between PDs for various services. While this disclosure develops and exemplifies the disclosure using PAC networks and PDs as examples, it should be understood that the disclosure is not limited to such networks. The general concepts developed in this disclosure may be used within various types of networks with various types of scenarios.

5 illustrates an exemplary electronic device 500 in accordance with embodiments of the present disclosure. The embodiment of the electronic device 500 shown in FIG. 5 is for illustrative purposes only. 5 does not limit the scope of the present disclosure to any particular embodiment. The electronic device 500 may perform a function or functions 111-116 as illustrated in FIG. 1 . In one embodiment, the electronic device may be 111-116 and/or 101-103 as shown in FIG. 1 .

The PDs may be electronic devices. Fig. 5 shows an exemplary electronic device 501 in a network environment 500 according to various embodiments. Referring to Fig. 5, the electronic device 501 in the network environment 500 is a first network 598. It may communicate with the electronic device 502 via (eg, a short-range wireless communication network) or with the electronic device 104 or the server 508 via a second network 599 (eg, a long-range wireless communication network). According to an embodiment, the electronic device 501 may communicate with the electronic device 504 through the server 508 .

According to an embodiment, the electronic device 501 includes a processor 520 , a memory 530 , a sound output device 555 , a display device 560 , an audio 570 , a sensor 576 , an interface 577 , haptic 579 , camera 580 , power management 588 , battery 589 , communication interface 590 , subscriber identity module (SIM) 596 , or antenna 597 . . In some embodiments, at least one of the components (eg, the display device 560 or the camera 580 ) may be omitted from the electronic device 501 , or one or more other components may be omitted from the electronic device 501 . can be added to In some embodiments, some of the components may be implemented as a single integrated circuit. For example, the sensor 576 (eg, a fingerprint sensor, an iris sensor, or an illumination sensor) may be implemented as being embedded within the display device 560 (eg, a display).

The processor 520 executes, for example, software (eg, a program 540) for controlling at least one other component (eg, hardware or software component) of the electronic device 501 connected to the processor 520 . It can perform various data processing or calculations. According to one embodiment of the present disclosure, as at least part of data processing or computation, the processor 520 stores commands or data received from other components (eg, the sensor 576 or communication interface 590) into a volatile memory ( It may be loaded into 532 , process commands or data stored in volatile memory 532 , and store the resulting data in non-volatile memory 534 .

According to an embodiment of the present disclosure, the processor 520 operates independently of or in conjunction with the main processor 521 (eg, central processing unit (CPU) or application processor (AP)) and the main processor 521 . It may include a coprocessor 523 (eg, a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) capable of performing the functions. Additionally, or alternatively, the co-processor 523 may consume less power than the main processor 521 or may be adapted to be specific to a particular function. The auxiliary processor 523 may be implemented separately from or as a part of the main processor 521 .

The coprocessor 523 replaces the main processor 521 while the main processor 521 is inactive (eg, in a sleep state) or while the main processor 521 is in an active state (eg, running an application). Together with 521 , one of the functions or states related to at least one of the components of the electronic device 501 (eg, the display device 560 , the sensor 576 , or the communication interface 590 ). At least some of it can be controlled. According to one embodiment, the coprocessor 523 (eg, an image signal processor or communication processor) is part of another component functionally associated with the coprocessor 523 (eg, the camera 580 or communication interface 190 ). can be implemented as

The memory 530 may store various data used by at least one component (eg, the processor 520 or the sensor 576 ) of the electronic device 501 . The various data may include, for example, input data or output data for software (eg, program 540 ) and instructions related thereto. Memory 530 may include volatile memory 532 and/or non-volatile memory 534 .

The program 50 may be stored in the memory 530 as software, and may include, for example, an operating system (OS) 542 , middleware 544 , or an application 546 .

The input device 550 may receive a command or data to be used by another component (eg, the processor 520 ) of the electronic device 101 from outside (eg, a user) of the electronic device 501 . 550 may include, for example, a microphone, mouse, keyboard, or digital pen (eg, a stylus pen).

The sound output device 555 may output sound signals to the outside of the electronic device 501 . The sound output device 555 may be, for example, a speaker or a receiver. The speaker can be used for general purposes such as multimedia playback or record playback, and the receiver can be used for incoming calls. According to an embodiment, the receiver may be implemented separately from or as part of the speaker.

The display device 560 may visually provide information to the outside (eg, a user) of the electronic device 501 . The display device 560 may include, for example, a display, a hologram device, or a projector, and control circuitry for controlling a corresponding one of the display, the hologram device, and the projector. According to an embodiment, the display device 560 may include a touch circuit configured to detect a touch or a sensor circuit (eg, a pressure sensor) configured to measure the intensity of a force generated by the touch.

Audio 570 may convert sound into electrical signals and vice versa. According to an embodiment, the audio 570 acquires sound through the input device 550 , or is directly (eg, using a wire) or wirelessly connected externally with the sound output device 555 or the electronic device 501 . Sound may be output through headphones of the electronic device (eg, the electronic device 502 ).

The sensor 576 detects an operating state (eg, power or temperature) of the electronic device 501 or an environmental state (eg, a user's state) outside the electronic device 501 , and then an electrical corresponding to the detected state. It can generate signals or data values. According to one embodiment, the sensor 576 may be, for example, a gesture sensor, a gyro sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor. It may include a sensor, a humidity sensor, or an illuminance sensor.

The interface 577 may support one or more specific protocols to be used by the electronic device 501 to connect with an external electronic device (eg, the electronic device 502 ) directly (eg, using a wired connection) or wirelessly. According to an embodiment of the present disclosure, the interface 577 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface. .

The connection terminal 578 may include a connector that enables the electronic device 501 to be physically connected to an external electronic device (eg, the electronic device 502 ). According to an embodiment, the connection terminal 578 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).

The haptic 579 may convert an electrical signal into a mechanical stimulus (eg, vibration or movement) or an electrical stimulus that the user can recognize through his tactile sense or kinesthetic sense. According to an embodiment, the haptic 579 may include, for example, a motor, a piezoelectric element, or an electrical stimulator.

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

The power management 588 may manage power supplied to the electronic device 501 . According to one embodiment, power management 588 may be implemented, for example, as at least part of a power management integrated circuit (PMIC). The battery 589 may supply power to, for example, at least one component of the electronic device 501 . According to an embodiment, the battery 589 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

The communication interface 590 is a direct (eg, wired) communication channel or wireless communication between the electronic device 101 and an external electronic device (eg, the electronic device 502 , the electronic device 504 , or the server 508 ). By setting a channel, it is possible to support performing communication through the set communication channel. Communication interface 590 may include one or more communication processors (eg, an application processor (AP)) that may operate independently of processor 520 , and support direct (eg, wired) communication or wireless communication. .

According to one embodiment of the present disclosure, communication interface 590 may be a wireless communication interface 592 (eg, a cellular communication interface, a short-range wireless communication interface, or a global navigation satellite system (GNSS) communication interface) or a wired communication interface 594 . ) (eg, a local area network (LAN) communication interface or power line communication (PLC)). A corresponding one of these communication interfaces is a first network 598 (eg, a short-range communication network such as Bluetooth, wireless-fidelity (Wi-Fi) Direct, ultra-wide band (UWB), or infrared data association (IrDA). ) or a second network 599 (eg, a cellular network, the Internet, or a long-distance communication network such as a computer network (eg, a LAN or wide area network (WAN)).

These various types of communication interfaces may be implemented as a single component (eg, a single chip), or may be implemented as multiple distinct components (eg, multiple chips). The wireless communication interface 592 uses subscriber information (eg, international mobile subscriber identity (IMSI)) stored in the subscriber identification module 596 within a communication network, such as the first network 598 or the second network 599 . to identify and permit the electronic device 501 .

The antenna 597 may transmit a signal to or receive a signal from the outside of the electronic device 501 (eg, an external electronic device). According to an embodiment, the antenna 597 may include an antenna including a radiating element formed of a conductive material or a conductive pattern formed on a substrate (eg, a PCB). According to an embodiment, the antenna 597 may include a plurality of antennas. In such a case, at least one antenna suitable for the communication scheme used in the communication network, such as the first network 198 or the second network 599 , is connected from the plurality of antennas, for example, to the communication interface 590 (eg, the wireless communication interface). (592)). Then, a signal or power may be transmitted or received between the communication interface 590 and the external electronic device through the selected at least one antenna. According to one embodiment, components other than the radiating element (eg, radio frequency integrated circuit (RFIC)) may be further formed as part of the antenna 597 .

At least some of the components described above may be connected to each other and communicate signals between them via a peripheral-to-peripheral communication scheme (eg, a bus, general purpose input/output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)). (eg, commands or data).

According to an embodiment of the present disclosure, commands or data may be transmitted or received between the electronic device 501 and the external electronic device 504 through the server 508 connected to the second network 599 . Each of the electronic devices 502 and 504 may be the same type as the electronic device 501 or a different type of device. According to an embodiment, all or some of the operations to be performed by the electronic device 501 may be performed by one or more of the external electronic devices 502 , 504 , or 508 . For example, if the electronic device 501 can perform a function or service automatically or in response to a request from a user or other device, the electronic device 501 may perform the function or service instead of, or in addition to, It may request one or more external electronic devices to perform at least a part of the function or service. One or more external electronic devices that have received the request may perform at least a part of the requested function or service or an additional function or additional service related to the request, and transmit the execution result to the electronic device 501 . The electronic devices 501 may provide the output as at least part of a response to the request with or without further processing for the output. For this purpose, for example, cloud computing, distributed computing, or client-server computing technology may be used.

The electronic device according to various embodiments may be one of various types of electronic devices. The electronic devices may include, for example, a portable communication device (eg, a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. According to an embodiment of the present disclosure, electronic devices are not limited to those described above.

The various embodiments referred to herein are software comprising one or more instructions stored in a machine (eg, electronic device 501 ) readable storage medium (eg, internal memory 536 or external memory 538 ). (eg, program 140 ). For example, a processor (eg, processor 520 ) of a machine (eg, electronic device 501 ) invokes at least one of one or more instructions stored in a storage medium to execute one or more other components under processor control. You can execute the command with or without it. This makes it possible for the machine to be operated to perform at least one function according to the at least one instruction invoked. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The device-readable storage medium may be provided in the form of a non-transitory storage medium. As used herein, the term “non-transitory” simply means that the storage medium is a tangible device that does not contain signals (eg, electromagnetic waves), and the term refers to both cases where data is semi-permanently stored on the storage medium and when data is stored on the storage medium. It does not distinguish between temporary storage cases.

According to an embodiment of the present disclosure, the method according to various embodiments of the present disclosure may be provided by being included in a computer program product. A computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a machine-readable storage medium (eg, compact disc read only memory (CD-ROM)), distributed online through an application store (eg, playstore), or distributed online (eg, downloaded or uploaded ), can be distributed directly between two user devices (eg, smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily created or at least temporarily stored in a machine-readable storage medium, such as a memory of a manufacturer's server, a server of an application store, or a relay server.

According to various embodiments of the present disclosure, each component (eg, a module or a program) of the above-described components may include a singular or a plurality of entities. According to various embodiments, one or more of the above-described components may be omitted, or one or more other components may be added. Alternatively or additionally, a plurality of components (eg, a module or a program) may be integrated into one component. In such a case, according to various embodiments, the integrated component may include one of each of the plurality of components in the same or similar manner as one or more functions are performed by a corresponding one of the plurality of components prior to integration. You can continue to perform the above functions. According to various embodiments, operations performed by a module, program, or other component are executed sequentially, in parallel, repeatedly, or heuristically, or operations performed by one or more of the above processes are executed in a different order; It may be omitted, or one or more other operations may be added.

Ultra-wideband communication, implemented by sending short radio pulses, has several key benefits, including low complexity transceiver design, large capacity by utilizing large bandwidth, and robustness to intersymbol interference (ISI) in multipath environments. to wireless communication. On the other hand, extremely narrow pulses also lower the possibility of interference and detection by third parties, which is highly desirable for data services with high security requirements, such as secure ranging. Currently, IEEE 802.15.4z seeks and develops improvements for the specifications of low-speed and high-speed UWB impulse radios aimed at providing greater integrity and efficiency.

Ranging and related localization are essential in various location-based services and applications, such as Wi-Fi Direct, Internet of Things (IoT), and the like. With the tremendous increase in network devices, high demand ranging requests can be expected in the near future, which means that the overall ranging message exchange within the network occurs frequently. This can exacerbate the bottleneck limited by battery capacity. Energy efficiency becomes more important in mobile devices and self-maintained stationary appliances, such as low power sensors.

Another major problem in a high-density environment is latency in implementing ranging sessions scheduled for various ranging pairs. Based on the ranging procedures defined in the IEEE specification, dedicated time slots may be allocated to each ranging pair. If there is a large amount of ranging requests, it may result in long latency for late scheduling pairs.

Accordingly, there is a need for implementation of more efficient ranging protocols to reduce the number of message exchanges required for many ranging pairs. In the present disclosure, an optimized ranging procedure between one group of devices and another group of devices is provided. As shown in FIG. 6 , one or more devices of group 1 request ranging from one or more devices of group 2 (group-2), or vice versa. Using the broadcast nature of the radio channel, optimized transmission mechanisms based on ranging operation: single-sided two-way ranging (SS-TWR) and double-sided two ranging -way ranging (DS-TWR) can each be implemented, which significantly reduces the number of information exchanges required compared to current standards.

6 illustrates an example many-to-many scenario 600 in accordance with embodiments of the present disclosure. The embodiment of the many-to-many scenario 600 shown in FIG. 6 is for illustrative purposes only. 6 does not limit the scope of the present disclosure to any particular embodiment. As shown in FIG. 6 , each node in group 1 and group 2 may perform the function or functions of 111-116 and 101-103 shown in FIG. 1 . In one embodiment, each node in group 1 and group 2 may be one of 111-116 and/or 101-103 shown in FIG. 1 .

As shown in FIG. 6 , group 1 and group 2 are determined to have one or more devices. One or more devices of group 1 request ranging from one or more devices of group 2

In the present disclosure, so that a pair of devices perform ranging message exchange, devices and related messages are supported by respective terms as follows: initiator - first ranging frame (RFRAME) a device that initializes and transmits to one or more responders; responder—a device expecting to receive a first RFRAME from one or more initiators; poll - RFRAME sent by the initiator, and ranging response. RFRAME is sent by the responder.

The IEEE standard specification ignores two aspects that are essential for future use cases. The first aspect is an optimized transmission procedure between one or more initiators and one or more responders, which can be important for energy saving purposes. Since a poll can be broadcast to multiple responders, the initiator initiates a multicast, i.e., one-to-many ranging round by sending one poll instead of starting multiple unicast ranging rounds. can do. Similarly, since the ranging response can also be broadcast to multiple initiators, the responder can embed data requested from different initiators in one ranging response message. Taking advantage of the broadcast characteristics of the radio channel, an optimized transmission procedure may be desirable for future UWB networks.

Another neglected aspect is the option for contention-based ranging within UWB networks. In the IEEE specification, one ranging round includes only one pair of devices, that is, one initiator and one responder. Within one ranging round, transmissions are implicitly scheduled: the responder/initiator can expect to receive a message from the far end and then start transmitting. Multiple ranging rounds may be scheduled by the CFP table of the sync frame. However, there may be other use cases that cannot be supported by the IEEE standard specification. For example, the initiator broadcasts a poll, but has no prior knowledge of who will respond. Likewise, the responder may not have prior knowledge of who will initiate the ranging, so may wait and pay attention for a certain amount of time to collect polls from each of the different initiators.

In this disclosure, a UWB network is provided with ranging requests between one group of devices and another group of devices. As shown in FIG. 6 , one or more devices in group 1 request ranging from one or more devices in group 2, or vice versa. In order to accommodate the optimized ranging transmission procedure and other new use cases, the setting of the device role, i.e., whether the setting of the device is an initiator or a responder, and scheduling information for scheduling-based ranging are determined to start a ranging round. must be exchanged before Aiming to build a standalone UWB network, this disclosure defines a new Control IE, and a Ranging Scheduling IE for Initiators and Responders, which can be exchanged via UWB MAC. However, the present disclosure does not exclude other methods of exchanging information through higher layers or out-of-band management.

7 illustrates an exemplary one-sided interactive ranging 700 in accordance with embodiments of the present disclosure. The embodiment of one-sided interactive ranging 700 shown in FIG. 7 is for illustrative purposes only. 7 does not limit the scope of the present disclosure to any particular implementation. The one-sided interactive ranging 700 may be performed in the electronic device 501 as shown in FIG. 5 .

SS-TWR involves a simple measure of the round-trip delay of a single message from an initiator to a responder and a response sent back to the initiator. The operation of the SS-TWR is as shown in FIG. 7 , where device A initiates an exchange and device B responds to perform the exchange. Each device precisely timestamps the transmission and reception times of the message frame, and thus can calculate _{the times T round} and T _{reply through simple subtraction.} Therefore, the resulting time-of-flight T _prop can be estimated using the following equation:

8 illustrates an example bilateral interactive ranging 800 using three messages in accordance with embodiments of the present disclosure. The embodiment of bilateral interactive ranging 800 using three messages shown in FIG. 8 is for illustration only. 8 does not limit the scope of the present disclosure to any particular implementation. The bilateral interactive ranging 800 using three messages may be performed in the electronic device 501 as shown in FIG. 5 .

The DS-TWR using three messages is shown in FIG. 8 and reduces estimation errors caused by clock drift from long response delays. Device A is the initiator initiating the first round-trip measurement, and device B responds as a responder to perform the first round-trip measurement while initiating the second round-trip measurement. Each device precisely timestamps the transmission and reception times of the message, and the resulting propagation time estimate T _prop can be calculated by the following equation:

9 illustrates an exemplary ranging request response time IE content field format 900 in accordance with embodiments of the present disclosure. The embodiment of the Ranging Request Response Time IE Content Field Format 900 shown in FIG. 9 is for illustration only. 9 does not limit the scope of the present disclosure to any particular implementation. As shown in FIG. 9 , the ranging request response time IE content field format 900 may be used by an electronic device as illustrated in FIG. 5 .

With reference to payload IEs for ranging control and transmission of timestamps from the IEEE 802.15.8 document, the relevant ranging IEs are introduced here.

The Ranging Request Response Time (RRRT) IE is used as a part of the ranging exchange to request a ranging response time from a remote device participating in the ranging exchange. When the RRRT IE is used to request a response time value of a specific device or multiple devices in a multicast/broadcast/many-to-many case, the RRRT IE is a field for a destination list and a list of destinations as shown in FIG. It may include a field for the length. The destination list length field indicates the number of rows in the destination list, which may correspond to the number of devices that need to transmit a response time.

10 illustrates an exemplary destination list content field format 1000 in accordance with embodiments of the present disclosure. The embodiment of the destination list content field format 1000 shown in FIG. 10 is for illustrative purposes only. 10 does not limit the scope of the present disclosure to any particular implementation. As shown in FIG. 10 , the destination list content field format 1000 may be used by an electronic device such as that illustrated in FIG. 5 .

Each row of the destination list includes a field for the MAC address of the destination device to which the response time is to be sent, as shown in FIG. 10 . The MAC address may be a 16-bit short address, a 48-bit MAC address, or a 64-bit extended address.

The ranging time of propagation (RTOF) information element (IE) may be used to transmit a ranging result to the other party upon request. Since multiple ranging results between a device and others are embedded in one data frame, a MAC address or other short addresses, such as a multicast group address, can be added to this IE, so that the device can The ranging result can be extracted. When a single pair of devices participate in a ranging round, there is no need to use the address field. An example of an RTOF IE content field is shown in FIG. 11 . Other examples are not excluded.

11 illustrates an example ranging time of propagation IE content field format 1100 in accordance with embodiments of the present disclosure. The embodiment of the Ranging Time of Propagation IE Content Field Format 1100 shown in FIG. 11 is for illustration only. 11 does not limit the scope of the present disclosure to any particular implementation. As shown in FIG. 11 , the ranging propagation time IE content field format 1100 may be used by an electronic device such as that illustrated in FIG. 5 .

The Ranging Round Trip Measurement IE (RRTM IE) content includes the time difference between the transmission time of the ranging frame (RFRAME) that initiates the round trip measurement and the response RFRAME per source address that completes the round trip. The address field may be a 16-bit short address, a 48-bit MAC address, or a 64-bit extended address. When a single pair of devices participate in a ranging round, there is no need to use the address field. An example of the RRTM IE content field format is shown in FIG. 12 . Other examples are not excluded.

12 illustrates an exemplary ranging round trip measurement IE content field format 1200 in accordance with embodiments of the present disclosure. The embodiment of the ranging round trip measurement IE content field format 1200 shown in FIG. 12 is for illustrative purposes only. 12 does not limit the scope of the present disclosure to any particular implementation. As shown in FIG. 12 , the ranging round trip measurement IE content field format 1200 may be used in an electronic device such as that illustrated in FIG. 5 .

The RRTI IE content includes the time difference between the reception time of the most recently received RFRAME and the transmission time of the RFRAME containing the IE per source address. The address field may be a 16-bit short address, a 48-bit MAC address, or a 64-bit extended address. When a single pair of devices participate in a ranging round, there is no need to use the address field. An example of the RRTI IE content field format is shown in FIG. 13 . Other examples are not excluded.

13 illustrates an exemplary ranging response time instantaneous IE content field format 1300 in accordance with embodiments of the present disclosure. The embodiment of the ranging response time instantaneous IE content field format 1300 shown in FIG. 13 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 13 does not limit the scope of the present disclosure to any particular implementation.

Ranging Response Time Deferred IE (RRTD IE) content contains, per source address, the time difference between the reception time of the most recently received RFRAME and the transmission time of the most recently transmitted response RFRAME before the frame containing this IE. . The address field may be a 16-bit short address, a 48-bit MAC address, or a 64-bit extended address. When a single pair of devices participate in a ranging round, there is no need to use the address field. An example of the RRTD IE content field format is shown in FIG. 14 . Other examples are not excluded.

14 illustrates an exemplary ranging response time deferral IE content field format 1400 in accordance with embodiments of the present disclosure. The embodiment of the ranging response time deferral IE content field format 1400 shown in FIG. 14 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 14 does not limit the scope of the present disclosure to any particular implementation.

The ranging angle-of-arrival (AoA) deferral (RAD) IE content contains an AoA estimate at the device receiving the request for AoA. The RAD IE is used as part of the interactive ranging exchange, and is used when the device cannot determine the AoA until after the response is sent, in which case the RAD IE includes the AoA in the next frame. When the RAD IE is used for a multicast/broadcast frame (eg, multicast/broadcast/many-to-many ranging), the RAD IE content may include the MAC address or device ID of the source requesting AoA estimation. The address field may be a 16-bit short address, a 48-bit MAC address, or a 64-bit extended address. In other cases, the RAD IE has a content field of length 0. The content field of the RAD IE may have a format as shown in FIG. 15 .

15 illustrates an exemplary ranging angle of arrival deferral IE content field format 1500 in accordance with embodiments of the present disclosure. The embodiment of the ranging arrival time delay IE content field format 1500 shown in FIG. 15 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 15 does not limit the scope of the present disclosure to any particular implementation.

Ranging Report Control One-sided TWR (RRCST) IE is used to control SS-TWR message exchange. An example of the RCST IE content field format is shown in FIG. 16 and Table 1. Other examples are not excluded.

16 illustrates an exemplary ranging control single-sided TWR IE content field format 1600) according to embodiments of the present disclosure. The embodiment of the ranging control single-sided TWR IE control field format 1600 shown in FIG. 16 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 16 does not limit the scope of the present disclosure to any particular implementation.

Table 1. Values of the control information field in the ranging report control one-sided TWR IE

Ranging Report Control Both TWR (RRCDT) IEs are used to control the DS-TWR message exchange. An example of the RCDT IE content field format is shown in FIG. 17 and Table 2. Other examples are not excluded.

17 illustrates an exemplary ranging control both TWR IE content field format 1700) in accordance with embodiments of the present disclosure. The embodiment of the ranging control both TWR IE control field format 1700 shown in FIG. 17 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 17 does not limit the scope of the present disclosure to any particular implementation.

Table 2. Values of the control information field in the TWR IE of both sides of the ranging report control

Contention Period (CP) IE is used to define individual contention periods within a ranging round, each contention period being either PP or RRP. 18 and 19 show an example of IE content fields for implementing the function of defining various contention periods, but do not exclude other examples.

18 illustrates content fields of an exemplary contention period (CP) IE 1800 in accordance with embodiments of the present disclosure. The embodiment of the content fields of the contention period (CP) IE 1800 shown in FIG. 18 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 18 does not limit the scope of the present disclosure to any particular embodiment.

19 shows an exemplary row of a CP table 1900 according to embodiments of the present disclosure. The embodiment of the row of the CP table 1900 shown in FIG. 19 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 19 does not limit the scope of the present disclosure to any particular implementation.

Each row of the contention period (CP) table represents a contention-based PP/RRP, and time slots allocated between the start index and the end index. The CP table length indicates the number of rows in the CP table, which corresponds to the number of contention periods within one round.

20 illustrates example content fields of a ranging scheduling (RS) IE 2000 in accordance with embodiments of the present disclosure. The embodiment of the content fields of the ranging scheduling (RS) IE 2000 shown in FIG. 20 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 20 does not limit the scope of the present disclosure to any particular implementation.

21 shows an exemplary row of the RS table 2100 according to embodiments of the present disclosure. The embodiment of the row of the RS table 2100 shown in FIG. 21 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 21 does not limit the scope of the present disclosure to any particular implementation.

For scheduling-based ranging, a ranging scheduling (RS) IE may be used to convey resource allocation. 20 and 21 show an example of the content fields of the RS IE, other examples for performing the same function are not excluded.

The RS IE includes an RS table, and each row in the RS table consists of a time slot index, an address of a device assigned to the slot, and a flag indicating the role of the assigned device. The RS table length field indicates the number of rows in the RS table, which corresponds to the number of time slots/resource elements available in one ranging round. After successfully exchanging this IE within the UWB network, the controller and the controls become aware of their respective roles and scheduling assignments in this ranging round. Then, once the ranging round begins, the devices can act accordingly.

22 illustrates an exemplary ranging next channel and preamble IE content field format 2200 according to embodiments of the present disclosure. The embodiment of the ranging next channel and preamble IE content field format 2200 shown in FIG. 22 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 22 does not limit the scope of the present disclosure to any particular implementation.

The ranging next channel and preamble (RNCP) IE is used to specify the channel index and preamble code index of the next ranging block. The ranging next channel and preamble IE content field is shown in FIG. It can have the same format as

23 illustrates an exemplary ranging max retransmission IE content field format 2300 in accordance with embodiments of the present disclosure. The embodiment of the ranging max retransmission IE content field format 2300 shown in FIG. 23 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 23 does not limit the scope of the present disclosure to any particular implementation.

The Ranging Max Retransmission (RMR) IE is for specifying the maximum number of retries for initiators/responders to contend in multiple contention-based ranging rounds. An example of IE content fields is shown in FIG. 23 , but other examples are not excluded.

24 shows exemplary three secure ranging PPDU formats 2400 according to embodiments of the present disclosure. The embodiment of the three secure ranging PPDU formats 2400 shown in FIG. 24 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 24 does not limit the scope of the present disclosure to any particular embodiment.

In the evolution of IEEE 802.15.4z, a major improvement to secure ranging is to include a scrambled timestamp sequence (STS) in the basic PHY protocol data unit (PPDU) format. Since the device's unique STS is known by one or more parties in the trust group, security ranging can be performed within the trust group, and the likelihood of being attacked is greatly reduced. In the present disclosure, for example, a system is established according to the fact that STSs of devices, which may be performed through higher layer control or out-of-band management, have been successfully exchanged. A method of initializing/updating the STS and exchanging it between devices is outside the scope of the present disclosure.

Three secure ranging PPDU formats can be supported, and the difference between the formats is the presence of the PHR and PHY as shown in FIG. 16 and the location of the STS. The abbreviations in Fig. 24 each represent the following definitions: Synchronization Header (SHR); scrambled timestamp sequence (STS); and a PHY header (PHY).

The positions of the STS in FIG. 24 are different. In the format of FIG. 24 (eg, FIG. 24(c)), there is no PHY header or data field (NHD). Ranging based on the PPDU format of the drawing (eg, (c) of FIG. 24 ) may be referred to as NHD security ranging. Other practices of implementing similar concepts are not excluded from this disclosure.

25 illustrates an exemplary MAC sublayer reference model 1500 in accordance with embodiments of the present disclosure. The embodiment of the MAC sublayer reference model 2500 shown in FIG. 25 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 25 does not limit the scope of the present disclosure to any particular embodiment.

According to the IEEE standard specification, the MAC sublayer provides an interface between the next higher layer and the PHY. The MAC sublayer conceptually includes a management entity called MLME. This entity provides service interfaces through which hierarchical management can be applied. The MLME is responsible for database management of managed objects related to the MAC sublayer. This database is called MAC sub-layer PIB. 25 shows the components and interfaces of the MAC sub-layer.

In this disclosure, a UWB network is considered with ranging requests between one group of devices and another group of devices. As shown in FIG. 6 , one or more devices in group 1 request ranging from one or more devices in group 2, or vice versa.

Using the broadcast characteristics of the wireless channel, optimized schemes with reduced transmission count can be implemented for use cases with one or more initiators and one or more responders. In order to accommodate the secure ranging and optimized transmission scheme, the present disclosure changes the primitives of the MAC service, and defines new PIB attributes in the IEEE standard specification for the development of IEEE 802.15.4z.

26 illustrates an exemplary temporal structure of a ranging round 2600 according to embodiments of the present disclosure. The embodiment of the time structure of the ranging round 2600 shown in FIG. 26 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 26 does not limit the scope of the present disclosure to any particular implementation.

The ranging setting includes control information of a ranging round consisting of a plurality of time slots as shown in FIG. 26 . A time slot is the basic unit of time for implementing a message exchange. Other conventions for performing the same functions as ranging rounds and time slots are not excluded from this disclosure. According to device specifications, the number of time slots and the slot duration (duration) in the ranging round may be adjusted in the ranging setting, or the number of time slots and the slot duration are default settings. One or more device pairs may participate in a ranging round to fulfill ranging requests.

27 illustrates another exemplary ranging device terminology 2700 (controller and controlleder) according to embodiments of the present disclosure. The embodiment of the ranging device terms 2700 shown in FIG. 27 is for illustration only. 27 does not limit the scope of the present disclosure to any particular implementation. As shown in FIG. 27 , the controller and the controlled unit may be an electronic device 501 as illustrated in FIG. 5 . In one embodiment, the controller and the controlled as shown in FIG. 27 may be one of the nodes in group 1 and/or group 2 as shown in FIG. 6 .

As shown in FIG. 27 , the setting of the ranging configuration determined by the next higher layer may be sent from the ranging controller to one or more ranging controllers. With different network configurations, the ranging configuration may be delivered through a dedicated data frame sent to one or more devices, or embedded in a sync frame broadcast to devices in the network. Meanwhile, the present disclosure does not exclude other methods of exchanging ranging configuration information through a higher layer or out-of-band management.

28 illustrates an example ranging round structure 2800 in accordance with embodiments of the present disclosure. The embodiment of the ranging round structure 2800 shown in FIG. 28 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 28 does not limit the scope of the present disclosure to any particular embodiment.

The ranging setup includes a structure of a ranging round comprising one or more polling periods (PP) and one or more ranging response periods (RRP), where the PP is one or more polling messages from the initiator(s) to send. Consists of time slots, and RRP consists of one or more time slots to send response messages from the responder(s). 28 shows two examples of SS-TWR and DS-TWR with three message exchanges, respectively, but other examples are not excluded. The ranging round may start with a ranging control period to exchange ranging settings through the UWB MAC. However, when the ranging configuration is exchanged in a higher layer, a ranging round may be started as a polling period.

For SS-TWR, one ranging round includes PP and RRP. For DS-TWR using 3 messages, one ranging round includes 1 PP, RRP, and 2 PP. Each period includes one or more time slots in which transmission from the initiator(s)/responder(s) is scheduled as determined by the next higher layer, or within respective corresponding periods. Compete for time slots.

29 illustrates an exemplary ranging block structure 2900 according to embodiments of the present disclosure. The embodiment of the ranging block structure 2900 shown in FIG. 29 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 29 does not limit the scope of the present disclosure to any particular implementation.

The ranging block refers to a virtual ranging frame composed of a plurality of ranging rounds as shown in FIG. 29 . The UWB MAC may operate on a block-based structure, in which a block length and the number of ranging rounds in a block may be set. Within a ranging block, one or more ranging rounds may be activated.

30 illustrates an example ARC IE Content Field Format 3000 in accordance with embodiments of the present disclosure. The embodiment of the ARC IE content field format 3000 shown in FIG. 30 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 30 does not limit the scope of the present disclosure to any particular embodiment.

An advanced ranging control IE (ARC IE) is used by a controller to transmit ranging configuration information to a controller (via a unicast frame) or to a plurality of controllers (via a broadcast frame). The content field of the ARC IE has a format as shown in FIG. 30 . For detailed definitions of fields, refer to IEEE 802.15.4z.

31 illustrates an exemplary RS IE content field format 3100 according to embodiments of the present disclosure. The embodiment of the RS IE content field format 3100 shown in FIG. 31 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 31 does not limit the scope of the present disclosure to any particular implementation.

32 illustrates an exemplary RS table element format 3200 in accordance with embodiments of the present disclosure. The embodiment of the RS table element format 3200 shown in FIG. 32 is for illustrative purposes only, and may be used in the electronic device shown in FIG. 5 . 32 does not limit the scope of the present disclosure to any particular implementation.

Ranging Scheduling IE (RS IE) is used in scheduling-based ranging to specify a list of devices selected to participate in a ranging round and to convey slot resource allocation for each device. This is applied when the multi-node mode field of the ARC IE indicates one-to-many or many-to-many without contention. The content field of the RS IE may have a format as shown in FIGS. 31 and 32 .

In one embodiment, the present disclosure provides new primitives and modifies existing ones supported by MCPS-SAP, which are necessary to accommodate the above general/security ranging configuration for the development of IEEE 802.15.4z. Similar conventions for each performing the same functions may also be used and are not limited by the present disclosure.

According to the IEEE standard specification, the MCPS-DATA.request primitive requests data transfer to another device. The present disclosure modifies the content of the parameter Ranging and introduces two parameters that are also used in the IEEE standard specification, namely RequestRrtiTx and TxTime. The meanings of these primitives are:

MCPS-DATA.request(

Ranging,

RequestRrtiTx,

TxTime,

other parameters within the IEEE standard specification,

)

The modified primitive parameters are defined in Table 3A. Table 3A. MCPS-DATA.request parameters (modified)

According to the modified range of the parameter Ranging in Table 3, the upper layer may apply a specific ranging type, for example, security or general ranging in UWB MAC.

When secure or normal ranging is performed, the upper layer may request insertion of the response time in the transmitted data frame by using the primitive parameter RequestRrtiTx. In Table 3, macUWBRngRrtiTime sets the desired RX-to-TX response time. Other primitive parameters already existing in IEEE 802.15.4 are maintained, and these are not excluded from the present disclosure.

A single RFRAME may be broadcast to multiple ranging devices, and the destinations of the inserted ranging IEs may be identified by respective address fields in FIGS. 12 and 13, for example. For example, in multicast ranging between a ranging initiator and multiple ranging responders, the initiator may embed RRTI IEs into the second poll message to responders as shown in FIG. 8 .

FIG. 33 shows an example message sequence diagram 3300 of a multicast DS-TWR in which the MAC layer may store timestamps of received RFRAMEs and corresponding source addresses, in accordance with embodiments of the present disclosure. The embodiment of message sequence diagram 3300 shown in FIG. 33 is for illustrative purposes only. 33 does not limit the scope of the present disclosure to any particular implementation.

33 , the initiator, responder 1, and responder N may perform the function or functions of 111-116 and/or 101-103 illustrated in FIG. 1 . Initiator, Responder 1, and Responder N may be one of the nodes in Group 1 and/or Group 2 shown in FIG. 6 . The initiator, responder 1, and responder N may be the electronic device 501 illustrated in FIG. 5 .

After collecting RFRAMEs with RRRT IEs from different parties, if the MAC layer of the ranging device can store the reception timestamp and source ID/address of each RFRAME, the next higher layer of the ranging device returns RequestRrtiTx to TRUE By setting to , you can request the MAC layer to insert RRTI IEs into the next RFRAME. An example of a message sequence diagram for a ranging round can be shown in FIG. 33 .

34 shows an example message sequence diagram 3400 of a multicast DS-TWR in which the MAC layer is unable to store timestamps and corresponding source addresses of received RFRAMEs, in accordance with embodiments of the present disclosure. The embodiment of message sequence diagram 3400 shown in FIG. 34 is for illustrative purposes only. 34 does not limit the scope of the present disclosure to any particular implementation.

34 , the initiator, responder 1, and responder N may perform the function or functions of 111-116 and/or 101-103 illustrated in FIG. 1 . Initiator, Responder 1, and Responder N may be one of the nodes in Group 1 and/or Group 2 shown in FIG. 6 . The initiator, responder 1, and responder N may be the electronic device 501 illustrated in FIG. 5 .

According to certain implementations, without additional memory to store timestamps and corresponding source addresses, the MAC layer can pass that information to the next higher layer. For this situation, additional parameters should be introduced in the primitive of MCPS-Data.request to control the MAC layer inserting RRTI IEs, which can be defined in Table 4, but other terms for implementing similar functions are not excluded from the present disclosure. An example of a message sequence diagram for a ranging round in which the MAC layer cannot store timestamps and source addresses is shown in FIG. 34 .

Table 4. Additional MCPS-DATA.request parameters

According to the inclusion of the parameters in Table 4, the meaning of the data request primitive is as follows:

MCPS-DATA.request(

Ranging,RequestRrtiTx,

RequestRrtiDevList,

*218 RecTimeList,

TxTime,

other parameters within the IEEE standard specification,

)

The parameters in Table 4 may be combined into one RrtiNodeList containing lists of RequestRrtiDevList and RecTimeListRrtiNodeList. In the development of IEEE 82.15.4z, to enable the use of STS it can be controlled by other next higher layer primitives. The ranging parameters in Table 3A may be redefined in the following manner in Table 3B.

Table 3B. Ranging parameters

This disclosure does not exclude the option of separating two Booleans in the ranging parameter into two independent parameters in MCPS-DATA.request, that is, RangingCounterEnable and RaningPhrBit. Table 3B below illustrates the definitions of these two new parameters that can be used to replace the ranging in MCPS-DATA.request.

Table 3C. New MCPS-DATA.request parameters to replace ranging parameters

TxTime may have an appropriate time unit in IEEE 802.15.4z, such as a ranging counter time unit (RCTU) or a ranging scheduling time unit (RSTU). The present disclosure does not limit the time unit of TxTime to a specific one. In the current IEEE 802.15.4z specification, TxTime is in units of RCTUs. However, a control parameter may be introduced to specify the type of TxTime. The control parameters, and revised TxTime, are illustrated in Table 3D.

Table 3D. MCPS-DATA.request parameters: revised TxTime and new control parameters

TxTime presented in Table 3A and Table 3D has a size of 3 octets. However, other sizes of this parameter are not excluded from this disclosure.

In one embodiment, the MCPS-DATA.confirm primitive reports the results of a request to transfer data to another device. The meanings of the MCPS-DATA.confirm primitive are as follows: New parameters introduced by this disclosure are suggested, but others remain the same as in the IEEE standard specification.

MCPS-DATA.confirm (

TxRrtiValueList,

Aoa Azimuth,

Aoa Elevation,

AoaPresent,

Rssi,

other parameters within the IEEE standard specification,

}

Table 5. MCPS-DATA.confirm (modified)

To calculate the response times, the TxRrtiValueList may not need to be used, as the next higher layer may also use the transmission time reported by MCPS-DATA.confirm, along with the reception timestamps of the RFRAME from other devices.

In one embodiment, multicast DS- via one ranging initiator and multiple ranging responders in FIGS. 33 and 34 to illustrate the function of the next higher layer using the newly defined parameters in the data primitives. Message sequence diagrams for doing TWR ranging are provided.

In FIG. 33 , the MAC layer may store timestamps of received RFRAMEs and corresponding source addresses. Thus, in the data request primitive of the second polling message from the initiator, the next higher layer may request the MAC layer to insert the RRTI IE(s) using RequestRrtiTx. The MAC layer may use the stored timestamps of received RFRAMEs to calculate response times to different devices and form corresponding RRTI IEs.

In FIG. 34 , the MAC layer is unable to store timestamps and corresponding source addresses of received RFRAMEs. In the data request primitive for the second polling message from the initiator, the next higher layer sets RequestRrtiTx to TRUE , as well as the addresses of the ranging devices that requested a response time in the RequestRrtiDevList , and the last from those devices in the RecTimeList. Delivers timestamps of received RFRAMEs. The MAC layer may then use the timestamps of the received RFRAMEs to calculate response times to different devices, and may form corresponding RRTI IEs.

In one embodiment, the ranging specific properties of the PIB are provided as illustrated in Table 6.

Table 6. Ranging Unique MAC PIB Attributes

The upper layer may read and set the values of the ranging unique MAC PIB attributes that may be used by the MAC sublayer to form the corresponding IEs. For example, the upper layer determines the scheduling assignment by macUWBrngScheduleAssign which can be used to form RS IE by the MAC sublayer.

Some attributes in Table 6 are specified for ranging setting as shown in FIGS. 26 and 29 . Table 7 illustrates those attributes with modified meaning and content, and introduces some other required PIB attributes to enable the MAC layer to implement ranging settings accordingly.

Table 7. Multi-Node Ranging Unique MAC PIB Attributes

Before exchanging for ranging setup, as part of ranging set-up activities, the ranging controller may adjust the PIB attributes in Table 7 via MLME-SET.request primitives.

The next upper layer of the controller may use MultiRangingEnable in the primitive MCPS-DATA.request to instruct the MAC sublayer to implement ranging configuration according to the PIB attributes of Table 7.

MCPS-DATA.request (

MultiRangingEnable

)

Table 8 illustrates the definition of MultiRangingEnable.

Table 8. MCPS-DATA.request parameter: MultiRangingEnable

If MultiRangingEnable is true, multi-node advanced ranging is enabled to be set by the MAC sublayer of the ranging controller. According to the MAC PIB attributes in Table 7, the MAC sublayer may attempt to generate an ARC IE and insert it into a Ranging Control Message (RCM) prior to sending it. If multi-node ranging is successfully set, the status of SUCCESS in MCPS-DATA.confirm is reported to the next higher layer of the controller, otherwise the status of UNSUPPORTED_RANGING is returned.

35 illustrates an exemplary message sequence diagram 3500 for configuring multi-node ranging according to embodiments of the present disclosure. The embodiment of message sequence diagram 3500 shown in FIG. 35 is for illustrative purposes only. 35 does not limit the scope of the present disclosure to any particular implementation.

35 , the controller and the controlled unit may perform the function or functions of 111-116 and/or 101-103 illustrated in FIG. 1 . The controller and the controlled may be one of the nodes in group 1 and/or group 2 shown in FIG. 6 . The controller and the controlled may be an electronic device 501 as illustrated in FIG. 5 .

A message sequence proposed for configuring multi-node ranging is shown in FIG. 35 .

The next higher layer of the controller initiates MCPS-DATA.request with MultiRangingEnable set to true, allowing the MAC sublayer to create an ARC IE through the MAC PIB attributes in Table 7 and insert it into the RCM. At this time, MCPS-DATA.confirm reports the status of the ranging setting to the next higher layer of the controller again, and MCPS-DATA.indication controls the ARC IE and other IEs, such as RS IE for scheduling-based ranging, to the controller. pass to the next higher layer of (s).

In one embodiment, interactions/procedures are provided for implementing ranging setup via MAC sublayer. To implement both ranging setup and scheduling, E4 uses additional PIB attributes from Table 6 and introduces new parameters into MCPS-DATA.request.

Table 9 illustrates properties related to ranging scheduling. Some of these come from Table 6 with changed meanings and content. Additional PIB attributes are also introduced, allowing the MAC sublayer to implement both ranging setup and scheduling according to Tables 7 and 9.

Table 9. Ranging Scheduling Unique MAC PIB Attributes

Before exchanging for ranging setup, as part of ranging set-up activities, the ranging controller may adjust the PIB attributes in Table 7 via MLME-SET.request primitives.

Instead of using MultiRangingEnable, S5 introduces MultiRangingSchedule and MultiRangingContention in the primitive MCPS-DATA.request to distinguish between scheduling-based and contention-based multi-node advanced ranging, respectively. The next higher layer of the controller can use it to instruct the MAC sublayer to implement ranging setup and scheduling according to the PIB attributes in Tables 7 and 9.

MCPS-DATA.request (

MultiRangingSchedule

MultiRanging Content

)

Table 10 exemplifies the definitions of MultiRangingSchedule and MultiRangingConttention.

Table 10. MCPS-DATA.request parameters: MultiRangingSchedule and MultiRangingContention

If MultiRangingSchedule is true, multi-node advanced scheduling-based ranging is enabled to be set by the MAC sublayer of the ranging controller. According to the MAC PIB attributes in Table 7 and Table 9, the MAC sublayer may attempt to generate an ARC, RS IE and insert it into a Ranging Control Message (RCM) prior to sending it. If multi-node scheduling-based ranging is successfully set, the status of SUCCESS in MCPS-DATA.confirm is reported to the next higher layer of the controller, otherwise the status of UNSUPPORTED_RANGING is returned.

If MultiRangingContention is true, multi-node advanced contention-based ranging is enabled to be set by the MAC sublayer of the ranging controller. According to the MAC PIB attributes in Tables 7 and 9, the MAC sublayer may attempt to generate the ARC IE, RIRL IE, and RCPS IE and insert them into the Ranging Control Message (RCM) prior to sending them.

In contention-based ranging, when the ranging controller does not know the IDs of the ranging controllers, the MAC sublayer of the ranging controller may implement the ranging configuration through the ARC IE, but generates an RIRL IE or RCPS IE can't When the ranging controller knows the IDs of the ranging controllers, the MAC sublayer of the ranging controller generates a RIRL IE to assign a device type, that is, a ranging initiator or a responder, to the controller, and the ranging round(s) ) can use the RCPS IE to set the contention steps. If multi-node contention-based ranging is successfully set, the status of SUCCESS in MCPS-DATA.confirm is reported to the next higher layer of the controller, otherwise the status of UNSUPPORTED_RANGING is returned.

When the ranging controller initializes MCPS.DATA.request, if one of MultiRangingSchedule and MultiRangingContention is enabled with a true value, the other may have a false value or be ignored in MCPS.DATA.request.

36 illustrates an exemplary message sequence diagram 3600 for multi-node scheduling-based ranging configuration according to embodiments of the present disclosure. The embodiment of message sequence diagram 3600 shown in FIG. 36 is for illustrative purposes only. 36 does not limit the scope of the present disclosure to any particular implementation.

As shown in FIG. 36 , the controller and the controlled unit may perform the function or functions of 111-116 and/or 101-103 shown in FIG. 1 . The controller and the controlled may be one of the nodes in group 1 and/or group 2 shown in FIG. 6 . The controller and the controlled may be an electronic device 501 as illustrated in FIG. 5 .

36 shows an exemplary message sequence diagram for multi-node scheduling-based ranging configuration. The next upper layer initializes MCPS-DATA.request with MultiRangingSchedule to enable the MAC sublayer to implement advanced scheduling-based ranging configuration. With a true value, MultiRangingSchedule triggers the MAC sublayer to generate an ARC, RS IE and insert it into the RCM before sending it.

To form the ARC IE, the MAC sublayer of the controller may use the PIB attributes specified in Table 7, which are adjusted by the next higher layer before the ranging setup starts. To form the RS IE, the MAC sublayer of the controller may use the attribute macUWBrngScheduleAssign in Table 9. At this time, MCPS-DATA.confirm reports the ranging configuration status to the next higher layer of the controller, and MCPS-DATA.indication delivers ARC and RS IE to the next higher layer of the control unit(s).

37 illustrates an exemplary message sequence diagram 3700 for multi-node contention-based ranging setup according to embodiments of the present disclosure. The embodiment of message sequence diagram 3700 shown in FIG. 37 is for illustrative purposes only. 37 does not limit the scope of the present disclosure to any particular embodiment.

As shown in FIG. 37 , the controller and the controlled device may perform the function or functions of 111-116 and/or 101-103 shown in FIG. 1 . The controller and the controlled may be one of the nodes in group 1 and/or group 2 shown in FIG. 6 . The controller and the controlled may be an electronic device 501 as illustrated in FIG. 5 .

37 shows an exemplary message sequence diagram for multi-node contention-based ranging setup. The next upper layer initializes MCPS-DATA.request with MultiRangingContinion to enable the MAC sublayer to implement advanced contention-based ranging configuration. Using a value of true, MultiRangingContention triggers the MAC sublayer to generate an ARC IE and insert it into the RCM prior to sending it. In Table 9, macDevicePresence must be true, and macUWBrngAddressList is not null to form some other IEs related to contention-based ranging, for example, RCPS, RIRL IE.

To form the ARC IE, the MAC sublayer of the controller may use the PIB attributes specified in Table 7, which are adjusted by the next higher layer before the ranging setup starts. To form the RIRL IE, the MAC sublayer of the controller may use the attributes macUWBrngInitiatorList and macUWBrngAddressList in Table 9. To form the RCPS IE, the MAC sublayer of the controller may use the attribute macUWBrngCPassign in Table 9.

At this time, MCPS-DATA.confirm reports the status of the ranging setting back to the next higher layer of the controller, and MCPS-DATA.indication sends the ARC, RIRL, and/or RCPS IE to the next higher layer of the control unit(s). transmit

In one embodiment, the two timestamps in a unit of RSTU are for transmission and reception of a frame, respectively, and are introduced into the primitives of MCPS-DATA.confirm and MCPS-DATA.indication.

Newly introduced timestamp parameters for MCPS-DATA.confirm are specified below.

MCPS-DATA.confirm(

TxRstuCounter,

RxRstuCounter,

)

Table 11. MCPS-DATA.confirm parameters: Timestamps in units of RSTU

Newly introduced timestamp parameters for MCPS-DATA.indication are specified below.

MCPS-DATA.indication(

TxRstuCounter,

RxRstuCounter,

)

Table 12. MCPS-DATA.indication parameters: Timestamps in unit of RSTU

Existing timestamp parameters exist in MCPS-DATA.confirm and MCPS-DATA.indication, and may be used to indicate the reception time in units of RSTU when the multi-node ranging method is used. This option is not excluded from this disclosure. Other suitable sizes of TxRstuCounter and RxRstuCounter are also not excluded from the present disclosure.

38 is a method 3800 for a secure ranging operation in accordance with embodiments of the present disclosure, as performed by a user device (eg, 111-116 and/or 101-103 shown in FIG. 1 ). shows the flow chart of In one embodiment, the electronic device may be a network entity. The embodiment of method 3800 shown in FIG. 38 is for illustrative purposes only. 38 does not limit the scope of the present disclosure to any particular embodiment.

In one embodiment, as a network entity, which may be one of the nodes in group 1 and/or group 2 as shown in FIG. 6 , a controller and a controller may perform method 3800 . In one embodiment, an initiator and a responder may perform method 3800 .

As shown in FIG. 38 , the method 3800 begins at step 3802 . In step 3802, a network entity (eg, an electronic device) is configured by a higher layer of the network entity, ranging response time instantaneous information elements (RRTI IEs) along with received ranging counter values A lane indicating a list of neighboring network entities Identifies the Jing response time node list (RrtiNodeList).

In step 3802 of an embodiment, RrtiNodeList including a request ranging response time device list (RequestRrtiDevList) and a reception time list (RecTimeList) indicates the MAC sublayer to form RRTI IEs for response time reports; RequestRrtiDevList contains a list of ranging device addresses that are short addresses of 2 bytes long or addresses of 8 bytes extended length; RecTimeList contains a list of timestamps, each timestamp containing a length of 32 bits to represent a value between ^{0 and 2 32 -1.}

Subsequently, in step 3804, a medium access control (MAC) common part sublayer (CPS) data request (MCPS-DATA.request) primitive including an RrtiNodeList is generated by an upper layer of the network entity.

Next, in step 3806, the network entity sends the generated MCPS-DATA.request primitive to the MAC layer of the network entity.

Finally, in step 3808, the network entity sends MAC data including ranging information, RRTI, and ranging measurement information IEs (RMI IEs) to another network entity in the list of neighboring network entities, the MAC of the network entity The layer is further configured to send the MCPS-DATA.confirm primitive to the upper layer of the network entity.

In one embodiment, the network entity determines address/ranging counter pairs from the RtriNodeList parameter; When the RequestRtriTx parameter is set to a non-zero value and the MAC layer of the network entity can generate RRTI IEs, insert the RRTI IEs into the frame based on the address/ranging counter pairs by the MAC layer of the network entity; Sends a frame including RRTI IEs to the other network entity in the list of neighboring network entities.

In one embodiment, the network entity calculates the value of the RX-to-TX response time field based on the difference between the RMARKER timestamp of the transmission frame and the corresponding receive ranging counter value from the RrtiNodeList, The address corresponds to the address of RrtiNodeList.

In one embodiment, the network entity sets the ranging counter to true indicating that the ranging counter is enabled for the ranging device (RDEV) or false indicating that the ranging counter is disabled Identifies a ranging field that determines whether it is enabled or not; Determines whether the ranging bit of the physical layer header (PHR) is set to true indicating that the ranging bit of the PHR is set to 1, or is set to false indicating that the ranging bit of the PHR is not set to 1 to identify a ranging physical header (RangingPhr) field; Create an MCPS-DATA.request primitive including a ranging field and a RangingPhr field.

In one embodiment, the network entity identifies a transmission time specific (TxTimeSpecified) field that determines the use of a ranging transmission time (RangingTxTime) parameter, (i) if the TxTimeSpecified value is set to NONE, RangingTxTime is not used, ( ii) When the TxTimeSpecified value is set to the ranging counter time unit (RCTU_TIME), RangingTxTime specifies the transmission time of the frame in units of RCTU, (iii) When the TxTimeSpecified value is set to the ranging scheduling time unit (RSTU_TIME), RangingTxTime Specifies the transmission time of the frame in units of this RSTU; identify a RangingTxTime field set between 0x00000000 and 0xffffffff to specify the transmission time of the frame; Create an MCPS-DATA.request primitive including a TxTimeSpecified field and a RangingTxTime field.

In such an embodiment, the RangingTxTime parameter indicates the RMARKER transmission time when the TxTimeSpecified field is set to RCTU_TIME; The RangingTxTime parameter indicates the transmission start time of the packet when the TxTimeSpecified field is set to RSTU_TIME; The RangingTxTime parameter is not used when TxTimeSpecified is set to NONE.

In one embodiment, the network entity, from the MAC layer of the network entity, has an AngleOfArrivalAzimuth field having a value between -π and +π, and an AngleOfArrivalElevation field having a value between -π and +π. , and an MCPS-DATA.confirm primitive containing an AngleOfArrivalPresent field set to NONE (none), BOTH (both), AZIMUTH (azimuth), or ELEVATION (altitude).

In such an embodiment, the AngleOfArrival Azimuth field indicates that when the AngleOfArrivalPresent field is set to AZIMUTH or BOTH, the angle of arrival (AOA) is located in radians of the received signal in the azimuth for reception of an ACK (acknowledgement) frame. ; The AngleOfArrivalElevation field indicates that when the AngleOfArrivalPresent field is set to ELEVATION or BOTH, the AOA is located in radians of the received signal on the elevation for the reception of the ACK frame; The AngleOfArrivalPresent field indicates validity of the AngleOfArrivalAzimuth field and the AngleOfArrivalElevation field.

In one embodiment, the network entity receives, from the MAC layer of the network entity, an MCPS-DATA.confirm primitive comprising a Timestamp field having a value between 0x000000-0xffffff, wherein the Timestamp field is the enhanced ranging For the device (ERDEV), it is set to RSTU_TIME corresponding to the start time of the packet including the preamble.

In one embodiment, the network entity receives, from the MAC layer of the network entity, an MCPS-DATA.indication primitive containing a Timestamp field with a value between 0x000000-0xffffff for ERDEV.

In such an embodiment, the Timestamp field is set in RSTU_TIME corresponding to the transmission start time of the packet including the preamble.

Although the present disclosure has been described in conjunction with exemplary embodiments, various changes and modifications may be suggested to those skilled in the art. It is intended that this disclosure cover such changes and modifications as fall within the scope of the appended claims. The content of this application should not be construed as implying an essential element for which any particular element, step, or function should be included in the claims.

Claims (15)

As a network entity in a wireless communication system supporting a ranging function,
By the upper layer of the network entity, ranging response time instantaneous information elements (RRTI IEs) indicate a list of neighboring network entities requested along with the received ranging counter values ranging response time node list (RrtiNodeList) identify;
generating, by a higher layer of the network entity, a medium access control (MAC) common part sublayer (CPS) data request (MCPS-DATA.request) primitive including an RrtiNodeList;
a processor configured to send the generated MCPS-DATA.request primitive to a MAC layer of the network entity; and
operatively coupled to the processor;
a transceiver configured to transmit MAC data comprising ranging information, the RRTI, and ranging measurement information IEs (RMI IEs) to another network entity in the list of neighbor network entities;
and the MAC layer of the network entity is further configured to send a MCPS-DATA.confirm primitive to a higher layer of the network entity. According to claim 1,
The RrtiNodeList including a Request Ranging Response Time Device List (RequestRrtiDevList) and a Reception Time List (RecTimeList) indicates a MAC sublayer to form RRTI IEs for time reports;
the RequestRrtiDevList contains a list of ranging device addresses that are short addresses of 2 bytes in length or extended addresses of 8 bytes in length;
The RecTimeList is a network entity comprising a list of timestamps, each timestamp containing a 32-bit length to indicate a value between ^{0 and 2 32 -1.} 3. The method of claim 2,
the processor
determine address/ranging counter pairs from the RtriNodeList parameter;
When the RequestRtriTx parameter is set to a non-zero value and the MAC layer of the network entity can generate the RRTI IEs, based on the address/ranging counter pairs, by the MAC layer of the network entity, the further configured to insert RRTI IEs into the frame;
and the transceiver is further configured to send the frame including the RRTI IEs to the other network entity in the list of neighboring network entities. 4. The method of claim 3,
the processor is further configured to calculate a value of a RX-to-TX (RX to TX) response time field based on a difference between a RMARKER timestamp of the transmitted frame and a corresponding receive ranging counter value from the RrtiNodeList become,
The address of each RRTI list field is a network entity corresponding to the address of the RrtiNodeList. The method of claim 1, wherein the processor is
For the ranging device (RDEV), whether the ranging counter is set to TRUE indicating that the ranging counter is enabled, indicating that the ranging counter is disabled Identifies a ranging field that determines whether or not it is set to FALSE;
Whether the ranging bit of the physical layer header (PHR) is set to TRUE to indicate that the ranging bit of the PHR is set to 1, or FALSE to indicate whether the ranging bit of the PHR is not set to 1. Identifies a ranging physical header (RangingPhr) field that determines whether it is set to ;
and generate the MCPS-DATA.request primitive comprising the Ranging field and the RangingPhr field. The method of claim 1, wherein the processor is
To identify the transmission time specific (TxTimeSpecified) field that determines the use of the ranging transmission time (RangingTxTime) parameter, (i) when the TxTimeSpecified value is set to NONE (none), RangingTxTime is not used, (ii) the TxTimeSpecified value is When set in the ranging counter time unit (RCTU_TIME), RangingTxTime specifies the transmission time of the frame in units of RCTU, (iii) when the TxTimeSpecified value is set in the ranging scheduling time unit (RSTU_TIME), RangingTxTime is in units of RSTU specify the transmission time of the frame;
identify a RangingTxTime field set between 0x00000000 and 0xffffffff to specify the transmission time of the frame;
The network entity further configured to generate the MCPS-DATA.request primitive comprising the TxTimeSpecified field and the RangingTxTime field. 7. The method of claim 6,
the RangingTxTime parameter indicates an RMARKER transmission time when the TxTimeSpecified field is set to RCTU_TIME;
The RangingTxTime parameter indicates a transmission start time of a packet when the TxTimeSpecified field is set to RSTU_TIME;
The RangingTxTime parameter is a network entity that is not used when the TxTimeSpecified is set to NONE. According to claim 1,
The transceiver receives, from the MAC layer of the network entity, an AngleOfArrivalAzimuth field having a value between -π and +π, an AngleOfArrivalElevation field having a value between -π and +π, and NONE ( and receive a MCPS-DATA.confirm primitive comprising an AngleOfArrivalPresent field set to none), BOTH (both), AZIMUTH (azimuth), or ELEVATION (altitude);
The AngleOfArrival Azimuth field indicates that when the AngleOfArrivalPresent field is set to AZIMUTH or BOTH, the angle of arrival (AOA) is located in radians of the received signal on the azimuth for reception of an acknowledgment (ACK) frame;
the AngleOfArrivalElevation field indicates that when the AngleOfArrivalPresent field is set to the ELEVATION or the BOTH, the AOA is located in radians of a received signal on an elevation for reception of the ACK frame;
The AngleOfArrivalPresent field is a network entity indicating validity of the AngleOfArrivalAzimuth field and the AngleOfArrivalElevation field. 9. The method of claim 8,
the processor is further configured to receive, from a MAC layer of the network entity, a MCPS-DATA.confirm primitive comprising a Timestamp field having a value between 0x000000-0xffffff;
The timestamp field is set to RSTU_TIME corresponding to the start time of the packet including the preamble for the enhanced ranging device (ERDEV). According to claim 1,
the processor is further configured to receive, from a MAC layer of the network entity, an MCPS-DATA.indication primitive comprising a timestamp field having a value between 0x000000-0xffffff for ERDEV;
The timestamp field is a network entity set in RSTU_TIME corresponding to a transmission start time of a packet including a preamble. A method of a network entity in a wireless communication system supporting a ranging function, comprising:
Ranging Response Time Instantaneous Information Elements (RRTI IE) by the upper layer of the network entity identifying a ranging response time node list (RrtiNodeList) indicating a list of neighboring network entities for which the receiving ranging counter values are requested. ;
generating, by a higher layer of the network entity, a medium access control (MAC) common part sublayer (CPS) data request (MCPS-DATA.request) primitive including the RrtiNodeList;
transmitting the generated MCPS-DATA.request primitive to the MAC layer of the network entity; and
transmitting MAC data including ranging information, the RRTI, and ranging measurement information IEs (RMI IEs) to another network entity in the list of neighboring network entities,
and the MAC layer of the network entity is further configured to send a MCPS-DATA.confirm primitive to a higher layer of the network entity. 12. The method of claim 11,
The RrtiNodeList including a Request Ranging Response Time Device List (RequestRrtiDevList) and a Reception Time List (RecTimeList) indicates a MAC sublayer to form RRTI IEs for time reports;
the RequestRrtiDevList contains a list of ranging device addresses that are short addresses of 2 bytes in length or extended addresses of 8 bytes in length;
wherein the RecTimeList includes a list of timestamps, each timestamp containing a 32-bit length that will indicate a value between ^{0 and 2 32 -1.} 13. The method of claim 12,
determining address/ranging counter pairs from the RtriNodeList parameter;
When the RequestRtriTx parameter is set to a non-zero value and the MAC layer of the network entity can generate the RRTI IEs, based on the address/ranging counter pairs, by the MAC layer of the network entity, the inserting RRTI IEs into a frame; and
The method further comprising sending the frame containing the RRTI IEs to the other network entity in the list of neighboring network entities. 14. The method of claim 13, wherein the value of the RX-to-TX (RX to TX) response time field is calculated based on the difference between the RMARKER timestamp of the transmission frame and the corresponding reception ranging counter value from the RrtiNodeList. The method further comprising the step of, wherein the address of each RRTI list field corresponds to the address of the RrtiNodeList. 12. The method of claim 11,
For the ranging device (RDEV), whether the ranging counter is set to TRUE indicating that the ranging counter is enabled, indicating that the ranging counter is disabled identifying a ranging field that determines whether it is set to FALSE;
Whether the ranging bit of the physical layer header (PHR) is set to TRUE to indicate that the ranging bit of the PHR is set to 1, or FALSE to indicate whether the ranging bit of the PHR is not set to 1. identifying a ranging physical header (RangingPhr) field that determines whether it is set to ; and
The method further comprising generating the MCPS-DATA.request primitive including the ranging field and the RangingPhr field.

Images