KR20240008206A - Method and apparatus for providing service using uwb (ultra wide band) communication - Google Patents

Abstract

This disclosure discloses a method of providing services using UWB communication. The method of the UWB device includes receiving, from an initiator anchor, a first UWB message that initiates a ranging procedure; receiving, from a plurality of responder anchors, a plurality of second UWB messages transmitted in response to the first UWB message; Receiving, from the Initiator anchor, a third UWB message transmitted in response to the second UWB message, based on the first UWB message, the second UWB message, and the third UWB message, DL- It may include the step of performing TDoA-based localization.

Description

Method and device for providing services using UWB communication {METHOD AND APPARATUS FOR PROVIDING SERVICE USING UWB (ULTRA WIDE BAND) COMMUNICATION}

This disclosure relates to UWB communication, and more specifically, to a method and device for providing services using UWB communication.

The Internet is evolving from a human-centered network where humans create and consume information to an IoT (Internet of Things) network that exchanges and processes information between distributed components such as objects. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technology through connection to cloud servers, etc., is also emerging. To implement IoT, technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required. Recently, technologies such as sensor network, Machine to Machine (M2M), and MTC (Machine Type Communication) for connection between objects are being researched.

In an IoT environment, intelligent IT (Internet Technology) services that create new value in human life can be provided by collecting and analyzing data generated from connected objects. IoT, through the convergence and combination of existing IT (information technology) technology and various industries, includes smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart home appliances, advanced medical services, etc. It can be applied in the field of

With the development of wireless communication systems, various services can be provided, and there is a need for methods to effectively provide these services. For example, ranging technology that measures the distance between electronic devices using UWB (Ultra Wide Band) may be used.

This disclosure discloses a method of providing a service (eg, payment service) using UWB communication.

A method of a UWB device according to an embodiment of the present disclosure includes receiving, from an initiator anchor, a first UWB message initiating a ranging procedure; Receiving, from a plurality of responder anchors, a plurality of second UWB messages transmitted in response to the first UWB message; Receiving, from the initiator anchor, a third UWB message transmitted in response to the second UWB message; and performing DL-TDoA-based localization based on the first UWB message, the second UWB message, and the third UWB message.

A UWB device according to an embodiment of the present disclosure includes a transceiver; and a control unit connected to the transceiver, wherein the control unit: receives a first UWB message initiating a ranging procedure from an initiator anchor, and receives a plurality of signals transmitted in response to the first UWB message from a plurality of responder anchors. Receive a second UWB message, receive, from the Initiator anchor, a third UWB message transmitted in response to the second UWB message, and respond to the first UWB message, the second UWB message, and the third UWB message. Based on this, it can be configured to perform DL-TDoA-based localization.

1 illustrates an example architecture of a UWB device according to one embodiment of the present disclosure.
FIG. 2A shows an example configuration of a communication system including an electronic device supporting UWB-based services according to an embodiment of the present disclosure.
FIG. 2B shows 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.
Figure 3 shows an example configuration of a framework included in an electronic device supporting UWB-based services according to an embodiment of the present disclosure.
Figure 4 shows the structure of a UWB MAC frame according to an embodiment of the present disclosure.
Figure 5 shows the structure of a UWB PHY packet according to an embodiment of the present disclosure.
FIG. 6A shows an example of a ranging block structure according to an embodiment of the present disclosure.
Figure 6b shows an example of a ranging round according to an embodiment of the present disclosure.
Figure 7 shows various examples of a UWB ranging method according to an embodiment of the present disclosure.
Figure 8a shows a method in which a UWB device performs DL-TDoA UWB ranging according to an embodiment of the present disclosure.
Figure 8b shows an example of a ranging block structure for a downlink TDoA method according to an embodiment of the present disclosure.
Figure 9 shows a payment processing method using UWB according to an embodiment of the present disclosure.
Figure 10 shows a method in which a UWB device performs DL-TDoA ranging and contention-based ranging together according to an embodiment of the present disclosure.
Figure 11 shows a method in which a UWB device performs DL-TDoA ranging and contention-based ranging together according to an embodiment of the present disclosure.
Figure 12a shows the structure of a UWB message according to an embodiment of the present disclosure.
Figure 12b shows the payload structure of a UWB message according to an embodiment of the present disclosure.
Figure 12c shows the payload structure of a UWB message according to an embodiment of the present disclosure.
13A and 13B show an example of an OWR message type-dependent payload field included in a UWB message, according to an embodiment of the present disclosure.
Figure 14 shows a method for creating a secure channel according to an embodiment of the present disclosure.
Figure 15 shows a UWB device including a security component, according to one embodiment of the present disclosure.
Figure 16 shows a UWB device including a security component, according to one embodiment of the present disclosure.
Figure 17 shows a method of transmitting data in a security component of a UWB device to UWBS according to an embodiment of the present disclosure.
Figure 18 shows the types of APDUs supported in the SUS API according to an embodiment of the present disclosure.
Figure 19 shows a data transmission procedure using UWB according to an embodiment of the present disclosure.
Figure 20a shows a UWB message for data transmission according to an embodiment of the present disclosure.
Figures 20b and 20c show an example of the Content field of a UWB message for data transmission according to an embodiment of the present disclosure.
Figure 21 shows the structure of a first UWB device, according to an embodiment of the present disclosure.
Figure 22 shows the structure of a second UWB device according to an embodiment of the present disclosure.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

In describing the embodiments, description of technical content that is well known in the technical field to which this disclosure belongs and that is not directly related to this disclosure will be omitted. This is to convey the gist of the present disclosure more clearly without obscuring it by omitting unnecessary explanation.

For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically shown. Additionally, the size of each component does not entirely reflect its actual size. In each drawing, identical or corresponding components are assigned the same reference numbers.

The advantages and features of the present disclosure and methods for achieving them will become clear by referring to the embodiments described in detail below along with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms, and the embodiments of the present disclosure are merely intended to ensure that the present disclosure is complete and that common knowledge in the technical field to which the present disclosure pertains is provided. It is provided to fully inform those who have the scope of the disclosure, and the disclosure is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagram diagrams can be performed by computer program instructions. These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flow chart block(s). It creates the means to perform functions. These computer program instructions may also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular manner, so that the computer-usable or computer-readable memory The instructions stored in may also be capable of producing manufactured items containing instruction means to perform the functions described in the flow diagram block(s). Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a process that is executed by the computer, thereby generating a process that is executed by the computer or other programmable data processing equipment. Instructions that perform processing equipment may also provide steps for executing the functions described in the flow diagram block(s).

Additionally, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). Additionally, it should be noted that in some alternative execution examples it is possible for the functions mentioned in the blocks to occur out of order. For example, it is possible for two blocks shown in succession to be performed substantially at the same time, or it may be possible for the blocks to be performed in reverse order depending on the corresponding function.

At this time, the term '~unit' used in this embodiment refers to software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and '~unit' performs certain roles. do. However, '~part' is not limited to software or hardware. The '~ part' may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Therefore, according to some embodiments, '~ part' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and processes. Includes scissors, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and 'parts' may be combined into a smaller number of components and 'parts' or may be further separated into additional components and 'parts'. Additionally, components and 'parts' may be implemented to regenerate one or more CPUs within a device or a secure multimedia card. Additionally, according to some embodiments, '~unit' may include one or more processors.

The term 'terminal' or 'device' used in this specification refers to a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, and subscriber unit. It may be referred to as a Subscriber Unit, a Subscriber Station (SS), a wireless device, a wireless communication device, a Wireless Transmit/Receive Unit (WTRU), a mobile node, a mobile, or other terms. . Various embodiments of the terminal include a cellular phone, a smart phone with a wireless communication function, a personal digital assistant (PDA) with a wireless communication function, a wireless modem, a portable computer with a wireless communication function, and a digital camera with a wireless communication function. It may include devices, gaming devices with wireless communication functions, music storage and playback home appliances with wireless communication functions, Internet home appliances capable of wireless Internet access and browsing, as well as portable units or terminals that integrate combinations of such functions. there is. Additionally, the terminal may include, but is not limited to, an M2M (Machine to Machine) terminal and an MTC (Machine Type Communication) terminal/device. In this specification, the terminal may be referred to as an electronic device or simply a device.

Hereinafter, the operating principle of the present disclosure will be described in detail with reference to the attached drawings. In the following description of the present disclosure, if a detailed description of a related known function or configuration is determined to unnecessarily obscure the gist of the present disclosure, the detailed description will be omitted. In addition, the terms described below are terms defined in consideration of the functions in the present disclosure, and may vary depending on the intention or custom of the user or operator. Therefore, the definition should be made based on the contents throughout this specification.

Hereinafter, embodiments of the present disclosure will be described in detail with the accompanying drawings. Hereinafter, embodiments of the present disclosure will be described using a communication system using UWB as an example, but embodiments of the present disclosure may also be applied to other communication systems with similar technical background or characteristics. For example, a communication system using Bluetooth or ZigBee may be included. Accordingly, the embodiments of the present disclosure may be applied to other communication systems through some modifications without significantly departing from the scope of the present disclosure at the discretion of a person with skilled technical knowledge.

Additionally, when describing the present disclosure, if it is determined that a detailed description of a related function or configuration may unnecessarily obscure the gist of the present disclosure, the detailed description will be omitted. In addition, the terms described below are terms defined in consideration of the functions in the present disclosure, and may vary depending on the intention or custom of the user or operator. Therefore, the definition should be made based on the contents throughout this specification.

In general, wireless sensor network technology is largely divided into wireless LAN (Wireless Local Area Network; WLAN) technology and wireless personal area network (WPAN) technology depending on recognition distance. At this time, wireless LAN is a technology based on IEEE 802.11 and is a technology that can connect to the backbone network within a radius of about 100m. Additionally, wireless private networks are technologies based on IEEE 802.15 and include Bluetooth, ZigBee, and ultra wide band (UWB). A wireless network in which this wireless network technology is implemented may be comprised of a plurality of electronic devices.

According to the definition of the Federal Communications Commission (FCC), UWB can refer to a wireless communication technology that uses a bandwidth of 500 MHz or more, or has a bandwidth of 20% or more corresponding to the center frequency. UWB may also refer to the band itself to which UWB communication is applied. UWB enables safe and accurate ranging between devices. Through this, UWB enables relative position estimation based on the distance between two devices or accurate position estimation of a device based on its distance from fixed devices (where the position is known).

Specific terms used in the following description are provided to aid understanding of the present disclosure, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present disclosure.

“Application Dedicated File (ADF)” may be, for example, a data structure within the Application Data Structure that can host an application or application specific data.

“Application Protocol Data Unit (APDU)” may be a command and response used when communicating with the Application Data Structure within a UWB device.

“Application specific data” may be, for example, a file structure with a root level and an application level containing UWB control information and UWB session data required for a UWB session.

“Controller” may be a Ranging Device that defines and controls Ranging Control Messages (RCM) (or control messages). The controller can define and control ranging features by transmitting a control message.

“Controlee” may be a ranging device that uses ranging parameters in the RCM (or control message) received from the controller. Controlee can use the same ranging features as set through control messages from Controller.

Unlike “Static STS,” “Dynamic STS (Scrambled Timestamp Sequence) mode” may be an operation mode in which STS is not repeated during a ranging session. In this mode, STS is managed by the ranging device, and the ranging session key that creates the STS can be managed by the Secure Component.

“Applet” may be, for example, an applet running on the Secure Component containing UWB parameters and service data. The Applet may be a FiRa Applet.

“Ranging Device” may be a device capable of performing UWB ranging. In this disclosure, the Ranging Device may be an Enhanced Ranging Device (ERDEV) or a FiRa Device defined in IEEE 802.15.4z. Ranging Device may be referred to as a UWB device.

“UWB-enabled Application” may be an application for UWB service. For example, a UWB-enabled Application may be an application that uses the Framework API to configure an OOB Connector, Secure Service, and/or UWB service for a UWB session. “UWB-enabled Application” may be abbreviated as application or UWB application. A UWB-enabled Application may be a FiRa-enabled Application.

“Framework” may be a component that provides access to the Profile, individual UWB settings, and/or notifications. The Framework may be a collection of logical software components, including, for example, Profile Manager, OOB Connector, Secure Service, and/or UWB Service. The Framework may be FiRa Framework.

“OOB Connector” may be a software component for establishing an out-of-band (OOB) connection (e.g., BLE connection) between Ranging Devices. The OOB Connector may be FiRa OOB Connector.

“Profile” may be a predefined set of UWB and OOB configuration parameters. The Profile may be a FiRa Profile.

“Profile Manager” may be a software component that implements profiles available on the Ranging Device. The Profile Manager may be FiRa Profile Manager.

“Service” may be the implementation of a use case that provides a service to an end-user.

“Smart Ranging Device” may be a ranging device that can implement an optional Framework API. The Smart Ranging Device may be a FiRa Smart Device.

“Global Dedicated File (GDF)” may be the root level of application specific data containing data required to establish a USB session.

“Framework API” may be an API used by a UWB-enabled Application to communicate with the Framework.

“Initiator” may be a Ranging Device that initiates a ranging exchange. The initiator can initiate a ranging exchange by sending the first RFRAME (Ranging Exchange Message).

“Object Identifier (OID)” may be an identifier of the ADF within the application data structure.

“Out-Of-Band (OOB)” is an underlying wireless technology and may be data communication that does not use UWB.

“Ranging Data Set (RDS)” may be data (e.g., UWB session key, session ID, etc.) required to establish a UWB session for which confidentiality, authenticity, and integrity need to be protected.

“Responder” may be a Ranging Device that responds to the Initiator in a ranging exchange. The Responder can respond to the ranging exchange message received from the Initiator.

“STS” may be an encrypted sequence to increase the integrity and accuracy of ranging measurement timestamps. STS can be generated from the ranging session key.

