Method and apparatus for providing service by using ultra-wideband communication

Abstract

The present disclosure discloses a method for providing a service by using UWB communication. A method for a UWB device may comprise the steps of: receiving a first UWB message to initiate a ranging process from an initiator anchor; receiving a plurality of second UWB messages transmitted in response to the first UWB message from the plurality of responder anchors; receiving, from the initiator anchor, a third UWB message transmitted in response to the second UWB message; and based on the first UWB message, the second UWB message and the third UWB message, performing DL-TDoA-based positioning.

Description

Technical Field

[0001] The present disclosure relates to UWB communication, and more particularly, to a method and apparatus for providing a service by using UWB communication. Background Art

[0002] The Internet is evolving from a human-centric connected network through which humans create and consume information to an Internet of Things (IoT) network in which distributed entities such as things exchange and process information. Internet of Everything (IoE) technology has emerged as a combination of IoT technology and big data processing technology through connection with cloud servers, etc. The realization of IoT requires technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology", and "security technology". Recently, technologies such as sensor networking, machine-to-machine (M2M) communication, machine type communication (MTC), etc. are being studied.

[0003] This IoT environment can provide intelligent Internet technology (IT) services that create new value for human life by collecting and analyzing data generated between connected things. Through the conversion or combination of existing information technology (IT) and various industrial applications, IoT can be applied to various fields such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances or advanced medical services.

[0004] As described above, with the development of wireless communication systems, various services can be provided, and thus methods for efficiently providing these services are required. For example, ranging technology that measures the distance between electronic devices by using ultra-wideband (UWB) can be utilized. Summary of the invention

[0005] Technical issues

[0006] The present disclosure provides a method for providing a service (eg, a payment service) by using UWB communication.

[0007] Technical Solution

[0008] A method for a UWB device according to an embodiment of the present disclosure may include: receiving a first UWB message for initiating a ranging process from an initiator anchor; receiving a plurality of second UWB messages sent in response to the first UWB message from a plurality of responder anchors; receiving a third UWB message sent in response to the second UWB message from the initiator anchor; and performing DL-TDoA based positioning based on the first UWB message, the second UWB message, and the third UWB message.

[0009] A UWB device according to an embodiment of the present disclosure may include: a transceiver; and a controller connected to the transceiver, wherein the controller is configured to: receive a first UWB message for initiating a ranging process from an initiator anchor; receive a plurality of second UWB messages sent in response to the first UWB message from a plurality of responder anchors; receive a third UWB message sent in response to the second UWB message from the initiator anchor; and perform DL-TDoA based positioning based on the first UWB message, the second UWB message, and the third UWB message.

[0010] Beneficial Effects

[0011] The present disclosure may efficiently provide services (eg, payment services) by using UWB communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 An example architecture of a UWB device according to an embodiment of the present disclosure is shown.

[0013] Figure 2A An example configuration of a communication system including an electronic device supporting a UWB-based service according to an embodiment of the present disclosure is shown.

[0014] Figure 2B An example configuration of a communication system including an electronic device supporting a UWB-based payment service according to an embodiment of the present disclosure is shown.

[0015] Figure 3 An example configuration of a framework included in an electronic device supporting a UWB-based service according to an embodiment of the present disclosure is illustrated.

[0016] Figure 4 The structure of a UWB MAC frame according to an embodiment of the present disclosure is shown.

[0017] Figure 5 The structure of a UWB PHY packet according to an embodiment of the present disclosure is shown.

[0018] Fig. 6A An example of a ranging block structure according to an embodiment of the present disclosure is shown.

[0019] Figure 6B An example of a ranging round according to an embodiment of the present disclosure is shown.

[0020] Figure 7 Various examples of UWB ranging methods according to embodiments of the present disclosure are shown.

[0021] Fig. 8A A method of performing UWB ranging in a DL-TDoA scheme by a UWB device according to an embodiment of the present disclosure is illustrated.

[0022] Figure 8B An example of a ranging block structure for a downlink TDoA scheme according to an embodiment of the present disclosure is shown.

[0023] Fig. 9 A payment processing method using UWB according to an embodiment of the present disclosure is shown.

[0024] Fig.10 A method of performing both DL-TDoA ranging and contention-based ranging by a UWB device according to an embodiment of the present disclosure is shown.

[0025] Fig.11 A method of performing both DL-TDoA ranging and contention-based ranging by a UWB device according to an embodiment of the present disclosure is shown.

[0026] Fig. 12A The structure of a UWB message according to an embodiment of the present disclosure is shown.

[0027] Fig. 12B The payload structure of a UWB message according to an embodiment of the present disclosure is shown.

[0028] Fig. 12C The payload structure of a UWB message according to an embodiment of the present disclosure is shown.

[0029] Fig.13A An example of an OWR message type-related payload field included in a UWB message according to an embodiment of the present disclosure is shown.

[0030] Fig. 13B An example of an OWR message type-related payload field included in a UWB message according to an embodiment of the present disclosure is shown.

[0031] Fig.14 A method for generating a secure channel according to an embodiment of the present disclosure is shown.

[0032] Fig.15 A UWB device including a security component according to an embodiment of the present disclosure is shown.

[0033] Fig.16 A UWB device including a security component according to an embodiment of the present disclosure is shown.

[0034] Fig.17 A method of transmitting data in a secure component of a UWB device to a UWBS according to an embodiment of the present disclosure is shown.

[0035] Fig.18 The APDU types supported in the SUS API according to an embodiment of the present disclosure are shown.

[0036] Fig.19A A data transmission process using UWB according to an embodiment of the present disclosure is shown.

[0037] Fig.19B is a diagram illustrating an embodiment of exchanging data while performing contention-based ranging between a first UWB device and a plurality of second UWB devices.

[0038] Fig.19C is a diagram illustrating an embodiment of exchanging data while performing contention-based ranging between a first UWB device and a plurality of second UWB devices.

[0039] Fig.19D is a diagram illustrating an embodiment of exchanging data while performing contention-based ranging between a first UWB device and a plurality of second UWB devices.

[0040] Fig. 20A A UWB message for data transmission according to an embodiment of the present disclosure is shown.

[0041] Fig. 20B An example of the content field of a UWB message used for data transmission according to an embodiment of the present disclosure is shown.

[0042] Fig. 20C An example of the content field of a UWB message used for data transmission according to an embodiment of the present disclosure is shown.

[0043] Fig.21 The structure of a first UWB device according to an embodiment of the present disclosure is shown.

[0044] Fig. 22 The structure of a second UWB device according to an embodiment of the present disclosure is shown.

[0045] Fig.23 An example of a data message payload IE according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0046] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0047] When describing the embodiments, descriptions of technical contents well-known in the related art and not directly related to the present disclosure are omitted. Such omission of unnecessary descriptions is to prevent blurring the main idea of ​​the present disclosure and to convey the main idea more clearly.

[0048] For the same reason, in the accompanying drawings, some elements may be exaggerated, omitted or schematically shown. In addition, the size of each element does not fully reflect the actual size. In all the accompanying drawings, the same or corresponding elements are assigned with the same reference numerals.

[0049] By referring to the embodiments described in detail below in conjunction with the accompanying drawings, the advantages and features of the present disclosure and the methods for realizing the advantages and features of the present disclosure will become apparent. However, the present disclosure is not limited to the embodiments set forth below, but can be implemented in various different forms. The following embodiments are only used to fully disclose the present disclosure and inform those skilled in the art of the scope of the present disclosure, and the present disclosure is limited only by the scope of the attached claims. Throughout the specification, the same or similar reference numerals indicate the same or similar elements.

[0050] It should be understood herein that each frame of the flow chart and the combination of multiple frames in the flow chart can be performed by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that the instructions run by the processor of the computer or other programmable data processing device create the means for realizing the function specified in one or more frames of the flow chart. These computer program instructions can also be stored in a computer-available or computer-readable memory, which can indicate that the computer or other programmable data processing device is operated in a specific manner so that the instructions stored in the computer-available or computer-readable memory produce the manufacture of the instruction means including the function specified in one or more frames of the flow chart. The instructions running on a computer or other programmable data processing device to cause a series of operation steps to be performed on a computer or other programmable data processing device to produce a computer-implemented process can provide the steps for realizing the function specified in one or more frames of the flow chart.

[0051] In addition, each box in the flow chart may represent a module, segment or part of a code including one or more executable instructions for implementing a specified logical function. In addition, it should also be noted that in some alternative implementations, the functions mentioned in the box may not occur in order. For example, two boxes shown in succession can actually be performed substantially simultaneously, or these boxes can sometimes be performed in reverse order, depending on the functions involved.

[0052] As used in the embodiments of the present disclosure, the term "unit" refers to a software element or a hardware element, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and the "unit" can perform certain specific functions. However, a "unit" does not always have a meaning limited to software or hardware. A "unit" can be constructed to be either stored in an addressable storage medium or to run one or more processors. Therefore, a "unit" includes, for example, software elements, object-oriented software elements, class elements and task elements, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcodes, circuits, data, databases, data architectures, tables, arrays, and parameters. The elements and functions provided by a "unit" can be combined into a smaller number of elements or "units", or can be divided into a larger number of elements or "units". In addition, elements and "units" can be implemented as one or more CPUs in a reproduction device or a secure multimedia card. In addition, a "unit" in various embodiments of the present disclosure can include one or more processors.

[0053] As used herein, the term "terminal" or "device" may also be referred to as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, user unit, subscriber station (SS), wireless device, wireless communication device, wireless transmit / receive unit (WTRU), mobile node, mobile phone or other terms. Various embodiments of the terminal may include a cellular phone, a smart phone with wireless communication function, a personal digital assistant (PDA) with wireless communication function, a wireless modem, a portable computer with wireless communication function, a photographing device such as a digital camera with wireless communication function, a gaming device with wireless communication function, a music storage and recording home appliance with wireless communication function, a networked home appliance enabling wireless Internet access and browsing, and a portable unit or terminal with an integrated combination of these capabilities. In addition, the terminal may include a machine-to-machine (M2M) terminal and a machine type communication (MTC) terminal / device, but is not limited thereto. In this specification, a terminal may be referred to as an electronic device or simply referred to as a device.

[0054] Hereinafter, the working principle of the present disclosure will be described in detail in conjunction with the accompanying drawings. In the following description of the present disclosure, when it is determined that the description will make the subject matter of the present disclosure unnecessarily unclear, the detailed description of the known functions or configurations incorporated herein will be omitted. The terms to be described below are defined in consideration of the functions in the present disclosure, and may be different depending on the user, the user's intention or habit. Therefore, these terms should be defined based on the content of the entire specification.

[0055] Hereinafter, embodiments of the present disclosure will be described in detail in conjunction with the accompanying drawings. In the following description of the embodiments of the present disclosure, a communication system using UWB will be described by way of example, but the embodiments of the present disclosure may be applied to other communication systems having similar technical backgrounds or features. Examples of these communication systems may include communication systems Bluetooth or ZigBee. Therefore, based on the determination of those skilled in the art, the embodiments of the present disclosure may be applied to other communication systems with some modifications without significantly departing from the scope of the present disclosure.

[0056] When describing the present disclosure below, when it is determined that the description will make the subject matter of the present disclosure unnecessarily unclear, the detailed description of the well-known functions or configurations incorporated herein will be omitted. The terms to be described below are defined in consideration of the functions in the present disclosure, and may differ depending on the user, the user's intention or custom. Therefore, these terms should be defined based on the content of the entire specification.

[0057] Generally, wireless sensor network technology is mainly divided into wireless local area network (WLAN) technology and wireless personal area network (WPAN) technology according to the recognition distance. In this case, wireless LAN is a technology based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11, and is a technology that can access the backbone network within a radius of about 100m. Wireless personal area network is a technology based on IEEE 802.15, and includes Bluetooth, ZigBee, and ultra-wideband (UWB), etc. A wireless network that implements these wireless network technologies may include multiple electronic devices.

[0058] According to the definition of the Federal Communications Commission (FCC), UWB can refer to a wireless communication system using a bandwidth of 500MHz or greater, or a wireless communication technology with a bandwidth corresponding to a center frequency of 20% or greater. UWB can refer to the frequency band itself used for UWB communication. UWB can achieve secure and accurate ranging between devices. Based on this, UWB can achieve relative position estimation based on the distance between two devices, or achieve accurate position estimation of a device based on the distance from a fixed device (whose position is known).

[0059] The terms used in the following description are provided to help understanding of the present disclosure, and the use of these specific terms may be changed in other forms without departing from the technical spirit of the present disclosure.

[0060] An "application specific file (ADF)" may be, for example, a data structure within an application data structure that may host application or application specific data.

[0061] An "application protocol data unit (APDU)" may be a command and response used when communicating with an application data structure in a UWB device.

[0062] The “application-specific data” may be, for example, a file structure having a root level and an application level, including UWB controller information and UWB session data required for a UWB session.

[0063] A "controller" may be a ranging device that defines and controls ranging control messages (RCMs) or control messages. A controller may define and control ranging characteristics by sending control messages.

[0064] A "controller" may be a ranging device that uses ranging parameters in an RCM (or control message) received from a controller. A controller may use the same ranging features as those configured by a control message from a controller.

[0065] Unlike "static STS", "dynamic scrambled timestamp sequence (STS) mode" may be an operation mode in which STS is not repeated during a ranging session. In this mode, STS may be managed by the ranging device, and the ranging session key used to generate STS may be managed by the security component.

[0066] An "applet" may be, for example, an applet running on a secure component that includes UWB parameters and service data. The applet may be a FiRa applet.

[0067] A “ranging device” may be a device capable of performing UWB ranging. In the present disclosure, the ranging device may be a FiRa device or an enhanced ranging device (ERDEV) defined in IEEE802.15.4z. The ranging device may be referred to as a UWB device.

[0068] A "UWB-enabled application" may be an application for UWB services. For example, a UWB-enabled application may be an application that uses a framework API to configure an out-of-band (OOB) connector, security services, and / or UWB services for a UWB session. A "UWB-enabled application" may be abbreviated as an application or a UWB application. A UWB-enabled application may be a FiRa-enabled application.

[0069] A "framework" may be a component that provides access to profiles, individual UWB configurations, and / or notifications. A framework may be, for example, a collection of logical software components including a profile manager, an OOB connector, security services, and / or UWB services. A framework may be a FiRa framework.

[0070] An "OOB connector" may be a software component for establishing an out-of-band (OOB) connection (eg, a BLE connection) between ranging devices. The OOB connector may be a FiRa OOB connector.

[0071] A "profile" may be a collection of previously defined UWB and OOB configuration parameters. A profile may be a FiRa profile.

[0072] A "profile manager" may be a software component that implements profiles available on a ranging device. The profile manager may be a FiRa profile manager.

[0073] A "service" may be an implementation of a use case that provides a service to an end user.

[0074] A "smart ranging device" may be a ranging device that implements an optional framework API. A smart ranging device may be a FiRa smart device.

[0075] A "Global Private File (GDF)" may be the root level of application specific data that includes data needed to establish a USB session.

[0076] A "framework API" may be an API used by UWB-enabled applications to communicate with the framework.

[0077] An "initiator" may be a ranging device that initiates a ranging exchange. An initiator may initiate a ranging exchange by sending a first RFRAME (Ranging Exchange Message).

[0078] An "object identifier (OID)" may be an identifier of an ADF in an application data structure.

[0079] "Out-of-band (OOB)" may be data communications that do not use UWB as the underlying radio technology.

[0080] A "Ranging Data Set (RDS)" may be data required to establish a UWB session that needs to protect confidentiality, authenticity, and integrity (eg, UWB session key, session ID, etc.).

[0081] A "responder" may be a ranging device that responds to an initiator in a ranging exchange. A responder may respond to a ranging exchange message received from an initiator.

[0082] "STS" may be an encryption sequence used to increase the integrity and accuracy of the ranging timestamp. STS may be generated from the ranging session key.

[0083] A "secure channel" may be a data channel that is protected from eavesdropping and tampering.

[0084] A “secure component” may be an entity with a defined security level (eg, a secure element (SE) or a trusted execution environment (TEE)) that interfaces with the UWBS to provide RDS to the UWBS, for example when using dynamic STS.

