KR20240064426A

KR20240064426A - Uwb 세션을 관리하는 방법 및 장치

Info

Publication number: KR20240064426A
Application number: KR1020220146443A
Authority: KR
Inventors: 안기수; 한세희; 김성동
Original assignee: 삼성전자주식회사
Priority date: 2022-11-04
Filing date: 2022-11-04
Publication date: 2024-05-13
Also published as: WO2024096719A1

Abstract

본 개시는 UWB 세션 관리를 위한 방법을 개시한다. 본 개시의 일 실시예에 따른 전자 장치의 방법은 UWB 지원 어플리케이션의 서비스를 위한 설정 정보를 식별하는 단계, 상기 설정 정보에 기초하여, 상기 서비스에 대한 서비스 인스턴스 ID 정보를 생성하는 단계, 상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트와 다른 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 사이의 보안 채널을 설정하는 단계 및 상기 보안 채널을 통해 UWB 세션을 설정하기 위한 데이터를 상기 보안 컴포넌트들 사이에서 교환하는 단계를 포함할 수 있다.

Description

UWB 세션을 관리하는 방법 및 장치 {METHOD AND APPARATUS FOR MANAGING UWB (ULTRA WIDE BAND) SESSION}

본 개시는 UWB 통신에 관한 것으로, 보다 상세하게는 UWB 세션을 관리하기 위한 방법 및 장치에 관한 것이다.