“Secure Channel” may be a data channel that prevents overhearing and tampering.

“Secure Component” is an entity (e.g., Secure Element (SE) or Trusted Execution Environment (TEE)) with a defined level of security that interfaces with the UWBS for the purpose of providing RDS to the UWBS, e.g., when dynamic STS is used. ) can be.

“SE” may be a tamper-resistant secure hardware component that can be used as a Secure Component in a Ranging Device.

“Secure Ranging” may be ranging based on an STS generated through strong encryption operations.

“Secure Service” may be a software component for interfacing with a Secure Component such as a Secure Element or TEE.

“Service Applet” may be an applet on the Secure Component that handles service-specific transactions.

“Service Data” may be data defined by the Service Provider that needs to be transferred between two ranging devices to implement a service.

“Service Provider” may be an entity that defines and provides hardware and software required to provide specific services to end-users.

“Static STS mode” is an operation mode in which STS repeats during a session and does not need to be managed by the Secure Component.

A “Secure UWB Service (SUS) Applet” may be an applet on the SE that communicates with the applet to retrieve data needed to enable a secure UWB session with another ranging device. Additionally, SUS Applet can transmit the data (information) to UWBS.

“UWB Service” may be a software component that provides access to UWBS.

“UWB Session” may be the period from when the Controller and Controllee start communicating via UWB until they stop communicating. A UWB Session may include ranging, data forwarding, or both ranging/data forwarding.

“UWB Session ID” may be an ID (e.g., a 32-bit integer) that identifies the UWB Session, shared between the controller and the controller.

“UWB Session Key” may be a key used to protect the UWB Session. UWB Session Key can be used to create STS. The UWB Session Key may be UWB Ranging Session Key (URSK), and may be abbreviated as session key.

“UWB Subsystem (UWBS)” may be a hardware component that implements the UWB PHY and MAC layer (specification). UWBS can have an interface to the Framework and an interface to the Secure Component to retrieve the RDS.

*“UWB message” may be a message containing a payload IE (information element) transmitted by a UWB device (eg, ERDEV).

“Payload IE” may be an IE included in the MAC payload of a UWB MAC frame. The MAC payload may include one or multiple Payload IEs.

* “Scheduled based ranging” can be used for ranging rounds in which controllers are scheduled by the controller to transmit ranging frames (RFRAME) and/or measurement reports in different ranging slots. Scheduling-based ranging may also be referred to as time-scheduled ranging. The scheduling mode in which scheduling-based ranging is used may be referred to as time-scheduled mode.

“Contention based ranging” can be used when the controller does not know the MAC addresses of controllers participating in a UWB session (ranging session). In contention-based ranging, the controller may be the initiator and may perform ranging with other unknown UWB devices. The scheduling mode in which contention-based ranging is used may be referred to as Contention-based mode.

Contention-based ranging can be used for a ranging round in which the controller determines the size of the contention access period (CAP) and informs the CAP size through a ranging control message. CAP may be referred to as a contention window or contention window period.

In contention-based mode, the UWB device can operate as a controller and initiator, in which case the ranging control phase (RCP) and ranging initiation phase (RIP) are performed in one step (e.g. , RIP). In the ranging phase (RP), the allocation of CAP size can determine the CAP period for the responder(s) participating in the ranging round in units of ranging slots. Each responder can randomly determine a slot within the CAP to transmit a ranging response message (RRM). Messages used in contention-based ranging can use SP1 as the RFRAME setting.

“Hybrid ranging” can be used when there are known controls and unknown controls. As described above, a known control may be a control for which the controller knows the MAC address of the control, and an unknown control may be a control for which the controller does not know the MAC address of the control. Hybrid ranging may be referred to as hybrid-based ranging. The scheduling mode in which hybrid ranging is used may be referred to as Hybrid-based Mode.

In hybrid-based mode, the controller can perform ranging in a scheduling-based mode with known controls and in a contention-based mode with unknown controls.

In Hybrid-based Mode, a ranging round may include a ranging control phase (RCP) and a ranging phase (RP). The RP may include a contention free period (CFP) for scheduling-based ranging (access) and a contention access period (CAP) for contention-based ranging (access). The control message (ranging control message) used in RCP in hybrid-based mode may be referred to as a ranging management message (RMM).

* “Downlink Time Difference of Arrival (DL-TDoA: DT)” is based on the DL-TDoA message (DTM) received by one or more tag devices (DT-Tag) from at least one anchor device (DT-anchor) This may be a positioning method that estimates one's location. In DL-TDoA, the anchor device transmits or broadcasts the DTM, and the tag device passively receives the DTM, thereby preventing the location of the tag device from being exposed.

In DL-TDoA, the anchor device can precisely measure its own DTM transmission time and the reception time of the received DTM. The anchor device may include the transmission time in the DTM it transmits or broadcasts. The tag device can measure the reception time of all DTMs it receives and estimate its own location using the reception timestamp and the coordinates of the acquired anchor devices. DL-TDoA may be classified as a type of one way ranging, like Uplink TDoA. DL-TDoA may be referred to as DL-TDoA localization.

“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 an indoor wall, ceiling, or structure to provide an indoor positioning service. In DL-TDoA, an anchor device may be a device that transmits a DTM that a tag device can use to calculate location based on TDoA localization (DL-TDoA localization). In DL-TDoA, anchor devices are divided into Initiator anchors and Responder anchors depending on the order and role of transmitting messages and can participate in the ranging round. The anchor device may be referred to as a UWB anchor or UWB anchor device, and the anchor device of DL-TDoA may be referred to as a DL-TDoA anchor or DT-anchor.

“Initiator anchor” may announce the start of a TDoA ranging round (DL-TDoA ranging round). In DL-TDoA, the Initiator anchor can initiate a DL-TDoA ranging round by sending an initiation message and schedule the transmission time of the Responder anchor(s). For example, the Initiator anchor can schedule a ranging slot in which Responder anchor(s) operating in the same ranging round sends a response message (response DTM). The initiation message may be referred to as an Initiator DTM, Poll message, Poll DTM, first DTM, etc. The initiator anchor may be referred to as an initiator UWB anchor, an initiator anchor device, an initiator DT-anchor, etc.

The Initiator anchor may additionally deliver a final message (Final DTM) after receiving the response from the Responder anchor(s). The Initiator anchor can additionally transmit a Final DTM after all Responder anchors in the same cluster transmit a response message (response DTM) in the DL-TDoA ranging round. The termination message may be referred to as Final DTM, Third DTM, etc.

A DL-TDoA network may have at least one reference initiator anchor. Reference initiator anchor is an initiator anchor that serves as a global time reference for inter-cluster synchronization and can establish a common ranging block structure for the DL-TDoA network to operate. Reference initiator anchor may be referred to as master anchor or global anchor.

“Responder anchor” may be a UWB anchor that responds to the initiation message of the Initiator anchor. The Responder anchor can respond to the Initiator anchor using a response message. The response message may be referred to as Responder DTM, Response DTM, Second DTM, etc. Responder anchor may be referred to as Responder UWB anchor, Responder UWB anchor device, Responder anchor device, etc.

“Tag device” can estimate its own location (e.g., geographical coordinates) using TDoA measurements based on the DTM received from the anchor device in DL-TDoA. The tag device may know the location of the anchor device in advance. Tag devices may be referred to as UWB tags, user devices, and UWB tag devices, and DL-TDoA tag devices may be referred to as DL-TDoA Tags and DT-Tags.

The tag device can receive the message transmitted by the anchor device and measure the reception time of the message. The tag device can acquire the geographic coordinates of the anchor device through an in-band or out-band method. The tag device may skip the ranging block if the location update rate is lower than what is supported by the network.

“Cluster” may refer to a set of anchor devices covering a specific area. In DL-TDoA, a cluster may refer to a set of anchor devices that exchange DTM to provide location services to at least one tag device. A cluster may consist of an Initiator anchor and at least one Responder anchor.

One anchor device can operate in one or more clusters. In this case, an anchor device that operates as an Initiator anchor in some clusters may operate as a Responder anchor in other clusters. The area of the cluster may be a space formed by anchor devices constituting the cluster. To support positioning services for a wide area, multiple clusters can be configured to provide positioning services to user devices. A cluster may also be referred to as a cell.

Also, in describing the present disclosure, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the gist of the present disclosure, the detailed description will be omitted.

Hereinafter, various embodiments of the present disclosure will be described with reference to the attached drawings.

1 illustrates an example architecture of a UWB device according to one embodiment of the present disclosure.

The UWB device 100 may be an electronic device that supports UWB communication. For example, the UWB device 100 may be a ranging device that supports UWB ranging. In one embodiment, the Ranging Device may be an Enhanced Ranging Device (ERDEV) or FiRa Device defined in IEEE 802.15.4z.

In the embodiment of Figure 1, UWB device 100 can interact with other UWB devices through a UWB session.

Additionally, the UWB device 100 may implement a first interface (Interface #1), which is an interface between the UWB-enabled Application 110 and the UWB Framework 120, and the first interface may be implemented as a UWB-enabled interface on the UWB device 100. Allows application 110 to use the UWB capabilities of UWB device 100 in a predetermined manner. In one embodiment, the first interface may be a Framework API or a proprietary interface, but is not limited thereto.

Additionally, the UWB device 100 may implement a second interface (Interface #2), which is an interface between the UWB Framework 110 and the UWB subsystem (UWBS) 130. In one embodiment, the second interface may be, but is not limited to, UCI (UWB Command Interface) or a proprietary interface.

Referring to FIG. 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. there is. Depending on the embodiment, some entities may not be included in the UWB device, or additional entities (eg, security layer) may be further included.

The UWB-enabled Application 110 may trigger establishment of a UWB session by the UWBS 130 using the first interface. Additionally, the UWB-enabled Application 110 can use one of the predefined profiles. UWB-enabled Application 110 may use the first interface to handle related events such as service discovery, ranging notifications, and/or error conditions.

Framework 120 may provide access to Profile, individual UWB settings and/or notifications. Additionally, the Framework 120 may support at least one of the following functions: a function for UWB ranging and transaction performance, a function to provide an interface to an application and the UWBS 130, or a function to estimate the location of the device 100. Framework 120 may be a set 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.

Meanwhile, in the present disclosure, the UWB-enabled Application 110 and/or Framework 120 may be implemented by an application processor (AP) (or processor). Accordingly, in the present disclosure, the operation of the UWB-enabled Application 110 and/or Framework 120 may be understood as being performed by the AP (or processor). In this disclosure, the framework may be referred to as an AP or processor.

UWBS 130 may be a hardware component including a UWB MAC Layer and a UWB Physical Layer. UWBS 130 performs UWB session management and can communicate with UWBS of other UWB devices. UWBS 130 can interface with the Framework 120 through a second interface and obtain secure data from the Secure Component. In one embodiment, the Framework (or application processor) 120 may transmit a command to the UWBS 130 through UCI, and the UWBS 130 may send a response to the command to the Framework 120. It can be delivered to . UWBS 130 may deliver notification to Framework 120 through UCI.

FIG. 2A shows an example configuration of a communication system including an electronic device supporting UWB-based services according to an embodiment of the present disclosure.

Referring to FIG. 2A, the communication system 200 includes a first electronic device 210a and a second electronic device 220a.

As an example, the first electronic device 210a and the second electronic device 220a may be, for example, the UWB device of FIG. 1 or an electronic device including the UWB device of FIG. 1 . For example, the first electronic device 210a may be a Smart Ranging Device or a Ranging Device, and the second electronic device 220a may be a Ranging Device or a Ranging Device. As an example, the Smart Ranging Device or Ranging Device may be an Enhanced Ranging Device (ERDEV) or a FiRa Device defined in IEEE 802.15.4z. In FIG. 2A, 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.

The first electronic device 210a may host, for example, one or more UWB-enabled Applications that may be installed by a user (e.g., a mobile phone). This may be based on the Framework API. The second electronic device 220a does not provide a Framework API and, for example, may use a proprietary interface to implement a specific UWB-enabled application provided only by the manufacturer. Meanwhile, unlike what is shown, depending on the embodiment, both the first UWB device and the second UWB device may be Ranging Devices that use the Framework API, or both the first UWB device and the second UWB device may be Ranging Devices that use a proprietary interface. It may be possible.

The first electronic device 210a and the second electronic device 220a include UWB-enabled Application Layer (UWB-enabled Application) (211a, 221a), Framework (212a, 222a), and OOB component (OOB subsystem) (213a, 223a). ), Secure Component (214a, 224a), and/or UWBS (215a, 225a) may be included, respectively. Depending on the embodiment, some components may be omitted or additional components may be included.

The first electronic device 210a and the second electronic device 220a may create an OOB connection (channel) through the OOB components 213a and 223a and create a UWB connection (channel) through the UWBS 215a and 225a. By creating them, they can communicate with each other.

Frameworks 212a and 222a may be responsible for providing access to profiles, individual UWB settings, and/or notifications. Frameworks 212a and 222a are a set of software components and may include, for example, Profile Manager, OOB Connector, Secure Service, and/or UWB service.

The OOB components 213a and 223a may be hardware components including a MAC Layer and/Physical Layer for OOB communication (eg, BLE communication). OOB components 213a and 223a may communicate with OOB components of other devices. In one embodiment, the first UWB device 210a and the second UWB device 220a may create an OOB connection (channel) using the OOB components 213a and 223a, and establish a UWB session through the OOB channel. You can exchange parameters for: In this disclosure, OOB components 213a and 223a may be referred to as an OOB subsystem.

Secure Components 214a and 224a may be hardware components that interface with the framework and/or UWBS to provide RDS. As an example, the Secure Components 214a and 224a may be an SE (eg, eSE), a TEE (or a trusted application (TA) within a TEE), or a Strongbox (SB).

UWBS (215a, 225a) may be a hardware component including a UWB MAC Layer and UWB Physical Layer. UWBS (215a, 225a) performs UWB session management and can communicate with the UWBS of other UWB devices. In one embodiment, the first UWB device 210a and the second UWB device 220a transact UWB ranging and service data through a UWB session established through the UWBS 215a and 225a using parameters exchanged with each other. can be performed.

In the present disclosure, the UWB-enabled Application Layer and/or Framework may be implemented by an application processor (AP) (or processor). Accordingly, in the present disclosure, the operation of the UWB-enabled Application Layer and/or Framework may be understood as being performed by the AP (or processor).

FIG. 2B shows an example configuration of a communication system including an electronic device supporting UWB-based services according to an embodiment of the present disclosure.

The embodiment of FIG. 2B may be an example of the embodiment of FIG. 2A.

In the embodiment of FIG. 2B, the UWB-based service may be a UWB-based payment service (wallet service). In this 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 can be applied to other types of UWB-based services.

Referring to FIG. 2B, a communication system 200b that provides a UWB-based payment service may include a first electronic device 210b and a second electronic device 220b. In FIG. 2B, 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.

<First electronic device (210b)>

The first electronic device 210b may be a user's electronic device (eg, a user's mobile device) for a UWB-based payment service. The first electronic device 210b includes at least one UWB enabled Wallet Application (UWB enabled application) 211b-1, 211b-2, UWB enabled Wallet Framework (Framework) 212b, OOB component 213b, and at least one security It may include components 214b-1, 214b-2 and/or UWBS 215b. For a description of each component, refer to the description of FIG. 2A.