[0085] “SE” may be a tamper-resistant secure hardware component that may be used as a secure component in a ranging device.

[0086] "Secure ranging" may be ranging based on an STS generated through a strong cryptographic operation.

[0087] A “security service” may be a software component used to interface with a secure component (eg, a secure element or TEE).

[0088] A "service applet" may be an applet on a secure component that handles service specific transactions.

[0089] "Service data" may be data defined by a service provider that needs to be transmitted between two ranging devices in order to implement a service.

[0090] A "service provider" may be an entity that defines and provides the hardware and software necessary to deliver a specific service to an end user.

[0091] "Static STS mode" is an operation mode in which the STS is repeated during a session and does not need to be managed by a security component.

[0092] A "Secure UWB Service (SUS) applet" may be an applet on the SE that communicates with the applet to retrieve data needed to implement a secure UWB session with another ranging device. In addition, the SUS applet may transmit corresponding data (information) to the UWBS.

[0093] A "UWB Service" may be a software component that provides access to a UWB S.

[0094] A "UWB session" may be a period from the time when the controller and the controlled device start communicating through UWB until the time when the communication stops. A UWB session may include ranging, data transmission, or both ranging and data transmission.

[0095] The “UWB session ID” may be an ID (eg, a 32-bit integer) for identifying a UWB session shared between the controller and the controlled device.

[0096] The "UWB session key" may be a key for protecting a UWB session. The UWB session key may be used to generate an STS. The UWB session key may be a UWB ranging session key (URSK) and may be abbreviated as a session key.

[0097] A "UWB Subsystem (UWBS)" may be a hardware component that implements the UWB PHY and MAC layers (specifications). The UWBS may have an interface to the framework and an interface to the security component to search for RDS.

[0098] A "UWB message" may be a message including a payload Information Element (IE) sent by a UWB device (eg, ERDEV).

[0099] A "payload IE" may be an IE included in a MAC payload of a UWB MAC frame. A MAC payload may include one or more payload IEs.

[0100] "Scheduled-based ranging" can be used for ranging cycles in which the controller schedules the controlled device to send ranging frames (RFRAME) and / or measurement reports in different ranging time slots. Scheduling-based ranging can be called time-scheduled ranging. The scheduling mode using scheduling-based ranging can be called time-scheduled mode.

[0101] "Content-based ranging" can be used when the controller does not know the MAC address of the controlled device participating in the UWB session (ranging session). In contention-based ranging, the controller can be the initiator and can perform ranging with another unknown UWB device. The scheduling mode using contention-based ranging can be called contention-based mode.

[0102] Contention-based ranging may be used for ranging cycles in which a controller determines the size of a contention access period (CAP) and indicates the size of the CAP through a ranging control message. The CAP may be referred to as a contention window or contention window period.

[0103] In contention-based mode, the UWB device may operate as a controller and initiator, and in this case, the ranging control phase (RCP) and the ranging initiation phase (RIP) may be combined into one phase (e.g., RIP). In the ranging phase (RP), the CAP size allocation may determine the CAP period in units of ranging slots for responders participating in the corresponding ranging cycle. Each responder may randomly determine a slot in the CAP to send a ranging response message (RRM). The messages used in contention-based ranging may use SP1 as the RFRAME configuration.

[0104] "Hybrid ranging" can be used when there are known controllers and unknown controllers. As described above, a known controller may be a controller whose MAC address is known to the controller, and an unknown controller may be a controller whose MAC address is unknown to the controller. Hybrid ranging may be referred to as hybrid-based ranging. A scheduling mode using hybrid ranging may be referred to as a hybrid-based mode.

[0105] In the hybrid-based mode, the controller may perform ranging with known slaves in the scheduling-based mode and perform ranging with unknown slaves in the contention-based mode.

[0106] In the hybrid-based mode, the ranging cycle may include a ranging control phase (RCP) and a ranging phase (RP). The RP may include a contention-free period for scheduling-based ranging (access) and a contention access period (CAP) for contention-based ranging (access). The control message (ranging control message) used in the RCP of the hybrid-based mode may be referred to as a ranging management message (RMM).

[0107] "Downlink Time Difference of Arrival (DL-TDoA, DT)" can be a positioning method for one or more tag devices (DT-Tag) to estimate their positions based on DL-TDoA messages (DTMs) received from at least one anchor device (DT-Anchor). In DL-TDoA, the anchor device can send or broadcast the DTM, and the tag device can passively receive the DTM, thereby preventing the location of the tag device from being exposed.

[0108] In DL-TDoA, the anchor device can accurately measure its own DTM transmission time and the reception time of the received DTM. The anchor device can include the transmission time in the transmitted or broadcasted DTM. The tag device can measure the reception time of all received DTMs and estimate the location of the tag device itself by using the reception timestamp and the coordinates of the acquired anchor device. DL-TDoA can be classified as a one-way ranging type like uplink TDoA. DL-TDoA can be called DL-TDoA positioning.

[0109] An "anchor device" may be a UWB device deployed at a specific location to provide positioning services. For example, an anchor device may be a UWB device installed by a service provider on a wall, ceiling, structure, etc. in a room to provide indoor positioning services. In DL-TDoA, an anchor device may be a device that sends a DTM, which a tag device may use to calculate a location based on TDoA positioning (DL-TDoA positioning). In DL-TDoA, anchor devices may be divided into initiator anchors and responder anchors according to the role and order in which messages are sent in order to participate in the ranging cycle. An anchor device may be referred to as a UWB anchor or a UWB anchor device, and an anchor device of a DL-TDoA may be referred to as a DL-TDoA anchor or a DT-anchor.

[0110] The "initiator anchor" may notify the start of a TDoA ranging cycle (DL-TDoA ranging cycle). In DL-TDoA, the initiator anchor may start the DL-TDoA ranging cycle by sending a start message, and may schedule the transmission time of (one or more) responder anchors. For example, the initiator anchor may schedule the ranging slots for (one or more) responder anchors running in the same ranging cycle to send response messages (response DTMs). The start message may be referred to as an initiator DTM, a polling message, a polling DTM, or a first DTM. The initiator anchor may be referred to as an initiator UWB anchor, an initiator anchor device, or an initiator DT-anchor.

[0111] The initiator anchor may additionally transmit an end message (final DTM) after receiving a response from (one or more) responder anchors. The initiator anchor may also send a final DTM after all responder anchors in the same cluster send response messages (response DTMs) in a DL-TDoA ranging cycle. The final message may be referred to as a final DTM or a third DTM.

[0112] There may be at least one reference initiator anchor in a DL-TDoA network. A reference initiator anchor is an initiator anchor used as a global time reference for inter-cluster synchronization and may configure a common ranging block structure for DL-TDoA network operation. A reference initiator anchor may be referred to as a primary anchor or a global anchor.

[0113] A "responder anchor" may be a UWB anchor that responds to an initiator anchor's initiation message. A responder anchor may respond to an initiator anchor using a response message. A response message may be referred to as a responder DTM, a response DTM, or a second DTM. A responder anchor may also be referred to as a responder UWB anchor, a responder UWB anchor device, a responder anchor device, etc.

[0114] A "tag device" may estimate its location (e.g., geographic coordinates) based on the DTM received from an anchor device in DL-TDoA by using TDoA measurements. The tag device may pre-identify the location of the anchor device. The tag device may be referred to as a UWB tag, UE, or UWB tag device, and a DL-TDoA tag device may be referred to as a DL-TDoA tag or a DT-tag.

[0115] The tag device can receive the message sent by the anchor device and measure the reception time of the message. The tag device can obtain the geographical coordinates of the anchor device through in-band or out-of-band methods. When the location update rate is lower than the location update rate supported by the network, the tag device can skip the ranging block.

[0116] A "cluster" may refer to a collection of anchor devices covering a specific area. In DL-TDoA, a cluster may refer to a collection of anchor devices that exchange DTMs to provide location services to at least one tag device. A cluster may include an initiator anchor and at least one responder anchor.

[0117] An anchor device may operate in one or more clusters. In this case, an anchor device that acts as an initiator anchor in some clusters may act as a responder anchor in other clusters. A cluster area may be a space configured by anchor devices that constitute a cluster. In order to support wide-area positioning services, multiple clusters may be configured to provide positioning services to UEs. A cluster may be referred to as a cell.

[0118] A "data message payload information element (DM payload IE)" may be a payload IE for transmitting data generated from an application, applet, or other data source by including the data in a UWB message. In the present disclosure, the data message payload IE may also be referred to as a data message. Fig.23 As shown, the data message payload IE may be combined with the ranging payload IE to become part of the PHY payload of the UWB message.

[0119] The data message payload IE may include a vendor OUI, a UWB message identifier (UWB message ID), a data message type (DM type), and a content field, or may include a portion thereof. The data message payload IE may be configured as shown in Table 1.

[0120] [Table 1] Data Message Payload IE (DM Payload IE) format

[0121] Depending on the data message type, the content of the message included in the content field may vary. If the value of the data message type (DM type) field is 0×0, the content field may include general application data. The content field may additionally include the length of the transmitted application data. The content field may also include a MAC data service data unit (MDSDU) as a payload, which is data generated in a layer higher than the MAC layer of the UWB subsystem and sent to the MAC. If the data message type (DM type) is 0×0, the content field may be configured as shown in Table 2.

[0122] [Table 2] Content field format for DM type payload

[0123] If the value of the Data Message Type (DM Type) field of the Data Message Payload IE is 0x1, the Content field may include a Data Transfer Phase Control Message (DTPCM). The DTPCM Content field may be configured as shown in Table 3 below, and the DTPML format may be configured as shown in Table 4 below.

[0124] [Table 3] Data transmission phase control message content fields

[0125] [Table 4] Data Transfer Phase Management List (DTPML) format

[0126] Furthermore, in describing the present disclosure, when it is determined that a detailed description of a related well-known function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted.

[0127] Hereinafter, various embodiments of the present disclosure are described with reference to the accompanying drawings.

[0128] Figure 1 An example architecture of a UWB device according to an embodiment of the present disclosure is shown.

[0129] The UWB device 100 may be an electronic device supporting UWB communication. The UWB device 100 may be, for example, a ranging device supporting UWB ranging. In an embodiment, the ranging device may be a FiRa device or an enhanced ranging device (ERDEV) defined in IEEE 802.15.4z.

[0130] exist Figure 1 In the embodiment of the present invention, the UWB device 100 may interact with another UWB device through a UWB session.