인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT (Internet of Things, 사물 인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터 (Big data) 처리 기술 등이 IoT 기술에 결합된 IoE(Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서는, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구된다. 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신 (Machine to Machine, M2M), MTC(Machine Type Communication) 등의 기술이 연구되고 있다.

IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는, 기존의 IT(information technology) 기술과 다양한 산업 간의 융합 및 복합을 통하여, 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.

무선 통신 시스템의 발전에 따라 다양한 서비스를 제공할 수 있게 됨으로써, 이러한 서비스들을 효과적으로 제공하기 위한 방안이 요구되고 있다. 예를 들어, UWB(Ultra Wide Band)를 이용하여 전자 디바이스들 간의 거리를 측정하는 레인징(ranging) 기술이 사용될 수 있다.

본 개시는 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트를 이용하여 UWB 세션을 관리하기 위한 방안을 제공한다.

본 개시의 일 양상에 따른, UWB 통신을 수행하는 전자 장치의 방법은 UWB 지원(enabled) 어플리케이션의 서비스를 위한 설정 정보를 식별하는 단계; 상기 설정 정보에 기초하여, 상기 서비스에 대한 서비스 인스턴스 ID 정보를 생성하는 단계; 상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트와 다른 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 사이의 보안 채널을 설정하는 단계; 및 상기 보안 채널을 통해 UWB 세션을 설정하기 위한 데이터를 상기 보안 컴포넌트들 사이에서 교환하는 단계를 포함하며, 상기 설정 정보는 서비스 설정 정보, UWB 설정 정보 또는 OOB 설정 정보 중 적어도 하나를 포함할 수 있다.

본 개시의 다른 양상에 따른, UWB 통신을 수행하는 전자 장치는 메모리; 및 상기 메모리에 연결된 프로세서를 포함하며, 상기 프로세서는: UWB 지원(enabled) 어플리케이션의 서비스를 위한 설정 정보를 식별하고, 상기 설정 정보에 기초하여, 상기 서비스에 대한 서비스 인스턴스 ID 정보를 생성하고, 상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트와 다른 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 사이의 보안 채널을 설정하고, 상기 보안 채널을 통해 UWB 세션을 설정하기 위한 데이터를 상기 보안 컴포넌트들 사이에서 교환하도록 구성되며, 상기 설정 정보는 서비스 설정 정보, UWB 설정 정보 또는 OOB 설정 정보 중 적어도 하나를 포함할 수 있다.

도 1 은 전자 장치를 개략적으로 도시한 블록도이다.
도 2a는 본 개시의 일 실시예에 따른 UWB 장치의 예시적인 아키텍쳐를 나타낸다.
도 2b는 본 개시의 일 실시예에 따른 UWB 장치의 프레임워크의 예시적인 구성을 나타낸다.
도 3은 본 개시의 일 실시예에 따른 UWB 장치의 프레임워크를 통한 UWB-enabled application의 예시적인 동작을 설명하기 위한 도면이다.
도 4는 본 개시의 일 실시예에 따른 Secure element를 포함하는 UWB 장치들 간의 데이터를 교환하는 방법을 나타낸다.
도 5는 본 개시의 일 실시예에 따른 UWB 장치들 간의 보안 채널을 설정하는 방법을 나타낸다.
도 6은 본 개시의 일 실시예에 따른 Application Data Structure의 일 예를 나타낸다.
도 7은 본 개시의 일 실시예에 따른, UWB 장치가 보안 엘리먼트를 이용하여 데이터를 관리하는 방법을 나타낸다.
도 8은 본 개시의 일 실시예에 따른, UWB 장치가 프레임워크 내의 보안 컴포넌트를 이용하여 데이터를 관리하는 방법을 나타낸다.
도 9는 본 개시의 일 실시에 따른 소프트웨어 기반의 보안 컴포넌트의 구성을 나타낸다.
도 10은 본 개시의 일 실시예에 따른 서비스 인스턴스 ID를 생성하는 방법을 나타낸다.
도 11은 본 개시의 일 실시예에 따른 UWB 장치가 UWB 세션을 관리하는 방법을 나타낸다.
도 12는 본 개시의 일 실시예에 따른 UWB 장치의 구성을 나타낸다.

이하, 본 개시의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.

실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.

마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.

본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 개시의 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

이때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능할 수 있다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능할 수 있다.

또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능할 수 있다.

이때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일부 실시 예에 따르면 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 일부 실시 예에 따르면, '~부'는 하나 이상의 프로세서를 포함할 수 있다.

본 명세서에서 사용하는 용어 '단말' 또는 '기기'는 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자 장치 또는 단순히 장치라 지칭할 수도 있다.

이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.

이하 본 개시의 실시 예를 첨부한 도면과 함께 상세히 설명한다. 이하에서는 UWB를 이용하는 통신 시스템을 일례로서 본 개시의 실시예를 설명하지만, 유사한 기술적 배경 또는 특성을 갖는 여타의 통신 시스템에도 본 개시의 실시예가 적용될 수 있다. 예를 들어, 블루투스 또는 지그비를 이용하는 통신 시스템 등이 이에 포함될 수 있을 것이다. 따라서, 본 개시의 실시예는 숙련된 기술적 지식을 가진 자의 판단으로써 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신시스템에도 적용될 수 있다.

또한, 본 개시를 설명함에 있어서 관련된 기능 혹은 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.

일반적으로 무선 센서 네트워크 기술은 인식 거리에 따라 크게 무선랜(Wireless Local Area Network; WLAN) 기술과 무선 사설망(Wireless Personal Area Network; WPAN) 기술로 구분된다. 이때, 무선랜은 IEEE 802.11에 기반한 기술로서, 반경 100m 내외에서 기간망(backbone network)에 접속할 수 있는 기술이다. 그리고, 무선 사설망은 IEEE 802.15에 기반한 기술로서, 블루투스(Bluetooth), 지그비(ZigBee), 초광대역 통신(ultra wide band; UWB) 등이 있다. 이러한 무선 네트워크 기술이 구현되는 무선 네트워크는 복수의 전자 장치들로 이루어질 수 있다.

FCC (Federal Communications Commission)의 정의에 따르면, UWB는 500MHz 이상의 대역폭을 사용하거나, 또는 중심 주파수에 대응하는 대역폭이 20% 이상인 무선통신 기술을 의미할 수 있다. UWB는 UWB 통신이 적용되는 대역 자체를 의미할 수도 있다. UWB는 장치들 간의 안전하고 정확한(secure and accurate) 레인징을 가능하게 한다. 이를 통해, UWB는 두 장치 간의 거리에 기반한 상대적 위치 추정 또는 (위치가 알려진) 고정 장치들로부터의 거리에 기반한 장치의 정확한 위치 추정을 가능하게 한다.

이하의 설명에서 사용되는 특정 용어들은 본 개시의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 개시의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.

* "Application Protocol Data Unit(APDU)"는 UWB 장치(예: FiRa 장치) 내의 Application Data Structure와 통신하는 경우에 사용되는 명령(command) 및 응답(response)일 수 있다. Command APDU는 명령을 포함하는 APDU이고 Response APDU는 응답을 포함하는 APDU이다.

"Application Data Structure"는 예컨대, UWB 세션 설정을 위해 요구되는 UWB Controlee Info 데이터 오브젝트 및 UWB Session Data 데이터 오브젝트와 같은 데이터 오브젝트를 포함하는 루트 레벨과 어플리케이션 레벨을 갖는 파일 시스템일 수 있다. 데이터 오브젝트는 태그 필드, 길이 필드, 및/또는 값 필드를 포함하는 BER-TLV 인코딩된 정보일 수 있다.

"Application Dedicated File (ADF)"는 예를 들면, 어플리케이션이나 어플리케이션 특정 데이터(application specific data)를 호스팅(hosting)할 수 있는 Application Data Structure 내의 데이터 구조일 수 있다.

"Object Identifier(OID)"는 Application Data Structure 내의 ADF의 식별자일 수 있다.

"Global Dedicated File(GDF)"는 UWB 세션을 설정하기 위해 필요한 데이터를 포함하는 Application Specific Data의 root level일 수 있다.

"Provisioning Authority(PA)"는 UWB 장치의 Application Data Structure를 관리하는 권한들(rights)을 갖는 third-party entity일 수 있다. 서비스 제공자는 자신의 ADF를 Application Data Structure에 쓰고, 서비스를 프로비저닝 또는 삭제하기 위해 PA를 이용할 수 있다.

"Controller"는 Ranging Control Messages (RCM) (또는, 제어 메시지)를 정의 및 제어하는 Ranging Device일 수 있다. Controller는 제어 메시지를 전송함으로써 레인징 특징들(ranging features)을 정의 및 제어할 수 있다.

"Controlee"는 Controller로부터 수신된 RCM (또는, 제어 메시지)내의 레인징 파라미터를 이용하는 Ranging Device일 수 있다. Controlee는 Controller로부터 제어 메시지를 통해 설정된 것과 같은 레인징 특징들을 이용할 수 있다.

"Initiator"는 레인징 교환(ranging exchange)을 개시하는 Ranging Device일 수 있다. Initiator는 첫 번째 RFRAME (레인징 교환 메시지)를 전송함으로써 레인징 교환을 개시할 수 있다.

"Responder"는 레인징 교환에서 Initiator에 응답하는 Ranging Device일 수 있다. Responder는 Initiator로부터 수신된 레인징 교환 메시지에 응답할 수 있다.

"STS"는 레인징 측정 타임스탬프(ranging measurement timestamps)의 무결성 및 정확도(integrity and accuracy)를 증가시키기 위한 암호화된 시퀀스(ciphered sequence)일 수 있다.

"Static STS mode"는 STS가 레인징 세션 동안 반복되는 동작 모드로서, Secure Component에 의해 관리될 필요가 없다.

"Dynamic STS(Scrambled Timestamp Sequence) mode"는 "Static STS"와 달리, STS가 레인징 세션 동안 반복되지 않는 동작 모드일 수 있다. 이 모드에서 STS는 Secure Component에 의해 관리될 수 있다.

"UWB Applet"는 예컨대, 서비스 제공자에 의해 프로비저닝될 수 있는 서비스 데이터 및 UWB 파라미터들을 포함하는 applet일 수 있다. UWB Applet은 Secure Component 상에서 실행되는 FiRa 정의된 Applet(FiRa Applet)일 수 있다. 서비스 데이터는 서비스 제공자에 의해 정의된 데이터로서, 서비스 구현을 위해 두 UWB 장치들 사이에서 전달될 필요가 있는 데이터일 수 있다. 서비스 제공자는 end-user에게 특정 서비스를 제공하기 위해 요구되는 하드웨어 및 소프트웨어를 정의 및 제공하는 엔티티일 수 있다.

"Service Applet"은 서비스 특정 트랜잭션들(예컨대, 도어를 해제하기 위한 크리덴셜들을 제공)을 다루는 applet일 수 있다. Service Applet은 Secure element 상의 applet일 수 있다.

"SUS Applet"은 다른 UWB 장치와의 보안 UWB 세션을 가능하기 하기 위한 데이터/정보를 검색하기 위해 UWB Applet 또는 Service Applet과 통신하고, 데이터/정보를 UWBS로 전달하는 Secure element일 수 있다. SUS Internal API는 RDS의 SUS Applet으로 전달을 위해, RDS를 생성할 수 있는 UWB Applet 또는 Service Applet으로 SUS Applet에 의해 노출된 인터페이스일 수 있다. SUS External API는 UWBS가 RDS를 검색하는 것을 가능하게 하는 SUS Applet에 의해 UWBS로 노출된 인터페이스일 수 있다.

"Key Exchange Applet"은 RDS를 생성하고, SUS Applet을 통해 RDS를 UWBS로 제공하는 applet일 수 있다.

"Ranging Device"는 UWB 레인징을 수행할 수 있는 장치일 수 있다. 본 개시에서, Ranging Device는 IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa Device일 수 있다. Ranging Device는 UWB device로 지칭될 수 있다.

"UWB-enabled Application"는 UWB 서비스를 위한 어플리케이션일 수 있다. 예를 들면, UWB-enabled Application는 UWB 세션을 위한, OOB Connector 컴포넌트, Secure Service 컴포넌트 및/또는 UWB Service 컴포넌트를 구성하기 위한 Framework API를 이용하는 어플리케이션일 수 있다. "UWB-enabled Application"는 어플리케이션 또는 UWB 어플리케이션으로 약칭될 수 있다. UWB-enabled Application은 FiRa-enabled Application일 수 있다. Framework API는 Framework와 통신하기 위해 UWB-enabled Application에 의해 사용되는 API일 수 있다.

"Framework"는 Profile에 대한 access, 개별 UWB 설정 및/또는 통지를 제공하는 컴포넌트일 수 있다. Framework는 예컨대, Profile Manager 컴포넌트, OOB Connector 컴포넌트, Secure Service 컴포넌트, UWB Service 컴포넌트, OOB Service 컴포넌트를 포함하는 논리적 소프트웨어 컴포넌트(logical software components)의 집합(collection)일 수 있다. Framework는 FiRa Framework일 수 있다.

"OOB Connector"는 Ranging Device 간의 OOB(out-of-band) 연결(예컨대, BLE 연결)을 설정하기 위한 소프트웨어 컴포넌트일 수 있다. OOB Connector는 FiRa OOB Connector일 수 있다.

"Profile"은 UWB 및 OOB 설정 파라미터(configuration parameter)의 미리 정의된 세트일 수 있다. Profile은 FiRa Profile 또는 Custom Profile일 수 있다.

"Profile Manager"는 Ranging Device에서 이용가능한 프로필을 구현하는 소프트웨어 컴포넌트일 수 있다. Profile Manager는 FiRa Profile Manager일 수 있다.

"Out-Of-Band(OOB)"는 하위(underlying) 무선 기술로서 UWB를 사용하지 않는 데이터 통신일 수 있다.

"OOB Subsystem"은 UWB 장치들 간의 OOB 연결을 설정하는 역할을 수행 하드웨어 컴포넌트일 수 있다.

"Ranging Data Set(RDS)"는 confidentiality, authenticity 및 integrity가 보호될 필요가 있는 UWB 세션을 설정하기 위해 요구되는 데이터(예컨대, UWB 세션 키, 세션 ID 등)일 수 있다.

"Secure Channel"는 overhearing 및 tampering을 방지하는 데이터 채널일 수 있다.

"Secure Component"은 UWBS와 인터페이싱하는 정의된 보안 레벨을 갖는 엔티티(예컨대, SE (Secure Element) 또는 TEE(Trusted Execution Environment))일 수 있다.

"SE"는 Ranging Device 내 Secure Component로서 사용될 수 있는 tamper-resistant secure hardware component일 수 있다. SE는 예컨대, embedded SE(eSE)일 수 있다.

"Secure Ranging"은 강한 암호화 동작을 통해 생성된 STS에 기초한 레인징일 수 있다.

"Secure Service"는 Secure Component와 인터페이싱하기 위한 소프트웨어 컴포넌트일 수 있다.

"Secure Messaging"은 보안 채널에서 운반되는 구조화된 데이터의 교환일 수 있다.

"Secure Messaging Authentication Key"는 Secure Messaging을 수행하기 위해 보안 채널을 설정하기 위해 사용되는 키일 수 있다.

"Secure Messaging Session Keys"는 Secure Messaging을 보장하기 위해 보안 채널이 설정된 후에 사용되는 키일 수 있다.

"Privacy Selection Key"는 인증 동안, privacy를 보호하기 위해 사용되는 키일 수 있다.

"UWB Service"는 UWBS에 대한 접속(access)을 제공하는 소프트웨어 component일 수 있다.

"UWB Session"은 Controller 및 Controlee가 UWB를 통해 통신을 시작할때부터 통신을 정지할 때까지의 기간일 수 있다. UWB Session은 레인징, 데이터 전달 또는 레인징/데이터 전달 둘 모두를 포함할 수 있다.

"UWB Session ID"는 컨트로러와 컨트롤리 사이에 공유되는, UWB Session을 식별하는 ID(예컨대, 32 비트의 정수)일 수 있다.

"UWB Session Key"는 UWB Session을 보호하기 위해 사용되는 키일 수 있다. UWB Session Key는 STS를 생성하기 위해 사용될 수 있다. UWB Session Key는 UWB Ranging Session Key(URSK)일 수 있고, 세션 키로 약칭될 수 있다.

"UWB Subsystem(UWBS)"는 UWB PHY 및 MAC 레이어(스펙)를 구현하는 하드웨어 컴포넌트일 수 있다. UWBS는 Framework에 대한 인터페이스 및 RDS를 검색하기 위한 Secure Component에 대한 인터페이스를 가질 수 있다.

*“UWB 메시지”는 UWB 장치(예컨대, ERDEV)에 의해 전송되는 payload IE를 포함하는 메시지일 수 있다. UWB 메시지는 예컨대, RIM(ranging initiation message), RRM(ranging response message), RFM(ranging final message), CM(control message), MRM(measurement report message), RRRM(Ranging Result Report Message), CUM(control update message), OWR(one-way ranging) 메시지와 같은 메시지일 수 있다. 필요한 경우, 복수의 메시지가 하나의 메시지로 병합될 수 있다.

“OWR”는 레인징 장치와 하나 이상의 다른 레인징 장치 사이에 한 방향으로 전송되는 메시지들을 이용하는 레인징 방식일 수 있다. OWR은 TDoA(Time Difference of Arrival)(예: DL(downlink)-TDoA 또는 UL(uplink)-TDoA)를 측정하기 위해 사용될 수 있다. 추가적으로, OWR은 TDoA를 측정하는 것이 아닌, 수신 측에서 AoA를 측정하기 위해 사용될 수 있다. 이 경우, 하나의 Advertiser와 하나의 observer 쌍이 이용될 수 있다.

“TWR”는 두 장치 간 레인징 메시지의 교환을 통해 ToF(time of flight)를 측정하여, 두 장치 간 상대적 거리를 추정할 수 있는 레인징 방식일 수 있다. TWR 방식은 double-sided two-way ranging(DS-TWR) 및 single-sided two-way ranging(SS-TWR) 중 하나일 수 있다. SS-TWR은 한번의 round-trip time measurement를 통해 레인징을 수행하는 절차일 수 있다. 예를 들면, SS-TWR은 initiator에서 responder로의 RIM의 전송 동작, 및 responder에서 initiator로의 RRM의 전송 동작을 포함할 수 있다. DS-TWR은 두 번의 round-trip time measurement를 통해 레인징을 수행하는 절차일 수 있다. 예를 들면, DS-TWR은 initiator에서 responder로의 RIM의 전송 동작, responder에서 initiator로의 RRM의 전송 동작 및 intiator에서 responder로의 RFM의 전송 동작을 포함할 수 있다. 이러한 레인징 교환(레인징 메시지 교환)을 통해, ToF(time of flight)가 계산될 수 있고, 두 장치간의 거리가 추정될 수 있다. 한편, TWR 과정에서, 측정된 AoA 정보(예컨대, AoA azimuth result, AoA elevation result)는 RRRM 또는 다른 메시지를 통해 다른 레인징 장치로 전달될 수 있다. 본 개시에서, TWR은 UWB TWR로 지칭될 수 있다.

도 1은 전자 장치를 개략적으로 도시한 블록도이다.

도 1을 참조하면, 네트워크 환경(100)에서 전자 장치(101)는 제 1 네트워크(198)(예: 근거리 무선 통신 네트워크)를 통하여 전자 장치(102)와 통신하거나, 또는 제 2 네트워크(199)(예: 원거리 무선 통신 네트워크)를 통하여 전자 장치(104) 또는 서버(108)와 통신할 수 있다. 일 실시 예에 따르면, 전자 장치(101)는 서버(108)를 통하여 전자 장치(104)와 통신할 수 있다. 일 실시 예에 따르면, 전자 장치(101)는 프로세서(120), 메모리(130), 입력 모듈(150), 음향 출력 모듈(155), 디스플레이 모듈(160), 오디오 모듈(170), 센서 모듈(176), 인터페이스(177), 연결 단자(178), 햅틱 모듈(179), 카메라 모듈(180), 전력 관리 모듈(188), 배터리(189), 통신 모듈(190), 가입자 식별 모듈(196), 또는 안테나 모듈(197)을 포함할 수 있다. 어떤 실시 예에서는, 전자 장치(101)에는, 이 구성요소들 중 적어도 하나(예: 연결 단자(178))가 생략되거나, 하나 이상의 다른 구성요소가 추가될 수 있다. 어떤 실시 예에서는, 이 구성요소들 중 일부들(예: 센서 모듈(176), 카메라 모듈(180), 또는 안테나 모듈(197))은 하나의 구성요소(예: 디스플레이 모듈(160))로 통합될 수 있다.

프로세서(120)는, 예를 들면, 소프트웨어(예: 프로그램(140))를 실행하여 프로세서(120)에 연결된 전자 장치(101)의 적어도 하나의 다른 구성요소(예: 하드웨어 또는 소프트웨어 구성요소)를 제어할 수 있고, 다양한 데이터 처리 또는 연산을 수행할 수 있다. 일 실시 예에 따르면, 데이터 처리 또는 연산의 적어도 일부로서, 프로세서(120)는 다른 구성요소(예: 센서 모듈(176) 또는 통신 모듈(190))로부터 수신된 명령 또는 데이터를 휘발성 메모리(132)에 저장하고, 휘발성 메모리(132)에 저장된 명령 또는 데이터를 처리하고, 결과 데이터를 비 휘발성 메모리(134)에 저장할 수 있다. 일 실시 예에 따르면, 프로세서(120)는 메인 프로세서(121)(예: 중앙 처리 장치 또는 어플리케이션 프로세서) 또는 이와는 독립적으로 또는 함께 운영 가능한 보조 프로세서(123)(예: 그래픽 처리 장치, 신경망 처리 장치(NPU: neural processing unit), 이미지 시그널 프로세서, 센서 허브 프로세서, 또는 커뮤니케이션 프로세서)를 포함할 수 있다. 예를 들어, 전자 장치(101)가 메인 프로세서(121) 및 보조 프로세서(123)를 포함하는 경우, 보조 프로세서(123)는 메인 프로세서(121)보다 저전력을 사용하거나, 지정된 기능에 특화되도록 설정될 수 있다. 보조 프로세서(123)는 메인 프로세서(121)와 별개로, 또는 그 일부로서 구현될 수 있다.

보조 프로세서(123)는, 예를 들면, 메인 프로세서(121)가 인액티브(예: 슬립) 상태에 있는 동안 메인 프로세서(121)를 대신하여, 또는 메인 프로세서(121)가 액티브(예: 어플리케이션 실행) 상태에 있는 동안 메인 프로세서(121)와 함께, 전자 장치(101)의 구성요소들 중 적어도 하나의 구성요소(예: 디스플레이 모듈(160), 센서 모듈(176), 또는 통신 모듈(190))와 관련된 기능 또는 상태들의 적어도 일부를 제어할 수 있다. 일 실시예에 따르면, 보조 프로세서(123)(예: 이미지 시그널 프로세서 또는 커뮤니케이션 프로세서)는 기능적으로 관련 있는 다른 구성요소(예: 카메라 모듈(180) 또는 통신 모듈(190))의 일부로서 구현될 수 있다. 일 실시 예에 따르면, 보조 프로세서(123)(예: 신경망 처리 장치)는 인공지능 모델의 처리에 특화된 하드웨어 구조를 포함할 수 있다. 인공지능 모델은 기계 학습을 통해 생성될 수 있다. 이러한 학습은, 예를 들어, 인공지능이 수행되는 전자 장치(101) 자체에서 수행될 수 있고, 별도의 서버(예: 서버(108))를 통해 수행될 수도 있다. 학습 알고리즘은, 예를 들어, 지도형 학습(supervised learning), 비지도형 학습(unsupervised learning), 준지도형 학습(semi-supervised learning) 또는 강화 학습(reinforcement learning)을 포함할 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은, 복수의 인공 신경망 레이어들을 포함할 수 있다. 인공 신경망은 심층 신경망(DNN: deep neural network), CNN(convolutional neural network), RNN(recurrent neural network), RBM(restricted boltzmann machine), DBN(deep belief network), BRDNN(bidirectional recurrent deep neural network), 심층 Q-네트워크(deep Q-networks) 또는 상기 중 둘 이상의 조합 중 하나일 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은 하드웨어 구조 이외에, 추가적으로 또는 대체적으로, 소프트웨어 구조를 포함할 수 있다.

메모리(130)는, 전자 장치(101)의 적어도 하나의 구성요소(예: 프로세서(120) 또는 센서 모듈(176))에 의해 사용되는 다양한 데이터를 저장할 수 있다. 데이터는, 예를 들어, 소프트웨어(예: 프로그램(140)) 및, 이와 관련된 명령에 대한 입력 데이터 또는 출력 데이터를 포함할 수 있다. 메모리(130)는, 휘발성 메모리(132) 또는 비 휘발성 메모리(134)를 포함할 수 있다.

프로그램(140)은 메모리(130)에 소프트웨어로서 저장될 수 있으며, 예를 들면, 운영 체제(142), 미들웨어(144) 또는 어플리케이션(146)을 포함할 수 있다.

입력 모듈(150)은, 전자 장치(101)의 구성요소(예: 프로세서(120))에 사용될 명령 또는 데이터를 전자 장치(101)의 외부(예: 사용자)로부터 수신할 수 있다. 입력 모듈(150)은, 예를 들면, 마이크, 마우스, 키보드, 키(예: 버튼), 또는 디지털 펜(예: 스타일러스 펜)을 포함할 수 있다.

음향 출력 모듈(155)은 음향 신호를 전자 장치(101)의 외부로 출력할 수 있다. 음향 출력 모듈(155)은, 예를 들면, 스피커 또는 리시버를 포함할 수 있다. 스피커는 멀티미디어 재생 또는 녹음 재생과 같이 일반적인 용도로 사용될 수 있다. 리시버는 착신 전화를 수신하기 위해 사용될 수 있다. 일 실시 예에 따르면, 리시버는 스피커와 별개로, 또는 그 일부로서 구현될 수 있다.

디스플레이 모듈(160)은 전자 장치(101)의 외부(예: 사용자)로 정보를 시각적으로 제공할 수 있다. 디스플레이 모듈(160)은, 예를 들면, 디스플레이, 홀로그램 장치, 또는 프로젝터 및 해당 장치를 제어하기 위한 제어 회로를 포함할 수 있다. 일 실시예에 따르면, 디스플레이 모듈(160)은 터치를 감지하도록 설정된 터치 센서, 또는 상기 터치에 의해 발생되는 힘의 세기를 측정하도록 설정된 압력 센서를 포함할 수 있다.

오디오 모듈(170)은 소리를 전기 신호로 변환시키거나, 반대로 전기 신호를 소리로 변환시킬 수 있다. 일 실시 예에 따르면, 오디오 모듈(170)은, 입력 모듈(150)을 통해 소리를 획득하거나, 음향 출력 모듈(155), 또는 전자 장치(101)와 직접 또는 무선으로 연결된 외부 전자 장치(예: 전자 장치(102))(예: 스피커 또는 헤드폰)를 통해 소리를 출력할 수 있다.

센서 모듈(176)은 전자 장치(101)의 작동 상태(예: 전력 또는 온도), 또는 외부의 환경 상태(예: 사용자 상태)를 감지하고, 감지된 상태에 대응하는 전기 신호 또는 데이터 값을 생성할 수 있다. 일 실시 예에 따르면, 센서 모듈(176)은, 예를 들면, 제스처 센서, 자이로 센서, 기압 센서, 마그네틱 센서, 가속도 센서, 그립 센서, 근접 센서, 컬러 센서, IR(infrared) 센서, 생체 센서, 온도 센서, 습도 센서, 또는 조도 센서를 포함할 수 있다.

인터페이스(177)는 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 직접 또는 무선으로 연결되기 위해 사용될 수 있는 하나 이상의 지정된 프로토콜들을 지원할 수 있다. 일 실시 예에 따르면, 인터페이스(177)는, 예를 들면, HDMI(high definition multimedia interface), USB(universal serial bus) 인터페이스, SD카드 인터페이스, 또는 오디오 인터페이스를 포함할 수 있다.

연결 단자(178)는, 그를 통해서 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 물리적으로 연결될 수 있는 커넥터를 포함할 수 있다. 일 실시예에 따르면, 연결 단자(178)는, 예를 들면, HDMI 커넥터, USB 커넥터, SD 카드 커넥터, 또는 오디오 커넥터(예: 헤드폰 커넥터)를 포함할 수 있다.

햅틱 모듈(179)은 전기적 신호를 사용자가 촉각 또는 운동 감각을 통해서 인지할 수 있는 기계적인 자극(예: 진동 또는 움직임) 또는 전기적인 자극으로 변환할 수 있다. 일 실시 예에 따르면, 햅틱 모듈(179)은, 예를 들면, 모터, 압전 소자, 또는 전기 자극 장치를 포함할 수 있다.

카메라 모듈(180)은 정지 영상 및 동영상을 촬영할 수 있다. 일 실시 예에 따르면, 카메라 모듈(180)은 하나 이상의 렌즈들, 이미지 센서들, 이미지 시그널 프로세서들, 또는 플래시들을 포함할 수 있다.

전력 관리 모듈(188)은 전자 장치(101)에 공급되는 전력을 관리할 수 있다. 일 실시 예에 따르면, 전력 관리 모듈(188)은, 예를 들면, PMIC(power management integrated circuit)의 적어도 일부로서 구현될 수 있다.

배터리(189)는 전자 장치(101)의 적어도 하나의 구성요소에 전력을 공급할 수 있다. 일 실시 예에 따르면, 배터리(189)는, 예를 들면, 재충전 불가능한 1차 전지, 재충전 가능한 2차 전지 또는 연료 전지를 포함할 수 있다.

통신 모듈(190)은 전자 장치(101)와 외부 전자 장치(예: 전자 장치(102), 전자 장치(104), 또는 서버(108)) 간의 직접(예: 유선) 통신 채널 또는 무선 통신 채널의 수립, 및 수립된 통신 채널을 통한 통신 수행을 지원할 수 있다. 통신 모듈(190)은 프로세서(120)(예: 어플리케이션 프로세서)와 독립적으로 운영되고, 직접(예: 유선) 통신 또는 무선 통신을 지원하는 하나 이상의 커뮤니케이션 프로세서를 포함할 수 있다. 일 실시 예에 따르면, 통신 모듈(190)은 무선 통신 모듈(192)(예: 셀룰러 통신 모듈, 근거리 무선 통신 모듈, 또는 GNSS(global navigation satellite system) 통신 모듈) 또는 유선 통신 모듈(194)(예: LAN(local area network) 통신 모듈, 또는 전력선 통신 모듈)을 포함할 수 있다. 이들 통신 모듈 중 해당하는 통신 모듈은 제 1 네트워크(198)(예: 블루투스, 와이파이(Wi-Fi: wireless fidelity) direct 또는 IrDA(infrared data association)와 같은 근거리 통신 네트워크) 또는 제 2 네트워크(199)(예: 레거시 셀룰러 네트워크, 5G 네트워크, 차세대 통신 네트워크, 인터넷, 또는 컴퓨터 네트워크(예: LAN 또는 WAN)와 같은 원거리 통신 네트워크)를 통하여 외부의 전자 장치(104)와 통신할 수 있다. 이런 여러 종류의 통신 모듈들은 하나의 구성요소(예: 단일 칩)로 통합되거나, 또는 서로 별도의 복수의 구성요소들(예: 복수 칩들)로 구현될 수 있다. 무선 통신 모듈(192)은 가입자 식별 모듈(196)에 저장된 가입자 정보(예: 국제 모바일 가입자 식별자(IMSI))를 이용하여 제 1 네트워크(198) 또는 제 2 네트워크(199)와 같은 통신 네트워크 내에서 전자 장치(101)를 확인 또는 인증할 수 있다.

무선 통신 모듈(192)은 4G 네트워크 이후의 5G 네트워크 및 차세대 통신 기술, 예를 들어, NR 접속 기술(new radio access technology)을 지원할 수 있다. NR 접속 기술은 고용량 데이터의 고속 전송(eMBB(enhanced mobile broadband)), 단말 전력 최소화와 다수 단말의 접속(mMTC(massive machine type communications)), 또는 고신뢰도와 저지연(URLLC(ultra-reliable and low-latency communications))을 지원할 수 있다. 무선 통신 모듈(192)은, 예를 들어, 높은 데이터 전송률 달성을 위해, 고주파 대역(예: mmWave 대역)을 지원할 수 있다. 무선 통신 모듈(192)은 고주파 대역에서의 성능 확보를 위한 다양한 기술들, 예를 들어, 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO(multiple-input and multiple-output)), 전차원 다중입출력(FD-MIMO: full dimensional MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 또는 대규모 안테나(large scale antenna)와 같은 기술들을 지원할 수 있다. 무선 통신 모듈(192)은 전자 장치(101), 외부 전자 장치(예: 전자 장치(104)) 또는 네트워크 시스템(예: 제 2 네트워크(199))에 규정되는 다양한 요구사항을 지원할 수 있다. 일 실시예에 따르면, 무선 통신 모듈(192)은 eMBB 실현을 위한 Peak data rate(예: 20Gbps 이상), mMTC 실현을 위한 손실 Coverage(예: 164dB 이하), 또는 URLLC 실현을 위한 U-plane latency(예: 다운링크(DL) 및 업링크(UL) 각각 0.5ms 이하, 또는 라운드 트립 1ms 이하)를 지원할 수 있다.

안테나 모듈(197)은 신호 또는 전력을 외부(예: 외부의 전자 장치)로 송신하거나 외부로부터 수신할 수 있다. 일 실시 예에 따르면, 안테나 모듈(197)은 서브스트레이트(예: PCB) 위에 형성된 도전체 또는 도전성 패턴으로 이루어진 방사체를 포함하는 안테나를 포함할 수 있다. 일 실시 예에 따르면, 안테나 모듈(197)은 복수의 안테나들(예: 어레이 안테나)을 포함할 수 있다. 이런 경우, 제 1 네트워크(198) 또는 제 2 네트워크(199)와 같은 통신 네트워크에서 사용되는 통신 방식에 적합한 적어도 하나의 안테나가, 예를 들면, 통신 모듈(190)에 의하여 상기 복수의 안테나들로부터 선택될 수 있다. 신호 또는 전력은 상기 선택된 적어도 하나의 안테나를 통하여 통신 모듈(190)과 외부의 전자 장치 간에 송신되거나 수신될 수 있다. 어떤 실시 예에 따르면, 방사체 이외에 다른 부품(예: RFIC(radio frequency integrated circuit))이 추가로 안테나 모듈(197)의 일부로 형성될 수 있다.

다양한 실시 예들에 따르면, 안테나 모듈(197)은 mmWave 안테나 모듈을 형성할 수 있다. 일 실시 예에 따르면, mmWave 안테나 모듈은 인쇄 회로 기판, 상기 인쇄 회로 기판의 제 1 면(예: 아래 면)에 또는 그에 인접하여 배치되고 지정된 고주파 대역(예: mmWave 대역)을 지원할 수 있는 RFIC, 및 상기 인쇄 회로 기판의 제 2 면(예: 윗면 또는 측 면)에 또는 그에 인접하여 배치되고 상기 지정된 고주파 대역의 신호를 송신 또는 수신할 수 있는 복수의 안테나들(예: 어레이 안테나)을 포함할 수 있다.

상기 구성요소들 중 적어도 일부는 주변 기기들간 통신 방식(예: 버스, GPIO(general purpose input and output), SPI(serial peripheral interface), 또는 MIPI(mobile industry processor interface))을 통해 서로 연결되고 신호(예: 명령 또는 데이터)를 상호간에 교환할 수 있다.

일 실시 예에 따르면, 명령 또는 데이터는 제 2 네트워크(199)에 연결된 서버(108)를 통해서 전자 장치(101)와 외부의 전자 장치(104)간에 송신 또는 수신될 수 있다. 외부의 전자 장치(102, 또는 104) 각각은 전자 장치(101)와 동일한 또는 다른 종류의 장치일 수 있다. 일 실시 예에 따르면, 전자 장치(101)에서 실행되는 동작들의 전부 또는 일부는 외부의 전자 장치들(102, 104, 또는 108) 중 하나 이상의 외부의 전자 장치들에서 실행될 수 있다. 예를 들면, 전자 장치(101)가 어떤 기능이나 서비스를 자동으로, 또는 사용자 또는 다른 장치로부터의 요청에 반응하여 수행해야 할 경우에, 전자 장치(101)는 기능 또는 서비스를 자체적으로 실행시키는 대신에 또는 추가적으로, 하나 이상의 외부의 전자 장치들에게 그 기능 또는 그 서비스의 적어도 일부를 수행하라고 요청할 수 있다. 상기 요청을 수신한 하나 이상의 외부의 전자 장치들은 요청된 기능 또는 서비스의 적어도 일부, 또는 상기 요청과 관련된 추가 기능 또는 서비스를 실행하고, 그 실행의 결과를 전자 장치(101)로 전달할 수 있다. 전자 장치(101)는 상기 결과를, 그대로 또는 추가적으로 처리하여, 상기 요청에 대한 응답의 적어도 일부로서 제공할 수 있다. 이를 위하여, 예를 들면, 클라우드 컴퓨팅, 분산 컴퓨팅, 모바일 에지 컴퓨팅(MEC: mobile edge computing), 또는 클라이언트-서버 컴퓨팅 기술이 이용될 수 있다. 전자 장치(101)는, 예를 들어, 분산 컴퓨팅 또는 모바일 에지 컴퓨팅을 이용하여 초저지연 서비스를 제공할 수 있다. 다른 실시예에 있어서, 외부의 전자 장치(104)는 IoT(internet of things) 기기를 포함할 수 있다. 서버(108)는 기계 학습 및/또는 신경망을 이용한 지능형 서버일 수 있다. 일 실시예에 따르면, 외부의 전자 장치(104) 또는 서버(108)는 제 2 네트워크(199) 내에 포함될 수 있다. 전자 장치(101)는 5G 통신 기술 및 IoT 관련 기술에 기반하여 지능형 서비스(예: 스마트 홈, 스마트 시티, 스마트 카, 또는 헬스 케어)에 적용될 수 있다.

본 문서에 개시된 다양한 실시 예들에 따른 전자 장치는 다양한 형태의 장치가 될 수 있다. 전자 장치는, 예를 들면, 휴대용 통신 장치(예: 스마트폰), 컴퓨터 장치, 휴대용 멀티미디어 장치, 휴대용 의료 기기, 카메라, 웨어러블 장치, 또는 가전 장치를 포함할 수 있다. 본 문서의 실시 예에 따른 전자 장치는 전술한 기기들에 한정되지 않는다.

본 문서의 다양한 실시 예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시 예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", "A 또는 B 중 적어도 하나", "A, B 또는 C", "A, B 및 C 중 적어도 하나", 및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.

본 문서의 다양한 실시 예들에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로와 같은 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 두 개 이상의 기능을 수행하는, 상기 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일 실시 예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.

본 문서의 다양한 실시 예들은 기기(machine)(예: 전자 장치(101)) 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리(136) 또는 외장 메모리(138))에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어(예: 프로그램(140))로서 구현될 수 있다. 예를 들면, 기기(예: 전자 장치(101))의 프로세서(예: 프로세서(120))는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장 매체는, 비일시적(non-transitory) 저장 매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장 매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장 매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.

일 실시 예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory(CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두 개의 사용자 장치들(예: 스마트 폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.

다양한 실시 예들에 따르면, 상기 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있으며, 복수의 개체 중 일부는 다른 구성요소에 분리 배치될 수도 있다. 다양한 실시 예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 상기 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.

도 2a는 본 개시의 일 실시예에 따른 UWB 장치의 예시적인 아키텍쳐를 나타낸다.

본 개시에서, UWB 장치(200)는 UWB 통신을 지원하는 전자 장치(예: FiRa 장치)일 수 있다. 예컨대, UWB 장치(200)는 도 1의 전자 장치(101)의 일 예일 수 있다.

도 2a의 실시예에서, UWB 장치(200)는 UWB 세션을 통해 다른 UWB 장치와 상호작용(interact)할 수 있다.

또한, UWB 장치(200)는 UWB-enabled Application(210)과 UWB Framework(220) 간의 인터페이스인 제1 인터페이스(Interface #1)를 구현할 수 있고, 제1 인터페이스는 UWB 장치(200) 상의 UWB-enabled application(110)이 미리 정해진 방식으로 UWB 장치(200)의 UWB 성능들을 사용할 수 있게 해준다. 일 실시예에서, 제1 인터페이스는 Framework API 또는 proprietary interface일 수 있으나, 이에 한정되지 않는다.

또한, UWB 장치(200)는 UWB Framework(210)와 UWB 서브시스템(UWBS)(230) 간의 인터페이스인 제2 인터페이스(Interface #2)를 구현할 수 있다. 일 실시예에서, 제2 인터페이스는 UCI(UWB Command Interface) 또는 proprietary interface일 수 있으나, 이에 한정되지 않는다.

도 2a를 참조하면, UWB 장치(200)는 UWB-enabled Application(210), Framework(UWB Framework)(220), 및/또는 UWB MAC Layer와 UWB Physical Layer를 포함하는 UWBS(230)를 포함할 수 있다. 실시예에 따라서는, UWB 장치의 일부 구성요소가 UWB 장치에 포함되지 않거나, 추가적인 구성요소(예컨대, 보안 컴포넌트)가 더 포함될 수 있다. 또한, UWB 장치의 복수의 구성요소가 하나의 구성요소로 병합될 수 있다.

UWB-enabled Application(210)(예: FiRa-enabled Application)은 제1 인터페이스를 이용하여 UWBS(230)에 의한 UWB 세션의 설정을 트리거링할 수 있다. 또한, UWB-enabled Application(210)은 미리 정의된 프로필(profile) 중 하나를 사용할 수 있다. 예를 들면, UWB-enabled Application(210)은 FiRa에 정의된 프로필(FiRa 프로필) 중 하나 또는 custom profile을 사용할 수 있다. UWB-enabled Application(210)은 제1 인터페이스를 사용하여, 서비스 발견(Service discovery), 레인징 통지(Ranging notifications), 및/또는 에러 컨디션(Error conditions)과 같은 관련 이벤트를 다룰 수 있다.

Framework(220)는 Profile에 대한 access, 개별 UWB 설정 및/또는 통지를 제공할 수 있다. 또한, Framework(220)는 UWB 레인징 및 트랜잭션 수행을 위한 기능, UWB-enabled Application(210) 및 UWBS(230)에 대한 인터페이스 제공 기능 또는 UWB 장치(200)의 위치 추정 기능과 같은 기능 중 적어도 하나를 지원할 수 있다. Framework(220)는 UWB-enabled Application(210)의 설정에 따라 관련 컴포넌트들(예컨대, 보안 컴포넌트, OOB 서브시스템(OOBS), USBS(230) 등)을 관리할 수 있다. Framework(220)는 소프트웨어 컴포넌트의 집합일 수 있다. 상술한 것처럼, UWB-enabled Application(210)은 제1 인터페이스를 통해 프레임워크(220)와 인터페이싱할 수 있고, 프레임워크(220)는 제2 인터페이스를 통해 UWBS(230)와 인터페이싱할 수 있다.

한편, 본 개시에서, UWB-enabled Application(210) 및/또는 Framework(220)는 어플리케이션 프로세서(AP)(또는, 프로세서)에 의해 구현될 수 있다. 따라서, 본 개시에서, UWB-enabled Application(210) 및/또는 Framework(220)의 동작은 AP(또는, 프로세서)에 의해 수행되는 것으로 이해될 수 있다. 본 개시에서, 프레임워크는 AP, 프로세서로 지칭될 수 있다.

UWBS(230)는 UWB MAC Layer(예: FiRa MAC)와 UWB Physical Layer(예: FiRa PHY)를 포함하는 하드웨어 컴포넌트일 수 있다. UWBS(230)는 UWB 세션 관리를 수행하고, 다른 UWB 장치의 UWBS와 통신할 수 있다. UWBS(230)는 제2 인터페이스를 통해 Framework(120)와 인터페이싱할 수 있고, Secure Component로부터 보안 데이터를 획득할 수 있다. 일 실시예에서, Framework(또는, 어플리케이션 프로세서)(220)는 UCI를 통해서 명령(command)을 UWBS(230)로 전달할 수 있고, UWBS(230)는 명령에 대한 응답(response)를 Framework(220)에 전달할 수 있다. UWBS(230)는 UCI를 통해 Framework(120)에 통지(notification)을 전달할 수도 있다.

도 2b는 본 개시의 일 실시예에 따른 UWB 장치의 프레임워크의 예시적인 구성을 나타낸다.

도 2b의 UWB 장치는 도 2a의 UWB 장치의 일 예일 수 있다.

도 2b을 참조하면, Framework(220)는 예컨대, Profile Manager(221), OOB Connector(s)(222), Secure Service(223), UWB service(224)및/또는 OOB service(s)(225)와 같은 소프트웨어 컴포넌트를 포함할 수 있다.

Profile Manager(221)(예: FiRa Profile Manager)는 UWB 장치 상에서 이용 가능한 프로필(들)(예: FiRa 프로필)을 관리할 수 있다. 여기서, 프로필은 UWB 장치 사이에 통신을 설정하기 위해 요구되는 파라미터의 집합일 수 있다. 예를 들면, 프로필은 어떤 OOB 보안 채널이 사용되는지를 나타내는 파라미터, UWB/OOB 설정 파라미터, 특정 보안 컴포넌트의 사용이 맨데토리(mandatory)인지를 나타내는 파라미터 및/또는 ADF의 파일 구조와 관련된 파라미터를 포함할 수 있다. 또한, Profile Manager(221)는 UWB-enabled Application(210)로부터의 UWB 및 OOB 설정 파라미터들을 추상화할 수 있다. Profile Manager(221)는 OOB Connector(222)와 상호작용하고, OOB 연결을 통해 교환되는 APDU들을 Secure Component(240)로 라우팅하는 방법을 제공할 수 있다.

UWB-enabled Application(210)(예: FiRa-enabled Application)은 제1 인터페이스(예컨대, Framework API)를 통해 Profile Manager(221)와 통신할 수 있다.

OOB Connector(222)(예: FiRa OOB Connector)는 다른 UWB 장치와 OOB 연결을 설정 및 관리하기 위한 역할을 수행할 수 있다. OOB Connector(222)는 OOB 서브시스템(250)과 통신하기 위해 OOB service(225)를 이용할 수 있다. UWB 장치는 UWB 세션을 설정하기 위해 필요한 정보를 교환하기 위해 요구되는 APDU 전달(transfer)들을 수행하기 위해 OOB 연결을 사용할 수 있다.

Secure Service(223)는 Secure Component(240)와 인터페이싱하는 역할을 수행할 수 있다. Secure Component(240)는 UWB 보안 레인징을 위한 설정 파라미터(들) 및/또는 보안 관련 키(들)을 저장/관리할 수 있다.

UWB Service(224)는 UWBS(230)와 인터페이싱하는 역할을 수행할 수 있다. UWB Service(224)는 제2 인터페이스(예컨대, UCI)를 구현함으로써, Profile Manager(321)에서 UWBS(230)로의 access를 제공할 수 있다.

OOB Service(225)는 OOB 서브시스템(250)와 인터페이싱하는 역할을 수행할 수 있다.

도 3은 본 개시의 일 실시예에 따른 UWB 장치의 프레임워크를 통한 UWB-enabled application의 예시적인 동작을 설명하기 위한 도면이다.

도 3의 UWB 장치(300)는 도 2a 또는 도 2b의 UWB 장치의 일 예일 수 있다. 예컨대, UWB 장치(300)는 FiRa 장치일 수 있다.

도 3을 참조하면, UWB 장치(300)는 적어도 하나의 UWB-enabled Application(311,312,313), UWB Framework(320), UWBS(330), 및/또는 Secure Component(340)를 포함할 수 있고, UWB 장치(300)의 구성요소들의 설명은 도 2에서 상술한 설명을 참조할 수 있다.

UWB 장치(300)는 적어도 하나의 서비스 제공자(service provider: SP)에 의해 제공되는 적어도 하나의 UWB-enabled application을 포함할 수 있다. 예를 들면, 도시된 것처럼, UWB 장치(300)는 UWB-enabled application #1(SP APP #1)(311), UWB-enabled application #2(SP APP #2)(312) 및 UWB-enabled application #3(SP APP #3)(313)을 포함할 수 있다. 이때, 서비스 제공자 별로 개별 UWB-enabled Application이 제공되거나, 복수의 UWB-enabled Application이 하나의 서비스 제공자에 의해 제공될 수도 있다.

각 UWB-enabled application(311,312,313)은 해당 UWB-enabled application 의 서비스를 제공할 수 있다. 예를 들면, UWB-enabled application #1(SP APP #1)(311)는 제1 서비스(서비스 #1)를 제공할 수 있고, UWB-enabled application #2(SP APP #2)(312)는 제2 서비스(서비스 #2)를 제공할 수 있고, UWB-enabled application #3(SP APP #3)(313)는 제3 서비스(서비스 #3)을 제공할 수 있다.

UWB-enabled application(311,312,313)은 UWB Framework API(예: FiRa Framework API)를 통해 Framework(320)(예: FiRa Framework)와 통신할 수 있다. 또한, UWB-enabled application(311,312,313)은 Framework(320)를 통해 UWBS(330) 및 보안 컴포넌트(340)에 접속할 수 있다. 예를 들면, UWB-enabled application(311,312,313)는 Framework(320)의 Profile Manger(321) 및 UWB Service(324)를 통해 UWBS(330)에 접속할 수 있고, Framework(320)의 Profile Manger(321) 및 Secure Service(323)을 통해 Secure Component(340)에 접속할 수 있고, Framework(320)의 Profile Manger(321) 및 OOB Service(325)를 통해 OOB 서브시스템에 접속할 수 있다.

보안 컴포넌트(340)는 예컨대, eSE와 같은 SE일 수 있고, SE는 UWB Applet(341), SUS Applet(342) 및/또는 적어도 하나의 Service Applet(343-1,343-2,343-3)을 포함할 수 있다. Service Applet은 SP Applet으로 지칭될 수도 있다.

UWB Applet(341)(예: FiRa Applet)은 RDS를 안전하게(securely) 생성하기 위해 요구되는 ADF를 포함할 수 있고, RDS를 SUS Applet(312)를 통해 UWBS(330)로 전달할 수 있다.

한편, 서비스 제공자는 해당 서비스의 서비스 데이터를 다루기 위해 별개의(separate) Service Applet을 사용할 수 있다. 예를 들면, 도시된 것처럼, SP APP #1(311)의 서비스 데이터를 위한 제1 Service Applet(343-1), SP APP #2(312)의 서비스 데이터를 위한 제2 Service Applet(343-2), 및 SP APP #3(313)의 서비스 데이터를 위한 제3 Service Applet(343-3)이 보안 컴포넌트(340) 내에 포함될 수 있다. 각 Service Applet(343-1, 343-2, 343-3)은 UWB Applet(341)을 이용하여 RDS를 SUS Applet(312)를 통해 UWBS(330)로 전달하거나, 또는 SUS internal API를 이용하여 SUS Applet(312)과 직접 통신할 수 있다.

도 4는 본 개시의 일 실시예에 따른 Secure element를 포함하는 UWB 장치들 간의 데이터를 교환하는 방법을 나타낸다.

도 4를 참조하면, 제1 UWB 장치(4100)는 UWB-enabled Application(4110), UWB Framework(4120), UWBS(4130), Secure Component(4140) 및 OOBS(4150)을 포함할 수 있고, 제2 UWB 장치(4200)는 UWB-enabled Application(4210), UWB Framework(4220), UWBS(4230), Secure Component(4240) 및 OOBS(4250)을 포함할 수 있다. 각 UWB 장치(4100,4200)의 구성요소들의 설명은 도 2 내지 3에서 상술한 설명을 참조할 수 있다.

도 4의 실시예의 Secure Component(4140,4240)는 프레임워크(4120,4220) 외부에 위치하는 Secure element(예: eSE)일 수 있다.

각 UWB 장치(4100,4200)의 Secure Component(4140,4240)는 서비스 프로바이더(400)에 의해 제공된 서비스 데이터를 저장/관리하기 위한 Service Applet(4143, 4243)을 각각 포함할 수 있다. Service Applet(4143, 4243)의 설명은 도 3의 상술한 설명을 참조할 수 있다.

도 4의 실시예에서, Secure Component(4140,4240)의 UWB Applet(4141,4241)(예: FiRa Applet)은 두 UWB 장치(4100,4200) 사이의 보안 채널 및 UWB 세션을 설정하기 위해 사용되지만, Service Applet(4143, 4243)에 포함된 서비스 데이터는 UWB Applet(4141,4241)의 사용 없이 두 UWB 장치(4100,4200) 사이에서 교환될 수 있다. 예를 들면, UWB Applet(4141,4241)을 이용하여 두 UWB 장치(4100,4200) 사이에 보안 채널(예: OOB 보안 채널) 및 UWB 세션이 설정된 후에, Service Applet(4143, 4243)은 서비스 데이터를 전달하기 위해 설정된 채널을 이용할 수 있다. 실시예로서, Service Applet(4143, 4243)은 특정 조건(예컨대, 미리 설정된 레인징 조건)이 만족되는 경우, 서비스 데이터를 전달하기 위해 설정된 채널을 이용할 수 있다.

두 UWB 장치(4100,4200) 중 하나는 service initiator로서 동작할 수 있다. service initiator의 역할은 UWB 역할(예컨대, UWB initiator 또는 UWB responder)과 독립적일 수 있다. service initiator인 UWB 장치는 UWB Applet(4141, 4241)의 터널 인터페이스를 통해 다른 UWB 장치의 Service Applet에 접속하기 위해 보안 채널을 이용할 수 있다. 보안 채널 메시지(들)로 랩핑된(wrapped) Service Applet APDU(들)은 UWB Applet(4141,4241)에서 언-랩핑(un-wrapped)되지 않고, Service Applet(4143,4243)으로 전달될 수 있다. 마찬가지 방식으로, Service Applet(4143,4243)의 응답은 보안 채널 메시지(들)로 랩핑되어 다른 UWB 장치로 전달될 수 있다. 이러한 설정된 보안 채널을 통한 Service Applet APDU(들)의 전달은 서비스 데이터 트랜잭션이 UWB 세션과 연관됨을 보장할 수 있다. 두 UWB 장치(4100,4200) 간의 보안 채널을 설정하는 절차의 일 예는 도 5를 참조하여 이하에서 설명한다.

도 5는 본 개시의 일 실시예에 따른 UWB 장치들 간의 보안 채널을 설정하는 방법을 나타낸다.

UWB 장치는 다른 UWB 장치의 데이터를 읽고 업데이트 하기 위해, 다음 엘리먼트들에 접근할 수 있어야 한다:

- 데이터를 포함하는 ADF의 OID

- 읽고 업데이트 될 엘리먼트에 대한 태그 넘버

- 보안 채널을 설정하기 위해 요구되는 보안 메시지 인증 키들(Secure Messaging Authentication Keys)

이하에서는 도 5를 참조하여, UWB 장치가 보안 채널을 설정하고, 다른 UWB 장치의 ADF 내의 데이터를 읽거나 업데이트 하는 절차에 대하여 설명한다.

단계 (1): 제1 UWB 장치(4100)는 제2 UWB 장치(4200)로 Application Data Structure를 선택하기 위한 SELECT 명령을 전송할 수 있다. SELECT 명령은 well-known Application ID를 사용하여 Application Data Structure를 선택하기 위해 UWB 장치에 의해 사용되는 APDU 명령일 수 있다. Application Data Structure의 일 예는 도 6을 참조하여 이하에서 설명한다.

단계 (2): 제1 UWB 장치(4100)는 제1 UWB 장치(4100)가 다루기를(handle) 의도하는 ADF들의 후보 OID들의 리스트(시퀀스)를 포함하는 SELECT_ADF 명령을 제2 UWB 장치(4200)로 전송할 수 있다. SELECT_ADF 명령은 UWB 장치가 읽거나 또는 쓰기를 의도하는 Application Data Structure 내의 ADF를 선택하기 위해 UWB 장치에 의해 사용되는 APDU 명령일 수 있다.

단계 (3): 프라이버시 선택 키들(Privacy Selection Keys)을 사용하여, 제1 UWB 장치(4100)는 요청된 OID들 중 하나가 제2 UWB 장치(4200)에 존재하는지를 확인하기 위해, SELECT_ADF 명령에 대한 응답을 복호화(decrypt)할 수 있다. 요청된 OID들 중 하나가 제2 UWB 장치(4200)에 존재하는 경우, 제1 UWB 장치(4100)는 상기 응답으로부터 Diversifier를 추출하고, 보안 메시지 인증 키들을 계산 또는 다이버시파잉(diversify)하기 위해 Diversifier를 이용할 수 있다.

단계 (4): 제1 UWB 장치(4100)는 제2 UWB 장치(4200)로부터 랜덤 챌린지를 획득하기 위해 GENERAL_AUTHENTICATE 명령(파트 1)을 제2 UWB 장치(4200)로 전송할 수 있다. 랜덤 챌린지에 대한 응답으로, 제1 UWB 장치(4100)는 제2 UWB 장치(4200)와 보안 채널을 설정하기 위해 암호화된 챌린지를 이용하여 GENERAL_AUTHENTICATE 명령(파트 2)을 제2 UWB 장치(4200)로 전송할 수 있다. GENERAL_AUTHENTICATE 명령은 GDF 내의 선택된 ADF와의 보안 채널을 설정하기 위해 UWB 장치에 의해 사용되는 APDU 명령일 수 있다.

단계 (5): 보안 메시지 인증 키가 correct 한 경우, GENERAL_AUTHENTICATE 명령(파트 2)에 대한 응답(APDU 응답)은 제2 UWB 장치(4200)과의 특정 보안 채널 세션에서 전송을 보안하기 위해 사용될 보안 메시지 세션 키들(Secure Messaging Session Keys)를 제1 UWB 장치(4100)가 계산하도록 허용하는 데이터를 포함할 수 있다. 이후 모든 후속 명령들은 보안 메시지 세션 키를 이용하여 보호될 수 있다.

단계 (6): 제1 UWB 장치(4100)는 특정 오브젝트의 컨텐츠를 읽기 위해 GET_DATA 명령 또는 오브젝트들을 업데이트 하기 위해 PUT_DATA 명령을 제2 UWB 장치(4200)로 전송할 수 있다. GET_DATA 명령은 UWB 장치(또는, UWB-enabled Application)가 데이터를 읽는 것을 허용하는 APDU 명령일 수 있다. PUT_DATA 명령은 UWB 장치(또는, UWB-enabled Application)가 ADF에 데이터를 쓰는 것을 허용하는 APDU 명령일 수 있다.

이렇게 설정된 보안 채널(예: OOB 보안 채널)을 통해, 예컨대, UWB 세션을 설정하기 위한 데이터 및/또는 서비스 데이터가 UWB 장치 간에 교환될 수 있다. OOB 보안 채널을 통한 데이터 교환은 OOB 메시지를 이용하여 수행될 수 있다. OOB 메시지는 controlee의 정보를 controller로 전달하기 위한 CONTROLEE_INFO 메시지, 및/또는 UWB 세션 관련 데이터를 controller로부터 controlee로 전달하기 위한 SESSION_DATA 메시지를 포함할 수 있다.

CONTROLEE_INFO 메시지는 UWB_CAPABILITY 데이터 오브젝트, UWB_CONTROLEE_PREFERENCE 데이터 오브젝트, SESSION_KEY_INFO 데이터 오브젝트, 및/또는 UWB_REGULATORY 데이터 오브젝트를 포함할 수 있다.

SESSION_DATA 메시지는 UWB_CONFIGURATION 데이터 오브젝트, SESSION_KEY_INFO 데이터 오브젝트 및/또는 UWB_REGULATORY 데이터 오브젝트를 포함할 수 있다.

도 6은 본 개시의 일 실시예에 따른 Application Data Structure의 일 예를 나타낸다.

도 6에서는, 설명의 편의를 위해, Application Data Structure가 두 개의 ADF를 포함하는 것으로 가정하지만, 이에 한정되지 않는다. 예를 들면, Application Data Structure는 단일 또는 다양한 수의 ADF를 포함할 수 있다.

도 6을 참조하면, Application Data Structure 내에 포함되는 데이터/정보는 태그 넘버를 사용하여 접근될 수 있는 데이터 오브젝트(들)로서 구조화될 수 있다. 데이터 오브젝트(DO)는 오픈 액세스로 구현되거나, 키로 보호되도록 구현될 수 있다. 키로 보호되도록 구현되는 경우, DO에 접근하기 위해 유효한 상호 인증이 수행될 필요가 있다.

도 6의 예시에서, Application Data Structure는 루트 레벨의 UWB Info 데이터 오브젝트(600)를 포함할 수 있다. UWB Info 데이터 오브젝트(600)는 UWB_CAPABILITY 데이터 오브젝트(601) 및/또는 UWB_REGULATORY 데이터 오브젝트를 포함할 수 있다. Application Data Structure 또는 GDF는 Application ID에 의해 식별될 수 있다.

UWB_CAPABILITY 데이터 오브젝트(601)는 UWB 장치의 성능들을 제공하기 위해 존재하고 프로비저닝되는 데이터 오브젝트일 수 있다. 이 데이터 오브젝트(601)에 의해 정의된 것을 벗어나는 설정은 UWB 레인징 세션 설정을 위해 사용될 수 없다. 이 데이터 오브젝트(601)는 UCI를 통해 획득된 UWBS 성능 정보에 기초하여 프레임워크에 의해 설정될 수 있다.

UWB_REGULATORY 데이터 오브젝트(602)는 UWB 장치의 규제 정보를 설정하기 위해 프레임워크에 의해 사용되는 데이터 오브젝트일 수 있다. 이러한 루트 레벨에 접근하기 위해, 상술한 SELECT 명령이 사용될 수 있다.

Application Data Structure는 ADF 레벨의 데이터 오브젝트(들)을 포함할 수 있다. 예를 들면, 도시된 것처럼, OID1에 의해 식별되는 ADF1 데이터 오브젝트(610) 및 OID2에 의해 식별되는 ADF2 데이터 오브젝트(620)가 Application Data Structure에 포함될 수 있다.

각 ADF 데이터 오브젝트(610,620)는 UWB Controlee Info 데이터 오브젝트(611,621), UWB Session Data 데이터 오브젝트(612,622) 및/또는 적어도 하나의 추가 데이터 오브젝트(613.623)를 포함할 수 있다.

UWB Controlee Info 데이터 오브젝트(611,621)는 UWB 장치의 UWB 성능들을 지정하는 UWB_CAPABILITY 데이터 오브젝트 및 규제 정보를 지정하는 UWB_REGULATORY 데이터 오브젝트를 포함할 수 있다. UWB Controlee Info 데이터 오브젝트(611,621)에 포함되는 UWB_CAPABILITY 데이터 오브젝트 및 UWB_REGULATORY 데이터 오브젝트는 루트 레벨의 데이터 오브젝트인 UWB_CAPABILITY 데이터 오브젝트(601) 및 UWB_REGULATORY 데이터 오브젝트(602)의 내용의 복제(copy)일 수 있다.

또한, UWB Controlee Info 데이터 오브젝트(611,621)는 선호되는 설정을 지정하는 UWB_CONTROLEE_PREFERENCE 데이터 오브젝트 및/또는 세션 암호화를 위한 데이터(예컨대, dynamic STS key or static STS key material)를 더 포함할 수 있다.

UWB Session Data 데이터 오브젝트(612,622)는 UWB 세션 설정을 위해 Controller에 의해 사용되는 데이터 오브젝트일 수 있다. UWB Session Data 데이터 오브젝트(612,622)는 UWB_SESSION_ID 데이터 오브젝트, UWB_SUB_SESSION_ID 데이터 오브젝트, CONFIGURATION_PARAMETERS 데이터 오브젝트, STATIC_RANGING_INFO 데이터 오브젝트, SECURE_RANGING_INFO 데이터 오브젝트, 및/또는 REGULATORY_INFORMATION 데이터 오브젝트를 포함할 수 있다.

적어도 하나의 추가 데이터 오브젝트(613,622)는 예컨대, 서비스 데이터를 포함하는 Service Data 데이터 오브젝트를 포함할 수 있다.

한편, 실시예에 따라서는, Service Data 데이터 오브젝트가 보안 엘리먼트 내 UWB 어플릿(예컨대, 도 4의 UWB applet(4143,4243))에 포함된 ADF에 내에 포함되지 않고, 별도의 데이터 오브젝트로 구성될 수 있다. 이 경우, Service Data 데이터 오브젝트는 보안 엘리먼트 내의 Service Applet(예컨대, 도 4의 Service Applet(4141,4241))에 포함되거나, UWB-enabled Application(예컨대, 도 4의 UWB-enabled Application(4110,4210))에 포함되거나, 또는 후술할 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트에 포함될 수 있다.

도 7은 본 개시의 일 실시예에 따른, UWB 장치가 보안 엘리먼트를 이용하여 데이터를 관리하는 방법을 나타낸다.

도 7을 참조하면, UWB 장치(700)는 UWB-enabled Application(710), Framework(720), 및/또는 보안 컴포넌트(730)을 포함할 수 있다. Framework(720)는 Profile Manager(721), OOB Connector(722), 및/또는 Secure Service(723)을 포함할 수 있다. UWB 장치(400)의 구성요소들의 설명은 도 2 내지 4에서 상술한 설명을 참조할 수 있다.

도 7의 실시예에서, UWB 장치(700)는 보안 컴포넌트(730)로서, 보안 엘리먼트(예: eSE)를 포함한다.

실시예로서, UWB 장치에서 이용가능한 보안 컴포넌트에 관련된 정보는 OOB 커넥터에 대한 커넥터 성능 정보(예: FiRa Connector Capabilities 정보)에 포함되어 다른 UWB 장치로 전송될 수 있다.

일 예로, 커넥터 성능 정보는 OOB 통신을 위해 이용가능한 적어도 하나의 보안 컴포넌트에 대한 리스트 정보(보안 컴포넌트 리스트 정보)를 포함할 수 있다. 보안 컴포넌트 리스트 정보는 SECID((Secure Component Identifier) 리스트 정보(List of SECIDs)로 지칭될 수 있다. 보안 컴포넌트 리스트 정보는 OOB 통신을 위해 이용가능한 각 보안 컴포넌트에 대하여, 해당 보안 컴포넌트의 ID(SECID)를 지시하는 SECID 정보, 해당 보안 컴포넌트의 보안 컴포넌트의 타입을 지시하는 보안 컴포넌트 타입 정보, 및/또는 해당 보안 컴포넌트의 보안 컴포넌트의 프로토콜 타입을 지시하는 보안 컴포넌트 프로토콜 타입 정보를 각각 포함할 수 있다.

아래 표 1은 커넥터 성능 정보에 포함되는 보안 컴포넌트 정보의 일 예를 나타낸다.

Field name	Size (bits)	Coding explanation
List of SECIDs	variable (multiple of 16)	A device which is updating or exposing the FiRa Connector Capabilities data structure should list in this field all specific SECIDs available for OOB communication. The administrative SECID with 7-bit value 0b0000001 is implicit and shall not be listed here. Each SECID consumes 16 bits coded as follows (from the most significant bit): 1 bit - Static indication (if given SECID is granted to be always available it shall be set to value 0b1, otherwise it is set to value 0b0). 7 bits - SECID value (unsigned integer in the range 2..127, values 0 and 1 are reserved). See FiRa Connector Message structure definition for more details. 4 bits - Secure Component type (value 0..15, see separate section for encoding rules). 4 bits - Secure Component protocol type (value 0..15, see separate section for encoding rules).

아래 표 2는 보안 컴포넌트 타입 정보의 일 예를 나타낸다.

Value	Secure Component type
0 (0b0000)	Reserved for future use.
1 (0b0001)	eSE (non-removable, as defined by [6])
2 (0b0010)	UICC (removable, as defined by [7])
3 (0b0011)	Discrete eUICC (removable, as defined by [8])
4 (0b0100)	Discrete eUICC (non-removable, as defined by [8])
5 (0b0101)	Integrated eUICC (non-removable, as defined by [8])
6 (0b0110)	SW emulated SC (e.g. Android HCE)
7..14 (0b0111..0b1110)	Reserved for future use.
15 (0b1111)	Vendor proprietary.

실시예로서, UWB 장치는 OOB 메시지(예: BLE Advertisement 메시지/패킷)을 통해 커넥터 성능 정보 또는 보안 컴포넌트 리스트 정보를 전송 또는 방송할 수 있다. 일 예로, 커넥터 성능 정보 또는 보안 컴포넌트 리스트 정보는 BLE Advertisement 메시지/패킷의 UWB indication data 필드에 포함될 수 있다.

실시예로서, UWB 장치는 UWB 메시지(예: Advertisement를 위한 OWR 메시지)를 통해 커넥터 성능 정보 또는 보안 컴포넌트 리스트 정보를 전송 또는 방송할 수 있다.

도 7을 참조하여, 보안 엘리먼트(예컨대, eSE)를 이용하여 데이터를 관리하는 절차는 다음 단계들을 포함할 수 있다. 데이터는 UWB 세션을 설정하기 위한 데이터 및 서비스 데이터를 포함할 수 있고, 상기 데이터는 보안 엘리먼트에 저장될 수 있다. 도 7에서는, 보안 컴포넌트 타입 정보가 eSE를 지정하는 값으로 설정된 것으로 가정한다.

[단계 1]

UWB-enabled Application(710)은 UWB-enabled Application(710)의 해당 서비스 또는 해당 서비스에 대한 프로필을 initiation하기 위한 service initiation API(예: FIRAServiceInit API)를 호출할 수 있다. service initiation API는 UWB-enabled Application가 UWB 장치에 launch 된 경우, 해당 UWB 장치의 UWB-enabled Application에 의해 호출될 수 있다.

FIRAServiceInit API는 UWB-enabled Application(710)이 프레임워크(720)에 자신을 등록하고, 특정 UWB 프로필(FiRa 프로필)을 인스턴스화하거나, UWB-enabled Application(710)에서 요청된 특정 설정을 적용하도록 요청하기 위해 UWB-enabled Application(710)에 의해 사용될 수 있다. FIRAServiceInit API는 ServiceConfiguration 오브젝트, UWBConfiguration 오브젝트 및/또는 OOBConfiguration 오브젝트를 포함할 수 있다.

ServiceConfiguration 오브젝트는 UWB 프로필(FiRa Profile)을 인스턴스화하고, 특정 어플리케이션에 맵핑하기 위해 사용될 수 있다. 아래 표 3은 ServiceConfiguration 오브젝트의 일 예일 수 있다.

Parameter	Type	Description
serviceID	Integer	Identifier for the FiRa Profile that the FiRa-enabled Application supports. For FiRa Profiles, the ServiceID defined in the corresponding FiRa Profile specification is mandatory and the UWB Configuration and OOB Configuration do not need to be set (as they are specified in the FiRa Profile specification and known to the FiRa Framework). For custom settings, the FiRa-enabled Application shall set the ServiceID to 255 and transfer UWB configuration and OOB configuration.
profilePriority	Integer	Priority of the FiRa Profile instance. It is used by the FiRa Framework to allocate resources appropriately. 1 = highest priority; 100 = lowest priority The use of the Profile priority is platform dependent.
serviceDeploymentOption	Integer	Indicates the chosen deployment option 1= service deployment scenario 1 2= service deployment scenario 2 3= service deployment scenario 3 4= service deployment scenario 4 5= service deployment scenario 5 ...
serviceAppletID	Integer	AID of Service Applet to be used by the FiRa Framework.
serviceAdfID	Integer	Tag OID of the ADF used for service deployement

UWBConfiguration 오브젝트는 예컨대, 커스텀 프로필이 사용되는 경우에, 개별 UWB 파라미터들을 설정하기 위해 사용될 수 있다. 아래 표 4는 UWBConfiguration의 일 예일 수 있다.

Parameter	Type	Description
UWBRole	Integer	Used to indicate selected UWB roles: 0: Controlee & Responder 1: Controlee & Initiator 2: Controller & Responder 3: Controller & Initiator
rangingRoundUsage	Integer	0: One way ranging (OWR). 1: Single-Sided Two-Way Ranging (SS-TWR) with Deferred Mode. 2: Double-Sided Two-Way Ranging (DS-TWR) with Deferred Mode. 3: Single-Sided Two-Way Ranging (SS-TWR) with Non-deferred Mode. 4: Double-Sided Two-Way Ranging (DS-TWR) with Non-deferred Mode
multiNodeMode	Integer	0: Unicast Ranging 1: One-to-many Ranging 2: Many-to-many Ranging
RFRAMEConfiguration	Integer	0: SP0 1: SP1 2: RFU 3: SP3
STSConfig	Integer	0: Static STS 1: Dynamic STS using a single UWB Session Key for all Responders 2: Dynamic STS using Responder Specific Sub-session Key
roundHopping	Boolean	0: Round Hopping disabled 1: Round Hopping enabled
scheduledMode	Integer	0: Contention Based Ranging 1: Time Scheduled Ranging
maximumContentionPhaseLength	Integer	Maximum number of slots for Contention-Based ranging
ToFReport	Boolean	0: No ToF Report 1: ToF Report
AoAAzimuthReport	Boolean	0: No AoA Azimuth Report 1: AoA Azimuth Report
AoAElevationReport	Boolean	0: No AoA Elevation Report 1: AoA Elevation Report
AoAFOMReport	Boolean	0: No AoA FOM Report 1: AoA FOM Report
blockStriding	Boolean	0: No Block Striding 1: Blocks may be skipped upon Controller's decision
slotDuration	Integer	Unsigned integer that specifies the duration of a ranging slot in the unit of RSTU
slotsPerRangingRound	Integer	Number of slots per ranging round. This parameter is not applicable for contention based ranging. This parameter is used to specify the ranging round duration in multiples of SlotDuration
rangingInterval	Integer	Unsigned integer that specifies the duration of a ranging block.Expressed in the unit of 1200 RSTU which is 1 ms between beginning of one ranging round to the beginning of the next. Minimum ranging interval should be at least the duration of one ranging round length.
channelNumber	Integer	Unsigned integer that specifies channel number to be used. Allowed values include: [5, 6, 8, 9, 10, 12, 13, 14]
preambleCodeIndex	Integer	Ci Code index Value range: 9 - 12 for BPRF Mode Value range: 25 - 32 for HPRF Mode
SP0PHYParameterSet	Integer	SP0 PHY parameter set# according to Table 2 or Table 3 of FiRa Consortium UWB PHY Technical Requirements (see Appendix E for supported set pairs)
SP1PHYParameterSet	Integer	SP1 PHY parameter set# according to Table 2 or Table 3 of FiRa Consortium UWB PHY Technical Requirements (see Appendix E for supported set pairs)
SP3PHYParameterSet	Integer	SP3 PHY parameter set# according to Table 2 or Table 3 of FiRa Consortium UWB PHY Technical Requirements (see Appendix E for supported set pairs)
maxRetry	Integer	Unsigned integer that specifies the number of failed ranging rounds before timing out.Note: The number of retries must be chosen so that the total retry time does not exceed 10 s due to FCC rules.
constraintLengthConvolutionalCode	Boolean	0: K=3 (Systematic convolutional encoding),1: K=7 (Non-systematic convolutional encoding) Note: For BPRF mode, systematic convolutional encoding shall be used.
UWBInitiationTime	Integer	Time taken for UWB initiation (in the unit of 1200 RSTU) Controller shall transmit UWB frames after UWB initiation time from transmitting timing of this parameter Controller should set UWB initiation time in consideration of UWB initiation time of Controlee
keyRotationRate	Integer	Defines n, with 2^n being the rotation rate of secDerivedPayloadKey, secDerivedAuthenticationIv, and secDerivedAuthenticationKey. If this parameter has value 0x3F, then no key rotation will be applied.
MACFCSType	Enum	0: 2 octets CRC will be used for FCS in MAC footer 1: 4 Octets CRC will be used for FCS in MAC footer Note: For BPRF mode, 2 octets CRC is used.
RangingRoundControl	Integer	This parameter is used to tell the UWBS which messages will be included in a Ranging Round. The parameter is a bit map with the following definition: b0 = Ranging Result Report Message (RRRM) If set to 1 (default), an initiator shall schedule an RRRM in the Ranging Device Management List (RDML). If set to 0, an initiator shall not schedule an RRRM in the RDML This bit shall be ignored by a responder; responders shall follow the message sequence provided in the RDML. b1 = Control Message (CM) If set to 1 (default), an initiator shall send a separate CM and a responder shall expect a separate CM If set to 0, an initiator shall not send a separate CM and a responder shall not expect a separate CM b6 to b2 = RFU b7 = Measurement Report Message (MRM) If set to 0 (default), the controller shall schedule the MRM to be sent from the initiator to the controlee(s) in the RDML. If set to 1, the controller shall schedule the MRM to be sent from the responder(s) to the initiator in the RDML. This bit shall be ignored by a Controlee. Controlees shall follow the message sequence provided in the RDML.
vendorID	Integer	16 bits unsigned integer, Unique ID of vendor. Vendor in this context is the FiRa enabled application provider. This is used to set phyVupper64[15:0] as defined in FiRa MAC technical requirements
staticSTSIV	ByteArray[6]	Array of 6 bytes. Pre-defined arbitrary value chosen by the vendor for FiRa enabled application on FiRa Smart Device and FiRa device. This is used to set vUpper64[63:16] as defined in FiRa MAC technical requirements.

OOBConfiguration 오브젝트는 예컨대, 커스텀 프로필이 사용되는 경우, 개별 OOB 파라미터들을 설정하기 위해 사용될 수 있다. 아래 표 5는 OOBConfiguration 오브젝트의 일 예일 수 있다.

Parameters	Type	Description
OOBType	Integer	This indicates the type of OOB connection used for FiRa Service establishment o None - value '0' o Bluetooth LE - value '1' o RFU - all other values
OOBBLERole	Integer	This indicates the role of FiRa Device for OOB GAP and GATT· Scanner/Central & GATT Client (CP) Value 0 · Advertiser/Peripheral & GATT Server (FCS) Value 1 · Peripheral Value 2 · Central. Value 3

UWB-enabled Application(710)는 FIRAServiceInit API를 이용하여, 상술한 FIRAServiceInit 파라미터들, 예컨대, ServiceConfiguration 오브젝트, UWBConfiguration 오브젝트, 및/또는 OOBConfiguration 오브젝트에 포함된 파라미터들을 프레임워크(720)로 전달할 수 있다. 예를 들면, 도시된 것처럼, FIRAServiceInit API를 통해, serviceDeploymentOption 파라미터의 값(예: serviceDeploymentOption=1), serviceAppletID의 파라미터(예: serviceAppletID =<0xA00000086746415000>)의 값 등이 프레임워크(720)으로 전달될 수 있다. serviceDeploymentOption 파라미터의 값 및 serviceAppletID의 파라미터의 값은 ServiceConfiguration 오브젝트에 포함될 수 있다.

[단계 2]

프레임워크(720)는 FIRAServiceInit에 대한 리턴 값을 UWB-enabled Application(710)로 전달할 수 있다. 실시예로서, 리턴 값은 serviceInstanceID 파라미터의 값 또는 statusCode 파라미터의 값을 포함할 수 있다. serviceInstanceID 파라미터는 Profile Manager(721)에 의해 할당된 128 비트의 해당 서비스 또는 프로필에 대한 Service Instance ID일 수 있다.

[단계 3]

UWB 장치(700)는 다른 UWB 장치와 보안 채널을 설정할 수 있다. UWB 장치 간의 보안 채널의 설정 절차는 도 5의 보안 채널 설정 절차를 따를 수 있다. 설정된 보안 채널을 통해, UWB Controlee Info 데이터 오브젝트, UWB Session Data 데이터 오브젝트 및/또는 Service Data 데이터 오브젝트가 두 UWB 장치의 보안 컴포넌트(예: eSE) 내의 FiRa Applet 및/또는 Service Applet들 사이에 교환될 수 있다. Service Applet은 상술한 ServiceConfiguration 오브젝트 내의 serviceAppletID 파라미터의 값에 의해 식별될 수 있다.

상술한 도 7의 실시예에 따른 데이터 관리 방법은 프레임워크 외부의 하드웨어 기반의 보안 컴포넌트(예: eSE)를 사용한다. 그러나, 실시예에 따라서는, UWB 장치에 프레임워크의 외부에 위치하는 별도의 하드웨어 기반의 보안 컴포넌트가 포함되지 않을 수 있다. 이 경우, 프레임워크 내에서 UWB 세션을 설정하기 위한 데이터 및/또는 서비스 데이터를 저장/관리하기 위한 소프트웨어 기반의 보안 컴포넌트가 프레임워크에 할당될 필요가 있다.

이하에서는, 프레임워크 내에 할당된 소프트웨어 기반의 보안 컴포넌트를 이용한 데이터 관리 방법에 대하여 설명한다.

도 8은 본 개시의 일 실시예에 따른, UWB 장치가 프레임워크 내의 보안 컴포넌트를 이용하여 데이터를 관리하는 방법을 나타낸다.

도 8을 참조하면, UWB 장치(800)는 UWB-enabled Application(810), Framework(820), 및/또는 보안 컴포넌트(830)을 포함할 수 있다. Framework(820)는 Profile Manager(821), OOB Connector(822), 및/또는 Secure Service(823)을 포함할 수 있다. UWB 장치(400)의 구성요소들의 설명은 도 2 내지 4에서 상술한 설명을 참조할 수 있다.

도 8의 실시예에서, UWB 장치(800)는 보안 컴포넌트로서, Framework(820) 내의 소프웨어(SW) 기반의 보안 컴포넌트(예: SW emulated SC)(830)를 포함한다.

실시예로서, UWB 장치에서 이용가능한 보안 컴포넌트에 관련된 정보는 OOB 커넥터(822)에 대한 커넥터 성능 정보(예: FiRa Connector Capabilities 정보)에 포함되어 다른 UWB 장치로 전송될 수 있다.

일 예로, 커넥터 성능 정보는 OOB 통신을 위해 이용가능한 적어도 하나의 보안 컴포넌트에 대한 리스트 정보(보안 컴포넌트 리스트 정보)를 포함할 수 있다. 보안 컴포넌트 리스트 정보는 SECID 리스트 정보(List of SECIDs)로 지칭될 수 있다. 보안 컴포넌트 리스트 정보는 OOB 통신을 위해 이용가능한 각 보안 컴포넌트에 대하여, 해당 보안 컴포넌트의 ID(Secure Component Identifier: SECID)를 지시하는 SECID 정보, 해당 보안 컴포넌트의 보안 컴포넌트의 타입을 지시하는 보안 컴포넌트 타입 정보, 및/또는 해당 보안 컴포넌트의 보안 컴포넌트의 프로토콜 타입을 지시하는 보안 컴포넌트 프로토콜 타입 정보를 각각 포함할 수 있다.

커넥터 성능 정보에 포함되는 보안 컴포넌트 정보의 일 예는 상기 표 1과 같을 수 있다.

소프트웨어(SW) 기반의 보안 컴포넌트의 타입을 포함하는 보안 컴포넌트 타입 정보의 일 예는 아래 표 6과 같을 수 있다.

Value	Secure Component type
0 (0b0000)	Reserved for future use.
1 (0b0001)	eSE (non-removable, as defined by [6])
2 (0b0010)	UICC (removable, as defined by [7])
3 (0b0011)	Discrete eUICC (removable, as defined by [8])
4 (0b0100)	Discrete eUICC (non-removable, as defined by [8])
5 (0b0101)	Integrated eUICC (non-removable, as defined by [8])
6 (0b0110)	SW emulated SC in TEE (e.g. Android HCE)
7 (0b0111)	SW emulated SC in Framework
8..14 (0b1000..0b1110)	Reserved for future use.
15 (0b1111)	Vendor proprietary.

도 8을 참조하여, 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트를 이용하여 데이터를 관리하는 절차는 다음 단계들을 포함할 수 있다. 데이터는 UWB 세션을 설정하기 위한 데이터 및 서비스 데이터를 포함할 수 있고, 상기 데이터는 보안 엘리먼트에 저장된다. 도 8에서는, 보안 컴포넌트 타입 정보가 "SW emulated SC in Framework"를 지정하는 값으로 설정된 것으로 가정한다.

[단계 1]

UWB-enabled Application(810)은 UWB-enabled Application(810)의 해당 서비스 또는 해당 서비스에 대한 프로필을 initiation하기 위한 service initiation API(예: FIRAServiceInit API)를 호출할 수 있다. service initiation API는 UWB-enabled Application가 UWB 장치에 launch 된 경우, 해당 UWB 장치의 UWB-enabled Application에 의해 호출될 수 있다.

FIRAServiceInit API는 UWB-enabled Application(810)이 프레임워크(820)에 자신을 등록하고, 특정 UWB 프로필(FiRa 프로필)을 인스턴스화하거나, UWB-enabled Application(810)에서 요청된 특정 설정을 적용하도록 요청하기 위해 UWB-enabled Application(810)에 의해 사용될 수 있다. FIRAServiceInit API는 ServiceConfiguration 오브젝트, UWBConfiguration 오브젝트 및/또는 OOBConfiguration를 포함할 수 있다.

ServiceConfiguration 오브젝트는 UWB 프로필(FiRa Profile)을 인스턴스화하고, 특정 어플리케이션에 맵핑하기 위해 사용될 수 있다. ServiceConfiguration 오브젝트는 표 3에 포함된 파라미터들의 일부 또는 전부를 포함할 수 있다. 실시예로서, ServiceConfiguration 오브젝트는 servicePackagename 파라미터를 더 포함할 수 있다. servicePackagename 파라미터는 UWB-enabled Application(810)의 Application ID의 값(예컨대, android package name)으로 설정될 수 있다.

UWBConfiguration 오브젝트는 예컨대, 커스텀 프로필이 사용되는 경우에, 개별 UWB 파라미터들을 설정하기 위해 사용될 수 있다. UWBConfiguration 오브젝트는 상기 표 4에 포함된 파라미터들의 일부 또는 전부를 포함할 수 있다.

OOBConfiguration 오브젝트는 예컨대, 커스텀 프로필이 사용되는 경우, 개별 OOB 파라미터들을 설정하기 위해 사용될 수 있다. OOBConfiguration 오브젝트는 상기 표 5에 포함된 파라미터들의 일부 또는 전부를 포함할 수 있다.

UWB-enabled Application(810)는 FIRAServiceInit API를 이용하여, 상술한 FIRAServiceInit 파라미터들, 예컨대, ServiceConfiguration 오브젝트, UWBConfiguration 오브젝트, 및/또는 OOBConfiguration 오브젝트에 포함된 파라미터들을 프레임워크(820)로 전달할 수 있다. 예를 들면, 도시된 것처럼, FIRAServiceInit API를 통해, serviceDeploymentOption 파라미터의 값(예: serviceDeploymentOption=5), serviceAppletID의 파라미터(예: serviceAppletID =<0xA00000086746415000>)의 값, serviceAdfID 파라미터의 값(예컨대, serviceAdfID 파라미터가 사용되지 않음을 나타내는 값(예: serviceADFID = <no use>), 및/또는 servicePackagename 파라미터 값(예컨대, UWB-enabled Application(810)에 의해 설정된 값) 등이 프레임워크(820)으로 전달될 수 있다.

실시예로서, ServiceConfiguration 오브젝트 내의 serviceAdfID 파라미터의 값이 serviceAdfID 파라미터가 사용되지 않음을 지시하는 값(예: serviceADFID = <no use>)으로 설정되거나, 또는 ServiceConfiguration 오브젝트 내에 serviceAdfID 파라미터가 포함되지 않는 경우, 프레임워크(820) 또는 프레임워크(820) 내의 Profile Manager(821)는 UWBConfiguration 오브젝트 내의 vendorID 파라미터의 값과, ServiceConfiguration 오브젝트 내의 serviceID 파라미터의 값을 이용하여 생성된 값을 serviceInstanceID 파라미터의 값으로 사용할 수 있다. serviceInstanceID 파라미터의 생성의 일 예는 도 10을 참조하여 이하에서 설명한다.

[단계 2]

프레임워크(820)는 FIRAServiceInit에 대한 리턴 값을 UWB-enabled Application(810)로 전달할 수 있다. 실시예로서, 리턴 값은 serviceInstanceID 파라미터의 값 또는 statusCode 파라미터의 값을 포함할 수 있다. serviceInstanceID 파라미터는 Profile Manager(821)에 의해 할당된 128 비트의 해당 서비스 또는 프로필에 대한 Service Instance ID일 수 있다.

[단계 3]

UWB-enabled Application(810)은 Provisioning API(예: DoProvisioning API)를 호출할 수 있다. Provisioning API는 프레임워크에 의한 ADF 생성 및 provisioning을 위해, UWB-enabled Application(810)에 의해 사용될 수 있다.

Provisioning API는 serviceInstanceID 파라미터 및/또는 adfKey 파라미터를 포함할 수 있다. Provisioning에서, adfKey 파라미터는 보안 채널 키(SCKey)로 사용될 수 있다.

UWB-enabled Application(810)에 의해 Provisioning API가 호출되는 경우, 프레임워크(820)는 프레임워크(830) 내의 소프트웨어 기반의 보안 컴포넌트 내에 ADF를 생성하고, ADF 내에 serviceInstanceID 파라미터의 값에 대응하는 프로필(또는, 서비스)에 대한 ServiceConfiguration 오브젝트, UWBConfiguration 오브젝트 및/또는 OOBConfiguration 오브젝트의 파라미터들의 값을 작성할 수 있다. 또한, 프레임워크(820)는 프레임워크(830) 내의 소프트웨어 기반의 보안 컴포넌트에 포함된 ADF 내에 다른 UWB 장치 내의 해당 보안 컴포넌트(예: 다른 UWB 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트)와 보안 채널을 생성하기 위해 필요한 키를 작성할 수 있다. 보안 채널을 생성하기 위해 필요한 키(보안 키)는 adfKey 파라미터에 의해 지정되는 adf key (ADF Specific Key)일 수 있다.

한편, eSE를 사용하는 도 7의 실시예의 경우, eSE를 관리하는 PA(Provisioning Authority) 또는 PA에 의해 인증된 SP가 ADF를 생성하기 때문에, 사전에 합의된 고정 값이 ADF ID로서 사용될 수 있다. 그러나, 도 8의 실시예의 경우, 프레임워크가 ADF를 생성하기 때문에 ADF ID가 UWB-enabled Application(810)와 사전 합의되기 어렵다. 따라서, 이 경우, UWB-enabled Application(810)에서 지정된 ADF ID의 값이 사용되는 대신에, 프레임워크에서 생성된 ADF ID의 값이 ADF를 식별하기 위해 사용된다.

실시예로서, 프레임워크(820) 또는 프레임워크의 Profile manager(821)는 미리 설정된 규칙에 따라 ADF ID를 생성할 수 있다.

예를 들면, 프레임워크(820) 또는 프레임워크의 Profile manager(821)는 UWBConfiguration 오브젝트 내의 vendorID 파라미터의 값과, ServiceConfiguration 오브젝트 내의 serviceID 파라미터의 값을 이용하여 생성된 Service Instance ID의 값을 ADF ID의 값으로 사용할 수 있다. 예컨대, 프레임워크(820) 또는 프레임워크의 Profile manager(821)는 UWBConfiguration 오브젝트 내의 vendorID 파라미터의 값과, ServiceConfiguration 오브젝트 내의 serviceID 파라미터의 값을 조합한 것을 입력으로 입력으로 Hash code Generation을 수행하여 획득된 출력을 ADF ID의 값으로 사용할 수 있다. 실시예로서, Hash code Generation을 위한 Hash Function (예: One way Hash Function)으로는, 예컨대, MD5, SHA256 등이 사용될 수 있다. Service Instance ID 생성 및 ADF ID 생성의 일 예는 도 10을 참조하여 이하에서 설명한다.

예를 들면, 프레임워크(820) 또는 프레임워크의 Profile manager(821)는 UWB-enabled Application(810)에 의해 설정된 servicePackagename 파라미터의 값을 이용하여 생성된 값을 ADF ID의 값으로 사용할 수 있다. 예컨대, 프레임워크(820) 또는 프레임워크의 Profile manager(821)는 UWB-enabled Application(810)에 의해 설정된 servicePackagename 파라미터의 값을 입력으로 Hash code Generation을 수행하여 획득된 출력을 ADF ID의 값으로 사용할 수 있다. 실시예로서, Hash code Generation을 위한 Hash Function (예: One way Hash Function)으로는, 예컨대, MD5, SHA256 등이 사용될 수 있다.

[단계 4]

UWB 장치(800)는 다른 UWB 장치와 보안 채널을 설정할 수 있다. UWB 장치 간의 보안 채널의 설정 절차는 도 5의 보안 채널 설정 절차를 따를 수 있다. 설정된 보안 채널을 통해, UWB Controlee Info 데이터 오브젝트, UWB Session Data 데이터 오브젝트 및/또는 Service Data 데이터 오브젝트가 두 UWB 장치의 프레임워크 내의 소브프웨어 기반의 보안 컴포넌트들 사이에 교환될 수 있다.

한편, 실시예에 따라서는, Service Data 데이터 오브젝트가 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트(830)에 포함되지 않고, UWB-enabled Application(810)에 포함될 수 있다.

상술한, 도 8의 실시예의 방법을 따르는 경우, non-Secure element 환경/조건에서도 Ranging이 가능해진다.

도 9는 본 개시의 일 실시에 따른 소프트웨어 기반의 보안 컴포넌트의 구성을 나타낸다.

도 9를 참조하면, 소프트웨어 기반의 보안 컴포넌트(예: SW emulated SC)(830)은 APDU 프로토콜 파서(831), 프로비저닝 매니저(832), 암호화 모듈(cypto module)(833) 및/또는 ADF 매니저(834)를 포함할 수 있다. 실시예로서, serviceDeploymentOption 파라미터의 값이 'serviceDeploymentOption=5'로 설정되고, 보안 컴포넌트 타입(Secure Component type) 정보/파라미터의 값이 'SW emulated SC in Framework'를 지시하는 값으로 설정된 경우, 소프트웨어 기반의 보안 컴포넌트(830)가 보안 컴포넌트로서 사용될 수 있다.

APDU 프로토콜 파서(831)는 OOB 커넥터(822)를 통해 전달되는 APDU(ADPU 명령 또는 APDU 응답)를 파싱하여, APDU에 포함된 데이터/정보를 획득하는 컴포넌트일 수 있다.

프로비저닝 매니저(832)는 데이터를 다른 UWB 장치로 프로비저닝하는 것을 관리하는 컴포넌트일 수 있다. 일 예로, 프로비저닝되는 데이터는 프레임워크에 의해 생성된 ADF에 관련된 데이터일 수 있다. 프로비저닝 매니저(832)는 ADF 생성 및 프로비저닝하는 역할을 수행함으로써, 프레임워크 또는 프레임워크 내의 소프트웨어 기반 보안 컴포넌트(SW emulated SC) 내에 보안 영역(secure domain)을 생성할 수 있다.

암호화 모듈(833)은 데이터/메시지에 대한 인증 및/또는 암호화/복호화를 수행하는 컴포넌트일 수 있다.

ADF 매니저(834)는 프레임워크에 의해 생성된 ADF를 관리하는 컴포넌트일 수 있다.

소프트웨어 기반의 보안 컴포넌트(830)에 저장되는 Application Data Structure (또는, GDF)는 도 6에 예시된 것과 동일한 구조를 가질 수 있다. 이때, Application Data Structure에 대한 Application ID(AID)는 도 7의 보안 컴포넌트(예: eSE)(730)에 저장되는 Application Data Structure에 대한 Application ID와 동일할 수 있다.

한편, 상술한 것처럼, eSE(730)를 사용하는 도 7의 실시예의 경우, eSE를 관리하는 PA(Provisioning Authority) 또는 PA에 의해 인증된 SP가 ADF를 생성하기 때문에, 사전에 합의된 고정 값이 ADF ID로서 사용될 수 있다. 그러나, 소프트웨어 기반의 보안 컴포넌트(830)를 이용하는 도 8의 실시예의 경우, 프레임워크가 ADF를 생성하기 때문에 ADF ID가 UWB-enabled Application(810)와 사전 합의되기 어렵다. 따라서, 이 경우, UWB-enabled Application(810)에서 지정된 ADF ID의 값이 사용되는 대신에, 프레임워크에서 생성된 ADF ID의 값이 사용된다.

실시예로서, 프레임워크 또는 프레임워크의 Profile manager는 미리 설정된 규칙에 따라 ADF ID를 생성할 수 있다.

예를 들면, 프레임워크 또는 프레임워크의 Profile manager는 UWBConfiguration 오브젝트 내의 vendorID 파라미터의 값과, ServiceConfiguration 오브젝트 내의 serviceID 파라미터의 값을 이용하여 생성된 Service Instance ID의 값을 ADF ID의 값으로 사용할 수 있다.

예를 들면, 프레임워크 또는 프레임워크의 Profile manager는 UWB-enabled Application(810)에 의해 설정된 servicePackagename 파라미터의 값을 이용하여 생성된 값을 ADF ID의 값으로 사용할 수 있다.

도 10은 본 개시의 일 실시예에 따른 서비스 인스턴스 ID를 생성하는 방법을 나타낸다.

도 10의 서비스 인스턴스 ID를 생성하는 방법은 예컨대, 보안 컴포넌트로서, 도 7 또는 도 8의 소프트웨어 기반의 보안 컴포넌트(830)를 사용하는 경우에 적용될 수 있으나, 이에 한정되지 않는다.

도 10을 참조하면, 프레임워크(예: 도 8의 프레임워크(820)) 또는 프레임워크 내 Profile Manager(예: 도 8의 Profile Manager(821))는 UWBConfiguration 오브젝트(예: 표 4의 UWBConfiguration 오브젝트) 내의 vendorID 파라미터의 값과, ServiceConfiguration 오브젝트(예: 표 3의 ServiceConfiguration 오브젝트) 내의 serviceID 파라미터의 값을 이용하여 serviceInstanceID 파라미터의 값을 생성할 수 있다.

실시예로서, 프레임워크 또는 Profile Manager가 serviceInstanceID 파라미터의 값을 생성하고, 이를 ADF의 ID(ADF ID)로 할당하는 절차는 다음의 동작들을 포함할 수 있다.

동작 1: UWB-enabled Application(예: 도 8의 UWB-enabled Application(810))에서 service initiation API(예: FIRAServiceInit API)를 호출하는 경우, 프레임워크 또는 Profile Manager는 UWBConfiguration 오브젝트 내의 vendorID 파라미터의 값과 ServiceConfiguration 오브젝트 내의 serviceID 파라미터의 값을 조합한 값을 Message(Input)(1010)으로 Hash code Generation 동작을 수행할 수 있다. 실시예로서, Hash code Generation을 위한 Hash Function (예: One way Hash Function)으로는, 예컨대, MD5, SHA256 등이 사용될 수 있다.

동작 2: 프레임워크 또는 Profile Manager는 Hash code Generation의 Digest(Output)(1020)의 크기를 serviceInstanceID 파라미터의 크기(예컨대, 128 비트)에 맞게 설정하고, 이 크기를 갖는 Digest(Output)(1020)를 serviceInstanceID 파라미터의 값으로 설정할 수 있다.

동작 3: 프레임워크 또는 Profile Manager는 생성된 serviceInstanceID 파라미터의 값을 해당 UWB-enabled Application에 할당된 프레임워크 내 소프트웨어 기반 보안 컴포넌트 내의 데이터 저장 영역을 지정하는 ADF ID로 설정할 수 있다. 예를 들면, UWB-enabled Application#1과 연관된 vendorID #1/serviceID (1011)를 이용하여 생성된 ServiceInstanceID#1(1021)가 해당 UWB-enabled Application#1에 대한 ADF1를 식별하는 OID(1031)로 설정될 수 있다.

한편, 상대 UWB 장치도 상술한 로직과 동일한 로직으로 serviceInstanceID 파라미터의 값을 생성하여, 이를 해당 UWB-enabled Application에 할당된 프레임워크 내 소프트웨어 기반 보안 컴포넌트 내의 데이터 저장 영역을 지정하는 ADF ID로 설정할 수 있다.

도 11은 본 개시의 일 실시예에 따른 UWB 장치가 UWB 세션을 관리하는 방법을 나타낸다.

도 11을 참조하면, UWB 장치는 UWB 지원(enabled) 어플리케이션의 서비스를 위한 설정 정보를 식별할 수 있다(1110).

UWB 장치는 상기 설정 정보에 기초하여, 상기 서비스에 대한 서비스 인스턴스 ID 정보를 생성할 수 있다(1120).

UWB 장치는 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트와 다른 UWB 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 사이의 보안 채널을 설정할 수 있다(1130).

UWB 장치는 상기 보안 채널을 통해 UWB 세션을 설정하기 위한 데이터를 상기 보안 컴포넌트들 사이에서 교환할 수 있다(1140).

실시예로서, 설정 정보는 서비스 설정 정보(예: ServiceConfiguration 오브젝트), UWB 설정 정보(예: UWBConfiguration 오브젝트) 또는 OOB 설정 정보(예: OOBConfiguration 오브젝트) 중 적어도 하나를 포함할 수 있다.

실시예로서, UWB 장치는 UWB 지원 어플리케이션이 상기 서비스를 위한 설정 정보를 프레임워크 API를 이용하여 상기 전자 장치의 프레임워크로 전달하고, 상기 전자 장치의 프레임워크가 상기 생성된 서비스 인스턴스 ID 정보를 상기 전자 장치의 UWB 지원 어플리케이션으로 전달하도록 제어할 수 있다.

실시예로서, UWB 장치는 보안 컴포넌트의 타입을 지시하는 보안 컴포넌트 타입 정보를 포함하는 광고(advertisement) 메시지를 상기 다른 전자 장치로 전송할 수 있다. 상기 보안 컴포넌트 정보는 상기 보안 컴포넌트의 타입이 상기 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트임을 지시하는 값으로 설정될 수 있다.

실시예로서, UWB 장치는 프레임워크가 상기 서비스 설정 정보에 포함된 서비스 ID 정보의 값 및 상기 UWB 설정 정보에 포함된 벤더 ID 정보의 값에 기초하여 상기 서비스 인스턴스 ID를 생성하도록 제어할 수 있다. 상기 서비스 ID 정보는 상기 UWB 지원 어플리케이션이 지원하는 프로필에 대한 식별 정보를 포함할 수 있다.

실시예로서, 상기 서비스 인스턴스 ID는, 상기 서비스 ID 정보의 값 및 상기 벤더 ID 정보의 값을 조합한 값을 입력으로 해시 코드 생성을 수행하여 획득된 출력에 대응할 수 있다.

실시예로서, 상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 내에 저장되는, 상기 UWB 지원 어플리케이션에 대한 ADF(Application Dedicated File)을 식별하기 위한 ADF ID 정보는 상기 서비스 인스턴스 ID 정보와 동일한 값으로 설정되며, 상기 ADF는 상기 UWB 세션을 설정하기 위한 데이터를 포함할 수 있다. 실시예로서, ADF는 상기 UWB 지원 어플리케이션을 제공한 서비스 제공자에 의해 정의된 서비스 데이터를 더 포함할 수 있다.

도 12는 본 개시의 일 실시예에 따른 UWB 장치의 구성을 나타낸다.

도 12는 본 개시의 일 실시예에 따른 UWB 장치의 구조를 도시한 도면이다.

도 12를 참고하면, 전자 장치는 송수신부 (1210), 제어부 (1220), 저장부 (1230)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.

송수신부 (1210)는 다른 엔티티와 신호를 송수신할 수 있다. 송수신부(1210)는 예컨대, UWB 레인징을 위한 데이터를 송수신할 수 있다.

제어부 (1220)은 본 개시에서 제안하는 실시예에 따른 전자 장치의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부 (1320)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(1220)는, 예컨대, 도 1 내지 11을 참조하여 설명한 UWB 장치의 동작을 제어할 수 있다.

저장부(1230)는 상기 송수신부 (1210)를 통해 송수신되는 정보 및 제어부 (1220)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부 (1230)는 예컨대, 도 1 내지 11을 참조하여 설명한 UWB 세션을 설정하기 위해 필요한 정보 및/또는 서비스 데이터를 저장할 수 있다.

상술한 본 개시의 구체적인 실시 예들에서, 본 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.

한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims

UWB 통신을 수행하는 전자 장치의 방법에 있어서,
UWB 지원(enabled) 어플리케이션의 서비스를 위한 설정 정보를 식별하는 단계;
상기 설정 정보에 기초하여, 상기 서비스에 대한 서비스 인스턴스 ID 정보를 생성하는 단계;
상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트와 다른 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 사이의 보안 채널을 설정하는 단계; 및
상기 보안 채널을 통해 UWB 세션을 설정하기 위한 데이터를 상기 보안 컴포넌트들 사이에서 교환하는 단계를 포함하며,
상기 설정 정보는 서비스 설정 정보, UWB 설정 정보 또는 OOB 설정 정보 중 적어도 하나를 포함하는, 방법.
제1항에 있어서, 상기 방법은:
상기 전자 장치의 UWB 지원 어플리케이션이 상기 서비스를 위한 설정 정보를 프레임워크 API를 이용하여 상기 전자 장치의 프레임워크로 전달하는 단계; 및
상기 전자 장치의 프레임워크가 상기 생성된 서비스 인스턴스 ID 정보를 상기 전자 장치의 UWB 지원 어플리케이션으로 전달하는 단계를 더 포함하는, 방법.
제1항에 있어서, 상기 방법은:
보안 컴포넌트의 타입을 지시하는 보안 컴포넌트 타입 정보를 포함하는 광고(advertisement) 메시지를 상기 다른 전자 장치로 전송하는 단계를 더 포함하고,
상기 보안 컴포넌트 정보는 상기 보안 컴포넌트의 타입이 상기 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트임을 지시하는 값으로 설정되는, 방법.
제1항에 있어서, 상기 서비스 인스턴스 ID 정보를 생성하는 단계는:
상기 전자 장치의 프레임워크가 상기 서비스 설정 정보에 포함된 서비스 ID 정보의 값 및 상기 UWB 설정 정보에 포함된 벤더 ID 정보의 값에 기초하여 상기 서비스 인스턴스 ID를 생성하는 단계를 포함하며,
상기 서비스 ID 정보는 상기 UWB 지원 어플리케이션이 지원하는 프로필에 대한 식별 정보를 포함하는, 방법.
제4항에 있어서, 상기 서비스 인스턴스 ID는, 상기 서비스 ID 정보의 값 및 상기 벤더 ID 정보의 값을 조합한 값을 입력으로 해시 코드 생성을 수행하여 획득된 출력에 대응하는, 방법.
제5항에 있어서,
상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 내에 저장되는, 상기 UWB 지원 어플리케이션에 대한 ADF(Application Dedicated File)을 식별하기 위한 ADF ID 정보는 상기 서비스 인스턴스 ID 정보와 동일한 값으로 설정되며,
상기 ADF는 상기 UWB 세션을 설정하기 위한 데이터를 포함하는, 방법.
제6항에 있어서,
상기 ADF는 상기 UWB 지원 어플리케이션을 제공한 서비스 제공자에 의해 정의된 서비스 데이터를 더 포함하는, 방법.
UWB 통신을 수행하는 전자 장치에 있어서,
메모리; 및
상기 메모리에 연결된 프로세서를 포함하며, 상기 프로세서는:
UWB 지원(enabled) 어플리케이션의 서비스를 위한 설정 정보를 식별하고,
상기 설정 정보에 기초하여, 상기 서비스에 대한 서비스 인스턴스 ID 정보를 생성하고,
상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트와 다른 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 사이의 보안 채널을 설정하고,
상기 보안 채널을 통해 UWB 세션을 설정하기 위한 데이터를 상기 보안 컴포넌트들 사이에서 교환하도록 구성되며,
상기 설정 정보는 서비스 설정 정보, UWB 설정 정보 또는 OOB 설정 정보 중 적어도 하나를 포함하는, 전자 장치.
제8항에 있어서, 상기 프로세서는:
상기 전자 장치의 UWB 지원 어플리케이션이 상기 서비스를 위한 설정 정보를 프레임워크 API를 이용하여 상기 전자 장치의 프레임워크로 전달하고,
상기 전자 장치의 프레임워크가 상기 생성된 서비스 인스턴스 ID 정보를 상기 전자 장치의 UWB 지원 어플리케이션으로 전달하도록 제어하기 위해 더 구성되는, 전자 장치.
제8항에 있어서, 상기 프로세서는:
보안 컴포넌트의 타입을 지시하는 보안 컴포넌트 타입 정보를 포함하는 광고(advertisement) 메시지를 상기 다른 전자 장치로 전송하도록 더 구성되며,
상기 보안 컴포넌트 정보는 상기 보안 컴포넌트의 타입이 상기 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트임을 지시하는 값으로 설정되는, 전자 장치.
제8항에 있어서, 상기 프로세서는:
상기 전자 장치의 프레임워크가 상기 서비스 설정 정보에 포함된 서비스 ID 정보의 값 및 상기 UWB 설정 정보에 포함된 벤더 ID 정보의 값에 기초하여 상기 서비스 인스턴스 ID를 생성하도록 제어하며,
상기 서비스 ID 정보는 상기 UWB 지원 어플리케이션이 지원하는 프로필에 대한 식별 정보를 포함하는, 전자 장치.
제1항에 있어서, 상기 프로세서는:
상기 전자 장치의 프레임워크가 상기 서비스 설정 정보에 포함된 서비스 ID 정보의 값 및 상기 UWB 설정 정보에 포함된 벤더 ID 정보의 값에 기초하여 상기 서비스 인스턴스 ID를 생성하도록 더 구성되며,
상기 서비스 ID 정보는 상기 UWB 지원 어플리케이션이 지원하는 프로필에 대한 식별 정보를 포함하는, 전자 장치.
제12항에 있어서, 상기 서비스 인스턴스 ID는, 상기 서비스 ID 정보의 값 및 상기 벤더 ID 정보의 값을 조합한 값을 입력으로 해시 코드 생성을 수행하여 획득된 출력에 대응하는, 전자 장치.
제13항에 있어서,
상기 전자 장치의 프레임워크 내의 소프트웨어 기반의 보안 컴포넌트 내에 저장되는, 상기 UWB 지원 어플리케이션에 대한 ADF(Application Dedicated File)을 식별하기 위한 ADF ID 정보는 상기 서비스 인스턴스 ID 정보와 동일한 값으로 설정되며,
상기 ADF는 상기 UWB 세션을 설정하기 위한 데이터를 포함하는, 전자 장치.