Meanwhile, in the embodiment of Figure 2b, for convenience of explanation, the UWB enabled application is described as corresponding to the UWB enabled Wallet Application, and the Framework is described as corresponding to the UWB enabled Wallet Framework, but the embodiment is not limited to this and various types of UWB Various UWB enabled applications and frameworks can be implemented to provide basic services. In Figure 2b, UWB enabled Wallet Application may be referred to as UWB enabled application, UWB enabled payment application, etc., and UWB enabled Wallet Framework may be referred to as UWB enabled payment framework, Framework, etc.

(1) UWB enabled application (211b-1, 211b-2) may support at least one of the following features.

- Hosting an applet (payment applet) for UWB-based payments within an SE (e.g., eSE (embedded SE)) or a Trusted Application (Trusted Payment Application) for UWB-based payments within a TEE

- When requested by the Framework, provide placement information and/or UWB block structure (e.g., ranging block structure) of anchors for estimating the location of the first electronic device.

- Communication with a second electronic device and back-end server for personalization of payment applet or Trusted Payment Application (TPA)

(2) Framework 212b can support at least one of the following features.

- Estimate the location of the first electronic device

- Implement UCI commands

- Provides a set of APIs for UWB enabled applications to access UWBS and OOB components.

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

- Implement OOB connection operation (e.g., BLE connection operation)

(4) Trusted Payment Application (211b-2) may be included within the TEE and may support at least one of the following features.

- Supports TEE Client API

- Implement Trusted Application

- Implements a secure channel protocol to communicate with a second electronic device in a secure manner.

- Host payment credentials and cryptographic keys for secure channels

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

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

- Support APDU

- Implements a secure channel protocol to communicate with a second electronic device in a secure manner.

- Host payment credentials and cryptographic keys for secure channels

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

Each component of the first electronic device 210b may communicate with other components through a predefined interface (IF). Below, each interface will be described.

- IF#1: 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 can be used to exchange UWB messages and/or payment transactions.

- IF#2: Interface between the OOB component 213b of the first electronic device 210b and the OOB component of another electronic device (e.g., the OOB component 222b of the second electronic device 220b). IF#2 can be used to exchange OOB messages.

- 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 (eg, UCI command/UCI notification, etc.) to establish a secure channel between the Trusted Payment Application (211b-2) and the UWBS (215b).

- IF#4: Interface between UWB enabled application (211b-2) and Trusted Payment Application (211b-2) within 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).

- IF#A: Interface between UWB enabled application (211b-1, 211b-2) and UWBS (215b). IF#A may be, for example, a SUS external API.

- IF#B: Interface between UWB enabled application (211b-2) and Payment Applet (214b-1) in SE (eSE). IF#B can be used to exchange APDUs through OMAPI (Object Management Application Programming Interface). For example, IF#B can be used to exchange APDUs to establish a secure channel between eSE and UWBS.

- IF#C: Interface between OOB component (213b) and Framework (212b) or UWB enabled application (211b-1, 211b-2). For example, IF#C may be HCI (Host Controller Interface).

- IF#D: Interface between UWB enabled application (211b-1, 211b-2) and Framework (212b). IF#D may be an API (Framework API) provided by the Framework 212b.

Meanwhile, although not shown in FIG. 2b, an interface between the TA (e.g., Trusted payment application) in the TEE (214b-2) and the UWBS (215b) will be set or defined for delivery of the RDS including the UWB session key. You can. In this case, to protect the interface between the TEE and the UWBS 215b, a secure channel may be established between the TA and the UWBS 215b. Additionally, it is possible to configure a new Driver TA and connect the TA and UWBS (215b) at the HW level.

<Second electronic device (220b)>

The second electronic device 220b may be an electronic device (eg, a payment terminal (eg, a retail Point of Service (PoS)) terminal) of a business operator for a UWB-based payment service. The second electronic device 220b may include a terminal application 221b, an OOB component 222b, and/or a UWBS 223b. As an example, the terminal application 221b may be a UWB enabled application.

Depending on the embodiment, not only the user device for the UWB-based payment service but also the payment terminal may have the same configuration as that of the first electronic device 220b.

Figure 3 shows an example configuration of a framework included in an electronic device supporting UWB-based services according to an embodiment of the present disclosure.

Framework 300 of FIG. 3 may be an example of the framework of FIGS. 2A and 2B. The framework 300 in FIG. 3 may be, for example, the FiRa Framework.

Framework 300 may be a set of logical software components. A UWB-enabled Application can interface with the framework through the framework API provided by the framework 300.

Referring to FIG. 3, the framework 300 may include Profile Manager 310, OOB Connector 320, Secure Service 330, and/or UWB Service 340. However, depending on the embodiment, some components may be omitted or additional components may be included.

The Profile Manager component 310 can manage Profile(s) available on the Ranging Device (UWB device). Profile may be a set of parameters required to establish a successful UWB session between Ranging Devices (UWB devices). For example, the profile may include parameters indicating which secure channel (e.g., OOB secure channel) is used, UWB/OOB configuration parameters, parameters indicating whether the use of a particular security component is mandatory, and/or a file in the ADF. It may contain parameters related to the structure. Additionally, Profile Manger can abstract UWB and OOB configuration parameters from UWB-enabled applications.

The OOB Connector component 320 may be a component for establishing OOB connections between Ranging Devices (UWB devices).

The Secure Service component 330 may play a role in interfacing with security components such as Secure Element (SE) or Trusted Execution Environment (TEE). The security component may be a component that interfaces with the UWBS to deliver UWB ranging data to the UWBS.

UWB Service component 340 may be a component that provides access to UWBS.

Figure 4 shows the structure of a UWB MAC frame according to an embodiment of the present disclosure.

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

Referring to FIG. 4, the UWB MAC frame may include a MAC header (MHR), MAC payload, and/or MAC footer (MFR).

(1) MAC header

The MAC header may include a Frame Control field, Sequence Number field, Destination Address field, Source Address field, Auxiliary Security Header field, and/or at least one Header IE field. Depending on the embodiment, some of the above-mentioned fields may not be included in the MAC header, and additional field(s) may be further included in the MAC header.

In one embodiment, the Frame Control field includes a Frame Type field, a Security Enabled field, a Frame Pending field, an AR field (Ack Request field), a PAN ID Compression field (PAN ID Present field), a Sequence Number Suppression field, an IE Present field, and a Destination field. It may include an Addressing Mode field, a Frame Version field, and/or a Source Addressing Mode field. Depending on the embodiment, some of the above-mentioned fields may not be included in the Frame Control field, and additional field(s) may be further included in the Frame Control field.

The description of each field is as follows.

The Frame Type field can indicate the type of frame. As an example, the type of frame may include data type and/or multipurpose type.

The Security Enabled field may indicate whether the Auxiliary Security Header field exists. The Auxiliary Security Header field may contain information required for security processing.

The Frame Pending field may indicate whether the device transmitting 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.

The AR field (Ack Request field) may indicate whether an acknowledgment of reception of the frame is required from the receiver.

The PAN ID Compression field (PAN ID Present field) may indicate whether the PAN ID field exists.

The Sequence Number Suppression field can indicate whether the Sequence Number field exists. The Sequence Number field may indicate a sequence identifier for the frame.

The IE Present field may indicate whether the Header IE field and Payload IE field are included in the frame.

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 can indicate the address of the recipient of the frame.

The Frame Version field can indicate the version of the frame. For example, the Frame Version field can be set to a value indicating IEEE std 802.15.4z-2020.

The Source Addressing Mode field indicates whether the Source Address field exists, and if the Source Address field exists, whether the Source Address field contains a short address (e.g., 16 bits) or an extended address (e.g., 64 bits). can do. The Source Address field can indicate the address of the originator of the frame.

(2) MAC payload

The MAC payload may include at least one Payload IE field. In one embodiment, the Payload IE field may include Vendor Specific Nested IE.

(3) MAC footer

The MAC footer may include an FCS field. The FCS field may include a 16-bit CRC or a 32-bit CRC.

Figure 5 shows the structure of a UWB PHY packet according to an embodiment of the present disclosure.

Part (a) of FIG. 5 shows an example structure of a UWB PHY packet to which STS packet settings are not applied, and part (b) of FIG. 4 shows an example structure of a UWB PHY packet to which STS packet settings are applied. UWB PHY packets may be referred to as PHY packets, PHY PDUs (PPDUs), and frames.

Referring to part (a) of FIG. 5, the PPDU may include a synchronization header (SHR), a PHY header (PHR), and a PHY payload (PSDU). The PSDU includes a MAC frame, and as shown in FIG. 4, the MAC frame may include a MAC header (MHR), MAC payload, and/or MAC footer (MFR). The synchronization header part may be referred to as a preamble, and the part including the PHY header and PHY payload may be referred to as the data part.

The synchronization header is used for synchronization for signal reception and may include a SYNC field and a start-of-frame delimiter (SFD).

The SYNC field may be a field containing a plurality of preamble symbols used for synchronization between transmitting and receiving devices. The preamble symbol can be set through one of predefined preamble codes.

The SFD field may be a field that indicates the end of the SHR and the start of the data field.

The PHY header may provide information about the composition 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), etc.

Meanwhile, the PHY layer of the UWB device may include an optional mode to provide reduced on-air time for high density/low power operation. In this case, the UWB PHY packet may include an encrypted sequence (i.e., STS) to increase the integrity and accuracy of the ranging measurement timestamp. STS may be included in the STS field of the UWB PHY packet and may be used for security ranging.

Referring to part (b) of FIG. 5, when the STS packet (SP) setting is 0 (SP0), the STS field is not included in the PPDU (SP0 packet). When SP setting is 1 (SP1), the STS field is located immediately after the SFD (Start of Frame Delimiter) field and before the PHR field (SP1 packet). For SP configuration 2 (SP2), the STS field is located after the PHY payload (SP2 packet). In case of SP setting 3 (SP3), the STS field is located immediately after the SFD field, and the PPDU does not include the PHR and data fields (PHY payload) (SP3 packet). That is, for SP3, the PPDU does not include PHR and PHY payload.

As shown in part (b) of Figure 5, each UWB PHY packet may include RMARKER for defining the reference time, and RMARKER is the transmission time, reception time, and reception time of the ranging message (frame) in the UWB ranging procedure. /Or may be used to obtain a time interval.

FIG. 6A shows an example of a ranging block structure according to an embodiment of the present disclosure. Figure 6b shows an example of a ranging round according to an embodiment of the present disclosure.

Referring to FIG. 6A, one ranging block includes at least one ranging round, and each ranging round may include at least one ranging slot. For example, as shown, one ranging block includes N ranging rounds (e.g., ranging round 0 to ranging round index N-1), and ranging round #0 is M ranging slots. (For example, ranging slot 0 to ranging slot M).

The ranging block refers to the time period for ranging. A ranging round is a period of sufficient duration to complete one entire ranging-measurement cycle (ranging cycle) involving a set of ranging devices participating in a ranging exchange. It can be. The ranging slot may be a sufficient period for transmission of at least one ranging frame (RFRAME) (eg, ranging start/response/final message, etc.).

Meanwhile, when the ranging mode is a block-based mode, the average time between successive ranging rounds may be constant. Alternatively, when the ranging mode is an interval-based mode, the time between successive ranging rounds can be changed dynamically. In other words, the interval-based mode can adopt a time structure with adaptive spacing.

A ranging block can be abbreviated as a block, a ranging round can be abbreviated as a round, and a ranging slot can be abbreviated as a slot.

Referring to FIG. 6B, one ranging round may include a ranging control step (RCP), a ranging step (RP), and/or a measurement report step (MRP). For example, one ranging round may include one slot for RCP, at least one slot for RP, and/or at least one slot for MRP.

Depending on the embodiment, some of the above-described steps may not be included in the ranging round, and additional steps may be included in the ranging round. For example, RCP may not be included in the ranging round. In this case, the Ranging Control Message (RCM) may be merged with the Ranging Initiation Message (RIM). For example, a ranging control update phase (RCUP) and/or a ranging interval update phase (RIUP) may be further included in the ranging round.