[0131] In addition, the UWB device 100 may implement a first interface (Interface #1), which is an interface between the UWB-enabled application 110 and the framework 120, and the first interface allows the UWB-enabled application 110 on the UWB device 100 to use the UWB capability of the UWB device 100 in a predetermined scheme. In an embodiment, the first interface may be a framework API or a proprietary interface, but is not limited thereto.

[0132] Furthermore, the UWB device 100 may implement a second interface (Interface #2) as an interface between the UWB framework 110 and the UWB subsystem (UWBS) 130. In an embodiment, the second interface may be a UWB command interface (UCI) or a proprietary interface, but is not limited thereto.

[0133] refer to Figure 1, the UWB device 100 may include a UWB-enabled application 110, a framework (UWB framework) 120, and / or a UWBS 130 including a UWB MAC layer and a UWB physical layer. Depending on the embodiment, the UWB device may not include some entities, or may further include additional entities (eg, a security layer).

[0134] The UWB-enabled application 110 may trigger the establishment of a UWB session by the UWBS 130 via the first interface. The UWB-enabled application 110 may use one of the previously defined profiles. The UWB-enabled application 110 may use the first interface to handle related events, such as service discovery, ranging notifications, and / or error conditions.

[0135] The framework 120 may provide access to configuration files, individual UWB configurations, and / or notifications. The framework 120 may support at least one of functions such as functions for performing UWB ranging and transactions, functions for providing interfaces to applications and the UWBS 130, or position estimation functions of the device 100. The framework 120 may be a collection of software components. As described above, the UWB-enabled application 110 may interface with the framework 120 through a first interface, and the framework 120 may interface with the UWBS 130 through a second interface.

[0136] In the present disclosure, the UWB-enabled application 110 and / or the framework 120 may be implemented by an application processor (AP) (or a processor). Therefore, in the present disclosure, it is understood that the operation of the UWB-enabled application 110 and / or the framework 120 is performed by the AP (or a processor). In the present disclosure, the framework may be referred to as an AP or a processor.

[0137] The UWBS 130 may be a hardware component including a UWB MAC layer and a UWB physical layer. The UWBS 130 may perform UWB session management and communicate with the UWBS of another UWB device. The UWBS 130 may interface with the framework 120 through a second interface and may obtain security data from a security component. In an embodiment, the framework (or application processor) 120 may send a command to the UWBS 130 through the UCI, and the UWBS 130 may send a response to the command to the framework 120. The UWBS 130 may transmit a notification to the framework 120 through the UCI.

[0138] Figure 2A An example configuration of a communication system including an electronic device supporting a UWB-based service according to an embodiment of the present disclosure is shown.

[0139] refer to Figure 2A , the communication system 200 includes a first electronic device 210a and a second electronic device 220a.

[0140] As an example, the first electronic device 210a and the second electronic device 220a may be, for example, Figure 1 UWB devices or including Figure 1 For example, the first electronic device 210a may be, for example, a smart ranging device or a ranging device, and the second electronic device 220a may be, for example, a ranging device or a ranging device. As an embodiment, the smart ranging device or the ranging device may be a FiRa device or an enhanced ranging device (ERDEV) defined in IEEE 802.15.4z. Figure 2A In the present invention, the first electronic device may be referred to as a first UWB device, and the second electronic device may be referred to as a second UWB device.

[0141] The first electronic device 210a may, for example, host one or more UWB-enabled applications installed by a user (e.g., a mobile phone). This may be based on a framework API. The second electronic device 220a may not provide a framework API, and use, for example, a dedicated interface to implement a specific UWB-enabled application that is only provided by the manufacturer. Different from what is shown, according to an embodiment, both the first UWB device and the second UWB device may be ranging devices that use a framework API, or both the first UWB device and the second UWB device may be ranging devices that use a proprietary interface.

[0142] The first electronic device 210a and the second electronic device 220a may include a UWB-enabled application layer (UWB-enabled application) 211a and 221a, a framework 212a and 222a, an OOB component (OOB subsystem) 213a and 223a, a security component 214a and 224a, and / or a UWBS 215a and 225a, respectively. Depending on the embodiment, some components may be omitted or additional components may be included.

[0143] The first electronic device 210 a and the second electronic device 220 a may communicate with each other by generating an OOB connection (channel) through the OOB components 213 a and 223 a and generating a UWB connection (channel) through the UWBS 215 a and 225 a .

[0144] Frameworks 212a and 222a may be used to provide access to profiles, individual UWB configurations, and / or notifications. Frameworks 212a and 222a are collections of software components, and each collection may include, for example, a profile manager, an OOB connector, security services, and / or UWB services.

[0145] The OOB components 213a and 223a may be hardware components including a MAC layer and / or a physical layer for OOB communication (e.g., BLE communication). The OOB components 213a and 223a may communicate with an OOB component of another device. In an embodiment, the first UWB device 210a and the second UWB device 220a may generate an OOB connection (channel) by using the OOB components 213a and 223a, and may exchange parameters for establishing a UWB session through the OOB channel. In the present disclosure, the OOB components 213a and 223a may be referred to as an OOB subsystem.

[0146] The security components 214a and 224a may be hardware components that interface with the framework and / or UWBS to provide RDS. In an embodiment, the security components 214a and 224a may be SE (e.g., ESES), TEE (or a trusted application (TA) within a TEE), or a strong box (SB).

[0147] The UWBS 215a and 225a may be hardware components including a UWB MAC layer and a UWB physical layer. The UWBS 215a and 225a may perform UWB session management and communicate with the UWBS of another UWB device. In an embodiment, the first UWB device 210a and the second UWB device 220a may perform UWB ranging and service data transactions via a UWB session established through the UWBS 215a and 225a by using parameters exchanged with each other.

[0148] In the present disclosure, the UWB-enabled application layer and / or framework may be implemented by an application processor (AP) (or processor). Therefore, in the present disclosure, it is understood that the operation of the UWB-enabled application and / or framework is performed by the AP (or processor).

[0149] Figure 2B An example configuration of a communication system including an electronic device supporting a UWB-based service according to an embodiment of the present disclosure is shown.

[0150] Figure 2B An example may be Figure 2A Examples of embodiments of the present invention.

[0151] exist Figure 2B In the embodiment of the present invention, the UWB-based service may be a UWB-based payment service (wallet service). In the present disclosure, the embodiments of the present disclosure are described assuming that the UWB-based service is a UWB-based payment service, but the embodiments of the present disclosure may also be applied to other types of UWB-based services.

[0152] refer to Figure 2B, a communication system 200b providing a UWB-based payment service may include a first electronic device 210b and a second electronic device 220b. Figure 2B In the present invention, the first electronic device may be referred to as a first UWB device, and the second electronic device may be referred to as a second UWB device.

[0153] <First Electronic Device 210b>

[0154] The first electronic device 210b may be an electronic device of a user for a UWB-based payment service (e.g., a user's mobile device). The first electronic device 210b may include at least one UWB-enabled wallet application (UWB-enabled application) 211b-1 and 211b-2, a UWB-enabled wallet framework 212b, an OOB component 213b, at least one security component 214b-1 and 214b-2, and / or a UWBS 215b. For a description of each component, reference may be made to Figure 2A Description.

[0155] exist Figure 2B In the embodiment of the invention, for ease of description, it is described that the UWB-enabled application corresponds to the UWB-enabled wallet application, and the framework corresponds to the UWB-enabled wallet framework, but the embodiment is not limited thereto, and various UWB-enabled applications and frameworks may be implemented to provide various types of UWB-based services. Figure 2B In the present invention, a UWB-enabled wallet application may be referred to as a UWB-enabled application, a UWB-enabled payment application, etc., and a UWB-enabled wallet framework may be referred to as a UWB-enabled payment framework, framework, etc.

[0156] (1) The UWB-enabled applications 211 b - 1 and 211 b - 2 may support at least one of the following features.

[0157] - Hosting an applet for UWB-based payment (payment applet) within a SE (e.g., embedded SE (eSE)) or a trusted application for UWB-based payment (trusted payment application) within a TEE

[0158] -When requested by the framework, provide UWB block structure (e.g., ranging block structure) and / or anchor deployment information for estimating the position of the first electronic device

[0159] -Communicate with the second electronic device and the backend server to personalize the payment applet or trusted payment application (TPA)

[0160] (2) The framework 212b may support at least one of the following features.

[0161] - estimating the location of the first electronic device

[0162] - Implementation of UCI orders

[0163] - Provides a collection of APIs for UWB-enabled applications to access UWBS and OOB components

[0164] (3) The OOB component 213b may support the following features.

[0165] - Implement OOB connection operations (e.g., BLE connection operations)

[0166] (4) The trusted payment application 211 b - 2 may be included in the TEE and may support at least one of the following features.

[0167] - Support TEE client API

[0168] - Implement trusted applications

[0169] - Implement a secure channel protocol to communicate with a second electronic device in a secure manner

[0170] -Escrow of payment credentials and encryption keys for secure channels

[0171] - Hosts important information (e.g., card information) to support UWB-based payment services

[0172] (5) The payment application 211 b - 1 may be included in the SE (eSE) and may support at least one of the following features.

[0173] -Support APDU

[0174] - Implement a secure channel protocol to communicate with a second electronic device in a secure manner

[0175] -Escrow of payment credentials and encryption keys for secure channels

[0176] - Hosts important information (e.g., card information) to support UWB-based payment services

[0177] Each component of the first electronic device 210b may communicate with another component through a predefined interface (IF). Hereinafter, each interface is described.

[0178] IF#1: An interface between the UWBS 215b of the first electronic device 210b and the UWBS of another electronic device (eg, the UWBS 223b of the second electronic device 220b). IF#1 may be used to exchange UWB messages and / or payment transactions.

[0179] IF#2: An interface between the OOB component 213b of the first electronic device 210b and an OOB component of another electronic device (eg, the OOB component 222b of the second electronic device 220b). IF#2 may be used to exchange OOB messages.

[0180] IF#3: Interface between framework 212b and UWBS 215b. IF#3 can be used to exchange UCI messages. For example, IF#3 can be used to exchange UCI messages (e.g., UCI commands / UCI notifications, etc.) to establish a secure channel between trusted payment application 211b-2 and UWBS 215b.

[0181] IF#4: Interface between the UWB-enabled application 211b-2 and the trusted payment application 211b-2 within the TEE. IF#4 can be used to exchange TEE commands through the TEE client API. For example, IF#4 can be used to exchange TEE commands to establish a secure channel between the trusted payment application 211b-2 and the UWBS 215b.

[0182] IF#A: Interface between UWBS 215b and UWB-enabled applications 211b-1 and 211b-2. IF#A may be, for example, a SUS external API.

[0183] IF#B: Interface between UWB-enabled application 211b-2 and payment applet 214b-1 within SE (eSE). IF#B can be used to exchange APDUs through Object Management Application Programming Interface (OMAPI). For example, IF#B can be used to exchange APDUs for establishing a secure channel between eSE and UWBS.

[0184] IF#C: Interface between the OOB component 213b and the framework 212b or the UWB-enabled applications 211b-1 and 211b-2. For example, IF#C may be a host controller interface (HCI).

[0185] IF#D: Interface between the framework 212b and the UWB-enabled application 211b-1 or 211b-2. IF#D may be an API (framework API) provided by the framework 212b.

[0186] Despite Figure 2B 214b-2, but in order to transmit the RDS including the UWB session key, an interface between the TA (e.g., a trusted payment application) in the TEE 214b-2 and the UWBS 215b may be established or defined. In this case, a secure channel may be established between the TA and the UWBS 215b to protect the interface between the TEE and the UWBS 215b. In addition, the TA and the UWBS 215b may also be connected at the HW level through the newly configured driver TA.

[0187] <Second Electronic Device 220b>

[0188] The second electronic device 220b may be an electronic device of a commercial operator for a UWB-based payment service (e.g., a payment terminal (e.g., a retailer's point of service (PoS) UE)). The second electronic device 220b may include a terminal application 221b, an OOB component 222b, and / or a UWBS 223b. As an embodiment, the terminal application 221b may be a UWB-enabled application.

[0189] According to an embodiment, not only a UE for a UWB-based payment service but also a payment terminal may have the same configuration as that of the first electronic device 220b.

[0190] Figure 3 An example configuration of a framework included in an electronic device supporting a UWB-based service according to an embodiment of the present disclosure is illustrated.

[0191] Figure 3 The frame 300 may be Figure 2A and Figure 2B An example of a framework. Figure 3 The framework 300 may be, for example, a FiRa framework.

[0192] The framework 300 may be a collection of logical software components. UWB-enabled applications may interface with the framework through a framework API provided by the framework 300 .

[0193] refer to Figure 3 , the framework 300 may include a profile manager 310, an OOB connector 320, a security service 330, and / or a UWB service 340. However, according to an embodiment, some components may be omitted, or additional components may be included.

[0194] The profile manager component 310 can manage the profiles available on the ranging device (UWB device). The profile can be a collection of parameters required to establish a successful UWB session between the ranging devices (UWB devices). For example, the profile can include parameters indicating the secure channel used (e.g., OOB secure channel), UWB / OOB configuration parameters, parameters indicating whether the use of a specific security component is mandatory, and / or parameters related to the file structure of the ADF. In addition, the profile manager can extract UWB and OOB configuration parameters from UWB-enabled applications.

[0195] The OOB connector component 320 may be a component for establishing an OOB connection between ranging devices (UWB devices).

[0196] The secure service component 330 may be used to perform an interface with a secure component such as a secure element (SE) or a trusted execution environment (TEE). The secure component may be a component that interfaces with the UWBS to transmit UWB ranging data to the UWBS.

[0197] The UWB service component 340 may be a component that provides access to the UWBS.

[0198] Figure 4 The structure of a UWB MAC frame according to an embodiment of the present disclosure is shown.

[0199] exist Figure 4 In an embodiment, the UWB MAC frame may be abbreviated as a MAC frame or a frame. As an embodiment, the UWB MAC frame may be used to transmit UWB related data (eg, UWB messages, ranging messages, control information, service data, application data, etc.).

[0200] refer to Figure 4 , a UWB MAC frame may include a MAC header (MHR), a MAC payload and / or a MAC frame tail (MFR).

[0201] (1) MAC header

[0202] The MAC header may include a frame control field, a sequence number field, a destination address field, a source address field, an auxiliary security header field, and / or at least one header IE field. According to an embodiment, some of the above fields may not be included in the MAC header, and additional fields may be further included in the MAC header.

[0203] In an embodiment, the frame control field may include a frame type field, a security enable field, a frame suspension field, an ACK request field (AR field), a PAN ID compression field (PAN ID presence field), a sequence number suppression field, an IE presence field, a destination addressing mode field, a frame version field, and / or a source addressing mode field. According to an embodiment, some of the above fields may not be included in the frame control field, and additional fields may be further included in the frame control field.

[0204] The various fields are described below.

[0205] The frame type field may indicate a frame type. As an embodiment, the frame type may include a data type and / or a multi-purpose type.

[0206] The Security Enabled field may indicate whether there is an Auxiliary Security Header field. The Auxiliary Security Header field may include information required for security processing.

[0207] The frame pending field can indicate whether the device sending the frame has more data for the recipient. In other words, the frame pending field can indicate whether there is a pending frame for the recipient.

[0208] The ACK request field (AR field) may indicate whether an acknowledgement of frame reception is required from the receiving side.

[0209] The PAN ID Compression field (PAN ID Exists field) may indicate whether a PAN ID field exists.

[0210] The Sequence Number Suppression field may indicate whether a Sequence Number field is present. The Sequence Number field may indicate a sequence identifier for the frame.

[0211] The IE presence field may indicate whether a header IE field and a payload IE field are included in a frame.

[0212] The destination addressing mode field may indicate whether the destination address field includes a short address (eg, 16 bits) or an extended address (eg, 64 bits).The destination address field may indicate the address of the receiver of the frame.

[0213] The frame version field may indicate a frame version. For example, the frame version field may be configured to indicate a value of IEEE std802.15.4z-2020.

[0214] The source addressing mode field may indicate whether a source address field is present, and if so, whether the source address field includes a short address (eg, 16 bits) or an extended address (eg, 64 bits). The source address field may indicate the address of the originator of the frame.

[0215] (2) MAC payload

[0216] The MAC payload may include at least one payload IE field. In an embodiment, the payload IE field may include a vendor specific nested IE.

[0217] (3) MAC frame tail

[0218] The MAC frame tail may include an FCS field. The FCS field may include a 16-bit CRC or a 32-bit CRC.

[0219] Figure 5 The structure of a UWB PHY packet according to an embodiment of the present disclosure is shown.

[0220] Figure 5 Part (a) shows an example structure of a UWB PHY packet to which the STS packet configuration is not applied, while Figure 4Part (b) of illustrative examples shows an example structure of a UWB PHY packet to which the STS packet configuration is applied. The UWB PHY packet may be referred to as a PHY packet, a PHY PDU (PPDU), or a frame.

[0221] refer to Figure 5 In part (a), the PPDU may include a synchronization header (SHR), a PHY header (PHR), and a PHY payload (PSDU). The PSDU may include a MAC frame, and Figure 4 As shown, the MAC frame may include a MAC header (MHR), a MAC payload, and / or an MFR. The synchronization header portion may be referred to as a preamble, and the portion including the PHY header and the PHY payload may be referred to as a data portion.

[0222] The synchronization header may be used for synchronization of signal reception, and may include a SYNC field and a start frame delimiter (SFD).

[0223] The SYNC field may be a field including a plurality of preamble symbols used for synchronization between transmitting / receiving devices. The preamble symbol may be configured by one of predefined preambles.

[0224] The SFD field may be a field indicating the end of the SHR and the start of the data field.

[0225] The PHY header may provide information about the configuration of the PHY payload. For example, the PHY header may include information about the length of the PSDU, information indicating whether the current frame is an RFRAME (or a data frame), and the like.

[0226] The PHY layer of a UWB device may include an optional mode to provide reduced air time for high density / low power operation. In this case, the UWB PHY packet may include an encryption sequence (i.e., STS) to increase the integrity and accuracy of the ranging measurement timestamp. The STS may be included in the STS field of the UWB PHY packet and may be used for secure ranging.

[0227] refer to Figure 5Part (b), for STS packet (SP) configuration 0 (SP0), the STS field is not included in the PPDU (SP0 packet). For SP configuration 1 (SP1), the STS field is immediately after the frame start delimiter (SFD) field and before the PHR field (SP1 packet). For SP configuration 2 (SP2), the STS field is located after the PHY payload (SP2 packet). For SP configuration 3 (SP3), the STS field is immediately after the SFD field, and the PPDU does not include the PHR and data fields (PHY payload) (SP3 packet). In other words, for SP3, the PPDU does not include the PHR and PHY payload.

[0228] like Figure 5 As shown in part (b), each UWB PHY packet may include a RMARKER for defining a reference time, and the RMARKER may be used to obtain a transmission time, a reception time and / or a time period of a ranging message (frame) during a UWB ranging process.

[0229] Fig. 6A An example of a ranging block structure according to an embodiment of the present disclosure is shown. Figure 6B An example of a ranging cycle according to an embodiment of the present disclosure is shown.

[0230] refer to Fig. 6A , a ranging block may include at least one ranging cycle, and each ranging cycle may include at least one ranging slot. For example, as shown in the figure, a ranging block may include N ranging cycles (e.g., ranging cycle index 0 to ranging cycle index N-1), and ranging cycle #0 may include M ranging slots (e.g., ranging slot 0 to ranging slot M).

[0231] A ranging block refers to a time period used for ranging. A ranging cycle may be a duration sufficient to complete a complete ranging measurement cycle (ranging cycle) involving a set of UWB devices participating in a ranging exchange. A ranging slot may be a time period sufficient to send at least one ranging frame (RFRAME) (e.g., ranging start / response / final message, etc.).

[0232] When the ranging mode is a block-based mode, the average time between consecutive ranging cycles can be constant. Alternatively, when the ranging mode is an interval-based mode, the time between consecutive ranging cycles can be dynamically changed. That is, the interval-based mode can adopt a time structure with adaptive gaps.

[0233] A ranging block may be abbreviated as a block, a ranging cycle may be abbreviated as a cycle, and a ranging slot may be abbreviated as a slot.

[0234] refer to Figure 6B, a ranging cycle may include a ranging control phase (RCP), a ranging phase (RP) and / or a measurement report phase (MRP). For example, a ranging cycle may include a time slot for RCP, at least one time slot for RP and / or at least one time slot for MRP.

[0235] According to an embodiment, some of the above phases may not be included in the ranging cycle, or additional phases may be further included in the ranging cycle. For example, the RCP may not be included in the ranging cycle. In this case, the ranging control message (RCM) may be combined with the ranging initiation message (RIM). For example, the ranging control update phase (RCUP) and / or the ranging interval update phase (RIUP) may be further included in the ranging cycle.

[0236] RCP may be a stage in which the controller sends RCM. RCM may be a message sent by the controller to configure ranging parameters. In an embodiment, RCM may be sent in the first time slot (time slot #0) of the ranging cycle. RCM may be abbreviated as control message (CM).

[0237] The RP may include a ranging initiation phase (RIP), a ranging response phase (RRP), and / or a ranging final phase (RFP).

[0238] RIP may be the stage where the initiator(s) sends a RIM to the responder(s).

[0239] RRP may be the phase in which the responder(s) sends their ranging response message (RRM) to the initiator.

[0240] RFP may be the phase where the initiator sends a ranging final message (RFM) to the responder(s). The ranging final phase may only be used for DS-TWR.

[0241] MRP may be a stage in which the devices involved in ranging exchange service information related to ranging measurements. In MRP, a measurement report message (MRM), a ranging result report message (RRRM), and / or a control update message (CUM) may be sent. MRM may be a message sent by a UWB device for exchanging measurement information. RRRM may be a message sent by a UWB device for reporting ranging results. CUM may be a message sent by a controller for updating control information. CUM may be referred to as a ranging control update message (RCUM).

[0242] RCUP may be a phase in which the controller sends a ranging control update message (RCUM). The ranging control update phase may be included in the last time slot of a set of ranging cycles specified by an RCM. RCUM may be a message sent by the controller to update ranging parameters for the next ranging cycle. RCUM may be sent in the last time slot of a ranging cycle specified by an RCM. RCUM may include some or all information elements (IEs) used by the RCM to update parameter values.

[0243] The ranging interval update phase (RIUP) may be a phase in which the controller sends a ranging interval update message (RIUM). The RIUM may be a message sent by the controller to help synchronization between devices participating in ranging or to update the interval between ranging blocks. The RIUM includes a predetermined time for the first RIUM. Before the start of a subsequent ranging block, the RIUM may include a predetermined time for a subsequent RIUM.

[0244] If necessary, the above multiple UWB messages can be combined into one message. For example, RCM can be combined with RIM and sent in RIP. For example, for non-delayed DS-TWR ranging, RFM can be combined with MRM and sent in RFP.

[0245] Figure 7 Various examples of UWB ranging methods according to embodiments of the present disclosure are shown.

[0246] Figure 7 Part (a) shows an example of a two-way ranging (TWR) scheme, Figure 7 Part (b) shows an example of an uplink TDoA (UL-TDoA) scheme as an OWR type, and Figure 7 Part (c) of FIG. 4 shows an example of a downlink TDoA (DL-TDoA) scheme as an OWR type.

[0247] refer to Figure 7 In part (a), the user's UWB device 720a may perform ranging with at least one UWB anchor 710a through ranging exchange using a plurality of ranging messages. Through ranging exchange (ranging message exchange), time of flight (ToF) may be calculated and the distance between the two devices may be estimated.

[0248] The UWB device 720a may perform single-sided two-way ranging (SS-TWR) or dual-sided two-way ranging (DS-TWR) using the UWB anchor 710a. When performing TWR, the UWB device 720a may function as an initiator or a responder.

[0249] In an embodiment, TWR may be performed according to a contention-based mode and / or a scheduling-based mode.

[0250] refer to Figure 7 In part (b), the user's UWB device (UWB tag) 720a may send (broadcast) a ranging message to at least one UWB anchor 710b, and the at least one UWB anchor 710b may acquire a TDoA based on the received ranging message and estimate the position of the UWB device 720b based on the TDoA. Figure 7 The TDoA scheme of the embodiment of part (b) may be referred to as an uplink TDoA (UL-TDoA) scheme.

[0251] refer to Figure 7 In part (c), the user's UWB device (UWB tag or DT-tag) 720c can estimate its own position by receiving ranging messages sent / received by one or more UWB anchors 710c to each other. Fig. 8A and Figure 8B To describe an example of a DL-TDoA scheme.

[0252] Fig. 8A A method of performing UWB ranging in a DL-TDoA scheme by a UWB device according to an embodiment of the present disclosure is illustrated.

[0253] exist Fig. 8A In the embodiment of , it is assumed that one initiator anchor (initiator DT-anchor) 810 and n responder anchors 830a, ... 830n operate as UWB anchors (DT-anchors). However, the embodiment is not limited thereto, and the number of initiator anchors and responder anchors may be configured to vary according to the embodiment.

[0254] In operation S802, the initiator anchor 810 may initiate a DL-TDoA cycle by sending or broadcasting a polling DTM that is received by responder anchors in the cluster. The polling DTM may include scheduling information for each responder anchor to send a response DTM in an allocated ranging slot.

[0255] In an embodiment, all responder anchors 830a, ... 830n may refer to the scheduling information in the polling DTM to thereby identify whether to send a response DTM and identify a time slot (time slot index) for sending the response DTM.

[0256] In operations S804a, ... S804n, all responder anchors 830a, ... 830n that have received the polling DTM may respond to the initiator anchor 810 by using the response DTM in the ranging slot allocated by the polling DTM. For example, each responder anchor 830a, ... 830n may send or broadcast the response DTM in its own ranging slot allocated by the polling DTM.

[0257] In operation S806, the initiator anchor 810 having received the response DTM may additionally transmit the final DTM to the responder anchors 830a, ... 830n. For example, the initiator anchor 810 may transmit or broadcast the final DTM after receiving the response DTM from the responder anchors 830a, ... 830n.

[0258] In operation S808, the tag device (DT-Tag) 820 may receive (or listen to) the polling DTM, the response DTM, and the final DTM, and calculate the TDoA value through the information included in the message and the reception timestamp. The tag device 820 may obtain (or estimate) its own position based on the calculated TDoA value. Therefore, the tag device 820 may estimate its own position without exposing its own position.

[0259] Figure 8B An example of a ranging block structure of a downlink TDoA scheme according to an embodiment of the present disclosure is shown.

[0260] Figure 8B The ranging block structure can be used to perform Fig. 8A An example of a ranging block structure for a ranging scheme.

[0261] refer to Figure 8B , a ranging block may include multiple ranging cycles.

[0262] As an embodiment, the ranging block may include a plurality of ranging cycles allocated to a plurality of clusters accordingly. For example, when n clusters are deployed, the ranging block may include a first ranging cycle allocated to a first cluster, a second ranging cycle allocated to a second cluster, ..., and an nth ranging cycle allocated to an nth cluster. Figure 7 Although not shown in B, according to an embodiment, a plurality of ranging cycles may be allocated to one cluster, or one ranging cycle may be allocated to a plurality of clusters.

[0263] In an embodiment, a ranging cycle may include a plurality of ranging slots. A ranging cycle may include a plurality of ranging slots allocated for corresponding ranging messages sent by anchor devices belonging to a cluster associated with the ranging cycle. For example, when a first cluster is configured by one initiator anchor and three responder anchors, a ranging cycle for the first cluster may include a first ranging slot (e.g., ranging slot index 0) allocated for sending / receiving a polling message of an initiator anchor included in the first cluster, a second ranging slot allocated for sending / receiving a response message of the first responder anchor, a third ranging slot allocated for sending / receiving a response message of the second responder anchor, a fourth ranging slot allocated for sending / receiving a response message of the third responder anchor, and a fifth ranging slot allocated for sending / receiving a final message of the initiator anchor.

[0264] In this way, ranging slots can be allocated to the ranging cycle of each cluster.

[0265] Through Figure 8B In the ranging block structure of the embodiment, the anchor devices of each cluster can exchange ranging messages in a cycle through their own ranging cycles in one ranging block, and the UE (tag device) can receive these ranging messages to calculate its own position. These operations can be repeated for each ranging block. Therefore, the position of the UE can be updated according to the ranging block period.

[0266] Fig. 9 A shows a payment processing method using UWB according to an embodiment of the present disclosure.

[0267] refer to Fig. 9 , payment processing using UWB can be performed by payment terminal 901, UE 902 and / or payment server 903.

[0268] The payment terminal 901 may be an electronic device that communicates with the UE (or a UWB-enabled (UWB-enabled) payment application of the UE) to perform an electronic funds transfer. The payment terminal 901 may be, for example, a point of service (PoS) terminal or a smartphone that supports payment processing functions. In an embodiment, the payment terminal 901 may operate as a controller / initiator for TWR and / or a DT-anchor for DL-TDoA. The payment terminal 901 may have, for example, Figure 1 All or some components of a UWB device or Figure 2A / Figure 2B All or some components of an electronic device (eg, a first electronic device or a second electronic device).

[0269] UE 902 may be a user's electronic device including a UWB-enabled payment application. UE 902 may be, for example, a user's smartphone. In an embodiment, UE 902 may operate as a slave / responder for TWR and / or as a DT-tag for DL-TDoA. UE 902 may have, for example, Figure 1 All or some components of a UWB device or Figure 2A / Figure 2B All or some components of an electronic device (eg, a first electronic device or a second electronic device).

[0270] The payment server 903 may be a backend server (system) that supports payments to the payment terminal 901 and / or UE 902 such as acquirers and issuers.

[0271] refer to Fig. 9, the payment processing method using UWB may include a UWB / BLE-based device discovery phase 910, a payment terminal information transmission phase 920, a user information transmission phase 930, a transaction information transmission phase 940, a UWB security ranging phase 950, and / or a payment phase 960. However, depending on the embodiment, some phases may be omitted, multiple phases may be combined into one phase, or additional phases may be further performed. In addition, the various phases may be performed in an order different from that shown here. For example, the transaction information transmission phase 940 may be performed after the UWB security ranging phase 950. For example, the UWB security ranging phase 950 may be omitted.

[0272] [Device discovery phase 910 based on UWB / BLE]

[0273] In an embodiment, the UWB / BLE based device discovery phase 910 may include a BLE advertising operation.

[0274] As an embodiment, the BLE announcement operation may include an operation in which the payment terminal 901 sends a BLE announcement packet to the UE as a BLE announcer. As an embodiment, the BLE announcement packet may include at least one piece of information that enables the UE 902 to initiate at least one UWB operation. For example, the BLE announcement packet may include a UWB payment identifier for identifying a supported payment service (or payment application). As an embodiment, at least one UWB operation that may be initiated based on the reception of the BLE announcement packet may include at least one of a DL-TDoA positioning process 911, a UWB announcement process 912, and a contention-based ranging (UWB contention-based ranging) process 913.

[0275] In an embodiment, the DL-TDoA positioning process 911 may be initiated upon receipt of a BLE advertisement packet or by user input executing a UWB enabled payment application.

[0276] The DL-TDoA positioning process 911 may provide a DL-TDoA based positioning service to the UE 902. Therefore, the UE 902 may estimate its location and perform proximity-based payment transactions without exposing the location to the payment terminal 901.

[0277] As an example, the DL-TDoA positioning process 911 may include an operation in which the payment terminal 901 sends a UWB message (eg, a polling DTM, a responding DTM, or a final DTM) for DL-TDoA.

[0278] In an embodiment, the contention-based ranging process 913 may be initiated upon receipt of a BLE advertisement packet or by user input executing a UWB-enabled payment application.

[0279] When the payment terminal 901 and the UE 902 are unaware of each other, the UE 902 is not suitable for performing scheduling-based ranging to respond to the UWB message (e.g., RIM) sent by the payment terminal 901. Therefore, in order for the UE 902 to respond to the UWB message sent by the payment terminal 901, it is necessary to perform contention-based ranging.

[0280] As an embodiment, the contention-based ranging process 913 may include an operation in which the payment terminal 901 transmits a control message for contention-based ranging. The control message may include information on a CAP for contention-based access of the UE 902.

[0281] As an embodiment, a control message (information) for contention-based ranging and a message (information) for DL-TDoA may be transmitted through one combined UWB message.

[0282] As an embodiment, in the contention-based ranging process 913, when a pre-configured condition is met, the UE 902 may respond to the UWB message sent by the payment terminal 901. For example, based on the result obtained by the DL-TDoA positioning process 911, when the distance between the UE 902 and the payment terminal 901 is identified as less than or equal to the pre-configured distance, the UE 902 may send a response message (e.g., RRM) to the payment terminal 901. As an embodiment, the UE 902 may send the response message in any time slot within the CAP configured by the payment terminal 901.

[0283] In an embodiment, the UWB announcement process 912 may be initiated based on the reception of a BLE announcement packet or by executing a UWB-enabled payment application through user input. In the UWB announcement process 912, the payment terminal 901 may send a UWB announcement message (signal), and the UE 902 may measure the AoA value of the received UWB announcement message. Based on the measured AoA value, the user's intention for payment processing may be detected. For example, a user's posture (tilting UX) of pointing the UE 902 toward the payment terminal 901 may be preconfigured as a posture for indicating the user's intention to start payment processing. When this posture is adopted, the AoA value of the UWB announcement message received from the payment terminal 901 may be measured to be almost zero. Therefore, in this case, when the AoA value is measured to be close to zero, the UE 902 may recognize that the user intends to start payment processing.

[0284] [Payment terminal information transmission stage 920]

[0285] In an embodiment, the payment terminal information transmission phase 920 may include an operation in which the payment terminal 901 sends payment terminal information to the UE 902. The payment terminal information may be referred to as PoS information.

[0286] As an embodiment, the payment terminal information may be included in a control message for contention-based ranging so as to be transmitted from the payment terminal 901 to the UE 902. As an embodiment, the payment terminal information may be included in a message for DL-TDoA (e.g., polling DTM, response DTM, or final DTM) so as to be transmitted from the payment terminal 901 to the UE 902. As an embodiment, the payment terminal information may be included in a UWB message in which a control message for contention-based ranging and a message for DL-TDoA are combined so as to be transmitted from the payment terminal 901 to the UE 902. As an embodiment, the payment terminal information may be included in a UWB message in which a control message for contention-based ranging and a start message and a data message of contention-based ranging are combined so as to be transmitted from the payment terminal 901 to the UE 902.

[0287] As an embodiment, the payment terminal information may be included in a UWB message, in which a message for DL-TDoA (e.g., polling DTM, response DTM, or final DTM), a control message for contention-based ranging, and a startup message and a data message for contention-based ranging are combined so as to be sent from the payment terminal 901 to the UE 902.

[0288] Therefore, payment terminal information can be sent in-band via UWB.

[0289] As an example, the payment terminal information may include identification information (e.g., identifier) ​​of the payment terminal 901 (or a merchant associated with the payment terminal 901), name information (e.g., nickname) of the payment terminal 901 (or a merchant associated with the payment terminal 901), and / or random challenge information (POS challenge) for mutual authentication of the payment terminal 901. The random challenge information (POS challenge) of the payment terminal 901 may be a random value (e.g., random number) generated by the payment terminal 901 for mutual authentication in a random challenge manner.

[0290] As an embodiment, the payment terminal information may be included in the payload within the content field of the data message so as to be sent. The payload of the data message may be an unencrypted public message. Table 5 below shows an example of a TLV formatted message that may be included in the payload of the DM Payload IE so as to be sent by the payment terminal, wherein the payload of the DM Payload IE is sent in combination with the contention-based start message. The payment terminal may configure some or more of the following messages in TLV format and add the TLV formatted message to the payload of the DM Payload IE so as to send it to the UE.

[0291] [Table 5]

[0292] [User Information Transmission Phase 930]

[0293] In an embodiment, the user information transmission phase 930 may include an operation in which the UE 902 transmits the user information to the payment terminal 901 .

[0294] As an embodiment, in the contention-based ranging process 913, the user information may be included in a response message (e.g., RRM for SS-TWR) sent from the UE 902 to the payment terminal 901 so as to be transmitted. Therefore, the user information may be transmitted in-band via UWB. As an embodiment, the user information may be included in a UWB message, in which a response message of contention-based ranging and a data message are combined so as to be transmitted from the UE 902 to the payment terminal 901. As an embodiment, the user information may be included in a payload within a content field of a data message so as to be transmitted. The payload of the data message may be an unencrypted public message.

[0295] As an embodiment, the user information may include identification information (e.g., an identifier) ​​of the UE 902 (or a user of the UE 902), name information (e.g., a nickname) of the UE 902 (or a user of the UE 902), and / or random challenge information (user challenge) of the UE 902 for mutual authentication. The random challenge information (user challenge) of the UE 902 may be a random value (e.g., a random number) generated by the UE 902 for mutual authentication in a random challenge manner.

[0296] [Table 6]

[0297] [Transaction information transmission stage 940]

[0298] In an embodiment, the transaction information transmission phase 940 may include an operation in which the payment terminal 901 sends the transaction information to the UE (or a UWB-enabled payment application of the UE 902 ).

[0299] As an example, transaction information may be sent via UWB data messages (data frames).

[0300] As an example, the transaction information may be payment-related private information, such as a merchant name and a transaction amount, sent from the payment terminal 901 to the UE 902. The transaction information may be data in a TLV format, including some or all of the information such as supported payment protocol types, transaction amounts, and bills.

[0301] [Table 7]

[0302] As an embodiment, the transaction information transmission phase 940 may be performed after a secure channel (session) is established. For example, the transaction information transmission phase 940 may be performed after a secure session is established through the UWB secure ranging process 950 .

[0303] [UWB secure ranging stage 950]

[0304] In an embodiment, the UWB secure ranging phase 950 may include a process of performing secure ranging between the payment terminal 901 and the UE 902 by using an STS (eg, a dynamic STS). Thus, a secure session may be established between the payment terminal 901 and the UE 902.

[0305] As an embodiment, the UWB security ranging phase 950 may be an optional phase.

[0306] [Payment Phase 960]

[0307] In an embodiment, the payment phase 960 may include a process 961 in which the UE 902 and the payment terminal 901 exchange UWB secure data including payment information.

[0308] As an example, the payment information may be sent via a UWB data message (data frame).

[0309] As an example, the payment information may be payment-related private information, such as a card number sent from the UE 902 to the payment terminal 901. As an example, in the process 961 of exchanging UWB security data, the payment information may be encrypted and sent through a secure channel.

[0310] In an embodiment, the payment stage 960 may include a process 962 in which the UE 902 and the payment terminal 901 perform an online payment.

[0311] Using the information exchanged via the payment stage 960 , the payment terminal 901 and / or the UE 902 may perform backend interactions with the payment server 902 in order to complete the transaction.

[0312] Hereinafter, a method of performing both a contention-based ranging procedure and a DL-TDoA procedure is described.

[0313] Fig.10 A method of performing both DL-TDoA ranging and contention-based ranging by a UWB device according to an embodiment of the present disclosure is shown.

[0314] Fig.10 The ranging process of the embodiment may be a ranging process in which both DL-TDoA ranging and contention-based ranging are performed.

[0315] When with Fig. 8A When comparing DL-TDoA Fig. 9 The UWB message used in the ranging process of an embodiment may include both a payload IE for contention-based ranging and a payload IE for DL-TDoA.

[0316] exist Fig.10 In the embodiment of the present invention, for ease of description, it is assumed that four anchors including one initiator anchor 1001 and three responder anchors 1002-1 to 1002-3, and two UEs 1003-1 and 1003-2 perform a ranging process, but the embodiment is not limited thereto. For example, a different number of anchors and UEs than shown here may participate in the ranging process.

[0317] In an embodiment, the launcher anchor 1001 may be a payment terminal for a UWB-based payment service (e.g., Fig. 9 As an example, the initiator anchor 1001 may be used as both a controller / initiator for contention-based ranging (TWR) and a DT-anchor (eg, initiator DT-anchor) for DL-TDoA (OWR).

[0318] In an embodiment, responder anchors 1002-1, 1002-2, and 1002-3 may be payment terminals for UWB-based payment services (e.g., Fig. 9 As an example, the responder anchors 1002-1, 1002-2, and 1002-3 may serve as both a controller / initiator for contention-based ranging (TWR) and a DT-anchor (eg, responder DT-anchor) for DL-TDoA (OWR).

[0319] In an embodiment, UE 1003-1 and 1003-2 may be UEs for UWB-based payment services (eg, Fig. 9 As an embodiment, the UEs 1003-1 and 1003-2 may be used as both slaves / responders for contention-based ranging (TWR) and DT-tags for DL-TDoA (OWR).

[0320] In an embodiment, Fig.10 The ranging process of the embodiment of the present invention can be performed in one ranging cycle. For example, the ranging process for performing Fig.10 Message exchange between devices in the ranging process.

[0321] refer to Fig.10, the ranging process may include stage 1010, stage 1020 and / or stage 1030. According to the embodiment, some stages or some operations within the stages may be omitted, additional stages may be further performed, and the order of the corresponding stages may be changed.

[0322] [Stage 1010]

[0323] Stage 1010 may be a stage for transmitting or broadcasting a UWB message that can implement both DL-TDoA and contention-based ranging for anchors 1001, 1002-1, and 1002-3. Stage 1010 may include at least one of operations 1011 to 1013 to be described below.

[0324] In operation 1011, the initiator anchor 1001 may send or broadcast a first UWB message to initiate a ranging process. The first UWB message may be used to provide both a RIM function for contention-based ranging and a polling DTM function for DL-TDoA. In addition, the first UWB message may be used for a UWB announcement for a tilted UX. In addition, the first UWB message may be used to send payment terminal information. The first UWB message may be referred to as a startup message, a first DTM, a polling DTM, etc.

[0325] In an embodiment, the first UWB message may include both a payload IE for contention based ranging and a payload IE for DL-TDoA.

[0326] In an embodiment, the payload IE for contention-based ranging in the first UWB message may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging may be a control message type 2. As an embodiment, the control message may include information indicating a CAP size (CAP size information).

[0327] In an embodiment, the payload IE for DL-TDoA in the first UWB message may include data for polling the DTM.As an embodiment, the payload IE for DL-TDoA in the first UWB message may include scheduling information for each responder anchor 1002-1, 1002-2, or 1002-3.

[0328] In operation 1012, each responder anchor 1002-1, 1002-2, or 1002-3 may send or broadcast a second UWB message in response to the first UWB message. The second UWB message may be used to provide both the RIM function for contention-based ranging and the response DTM function for DL-TDoA. In addition, the second UWB message may be used for UWB announcements for tilted UX. In addition, the second UWB message may be used to send payment terminal information. The second UWB message may be referred to as a response message, a second DTM, a response DTM, etc.

[0329] In an embodiment, each responder anchor 1002-1, 1002-2, or 1002-3 may send or broadcast a second UWB message in its own ranging slot based on the scheduling information in the first UWB message.

[0330] In an embodiment, the second UWB message may include both a payload IE for contention based ranging and a payload IE for DL-TDoA.

[0331] In an embodiment, the payload IE for contention-based ranging in the second DTM may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging may be a control message (CM) type 2. As an embodiment, the control message for contention-based ranging in the second DTM may be a synchronized control message.

[0332] As an embodiment, in operation 1001 , the synchronization control message may be a control message synchronized with a control message included in the first UWB message transmitted by the initiator anchor 1001 .

[0333] As an embodiment, the CAP for contention-based ranging can be configured to the same time period through a synchronous control message. In other words, the synchronization of control messages with each other can indicate that the CAP configured by the synchronous control message has the same time period. For example, when the CAP configured by the control message included in the first control message is configured to correspond to the time period of ranging slot #11 to ranging slot #20, the control message synchronized with the control message included in the first control message can also configure the CAP to be the same as the time period corresponding to ranging slot #11 to ranging slot #20. Through the synchronous control message, the CAP configured by each control message can be configured to the same time period without conflicting with each other.

[0334] Hereinafter, synchronization of control messages is described by way of example.

[0335] The control message included in the first UWB message may include CAP size information. The CAP size information may specify the size of the CAP in which UEs 1003-1 and 1003-2 may make a contention-based response.

[0336] The CAP having the CAP size may be configured after a time point at which the initiator anchor 1001 and the responder anchors 1002 - 1 to 1002 - 4 transmit all UWB messages for DL-TDoA (ie, a time point at which the operation of stage 1010 is completed).

[0337] If it is assumed that stage 1010 ends at ranging slot #10, and the CAP size specified by the CAP size information of the control message in the first UWB message is 10, the CAP configured by the control message in the first UWB message can be configured to include a time period of 10 ranging slots after ranging slot #10 (e.g., a time period from ranging slot #11 to ranging slot #20). In this case, the CAP configured by the second UWB message having a control message synchronized with the control message in the first UWB message should also be configured to include a time period of 10 ranging slots after ranging slot #10 (e.g., a time period from ranging slot #11 to ranging slot #20). Therefore, the value of the size of the CAP configured by the control message in the first UWB message and the index value of the ranging slot included in the CAP should be equal to the value of the size of the CAP configured by the synchronization control message of the second UWB message and the index value of the ranging slot included in the CAP. Through these synchronized control messages, the time periods in which the UEs 1003 - 1 and 1003 - 2 can make contention-based responses can all be configured to have the same time period without conflict.

[0338] Hereinafter, a method of configuring a synchronized control message is described by way of example.

[0339] For example, as shown in the figure, when it is assumed that there is one initiator anchor and three responder anchors, and the CAP size is 5, the method of configuring the synchronization control message may be as follows.

[0340] In ranging slot #0, the initiator anchor sends the first UWB message (the initiation message).

[0341] In ranging slots #1, #2, and #3, the responder anchor transmits a second UWB message (first response message), respectively.

[0342] In ranging slot #4, the initiator anchor sends a third UWB message (final message).

[0343] The UE can attempt to make a contention-based response by randomly selecting one of ranging slots #5, #6, #7, #8, and #9.

[0344] In this case, when the initiator anchor transmits the first UWB message in ranging slot #0, the initiator anchor may configure the value of the CAP size information in the control message to be 5, and configure the value of the responder management list size (RML size) information to be 4. Therefore, the UE may skip 4 ranging slots corresponding to the value 4 specified by the RML size information in ranging slot #0 in which the initiator anchor has transmitted the first UWB message, and then perform contention-based response in 5 ranging slots corresponding to the value 5 specified by the CAP size information starting from ranging slot #5. That is, based on the CAP size information (=5) and the RML size information (=4) of the control message in the first UWB message, the UE may recognize that the time period corresponding to ranging slots #5 to #9 is the CAP, and transmit the response message in any slot within the CAP.

[0345] Then, when the first responder anchor transmits the second UWB message in ranging slot #1, the first responder anchor may similarly configure the value of the CAP size information in the control message to 5, and configure the value of the RML size information to 3. Therefore, the UE may skip 3 ranging slots corresponding to the value 3 specified by the RML size information from ranging slot #1 in which the first responder anchor has transmitted the second UWB message, and then perform contention-based response in 3 ranging slots corresponding to the value 3 specified by the CAP size information from ranging slot #3. That is, the same CAP may be configured by the control message of the initiator anchor and the synchronization control message of the first responder anchor.

[0346] Likewise, control messages in UWB messages transmitted by all remaining anchors may be configured to designate CAP as the same time period corresponding to ranging slots #5, #6, #7, #8, and #9 so that the control messages may be synchronized with each other.

[0347] In an embodiment, the payload IE for DL-TDoA in the second UWB message may include data of the response DTM. As an embodiment, the payload IE for DL-TDoA in the second UWB message may include first response time information. The first response time information of the corresponding responder anchor may include a first responder response time, which indicates the time elapsed between the time when the responder anchor receives the first UWB message and the time when the second UWB message is sent.

[0348] In operation 1003, the initiator anchor 1001 may send or broadcast a third UWB message in response to the second UWB message from the responder anchors 1002-1, 1002-2, and 1002-3. The third UWB message may be used to provide both the RIM function for contention-based ranging and the final DTM function for DL-TDoA. In addition, the third UWB message may be used for UWB announcements for tilted UX. In addition, the third UWB message may be used to send payment terminal information. The third UWB message may be referred to as a final message, a third DTM, or a final DTM.

[0349] In an embodiment, the third UWB message may include both a payload IE for contention-based ranging and a payload IE for DL-TDoA.

[0350] In an embodiment, the payload IE for contention-based ranging in the third UWB message may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging in the third DTM may be a synchronization control message. For synchronization of the control message, reference may be made to the description in stage 1012.

[0351] In an embodiment, the payload IE for DL-TDoA in the third UWB message may include data of the final DTM. As an embodiment, the payload IE for DL-TDoA in the third UWB message may include second response time information. The second response time information may include a list of response times for the second UWB message from each responder anchor 1002-1, 1002-2, and 1002-3. The response time for the second UWB message may be the time elapsed between the time when the initiator anchor 1001 receives the second UWB message from the corresponding responder anchor and the time when the third UWB message is sent.

[0352] In an embodiment, the third UWB message may be used as a UWB announcement message for UWB announcement. As an embodiment, the third UWB message may include information to be used as a UWB announcement message. UEs 1003-1 and 1003-2 may perform a UWB announcement procedure for a tilted UX (e.g., Fig. 9 UWB announcement process 912).

[0353] In an embodiment, the third UWB message may further include random challenge information (pos-challenge) of the anchor for mutual authentication.

[0354] [Phase 1020]

[0355] Stage 1020 may be a stage for the UE to perform DL-TDoA positioning and perform a contention-based response to the anchor. Stage 1020 may include at least one of the following operations 1021 to 1022.

[0356] In operation 1021, UEs 1003-1 and 1003-2 may receive the first UWB message, the second UWB message, and the third UWB message, calculate TDoA based on a payload IE for DL-TDoA in each UWB message, and estimate their own positions based on the calculated TDoA.

[0357] In operation 1022, each UE 1003-1 or 1003-2 may transmit a ranging response message (RRM) for contention-based ranging to the selected anchor.

[0358] In an embodiment, UE 1003-1 or 1003-2 may select one of anchors 1001 and 1002-1 to 1002-4 based on preconfigured criteria. For example, UE 1003-1 or 1003-2 may select an anchor located within a preconfigured distance (e.g., 2 meters) from the location of the UE based on the DL-TDoA result. If there are multiple anchors located within the preconfigured distance, the UE may select an anchor located at the closest distance among the multiple anchors.

[0359] In an embodiment, UE 1003-1 or 1003-2 may send a ranging response message in any ranging time slot within the CAP. As an embodiment, the CAP may be configured by a control message in a first UWB message, a synchronization control message in a second UWB message, and a synchronization control message in a third UWB message. The CAPs configured by the synchronization control messages may have the same time period.

[0360] In an embodiment, the ranging response message may include user information. For example, the ranging response message may additionally include a random challenge value (user challenge) randomly generated by the UE. In this case, the random challenge value may be included in a data message payload IE (DM payload IE) so as to be transmitted, and the DM payload IE is transmitted in the RRM. The user challenge (user challenge) value transmitted in operation 1022 may be used as a security tool to verify whether the payment terminal 1001 has a valid certificate and a corresponding private key.

[0361] In an embodiment, the ranging response message may include reply time information specifying the time elapsed between the time a UWB message (eg, the first UWB message, the second UWB message, or the third UWB message) is received from the selected anchor and the time the ranging response message is sent.

[0362] [Phase 1030]

[0363] Phase 1030 may be a phase in which the anchor that has received the ranging response message measures the distance to the UE that has responded. As an embodiment, the distance measurement may be based on SS-TWR.

[0364] The anchor having received the response message from the UE may perform an SS-TWR operation based on the ranging response message at stage 1030. Thus, the anchor may acquire an accurate distance from the UE.

[0365] and Fig. 8A The embodiments are different. Fig.10 In the embodiment of the present invention, the UWB message used in the ranging process includes not only the payload IE for DL-TDoA, but also the payload IE for contention-based ranging. Therefore, both DL-TDoA ranging and contention-based ranging can be performed in one ranging cycle (ranging cycle). This can improve the efficiency of resource utilization.

[0366] Fig.11 A method of performing both DL-TDoA ranging and contention-based ranging by a UWB device according to an embodiment of the present disclosure is shown.

[0367] Fig.11 The ranging process of the embodiment may be a ranging process that performs both DL-TDoA ranging and contention-based ranging.

[0368] When with Fig. 8A When compared, Fig.11 The UWB message used in the ranging process of an embodiment may include both a payload IE for contention-based ranging and a payload IE for DL-TDoA.

[0369] When with Fig. 8A and Fig.10 When compared with the DL-TDoA process, Fig.11 In the ranging process of the embodiment, each responder anchor may send two response DTMs (second DTMs) in one ranging cycle (DL-TDoA ranging cycle).

[0370] exist Fig.11 In the embodiment of the present invention, for ease of description, it is assumed that five anchors including one initiator anchor 1101 and four responder anchors 1102-1 to 1102-4, and two UEs 1103-1 and 1103-2 perform a ranging process, but the embodiment is not limited thereto. For example, a different number of anchors and UEs than shown here may participate in the ranging process.

[0371] In an embodiment, the launcher anchor 1101 may be a payment terminal for a UWB-based payment service (e.g., Fig. 9As an example, the initiator anchor 1101 may serve as both a controller / initiator for contention-based ranging (TWR) and a DT-anchor (eg, initiator DT-anchor) for DL-TDoA (OWR).

[0372] In an embodiment, responder anchors 1102-1, 1102-2, 1102-3, and 1102-4 may be payment terminals for UWB-based payment services (e.g., Fig. 9 As an example, the responder anchors 1102-1, 1102-2, 1102-3, and 1102-4 may serve as both a controller / initiator for contention-based ranging (TWR) and a DT-anchor (eg, responder DT-anchor) for DL-TDoA (OWR).

[0373] In an embodiment, UE 1103-1 and 1103-2 may be UEs for UWB-based payment services (eg, Fig. 9 As an embodiment, UE 1103-1 and 1103-2 may be used as both a slave / responder for contention-based ranging (TWR) and a DT-Tag for DL-TDoA (OWR).

[0374] In an embodiment, Fig.11 The ranging process of the embodiment can be performed in one ranging cycle. For example, Fig.11 Operations 1111 to 1150 may be performed in one ranging cycle.

[0375] refer to Fig.11 In operation 1110, the initiator anchor 1101 may send or broadcast a first UWB message to initiate a ranging process. The first UWB message may be used to provide both a RIM function for contention-based ranging and a polling DTM function for DL-TDoA. In addition, the first UWB message may be used for a UWB announcement for a tilted UX. In addition, the first UWB message may be used to send payment terminal information. The first UWB message may be referred to as a startup message, a first DTM, a polling DTM, etc.

[0376] In an embodiment, the first UWB message may include both a payload IE for contention based ranging and a payload IE for DL-TDoA.

[0377] In an embodiment, the payload IE for contention-based ranging in the first UWB message may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging may be a control message type 2. As an embodiment, the control message may include information indicating a CAP size (CAP size information).

[0378] In an embodiment, the payload IE for DL-TDoA in the first UWB message may include data for polling the DTM.As an embodiment, the payload IE for DL-TDoA in the first UWB message may include scheduling information for each responder anchor 1102-1, 1102-2, 1102-3, or 1102-4.

[0379] In operation 1120, each responder anchor 1102-1, 1102-2, 1102-3, or 1102-4 may send or broadcast a second UWB message in response to the first UWB message. The second UWB message may be used to provide both the RIM function for contention-based ranging and the response DTM function for DL-TDoA. In addition, the second UWB message may be used for UWB announcements for tilted UX. In addition, the second UWB message may be used to send payment terminal information. The second UWB message may be referred to as a first response message, a second DTM, a response DTM, etc.

[0380] In an embodiment, each responder anchor 1102-1, 1102-2, 1102-3, or 1102-4 may send or broadcast a second UWB message in its own ranging slot based on the first scheduling information in the first UWB message.

[0381] In an embodiment, the second UWB message may include both a payload IE for contention based ranging and a payload IE for DL-TDoA.

[0382] In an embodiment, the payload IE for contention-based ranging in the second DTM may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging may be a control message (CM) type 2. As an embodiment, the control message for contention-based ranging in the second DTM may be a synchronized control message.

[0383] As an embodiment, in operation 1111 , the synchronization control message may be a control message synchronized with a control message included in the first UWB message transmitted by the initiator anchor 1101 .

[0384] As an embodiment, the CAP for contention-based ranging can be configured to the same time period through a synchronous control message. In other words, the synchronization of control messages with each other can indicate that the CAP configured by the synchronous control message has the same time period. For example, when the CAP configured by the control message included in the first control message is configured to correspond to the time period from ranging slot #11 to ranging slot #20, the control message synchronized with the control message included in the first control message can also configure the CAP to be the same as the time period corresponding to ranging slot #11 to ranging slot #20. Through the synchronous control message, the CAP configured by each control message can be configured to the same time period without conflicting with each other. For the synchronization of control messages, reference can be made to Fig.10 as described in stage 1012 of the present invention.

[0385] In an embodiment, the payload IE for DL-TDoA in the second UWB message may include data of the response DTM. As an embodiment, the payload IE for DL-TDoA in the second UWB message may include first response time information. The first response time information of the corresponding responder anchor may include a first responder response time, which indicates the time elapsed between the time when the responder anchor receives the first DTM and the time when the second DTM is sent.

[0386] In operation 1130, the initiator anchor 1101 may send or broadcast a third UWB message in response to the second UWB message from the responder anchors 1102-1, 1102-2, 1102-3, and 1102-4. The third UWB message may be used to provide both the RIM function for contention-based ranging and the final DTM function for DL-TDoA. In addition, the third UWB message may be used for UWB announcements for tilted UX. In addition, the third UWB message may be used to send payment terminal information. The third UWB message may be referred to as a final message, a third DTM, or a final DTM.

[0387] In an embodiment, the third UWB message may include both a payload IE for contention-based ranging and a payload IE for DL-TDoA.

[0388] In an embodiment, the payload IE for contention-based ranging in the third UWB message may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging in the third DTM may be a synchronization control message. In order to control the synchronization of the message, reference may be made to Fig. 9 as described in stage 920.

[0389] In an embodiment, the payload IE for DL-TDoA in the third UWB message may include data of the final DTM. As an embodiment, the payload IE for DL-TDoA in the third UWB message may include second response time information. The second response time information may include a list of response times for the second DTM from each responder anchor 1102-1, 1102-2, 1102-3, and 1102-4. The response time for the second DTM may be the time elapsed between the time when the initiator anchor 1101 receives the second DTM from the corresponding responder anchor and the time when the third DTM is sent.

[0390] In operation 1140, each responder anchor 1102-1, 1102-2, 1102-3, or 1102-4 may send or broadcast a fourth UWB message in response to the third UWB message. The fourth UWB message may be used to provide both the RIM function for contention-based ranging and the response DTM function for DL-TDoA. In addition, the fourth UWB message may be used for UWB announcements for tilted UX. In addition, the fourth UWB message may be used to send payment terminal information. As an embodiment, the message format of the fourth UWB message may be the same as the message format of the second UWB message. The fourth UWB message may be referred to as a second response message, a second DTM, a response DTM, etc.

[0391] In an embodiment, each responder anchor 1102-1, 1102-2, 1102-3, or 1102-4 may send or broadcast a fourth UWB message in its own ranging slot based on the second scheduling information in the first UWB message.

[0392] In an embodiment, the fourth UWB message may include both a payload IE for contention-based ranging and a payload IE for DL-TDoA.

[0393] In an embodiment, the payload IE for contention-based ranging in the fourth UWB message may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging may be a control message (CM) type 2. As an embodiment, the control message for contention-based ranging in the fourth DTM may be a synchronized control message. For synchronization of the control message, reference may be made to the description in stage 920.

[0394] In an embodiment, the payload IE for DL-TDoA in the fourth UWB message may include data of the response DTM. As an embodiment, the payload IE for DL-TDoA in the fourth UWB message may include third response time information. The third response time information of the corresponding responder anchor may include a second responder response time, which indicates the time elapsed between the time when the responder anchor receives the third DTM and the time when the fourth DTM is sent.

[0395] In an embodiment, UEs 1103-1 and 1003-2 may receive a first UWB message, a second UWB message, a third UWB message, and a fourth UWB message, calculate TDoA based on a payload IE of DL-TDoA in each UWB message, and estimate their own positions based on the calculated TDoA.

[0396] In operation 1150, each UE 1103-1 or 1003-2 may send a ranging response message (RRM) for contention-based ranging to the selected anchor. The anchor having received the response message from the UE may perform an SS-TWR operation based on the ranging response message. Thus, the anchor may acquire an accurate distance from the UE. The ranging response message may be referred to as a fifth UWB message or an extended ranging response message (extended RRM).

[0397] In an embodiment, UE 1103-1 or 1003-2 may select one of anchors 1101 and 1102-1 to 1102-4 based on preconfigured criteria. For example, UE 1103-1 or 1003-2 may select an anchor located within a preconfigured distance (e.g., 2 meters) from the location of the UE based on the DL-TDoA result. If there are multiple anchors located within the preconfigured distance, the UE may select an anchor located at the closest distance among the multiple anchors.

[0398] In an embodiment, UE 1103-1 or 1103-2 may send a ranging response message in any ranging time slot within the CAP. As an embodiment, the CAP may be configured by a control message in a first UWB message, a synchronization control message in a second UWB message, a synchronization control message in a third UWB message, and a synchronization control message in a fourth UWB message. The CAPs configured by the synchronization control messages may have the same time period.

[0399] In an embodiment, the ranging response message may include user information.

[0400] In an embodiment, the ranging response message may include two pieces of response time information for the selected anchor. For example, if responder anchor 1102-1 is selected, the ranging response message may include response time information for the second UWB message of responder anchor 1102-1 and response time information for the fourth UWB message of responder anchor 1102-1. The response time information for the second UWB message of responder anchor 1102-1 may be the time elapsed between the reception time of the second UWB message of responder anchor 1102-1 and the transmission time of the ranging response message from the UE. The response time information for the fourth UWB message of responder anchor 1102-1 may be the time elapsed between the reception time of the fourth UWB message of responder anchor 1102-1 and the transmission time of the ranging response message from the UE.

[0401] for Fig. 8A and Fig.10 In the embodiment of the present invention, in one DL-TDoA ranging cycle, the initiator anchor sends two DTMs, but the responder anchor may only send one DTM. Fig. 8A and Fig.10 In an embodiment, it is difficult for the UE to estimate the CFO of the responder anchor.

[0402] However, for Fig.11 In an embodiment, all anchors transmit two or more DTMs (UWB messages) in one DL-TDoA ranging cycle. Therefore, the UE can receive two or more DTMs from each anchor. As a result, the UE can estimate the clock frequency offset (CFO) for any anchor based on the two or more DTMs received from each anchor. In addition, since each anchor transmits two or more DTMs, the possibility of the UE acquiring TDoA can be increased.

[0403] In addition, when Fig. 8A When compared with the embodiment of Fig.11 In the embodiment of the present invention, the UWB message used in the ranging process includes not only the payload IE for DL-TDoA, but also the payload IE for contention-based ranging. Therefore, both DL-TDoA ranging and contention-based ranging can be performed in one ranging cycle (ranging cycle). This can improve the efficiency of resource utilization.

[0404] Fig. 12A The structure of a UWB message according to an embodiment of the present disclosure is shown.

[0405] exist Fig. 12A In the embodiment of the present invention, the UWB message may be Fig.10 and Fig.11 An example of a UWB message used in the ranging process. For example, Fig. 12A The UWB message can be in Fig.10 and Fig.11 An example of a UWB message (eg, one of the first to fourth UWB messages) used in a ranging process.

[0406] refer to Fig. 12A The UWB message includes a MAC header 1210, a MAC payload including a payload IE 1220-1 for contention-based ranging and a payload IE 1220-2 for DL-TDoA, and a MAC frame trailer 1230 including an FCS.

[0407] In an embodiment, the MAC header 1210 may include Figure 4 All or some of the fields included in the MAC header.

[0408] In an embodiment, the payload IE 1220-1 for contention-based ranging may include data of a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging may include information indicating a CAP size, information about a transmit (Tx) offset, and / or configuration information related to a responder management list (RML).

[0409] In an embodiment, the Payload IE 1220 - 2 for DL-TDoA may include all or some fields contained in any one of the Payload IE of the Polling DTM, the Payload IE of the Responder DTM, or the Payload IE of the Final DTM.

[0410] Fig. 12B The payload structure of a UWB message according to an embodiment of the present disclosure is shown.

[0411] exist Fig. 12B In the embodiment of the present invention, the payload of the UWB message may be Fig. 12A An example of the payload (MAC payload) of a UWB message.

[0412] refer to Fig. 12B , the UWB message (or the payload of the UWB message) may include a payload IE 1220-1 for contention-based ranging and a payload IE 1220-2 for DL-TDoA. The payload IE 1220-1 for contention-based ranging may be Fig.11 An example of a payload IE 1120-1 for contention-based ranging and a payload IE 1220-2 for DL-TDoA may be Fig.11 Example of Payload IE 1120-2 for DL-TDoA.

[0413] exist Fig. 12BIn the embodiment of the present invention, the payload IE 1220-1 for contention-based ranging may precede the payload IE 1220-2 for DL-TDoA.

[0414] [Payload IE 1220-1 for Contention-Based Ranging]

[0415] The payload IE 1220-1 for contention-based ranging may include a control message for contention-based ranging. As an embodiment, the control message for contention-based ranging may be a control message type 2.

[0416] In an embodiment, the payload IE 1220-1 for contention-based ranging (or a control message for contention-based ranging) may include a UWB message ID field, a message control field, a step length field, an RML size field, and / or an RML field.

[0417] The UWB message ID field may identify a UWB message.For the payload IE 1220-1 for contention-based ranging, the UWB ID field may be configured to a value that specifies a control message.

[0418] The message control field may configure parameters for contention-based ranging with responders participating in contention-based ranging. As an embodiment, the message control field may include CAP size information (field) that specifies the size of the contention time period in units of ranging slots used in the CAP. Through the CAP size information, the number of ranging slots in which the UE can make a contention-based response may be specified. Table 8 below may show an example of the message control field.

[0419] [Table 8]

[0420] The step length field may specify the number of ranging blocks to skip.

[0421] The RML size field may specify the RML size.

[0422] The RML field may be a list of device MAC addresses including known responders. The RML field may include the number of RML elements corresponding to the RML size. Table 9 below shows an example of RML elements included in the RML field. Referring to Table 2, each RML element may specify the MAC address of the corresponding responder.

[0423] [Table 9]

[0424] For example, when a two-byte short MAC address is used and 5 responders are managed by the RML, the value of the RML size field may be configured as 5, and the RML field may be data having a length of 10 bytes.

[0425] like Fig.10 and Fig.11 As shown, the CAP in which the UE can perform a contention-based response can be configured by including a CAP size field and an RML size field in the payload IE 1220-1 for contention-based ranging. In addition, when the control messages for contention-based ranging are synchronized with each other, the value of the CAP size field and the value of the RML size field can be configured so that all synchronous control messages can configure the same CAP. In this case, the value of the CAP size field can be the same in all synchronous control messages.

[0426] [Payload IE 1220-2 for DL-TDoA]

[0427] In an embodiment, the payload IE 1220 - 2 for DL-TDoA may include a UWB message ID field, an OWR message type field, and an OWR message type-related payload field.

[0428] The UWB message ID field may identify a UWB message. For the Payload IE 1220-2 for DL-TDoA, the UWB ID field may be configured as a value specifying an OWR message.

[0429] The OWR Message Type field may specify the OWR message type. For Payload IE 1220-2 for DL-TDoA, the OWR Message Type field may be configured to specify a value of one of Polling DTM, Response DTM, or Final DTM.

[0430] The payload field associated with the OWR message type may include payload data according to the value specified by the OWR message type field. When the value configured in the OWR message type field specifies a polling DTM, a responding DTM, or a final DTM, that is, when a DTM is specified, the following reference Fig.13A and Fig. 13B To describe examples of payload fields related to the OWR message type.

[0431] Fig. 12C The payload structure of a UWB message according to an embodiment of the present disclosure is shown.

[0432] exist Fig. 12C In the embodiment of the present invention, the payload of the UWB message may be Fig. 12A An example of the payload (MAC payload) of a UWB message.

[0433] refer to Fig. 12C , the UWB message (or the payload of the UWB message) may include a payload IE 1220-1 for contention-based ranging and a payload IE 1220-2 for DL-TDoA. The payload IE 1220-1 for contention-based ranging may be Fig.11 An example of a payload IE 1120-1 for contention-based ranging and a payload IE 1220-2 for DL-TDoA may be Fig.11 Example of Payload IE 1120-2 for DL-TDoA.

[0434] and Fig. 12B The embodiments are different. Fig. 12C In the embodiment of the present invention, the payload IE 1220-1 for contention-based ranging may be followed by the payload IE 1220-2 for DL-TDoA.

[0435] exist Fig. 12C In the embodiment of the present invention, each field (information) included in the payload IE 1220-1 for contention-based ranging is the same as Fig. 12B Each field (information) included in the payload IE 1220-1 for contention-based ranging is the same as in . Therefore, reference may be made to Fig. 12B Description.

[0436] also, Fig. 12C Each field (information) included in the payload IE 1220-2 for DL-TDoA in the embodiment is the same as Fig. 12B Each field (information) included in the payload IE 1220-2 for DL-TDoA is the same. Therefore, reference may be made to Fig. 12B Description.

[0437] Fig.13A and Fig. 13B An example of an OWR message type-related payload field included in a UWB message according to an embodiment of the present disclosure is shown.

[0438] In the embodiment of FIG. 13 , the payload field associated with the OWR message type of the UWB message may be Fig. 12A and Fig. 12B

[0063] An example of payload fields associated with the OWR message type of the Payload IE 1220-2 for DL-TDoA.

[0439] refer to Fig.13A, when the value configured in the OWR message type field specifies polling DTM, responding DTM, or final DTM, the payload fields associated with the OWR message type may include a message control field, a cycle index field, a block index field, a transmit (Tx) timestamp field, and / or a responder DT-anchor management list field.

[0440] The message control field may include the configuration of the corresponding DTM.

[0441] The loop index field may specify the loop index of the current ranging loop.

[0442] The block index field may specify the block index of the current ranging block.

[0443] The transmit timestamp field may specify the transmit timestamp of the DTM expressed as a local or common time base.

[0444] The Responder DT-Anchor Management List field may include N Responder DT-Anchor Management List elements.

[0445] N may be determined by the value of the Responder DT-Anchor Management List Length field in the Message Control field. Each Responder DT-Anchor Management List element may include a Responder Address field, a Ranging Slot Index field, a Second Ranging Slot Index field, and / or a ToF Result field for the corresponding Responder DT-Anchor. Fig. 13B To describe an example of a responder DT-anchor management list element.

[0446] refer to Fig. 13B , the responder DT-anchor management list element may include a responder address field, a ranging slot index field, a second ranging slot index field and / or a ToF result field.

[0447] The Responder Address field may specify the address (eg, MAC address) of the responder DT-Anchor (Responder Anchor).

[0448] The Ranging Slot Index field may specify a ranging slot allocated to the responder DT-anchor (responder anchor) identified by the Responder Address field. As an embodiment, the ranging slot specified by the Ranging Slot Index field may be used by the responder DT-anchor to respond to an initiation message (e.g., Fig.10 / Fig.11 The first UWB message) is sent while the first response message (for example, Fig.10 / Fig.11 In other words, the second ranging slot index field may be used by the responder anchor to send the first response message.

[0449] The second ranging slot index field may specify a second ranging slot allocated to the responder DT-anchor (responder anchor) identified by the responder address field. As an embodiment, the ranging slot specified by the second ranging slot index field may be used by the responder DT-anchor to respond to the final message (e.g., Fig.10 / Fig.11 A third UWB message) is sent while a second response message (eg, Fig.10 / Fig.11 In other words, the second ranging slot index field may be used by the responder anchor to send a second response message.

[0450] The ToF Result field may include the ToF as a result of SS-TWR with the responder DT-Anchor identified by the Responder Address field.

[0451] In an embodiment, the OWR message type-related payload fields may further include a clock frequency offset (CFO) field specifying the CFO with respect to the initiator anchor and / or a response time field (eg, a response time list field or a responder response time field) containing information about at least one response time.

[0452] Fig.14 A method for generating a secure channel according to an embodiment of the present disclosure is shown.

[0453] The payment terminal 1401 (e.g. Fig. 9 The payment terminal 901) and the UE 1402 (for example, Fig. 9 A secure channel is established between the payment terminal 1401 and the payment application of the UE 902) (or the payment application (wallet application) of the UE). For example, the secure channel can be used to establish a communication channel supporting encryption between the payment terminal 1401 and the payment application of the UE 1402.

[0454] The secure channel may be used for the payment terminal 1401 and the UE 1402 to exchange payment transactions within the UWB band.

[0455] refer to Fig.14 , the process of establishing a secure channel may include operations 1 to 11. However, according to an embodiment, some operations may be omitted, additional operations may be further performed, or operations may be performed in an order different from that shown here.

[0456] In operation 1, the payment terminal 1401 may generate a temporary key of the payment terminal. The temporary key of the payment terminal may be represented as "ePK.Terminal".

[0457] In addition, the payment terminal 1401 may perform a signature on the generated "ePK.Terminal" by using a private key. As an example, the private key may be a static private key. The signed temporary key of the payment terminal may be represented as "Sign (signature) (ePK.Terminal)".

[0458] In addition, the payment terminal 1401 can use the private key to perform a signature by combining the generated ePK.Terminal and the user random challenge information transmitted by the UE in stage 1022. For example, a signature can be performed on a string (ePK.Terminal|UserChallenge) connecting the ePK.Terminal and the user random challenge. The user random challenge value is a value randomly generated and transmitted by the UE in stage 1022, so that by performing a signature on the string including the user random challenge value, the payment terminal 1401 can maintain a private key corresponding to the public key included in the certificate of the payment terminal, and this can be used as a method for proving that the payment terminal 1401 can perform a signature in real time.

[0459] In addition, the payment terminal 1401 may send "ePK.Terminal", "Sign (ePK.Terminal)", and the certificate of the payment terminal including the ID of the payment terminal together with the UE random challenge information for mutual authentication to the UE 1402. The certificate of the payment terminal including the ID of the payment terminal may be expressed as "Cert.Terminal (ID.Terminal)". The random challenge information of the UE may be expressed as "userChallenge (user challenge)".

[0460] In operation 2, UE 1402 (or payment application) may verify the certificate of the payment terminal (Cert.Terminal) and extract the public key of the payment terminal from the certificate. As an example, the public key may be a static public key. The public key of the payment terminal may be referred to as "PK.Ternimal".

[0461] In operation 3, UE 1402 (or payment application) can derive a shared temporary key (Ses). As an example, UE 1402 (or payment application) can generate Ses by using "ePK.Terminal" and the temporary private key of the payment application. The temporary key of the payment application can be expressed as "eSK.Wallet". For example, Ses can include "ePK.Terminal" and "eSK.Wallet". In this case, UE 1402 may already have a certificate chain for verifying the certificate of the payment terminal in the payment application or the payment applet. Alternatively, UE 1402 can perform verification by downloading a certificate chain that can be used to verify the certificate via a certificate database that can be searched using the payment terminal ID. The certificate chain can be a certificate chain including a certificate issued by a certificate issuer trusted by UE 1402.

[0462] In operation 4, UE 1402 (or payment application) may derive a shared static key (Shs). UE 1402 (or payment application) may generate Shs by using "PK.Terminal" and the static private key of the payment application. The static private key of the payment application may be represented as "SK.Wallet". As an example, Shs may include "PK.Terminal" and "SK.Wallet".

[0463] In operation 5, UE 1402 (or payment application) may derive a message authentication code (MAC) from "Shs" and "ePK.Terminal". The message authentication code may be represented as "ShsMAC.Wallet". As an example, the message authentication code is generated based on a password-based message authentication code (CMAC) algorithm. For example, the message authentication code may be generated based on "CMAC (Shs, ePK.Terminal, context)".

[0464] In operation 6, UE 1402 (or payment application) may generate secure channel keys for encryption and authentication, respectively. That is, secure channel keys for encryption and secure channel keys for authentication may be generated separately. UE 1402 (or payment application) may generate secure channel keys for encryption and authentication from "Ses" and "ShsMAC.Wallet". The secure channel key may be represented as "SCkey". As an example, the secure channel key may be generated based on the CMAC algorithm. For example, the secure channel key may be generated based on "CMAC (Ses, ShsMAC.Wallet, Context)".

[0465] In operation 7 , the UE 1402 (or the payment application) may send “ePK.Wallet” and “ShsMAC.Wallet” to the payment terminal 1401 .

[0466] In operation 8, the payment terminal 1401 may derive Ses from the received "ePK.Wallet". For example, Ses may include "ePK.Terminal" and "eSK.Wallet".

[0467] In addition, the payment terminal 1401 can derive security keys for encryption and authentication. As an example, a secure channel key can be generated based on a CMAC algorithm. For example, a secure channel key can be generated based on “CMAC (Ses, ShsMAC.Wallet, Context)”.

[0468] Therefore, a secure channel can be established. In the subsequent process, UE 1402 and payment terminal 1401 can send data through the established secure channel.

[0469] The secure channel established by performing operations up to operation 8 may be a semi-authenticated channel. That is, only the payment terminal 1401 has completed authentication for the secure channel. In order for the secure channel to be fully authenticated, that is, in order to authenticate the UE 1402 (or the payment application), subsequent operations 9 and 10 may be further performed.

[0470] Furthermore, the secure channel may be a semi-trusted channel, where the credentials are protected with a temporary key.

[0471] In operation 9, UE 1402 (or payment application) may send a certificate of the payment application ("Cert.Wallet") including the ID of the payment application and / or the ID of the UE to the payment terminal 1401 through the established secure channel. "Cert.Wallet" includes personal information, such as the ID of the payment application and the ID of the UE, so that in order to protect the personal information, "Cert.Wallet" may be sent through the established secure channel instead of before the secure channel is established.

[0472] In operation 10, the payment terminal 1401 may verify "Cert.Wallet". The payment terminal 1401 may extract the static public key from "Cert.Wallet". The payment terminal 1401 may derive "Shs", derive "ShsMAC.Wallet" from "Shs", and compare the derived "ShsMAC.Wallet" with the "ShsMAC.Wallet" received in operation 7.

[0473] As an example, “ShsMAC.Wallet” may be generated based on a cipher-based message authentication code (CMAC) algorithm. For example, “ShsMAC.Wallet” may be generated based on “CMAC (Shs, ePK.Terminal, context)”.

[0474] If the two "ShsMAC.Wallet" do not have the same value, the payment terminal 1401 may discard all previous messages and terminate the session. If the two "ShsMAC.Wallet" have the same value, the authentication of the UE (or payment application) may be completed.

[0475] In an embodiment, the payment terminal 1401 may send the transaction information after operation 9. For example, the payment terminal 1401 may send the transaction information after operation 9 and before operation 10. For example, the payment terminal 1401 may send the transaction information after operation 10. In an embodiment, the transaction information may include information about a merchant name associated with the payment terminal 1401 and / or amount information.

[0476] In an embodiment, after receiving the transaction information, the UE 1402 (or the payment application) may send the payment information to the payment terminal 1401. For example, the UE 1402 (or the payment application) may send the payment information after operation 10. As an embodiment, the payment information may include information about a card number (or token).

[0477] In operation 11, the payment terminal 1401 may send a result to the UE 1402 (or a payment application). As an example, the result may include an indication Fig.10 Information and instructions about authentication failure Fig.10 Information, instructions that the authentication failed and therefore the payment was not approved Fig.10 Information or indication that authentication has been successful Fig.10 Information that the authentication has been successful and therefore the final payment has been approved.

[0478] Fig.15 A UWB device including a security component according to an embodiment of the present disclosure is shown.

[0479] For example, Fig.15 A UWB device can be Figure 2B Examples of UWB devices.

[0480] refer to Fig.15 , UWB device 1500 may include a security element 1510. Security element 1510 may be Figure 2B An example of a secure element 214b-1.

[0481] The security element 1510 may include at least one applet. For example, it may include a payment service based on UWB (e.g., Fig. 9 Payment service) payment applet 1511.

[0482] As an example, the payment applet 1511 may include data / information for UWB-based payment. For example, the payment applet 1511 may include data / information (eg, payment information or transaction information) for a payment transaction.

[0483] As an embodiment, the data of the applet may be sent through an application protocol data unit (APDU).For example, the data of the payment applet 1511 may be sent by being included in an APDU called a payment transaction data APDU.

[0484] As an example, the payment applet 1511 may send the data of the payment applet 1511 (or the payment transaction data APDU) to the UWBS 1520 through an API defined / configured between the UWBS 1520 and the payment applet 1511 .

[0485] For example, Fig.15 As shown, the SUS internal API as an interface between the applet and the SUS applet and the SUS external API as an interface between the SUS applet and the USBS 1520 may be used only to send data such as a ranging data set (RDS) for generating a UWB session (e.g., a UWB session key and a UWB session ID), and may not be used to send data of an applet such as the payment applet 1511. In this case, the data of the payment applet 1511 cannot be sent to the UWBS 1520 through the SUS internal API and the SUS external API.

[0486] Therefore, a separate API needs to be defined / configured between UWBS 1520 and payment applet 1511 , and payment applet 1511 may send data of payment applet 1511 to UWBS 1520 through the API defined / configured between UWBS 1520 and payment applet 1511 .

[0487] Fig.16 A UWB device including a security component according to an embodiment of the present disclosure is shown.

[0488] Fig.16 A UWB device can be, for example, Figure 2B Examples of UWB devices.

[0489] refer to Fig.16 , UWB device 1600 may include a security element 1610. Security element 1610 may be Figure 2BAn example of a secure element 214b-1.

[0490] The security element 1610 may include at least one applet. For example, it may include a payment service based on UWB (e.g., Fig. 9 Payment service)’s payment applet 1611.

[0491] As an example, the payment applet 1611 may include data / information for UWB-based payment. For example, the payment applet 1611 may include data / information (eg, payment information or transaction information) for a payment transaction.

[0492] As an embodiment, the data of the applet may be sent through an application protocol data unit (APDU).For example, the data of the payment applet 1611 may be sent by being included in an APDU called a payment transaction data APDU.

[0493] As an example, the payment applet 1611 may send the data of the payment applet 1511 (or the payment transaction data APDU) to the UWBS 1520 through the extended SUS internal API 1630 and the extended SUS external API 1640 .

[0494] and Fig.15 The embodiments are different. Fig.16 In an embodiment, the SUS internal API 1630 and the SUS external API 1640 may be extended and used to send not only the RDS but also the data of the payment applet 1611 (or the payment transaction data APDU).

[0495] Fig.17 A method of transmitting data in a secure component of a UWB device to a UWBS according to an embodiment of the present disclosure is shown.

[0496] exist Fig.17 In the embodiment, Fig.17 A UWB device can be e.g. Figure 2B Examples of UWB devices.

[0497] refer to Fig.17 , the UWB device may include a security element 1710. The security element 1710 may be Figure 2B An example of a secure element 214b-1.

[0498] The security element 1710 may include at least one applet. For example, the security element 1710 may include a FiRa applet that provides a range data set (RDS) for secure ranging. In addition, a payment service based on UWB (e.g., Fig. 9 Payment service)’s payment applet 1711.

[0499] As an example, the payment applet 1711 can be accessed through an extended SUS external API (e.g., Fig.16 The payment applet 1711 can also interface with UWBS based on the extended SUS external API 1640. Fig.16 The Secure UWB Services applet (SUS applet) interfaces with the UWBS through the extended SUS internal API 1630 through the extended SUS external API 1640 .

[0500] The data (or payment transaction data APDU) transmitted to the payment applet 1711 of the UWBS through the extended SUS external API may be transmitted to the MAC layer through the link layer (LL).

[0501] The data of the payment applet 1711 (or the payment transaction data APDU) can be processed in a connection-oriented mode according to the pre-configured transmission mode of the link layer (e.g., a connection-oriented mode) and sent to the MAC layer. The payment applet 1711 can transmit or process data according to the payment transaction protocol defined by EMVCo. For data sent and received by the payment applet 1711, a data transmission technology based on a connection-oriented mode of the link layer (LL) can be used. According to the transmission technology based on the connection-oriented mode, the payment applet 1711 can send payment data by specifying the destination as the payment applet on the other device side with which the communication for payment is performed. In addition, through the data transmission technology based on the connection-oriented mode, functions such as timeout, retransmission, and payment data segmentation / reassembly can be performed.

[0502] Fig.18 The RDS components supported in the SUS API according to an embodiment of the present disclosure are shown.

[0503] Specifically, Fig.18 are some examples of ranging data set (RDS) configurations provided in the SUS internal API. The SUS internal API is an API between the key exchange applet in the secure element 1610 and the SUS applet. The key exchange applet is Fig.18 The tag length value (TLV) format shown in the figure configures the ranging data set (RDS) and transmits it to the SUS applet through the SUS internal API. Fig.18 , shows some embodiments, including APDU (payment transaction data APDU) as one of the RDS components supported by SUSAPI (SUS internal API and / or SUS external API) for transmitting payment transaction data. In an embodiment, payment transaction data as payment related data defined by EMVCo can be identified by tag number 0xXX and transmitted as one of the RDS components. According to Fig.18 , payment transaction data can be transferred from the payment applet to the SUS applet through the RDS transfer scheme supported by the extended SUS internal API, and transferred to the UWBS through the extended SUS external API.

[0504] Although not shown in the accompanying drawings, payment transaction data can also be transmitted through a separate APDU. In this case, the extended SUS internal API can be extended to be used to transmit data APDUs including payment transaction data. In addition, the extended SUS external API can be extended to be used to transmit data APDUs including payment transaction data. In this case, the APDU commands for transmitting payment transaction data APDUs can be GET DATA and STOREDATA defined in the global platform card specification.

[0505] Fig.19A A data transmission process using UWB according to an embodiment of the present disclosure is shown.

[0506] Fig.19A The data transmission process may be a process for transmitting a data message (DM) (data frame) instead of a ranging message (RFRAME). As an example, the data message may include transaction information and / or payment information, such as for a UWB-based payment service.

[0507] exist Fig.19A In the embodiment of the present invention, it is assumed that the first UWB device 1901 is configured to be used as an initiator device and a controller of device type, and the second UWB device 1902 is configured to be used as a responder device and a controller of device type. According to the embodiment, the first UWB device 1901 may be a payment terminal 901 or a UE 902.

[0508] refer to Fig.19A , the first UWB device 1901 may transmit a data transmission phase control message (DTPCM) 1910 for configuring a data transmission phase. According to an embodiment, the payment terminal 901 may be the first UWB device 1901, and transmit the data transmission phase control message (DPTCM) to the UE 902 which is the second UWB device 1902, and the UE 902 may transmit the user information 903 to the payment terminal 901 based on the scheduling information of the data transmission phase control message (DTPCM). The UE 901 may identify a ranging time slot for receiving the payment terminal information 920 or the payment information 940 sent by the payment terminal 901 based on the data transmission phase control message (DTPCM). As an example, the first UWB device 1901 may configure the DTPCM based on the application data transmitted from the upper layer. Referring to FIG. 10A and FIG. 10B , the first UWB device 1901 may configure the DTPCM based on the application data transmitted from the upper layer. FIG. 20A to FIG. 20C An example of DTPCM 1910 is described below.

[0509] The first UWB device 1901 may transmit at least one DM. For example, as shown, the first UWB device 1901 may transmit three DMs 1920-1, 1920-2, and 1920-3. As an embodiment, the first UWB device 1901 may transmit the DM in the ranging slot allocated by the DTPCM 1910. As an example, the first UWB device 1901 may configure the DM based on the application data transmitted from the upper layer. As an embodiment, the second UWB device 1901 may transmit the application data in the DM received from the first UWB device 1901 to the upper layer.

[0510] The second UWB device 1902 may transmit at least one DM. For example, as shown, the second UWB device 1902 may transmit one DM 1930. As an embodiment, the second UWB device 1902 may transmit the DM in the ranging slot allocated by the DTPCM 1910. As an example, the second UWB device 1902 may configure the DM based on the application data transmitted from the upper layer. As an embodiment, the first UWB device 1901 may transmit the application data in the DM received from the second UWB device 1902 to the upper layer.

[0511] Fig.19B is a diagram illustrating an embodiment of exchanging data when contention-based ranging is performed between a first UWB device (merchant device) and a plurality of second UWB devices (client devices).

[0512] exist Fig.19B In the embodiment, the first UWB device may correspond to a merchant device or a payment terminal. According to stage 5 of the accompanying drawings, the payment terminal may transmit a contention-based ranging start message to a nearby UE. The contention-based ranging start message may include a contention-based ranging control message. The contention-based ranging start message and the DM payload IE may be combined and sent. Stage 5 may be Fig. 9 A partial implementation example of the payment terminal information transmission stage 920.

[0513] exist Fig.19B In stage 6, the UE may transmit a contention-based ranging response message to the payment terminal. The UE may combine the contention-based ranging response message with the DM payload IE and transmit them. In this case, user information in the content field of the DM payload IE combined with the contention-based ranging response message may be transmitted. Stage 6 may be Fig. 9 A partial implementation example of the user information transmission stage 930.

[0514] When contention-based ranging is two-sided bidirectional ranging, it can be additionally performed Fig.19B Stage 7 and Stage 8.

[0515] As Fig.19B As a result of stage 6 or stage 8, the payment terminal may discover a nearby UE. In this case, the payment terminal may measure the distance between the payment terminal itself and the discovered nearby UE. In addition, in stage 6, when the discovered nearby UE sends a response message including user information, the payment terminal may additionally obtain the user information.

[0516] exist Fig.19B In stage 9 of the present invention, the payment terminal may select one of the discovered UEs and send a connection request message. The connection request message may be included in the payload of the DM Payload IE combined with the contention-based initiation message so as to be transmitted. The connection request message may be configured according to a TLV (type-length-value or tag-length-value) structure. The connection request message may include data in a TLV format having a type or tag value indicating the connection request.

[0517] [Table 10]

[0518] When the payment terminal sends a connection request message, a random challenge (pos challenge) of the payment terminal may be additionally included and sent. In this case, the payment terminal may connect the data in the TLV format corresponding to the connection request and the data in the TLV format corresponding to the random challenge (pos challenge) of the payment terminal, and include the connected data in the payload of the DM payload IE so as to send it to the UE that desires to be connected.

[0519] exist Fig.19B In stage 12 of the present invention, the UE that has received the connection request message may add a connection approval message or a connection rejection message to the payload of the DM payload IE combined with the contention-based ranging response message and transmit it to the payment terminal. The connection approval message or the connection rejection message may be configured according to a TLV (type length value or tag length value) structure. The connection approval message and the connection rejection message may include data in a TLV format having a type or tag value indicating connection approval and connection rejection, respectively.

[0520] [Table 11]

[0521] When approving the connection, the UE may additionally send a UserChallenge value. In this case, a TLV structure indicating connection approval and a TLV structure indicating user challenge may be concatenated and included in the payload of the DM Payload IE and sent from the UE to the payment terminal.

[0522] In the above stage, the random challenge (posChallenge) of the payment terminal and the random challenge (userChallenge) of the UE exchanged between the UE and the payment terminal may also be used as Fig.14 The random challenge used in the mutual authentication performed between the UE and the payment terminal in the DM Payload IE. In this case, the random challenge may be a value used in a secure channel protocol, such as SCP03 and SCP11 of a global platform that are commonly used security protocols. In the payload of the DM Payload IE that is combined with the ranging message of the contention-based ranging and transmitted, the payment terminal and the UE may use the random challenge of the payment terminal and the random challenge of the UE, respectively, as part of data for generating a signature for mutual authentication to enhance security.

[0523] Fig. 20A A UWB message for data transmission according to an embodiment of the present disclosure is shown.

[0524] Used for Fig. 20A The UWB message for data transmission may be an example of DM or DTPCM of FIG. 19 .

[0525] refer to Fig. 20A , a UWB message (data frame) for data transmission may include a UWB message ID field, a data transmission content type field, and / or a content field. For example, a UWB message (data frame) for data transmission may have a payload IE including a UWB message ID field, a data transmission content type field, and / or a content field.

[0526] If the UWB message is DM or DTPCM, the UWB ID field may be configured to specify a value of the data message (DM).

[0527] The data transmission content type field may specify the type of the content field. As an example, the data transmission content type field may be configured as a first value indicating that the type of the content field is a payload type, or a second value indicating that the type of the content field is a DTPCM type. For example, if the UWB message is DTPCM, the data transmission content type field may be configured as a second value indicating that the type of the content field is a DTPCM type. In this case, the following reference Fig. 20B and Fig. 20C to describe an example of the content field.

[0528] The content field may include a payload (payload data) associated with the data transfer content type field.

[0529] Fig. 20B and Fig. 20CAn example of the content field of a UWB message used for data transmission according to an embodiment of the present disclosure is shown.

[0530] refer to Fig. 20B , when the data transmission content type field is configured as a second value indicating that the type of the content field is a DTPCM type (ie, when the UWB message is DTPCM), the content field may include a data transmission phase management list (DTPML) length field and / or a DTPML list field.

[0531] The DTPML length field may specify the length of the DTPML list field. The DTPML length may be the number of UWB UEs participating in a data transmission session for data transmission. For example, when two devices, a payment terminal and a UE, participate in a data transmission session for data transmission, the value of the DTPML length field may be 2.

[0532] The DTPML List field may include as many Data Transfer Phase Management Entries as the number specified by the DTPML Length field. Fig. 20C Describes an example of management entries for the data transfer phase.

[0533] refer to Fig. 20C The data transmission phase management entry may include a MAC address field, a time slot bitmap field and / or a stop data transmission time slot field.

[0534] The MAC address field may specify the MAC address of a transmitting data transmission device for which the time slot allocation configured by the time slot bitmap field is used.

[0535] The Slot Bitmap field may provide a time slot allocation for the device identified by the MAC Address field. The Slot Bitmap field may include a time slot bitmap. Each bit in the time slot bitmap may represent a time slot index.

[0536] For example, the slot bitmap field may have a size of 64 bits. In this case, bit 0 represents a slot index corresponding to the current slot+1, ..., and bit 63 represents a slot index corresponding to the current slot+63.

[0537] As an example, when the value of the corresponding bit in the time slot bitmap is configured as 1, this may indicate that the corresponding time slot is used by the device identified by the MAC address field. Alternatively, when the value of the corresponding bit in the time slot bitmap is configured as 0, this may indicate that the corresponding time slot is not used by the device identified by the MAC address field.

[0538] The stop data transmission time slot field may be configured as a first value indicating that data transmission is to be stopped or a second value indicating that data transmission is to be continued.

[0539] Fig.21 The structure of a first UWB device according to an embodiment of the present disclosure is shown.

[0540] exist Fig.21 In an embodiment of the present invention, the first UWB device may be a device corresponding to Figure 1 An electronic device comprising a UWB device, a UWB device, or a portion of a UWB device. The first UWB device may be, for example, an anchor (eg, an initiator anchor / responder anchor) for a UWB-based payment service.

[0541] refer to Fig.21 , the first UWB device may include a transceiver 2110, a controller 2120, and a storage unit 2130. In the present disclosure, the controller may be defined as a circuit, an application specific integrated circuit, or at least one processor.

[0542] The transceiver 2110 may transmit a signal to another entity or receive a signal from another entity.

[0543] The controller 2120 may control the overall operation of the electronic device according to the embodiment proposed in the present disclosure. For example, the controller 2120 may control the signal flow between the various blocks to perform the operations according to the above flowchart. Specifically, the controller 2120 may control, for example, the reference Figures 1 to 20C as well as Fig.23 Operation of a first UWB device (eg, operation of an anchor for a UWB-based payment service) is described.

[0544] The storage unit 2130 may store at least one of information transmitted or received by the transceiver 2110 and information generated by the controller 2120. For example, the storage unit 2130 may store a reference Figures 1 to 20C as well as Fig.23 Describe the information and data required for the method.

[0545] Fig. 22 The structure of a second UWB device according to an embodiment of the present disclosure is shown.

[0546] exist Fig. 22 In the embodiment of the present invention, the second UWB device may be a device corresponding to Figure 1 The second UWB device may be, for example, a UE for a UWB-based payment service.

[0547] refer to Fig. 22 , the second UWB device may include a transceiver 2210, a controller 2220, and a storage unit 2230. In the present disclosure, the controller may be defined as a circuit, an application specific integrated circuit, or at least one processor.

[0548] The transceiver 2210 may transmit a signal to another entity or receive a signal from another entity.

[0549] The controller 2220 may control the overall operation of the electronic device according to the embodiment proposed in the present disclosure. For example, the controller 2220 may control the signal flow between the various blocks to perform the operations according to the above flowchart. Specifically, the controller 2220 may control, for example, the reference Figures 1 to 20C as well as Fig.23 The operation of the second UWB device (eg, the operation of a UE for a UWB-based payment service) is described.

[0550] As an embodiment, the controller 2220 can be configured to receive a first UWB message for initiating a ranging process from an initiator anchor; receive multiple second UWB messages sent in response to the first UWB message from multiple responder anchors; receive a third UWB message sent in response to the second UWB message from the initiator anchor; and perform DL-TDoA based positioning based on the first UWB message, the second UWB message and the third UWB message.

[0551] As an embodiment, the first UWB message may include first information for DL-TDoA and second information for contention-based ranging.

[0552] As an embodiment, the first information for DL-TDoA may include a random number generated by the initiator anchor for mutual authentication.

[0553] As an embodiment, the second information for contention-based ranging may include information specifying a size of a contention access time period.

[0554] As an embodiment, the controller 2220 may select an anchor among an initiator anchor and a plurality of responder anchors based on the result of the DL-TDoA based positioning.

[0555] As an embodiment, the controller 2220 may transmit a ranging response message for SS-TWR to one anchor selected from the initiator anchor and a plurality of responder anchors in any time slot in the contention access period.

[0556] As an embodiment, the ranging response message for SS-TWR may include a random number generated by the UWB device for mutual authentication between the UWB device and the selected anchor.

[0557] As an embodiment, in the UWB device, the controller 2220 is further configured to obtain the user's intention by measuring the AoA value of the third UWB message.

[0558] The storage unit 2230 may store at least one of information transmitted or received by the transceiver 2210 and information generated by the controller 2220. For example, the storage unit 2230 may store a reference Figures 1 to 20C as well as Fig.23 Describe the information and data required for the method.

[0559] In the above specific embodiments of the present disclosure, the elements included in the present disclosure are expressed in the singular or plural, depending on the specific embodiments proposed. However, for the convenience of description, the singular form or the plural form is appropriately selected according to the proposed situation, and the present disclosure is not limited to the elements expressed in the singular or plural. Therefore, the elements expressed in the plural may also include a single element, or the elements expressed in the singular may also include multiple elements.

[0560] Although specific embodiments have been described in the detailed description of the present disclosure, it is apparent that various modifications and changes may be made thereto without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the embodiments described herein, but should be limited by the appended claims and their equivalents.

Claims

1. A method for a UWB device, the method comprising: receiving a first UWB message from an initiator anchor for initiating a ranging process; receiving, from a plurality of responder anchors, a plurality of second UWB messages sent in response to the first UWB message; receiving, from the initiator anchor, a third UWB message sent in response to the second UWB message; and DL-TDoA based positioning is performed based on the first UWB message, the second UWB message, and the third UWB message.

2. The method according to claim 1, wherein: The first UWB message includes first information for DL-TDoA and second information for contention-based ranging.

3. The method according to claim 2, wherein: The first information for DL-TDoA includes a random number for mutual authentication, the random number being generated by the initiator anchor.

4. The method according to claim 2, wherein: The second information for contention-based ranging includes information specifying a size of a contention access time period.

5. The method according to claim 4, further comprising: Based on a result of the DL-TDoA based positioning, an anchor is selected from the initiator anchor and the plurality of responder anchors.

6. The method according to claim 5, further comprising: transmitting a ranging response message for SS-TWR to the one anchor selected from the initiator anchor and the plurality of responder anchors in any time slot in the contention access time period, The ranging response message for SS-TWR includes a random number used for mutual authentication between the UWB device and the selected anchor, and the random number is generated by the UWB device.

7. The method according to claim 1, further comprising: The user's intention is obtained by measuring the AoA value of the third UWB message.

8. A UWB device, comprising: Transceiver; as well as A controller, connected to the transceiver, Wherein, the controller is configured as: receiving a first UWB message from an initiator anchor for initiating a ranging process; receiving, from a plurality of responder anchors, a plurality of second UWB messages sent in response to the first UWB message; receiving, from the initiator anchor, a third UWB message sent in response to the second UWB message; and DL-TDoA based positioning is performed based on the first UWB message, the second UWB message, and the third UWB message.

9. The device according to claim 8, wherein: The first UWB message includes first information for DL-TDoA and second information for contention-based ranging.

10. The device according to claim 9, wherein: The first information for DL-TDoA includes a random number for mutual authentication, the random number being generated by the initiator anchor.

11. The device according to claim 9, wherein: The second information for contention-based ranging includes information specifying a size of a contention access time period.

12. The device according to claim 11, wherein The controller is further configured to select an anchor among the initiator anchor and the plurality of responder anchors based on a result of the DL-TDoA based positioning.

13. The device according to claim 12, wherein: The controller is further configured to: transmit a ranging response message for SS-TWR to the one anchor selected from the initiator anchor and the plurality of responder anchors in any time slot in the contention access time period, The ranging response message for SS-TWR includes a random number used for mutual authentication between the UWB device and the selected anchor, and the random number is generated by the UWB device.

14. The apparatus according to claim 8, wherein: The controller is further configured to obtain the user's intention by measuring an AoA value of the third UWB message.

Images