RCP may be the step where the controller transmits RCM. RCM may be a message sent by the controller to set ranging parameters. In one embodiment, the RCM may be transmitted in the first slot (slot #0) of the ranging round. RCM can be abbreviated as Control Message (CM).

RP may be a phase including a ranging initiation phase (RIP), a ranging response phase (RRP), and/or a ranging final phase (RFP).

RIP may be a step in which the initiator(s) transmits the RIM(s) to the responder(s).

RRP may be a step in which the responder(s) transmits their ranging response message (RRM)(s) to the initiator.

RFP may be a step in which the initiator transmits a ranging final message (RFM)(s) to the responder(s). The ranging end step can only be used for DS-TWR.

MRP may be a step in which participating ranging devices exchange service information related to ranging measurement. In MRP, a Measurement Report Message (MRM), Ranging Result Report Message (RRRM), and/or Control Update Message (CUM) may be transmitted. MRM may be a message sent by a UWB device to exchange measurement information. RRRM may be a message transmitted by the UWB device to report ranging results. CUM may be a message sent by the controller to update control information. CUM may be referred to as a Control Update Message (RCUM).

RCUP may be a step in which the controller transmits a Ranging Control Update Message (RCUM). The ranging control update step may be included in the last slot of the set of ranging rounds specified by the RCM. RCUM may be a message sent by the controller to update ranging parameters for the next ranging round(s). RCUM may be transmitted in the last slot of the ranging round(s) specified by RCM. RCUM may include some or all of the information elements (IE) employed by RCM to update the values of parameters.

The ranging interval update step (RIUP) may be a step in which the controller transmits a ranging interval update message (RIUM). RIUM may be a message sent by the controller to aid synchronization between participating ranging devices or to update the interval between ranging blocks. RIUM includes the scheduled time of the first RIUM. RIUM may include the scheduled time of the next RIUM before the next ranging block starts.

If necessary, the plurality of UWB messages described above can be merged into one message. For example, RCM can be merged with RIM and transmitted in RIP. For example, in the case of non-deferred DS-TWR ranging, RFM can be merged with MRM and transmitted in RFP.

Figure 7 shows various examples of a UWB ranging method according to an embodiment of the present disclosure.

Part (a) of FIG. 7 shows an example of a two way ranging (TWR) method, and part (b) of FIG. 7 shows an example of an Uplink TDoA (UL-TDoA) method, which is a type of OWR, and FIG. 7 Part (c) of shows an example of the Downlink TDoA (DL-TDoA) method, which is a type of OWR.

Referring to part (a) of FIG. 7, the user's UWB device 720a can perform ranging through ranging exchange using at least one UWB anchor 710a and a plurality of ranging messages. there is. Through this ranging exchange (ranging message exchange), time of flight (ToF) can be calculated and the distance between the two devices can be estimated.

The UWB device 720a may perform single-sided two-way ranging (SS-TWR) or double-sided two-way ranging (DS-TWR) with the UWB anchor 710a. When performing TWR, the UWB device 720a may perform the role of an initiator or responder.

In one embodiment, TWR may be performed according to a contention-based mode and/or a scheduling-based mode.

Referring to part (b) of FIG. 7, the user's UWB device (UWB tag) 720a may transmit (broadcast) a ranging message to at least one UWB anchor 710b, and the at least one UWB anchor 710b may obtain the TDoA based on the received ranging message and estimate the location of the UWB device 720b based on the TDoA. The TDoA scheme in the embodiment of part (b) of FIG. 7 may be referred to as an uplink TDoA (UL-TDoA) scheme.

Referring to part (c) of FIG. 7, the user's UWB device (UWB tag or DT-tag) 720c determines its location by receiving ranging messages transmitted/received by at least one UWB anchor 710c. can be estimated. An example of this DL-TDoA method is described below with reference to FIGS. 8A and 8B.

Figure 8a shows a method in which a UWB device performs DL-TDoA UWB ranging according to an embodiment of the present disclosure.

The embodiment of FIG. 8A assumes that one initiator anchor (810) and n responder anchors (830a...830n) operate as UWB anchors (DT-anchors). do. However, the embodiment is not limited to this, and the number of Initiator anchors and Responder anchors may be set in various ways depending on the embodiment.

In operation S802, the Initiator anchor 810 may initiate a DL-TDoA round by transmitting or broadcasting a Poll DTM, which is received by the Rseponder anchor in the cluster. Poll DTM may include scheduling information for each Responder anchor to transmit Response DTM in the allocated ranging slot.

In one embodiment, all Responder anchors (830a, ... 830n) know whether to transmit the Response DTM and the slot (slot index) to use to transmit the Response DTM by referring to the scheduling information in the Poll DTM. You can.

In operations S804a,...,S804n, all Responder anchors 830a,...,830n that have received the Poll DTM move to the Initiator anchor 810 using the Response DTM in the ranging slot allocated by the Poll DTM. You can respond. For example, each Responder anchor (830a,...,830n) may transmit or broadcast a Response DTM in its ranging slot allocated by the Poll DTM.

In operation S806, the Initiator anchor 810, which has received the Response DTMs, may additionally transmit the Final DTM to the Responder anchors 830a,...,830n. For example, the Initiator anchor 810 may transmit or broadcast a Final DTM after receiving Response DTMs from Responder anchors 830a,...,830n.

In operation S808, the tag device (DT-Tag) 820 can receive (or overhear) the Poll DTM, Response DTM, and Final DTM, and calculate TDoA values through the information included in the message and the reception timestamp. You can. The tag device 820 may obtain (or estimate) its own location using the calculated TDoA values. Through this, the tag device 820 can estimate its own location without exposing its own location.

Figure 8b shows an example of a ranging block structure for a downlink TDoA method according to an embodiment of the present disclosure.

For example, the ranging block structure of FIG. 8B may be an example of a ranging block structure for performing the ranging method of FIG. 8A.

Referring to FIG. 8B, a ranging block may include a plurality of ranging rounds.

As an example, a ranging block may include a plurality of ranging rounds allocated to each cluster. For example, when n clusters are deployed, the ranging block consists of a first ranging round allocated for the first cluster, a second ranging round allocated for the second cluster, ... and the n-th cluster. It may include the nth ranging round allocated for this. Meanwhile, although not shown in FIG. 7B, depending on the embodiment, a plurality of ranging rounds may be allocated to one cluster, or one ranging round may be allocated to a plurality of clusters.

In one embodiment, a ranging round may include a plurality of ranging slots. A ranging round may include a plurality of ranging slots allocated for each ranging message transmitted by anchor devices belonging to a cluster associated with the ranging round. For example, if the first cluster is set with 1 Initiator anchor and 3 Responder anchors, the ranging round for the first cluster is the second allocated for sending/receiving Poll messages of the Initiator anchor included in the first cluster. 1 ranging slot (e.g., ranging slot index 0), a second ranging slot allocated for transmitting/receiving a response message of the first Responder anchor, and a second ranging slot allocated for transmitting/receiving a response message of the second Responder anchor. It may include a third ranging slot, a fourth ranging slot allocated for transmitting/receiving a response message of the third responder anchor, and a fifth ranging slot allocated for transmitting/receiving a final message of the initiator anchor. .

In this way, ranging slots can be allocated to a ranging round for each cluster.

Through the ranging block structure as in the embodiment of FIG. 8B, anchor devices in each cluster can perform one cycle of ranging message exchange through their ranging rounds in one ranging block, and user devices (tag devices) ) can calculate its own location by receiving these ranging messages. This operation can be repeated for each ranging block. Through this, the location of the user device can be updated in the cycle of the ranging block.

Figure 9 shows a payment processing method using UWB according to an embodiment of the present disclosure.

Referring to FIG. 9, payment processing using UWB may be performed by a payment terminal 901, a user device 902, and/or a payment server 903.

The payment terminal 901 may be an electronic device that communicates with a user device (or a UWB-enabled payment application on the user device) to perform electronic fund transfers. The payment terminal 901 may be, for example, a PoS (Point-of-service) terminal or a smart phone that supports a payment processing function. In one 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, all or part of the components of the UWB device of FIG. 1, or all or part of the components of the electronic device (e.g., the first electronic device or the second electronic device) of FIG. 2a/b. .

User device 902 may be a user's electronic device that includes a UWB-enabled payment application. User device 902 may be, for example, a user's smart phone. In one embodiment, user device 902 may operate as a controlee/responder for TWR and/or a DT-tag for DL-TDoA. The user device 902 may have, for example, all or part of the configurations of the UWB device of FIG. 1, or all or part of the configurations of the electronic device (e.g., the first electronic device or the second electronic device) of FIG. 2A/B. .

The payment server 903 may be a backend server (system), such as an acquirer or an issuer, that supports payment to the payment terminal 901 and/or the user device 902.

Referring to FIG. 9, the payment processing method using UWB includes a UWB/BLE based device discovery step (910), a payment terminal information transmission step (920), a user information transmission step (930), a transaction information transmission step (940), and UWB. It may include a security ranging step 950 and/or a payment step 960. However, depending on the embodiment, some steps may be omitted, multiple steps may be merged into one step, or additional steps may be performed. Additionally, each step may be performed in an order different from the order shown. For example, the transaction information transmission step 940 may be performed after the UWB security ranging step 950. For example, the UWB security ranging step 950 may be omitted.

[UWB/BLE based device discovery step (910)]

In one embodiment, the UWB/BLE based device discovery step 910 may include a BLE advertisement operation.

As an embodiment, the BLE advertisement operation may include the payment terminal 901 transmitting a BLE advertisement packet to the user device as a BLE advertiser. As an embodiment, the BLE advertisement packet may include at least one information that allows the user device 902 to initiate at least one UWB operation. For example, the BLE advertisement packet may include a UWB payment identifier to identify a supported payment service (or payment application). As an embodiment, at least one UWB operation that can be initiated based on receipt of a BLE advertisement packet includes a DL-TDoA localization procedure 911, a UWB advertisement procedure 912, and contention-based ranging (UWB contention-based ranging). ) It may include at least one of procedure 913 and.

In one embodiment, the DL-TDoA localization procedure 911 may be initiated upon receipt of a BLE advertisement packet or execution of a UWB-enabled payment application by user input.

The DL-TDoA localization procedure 911 can provide a DL-TDoA-based localization service to the user device 902. Through this, the user device 902 can estimate its own location and perform a proximity-based payment transaction without exposing its location to the payment terminal 901.

As an embodiment, the DL-TDoA localization procedure 911 may include the payment terminal 901 transmitting a UWB message (eg, Poll DTM, Response DTM, or Final DTM) for DL-TDoA.

In one embodiment, the contention-based ranging procedure 913 may be initiated upon receipt of a BLE advertisement packet or execution of a UWB-enabled payment application by user input.

When the payment terminal 901 and the user device 902 do not know each other, the user device 902 performs scheduling-based ranging to respond to a UWB message (e.g., RIM) transmitted by the payment terminal 901. It is not appropriate to do so. Therefore, in order for the user device 902 to respond to the UWB message sent by the payment terminal 901, contention-based ranging needs to be performed.

As an embodiment, the competition-based ranging procedure 913 may include the payment terminal 901 transmitting a control message for competition-based ranging. The control message may include information about the CAP for contention-based access of the user device 902.

As an embodiment, the control message (information) for contention-based ranging may be transmitted along with the message (information) for DL-TDoA through one combined UWB message.

As an example, in the contention-based ranging procedure 913, the user device 902 may respond to a UWB message sent by the payment terminal 901 if a preset condition is satisfied. For example, based on the results obtained by the DL-TDoA localization procedure 911, if the distance between the user device 902 and the payment terminal 901 is identified as being less than or equal to a preset distance, the user device 902 Can transmit a response message (eg, RRM) to the payment terminal 901. As an embodiment, the user device 902 may transmit a response message at any slot within the CAP set by the payment terminal 901.

In one embodiment, the UWB advertisement procedure 912 may be initiated upon receipt of a BLE advertisement packet or execution of a UWB-enabled payment application by user input. In the UWB advertisement procedure 912, the payment terminal 901 can transmit a UWB advertisement message (signal), and the user terminal 902 can measure the AoA value for the received UWB advertisement message. Based on the measured AoA value, user intent for payment processing may be detected. For example, a gesture (tilt UX) in which the user points the user device 902 toward the payment terminal 901 may be preset as a gesture to express the user's intention to start payment processing. When such a gesture is taken, the AoA value for the UWB advertisement message received from the payment terminal 901 can be measured as almost zero. Accordingly, in this scenario, if the AoA value is measured close to zero, the user device 902 can confirm that there is a user intention to initiate payment processing.

[Payment terminal information transmission step (920)]

In one embodiment, the payment terminal information transmission step 920 may include the payment terminal 901 transmitting payment terminal information to the user device 902. Payment terminal information may be referred to as PoS information.

As an embodiment, payment terminal information may be included in a control message for competition-based ranging and transmitted from the payment terminal 901 to the user device 902. As an embodiment, payment terminal information may be included in a message for DL-TDoA (e.g., Poll DTM, Response DTM, Final DTM) and transmitted from the payment terminal 901 to the user device 902. As an embodiment, the payment terminal information may be transmitted from the payment terminal 901 to the user device 902 by being included in a UWB message in which a control message for contention-based ranging and a message for DL-TDoA are merged. Through this, payment terminal information can be transmitted through UWB in-band.

As an embodiment, payment terminal information may include identification information (e.g., identifier) of the payment terminal 901 (or a store associated with the payment terminal 901), payment terminal 901 (or a store associated with the payment terminal 901), It may include name information (e.g. nickname) of the store) and/or random challenge information (posChallenge) of the payment terminal 901 for mutual authentication. The random challenge information (posChallenge) of the payment terminal 901 may be a random value (eg, random number) generated by the payment terminal 901 used for mutual authentication using the random challenge method.

[User information transmission step (930)]

In one embodiment, the user information transmission step 930 may include the user device 902 transmitting user information to the payment terminal 901.

As an embodiment, user information may be transmitted by being included in a response message (e.g., RRM for SS-TWR) sent from the user device 902 to the payment terminal 901 in the competition-based ranging procedure 913. there is. Through this, user information can be transmitted through UWB in-band.

In embodiments, user information may include identifying information (e.g., an identifier) of user device 902 (or a user of user device 902), It may include name information (eg, nickname) and/or random challenge information (userChallenge) of the user device 902 for mutual authentication. The random challenge information (userChallenge) of the user device 902 may be a random value (eg, random number) generated by the user device 902 used for mutual authentication in the random challenge method.

[Transaction information transmission step (940)]

In one embodiment, the transaction information transmission step 940 may include the payment terminal 901 transmitting transaction information to the user device (or a UWB-enabled payment application of the user device 902).

By way of example, transaction information may be transmitted via UWB data messages (data frames).

As an embodiment, the transaction information may be personal information related to payment, such as a store name and transaction amount, transmitted from the payment terminal 901 to the user device 902.

As an example, the transaction information transmission step 940 may be performed after a secure channel (session) is established. For example, the transaction information transmission step 940 may be performed after a secure session is established through the UWB security ranging procedure 950.

[UWB security ranging step (950)]

In one embodiment, the UWB secure ranging step 950 may include a procedure for performing secure ranging between the payment terminal 901 and the user device 902 using STS (eg, dynamic STS). Through this, a secure session can be established between the payment terminal 901 and the user device 902.

As an embodiment, the UWB security ranging step 950 may be an optional step.

[Payment stage (960)]

In one embodiment, the payment step 960 may include a procedure 961 in which the user device 902 and the payment terminal 901 exchange UWB security data including payment information.

As an example, payment information may be transmitted via UWB data messages (data frames).

As an example, the payment information may be personal information related to payment, such as a card number, transmitted from the user device 902 to the payment terminal 901. As an example, in procedure 961 for exchanging UWB secure data, payment information may be encrypted and transmitted over a secure channel.

In one embodiment, the payment step 960 may include a procedure 962 in which the user device 902 and the payment terminal 901 perform an online payment.

Using the information exchanged through the payment step 960, the payment terminal 901 and/or the user device 902 may perform a back-end interaction with the payment server 902 to complete the transaction.

Below, a method for performing the contention-based ranging procedure and the DL-TDoA procedure together is described.

Figure 10 shows a method in which a UWB device performs DL-TDoA ranging and contention-based ranging together according to an embodiment of the present disclosure.

The ranging procedure in the embodiment of FIG. 10 may be a ranging procedure in which DL-TDoA ranging and contention-based ranging are performed together.

Compared to the DL-TDoA of FIG. 8A, the UWB message used in the ranging procedure of the embodiment of FIG. 9 may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In the embodiment of FIG. 10, for convenience of explanation, four anchors including one initiator anchor 1001 and three responder anchors 1002-1 to 1002-3 and two user devices 1003-1 , 1003-2) is assumed to perform the ranging procedure, but the embodiment is not limited thereto. For example, a different number of anchors and user devices than those illustrated may participate in the ranging procedure.

In one embodiment, the initiator anchor 1001 may be a payment terminal for a UWB-based payment service (eg, the payment terminal 901 in FIG. 9). As an embodiment, the initiator anchor 1001 performs the role of a controller/initiator for contention-based ranging (TWR) and a DT-anchor (e.g., initiator DT-anchor) for DL-TDoA (OWR). can do.

In one embodiment, the responder anchors 1002-1, 1002-2, and 1002-3 may be payment terminals for UWB-based payment services (eg, payment terminal 901 in FIG. 9). As an embodiment, the responder anchors 1002-1, 1002-2, and 1002-3 play the role of controller/initiator for contention-based ranging (TWR) and DT-anchor (e.g., DL-TDoA (OWR)) : Can perform the role of responder DT-anchor).

In one embodiment, the user devices 1003-1 and 1003-2 may be user devices for a UWB-based payment service (eg, user device 902 in FIG. 9). As an embodiment, the user devices 1003-1 and 1003-2 play the role of controlee/responder for contention-based ranging (TWR) and DT-tag (e.g., DT-tag) for DL-TDoA (OWR). ) can perform the role together.

In one embodiment, the ranging procedure of the embodiment of FIG. 10 may be performed in one ranging round. For example, in FIG. 10, the exchange of messages between devices to perform a ranging procedure may be performed in one ranging round.

Referring to FIG. 10, the ranging procedure may include step 1010, step 1020, and/or step 1030. Depending on the embodiment, some steps or some operations within the steps may be omitted, additional steps may be performed, and the order of each step may be changed.

[Step 1010]

Step 1010 may be a step for anchors 1001, 1002-1 to 1002-3 to transmit or broadcast a UWB message that enables both DL-TDoA and contention-based ranging. Step 1010 may include at least one of operations 1011 to 1013, which will be described below.

In operation 1011, the initiator anchor 1001 may transmit or broadcast a first UWB message to initiate the ranging procedure. The first UWB message can be used to provide both the RIM function for contention-based ranging and the Poll DTM function for DL-TDoA. Additionally, the first UWB message may be used for UWB advertisement for tilt UX. Additionally, the first UWB message may be used to transmit payment terminal information. The first UWB message may be referred to as an initiation message, first DTM, poll DTM, etc.

In one embodiment, the first UWB message may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In one 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 control message type 2. As an embodiment, the control message may include information indicating the size of the CAP (CAP size information).

In one embodiment, the payload IE for DL-TDoA in the first UWB message may include data of Poll 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, and 1002-3).

In operation 1012, each responder anchor (1002-1, 1002-2, and 1002-3) may transmit or broadcast a second UWB message in response to the first UWB message. The second UWB message can be used to provide both the RIM function for contention-based ranging and the Response DTM function for DL-TDoA. Additionally, the second UWB message may be used for UWB advertisement for tilt UX. Additionally, the second UWB message may be used to transmit payment terminal information. The second UWB message may be referred to as a response message, second DTM, response DTM, etc.

In one embodiment, each responder anchor (1002-1, 1002-2, and 1002-3) may transmit or broadcast a second UWB message in its ranging slot based on scheduling information in the first UWB message. there is.

In one embodiment, the second UWB message may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In one 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 example, the control message for contention-based ranging may be control message (CM) type 2. As an embodiment, the control message for contention-based ranging in the second DTM may be a synced control message.

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

As an embodiment, synchronized control messages may set the CAP for contention-based ranging to the same time period. That is, the fact that the control messages are synchronized with each other may mean that the CAP set by the synchronized control messages has the same time period. For example, when the CAP set by the control message included in the first control message is set to a period corresponding to ranging slot #11 to ranging slot #20, control synchronized with the control message included in the first control message Messages can also set the CAP to the same period corresponding to ranging slot #11 to ranging slot #20. Through these synchronized control messages, CAPs set by each control message can be set to the same time period without conflicting with each other.

Hereinafter, synchronization of control messages will be explained using an example.

The control message included in the first UWB message may include CAP size information. CAP size information may specify the size of the CAP through which user devices 1003-1 and 1003-2 can make contention-based responses.

The CAP with the size of the CAP is the time when the initiator anchor (1001) and the responder anchors (1002-1 to 1002-4) transmit all UWB messages for DL-TDoA, that is, after the operation of step 1010 is completed. can be set.

If step 1010 ends at ranging slot #10, and assuming that the size of the CAP specified by the CAP size information of the control message in the first UWB message is 10, the CAP set by the control message in the first UWB message may be set to a time period including 10 ranging slots after ranging slot #10 (eg, the period from ranging slot #11 to ranging slot #20). In this case, the CAP established by the second UWB message with the control message synchronized with the control message in the first UWB message is also set in the time period (e.g., ranging slot) including 10 ranging slots after ranging slot #10. It must be set to the period from #11 to ranging slot #20). Accordingly, the value of the size of the CAP set by the control message in the first UWB message and the index values of the ranging slots included in the CAP are the value of the size of the CAP set by the synchronized control message in the second UWB message and the CAP. The index values of the included ranging slots must be the same. Through these synchronized control messages, time zones in which user terminals 1003-1 and 1003-2 can make contention-based responses can all be set to have the same time zone without collision.

Hereinafter, a method for setting a synchronized control message will be described as an example.

For example, assuming that there is one Initiator anchor, three Responder anchors, and the size of CAP is 5, as shown, the method of configuring a synchronized control message may be as follows.

The initiator anchor transmits the first UWB message (initiation message) in ranging slot #0.

In ranging slots #1, #2, and #3, the responder anchors transmit the second UWB message (first response message), respectively.

In ranging slot #4, the initiator anchor transmits the third UWB message (end message).

User devices can attempt a contention-based response by randomly selecting one of the ranging slots #5, #6, #7, #8, and #9.

In this scenario, when the Initiator anchor transmits the first UWB message in ranging slot #0, the Initiator anchor sets the value of the CAP size information in the control message to 5 and the value of the Responder Management List Size (RML Size) information. can be set to 4. Through this, user devices skip four ranging slots corresponding to the value 4 specified by the RML size information in ranging slot #0, where the initiator anchor transmitted the first UWB message, and then start CAP from ranging slot #5. A contention-based response can be performed in 5 ranging slots corresponding to the value 5 specified in size information. That is, based on the CAP size information (=5) and RML size information (=4) of the control message in the first UWB message, the user device identifies that the period corresponding to ranging slots #5 to #9 is CAP, A response message can be transmitted in any slot within the CAP.

Afterwards, when the first responder anchor transmits the second UWB message in ranging slot #1, the first responder anchor sets the value of the CAP size information in the control message to 5 and sets the value of the RML size information to 3. You can set it. Through this, user devices skip three ranging slots corresponding to the 3 value specified by the RML size information starting from ranging slot #1 where the first responder anchor transmitted the second UWB message, and then reach ranging slot #3. From , a contention-based response can be performed in 3 ranging slots corresponding to the 3 value specified in the CAP size information. That is, the same CAP can be set through the control message of the initiator anchor and the synchronized control message of the first responder anchor.

In a similar way, control messages in UWB messages transmitted by all remaining anchors are set to specify periods corresponding to the same ranging slots #5, #6, #7, #8, #9 as CAPs, so that the control messages They can be synchronized with each other.

In one embodiment, the payload IE for DL-TDoA in the second UWB message may include data of 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 responder anchor may include the first responder response time indicating the time elapsed between the time the responder anchor received the first UWB message and the time it transmitted the second UWB message. You can.

In operation 1003, the initiator anchor 1001 may transmit 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 can be used to provide both the RIM function for contention-based ranging and the Final DTM function for DL-TDoA. Additionally, the third UWB message may be used for UWB advertisement for tilt UX. Additionally, the third UWB message may be used to transmit payment terminal information. The third UWB message may be referred to as a final message, third DTM, or final DTM.

In one embodiment, the third UWB message may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In one 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 within the third DTM may be a synchronized control message. For synchronization of control messages, refer to the description described above in step 1012.

In one embodiment, the payload IE for DL-TDoA in the third UWB message may include data of 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 second UWB messages 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 the initiator anchor 1001 receives the second UWB message from the corresponding responder anchor and the time the third UWB message is transmitted.

In one embodiment, the third UWB message may be used as a UWB advertisement message for UWB advertisement. As an embodiment, the third UWB message may include information to be used as a UWB advertisement message. The user devices 1003-1 and 1003-2 may perform a UWB advertisement procedure for tilt UX (e.g., UWB advertisement procedure 912 in FIG. 9) using the third UWB message.

In one embodiment, the third UWB message may further include anchor random challenge information (posChallenge) used for mutual authentication.

[Step 1020]

Step 1020 may be a step for the user device to perform DL-TDoA localization and a contention-based response to the anchor. Step 1020 may include at least one of the following operations 1021 to 1022.

At operation 1021, user devices 1003-1 and 1003-2 receive the first UWB message, the second UWB message, and the third UWB message and perform TDoA based on the payload IE for DL-TDoA in each UWB message. You can calculate and estimate your location based on the calculated TDoA.

In operation 1022, each user device 1003-1 and 1003-2 may transmit a ranging response message (RRM) for contention-based ranging to the selected anchor.

In one embodiment, the user device 1003-1 and 1003-2 may select one of the anchors 1001 and 1002-1 to 1002-4 based on preset criteria. For example, the user devices 1003-1 and 1003-2 may select an anchor located within a preset distance (eg, 2 meters) from its own location based on the DL-TDoA result. If there are a plurality of anchors located within a preset distance, the user device may select the anchor at the closest distance among the plurality of anchors.

In one embodiment, user devices 1003-1 and 1003-2 may transmit a ranging response message in any ranging slot within the CAP. As an embodiment, the CAP may be set through a control message in the first UWB message, a synchronized control message in the second UWB message, and a synchronized control message in the third UWB message. CAPs established through synchronized control messages may have the same time period.

In one embodiment, the ranging response message may include user information. For example, the ranging response message may respond by additionally including a random challenge value (user challenge) randomly generated by the user device. At this time, the random challenge value can be delivered by being included in the Data Message payload IE (DM payload IE) that is piggybacked and delivered to the RRM to which the user responds. The userChallenge value transmitted at 1022 can be used as a security tool to verify whether the payment terminal 1001 holds a valid certificate and a corresponding private key.

In one embodiment, the ranging response message is the time elapsed between the time of receiving the UWB message (e.g., the first UWB message, the second UWB message, or the third UWB message) from the selected anchor and the time of transmitting the ranging response message. Response time information specifying the time may be included.

[Step 1030]

Step 1030 may be a step for measuring the distance between the anchor that has received the ranging response message and the user device that has responded. As an example, the distance measurement may be based on SS-TWR.

In step 1030, the anchor that has received the response message from the user device may perform an SS-TWR operation based on the ranging response message. Through this, the anchor can obtain an accurate distance from the user device.

Unlike the embodiment of FIG. 8A, in the embodiment of FIG. 10, the UWB message used in the ranging procedure includes not only the payload IE for DL-TDoA, but also the payload IE for contention-based ranging. Therefore, in one ranging cycle (ranging round), DL-TDoA ranging and contention-based ranging can be performed together. This can increase the efficiency of resource use.

Figure 11 shows a method in which a UWB device performs DL-TDoA ranging and contention-based ranging together according to an embodiment of the present disclosure.

The ranging procedure in the embodiment of FIG. 11 may be a ranging procedure in which DL-TDoA ranging and contention-based ranging are performed together.

Compared to FIG. 8A, the UWB message used in the ranging procedure of the embodiment of FIG. 11 may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

Compared to the DL-TDoA procedure of FIGS. 8A and 10, in the ranging procedure of the embodiment of FIG. 11, each responder anchor generates a response DTM (second DTM) in one ranging cycle (DL-TDoA ranging cycle). It can be sent twice.

In the embodiment of FIG. 11, for convenience of explanation, five anchors including one initiator anchor 1101 and four responder anchors 1102-1 to 1102-4 and two user devices 1103-1 , 1103-2) is assumed to perform the ranging procedure, but the embodiment is not limited to this. For example, a different number of anchors and user devices than those illustrated may participate in the ranging procedure.

In one embodiment, the initiator anchor 1101 may be a payment terminal for a UWB-based payment service (eg, the payment terminal 901 in FIG. 9). As an embodiment, the initiator anchor 1101 performs the role of a controller/initiator for contention-based ranging (TWR) and a DT-anchor (e.g., initiator DT-anchor) for DL-TDoA (OWR). can do.

In one embodiment, the responder anchors 1102-1, 1102-2, 1102-3, and 1102-4 may be payment terminals for a UWB-based payment service (eg, payment terminal 901 in FIG. 9). As an embodiment, responder anchors 1102-1, 1102-2, 1102-3, and 1102-4 play the role of controller/initiator for contention-based ranging (TWR) and DT for DL-TDoA (OWR). -Can perform the role of anchor (e.g. responder DT-anchor).

In one embodiment, the user devices 1103-1 and 1103-2 may be user devices for a UWB-based payment service (eg, user device 902 in FIG. 9). As an embodiment, the user devices 1103-1 and 1103-2 may perform the role of a controlee/responder for contention-based ranging (TWR) and a DT-tag for DL-TDoA (OWR). You can.

In one embodiment, the ranging procedure of the embodiment of FIG. 11 may be performed in one ranging round. For example, operations 1111 to 1150 of FIG. 11 may be performed in one ranging round.

Referring to FIG. 11, in operation 1110, the initiator anchor 1101 may transmit or broadcast a first UWB message to initiate a ranging procedure. The first UWB message can be used to provide both the RIM function for contention-based ranging and the Poll DTM function for DL-TDoA. Additionally, the first UWB message may be used for UWB advertisement for tilt UX. Additionally, the first UWB message may be used to transmit payment terminal information. The first UWB message may be referred to as an initiation message, first DTM, poll DTM, etc.

In one embodiment, the first UWB message may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In one 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 control message type 2. As an embodiment, the control message may include information indicating the size of the CAP (CAP size information).

In one embodiment, the payload IE for DL-TDoA in the first UWB message may include data of Poll 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, and 1102-4).

In operation 1120, each responder anchor (1102-1, 1102-2, 1102-3, and 1102-4) may transmit or broadcast a second UWB message in response to the first UWB message. The second UWB message can be used to provide both the RIM function for contention-based ranging and the Response DTM function for DL-TDoA. Additionally, the second UWB message may be used for UWB advertisement for tilt UX. Additionally, the second UWB message may be used to transmit payment terminal information. The second UWB message may be referred to as a first response message, second DTM, response DTM, etc.

In one embodiment, each responder anchor (1102-1, 1102-2, 1102-3, and 1102-4) sends a second UWB message in its ranging slot based on the first scheduling information in the first UWB message. It can be transmitted or broadcast.

In one embodiment, the second UWB message may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In one 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 example, the control message for contention-based ranging may be control message (CM) type 2. As an embodiment, the control message for contention-based ranging in the second DTM may be a synced control message.

As an embodiment, the synchronized control message may be a control message synchronized with the control message included in the first UWB message transmitted by the initiator anchor 1101 in step 1111.

As an embodiment, synchronized control messages may set the CAP for contention-based ranging to the same time period. That is, the fact that the control messages are synchronized with each other may mean that the CAP set by the synchronized control messages has the same time period. For example, when the CAP set by the control message included in the first control message is set to a period corresponding to ranging slot #11 to ranging slot #20, control synchronized with the control message included in the first control message Messages can also set the CAP to the same period corresponding to ranging slot #11 to ranging slot #20. Through these synchronized control messages, CAPs set by each control message can be set to the same time period without conflicting with each other. For synchronization of control messages, refer to the description described above in step 1012 of FIG. 10.

In one embodiment, the payload IE for DL-TDoA in the second UWB message may include data of Response DTM. As an embodiment, the payload IE for DL-TDoA in 2 UWB messages may include first response time (reply time) information. The first response time information of the corresponding responder anchor may include the first responder response time indicating the time elapsed between the time the corresponding responder anchor received the first DTM and the time it transmitted the second DTM.

In operation 1130, the initiator anchor 1101 may transmit 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. there is. The third UWB message can be used to provide both the RIM function for contention-based ranging and the Final DTM function for DL-TDoA. Additionally, the third UWB message may be used for UWB advertisement for tilt UX. Additionally, the third UWB message may be used to transmit payment terminal information. The third UWB message may be referred to as a final message, third DTM, or final DTM.

In one embodiment, the third UWB message may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In one 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 within the third DTM may be a synchronized control message. For synchronization of control messages, refer to the description described above in step 920 of FIG. 9.

In one embodiment, the payload IE for DL-TDoA in the third UWB message may include data of 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 the initiator anchor 1101 receives the second DTM from the corresponding responder anchor and the time the third DTM is transmitted.

In operation 1140, each responder anchor (1102-1, 1102-2, 1102-3, and 1102-4) may transmit or broadcast a fourth UWB message in response to the third UWB message. The fourth UWB message can be used to provide both the RIM function for contention-based ranging and the Response DTM function for DL-TDoA. Additionally, the fourth UWB message may be used for UWB advertisement for tilt UX. Additionally, the fourth UWB message may be used to transmit 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, second DTM, response DTM, etc.

In one embodiment, each responder anchor (1102-1, 1102-2, 1102-3, and 1102-4) sends the fourth UWB message in its ranging slot based on the second scheduling information in the first UWB message. It can be transmitted or broadcast.

In one embodiment, the fourth UWB message may include a payload IE for contention-based ranging and a payload IE for DL-TDoA.

In one 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 example, the control message for contention-based ranging may be control message (CM) type 2. As an embodiment, the control message for contention-based ranging in the fourth UWB message may be a synced control message. For synchronization of control messages, refer to the description described above in step 920.

In one embodiment, the payload IE for DL-TDoA in the fourth UWB may include data of Response DTM. As an embodiment, the payload IE for DL-TDoA in the fourth UWB may include third response time information. The third response time information of the corresponding responder anchor may include a second responder response time indicating the time elapsed between the time the corresponding responder anchor received the third DTM and the time it transmitted the fourth DTM.

In one embodiment, user devices 1103-1 and 1103-2 receive a first UWB message, a second UWB message, a third UWB message, and a fourth UWB message, and configure the DL-TDoA for DL-TDoA within each UWB message. You can calculate TDoA based on payload IE and estimate your location based on the calculated TDoA.

In operation 1150, each user device 1103-1 and 1103-2 may transmit a ranging response message (RRM) for contention-based ranging to the selected anchor. The anchor that receives the response message from the user device may perform the SS-TWR operation based on the ranging response message. Through this, the anchor can obtain an accurate distance from the user device. The ranging response message may be referred to as the fifth UWB message, extended ranging response message (extended RRM).

In one embodiment, the user device 1103-1 and 1103-2 may select one of the anchors 1101 and 1102-1 to 1102-4 based on preset criteria. For example, the user devices 1103-1 and 1103-2 may select an anchor located within a preset distance (eg, 2 meters) from its own location based on the DL-TDoA result. If there are a plurality of anchors located within a preset distance, the user device may select the anchor at the closest distance among the plurality of anchors.

In one embodiment, user devices 1103-1 and 1103-2 may transmit a ranging response message in any ranging slot within the CAP. As an embodiment, the CAP may be set through a control message in the first UWB message, a synchronized control message in the second UWB message, a synchronized control message in the third UWB message, and a synchronized control message in the fourth UWB message. CAPs established through synchronized control messages may have the same time period.

In one embodiment, the ranging response message may include user information.

In one embodiment, the ranging response message may include two pieces of response time information for the selected anchor. For example, when the responder anchor 1102-1 is selected, the ranging response message includes response time information for the second UWB message of the responder anchor 1102-1 and the fourth UWB message of the responder anchor 1102-1. It may contain response time information. The response time information for the second UWB message of the responder anchor 1102-1 may be the elapsed time between the reception time of the second UWB message of the responder anchor 1102-1 and the transmission time of the ranging response message of the user device. there is. The response time information for the fourth UWB message of the responder anchor 1102-1 may be the elapsed time between the reception time of the fourth UWB message of the responder anchor 1102-1 and the transmission time of the ranging response message of the user device. there is.

Meanwhile, in the embodiment of FIGS. 8A and 10, in one DL-TDoA ranging cycle, the initiator anchor transmits two DTMs, but the responder anchors can transmit only one DTM. Therefore, in the case of the embodiment of FIGS. 8A and 10, it is difficult for the user device to estimate CFO for responder anchors.

However, in the case of the embodiment of FIG. 11, in one DL-TDoA ranging cycle, all anchors transmit two or more DTMs (UWB messages). Accordingly, the user device can receive two or more DTMs from each anchor. As a result, the user device can estimate the clock frequency offset (CFO) for any anchor based on two or more DTMs received from each anchor. Additionally, because each anchor transmits two or more DTMs, the possibility of the user device obtaining a TDoA can be increased.

Additionally, compared to the embodiment of FIG. 8A, in the case of the embodiment of FIG. 11, the UWB message used in the ranging procedure includes not only the payload IE for DL-TDoA, but also the payload IE for contention-based ranging. . Therefore, in one ranging cycle (ranging round), DL-TDoA ranging and contention-based ranging can be performed together. This can increase the efficiency of resource use.

Figure 12a shows the structure of a UWB message according to an embodiment of the present disclosure.

In the embodiment of FIG. 12A, the UWB message may be an example of a UWB message used in the ranging procedure of FIGS. 10 and 11. For example, the UWB message of FIG. 12A may be an example of a UWB message (eg, any one of the first to fourth UWB messages) used in the ranging procedure of FIGS. 10 and 11.

Referring to FIG. 12A, the UWB message includes a MAC header 1210, a MAC payload including payload IE 1220-1 for contention-based ranging and payload IE 1220-2 for DL-TDoA, and FCS It may include a MAC footer 1230 including .

In one embodiment, the MAC header 1210 may include all or part of the fields included in the MAC header of FIG. 4.

In one 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 the size of the CAP, information about the transmission (Tx) offset, and/or setting information related to the responder management list (RML).

In one embodiment, the payload IE 1220-2 for DL-TDoA may include all or part of the fields included in any one of the payload IE of the Poll DTM, the payload IE of the responder DTM, or the payload IE of the final DTM. there is.

Figure 12b shows the payload structure of a UWB message according to an embodiment of the present disclosure.

In the embodiment of FIG. 12B, the payload of the UWB message may be an example of the payload (MAC payload) of the UWB message of FIG. 12A.

Referring to FIG. 12b, the UWB message (or 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 competition-based ranging may be an example of the payload IE 1120-1 for competition-based ranging in FIG. 11, and the payload IE 1220-2 for DL-TDoA is shown in FIG. This may be an example of payload IE (1120-2) for DL-TDoA in 11.

In the embodiment of FIG. 12B, payload IE 1220-1 for contention-based ranging may precede payload IE 1220-2 for DL-TDoA.

[payload IE(1220-1) for competition-based ranging]

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

In one embodiment, the payload IE 1220-1 for contention-based ranging (or control message for contention-based ranging) includes a UWB message ID field, a message control field, a striding length field, an RML size field, and/ Alternatively, it may include an RML field.

The UWB message ID field can identify a UWB message. In the case of the payload IE 1220-1 for contention-based ranging, the UWB ID field may be set to a value specifying a control message.

The message control field can set parameters used 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 period in units of ranging slots used in CAP. Through this CAP size information, the number of ranging slots in which the user terminal can make a contention-based response can be specified. Table 1 below may be an example of a message control field.

The striding length field can specify the number of ranging blocks to be skipped.

The RML size field can specify the size of the RML.

The RML field may be a list containing the device MAC addresses of known responder(s). The RML field may include a number of RML elements corresponding to the size of the RML. Table 2 below shows an example of RML elements included in the RML field. Referring to Table 2, each RML element can specify the MAC address of the corresponding responder.

Parameter Size (octets) Notes Responder MAC Address 2/8 Device MAC Address of Responder

For example, when a short MAC address of 2 bytes is used and 5 responders are managed by RML, the value of the RML size field is set to 5, and the RML field can be 10 bytes of data.

As described above in FIGS. 10 and 11, a CAP through which the user device can perform a contention-based response can be set through the CAP size field and the RML size field included in the payload IE 1220-1 for contention-based ranging. You can. Additionally, when 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 set so that they all set the same CAP. At this time, the value of the CAP size field may be the same in all synchronized control messages.

[payload IE(1220-2) for DL-TDoA]

In one 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-dependent payload field.

The UWB message ID field can identify a UWB message. In the case of payload IE (1220-2) for DL-TDoA, the UWB ID field can be set to a value specifying an OWR message.

The OWR message type field can specify the type of OWR message. For payload IE (1220-2) for DL-TDoA, the OWR message type field can be set to a value that specifies one of Poll DTM, Response DTM, or Final DTM.

The OWR message type-dependent payload field may contain payload data according to the value specified by the OWR message type field. If the value set in the OWR message type field specifies Poll DTM, Response DTM, or Final DTM, that is, specifies DTM, an example of the OWR message type-dependent payload field is shown below, with reference to FIGS. 13A and 13B. This is explained in

Figure 12c shows the payload structure of a UWB message according to an embodiment of the present disclosure.

In the embodiment of FIG. 12C, the payload of the UWB message may be an example of the payload (MAC payload) of the UWB message of FIG. 12A.

Referring to FIG. 12C, the UWB message (or 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 competition-based ranging may be an example of the payload IE 1120-1 for competition-based ranging in FIG. 11, and the payload IE 1220-2 for DL-TDoA is shown in FIG. This may be an example of payload IE (1120-2) for DL-TDoA in 11.

Unlike the embodiment of FIG. 12B, in the embodiment of FIG. 12C, the payload IE 1220-1 for contention-based ranging may follow the payload IE 1220-2 for DL-TDoA.

Meanwhile, each field (information) included in the payload IE 1220-1 for competition-based ranging in the embodiment of FIG. 12C is equivalent to each field included in the payload IE 1220-1 for competition-based ranging in the embodiment of FIG. 12B. Same as (information). Accordingly, reference may be made to the description of FIG. 12B.

In addition, each field (information) included in the payload IE 1220-2 for DL-TDoA of the embodiment of FIG. 12C is each field (information) included in the payload IE 1220-2 for DL-TDoA of FIG. 12B. ) is the same as Accordingly, reference may be made to the description of FIG. 12B.

13A and 13B show an example of an OWR message type-dependent payload field included in a UWB message, according to an embodiment of the present disclosure.

In the embodiment of FIG. 13, the OWR message type-dependent payload field of the UWB message may be an example of the OWR message type-dependent payload field of the payload IE 1220-2 for DL-TDoA of FIGS. 12A and 12B. there is.

Referring to Figure 13a, if the value set in the OWR message type field specifies Poll DTM, Response DTM, or Final DTM, the OWR message type-dependent payload field includes the message control field, round index field, block index field, and transmission ( Tx) may include a timestamp field and/or a responder DT-anchor management list field.

The message control field may include settings for the corresponding DTM.

The round index field can specify the round index of the current ranging round.

The block index field can specify the block index of the current ranging block.

The transmission timestamp field can specify the transmission timestamp of the DTM, expressed as either a local or common time base.

The responder DT-anchor management list field may include N responder DT-anchor management list elements.

N can 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. An example of the responder DT-anchor management list element is described below with reference to FIG. 13B.

Referring 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.

The responder address field can specify the address (e.g. MAC address) of the responder DT-anchor (responder anchor).

The ranging slot index field can specify the 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 is used by the corresponding responder DT-anchor in the initiation message (e.g., the first UWB message in Figures 10/11) transmitted by the initiator DT-anchor (initiator anchor). It may be used to transmit a first response message (e.g., the second UWB message in FIGS. 10/11) in response. That is, the second ranging slot index field can be used by the responder anchor to transmit the first response message.

The second ranging slot index field may specify a second assigned ranging slot for 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 is the corresponding responder DT-anchor's end message transmitted by the initiator DT-anchor (e.g., the third UWB message in Figures 10/11). ) can be used to transmit a second response message (e.g., the fourth UWB message in FIGS. 10/11) in response. That is, the second ranging slot index field can be used by the responder anchor to transmit a second response message.

The ToF result field may contain the ToF as a result of the SS-TWR with the responder DT-anchor identified by the responder address field.

In one embodiment, the OWR message type-dependent payload field is a CFO field that specifies a clock frequency offset with respect to initiator anchor (CFO) and/or a response time that includes information about at least one response time. It may include additional fields (e.g. Reply Time List field or Responder Reply Time field).

Figure 14 shows a method for creating a secure channel according to an embodiment of the present disclosure.

The secure channel is a payment terminal 1401 (e.g., payment terminal 901 in FIG. 9) and a user device 1402 (e.g., user device 902 in FIG. 9) (or a payment application (wallet application) on the user device). )) can be set between. For example, a secure channel may be used to establish an encryption-enabled communication channel between the payment terminal 1401 and a payment application on the user device 1402.

The secure channel can be used by the payment terminal 1401 and the user device 1402 to exchange payment transactions on UWB in-band.

Referring to FIG. 14, the procedure for establishing a secure channel may include operations 1 to 11. However, depending on the embodiment, some operations may be omitted, additional operations may be performed, or may be performed in an order different from the order shown.

In operation 1, the payment terminal 1401 may generate an ephemeral key of the payment terminal. The temporary key of the payment terminal can be expressed as 'ePK.Terminal'.

Additionally, the payment terminal 1401 can sign the generated 'ePK.Terminal' using a private key. As an example, the private key may be a static private key. The temporary key of the signed payment terminal can be expressed as 'Sign(ePK.Terminal)'.

Additionally, the payment terminal 1401 can use a private key to sign by combining the generated ePK.Terminal and the user random challenge information transmitted by the user device in step 1022. As an example, a signature can be performed on a string (ePK.Terminal | UserChallenge) connecting ePK.Terminal and a user random challenge. Since the user random challenge value is a value randomly generated and transmitted by the user terminal in step 1022, the payment terminal 1401 signs a string containing the user random challenge value, so that the payment terminal 1401 receives the payment terminal's certificate. It can be used as a way to prove that real-time signing is possible by holding a private key corresponding to the public key included in the certificate.

In addition, the payment terminal 1401 sends a certificate of the payment terminal including 'ePK.Terminal', 'Sign(ePK.Terminal)', and the ID of the payment terminal, and a random challenge of the user device used for mutual authentication. It may be transmitted to the user device 1402 along with the information. The certificate of the payment terminal including the ID of the payment terminal can be expressed as 'Cert.Terminal(ID.Terminal). The random challenge information of the user device may be expressed as 'userChallenge'.

In operation 2, the user device 1402 (or payment application) may verify the certificate (Cert.Terminal) of the payment 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'.

In operation 3, user device 1402 (or payment application) may derive a Shared Ephemeral Secret (Ses). As an example, the user device 1402 (or a payment application) may generate Ses using 'ePK.Terminal' and an ephemeral private key of the payment application. The temporary secret key of the payment application can be expressed as 'eSK.Wallet'. As an example, Ses may include 'ePK.Terminal' and 'eSK.Wallet'. At this time, the user device 1402 may already have a certificate chain used to verify the certificate of the payment terminal in the payment application or payment app. Alternatively, the user device 1402 may download and verify a certificate chain that can be used to verify a certificate through a certificate database that can be searched through the payment terminal ID. The certificate chain may be a certificate chain composed of certificates issued from a certificate issuer that the user terminal 1402 can trust.

In operation 4, the user device 1402 (or the payment application) may derive a Shared Static Secret (Shs). The user device 1402 (or payment application) can generate Shs using 'PK.Ternimal' and the static private key of the payment application. The static private key of the payment application can be expressed as 'SK.Wallet'. As an example, Shs may include 'PK.Terminal' and 'SK.Wallet'.

In operation 5, the user device 1402 (or payment application) may derive a Message Authentication Code (MAC) from 'Shs' and 'ePK.Terminal'. The message authentication code can be expressed as 'ShsMAC.Wallet'. As an example, the message authentication code may be generated based on a cipher-based message authentication code (CMAC) algorithm. For example, the message authentication code can be generated based on 'CMAC (Shs, ePK.Terminal, context)'.

In operation 6, the user device 1402 (or payment application) may generate secure channel keys for encryption and authentication, respectively. That is, a secure channel key for encryption and a secure channel key for authentication can be generated, respectively. The user device 1402 (or payment application) may generate secure channel keys for encryption and authentication from 'Ses' and 'ShsMAC.Wallet'. The secure channel key can be expressed 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)'.

In operation 7, the user device 1402 (or payment application) may transmit 'ePK.Wallet' and 'ShsMAC.Wallet' to the payment terminal 1401.

In operation 8, the payment terminal 1401 may derive Ses from the received 'ePK.Wallet'. As an example, Ses may include 'ePK.Terminal' and 'eSK.Wallet'.

Additionally, the payment terminal 1401 can derive security keys for encryption and authentication. 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)'.

Through this, a secure channel can be established. In the subsequent procedure, the user device 1402 and the payment terminal 1401 may transmit data through an established secure channel.

Meanwhile, the security channel established by performing operation 8 may be a half-authenticated channel. That is, only the payment terminal 1401 may be an authenticated channel. In order for the secure channel to be fully authenticated, that is, to authenticate the user device 1402 (or the payment application), the following operations 9 to 10 may be further performed.

Additionally, the secure channel may be a half-trusted channel where the certificate can be protected with a temporary key.

In operation 9, the user device 1402 (or payment application) sends the ID of the payment application and/or the certificate ('Cert.Wallet') of the payment application including the ID of the user device to the payment terminal ( 1401). Since 'Cert.Wallet' contains personal information such as the ID of the payment application and the ID of the user device, to protect personal information, it is not transmitted before the secure channel is established and can be transmitted through the established secure channel. there is.

In operation 10, the payment terminal 1401 can verify 'Cert.Wallet'. The payment terminal 1401 can extract the static public key from 'Cert.Wallet'. The payment terminal 1401 can derive 'Shs', derive 'ShsMAC.Wallet' from 'Shs', and compare the self-derived 'ShsMAC.Wallet' with the 'ShsMAC.Wallet' received through operation 7. there is.

As an example, 'ShsMAC.Wallet' may be generated based on the CMAC (cipher-based message authentication code) algorithm. For example, 'ShsMAC.Wallet' can be created based on 'CMAC(Shs, ePK.Terminal, context)'.

If the two 'ShsMAC.Wallets' do not have the same value, the payment terminal 1401 may drop all previous messages and terminate the session. If both 'ShsMAC.Wallets' have the same value, authentication for the user device (or payment application) can be completed.

In one embodiment, the payment terminal 1401 may transmit transaction information after operation 9. For example, the payment terminal 1401 may transmit transaction information after operation 9 and before operation 10. For example, the payment terminal 1401 may transmit transaction information after operation 10. As an example, the transaction information may include information about the merchant name associated with the payment terminal 1401 and/or information about the amount.

In one embodiment, the user device 1402 (or payment application) may transmit payment information to the payment terminal 1401 after receiving transaction information. For example, the user device 1402 (or the payment application) may transmit payment information after operation 10. As an example, payment information may include information about a card number (or token).

In operation 11, the payment terminal 1401 may transmit a result to the user device 1402 (or a payment application). As an embodiment, the result may be information indicating that the authentication in FIG. 10 failed, or information indicating that the authentication in FIG. 10 failed and the final payment was not approved, or information indicating that the authentication in FIG. 10 was successful, or information indicating that the authentication in FIG. 10 was successful. It may include information indicating that this has been successful and final payment approval has been completed.

Figure 15 shows a UWB device including a security component, according to one embodiment of the present disclosure.

For example, the UWB device of FIG. 15 may be an example of the UWB device of FIG. 2B.

Referring to FIG. 15 , the UWB device 1500 may include a security element 1510. Security element 1510 may be an example of security element 214b-1 in FIG. 2B.

The security element 1510 may include at least one applet. For example, it may include a payment app 1511 for a UWB-based payment service (e.g., the payment service in FIG. 9).

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

As an example, the app's data may be transmitted via an Application Protocol Data Unit (APDU). For example, data of the payment app 1511 may be transmitted and included in an APDU called payment transaction data APDU.

As an embodiment, the payment app 1511 sends data (or payment transaction data APDU) of the payment app 1511 to the UWBS 1520 through an API defined/set between the UWBS 1520 and the payment app 1511. Can be transmitted.

For example, as shown in FIG. 15, SUS internal API, which is the interface between the app and the SUS applet, and SUS external API, which is the interface between the SUS apple and the USBS (1520), provide UWB sessions such as UWB session keys and UWB session IDs. It is only used to transmit data such as a ranging data set (RDS) used for generation, and may not be used to transmit data of an app such as the payment app 1511. In this scenario, data from the payment app 1511 cannot be transmitted to the UWBS 1520 through the SUS internal API and SUS external API.

Therefore, a separate API needs to be defined/set between UWBS (1520) and the payment app (1511), and the payment app (1511) needs to be defined/set between the UWBS (1520) and the payment app (1511) through the API defined/set between the UWBS (1520) and the payment app (1511). , data of the payment app 1511 can be transmitted to the UWBS 1520.

Figure 16 shows a UWB device including a security component, according to one embodiment of the present disclosure.

For example, the UWB device of FIG. 16 may be an example of the UWB device of FIG. 2B.

Referring to FIG. 16, UWB device 1600 may include a security element 1610. Security element 1610 may be an example of security element 214b-1 in FIG. 2B.

The security element 1610 may include at least one applet. For example, it may include a payment app 1611 for a UWB-based payment service (e.g., the payment service in FIG. 9).

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

As an example, the app's data may be transmitted via an Application Protocol Data Unit (APDU). For example, data of the payment app 1611 may be transmitted and included in an APDU called payment transaction data APDU.

As an embodiment, the payment app 1611 transmits data (or payment transaction) of the payment app 1511 to the UWBS 1520 through the extended SUS internal API 1630 and the extended SUS external API 1640. data APDU) can be transmitted.

In the case of the embodiment of FIG. 16, unlike the embodiment of FIG. 15, the SUS internal API 1630 and SUS external API 1640 are used not only to transmit RDS but also to transmit data of the payment app 1611 (or payment transaction data APDU). It can be expanded and used to transmit .

Figure 17 shows a method of transmitting data in a security component of a UWB device to UWBS according to an embodiment of the present disclosure.

In the embodiment of FIG. 17, the UWB device of FIG. 17 may be an example of the UWB device of FIG. 2B, for example.

Referring to FIG. 17, the UWB device may include a security element 1710. Security element 1710 may be an example of security element 214b-1 in FIG. 2B.

The security element 1710 may include at least one applet. For example, the secure element 1710 may include a FiRa Applet that provides a Ranging Data Set (RDS) for secure ranging. Additionally, it may include a payment app 1711 for a UWB-based payment service (e.g., the payment service in FIG. 9).

As an embodiment, the payment app 1711 may interface with UWBS through an extended SUS external API (e.g., the extended SUS external API 1640 of FIG. 16). The payment applet 1711 may interface with UWBS through the expanded SUS internal API 1630, the Secure UWB Service Applet (SUS Applet), and the expanded SUS External API 1640 according to FIG. 16.

Data (or payment transaction data APDU) of the payment app 1711 transmitted to UWBS through the extended SUS external API may be transmitted to the MAC layer through a link layer (LL).

Data (or payment transaction data APDU) of the payment app 1711 may be processed in connection-oriented mode according to a preset link layer transmission mode (e.g., connection-oriented mode) and transmitted to the MAC layer. The payment app 1711 can transmit or process data according to the payment transaction protocol defined by EMVCo. Data transmitted and received through the payment app 1711 may utilize a data transmission technique based on the connection-oriented mode of the link layer (LL). By using a connection-oriented mode-based transmission technique, the payment app 1711 can transmit payment data by specifying a destination to the payment app on the other device communicating for payment. Additionally, functions such as time out, retransmission, and payment data fragmentation/reassembly can be performed through a connection-oriented mode-based data transmission technique.

Figure 18 shows components of RDS supported by SUS API according to an embodiment of the present disclosure.

Figure 18 specifically shows some examples of the Ranging Data Set (RDS) configuration provided by the SUS internal API. SUS internal API is the API between the Key Exchange Applet within the secure element (1610) and the SUS applet. The key exchange applet forms a Ranging Data Set (RDS) in TLV (Tag Length Value) format as shown in Figure 18 and delivers it to the SUS Applet through the SUS internal API. Referring to FIG. 18, in some embodiments, APDU (payment transaction data APDU) is included as one of the components of RDS supported by SUS API (SUS internal API and/or SUS external API) for transmission of payment transaction data. . In this embodiment, payment transaction data, which is payment-related data defined in EMVCo, can be identified with a tag number of 0xXX and transmitted to one of the RDS. Payment transaction data can be transmitted from the payment applet to the SUS applet by the RDS transmission method supported by the expanded SUS internal API according to FIG. 18, and can be transmitted to UWBS through the expanded SUS external API.

Although not shown in the drawing, payment transaction data may be transmitted through a separate APDU. In this case, the extended SUS internal API can be extended to transmit a data APDU including payment transaction data. Additionally, the expanded SUS external API can be extended to transmit data APDUs including payment transaction data. At this time, the APDU command used to transmit the payment transaction data APDU may be GET DATA or STORE DATA defined in the GlobalPlatform Card Specification.

Figure 19 shows a data transmission procedure using UWB according to an embodiment of the present disclosure.

The data transmission procedure of FIG. 19 may be a procedure for transmitting a data message (DM) (Data Frame) rather than a ranging message (RFRAME). As an embodiment, the data message may include, for example, transaction information and/or payment information for a UWB-based payment service.

In the embodiment of FIG. 19, the first UWB device 1901 is set to perform the device type of the controller and the device role of the initiator, and the second UWB device 1902 is set to perform the device type of the controlee and the device role of the responder. Assume it is set. According to the embodiment, the first UWB device 1901 may be a payment terminal 901 or a user terminal 902.

Referring to FIG. 19, the first UWB device 1901 may transmit a data transfer phase control message (DTPCM) 1910 to set a data transfer phase. According to one embodiment, the payment terminal 901 becomes the first UWB device 1901 and transmits a data transmission phase control message (DPTCM) to the user terminal 902, which is the second UWB device 1902, and the user terminal 902 may transmit user information 903 to the payment terminal 901 based on the scheduling information of the data transfer phase control message (DTPCM). The user terminal 901 may identify a ranging slot that receives the payment terminal information 920 or payment information 940 transmitted by the payment terminal 901 based on the data transmission phase control message (DTPCM). As an example, the first UWB device 1901 may set DTPCM based on application data transmitted from an upper layer. An example of DTPCM 1910 is described below with reference to FIGS. 20A to 20C.

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

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

Figure 20a shows a UWB message for data transmission according to an embodiment of the present disclosure.

The UWB message for data transmission in FIG. 20A may be an example of DM or DTPCM in FIG. 19.

Referring to FIG. 20A, a UWB message (Data Frame) for data transmission may include a UWB message ID field, Data Transfer Content Type field, and/or Content field. For example, a UWB message (Data Frame) for data transmission may have a payload IE including a UWB message ID field, Data Transfer Content Type field, and/or Content field.

If the UWB message is a DM or DTPCM, the UWB ID field can be set to a value that specifies the data message (DM).

The Data Transfer Content Type field can specify the type of the Content field. As an embodiment, the Data Transfer Content Type field may be set to 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, when the UWB message is DTPCM, the Data Transfer Content Type field may be set to a second value indicating that the type of the content field is the DTPCM type. In this case, an example of the content field is described below with reference to FIGS. 20B and 20C.

The Content field may include payload (payload data) related to the Data Transfer Content Type field.

Figures 20b and 20c show an example of the Content field of a UWB message for data transmission according to an embodiment of the present disclosure.

Referring to FIG. 20b, when the Data Transfer Content Type field is set to a second value indicating that the type of the content field is DTPCM type (i.e., when the UWB message is DTPCM), the content field is DTPML (Data Transfer Phase Management List) May contain length fields and/or DTPML list fields.

The DTPML length field can specify the length of the DTPML list field. The DTPML length may be the number of UWB terminals participating in a Data Transfer session for data transmission. For example, when two payment terminals and user terminals participate in a Data Transfer session for data transfer, the value of the DTPML length field may be 2.

The DTPML list field may contain a number of data transfer phase management entries corresponding to the number specified by the DTPML length field. An example of a data transfer phase management entry is described below with reference to FIG. 20C.

Referring to FIG. 20C, the data transfer phase management entry may include a MAC address field, a slot bitmap field, and/or a stop data transfer slot field.

The MAC address field can specify the MAC address of a transmitting data transfer device using the slot assignment set by the slot bitmap field.

The slot bitmap field may provide slot allocation for the device identified by the MAC address field. The slot bitmap field may include a slot bitmap. Each bit in the slot bitmap can represent one slot index.

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

As an example, when the value of the corresponding bit in the slot bitmap is set to 1, it may indicate that the corresponding slot is used by the device identified by the MAC address field. Alternatively, if the value of the corresponding bit in the slot bitmap is set to 0, it may indicate that the corresponding slot is not used by the device identified by the MAC address field.

The stop data transfer slot field may be set to a first value indicating that data transfer will be stopped or a second value indicating that data transfer will continue.

Figure 21 shows the structure of a first UWB device, according to an embodiment of the present disclosure.

In the embodiment of FIG. 21, the first UWB device may be an electronic device that corresponds to the UWB device of FIG. 1, includes a UWB device, or includes a part of a UWB device. For example, the first UWB device may be an anchor (eg, initiator anchor/responder anchor) for a UWB-based payment service.

Referring to FIG. 21, the first UWB device may include a transceiver 2110, a control unit 2120, and a storage unit 2130. In the present disclosure, the control unit may be defined as a circuit or application-specific integrated circuit or at least one processor.

The transceiver unit 2110 can transmit and receive signals with other entities.

The control unit 2120 may control the overall operation of the electronic device according to the embodiment proposed in this disclosure. For example, the control unit 2120 may control signal flow between each block to perform operations according to the flowchart described above. Specifically, the control unit 2120 may control, for example, the operation of the first UWB device described with reference to FIGS. 1 to 20 (e.g., the operation of the anchor for a UWB-based payment service).

The storage unit 2130 may store at least one of information transmitted and received through the transmitting and receiving unit 2110 and information generated through the control unit 2120. For example, the storage unit 2130 may store information and data necessary for the method described with reference to FIGS. 1 to 20, for example.

Figure 22 shows the structure of a second UWB device according to an embodiment of the present disclosure.

In the embodiment of FIG. 22, the second UWB device may be an electronic device that corresponds to the UWB device of FIG. 1, includes a UWB device, or includes a part of a UWB device. The second UWB device may be, for example, a user device for a UWB-based payment service.

Referring to FIG. 22, the second UWB device may include a transceiver 2210, a control unit 2220, and a storage unit 2230. In the present disclosure, the control unit may be defined as a circuit or application-specific integrated circuit or at least one processor.

The transceiver 2210 can transmit and receive signals with other entities.

The control unit 2220 may control the overall operation of the electronic device according to the embodiment proposed in this disclosure. For example, the control unit 2220 may control signal flow between each block to perform operations according to the flowchart described above. Specifically, the control unit 2220 may control, for example, the operation of the second UWB device described with reference to FIGS. 1 to 22 (e.g., the operation of the user device for a UWB-based payment service).

As an embodiment, the control unit 2220 receives a first UWB message that initiates a ranging procedure from an initiator anchor, and sends a plurality of second UWB messages transmitted in response to the first UWB message from a plurality of responder anchors. Receive, 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, DL- TDoA-based localization can be performed.

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

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

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

As an embodiment, the control unit 2220 may select one anchor among the initiator anchor and the plurality of responder anchors based on the result of the DL-TDoA-based localization.

As an embodiment, the control unit 2220 may transmit a ranging response message for SS-TWR to one anchor selected from among the initiator anchor and the plurality of responder anchors at any slot within the contention access period.

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

As an embodiment, the control unit 2220 is further configured to obtain user intent by measuring the AoA value of the third UWB message.

The storage unit 2230 may store at least one of information transmitted and received through the transmitting and receiving unit 2210 and information generated through the control unit 2220. For example, the storage unit 2230 may store information and data necessary for the method described with reference to FIGS. 1 to 20, for example.

In the specific embodiments of the present disclosure described above, components included in the present disclosure are expressed in singular or plural numbers depending on the specific embodiment presented. However, singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components, and even components expressed in plural may be composed of singular or singular. Even expressed components may be composed of plural elements.

Meanwhile, in the detailed description of the present disclosure, specific embodiments have been described, but of course, various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be determined not only by the scope of the patent claims described later, but also by the scope of this patent claim and equivalents.

Claims (14)

In the method of the UWB device,
Receiving, from an initiator anchor, a first UWB message initiating a ranging procedure;
Receiving, from a plurality of responder anchors, a plurality of second UWB messages transmitted in response to the first UWB message;
Receiving, from the initiator anchor, a third UWB message transmitted in response to the second UWB message; and
A method comprising performing DL-TDoA based localization based on the first UWB message, the second UWB message, and the third UWB message.
According to paragraph 1,
The first UWB message includes first information for DL-TDoA and second information for contention-based ranging.
According to paragraph 2,
The first information for the DL-TDoA includes a random number generated by the initiator anchor used for mutual authentication.
According to paragraph 2,
The second information for the contention-based ranging includes information specifying the size of the contention access period.
According to paragraph 4,
Based on the result of the DL-TDoA based localization, the method further includes selecting one anchor among the initiator anchor and the plurality of responder anchors.
According to clause 5,
In a random slot within the contention access period, transmitting a ranging response message for SS-TWR to one anchor selected from the initiator anchor and the plurality of responder anchors,
The ranging response message for the SS-TWR includes a random number generated by the UWB device used for mutual authentication between the UWB device and the selected anchor.
According to paragraph 1,
The method further includes obtaining user intent by measuring the AoA value of the third UWB message.
In UWB devices,
transceiver; and
It includes a control unit connected to the transceiver, wherein the control unit:
Receive, from the Initiator anchor, a first UWB message that initiates a ranging procedure,
Receiving a plurality of second UWB messages transmitted in response to the first UWB message from a plurality of responder anchors,
Receiving a third UWB message transmitted in response to the second UWB message from the Initiator anchor,
A UWB device configured to perform DL-TDoA based localization based on the first UWB message, the second UWB message, and the third UWB message.
According to clause 8,
The first UWB message includes first information for DL-TDoA and second information for contention-based ranging.
According to clause 9,
The first information for the DL-TDoA includes a random number generated by the initiator anchor used for mutual authentication.
According to clause 9,
The second information for the contention-based ranging includes information specifying the size of the contention access period.
According to clause 11,
The control unit is further configured to select one anchor among the initiator anchor and the plurality of responder anchors based on a result of the DL-TDoA based localization.
According to clause 12,
The control unit is further configured to transmit a ranging response message for SS-TWR to one anchor selected from the initiator anchor and the plurality of responder anchors at a random slot within the contention access period,
The ranging response message for the SS-TWR includes a random number generated by the UWB device used for mutual authentication between the UWB device and the selected anchor.
According to clause 8,
The control unit is further configured to obtain user intent by measuring the AoA value of the third UWB message.

Images