KR20220033337A - 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 - Google Patents
블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 Download PDFInfo
- Publication number
- KR20220033337A KR20220033337A KR1020200115613A KR20200115613A KR20220033337A KR 20220033337 A KR20220033337 A KR 20220033337A KR 1020200115613 A KR1020200115613 A KR 1020200115613A KR 20200115613 A KR20200115613 A KR 20200115613A KR 20220033337 A KR20220033337 A KR 20220033337A
- Authority
- KR
- South Korea
- Prior art keywords
- server
- client
- ens
- bluetooth
- data
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 214
- 230000000977 initiatory effect Effects 0.000 claims description 16
- 108091006146 Channels Proteins 0.000 description 93
- 230000004044 response Effects 0.000 description 75
- 238000004891 communication Methods 0.000 description 33
- 238000005516 engineering process Methods 0.000 description 31
- 238000010586 diagram Methods 0.000 description 30
- 230000009471 action Effects 0.000 description 25
- 230000015654 memory Effects 0.000 description 25
- 230000008569 process Effects 0.000 description 22
- 230000005540 biological transmission Effects 0.000 description 21
- 238000005096 rolling process Methods 0.000 description 21
- 230000006870 function Effects 0.000 description 19
- 230000008859 change Effects 0.000 description 16
- 230000000737 periodic effect Effects 0.000 description 15
- 238000001914 filtration Methods 0.000 description 12
- 238000012546 transfer Methods 0.000 description 12
- 230000000875 corresponding effect Effects 0.000 description 10
- 238000012790 confirmation Methods 0.000 description 9
- 238000007667 floating Methods 0.000 description 8
- 230000006399 behavior Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 7
- 238000003860 storage Methods 0.000 description 7
- 230000002093 peripheral effect Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000005070 sampling Methods 0.000 description 6
- 230000032258 transport Effects 0.000 description 6
- 230000009118 appropriate response Effects 0.000 description 5
- 208000025721 COVID-19 Diseases 0.000 description 4
- 238000009826 distribution Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000006978 adaptation Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 238000003745 diagnosis Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 241001678559 COVID-19 virus Species 0.000 description 2
- 241000711573 Coronaviridae Species 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 239000004020 conductor Substances 0.000 description 2
- 238000000354 decomposition reaction Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000005265 energy consumption Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012806 monitoring device Methods 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 238000003825 pressing Methods 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 239000013589 supplement Substances 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 206010000210 abortion Diseases 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000010835 comparative analysis Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 210000000105 enteric nervous system Anatomy 0.000 description 1
- 208000015181 infectious disease Diseases 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001151 other effect Effects 0.000 description 1
- 244000052769 pathogen Species 0.000 description 1
- 230000001717 pathogenic effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000003362 replicative effect Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000002087 whitening effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
- A61B5/00—Measuring for diagnostic purposes; Identification of persons
- A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/80—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for detecting, monitoring or modelling epidemics or pandemics, e.g. flu
-
- H04L67/42—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/025—Services making use of location information using location based information parameters
- H04W4/026—Services making use of location information using location based information parameters using orientation information, e.g. compass
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/50—Service provisioning or reconfiguring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/14—Direct-mode setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/005—Discovery of network devices, e.g. terminals
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Public Health (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Life Sciences & Earth Sciences (AREA)
- Medical Informatics (AREA)
- Multimedia (AREA)
- Pathology (AREA)
- Biomedical Technology (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- Molecular Biology (AREA)
- Surgery (AREA)
- Animal Behavior & Ethology (AREA)
- Heart & Thoracic Surgery (AREA)
- Biophysics (AREA)
- Veterinary Medicine (AREA)
- Data Mining & Analysis (AREA)
- Epidemiology (AREA)
- Primary Health Care (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
본 명세서는 ENS 서비스를 수행하기 위한 방법을 제공한다. 보다 구체적으로, 서버에 의해, 연결 가능한 ENS 비콘에 대해 광고하는 단계; 클라이언트에 의해, 새로운 디바이스를 상기 클라이언트의 프로파일에 추가하는 단계; 상기 클라이언트에 의해, 상기 서버로 제 1 페어링 요청을 전송하는 단계; 상기 서버에 의해, 상기 클라이언트와 페어링을 확인하여 상기 클라이언트로 호환 가능한 ENS 클라이언트를 연결하는 단계; 상기 서버에 의해, 상기 클라이언트로 상기 서버의 특징을 리드(read)하는 단계; 상기 서버에 의해, ENS 세팅을 설정하는 단계; 및 상기 클라이언트에 의해, 상기 서버로 ENS 시작을 전송하는 단계를 포함하는 것을 특징으로 한다.
Description
본 명세서는 블루투스에 관한 것으로, 특히 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치에 관한 것이다.
블루투스(Bluetooth)는 IoT 의 기반이 되는 기술 중 하나로 휴대폰, 노트북, 이어폰, 헤드셋 등의 휴대기기를 서로 연결해 정보를 교환하는 근거리 무선 기술 표준이다. 블루투스는 ISM(Industrial, Scientific, Medical) 대역인 2400~2483.5MHz 주파수를 이용해 통신한다. 블루투스는 이 대역에서 아래 2MHz 위 3.5MHz 의 보호대역을 가지고, 각 채널의 대역폭을 1MHz 로 해 총 79 개의 채널을 사용하고, 전파 간섭을 예방하기 위해 주파수 도약(Frequency Hopping)을 사용한다. 주파수 도약은 주파수 호핑이라고도 불리우며, 채널을 특정한 패턴에 따라 빠르게 이동하며 데이터를 전송하는 방식이다. 블루투스 기기 간 연결은 마스터와 슬레이브로 구성되며, 하나의 마스터 기기에는 최대 7 대의 슬레이브 기기를 연결할 수 있다. 마스터와 슬레이브는 고정된 것이 아니며, 상황에 따라 마스터와 슬레이브가 바뀔 수도 있다.
블루투스 통신방법에는 BR/EDR (Basic Rate/Enhanced Data Rate)방식과 저전력 방식인 LE(Low Energy)방식이 있다. BR/EDR 방식은 블루투스 클래식 (Bluetooth Classic)라고 호칭될 수 있다. 블루투스 클래식 방식은 베이직 레이트(Basic Rate)를 이용하는 블루투스 1.0 부터 이어져온 블루투스 기술과 블루투스 2.0 에서부터 지원되는 인핸스드 데이터 레이트(Enhanced Data Rate)를 이용하는 블루투스 기술을 포함한다.
블루투스 저전력 에너지(Bluetooth Low energy, 이하 블루투스 LE 라고 한다.) 블루투스 4.0 부터 적용되어 적은 전력을 소모하여 수백 키로바이트(KB)의 정보를 안정적으로 제공할 수 있다. 이러한 블루투스 저전력 에너지 기술은 속성 프로토콜(Attribute Protocol)을 활용해서 디바이스(Device) 간 정보를 교환하게 된다. 이러한 블루투스 LE 방식은 헤더의 오버헤드(overhead)를 줄이고 동작을 간단하게 해서 에너지 소비를 줄일 수 있다. 블루투스 LE 를 기반으로 하는 블루투스 메시(Mesh)는 다대다 디바이스 통신을 지원하고, 대규모 디바이스 네트워크 생성을 최적화한다. 산업용 수준의 안정성, 확장성 및 보안성을 갖췄고, 글로벌 상호 운용성을 지원한다. 특히, 수천 개의 디바이스들이 서로 안정적이고 안전하게 통신해야 하는 건물 자동화, 센서 네트워크, 자산 추적 등의 사물인터넷 솔루션에 적합하다. 메시 네트워크는 저전력 블루투스 연결의 범위를 확장하며, '매니지드 플러드(Managed Flood)'라는 기술을 사용하기 때문에 수만 개의 장치의 끝 없는 요청을 처리할 수 있다. 블루투스 메시 네트워킹은 컨슈머를 넘어 공장 자동화 시스템, 스마트 오피스, 스마트 시티 등으로 블루투스의 활용을 확대하는데 기여한다.
블루투스 버전 5 는 블루투스 버전 4 의 업그레이드 버전이다. 이론적으로, 블루투스 버전 5 는 장애물이 없는 환경에서 400m 까지 연결할 수 있다. 블루투스 버전 5 는 현실적인 구성에서 최대 120m 까지 연결할 수 있는데, 블루투스 버전 4 의 4 배에 달한다. 데이터 전송 속도 역시 2 배로 늘어나 2Mbps 가 된다. 따라서, 블루투스 버전 5 는 더 빨라진 속도와 더 넓은 접속 거리, 오류 정정기능으로 디바이스의 펌웨어 전송을 한층 쉽게 만들어 주고, 자동차나 지능형 계량기, 사람 몸 속에 심는 의료기기 등에 유용하다. 또한, 블루투스는 기본적으로 두 기기 간에 페어링(연결)이 이루어지는데, 브로드캐스트라는 기능을 활용하면 별도의 페어링 없이 주변의 비콘과 다중으로 통신할 수 있다. 블루투스 5 는 이 브로드캐스트 용량을 8 배 늘려 한층 다양한 비콘 서비스를 활용할 수 있도록 한다.
블루투스 기기들 중에는 디스플레이(Display)나 유저인터페이스(User Interface)가 없는 제품들도 있다. 다양한 종류의 블루투스 기기들과 그 중에서도 유사기술이 적용된 블루투스 기기들 간의 연결 / 관리 / 제어 / 분리 (Connection / Management / Control / Disconnection)의 복잡도가 증가하고 있다.
본 명세서는 블루투스 통신에서 노출 알림 서비스를 제공함으로써, 개인에게 잠재적인 노출을 감지 및 알려줌으로써 COVID-19 의 확산 방지를 제공함에 목적이 있다.
본 명세서는 ENS 서비스를 수행하기 위한 방법을 제공한다. 보다 구체적으로, 서버에 의해, 연결 가능한 ENS 비콘에 대해 광고하는 단계; 클라이언트에 의해, 새로운 디바이스를 상기 클라이언트의 프로파일에 추가하는 단계; 상기 클라이언트에 의해, 상기 서버로 제 1 페어링 요청을 전송하는 단계; 상기 서버에 의해, 상기 클라이언트와 페어링을 확인하여 상기 클라이언트로 호환 가능한 ENS 클라이언트를 연결하는 단계; 상기 서버에 의해, 상기 클라이언트로 상기 서버의 특징을 리드(read)하는 단계; 상기 서버에 의해, ENS 세팅을 설정하는 단계; 및 상기 클라이언트에 의해, 상기 서버로 ENS 시작을 전송하는 단계를 포함하는 것을 특징으로 한다.
본 명세서는 블루투스 통신에서 노출 알림 서비스를 제공함으로써, 개인에게 잠재적인 노출을 감지 및 알려줌으로써 COVID-19의 확산을 방지할 수 있는 효과가 있다.
한편, 본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 명세서가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1 은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
도 2 는 본 명세서에서 제안하는 방법들을 구현할 수 있는 서버 디바이스 및 클라이언트 디바이스의 내부 블록도의 일 예를 나타낸다.
도 3은 블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 아키텍처의 일 예를 나타낸다.
도 4는 블루투스 LE(Low Energy)의 아키텍처의 일 예를 나타낸다.
도 5는 블루투스 저전력 에너지의 GATT Profile 구조의 일 예를 나타낸 도이다.
도 6은 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.
도 7 은 블루투스 저전력 에너지 기술에서 객체 전송 서비스(Object Transfer Service)를 제공하는 방법의 일 예를 나타낸 흐름도이다.
도 8은 블루투스 BR/EDR 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.
도 9 는 본 명세서가 적용될 수 있는 블루투스 메쉬 네트워크(Mesh Network)의 일 예를 나타낸 개략도이다.
도 10 은 본 명세서가 적용될 수 있는 블루투스 메쉬 네트워크(Mesh Network)의 프로토콜 스택의 일 예를 나타낸 도이다.
도 11 은 본 명세서가 적용될 수 있는 디바이스가 블루투스 메쉬 네트워크(Mesh Network)에 참여하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 12 는 본 명세서에서 제안하는 방법이 적용될 수 있는 도착 각도(AoA) 및 출발 각도(AoD)의 일례를 나타낸다.
도 13은 CTE 필드의 일례를 나타낸 도이다.
도 14는 서비스 디스커버리 및 속성 캐싱의 일례를 나타낸 도이다.
도 15 는 광고 채널의 고정된 순서(sequence)를 가진 블루투스 코어 스펙 v5.0 에 따른 광고 채널 사용의 일례를 나타낸다.
도 16 은 랜덤화된 채널 인덱스 시퀀스를 사용하는 블루투스 코어 스펙 v5.1 에 따른 광고 채널 사용의 일례를 나타낸 도이다.
도 17은 주기적인 광고 동기화 전송 사용의 일례를 나타낸 도이다.
도 18은 본 명세서에서 제안하는 광고 페이로드 포맷의 일례를 나타낸 도이다.
도 19는 본 명세서에서 제안하는 ENS 관련 브로드캐스팅 플로우의 일례를 나타낸 도이다.
도 20은 본 명세서에서 제안하는 ENS 관련 스캐닝 플로우의 일례를 나타낸 도이다.
도 21은 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 22는 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 23은 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 24는 본 명세서에서 제안하는 Client ENS를 제거하는 방법의 일례를 나타낸 순서도이다.
도 25는 본 명세서에서 제안하는 Client ENS를 추가하기 위한 절차의 일례를 나타낸 순서도이다.
도 26은 본 명세서에서 제안하는 서버와 Client 들 간 흐름도의 일례를 나타낸 도이다.
도 27은 본 명세서에서 제안하는 ENS 관련 절차의 일례를 나타낸 순서도이다.
도 28은 본 명세서에서 제안하는 서버와 Client 간 절차의 일례를 나타낸 흐름도이다.
도 2 는 본 명세서에서 제안하는 방법들을 구현할 수 있는 서버 디바이스 및 클라이언트 디바이스의 내부 블록도의 일 예를 나타낸다.
도 3은 블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 아키텍처의 일 예를 나타낸다.
도 4는 블루투스 LE(Low Energy)의 아키텍처의 일 예를 나타낸다.
도 5는 블루투스 저전력 에너지의 GATT Profile 구조의 일 예를 나타낸 도이다.
도 6은 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.
도 7 은 블루투스 저전력 에너지 기술에서 객체 전송 서비스(Object Transfer Service)를 제공하는 방법의 일 예를 나타낸 흐름도이다.
도 8은 블루투스 BR/EDR 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.
도 9 는 본 명세서가 적용될 수 있는 블루투스 메쉬 네트워크(Mesh Network)의 일 예를 나타낸 개략도이다.
도 10 은 본 명세서가 적용될 수 있는 블루투스 메쉬 네트워크(Mesh Network)의 프로토콜 스택의 일 예를 나타낸 도이다.
도 11 은 본 명세서가 적용될 수 있는 디바이스가 블루투스 메쉬 네트워크(Mesh Network)에 참여하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 12 는 본 명세서에서 제안하는 방법이 적용될 수 있는 도착 각도(AoA) 및 출발 각도(AoD)의 일례를 나타낸다.
도 13은 CTE 필드의 일례를 나타낸 도이다.
도 14는 서비스 디스커버리 및 속성 캐싱의 일례를 나타낸 도이다.
도 15 는 광고 채널의 고정된 순서(sequence)를 가진 블루투스 코어 스펙 v5.0 에 따른 광고 채널 사용의 일례를 나타낸다.
도 16 은 랜덤화된 채널 인덱스 시퀀스를 사용하는 블루투스 코어 스펙 v5.1 에 따른 광고 채널 사용의 일례를 나타낸 도이다.
도 17은 주기적인 광고 동기화 전송 사용의 일례를 나타낸 도이다.
도 18은 본 명세서에서 제안하는 광고 페이로드 포맷의 일례를 나타낸 도이다.
도 19는 본 명세서에서 제안하는 ENS 관련 브로드캐스팅 플로우의 일례를 나타낸 도이다.
도 20은 본 명세서에서 제안하는 ENS 관련 스캐닝 플로우의 일례를 나타낸 도이다.
도 21은 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 22는 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 23은 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 24는 본 명세서에서 제안하는 Client ENS를 제거하는 방법의 일례를 나타낸 순서도이다.
도 25는 본 명세서에서 제안하는 Client ENS를 추가하기 위한 절차의 일례를 나타낸 순서도이다.
도 26은 본 명세서에서 제안하는 서버와 Client 들 간 흐름도의 일례를 나타낸 도이다.
도 27은 본 명세서에서 제안하는 ENS 관련 절차의 일례를 나타낸 순서도이다.
도 28은 본 명세서에서 제안하는 서버와 Client 간 절차의 일례를 나타낸 흐름도이다.
본 명세서의 상술한 목적, 특징들 및 장점은 첨부된 도면과 관련된 다음의 상세한 설명을 통해 보다 분명해질 것이다. 다만, 본 명세서는 다양한 변경을 가할 수 있고 여러 가지 실시 예들을 가질 수 있는 바, 이하에서는 특정 실시 예들을 도면에 예시하고 이를 상세히 설명하고자 한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 명세서와 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 명세서의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.
이하, 본 명세서와 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다.
도 1 은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
무선 통신 시스템(100)은 적어도 하나의 서버 디바이스(Server Device, 120) 및 적어도 하나의 클라이언트 디바이스(Client Device, 110)를 포함한다.
서버 디바이스와 클라이언트 디바이스는 블루투스 저전력 에너지(Bluetooth Low Energy: BLE, 이하 편의상 'BLE'로 표현한다.) 기술을 이용하여 블루투스 통신을 수행한다.
BLE 기술에서, (1) RF 채널수는 40 개이며, (2) 데이터 전송 속도는 1Mbps 를 지원하며, (3) 토폴로지는 스캐터넷 구조이며, (4) latency 는 3ms 이며, (5) 최대 전류는 15mA 이하이며, (6) 출력 전력은 10mW(10dBm)이하이며, (7) 휴대폰, 시계, 스포츠, 헬스케어, 센서, 기기제어 등의 어플리케이션에 주로 사용된다.
상기 서버 장치(120)는 다른 장치와의 관계에서 클라이언트 장치로 동작할 수 있고, 상기 클라이언트 장치는 다른 장치와의 관계에서 서버 장치로 동작할 수 있다. 즉, BLE 통신 시스템에서 어느 하나의 장치는 서버 장치 또는 클라이언트 장치로 동작하는 것이 가능하며, 필요한 경우, 서버 장치 및 클라이언트 장치로 동시에 동작하는 것도 가능하다.
상기 서버 장치(120)는 데이터 서비스 장치(Data Service Device), 슬레이브 디바이스(slave device) 디바이스, 슬레이브(slave), 서버, 컨덕터(Conductor), 호스트 디바이스(Host Device), 게이트웨이(Gateway), 센싱 장치(Sensing Device), 모니터링 장치(monitoring device) 등으로 표현될 수 있다.
상기 클라이언트 디바이스(110)는 마스터 디바이스(master device), 마스터(master), 클라이언트, 멤버(Member), 센서 디바이스, 싱크 디바이스(Sink Device), 콜렉터(Collector), 제 3 디바이스, 제 4 디바이스 등으로 표현될 수 있다.
서버 디바이스(또는 서버 장치)와 클라이언트 디바이스(또는 클라이언트 장치)는 상기 무선 통신 시스템의 주요 구성요소에 해당하며, 상기 무선 통신 시스템은 서버 장치 및 클라이언트 장치 이외에도 다른 구성요소를 포함할 수 있다.
상기 서버 장치는 클라이언트 장치로부터 데이터를 제공받고, 클라이언트 장치와 직접 통신을 수행함으로써, 클라이언트 장치부터 데이터 요청을 수신하는 경우, 응답을 통해 클라이언트 장치로 데이터를 제공하는 장치를 말한다.
또한, 상기 서버 장치는 클라이언트 장치로 데이터 정보를 제공하기 위해 클라이언트 장치에게 알림(Notification) 메시지, 지시(Indication) 메시지를 보낸다. 또한, 상기 서버 장치는 상기 클라이언트 장치로 지시 메시지를 전송하는 경우, 상기 클라이언트로부터 상기 지시 메시지에 대응하는 확인(Confirm) 메시지를 수신한다.
또한, 상기 서버 장치는 알림, 지시, 확인 메시지들을 클라이언트 디바이스와 송수신하는 과정에서 출력부(Display Unit)을 통해서 사용자에게 데이터 정보를 제공하거나 입력부(User Input Interface)를 통해 사용자로부터 입력되는 요청을 수신할 수 있다.
또한, 상기 서버 장치는 상기 클라이언트 장치와 메시지를 송수신하는 과정에서 메모리(memory unit)로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
또한, 하나의 서버 장치는 다수의 클라이언트 장치들과 연결될 수 있으며, 본딩(Bonding) 정보를 활용하여 클라이언트 장치들과 쉽게 재 연결(또는 접속)이 가능하다.
상기 클라이언트 장치 (120)는 서버 장치에게 데이터 정보 및 데이터 전송을 요청하는 장치를 말한다.
클라이언트 장치는 상기 서버 장치로부터 알림 메시지, 지시 메시지 등을 통해 데이터를 수신하고, 지시 메시지를 상기 서버 디바이스로부터 수신하는 경우, 상기 지시 메시지에 대한 응답으로 확인 메시지를 보낸다.
상기 클라이언트 장치도 마찬가지로 상기 서버 장치와 메시지들을 송수신하는 과정에서 출력부를 통해 사용자에게 정보를 제공하거나 입력부를 통해 사용자로부터의 입력을 수신할 수 있다.
또한, 상기 클라이언트 장치는 상기 서버 장치와 메시지를 송수신하는 과정에서 메모리로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
상기 서버 장치 및 클라이언트 장치의 출력부, 입력부 및 메모리 등과 같은 하드웨어 구성요소에 대해서는 도 2 에서 구체적으로 살펴보기로 한다.
또한, 상기 무선 통신 시스템은 블루투스 기술을 통해 개인 영역 네트워킹(Personal Area Networking:PAN)을 구성할 수 있다. 일 예로, 상기 무선 통신 시스템에서는 디바이스 간 개인적인 피코넷(private piconet)을 확립함으로써 파일, 서류 등을 신속하고 안전하게 교환할 수 있다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 서버 디바이스 및 클라이언트 디바이스의 내부 블록도의 일 예를 나타낸다.
서버 디바이스는 적어도 하나의 클라이언트 디바이스와 연결될 수 있다.
또한, 필요에 따라 각 디바이스의 내부 블록도는 다른 구성 요소(모듈, 블록, 부)를 더 포함할 수도 있고, 도 2의 구성 요소 중 일부가 생략될 수도 있다.
도 2에 도시된 바와 같이, 서버 디바이스는 출력부(Display Unit,111), 입력부(User Input Interface,112), 전력 공급부(Power Supply Unit,113), 프로세서(Processor,114), 메모리(Memory Unit,115), 블루투스 인터페이스(Bluetooth Interface,116), 다른 통신 인터페이스(Other Interface,117) 및 통신부(또는 송수신부, 118)를 포함한다.
상기 출력부(111), 입력부(112), 전력 공급부(113), 프로세서(114), 메모리(115), 블루투스 인터페이스(116), 다른 통신 인터페이스(117) 및 통신부(118)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
또한, 클라이언트 디바이스는 출력부(Display Unit,121), 입력부(User Input Interface,122), 전력 공급부(Power Supply Unit,123), 프로세서(Processor,124), 메모리(Memory Unit,125), 블루투스 인터페이스(Bluetooth Interface,126) 및 통신부(또는 송수신부, 127)를 포함한다.
상기 출력부(121), 입력부(122), 전력 공급부(123), 프로세서(124), 메모리(125), 블루투스 인터페이스(126), 및 통신부(127)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
상기 블루투스 인터페이스(116,126)는 블루투스 기술을 이용하여 디바이스들 간의 요청/응답, 명령, 알림, 지시/확인 메시지 등 또는 데이터 전송이 가능한 유닛(또는 모듈)을 말한다.
상기 메모리(115,125)는 다양한 종류의 디바이스에 구현되는 유닛으로서, 다양한 종류의 데이터가 저장되는 유닛을 말한다.
상기 프로세서(114,124)는 서버 디바이스 또는 클라이언트 디바이스의 전반적인 동작을 제어하는 모듈을 말하며, 블루투스 인터페이스 및 다른 통신 인터페이스로 메시지를 전송 요청 및 수신받은 메시지를 처리하도록 제어한다.
상기 프로세서(114,124)는 제어부, 제어 유닛(Control Unit), 컨트롤러 등으로 표현될 수 있다.
상기 프로세서(114,124)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다.
상기 메모리(115,125)는 ROM(read-only memory), RAM(random access memory), 플래쉬 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 장치를 포함할 수 있다.
상기 통신부(118,127)는 무선 신호를 처리하기 위한 베이스밴드 회로를 포함할 수 있다. 실시 예가 소프트웨어로 구현될 때, 상술한 기법은 상술한 기능을 수행하는 모듈(과정, 기능 등)로 구현될 수 있다. 모듈은 메모리에 저장되고, 프로세서에 의해 실행될 수 있다.
상기 메모리(115,125)는 프로세서(114,124) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(114,124)와 연결될 수 있다.
상기 출력부(111,121)는 디바이스의 상태 정보 및 메시지 교환 정보 등을 화면을 통해서 사용자에게 제공하기 위한 모듈을 말한다.
상기 전력 공급부(전원 공급부,113,123)는 제어부의 제어 하에 외부의 전원, 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급해주는 모듈을 말한다.
앞에서 살핀 것처럼, BLE 기술에서는 작은 duty cycle을 가지며, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있어, 상기 전력 공급부는 적은 출력 전력으로도(10mW(10dBm)이하) 각 구성요소들의 동작에 필요한 전원을 공급할 수 있다.
상기 입력부(112,122)는 화면 버튼과 같이 사용자의 입력을 제어부에게 제공하여 디바이스의 동작을 사용자가 제어할 수 있게 하는 모듈을 말한다.
도 3 및 도 4는 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸 도이다.
구체적으로, 도 3은 블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 아키텍처의 일 예를 나타낸다.
도 4는 블루투스 LE(Low Energy)의 아키텍처의 일 예를 나타낸다.
먼저, 도 3에 도시된 바와 같이, 블루투스 BR/EDR 아키텍처는 컨트롤러 스택(Controller stACK,310), HCI(Host Controller Interface,320) 및 호스트 스택(Host stACK,330)을 포함한다.
상기 컨트롤러 스택(또는 컨트롤러 모듈, 310)은 2.4GHz의 블루투스 신호를 받는 무선 송수신 모듈과 블루투스 패킷을 전송하거나 수신하기 위한 하드웨어를 말하며, BR/EDR Radio 계층(311), BR/EDR Baseband 계층(312), BR/EDR Link Manager 계층(313)을 포함할 수 있다.
상기 BR/EDR Radio 계층(311)은 2.4 GHz 무선 신호를 송수신하는 계층으로, GFSK (Gaussian Frequency Shift Keying) modulation을 사용하는 경우 79 개의 RF 채널을 hopping 하여 데이터를 전송할 수 있다.
상기 BR/EDR Baseband 계층(312)은 Digital Signal을 전송하는 역할을 담당하며, 초당 1600번 hopping 하는 채널 시퀀스를 선택하며, 각 채널 별 625us 길이의 time slot을 전송한다.
상기 Link Manager 계층(313)은 LMP(Link Manager Protocol)을 활용하여 Bluetooth Connection의 전반적인 동작(link setup, control, security)을 제어한다.
상기 Link Manager 계층은 아래와 같은 기능을 수행할 수 있다.
- ACL/SCO logical transport 및 logical link setup 및 control을 한다.
- Detach: connection을 중단하고, 중단 이유를 상대 디바이스에게 알려준다.
- Power control 및 Role switch를 한다.
- Security(authentication, pairing, encryption) 기능을 수행한다.
상기 Host Controller Interface 계층(320)은 Host 모듈(330)과 Controller 모듈(310) 사이의 인터페이스 제공하여 Host 가 command와 Data를 Controller에게 제공하게 하며, Controller가 event와 Data를 Host에게 제공할 수 있도록 해준다.
상기 호스트 스택(또는 호스트 모듈,330)은 L2CAP(337), SDP(Service Discovery Protocol,333), BR/EDR Protocol(332), BR/EDR Profiles(331), Attribute Protocol(336), Generic Access Profile(GAP,334), Generic Attribute Profile(GATT,335)을 포함한다.
상기 Logical Link Control and Adaptation Protocol(L2CAP,337)은 특정 protocol 또는 profile 에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공한다.
상기 L2CAP은 블루투스 상위에서 제공하는 다양한 protocol, profile 등을 multiplexing한다.
블루투스 BR/EDR의 L2CAP에서는 dynamic 채널 사용하며, protocol service multiplexer, retransmission, streaming mode를 지원하고, Segmentation 및 reassembly, per-channel flow control, error control을 제공한다.
상기 SDP(Service Discovery Protocol,333)는 블루투스 디바이스에서 지원하는 서비스(Profile 및 Protocol)을 찾기 위한 프로토콜을 말한다.
상기 BR/EDR Protocol 및 Profiles(332,331)은 블루트스 BR/EDR를 이용하는 서비스 (profile)의 정의 및 이들 데이터를 주고 받기 위한 application 프로토콜을 정의한다.
상기 Attribute Protocol(336)은 Server-Client 구조로, 상대 디바이스의 data를 접근하기 위한 규칙을 정의한다. 아래와 같이 6가지 메시지(Request message, Response message, Command message, Notification message, Indication message) 유형이 있다.
-서버에서 클라이언트로 응답 메시지와 함께 클라이언트에서 서버로 메시지 요청
-응답 메시지없이 클라이언트에서 서버로 명령(command) 메시지
-확인 메시지없이 서버에서 클라이언트로의 알림(notification) 메시지
-클라이언트에서 서버로의 확인 메시지와 함께 서버에서 클라이언트로의 지시(indication) 메시지
상기 Generic Attribute Profile(GATT,335)은 attribute의 type을 정의한다.
상기 Generic Access Profile(GAP,334)은 디바이스 발견, 연결, 사용자에게 정보를 제공하는 방안을 정의하며, privacy를 제공한다.
도 4에 도시된 바와 같이, BLE 구조는 타이밍이 중요한 무선장치 인터페이스를 처리하도록 동작가능한 컨트롤러 스택(Controller stACK)과 고레벨(high level) 데이터를 처리하도록 동작가능한 호스트 스택(Host stACK)을 포함한다.
상기 Controller stACK은 Controller로 호칭될 수도 있으나, 앞서 도 2에서 언급한 디바이스 내부 구성요소인 프로세서와의 혼동을 피하기 위해 이하에서는 Controller stACK으로 표현하기로 한다.
먼저, 컨트롤러 스택은 블루투스 무선장치를 포함할 수 있는 통신 모듈과, 예를 들어, 마이크로프로세서와 같은 프로세싱 디바이스를 포함할 수 있는 프로세서 모듈을 이용하여 구현될 수 있다.
호스트 스택은 프로세서 모듈 상에서 작동되는 OS의 일부로서, 또는 OS 위의 패키지(pACKage)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.
일부 사례들에서, 컨트롤러 스택 및 호스트 스택은 프로세서 모듈 내의 동일한 프로세싱 디바이스 상에서 작동 또는 실행될 수 있다.
호스트 스택은 GAP(Generic Access Profile,410), GATT based Profiles(420), GATT(Generic Attribute Profile,430), ATT(Attribute Protocol,440), SM(Security Manage,450), L2CAP(Logical Link Control and Adaptation Protocol,460)을 포함한다. 다만, 호스트 스택은 이것으로 한정되지는 않고 다양한 프로토콜들 및 프로파일들을 포함할 수 있다.
호스트 스택은 L2CAP을 사용하여 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 다중화(multiplexing)한다.
먼저, L2CAP(Logical Link Control and Adaptation Protocol,460)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공한다.
L2CAP은 상위 계층 프로토콜들 사이에서 데이터를 다중화(multiplex)하고, 패키지(pACKage)들을 분할(segment) 및 재조립(reassemble)하고, 멀티캐스트 데이터 송신을 관리하도록 동작 가능할 수 있다.
BLE 에서는 3개의 고정 채널(signaling CH을 위해 1개, Security Manager를 위해 1개, Attribute protocol을 위해 1개)을 사용한다.
반면, BR/EDR(Basic Rate/Enhanced Data Rate)에서는 동적인 채널을 사용하며, protocol service multiplexer, retransmission, streaming mode 등을 지원한다.
SM(Security Manager,450)은 디바이스를 인증하며, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.
ATT(Attribute Protocol,440)는 서버-클라이언트(Server-Client) 구조로 상대 디바이스의 데이터를 접근하기 위한 규칙을 정의한다. ATT에는 6가지의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 있다.
즉, ① Request 및 Response 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보를 요청하기 위한 메시지이며, Response 메시지는 Request 메시지에 대한 응답 메시지로서, 서버 디바이스에서 클라이언트 디바이스로 전송되는 메시지를 말한다.
② Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 특정 동작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.
③ Notification 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.
④ Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지를 서버 디바이스로 전송한다.
GAP(Generic Access Profile)는 BLE 기술을 위해 새롭게 구현된 계층으로, BLE 디바이스들 간의 통신을 위한 역할 선택, 멀티 프로파일 작동이 어떻게 일어나는지를 제어하는데 사용된다.
또한, GAP는 디바이스 발견, 연결 생성 및 보안 절차 부분에 주로 사용되며, 사용자에게 정보를 제공하는 방안을 정의하며, 하기와 같은 attribute의 type을 정의한다.
① Service : 데이터와 관련된 behavior의 조합으로 디바이스의 기본적인 동작을 정의
② Include : 서비스 사이의 관계를 정의
③ Characteristics : 서비스에서 사용되는 data 값
④ Behavior : UUID(Universal Unique Identifier, value type)로 정의된 컴퓨터가 읽을 수 있는 포맷
GATT-based Profiles은 GATT에 의존성을 가지는 profile 들로 주로 BLE 디바이스에 적용된다. GATT-based Profiles은 Battery, Time, FindMe, Proximity, Time, Object Delivery Service 등 일 수 있다. GATT-based Profiles의 구체적인 내용은 하기와 같다.
Battery : 배터리 정보 교환 방법
Time : 시간 정보 교환 방법
FindMe : 거리에 따른 알람 서비스 제공
Proximity : 배터리 정보 교환 방법
GATT는 서비스들의 구성 시에 ATT가 어떻게 이용되는지를 설명하는 프로토콜로서 동작가능할 수 있다. 예를 들어, GATT는 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작가능할 수 있다.
따라서, GATT 및 ATT는 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.
컨트롤러(Controller) 스택은 물리 계층(Physical Layer,490), 링크 계층(Link Layer,480) 및 호스트 컨트롤러 인터페이스(Host Controller Interface,470)를 포함한다.
물리 계층(무선 송수신 모듈,490)은 2.4 GHz 무선 신호를 송수신하는 계층으로 GFSK (Gaussian Frequency Shift Keying) modulation과 40 개의 RF 채널로 구성된 frequency hopping 기법을 사용한다.
링크 계층(480)은 블루투스 패킷을 전송하거나 수신한다.
또한, 링크 계층은 3개의 Advertising 채널(channel 31, 38, 39)을 이용하여 Advertising, Scanning 기능을 수행한 후에 디바이스 간 연결을 생성하고, 37개 Data 채널을 통해 최대 42bytes의 데이터 패킷을 주고 받는 기능을 제공한다.
HCI(Host Controller Interface)는 Host 스택과 Controller 스택 사이의 인터페이스를 제공하여, Host 스택에서 command와 Data를 Controller 스택으로 제공하게 하며, Controller 스택에서 event와 Data를 Host 스택으로 제공하게 해준다.
이하에서, 블루투스 저전력 에너지(Bluetooth Low Energy:BLE) 기술의 절차(Procedure)들에 대해 간략히 살펴보기로 한다.
BLE 절차는 디바이스 필터링 절차(Device Filtering Procedure), 광고 절차(Advertising Procedure), 스캐닝 절차(Scanning Procedure), 디스커버링 절차(Discovering Procedure), 연결 절차(Connecting Procedure) 등으로 구분될 수 있다.
디바이스 필터링 절차(Device Filtering Procedure)
디바이스 필터링 절차는 컨트롤러 스택에서 요청, 지시, 알림 등에 대한 응답을 수행하는 디바이스들의 수를 줄이기 위한 방법이다.
모든 디바이스에서 요청 수신 시, 이에 대해 응답하는 것이 불필요하기 때문에, 컨트롤러 스택은 요청을 전송하는 개수를 줄여서, BLE 컨트롤러 스택에서 전력 소비가 줄 수 있도록 제어할 수 있다.
광고 디바이스 또는 스캐닝 디바이스는 광고 패킷, 스캔 요청 또는 연결 요청을 수신하는 디바이스를 제한하기 위해 상기 디바이스 필터링 절차를 수행할 수 있다.
여기서, 광고 디바이스는 광고 이벤트를 전송하는 즉, 광고를 수행하는 디바이스를 말하며, 광고자(Advertiser)라고도 표현된다.
스캐닝 디바이스는 스캐닝을 수행하는 디바이스, 스캔 요청을 전송하는 디바이스를 말한다.
BLE에서는, 스캐닝 디바이스가 일부 광고 패킷들을 광고 디바이스로부터 수신하는 경우, 상기 스캐닝 디바이스는 상기 광고 디바이스로 스캔 요청을 전송해야 한다.
하지만, 디바이스 필터링 절차가 사용되어 스캔 요청 전송이 불필요한 경우, 상기 스캐닝 디바이스는 광고 디바이스로부터 전송되는 광고 패킷들을 무시할 수 있다.
연결 요청 과정에서도 디바이스 필터링 절차가 사용될 수 있다. 만약, 연결 요청 과정에서 디바이스 필터링이 사용되는 경우, 연결 요청을 무시함으로써 상기 연결 요청에 대한 응답을 전송할 필요가 없게 된다.
광고 절차(Advertising Procedure)
광고 디바이스는 영역 내 디바이스들로 비지향성의 브로드캐스트를 수행하기 위해 광고 절차를 수행한다.
여기서, 비지향성의 브로드캐스트는 특정 방향으로의 브로드캐스트가 아닌 전(모든) 방향으로의 브로드캐스트를 말한다.
이와 달리, 지향성 브로드 캐스트는 특정 방향으로의 브로드캐스트를 말한다. 비지향성 브로드캐스트는 광고 디바이스와 리스닝(또는 청취) 상태에 있는 디바이스(이하, 리스닝 디바이스라 한다.) 간에 연결 절차 없이 발생한다.
광고 절차는 근처의 개시 디바이스와 블루투스 연결을 확립하기 위해 사용된다.
또는, 광고 절차는 광고 채널에서 리스닝을 수행하고 있는 스캐닝 디바이스들에게 사용자 데이터의 주기적인 브로드캐스트를 제공하기 위해 사용될 수 있다.
광고 절차에서 모든 광고(또는 광고 이벤트)는 광고 물리 채널을 통해 브로드캐스트된다.
광고 디바이스들은 광고 디바이스로부터 추가적인 사용자 데이터를 얻기 위해 리스닝을 수행하고 있는 리스닝 디바이스들로부터 스캔 요청을 수신할 수 있다. 광고 디바이스는 스캔 요청을 수신한 광고 물리 채널과 동일한 광고 물리 채널을 통해, 스캔 요청을 전송한 디바이스로 스캔 요청에 대한 응답을 전송한다.
광고 패킷들의 일 부분으로서 보내지는 브로드캐스트 사용자 데이터는 동적인 데이터인 반면에, 스캔 응답 데이터는 일반적으로 정적인 데이터이다.
광고 디바이스는 광고 (브로드캐스트) 물리 채널 상에서 개시 디바이스로부터 연결 요청을 수신할 수 있다. 만약, 광고 디바이스가 연결 가능한 광고 이벤트를 사용하였고, 개시 디바이스가 디바이스 필터링 절차에 의해 필터링 되지 않았다면, 광고 디바이스는 광고를 멈추고 연결 모드(connected mode)로 진입한다. 광고 디바이스는 연결 모드 이후에 다시 광고를 시작할 수 있다.
스캐닝 절차(Scanning Procedure)
스캐닝을 수행하는 디바이스 즉, 스캐닝 디바이스는 광고 물리 채널을 사용하는 광고 디바이스들로부터 사용자 데이터의 비지향성 브로드캐스트를 청취하기 위해 스캐닝 절차를 수행한다.
스캐닝 디바이스는 광고 디바이스로부터 추가적인 사용자 데이터를 요청 하기 위해, 광고 물리 채널을 통해 스캔 요청을 광고 디바이스로 전송한다. 광고 디바이스는 광고 물리 채널을 통해 스캐닝 디바이스에서 요청한 추가적인 사용자 데이터를 포함하여 상기 스캔 요청에 대한 응답인 스캔 응답을 전송한다.
상기 스캐닝 절차는 BLE 피코넷에서 다른 BLE 디바이스와 연결되는 동안 사용될 수 있다.
만약, 스캐닝 디바이스가 브로드캐스트되는 광고 이벤트를 수신하고, 연결 요청을 개시할 수 있는 개시자 모드(initiator mode)에 있는 경우, 스캐닝 디바이스는 광고 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 광고 디바이스와 블루투스 연결을 시작할 수 있다.
스캐닝 디바이스가 광고 디바이스로 연결 요청을 전송하는 경우, 스캐닝 디바이스는 추가적인 브로드캐스트를 위한 개시자 모드 스캐닝을 중지하고, 연결 모드로 진입한다.
디스커버링 절차(Discovering Procedure)
블루투스 통신이 가능한 디바이스(이하, '블루투스 디바이스'라 한다.)들은 근처에 존재하는 디바이스들을 발견하기 위해 또는 주어진 영역 내에서 다른 디바이스들에 의해 발견되기 위해 광고 절차와 스캐닝 절차를 수행한다.
디스커버링 절차는 비대칭적으로 수행된다. 주위의 다른 디바이스를 찾으려고 하는 블루투스 디바이스를 디스커버링 디바이스(discovering device)라 하며, 스캔 가능한 광고 이벤트를 광고하는 디바이스들을 위해 찾기 위해 리스닝한다. 다른 디바이스로부터 발견되어 이용 가능한 블루투스 디바이스를 디스커버러블 디바이스(discoverable device)라 하며, 적극적으로 광고 (브로드캐스트) 물리 채널을 통해 다른 디바이스가 스캔 가능하도록 광고 이벤트를 브로드캐스트한다.
디스커버링 디바이스와 디스커버러블 디바이스 모두 피코넷에서 다른 블루투스 디바이스들과 이미 연결되어 있을 수 있다.
연결 절차(Connecting Procedure)
연결 절차는 비대칭적이며, 연결 절차는 특정 블루투스 디바이스가 광고 절차를 수행하는 동안 다른 블루투스 디바이스는 스캐닝 절차를 수행할 것을 요구한다.
즉, 광고 절차가 목적이 될 수 있으며, 그 결과 단지 하나의 디바이스만 광고에 응답할 것이다. 광고 디바이스로부터 접속 가능한 광고 이벤트를 수신한 이후, 광고 (브로트캐스트) 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 연결을 개시할 수 있다.
다음으로, BLE 기술에서의 동작 상태 즉, 광고 상태(Advertising State), 스캐닝 상태(Scanning State), 개시 상태(Initiating State), 연결 상태(connection state)에 대해 간략히 살펴보기로 한다.
광고 상태(Advertising State)
링크 계층(LL)은 호스트 (스택)의 지시에 의해, 광고 상태로 들어간다. 링크 계층이 광고 상태에 있을 경우, 링크 계층은 광고 이벤트들에서 광고 PDU(PACKet Data Unit)들을 전송한다.
각각의 광고 이벤트는 적어도 하나의 광고 PDU들로 구성되며, 광고 PDU들은 사용되는 광고 채널 인덱스들을 통해 전송된다. 광고 이벤트는 광고 PDU가 사용되는 광고 채널 인덱스들을 통해 각각 전송되었을 경우, 종료되거나 광고 디바이스가 다른 기능 수행을 위해 공간을 확보할 필요가 있을 경우 좀 더 일찍 광고 이벤트를 종료할 수 있다.
스캐닝 상태(Scanning State)
링크 계층은 호스트 (스택)의 지시에 의해 스캐닝 상태로 들어간다. 스캐닝 상태에서, 링크 계층은 광고 채널 인덱스들을 리스닝한다.
스캐닝 상태에는 수동적 스캐닝(passive scanning), 적극적 스캐닝(active scanning)의 두 타입이 있으며, 각 스캐닝 타입은 호스트에 의해 결정된다.
스캐닝을 수행하기 위한 별도의 시간이나 광고 채널 인덱스가 정의되지는 않는다.
스캐닝 상태 동안, 링크 계층은 스캔윈도우(scanWindow) 구간(duration) 동안 광고 채널 인덱스를 리스닝한다. 스캔인터벌(scanInterval)은 두 개의 연속적인 스캔 윈도우의 시작점 사이의 간격(인터벌)으로서 정의된다.
링크 계층은 스케쥴링의 충돌이 없는 경우, 호스트에 의해 지시되는 바와 같이 스캔윈도우의 모든 스캔인터벌 완성을 위해 리스닝해야한다. 각 스캔윈도우에서, 링크 계층은 다른 광고 채널 인덱스를 스캔해야한다. 링크 계층은 사용 가능한 모든 광고 채널 인덱스들을 사용한다.
수동적인 스캐닝일 때, 링크 계층은 단지 패킷들만 수신하고, 어떤 패킷들도 전송하지 못한다.
능동적인 스캐닝일 때, 링크 계층은 광고 디바이스로 광고 PDU들과 광고 디바이스 관련 추가적인 정보를 요청할 수 있는 광고 PDU 타입에 의존하기 위해 리스닝을 수행한다.
개시 상태(Initiating State)
링크 계층은 호스트 (스택)의 지시에 의해 개시 상태로 들어간다.
링크 계층이 개시 상태에 있을 때, 링크 계층은 광고 채널 인덱스들에 대한 리스닝을 수행한다.
개시 상태 동안, 링크 계층은 스캔윈도우 구간 동안 광고 채널 인덱스를 리스닝한다.
연결 상태(connection state)
링크 계층은 연결 요청을 수행하는 디바이스 즉, 개시 디바이스가 CONNECT_REQ PDU를 광고 디바이스로 전송할 때 또는 광고 디바이스가 개시 디바이스로부터 CONNECT_REQ PDU를 수신할 때 연결 상태로 들어간다.
연결 상태로 들어간 이후, 연결이 생성되는 것으로 고려된다. 다만, 연결이 연결 상태로 들어간 시점에서 확립되도록 고려될 필요는 없다. 새로 생성된 연결과 기 확립된 연결 간의 유일한 차이는 링크 계층 연결 감독 타임아웃(supervision timeout) 값뿐이다.
두 디바이스가 연결되어 있을 때, 두 디바이스들은 다른 역할로 활동한다.
마스터 역할을 수행하는 링크 계층은 마스터로 불리며, 슬레이브 역할을 수행하는 링크 계층은 슬레이브로 불린다. 마스터는 연결 이벤트의 타이밍을 조절하고, 연결 이벤트는 마스터와 슬레이브 간 동기화되는 시점을 말한다.
마스터(Master, Central)는 다른 디바이스(슬레이브, Peripheral)와 Connection을 맺기 위해, Connectable Advertising Signal을 주기적으로 스캔하다가, 적절한 디바이스에 연결을 요청하는 디바이스이다.
또한, 마스터 디바이스는 슬레이브 디바이스와 연결이 되고 나면, timing을 설정하고 주기적인 데이터 교환을 주도한다.
여기서 timing이란, 두 디바이스가 매번 같은 Channel에서 데이터를 주고 받기 위해 정하는 hopping 규칙일 수 있다.
슬레이브(Slave, Peripheral) 디바이스는 다른 디바이스(Master)와 Connection을 맺기 위해, Connectable Advertising Signal을 주기적으로 전송하는 디바이스이다.
따라서, 이를 수신한 마스터 디바이스가 Connection Request를 보내면, 이를 수락하여 Connection을 맺는다.
슬레이브 디바이스가 마스터 디바이스와 Connection을 맺고 나면 마스터 디바이스가 지정한 timing에 맞추어 Channel을 같이 hopping 하면서 주기적으로 데이터를 교환한다.
이하에서, 블루투스 인터페이스에서 정의되는 패킷에 대해 간략히 살펴보기로 한다. BLE 디바이스들은 하기에서 정의되는 패킷들을 사용한다.
패킷 포맷(Packet Format)
링크 계층(Link Layer)은 광고 채널 패킷과 데이터 채널 패킷 둘 다를 위해 사용되는 단지 하나의 패킷 포맷만을 가진다.
각 패킷은 프리앰블(Preamble), 접속 주소(Access Address), PDU 및 CRC 4개의 필드로 구성된다.
하나의 패킷이 광고 물리 채널에서 송신될 때, PDU는 광고 채널 PDU가 될 것이며, 하나의 패킷이 데이터 물리 채널에서 전송될 때, PDU는 데이터 채널 PDU가 될 것이다.
광고 채널 PDU(Advertising Channel PDU)
광고 채널 PDU(PACKet Data Unit)는 16비트 헤더와 다양한 크기의 페이로드를 가진다.
헤더에 포함되는 광고 채널 PDU의 PDU 타입 필드는 하기 표 1에서 정의된 바와 같은 PDU 타입을 나타낸다.
광고 PDU
아래 광고 채널 PDU 타입들은 광고 PDU로 불리고 구체적인 이벤트에서 사용된다.
ADV_IND: 연결 가능한 비지향성 광고 이벤트
ADV_DIRECT_IND: 연결 가능한 지향성 광고 이벤트
ADV_NONCONN_IND: 연결 가능하지 않은 비지향성 광고 이벤트
ADV_SCAN_IND: 스캔 가능한 비지향성 광고 이벤트
상기 PDU들은 광고 상태에서 링크 계층(Link Layer)에서 전송되고, 스캐닝 상태 또는 개시 상태(Initiating State)에서 링크 계층에 의해 수신된다.
Scanning PDUs
아래 광고 채널 PDU 타입은 스캐닝 PDU로 불리며, 하기에서 설명되는 상태에서 사용된다.
SCAN_REQ: 스캐닝 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
SCAN_RSP: 광고 상태에서 링크 계층에 의해 전송되며, 스캐닝 상태에서 링크 계층에 의해 수신된다.
Initiating PDUs
아래 광고 채널 PDU 타입은 개시 PDU로 불린다.
CONNECT_REQ: 개시 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
데이터 채널 PDU(Data Channel PDU)
데이터 채널 PDU는 16 비트 헤더, 다양한 크기의 페이로드를 가지고, 메시지 무결점 체크(Message Integrity Check:MIC) 필드를 포함할 수 있다.
앞에서 살펴본, BLE 기술에서의 절차, 상태, 패킷 포맷 등은 본 명세서에서 제안하는 방법들을 수행하기 위해 적용될 수 있다.
도 5는 블루투스 저전력 에너지의 GATT Profile 구조의 일 예를 나타낸 도이다.
상기 도 5를 참조하면 블루투스 저전력 에너지의 프로파일 데이터(Profile Data) 교환을 위한 구조를 살펴볼 수 있다.
구체적으로, GATT(Generic Attribute Profile)는 블루투스 LE 장치 간의 서비스(Service), 특성(Characteristic)을 이용해서 데이터를 주고 받는 방법을 정의한 것이다.
일반적으로, 페리페럴(Peripheral) 장치(예를 들면, 센서 장치)가 GATT 서버(Server)역할을 하며, 서비스(Service), 특성(Characteristic)에 대한 정의를 가지고 있다.
데이터를 읽거나 쓰기 위해서 GATT 클라이언트는 GATT 서버로 데이터 요청을 보내게 되며, 모든 동작(Transaction)은 GATT client에서 시작되어 GATT 서버로부터 응답을 받게 된다.
블루투스 LE에서 사용하는 GATT 기반 동작 구조는 프로파일(Profile), 서비스(Service), 특성(Characteristic)에 기초하며, 상기 도 5와 같은 수직 구조를 이룰 수 있다.
상기 프로파일(Profile)은 하나 또는 그 이상의 서비스들로 구성되어 있으며, 상기 서비스는 하나 이상의 특성 또는 다른 서비스들로 구성되어 있을 수 있다.
상기 서비스(Service)는 데이터를 논리적인 단위로 나누는 역할을 하며 하나 이상의 특성(Characteristic) 또는 다른 서비스들을 포함하고 있을 수 있다.
각 서비스는 UUID(Universal Unique Identifier)라 불리는 16 bit 또는 128 bit의 구분자를 가지고 있다.
상기 특성(Characteristic)은 GATT 기반 동작 구조에서 가장 하위 단위이다. 상기 특성은 단 하나의 데이터를 포함하며, 상기 서비스와 유사하게 16 bit 또는 128 bit의 UUID를 가지고 있다.
상기 특성은 여러 가지 정보들의 값으로 정의되고, 각각의 정보를 담기 위해서 속성(Attribute) 하나씩을 필요로 한다. 상기 특성은 여러 개의 연속된 속성을 사용할 수 있다.
상기 속성(Attribute)는 네 개의 구성 요소로 이루어지며, 아래와 같은 의미를 가진다.
- handle: 속성의 주소
- Type: 속성의 유형
- Value: 속성의 값
- Permission: 속성에 대한 접근 권한
이하에서, 블루투스 LE에서 connection procedure(연결 절차)에 대해 간략히 살펴보고, 이의 일례로서, 블루투스 LE에서 객체 전송 서비스를 제공하는 방법을 살펴보기로 한다.
도 6은 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.
서버는 클라이언트로 3개의 광고 채널들(channel 37, 38, 39)을 통해 광고 메시지를 전송한다(S610).
상기 서버는 Connection 전에는 광고자(Advertiser)로 호칭될 수 있고, Connection 이후에는 Master로 호칭될 수 있다. 상기 서버의 일례로, 센서들(온도 센서 등)이 있을 수 있다.
또한, 상기 클라이언트는 Connection 전에는 스캐너(Scanner)로 호칭될 수 있고, Connection 이후에는 Slave로 호칭될 수 있다. 상기 클라이언트의 일례로, 스마트폰을 들 수 있다.
살핀 것처럼, 블루투스는 2.4GHz 밴드를 통해 총 40개의 채널로 나누어 통신을 한다. 40개 채널 중 3개의 채널은 광고 채널로써, 각종 광고 패킷(Advertising Packet)을 비롯하여 Connection을 맺기 위해 주고 받는 Packet들의 교환에 이용된다.
나머지 37개의 채널들은 데이터 채널로 Connection 이후의 Data Packet 교환에 이용된다.
상기 클라이언트는 상기 광고 메시지를 수신한 후, 상기 서버로부터 추가적인 데이터(예: 서버 디바이스 이름 등)을 획득하기 위해 상기 서버로 Scan Request를 전송할 수 있다.
그러면, 상기 서버는 상기 클라이언트로 Scan Request에 대한 응답으로 나머지 데이터를 포함하여 Scan Response를 전송한다.
여기서, Scan Request와 Scan Response는 광고 패킷의 한 종류로서, 광고 패킷은 31 bytes 이하의 User Data만을 포함할 수 있다.
따라서, data의 크기가 31 bytes보다는 크지만, Connection까지 맺어서 data를 보내기에는 오버헤드가 큰 데이터가 있을 경우, Scan Request/Scan Response를 이용하여 두 번에 걸쳐서 data를 나눠 보낸다.
다음, 상기 클라이언트는 상기 서버와 블루투스 연결 설정을 위한 연결 요청(Connection Request)를 상기 서버로 전송한다(S620).
이를 통해, 상기 서버와 클라이언트 간에 Link Layer(LL)의 연결이 확립(establish)된다.
이후, 상기 서버와 상기 클라이언트는 보안 설립 절차를 수행한다.
상기 보안 설립 절차는 Secure Simple Pairing으로 해석되거나 이를 포함하여 수행될 수 있다.
즉, 상기 보안 설립 절차는 Phase 1 단계 내지 Phase 3 단계를 거쳐 수행될 수 있다.
구체적으로, 서버와 클라이언트 간에 페어링 절차(Phase 1)를 수행한다(S630).
상기 페어링 절차는 클라이언트가 서버로 페어링 요청(Pairing Request)을 전송하고, 서버가 클라이언트로 페어링 응답(Pairing Response)을 전송한다.
다음, Phase 2로서, 서버와 클라이언트 간에 레거시 페어링(Legacy Pairing) 또는 Secure Connections를 수행한다(S640).
다음, SSP Phase 3으로서, 서버와 클라이언트 간에 키 분배(Key Distribution) 절차를 수행한다(S750).
이를 통해, 서버와 클라이언트 간에 보안 연결이 확립되고, 암호화된 데이터를 송수신할 수 있게 된다.
도 7은 블루투스 저전력 에너지 기술에서 객체 전송 서비스(Object Transfer Service)를 제공하는 방법의 일 예를 나타낸 흐름도이다.
객체 전송 서비스(Object Delivery Service or Object Transfer Service)는 블루투스 통신에서 벌크 데이터(bulk data)와 같은 객체 또는 데이터를 송/수신하기 위해 BLE에서 지원하는 서비스를 말한다.
서버 디바이스와 클라이언트 디바이스 간에 블루투스 연결 설정을 위해 S710~S730 단계에 해당하는 광고 과정 및 스캐닝 과정이 진행된다.
먼저, 서버 디바이스는 객체 전송 서비스를 포함하여 상기 서버 디바이스 관련 정보를 알리기 위해 클라이언트 디바이스로 광고 메시지를 전송한다(S710).
상기 광고 메시지는 광고 PDU(PACKet Data Unit), 광고 패킷, 광고, 광고 프래임, 광고 물리 채널 PDU 등으로 표현될 수 있다.
상기 광고 메시지는 서버 디바이스에서 제공하는 서비스 정보(서비스 이름 포함), 서버 디바이스의 이름, 제조자 데이터 등을 포함할 수 있다.
또한, 상기 광고 메시지는 브로드캐스트 방식 또는 유니캐스트(unicast) 방식으로 상기 클라이언트 디바이스로 전송될 수 있다.
이후, 상기 클라이언트 디바이스는 서버 디바이스 관련 보다 자세한 정보를 알기 위해 스캔 요청(Scan Request) 메시지를 상기 서버 디바이스로 전송한다(S720).
상기 스캔 요청 메시지는 스캐닝(Scanning) PDU, 스캔 요청 PDU, 스캔 요청, 스캔 요청 프래임, 스캔 요청 패킷 등으로 표현될 수 있다.
이후, 상기 서버 디바이스는 상기 상기 클라이언트 디바이스로부터 수신된 스캔 요청 메시지에 대한 응답으로 스캔 응답(Scan Response) 메시지를 상기 클라이언트 디바이스로 전송한다(S730).
상기 스캔 응답 메시지에는 상기 클라이언트 디바이스에서 요청한 서버 디바이스 관련 정보가 포함된다. 여기서, 상기 서버 디바이스 관련 정보는 객체 전송 서비스 제공과 관련하여 서버 디바이스에서 전송할 수 있는 객체 또는 데이터 등일 수 있다.
광고 과정 및 스캐닝 과정이 종료하는 경우, 상기 서버 디바이스와 상기 클라이언트 디바이스는 S740~S770 단계에 해당하는 연결 개시(Initiating Connection) 과정, 데이터 교환(Data Exchange) 과정을 수행한다.
구체적으로, 상기 클라이언트 디바이스는 상기 서버 디바이스와 블루투스 통신 연결을 위해 상기 서버 디바이스로 연결 요청(Connect Request) 메시지를 전송한다(S740).
상기 연결 요청 메시지는 연결 요청 PDU, 개시(Initiation) PDU, 연결 요청 프래임, 연결 요청 등으로 표현될 수 있다.
S740 단계를 통해, 상기 서버 디바이스와 상기 클라이언트 디바이스 간에 블루투스 연결이 확립되며, 이후 상기 서버 디바이스와 상기 클라이언트 디바이스는 데이터를 교환하게 된다. 상기 데이터 교환 과정에서 데이터는 데이터 채널 PDU를 통해 송수신될 수 있다.
상기 클라이언트 디바이스는 데이터 채널(Data Channel) PDU를 통해 객체 데이터 요청을 상기 서버 디바이스로 전송한다(S750). 상기 데이터 채널 PDU는 데이터 요청 메시지, 데이터 요청 프래임 등으로 표현될 수 있다.
이후, 상기 서버 디바이스는 상기 클라이언트 디바이스에서 요청한 객체 데이터를 데이터 채널 PDU를 통해 상기 클라이언트 디바이스로 전송한다(S760).
여기서, 상기 데이터 채널 PDU는 Attribute protocol에서 정의한 방식으로 상대 디바이스에게 데이터를 제공하거나 데이터 정보를 요청하기 위해 사용된다.
이후, 상기 서버 디바이스에서 데이터의 변경이 발생하는 경우, 상기 서버 디바이스는 데이터 또는 객체의 변경을 알리기 위해 상기 클라이언트 디바이스로 데이터 채널 PDU를 통해 데이터 변경 지시(Data Changed Indication) 정보를 전송한다(S770).
이후, 상기 클라이언트 디바이스는 변경된 데이터 또는 변경된 객체를 찾기 위해 상기 서버 디바이스로 변경된 객체 정보를 요청한다(S780).
이후, 상기 서버 디바이스는 상기 변경된 객체 정보 요청에 대한 응답으로 상기 클라이언트 디바이스로 상기 서버 디바이스에서 변경된 객체 정보를 전송한다(S790).
이후, 상기 클라이언트 디바이스는 상기 수신된 변경된 객체 정보와 현재 상기 클라이언트 디바이스가 가지고 있는 객체 정보와 비교 분석을 통해 변경된 객체를 찾는다.
다만, 상기 클라이언트 디바이스는 변경된 객체 또는 데이터를 찾을 때까지 S780 및 S790 단계를 반복적으로 수행한다.
이후, 상기 호스트 디바이스와 상기 클라이언트 디바이스 간에 연결 상태가 유지될 필요가 없는 경우, 상기 호스트 디바이스 또는 상기 클라이언트 디바이스는 해당 연결 상태를 종료(Disconnect)시킬 수 있다.
도 8은 블루투스 BR/EDR 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.
도 8에 도시된 바와 같이, 블루투스 BR/EDR에서의 연결 절차(connection procedure)는 아래와 같은 단계들로 구성될 수 있다.
상기 연결 절차는 페어링 절차(pairing procedure)로도 표현될 수 있다.
블루투스 페어링 절차(pairing procedure)는 대기 상태(Standby State)와 연결 상태(Connected State)로만 구분된다.
블루투스 페어링이 완료된 디바이스는 상기 연결 상태(Connected State)가 되고, 접속이 종료된 장치는 대기 상태(Standby State)로 동작한다.
또한, 블루투스 디바이스들은 특정 디바이스와 연결 절차를 통해 연결되었다가, 이후 재 연결하기 위해 재 연결 절차를 수행할 수 있다.
재 연결 절차는 연결 절차와 동일한 절차를 통해 수행될 수 있다.
구체적으로, 마스터 디바이스는 전원이 입력되면 기본적으로 대기 상태에 진입한다.
이후, 블루투스를 연결하기 위해 주변 디바이스들을 발견하기 위한 인쿼리(Inquiry) 절차(S811)를 수행한다.
즉, 마스터 디바이스는 주변의 연결할 수 있는 디바이스(슬레이브)를 발견(Discovery)하기 위해서 인쿼리 상태(Inquiry State)가 될 수 있으며, 슬레이브 디바이스는 주변의 디바이스(마스터)가 인쿼리 상태에서 전송하는 ID 패킷을 수신하기 위해서 인쿼리 스캔 상태(Inquiry scan State)가 될 수 있다.
상기 인쿼리 상태가 된 마스터 디바이스는 주변의 연결할 수 있는 디바이스를 발견하기 위해, 일회 또는 소정 시간 간격마다 ID 패킷을 이용한 인쿼리 메시지를 전송한다.
상기 ID 패킷은 GIAC(General Inquiry Access Code) 또는 DIAC(Dedicated Inqury Access Code)일 수 있다.
슬레이브 디바이스는 마스터 디바이스가 전송한 ID 패킷인 GIAC 또는 DIAC를 수신한 후, 상기 마스터 디바이스와 블루투스 페어링을 하기 위해서, 주파수 호핑 시퀸스(Frequency Hoppinf Sequence, FHS)를 전송한다.
또한, 필요에 의해서, 전송할 데이터가 존재하는 경우 확장된 인쿼리 응답(Extended Inquiry Response, 이하 EIR이라고 한다.)를 마스터 디바이스로 전송할 수 있다.
상기 인쿼리 절차를 통해서 주변의 연결 가능한 블루투스 디바이스를 찾아내면, 페이징 절차(S812)를 수행한다.
상기 페이징 절차(S812)는 상기 인쿼리 절차를 통해서 주변의 연결 가능한 블루투스 디바이스를 찾아내면, 어드레스와 클럭 정보 등으로 호핑 시퀸스를 동기화하여 실제 커넥션을 수행하는 단계를 말한다.
구체적으로, 상기 페이징 절차는 (1) 마스터 디바이스가 슬레이브 디바이스로 Page를 전송하는 단계, (2) 슬레이브 디바이스가 마스터 디바이스로 Slave Page Response를 전송하는 단계, (3) 마스터 디바이스가 슬레이브 디바이스로 Master Page Response를 전송하는 단계로 구분될 수 있다.
상기 인쿼리 절차와 상기 페이징 절차가 완료되면, 마스터 디바이스와 슬레이브 디바이스는 보안 설립(Security Establishment) 단계(S814)를 수행하고, 이후 L2CAP 연결 및 서비스 디스커버리(Service Discovery) 단계(S815)를 수행한다.
상기 보안 설립 단계를 수행하기 전에, 마스터 디바이스와 슬레이브 디바이스는 I(Input)/O(Output) 능력을 서로 교환한다(S813).
이는 I/O capability request와 I/O capability response를 통해 수행될 수 있다.
또한, 상기 보안 설립 단계는 후술할 Secure Simple Pairing 절차를 포함하거나 같은 의미로 해석될 수도 있다.
상기 L2CAP(Logical Link Control and Adaption Protocol)은 패킷 방식의 프로토콜로서 UDP 프로토콜과 비슷한 특징을 가지고 있다. 기본 최대 672 byte의 패킷 사이즈를 가지지만 통신이 시작되면 최대 65,535 byte까지 변경이 가능하다.
상기 L2CAP연결 및 서비스 디스커버리 단계를 수행한 후, 마스터 디바이스는 사용자로부터 입력받은 데이터를 슬레이브 디바이스로 전송할 수 있다(S816).
이와 같은 연결 절차를 수행한 마스터 디바이스와 슬레이브 디바이스는 일정 시간 동안 서로 간의 데이터 교환이 없게 되면, 에너지 소모를 방지하기 위하여 슬립(Sleep) 상태로 전환되며, 연결 상태는 종료하게 된다.
이후, 마스터 디바이스와 슬레이브 디바이스가 다시 데이터를 송/수신하기 위해서는 재 연결 절차를 수행한다.
재 연결 절차는 앞서 살핀 연결 절차와 동일한 단계를 통해 수행될 수 있다.
메시 네트워크(Mesh Network)
이하, 메쉬 네트워크에 대해 살펴보도록 한다.
도 9는 본 명세서가 적용될 수 있는 블루투스 메쉬 네트워크(Mesh Network)의 일 예를 나타낸 개략도이다.
상기 도 9에 도시된 바와 같이, 메쉬 네트워크는 다수의 디바이스들이 블루투스를 통해서 그물망처럼 연결되어 데이터를 송수신할 수 있는 네트워크를 말한다.
블루투스 메쉬 네트워크 기술은 데이터를 전송하는 소스 디바이스(200-1)와 데이터를 수신하는 데스티네이션 디바이스(200-2) 중간에 메시지를 중계(또는 릴레이)하는 하나 또는 그 이상의 디바이스들이 존재한다.
이때, 소스 디바이스 및 데스티네이션 디바이스는 엣지 노드(Edge node, 200-1, 200-2)로 호칭될 수 있으며, 중간에 메시지를 중계하는 하나 또는 그 이상의 디바이스들은 메시지를 릴레이하는 릴레이 노드(Relay node)로 호칭될 수 있다.
또는, 위치가 쉽게 변경되는 디바이스, 즉, 이동성을 가진 디바이스(200-1, 200-2) 및 초기에 설치된 상태에서 이동성 없이 고정된 디바이스들로 구성될 수 있다.
각 릴레이 노드들은 최근에 수신한 메시지의 메시지 캐시(message cache)를 포함하고 있다. 만약 수신된 메시지가 이미 메시지 캐시에 존재하는 경우, 상기 메시지는 릴레이 되지 않는다.
하지만, 상기 수신된 메시지가 메시지 캐시에 존재하지 않는 다면, 메시지는 릴레이 되고, 메시지는 메시지 캐시에 저장되게 된다.
엣지 노드는 일반적으로 배터리를 통해서 전력을 공급 받고, 평소에는 슬립 상태로 존재하다가 상호 작용 또는 주기적으로 깨어날 수 있다.
상기 엣지 노드는 아래의 조건을 만족하면 수신된 메시지를 처리할 수 있다.
- 메시지가 메시지 캐시에 존재하지 않음.
- 메시지가 알려진 네트워크 키에 의해서 인증됨.
- 메시지의 목적지가 상기 엣지 노드의 유니 캐스트 주소 이거나, 브로드캐스트 주소 또는 그룹 주소가 상기 엣지 노드가 속해 있는 곳의 주소인 경우.
릴레이 노드는 일반적으로 메인 파워를 공급 받는 디바이스로써, 항상 깨어 있으며, 다른 노드들을 위해서 수신한 데이터를 전송할 수 있다.
릴레이 노드는 아래의 조건을 만족하면 수신한 메시지를 다른 노드로 재 전송할 수 있다.
- 메시지가 메시지 캐시에 존재하지 않음.
- 메시지가 알려진 네트워크 키에 의해서 인증됨.
- 메시지의 릴레이 여부를 나타내는 필드(예를 들면, 릴레이 횟수 값)가 릴레이를 허용하는 값인 경우.
- 목적지 주소가 상기 릴레이 노드에게 할당된 유니 캐스트 주소가 아닌 경우.
블루투스 메쉬 네트워크에서는 릴레이 노드들(200-3, 200-4)의 데이터 전송 방식에 따라 플로딩(flooding) 방식과 라우팅(routing) 방식으로 구분할 수 있다.
상기 플로딩 방식은 무선 전파가 공기 중에서 사방으로 퍼지는 특성을 이용하여 메시지를 수신하는 릴레이 노드들이 이를 다시 공기 중에 쏘는 방식을 말한다.
즉, 소스 디바이스(200-1)가 브로드캐스트 채널들을 통해서 메시지를 릴레이 노드들(200-3, 200-4)로 전송하고, 이를 수신한 릴레이 노드들은 상기 메시지를 다시 인접 릴레이 노드들로 전송하여 데스티네이션 디바이스(200-2)로 전송하는 방식을 말한다.
상기 플로딩 방식에서는 메시지의 수신 및 재전송을 위해서 브로드캐스팅 채널을 사용하며, 메시지의 전송범위를 확장 시켜줄 수 있다.
상기 플로딩 기법의 메쉬 네트워크는 동적 네트워크로써, 상기 플로딩 방식의 메쉬 네트워크에서 디바이스는 어느 때라도 디바이스의 밀도(density)가 만족하는 한 메시지를 수신하고 전송(또는 재 전송)하는 것이 가능할 수 있다.
상기 플로딩 기법은 구현이 쉽다는 장점이 있지만 메시지들이 방향성이 없이 전송되기 때문에 네트워크가 확장될수록 확장성 문제가 발생할 수 있다.
즉, 상기 플로딩 방식의 메쉬 네트워크는 디바이스가 메시지를 전송하면 다수의 디바이스들이 상기 메시지를 수신하고, 수신된 메시지를 다시 또 다른 다수의 디바이스들에게 전송한다.
이를 방지하기 위해서, 메쉬 네트워크를 구성하는 디바이스들의 숫자는 100개에서 1000개 사이로 조절될 수 있으며, 정확한 디바이스들의 숫자는 여러가지 요소에 의해서 결정될 수 있다.
예를 들면, 네트워크 커패시티, 데이터 소스들의 트래픽 부하, 네트워크의 Latency 및 신뢰성 요구사항 등에 의해서 결정될 수 있다.
또한, 플로딩 방식은 라우팅 방식과 다르게 라우팅 테이블의 구축 비용 없이 쉽게 메시지의 전달이 가능하지만, 메시지를 받은 릴레이 디바이스들(200-3, 200-4) 모두가 다시 전송 받은 메시지를 재 전송하는 특성으로 인하여 네트워크 트래픽을 증가시키는 단점이 존재한다.
상기 라우팅 방식은 소스 디바이스(200-1)는 특정 릴레이 노드로 메시지를 전송하고, 이를 수신한 상기 특정 릴레이 노드는 메시지를 재 전송할 다른 릴레이 노드 또는 데스티네이션 노드(200-2)의 정보를 가지고 메시지를 전송하게 된다.
상기 라우팅 방식은 메시지의 수신 및 재전송을 위해서 브로드캐스팅 채널 또는 Point-to-Point 연결 방식을 사용한다.
또한, 상기 라우팅 방식에서 메시지를 수신한 라우팅 디바이스는 중간 디바이스 또는 목적지 디바이스로 상기 메시지를 전송하기 위한 가장 최선의 라우팅 루트(들)를 결정하고, 결정된 라우팅 테이블에 기초하여 메시지를 어떤 루트로 전송할지 여부를 결정한다.
상기 라우팅 방식은 확장성이 좋다는 장점이 있지만, 각 노드들은 라우팅 테이블들을 유지하며 메시지를 전송해야 되기 때문에, 메시지가 증가함에 따라 복잡성(Complexity)이 커지고, 많은 메모리를 요구하며, 플로딩 방식보다 덜 동적이고 구현하는데 더 어렵다는 단점이 존재한다.
도 10은 본 명세서가 적용될 수 있는 블루투스 메쉬 네트워크(Mesh Network)의 프로토콜 스택의 일 예를 나타낸 도이다.
상기 도 10을 참조하면, 메쉬 네트워크의 프로토콜 스택은 베어러 계층(81), 네트워크 계층(82), 전송 계층(83), 어플리케이션 계층(84)으로 구성된다.
상기 베어러 계층(81)은 노드간에 메시지가 전송되는 방법을 정의한다. 즉, 메쉬 네트워크에서 메시지가 전송되는 베어러를 결정한다.
메쉬 네트워크에서는 메시지 전송을 위한 애드버타이징 베어러(advertising bearer) 및 GATT 베어러(GATT Bearer)가 존재한다.
상기 네트워크 계층(82)은 메쉬 네트워크에서 메시지가 하나 또는 그 이상의 노드들로 보내지는 방법 및 상기 베어러 계층(81)에 의해서 전송되는 네트워크 메시지들의 포맷을 정의한다.
또한, 상기 네트워크 계층(82)은 메시지가 릴레이 또는 포워딩될지 여부 및 네트워크 메시지들의 인증 및 암호화 방법을 정의한다.
상기 전송 계층(83)은 어플리케이션 메시지의 기밀성(Confidentiality)을 제공하여 어플리케이션 데이터의 암호화 및 인증을 정의한다.
상기 어플리케이션 계층(84)은 상위 계층 어플리케이션이 상기 전송 계층(73)을 어떻게 사용하는지 여부와 관련된 방법 및 어플리케이션 동작 코드(Opcode), 파라미터들을 정의한다.
도 11은 본 명세서가 적용될 수 있는 디바이스가 블루투스 메쉬 네트워크(Mesh Network)에 참여하기 위한 방법의 일 예를 나타낸 흐름도이다.
새로운 디바이스 또는 프로비저닝 되지 않은 디바이스가 메쉬 네트워크에 참여(join)하여 동작하기 위해서는 프로비저닝(Provisioning) 절차를 거쳐야 한다.
상기 프로비저닝 절차는 인증되지 않은 디바이스를 인증하고, 메쉬 네트워크에 참여하기 위한 기본적인 정보(예를 들면, 유니캐스트 주소(Unicast Address), 각종 키들 등)을 제공하기 위한 절차를 의미한다.
즉, 상기 프로비저닝 절차는 메쉬 네트워크의 프로비저너(Provisioner, 제 2 디바이스(400))가 메쉬 네트워크에 참여하기 위한 정보를 제공하는 절차로써, 상기 프로비저닝 절차를 통해서 상기 제 1 디바이스(300)는 네트워크의 주소, 키들, 디바이스 식별자 및 메쉬 네트워크의 일부로써 동작하기 위한 다양한 정보를 획득할 수 있다.
상기 프로비저닝 절차는, 초대 단계(Invitation Step), 공용 키 교환 단계(Exchanging Public Key Step), 인증 단계(Authentication Step) 및 프로비저닝 데이터 배포 단계(Distribution of Provisioning Step)으로 구성된다.
상기 프로비저닝 절차는 다양한 종류의 베어러들을 통해서 수행될 수 있다. 예를 들면, 광고에 기초한 베어러(advertising-based bearer), 메쉬 프로비저닝 서비스에 기초한 베어러(Mesh Provisioning Service-based bearer) 또는 메쉬에 기초한 베어러(Mesh-based bearer)에 의해서 수행될 수 있다.
상기 광고에 기초한 베어러는 필수적으로 설립되는 베어러로 상기 광고에 기초한 베어러를 지원하지 않거나, 프로비저닝 데이터가 상기 광고에 기초한 베어러를 통해서 전송될 수 없는 경우에 상기 프로비저닝 서비스에 기초한 베어러 또는 메쉬에 기초한 베어러가 프로비저닝 절차에 사용될 수 있다.
상기 프로비저닝 서비스에 기초한 베어러는 기존의 블루투스 LE의 GATT Protocol을 통해서 프로비저닝 데이터를 주고 받기 위한 베어러를 의미하며, 상기 메쉬에 기초한 베어러는 상기 제 1 디바이스(300)와 상기 제 2 디바이스(400)가 직접적으로 데이터를 주고 받을 수 있는 거리에 존재하지 않는 경우, 메쉬 네트워크를 통해서 프로비저닝 데이터를 주고 받을 수 있는 베어러를 의미한다.
상기 광고에 기초한 베어러의 설립 절차는 이후에 살펴보도록 한다.
상기 베어러가 제 1 디바이스(300)와 상기 제 2 디바이스(400)사이에 설립된 뒤에, 아래의 프로비저닝 절차를 통해서 상기 제 1 디바이스(300)는 프로비전될 수 있다.
초대 단계(Invitation Step)
상기 초대 단계는 상기 제 2 디바이스(400)가 상기 제 1 디바이스(300)를 스캐닝(Scanning)하면서 시작된다. 상기 제 1 디바이스는 비콘 메시지를 상기 제 2 디바이스(400)로 전송한다(S1110). 상기 비콘 메시지는 상기 제 1 디바이스(300)의 UUID를 포함한다.
상기 비콘 메시지를 통해서 상기 제 1 디바이스(300)를 스캐닝한 상기 제 2 디바이스(400)는 상기 제 1 디바이스(300)로 초대 메시지(Invite message)를 전송한다(S1120).
상기 초대 메시지는 상기 제 1 디바이스(300)가 프로비저닝 절차를 수행할 지 여부를 묻는 것으로써, 상기 제 1 디바이스(300)가 상기 프로비저닝 절차를 수행하는 것을 원하지 않을 경우, 상기 초대 메시지를 무시한다.
하지만, 상기 제 1 디바이스(300)가 상기 프로비저닝 절차를 수행하는 것을 원하는 경우, 즉, 메쉬 네트워크에 참여하려는 경우, 상기 제 1 디바이스(300)는 이에 대한 응답으로 능력 메시지(Capability message)를 전송한다(S1130).
상기 능력 메시지는 상기 제 1 디바이스(300)가 보안 알고리즘의 설정을 지원하는지 여부, 공개 키(Public Key), 사용자에게 값을 출력할 수 있는지 여부를 나타내는 정보 및 사용자로부터 값을 입력 받을 수 있는지 여부를 나타내는 정보 등을 포함할 수 있다.
공용 키 교환 단계(Exchanging Public Key Step)
이후, 상기 제 2 디바이스(400)는 상기 제 1 디바이스(300)로 프로비저닝 시작을 위한 시작 메시지를 전송한다(S1140).
만약, 대역 외 기술(Out of band technology)를 사용하여 공개 키(Public Key)를 이용할 수 없는 경우, 상기 제 2 디바이스(400)와 상기 제 1 디바이스(300)는 공개 키들을 교환한다(S1150, S1160).
하지만, 대역 외 메커니즘을 통해서 공개 키를 이용할 수 있는 경우, 상기 제 2 디바이스(400)는 상기 제 1 디바이스(300)로 임시 공개 키(ephemeral public key)를 전송하고, 상기 제 1 디바이스(300)로부터 대역 외 기술을 사용하여 스태틱 공개 키를 읽어올 수 있다.
이후, 상기 제 2 디바이스(400)는 상기 제 1 디바이스(300)와 인증 절차를 수행하여 상기 제 1 디바이스(300)를 인증한다(S1170).
프로비저닝 데이터 배포 단계(Distribution of Provisioning Data Step)
상기 제 1 디바이스(300)가 인증되면, 상기 제 2 디바이스(400)와 상기 제 1 디바이스(300)는 세션 키를 계산하여 생성한다.
이후, 상기 제 2 디바이스(400)는 상기 제 1 디바이스(300)로 프로비저닝 데이터를 전송한다(S1180).
상기 프로비저닝 데이터는 어플리케이션 키, 디바이스 키, 네트워크 키, IVindex, 및 유니캐스트 주소 등을 포함할 수 있다.
상기 프로비저닝 데이터를 수신한 상기 제 1 디바이스(300)는 이에 대한 응답으로 완료 메시지를 전송하고, 프로비저닝 절차는 종료되게 된다(S1190).
방향 찾기(Direction Finding)
Bluetooth 근접 솔루션 및 포지셔닝 시스템들은 거리를 추정하기 위해 신호 강도를 현재 사용한다.
Bluetooth Core Specification v5.1 에서 새로운 방향 찾기 특징은 블루투스 디바이스들이 블루투스 신호 전송의 방향을 결정하는 것을 가능하게 한다.
이 새로운 특징은 블루투스 신호가 높은 정확도를 가지고 전송되는 각도를 결정하기 위해 2 가지 방법을 제공한다. 2 가지 방법들은 도착 각도(AoA, Angle of Arrival) 및 출발 각도(AoD, Angle of Departure)로 불린다.
각 기술은 두 개의 통신 장치들 중 하나가 다수의 안테나들의 어레이를 가질 것을 요구한다. 안테나 어레이는 AoA 방법을 사용할 때 수신 장치에 포함되고, AoD를 사용할 때 전송 장치에 포함된다.
도 12 는 본 명세서에서 제안하는 방법이 적용될 수 있는 도착 각도(AoA) 및 출발 각도(AoD)의 일례를 나타낸다.
특히, 도 12(a)는 도착 각도의 일례를, 도 12(b)는 출발 각도의 일례를 나타낸 도이다.
Bluetooth Core Spec. v5.1 은 수신 장치의 Bluetooth Low Energy (BLE) controller 에 데이터를 생성하는 기능을 제공하여 전송 장치에 대한 방향 각도를 계산하는 데 사용할 수 있다. 이 Bluetooth Core Spec. v5.1 에서 방향 찾기를 추가하는 것은 궁극적으로 Bluetooth 위치 서비스의 주요 향상을 가능하게 하는 Bluetooth 로드맵의 여러 단계 중 첫 번째 단계이다. 연관된 프로파일(Profile)들이 release 되며, Bluetooth 개발자는 실시간 위치 확인 시스템(real-time locating systems, RTLS) 및 실내 위치 시스템(indoor positioning systems, IPS)와 같은 고정밀, 상호 운용 가능한 위치 시스템을 만들기 위해 새로운 방향 찾기 컨트롤러 능력을 개발할 것이다. 새로운 방향 찾기 기능은 특히 방향 항목 찾기 및 관심 지점 정보 솔루션에서 장치 방향을 결정하여 Bluetooth 근접 솔루션을 향상시킬 수 있는 잠재력을 가지고 있다.
Bluetooth 방향 찾기 특징은 특정 시간에 안테나에 입사되는 전파의 위상을 측정하기 위해 IQ (In-Phase and Quadrature) 샘플링을 사용한다. AoA 접근 방식에서, 샘플링 프로세스는 어레이 설계에 의존하는 적절한 시퀀스로, 그리고 한 번에 하나씩 안테나 어레이의 각 안테나에 적용된다.
샘플링된 데이터는 호스트 컨트롤러 인터페이스 (Host Controller Interface, HCI)를 통해 스택 위로 전달되며, 한 장치에서 다른 장치의 방향을 계산하기 위해 적절한 알고리즘을 샘플링된 데이터에 적용하는 것이 가능하다. IQ 샘플에서 각도를 계산하는 알고리즘은 Core Spec. v5.1 에 정의되지는 않는다. 일단 연관된 프로파일들이 이용가능한 경우, 애플리케이션 개발자는 의도된 사용 사례(use case)에 적합한 알고리즘을 구현할 기회를 갖게 된다.
스택의 상위 계층(higher layer)에서 IQ 샘플들의 사용 및 IQ 샘플링을 지원하기 위해, 링크 계층(link layer, LL) 및 HCI가 각각 변경되었다.
링크 계층에서 CTE (Constant Tone Extension)라는 새 필드가 정의되었다 (도 13 참조). CTE 필드의 목적은 IQ 샘플링이 수행될 수 있는 일정한 주파수 및 파장 신호 재료(wavelength signal material)을 제공하는 것이다. 이 필드에는 1 로된 시퀀스를 포함하며, 일반적인 화이트닝 프로세스(whitening process)가 적용되지 않으며, CRC 계산에 포함되지 않는다.
도 13은 CTE 필드의 일례를 나타낸 도이다.
도 13 의 패킷은 프리앰블 필드, 액세스-주소 필드, PDU 및 CRC 를 포함하고, 선택적으로 CTE 필드를 포함하는 것을 알 수 있다. CTE 는 비연결(connectionless) 및 연결 지향(connection-oriented) 시나리오 모두에서 사용될 수 있다. 비연결 사용을 위해, 주기적인 광고 기능이 요구되며(샘플링 프로세스에서 결정적 타이밍이 중요), CTE 가 AUX_SYNC_IND PDU 에 추가된다. 연결 지향 사용을 위해, 새로운 PDU 들 LL_CTE_REQ 및 LL_CTE_RSP 가 정의되었다. 어느 하나의 경우에서, CTE 길이, 안테나 스위칭 패턴의 길이, 및 안테나 ID와 같은 CTE PDUs 의 다양한 측면을 구성할 수 있는 새로운 HCI PDU가 있다.
GATT 캐싱 향상(caching enhancement)
모든 Bluetooth LE 연결 장치는 GATT 를 사용한다. 따라서 GATT 캐싱의 주제는 다양한 장치 타입과 관련이 있다. GATT 장치는 속성 테이블(attribute table)로 알려진 데이터 베이스를 포함한다. 속성 테이블은 GATT 서비스, characteristic, descriptor 구조 세부 사항 및 값들을 포함하고, GATT 기반 Bluetooth LE 장치가 어떻게 작동하는지가 핵심이다. 속성 테이블의 엔트리들은 속성 핸들(attribute handle)로 식별된다. GATT 클라이언트는 클라이언트가 연결된 리모트 GATT 서버 장치의 속성 테이블에 대한 세부 정보를 얻기 위해 서비스 디스커버리(service discovery)로 알려진 절차를 수행해야 한다. 상기 GATT 클라이언트는 서버와의 후속 ATT (속성 프로토콜) 상호 작용에서 속성 핸들을 식별하는 것을 포함하여 이러한 세부 사항들을 사용할 수 있다.
도 14는 서비스 디스커버리 및 속성 캐싱의 일례를 나타낸 도이다.
일부 장치는 수명 동안 속성 테이블 구조를 변경하지 않는다. 속성 테이블에서 GATT 서비스, 특성(characteristic) 및 descriptor 들은 항상 동일하며, 특성 또는 descriptor의 일부 값만 변경된다. 다른 장치는 때때로 속성 테이블을 변경한다. 서비스 디스커버리(또는 서비스 검색)은 시간이 걸리고, 에너지가 소비된다. 따라서, Bluetooth Core Specification v5.1 은 아무것도 변경되지 않은 경우 클라이언트가 서비스 디스커버리를 건너 뛸 수 있도록 하는 속성 캐싱 전략을 정의한다. 이전에, 캐싱 및 클라이언트 / 서버 속성 테이블 동기화가 Generic Attribute Service 에 있을 수 있는 서비스 변경 특성을 사용해서만 제어되었다.
GATT 서버는 ATT indication 을 클라이언트에 전송하여 속성 테이블이 변경되었음을 연결된 클라이언트에 알릴 수 있다. 클라이언트는 ATT 확인(confirmation)으로 응답하고, 자신의 속성 캐시를 서버의 속성 캐시와 동기화하기 위해 서비스 디스커버리를 수행한다.
GATT 서버에 연결된 적이 있는 모든 클라이언트를 추적하고, 각 클라이언트가 최신 속성 테이블 변경에 대해 알림을 받았는지 여부를 추적하기 위해 필요한 GATT 서버를 피하기 위해, 이전에 Core Spec.은 신뢰관계가 없는(즉, 연결되지 않은) 클라이언트와 서버가 연결할 때마다 서비스 디스커버리를 수행해야 했다.
이 규칙은 일부 제품 타입들에 대해 에너지 효율성 및 사용자 경험 문제를 일으킬 수 있다.
또한, 속성 테이블이 ATT Service Changed indication 을 사용하여 변경되었음을 클라이언트에 알리려는 시도를 한 번만 수행한 것 외에 속성 테이블의 클라이언트의 관점 대 서버의 관점에 관하여 수행된 추가 상태 관리가 없었다.
이 접근 방식은 속성 테이블 변경과 관련하여 클라이언트와 서버 간의 통신에서 경쟁 조건을 허용했고,
일반적인 ATT 상호 작용이 존재하도록 했다. 여기서, 클라이언트가 서버에 연결한 후 service changed indication 을 기다리는 동안 시간 초과하는 것을 가능하게 하고, 일반 ATT PDU 전송을 진행하고, 그 이후 클라이언트는 service changed indication을 받는다.
향상된 캐싱 전략(Improved Caching Strategy)
Bluetooth Core Spec. v5.1 은 속성 캐싱 및 캐시 동기화가 GATT 클라이언트 및 서버에 의해 접근되는 방식을 변경한다. 이것은 서버와 신뢰관계가 없는 클라이언트가 연결을 통해 클라이언트의 속성 캐시를 유지하도록 허용하고, 앞에서 설명한 경쟁 조건 이슈를 해결해서 상당한 사용자 경험과 에너지 효율성 향상을 제공한다.
각각 Generic Attribute Service 의 멤버인 2 개의 새로운 특성들이 도입되었다: 데이터베이스 해시(Database Hash) 및 클라이언트 지원 기능(Client Supported Feature). 서버와 신뢰관계가 없는 클라이언트는, 서버의 클라이언트 지원 기능 특성에서 플래그를 업데이트하는 클라이언트에 의해 지시되는 것처럼 클라이언트가 새로운 데이터 베이스 해시 특성을 지원하는 경우, 연결을 통해 속성 테이블을 캐시할 수 있다.
데이터베이스 해시 특성은 클라이언트가 서비스 변경 지시(service changed indication)를 사용하여 알려주는 서버에 의존하지 않고 변경된 사항이 있는지 서버에 요청할 수 있도록 한다. 서버는 속성 테이블의 적절한 측면에서 계산된 해시 값인 데이터베이스 해시 특성의 값을 유지 관리한다. 클라이언트는 연결 설정 후 즉시 값을 읽는다.
클라이언트는 데이터베이스 해시 값을 캐시할 수 있고, 원격 속성 테이블이 변경되었는지 여부를 결정하기 위해 데이터베이스 해시 값을 후속적으로 사용한다. 만약 원격 속성 테이블이 변경된 경우 클라이언트는 다시 서비스 디스커버리를 수행한다.
만약 원격 속성 테이블이 변경되지 않은 경우, 클라이언트는 서비스 디스커버리를 수행할 필요가 없다.
이는 일부 장치 타입에 주요 사용자-경험 및 에너지 효율성의 이점을 제공한다.
또한, 클라이언트는 연결 중인 장치가 이전에 연결되어 있고 속성 테이블이 클라이언트에 의해 이미 캐시된 장치의 동일한 타입이라고 추론할 수 있다. 만약 연결된 장치의 데이터베이스 해시가 클라이언트의 속성 캐시에 연결된 것과 동일하고 장치 제조업체와 같은 기타 세부 정보가 동일하면 클라이언트는 다른 장치에서 얻은 속성 캐시에 이미 동일한 데이터가 포함되어 있으므로 연결된 장치에 대한 서비스 검색을 수행 할 필요가 없다고 결론을 내릴 수 있다.
일부 어플리케이션에 대해, 이 변경은 상당한 가치가 있다. 예를 들어, 블루투스 스마트 락(smart lock)을 고려해보자.
여기서, 스마트폰 또는 기타 클라이언트 장치는 인증하기 위해 빌딩 내 문(door)과 상호 작용하여 사용자가 접근할 때 사용자를 위해 문을 연다.
서비스 디스커버리는 사용자가 스마트 잠금 장치를 사용하여 처음으로 문을 통과하려고 할 때만 수행될 필요가 있다. 사용자는 이 첫 번째 기회(occasion) 동안 잠금 해제하는 문에서 지연을 감지할 수 있지만, 이후에 사용자가 빌딩 서비스 디스커버리에서 문에 접근할 때마다 필요하지는 않고, 사용자는 스마트 락으로부터 거의 즉각적인 응답을 경험하게 된다.
더 나은 상태 관리
상태 머신은 속성 테이블의 클라이언트 관점과 속성 테이블의 서버 관점이 동기화되어 있는지 여부와 클라이언트가 서비스 디스커버리를 수행해야할 필요가 있는지 여부를 정의한다.
속성 캐싱(attribute caching)에 대한 수정된 spec.은 이 상태 머신을 공식화하고 이를 사용하기 위한 메커니즘을 소개하는 Robust Caching의 엄격하게 정의된 개념을 소개한다.
클라이언트는 change-aware 상태 또는 change-unaware 상태에 있을 수 있다. Spec.은 적절한 상태로 전환하기 위한 정확한 규칙과 두 가지 상태 각각에서 작동하는 방법을 설명한다.
특히 주목할 점은 클라이언트 속성 테이블 캐시가 서버와 동기화되지 않은 것으로 판단되는 경우 서버가 반환할 수 있는 새로운 ≪Database Out Of Sync≫ATT 에러 응답이다. 서버는 change-unaware state 동안 클라이언트로부터 수신된 ATT command 모두를 무시한다.
이전에 전송된 서비스 변경 지시에 대한 ATT 확인을 수신하는 서버 또는 << Database Out Of Sync >> 오류를 사용하여 클라이언트에 알리고 이후에 클라이언트로부터 다른 ATT PDU 를 수신한 서버를 포함하여 많은 수의 이벤트들은 클라이언트의 상태를 change-aware state로 천이할 수 있다.
클라이언트의 관점에서 볼 때, change-unaware state 로 이동하면 속성 캐시를 유효하지 않은 것으로 간주하여 사용하지 않는다. 클라이언트의 속성 캐시 및 서버의 속성 캐시가 다시 한번 동기화될 때까지 계속 유효하지 않은 것으로 간주된다.
광고 향상(advertising enhancement) 1 : 무작위 광고 채널 인덱싱(randomized advertising channel indexing)
Bluetooth Core Spec. v5.0 에서, 광고 이벤트는 "첫 번째로 사용된 광고 채널 인덱스로 시작하고 마지막으로 사용된 광고 채널 인덱스로 끝나는 프라이머리 광고 채널에서 전송된 하나 이상의 광고 PDU"로 정의된다.
실제로, 이것은 세 채널이 모두 사용 중일 때(종종 이런 상황이 발생함), 광고(advertising)는 엄격한 순서로 순서 37, 38, 39의 채널을 사용하는 것을 의미한다.
두 개 이상의 장치들이 겹치는(overlapping) 시간 구간(period)에서 동일한 채널 상에서 광고하는 지속적인 패킷 충돌 가능성을 줄이기 위해, Bluetooth Core Spec. v5.0 은 연속적인 광고 이벤트들 사이의 시간은 0 ~ 10ms의 임의 지연(random delay)을 포함해야 한다.
도 15 는 광고 채널의 고정된 순서(sequence)를 가진 블루투스 코어 스펙 v5.0 에 따른 광고 채널 사용의 일례를 나타낸다.
향상된 패킷 충돌 방지(Improved Packet Collision Avoidance)
Bluetooth Core Spec.v5.0 에서, 광고 상태의 장치들은 사용된 가장 낮은 채널 인덱스에서 시작하여 가장 높은 채널 인덱스에서 끝나는 엄격하고 변경되지 않는 순서로 더 이상 광고 채널을 선택할 필요가 없다.
무작위로 채널 인덱스들을 선택하는 것이 허용된다. 광고 채널 인덱스들의 랜덤화는 광고 패킷 충돌 발생 가능성을 더욱 감소시킨다.
비 연결형 통신을 수행하기 위해 광고를 사용하는 애플리케이션은 광고 채널 인덱스 선택에 대한 이러한 변경을 구현함으로써 바쁜(busy) 무선 환경에서 향상된 확장성(scalability)과 신뢰성(reliability)의 이점을 누릴 수 있다.
도 16 은 랜덤화된 채널 인덱스 시퀀스를 사용하는 블루투스 코어 스펙 v5.1 에 따른 광고 채널 사용의 일례를 나타낸 도이다.
광고 개선 2 : 주기적 광고 동기화 전송(Periodic Advertising Sync. Transfer)
Bluetooth Core Spec. v5.0 은 광고 이벤트의 결정적 스케줄링을 사용하는 주기적인 광고를 소개하고, 장치가 다른 장치의 광고 스케쥴을 그들의 스캐닝과 동기화하는 데 사용할 수 있는 절차를 제공한다.
스캐닝 및 광고 타이밍의 동기화는 스캐닝 장치의 에너지 효율성을 높이고 데이터 교환에서 정확한 타이밍이 필요한 일부 사용 사례를 가능하게 할 수 있다.
리모트 장치의 주기적인 광고와 동기화를 허용하기 위해, 리모트 장치는 SyncInfo 라는 필드를 포함하는 AUX_ADV_IND PDU 를 광고한다. SyncInfo 는 수신 장치가 해당 시점부터 리모트 장치에 의해 수행되는 AUX_SYNC_IND PDU의 주기적인 광고와 동기화하는 것을 할 필요가 있는 모든 것을 포함한다.
하지만, 이 주기적인 광고 동기화 절차는 상대적으로 비용이 많이 드는 작업 일 수 있다.
제한된 전력을 가진 일부 장치 타입은 주기적인 광고 동기화 절차와 연관된 에너지 비용을 감당할 수 없거나 동작을 방해하는 듀티 사이클(duty cycle) 또는 스캔 시간(scan time)에 제한을 가질 수 있다.
도 17은 주기적인 광고 동기화 전송 사용의 일례를 나타낸 도이다.
새로운 주기적인 광고 동기화 전송(Periodic Advertising Sync Transfer, PAST) 특징은 또 다른 장치 즉, 동기화 절차를 수행하기 위해 비교적 제한이 적은 장치를 허용하고, 이후 다른 장치 즉, 제한된 장치로 포인트-투-포인트 블루투스 저 에너지(point-to-point Bluetooth Low Energy) 연결에 대한 획득된 동기화 세부 정보를 전달한다. 예를 들어, 스마트 폰은 TV 로부터 AUX_SYNC_IND 패킷에 대해 스캔을 하고, 이후 그것들을, 스마트 와치가 TV 로부터 데이터를 획득하기 위해 주기적인 광고 및 스캐닝을 사용하여 이익을 얻을 수 있도록, 연관된 스마트 와치(smart watch)로 연결을 전달한다.
사소한 향상(Minor Enhancements)
Bluetooth Core Spec. v5.1에 몇 가지 사소한 개선 사항이 포함되어 있다.
LE 보안 연결에서 디버그 키에 대한 HCI 지원
LE 보안 연결은 Diffie Hellman 키 계약 프로토콜을 사용하여 페어링 중 공유 보안 키 교환을 보호하는 Bluetooth 페어링 절차이다. Diffie Hellman 은 공개키와 개인키를 갖는 비대칭(asymmetric), 타원 곡선 암호화(elliptic curve cryptography)를 사용한다. 이는 개발 및 테스트 동안 공유키를 가져와서 연결 추적 및 디버깅에 사용하는 것을 불가능하게 한다.
Bluetooth Core Spec. v4.2 에서, 테스트 목적을 위해 하드-코딩된 키 값들이 정의되었다. 그러나, 타원 곡선 알고리즘이 컨트롤러에서 구현된 경우, 호스트가 이것을 사용하기를 원함을 지시하는 방법이 없다. Bluetooth Core Spec.의 최신 버전은 호스트가 컨트롤러에 디버그 키 값을 사용하도록 지시할 수 있는 HCI command 를 추가한다. 호스트가 타원 곡선 알고리즘 자체를 구현하는 사용 사례들은 이 변경에 의해 영향을 받지 않는다.
슬립 클럭(sleep clock) 정확도 업데이트 메커니즘
현재, LE 연결을 설정할 때, 마스터 장치는 슬레이브에게 마스터의 클럭이 얼마나 정확한지를 Sleep Clock Accuracy (SCA) 필드를 사용하여 알려준다. 그러나, 정확한 요구 사항은 controller 에 의해 처리되는 동시 사용 사례에 의존하여 변경될 수 있다.
예를 들어, 더 높은 클럭 정확도 요구 사항이 있는 또 다른 연결이 설정될 때, 하나의 값에서 시작할 수 있지만 한 단계 더 높아져야할 필요가 있다. Bluetooth Core Spec. v5.1 은 새로운 링크 계층 PDU 인 LL_CLOCK_ACCURACY_REQ 를 제공하고, 이는 연결된 슬레이브에 새로운 클럭 정확도 값을 알리는 데 사용할 수 있다. 이 PDU 는 슬레이브가 이것을 그것들의 클럭 정확도의 연결에서 마스터로 알리도록 하기 위해 마스터에 의해 슬레이브로 또는 슬레이브에 의해 마스터로 전송될 수 있다. 이 특징은 경우에 따라 전력 소비를 낮출 수 있다.
AdvDataInfo (ADI) 필드는 확장된 광고 패킷에 사용됩니다. 이전에, 이 필드는 스캔 응답 패킷에 허용되지 않았다. 최신 Bluetooth Core Spec. v5.1 에서, 스캔 응답 패킷에 ADI 를 포함하는 것이 허용하게 되었다.
이 변경은 Bluetooth 기본 레이트 / 향상된 데이터 속도 (BR/EDR)와 관련된 서비스 품질 (QoS) 및 흐름(flow)과 관련된 규칙을 명확히 한 것이다.
세컨더리 광고를 위한 호스트 채널 분류(Host Channel Classification)
HCI 커맨드 LE_Set_Host_Channel_Classification 는 무선 채널들의 분류를 "bad"로 허용한다. 이전에 연결에만 적용되었지만, 이제는 세컨더리 광고 채널에도 적용된다.
광고 세트 ID (SID) 필드는 확장된 광고 패킷에 사용된다. 이전에 이 필드는 스캔 응답 패킷에서 허용되지 않았다. Bluetooth Core Spec. v5.1에서, 스캔 응답 보고에 SID를 포함 할 수 있게 되었다.
'유효하지 않은 행동에 응답'은 잘못 동작하는 Bluetooth 장치를 다룰 때 따를 수 있는 규칙을 명확히 하기 위해 최신 Core Spec. release에 추가되었다.
Wearable ENS(Exposure Notification Service, W-ENS)
노출 알림은, 최근에 접촉한 사람에게 노출될 가능성을 참가자에게 경고함으로써, COVID-19 를 유발하는 병원체 즉, 코로나 바이러스의 확산을 방지할 수 있다. 노출 알림 서비스는 노출 알림을 구현하는 수단이며, Bluetooth Low Energy 무선 기술을 사용하여 근처 스마트폰의 근접 감지 및 데이터 교환 메커니즘을 제공한다. 즉, 노출 알림 서비스(또는 시스템) (ENS)은 개인에게 잠재적인 노출을 감지하고 알려줌으로써 SARS-CoV-2 발생을 늦추고 잠재적으로 억제할 수 있도록 전 세계적으로 배포되고 있다. 이러한 시스템의 대부분은 스마트폰과 같은 호환되는 클라이언트 장치를 소유하고 휴대하는 개인에게 의존한다. 그러나 국가에 따라 전 세계 인구의 상당 부분이 호환되는 클라이언트 장치를 소유하지 않으며, ENS 에 참여할 수 없는 상태이다. 이는 어린이 및 노인과 같은 사회의 특정 그룹에 영향을 미친다. 마찬가지로, 항상 휴대하거나 액세스 할 수 있는 것이 아닌 (예: 교실 세션 또는 팀 스포츠) 호환되는 클라이언트를 가지는 사람들은 해당 시간 동안 참여하지 못할 수도 있다. 이러한 시스템은 인구의 대다수가 액세스 권한을 갖고 사람들이 시스템을 지속적으로 사용하는 경우에만 발병 속도를 늦추는데 중요한 영향을 미친다. 이 내용은 인터넷에 연결되지 않은 웨어러블 장치가 하나 이상의 배포된 클라이언트 기반 ENS 와 보완적인 방식으로 동작할 수 있도록 표준화된 방법을 정의하여 상당한 수의 추가 개인이 ENS 에 참여할 수 있도록 한다. 여기서 정의된 방법은 SARS-CoV-2를 포함한 다양한 감염의 봉쇄에 적용된다.
TDS (Transport Discovery Service)는 Bluetooth LE 무선 기술을 사용하는 장치가 Bluetooth LE 이외의 전송에서 사용할 수 있는 서비스를 노출할 수 있도록 한다. 이 문서에서 사용되는 '전송'이라는 용어는 서버와 클라이언트 간의 데이터 전송에 사용할 수 있는 통신 기술을 나타낸다. 상위 수준 문서 (예 : TDS 를 참조하고 사용하는 문서)와 함께 사용하는 경우, 이 서비스에 의해 제공되는 정보는 BR/EDR 또는 Bluetooth SIG 에서 정의하지 않은 전송의 검색(또는 디스커버리) 및 활용을 용이하게 하는 데 사용될 수 있다. 이 서비스에 대한 적합성이 요구되는 경우, 이 서비스에 대해 필수로 지시된 모든 능력들은 지정된 방법 (프로세스-필수)으로 지원된다. 이는 지원이 지시된 모든 선택적 및 조건부 능력들에 적용된다. 이 서비스는 다른 서비스에 의존하지 않는다.
이 문서는 GATT (Generic Attribute Profile) 및 Bluetooth Core Spec.의 Bluetooth LE controller 부분을 포함하는 어떤 Bluetooth core spec.과도 호환된다.
노출 알림 서비스에서 사용되는 용어에 대해 간략히 정리한다.
- 노출 알림 서비스 - 장치 근접성을 감지하기위한 Bluetooth Low Energy 서비스.
- 임시 노출 키(temporary exposure key) - 개인 정보 보호를 위해 24 시간마다 생성되는 키.
- 진단 키(diagnosis key) - 장치 소유자가 코로나 바이러스 양성으로 진단될 때 업로드되는 임시 노출 키의 하위 집합.
- 롤링 근접 식별자(rolling proximity identifier) - 임시 노출 키에서 파생되고, Bluetooth 페이로드의 브로드 캐스트로 전송되는 개인 정보 보호 식별자. 식별자는 장치의 무선 추적을 방지하기 위해 약 15 분마다 변경된다.
- AEM (Associated Encrypted Metadata) - 더 나은 거리 근사를 위해 프로토콜 버전 관리 및 전송 (Tx) 전력을 전달하는 데 사용되는 암호화된 메타 데이터를 보존하는 프라이버시. 연관된 암호화된 메타 데이터는 디바이스의 무선 추적을 방지하기 위해 약 15 분마다 롤링 근접 식별자와 동일한 케이던스(cadence)로 변경된다.
이하, 블루투스에서 ENS를 위한 광고 및 스캐닝 동작에 대해 간략히 살펴본다.
디바이스들은 16 비트 서비스 UUID(Universally Unique Identifiers)를 통해 노출 알림 서비스를 브로드 캐스트하고 검색한다. 이 서비스 UUID 를 사용하는 서비스 데이터 유형은 롤링 근접 식별자 및 관련 암호화된 메타 데이터를 포함해야 한다. 그리고, 둘 다 주기적으로 변경된다.
광고 페이로드(Advertising Payload)
노출 알림 서비스 페이로드는 도 18과 같이 정렬되어야 하며, 다른 데이터 유형을 포함하지 않는다.
도 18은 본 명세서에서 제안하는 광고 페이로드 포맷의 일례를 나타낸 도이다.
도 18 을 참고하면, 광고 페이로드(1800)는 length, type, flag 를 포함하는 flag 필드(1810), 완전(Complete) 16-bit 서비스 UUID 필드(1820) 및 서비스 데이터-16bit UUID 필드(1830)를 포함한다. 즉, 노출 알림 서비스는 아래 4가지 섹션(또는 필드)들을 포함한다.
1. 플래그 섹션 - Bluetooth LE 일반 검색 가능 모드 (비트 1)는 '1'로 설정된다.
2. 완전한(complete) 16-비트 서비스 UUID 섹션 - UUID 는 0xFD6F 일 수 있으며, 서비스 데이터 섹션 앞에 온다.
3. 서비스 데이터 16-비트 UUID 섹션 - 이 섹션은 페이로드에 두 개의 다른 섹션이 있다.
a. 16 바이트 롤링 근접 식별자(rolling proximity identifier).
b. 다음을 포함하는 4 바이트 관련 암호화 메타 데이터 (LSB 우선):
i) 바이트 0 - 버젼닝(versioning).
- 비트 7:6 - 주 버전 (01).
- 비트 5:4 - 부 버전 (00).
- 비트 3:0 - 향후 사용을 위해 reserved.
ii) 바이트 1 - 전송 전력 레벨.
- 블루투스 광고 패킷의 측정된 방사 전송 전력으로, 거리 근사치를 개선하는데 사용된다. 이 섹션(또는 필드)의 범위는 -127 ~ +127dBm이다.
iii) 바이트 2 - 향후 사용을 위해 reserved.
iv) 바이트 3 - 향후 사용을 위해 reserved.
브로드캐스팅 동작(broadcasting behavior)
- Bluetooth 브로드캐스트 중, 광고는 ADV_NONCONN_IND 타입의 non-connectable undirected이다.
- 광고주 주소 타입은 Random Non-Resolvable이다.
- 랜덤된 순환 시간 초과 간격을 가진 Bluetooth 랜덤 개인 주소를 지원하는 플랫폼에서, 광고주 주소 순환 기간은 10 분 이상 20 분 미만의 랜덤 값이다.
- 광고주 주소, 롤링 근접 식별자 및 관련 암호화된 메타 데이터는 링크될 수 없도록 동기적으로 변경된다.
- 하드웨어가 허용하는 경우, 최적의 간격을 선택할 때 안정성과 유연성을 제공하기 위해 별도의 Bluetooth 방송 인스턴스를 사용해야 한다.
- 방송 간격은 변경될 수 있지만, 현재는 200-270 밀리초(millisecond)로 권장된다.
도 19는 본 명세서에서 제안하는 ENS 관련 브로드캐스팅 플로우의 일례를 나타낸 도이다.
즉, 도 19는 디바이스들 간에 브로드캐스팅 플로우의 일례를 나타낸다.
도 19 를 참고하면, 제 1 엔터티는 제 2 엔터티로 EN 상태 설정 요청 메시지(예: ENStateSetRequest)를 'True'로 설정하여 전송한다. 이후, 상기 제 2 엔터티는 노출 알림을 가능하게 하도록 사용자 허락을 요청한다. 이후, 상기 제 2 엔터티는 임시_노출_키를 생성한다. 이후, 상기 제 2 엔터티는 롤링 근접 식별자(Temporary_Exposure_Key 등)을 도출한다(derive). 이후, 상기 제 2 엔터티는 제 3 엔터티로부터 롤링 근접 식별자, 연관된 암호화된 메타데이터를 수신한다. 이후, 상기 제 2 엔터티는 제 4 엔터티로 블루투스 브로드캐스트(노출 알림 서비스 UUID, 롤링 근접 식별자, 연관된 암호화된 메타데이터)를 전송한다. 이후, 상기 제 4 엔터티는 롤링 근접 식별자, 연관된 암호화된 메타데이터를 저장한다. 그리고, 15 분이 경과 후, 상기 제 2 엔터티는 상기 제 3 엔터티로 롤링 근접 식별자(Temporary_Exposure_Key 등)을 유도한다. 그리고, 상기 제 2 엔터티는 상기 제 3 엔터티로부터 롤링 근접 식별자, 연관된 암호화된 메타데이터를 수신한다. 이후, 상기 제 2 엔터티는 상기 제 4 엔터티로 블루투스 브로드캐스트(노출 알림 서비스 UUID, 롤링 근접 식별자, 연관된 암호화된 메타데이터)를 전송한다. 이후, 상기 제 4 엔터티는 롤링 근접 식별자, 연관된 암호화된 메타데이터를 저장한다. 그리고, 24 시간 경과 후, 상기 제 2 엔터티는 임시_노출_키, 연관된 암호화된 메타데이터를 생성한다.
도 19 에서, 제 1 엔터티는 어플리케이션 로컬일 수 있으며, 제 2 엔터티는 프래임워크/블루투스 로컬일 수 있으며, 제 3 엔터티는 암호화 로컬일 수 있으며, 제 4 엔터티는 프래임워크/블루투스 리모트일 수 있으며, 제 5 엔터티는 암호화 리모트일 수 있다. 다만, 제 1 엔터티 내지 제 5 엔터티의 용어는 일례이며, 본 명세서에서 기재된 내용에 맞춰 변경될 수 있음은 물론이다.
스캐닝 동작(Scanning Behavior)
- 발견된 노출 알림 서비스 광고는 디바이스에 유지되어야 한다.
- 스캔 결과는 브로드 캐스트 별로 타임 스탬프 및 RSSI 캡처된다.
- 스캐닝 간격 및 윈도우는 5 분 이내에 근처의 노출 알림 서비스 광고를 발견할 수 있도록 충분한 범위를 가져야 한다.
- 가장 잘 동작하는 스캐닝 전략은 기회적이며(기존 깨우기 및 검색 윈도우 활용), 5 분마다 최소 주기적 샘플링을 사용한다.
스캔 파워 고려사항들(Scan Power Considerations)
- 노출 알림 서비스를 실행하는 플랫폼은 공공 장소에 있는 많은 방송사를 고려하도록 설계되어야 하며, Random Non-resolvable address 및 Rolling Proximity Identifier를 자주 교체해야 한다.
- 하드웨어 및 운영 체제에서 지원하는 경우, Bluetooth 컨트롤러는 필터를 복제하고, 다른 하드웨어 필터들은 과도한 전력 소모를 방지하기 위해 사용된다.
스캐닝 플로우(Scanning Flow)
도 20은 본 명세서에서 제안하는 ENS 관련 스캐닝 플로우의 일례를 나타낸 도이다.
즉, 도 20은 디바이스 스캐닝 동작의 일례를 나타낸다.
도 20 에서 기술하는 제 1 엔터티, 제 2 엔터티, 제 3 엔터티, 제 4 엔터티 및 제 5 엔터티는 도 19 에서 표현된 엔터티들과 다른 것을 의미하며, 설명의 편의를 위해 동일한 용어를 사용한 것임을 명확히 한다.
도 20 을 참고하면, 제 1 엔터티는 제 2 엔터티로부터 'True'로 설정된 EN 상태 설정 요청 메시지(ENStateSetRequest)를 수신한다. 이후, 상기 제 1 엔터티는 노출 알림을 가능하게 하도록 사용자 허락을 요청한다. 이후, 상기 제 1 엔터티는 임시 노출 서비스 UUID 를 스캔한다. 이후, 상기 제 1 엔터티는 제 3 엔터티로부터 블루투스 브로드캐스트(노출 알림 서비스 UUID, 롤링 근접 식별자, 연관된 암호화된 메타데이터)를 수신한다. 이후, 상기 제 1 엔터티는 롤링 근접 식별자 및 연관된 암호화된 메타데이터를 저장한다. 이후, 상기 제 1 엔터티는 상기 제 3 엔터티로부터 블루투스 브로드캐스트(노출 알림 서비스 UUID, 롤링 근접 식별자, 연관된 암호화된 메타데이터)를 수신한다. 이후, 상기 제 1 엔터티는 롤링 근접 식별자 및 연관된 암호화된 메타데이터를 저장한다. 그리고, 상기 제 2 엔터티는 Periodic Diagnosis_Key Fetch 를 수행한다. 이후, 상기 제 2 엔터티는 제 4 엔터티로부터 Diagnosis_Keys 를 수신한다. 이후, 상기 제 1 엔터티는 상기 제 2 엔터티로부터 ENExposureDetectionSession(List of Diagnosis_Keys)를 수신한다. 이후, 상기 제 1 엔터티는 모든 롤링 근접 식별자들에 대한 Diagnosis_Key 들을 해결한다. 이후, 상기 제 1 엔터티는 제 5 엔터티로 Resolve(RPI, Diagnosis_Key)를 전송한다. 이후, 상기 제 1 엔터티는 상기 제 5 엔터티로부터 Match/No-Match 를 수신한다. 이후, 상기 제 1 엔터티는 노출 기간에 기초하여 위험을 평가할 알고리즘을 수행한다. 이후, 상기 제 1 엔터티는 상기 제 2 엔터티로 ENExposureDetectionSummary(matches 의 수, contact 의 가장 최근일)을 전송한다. 이후, 상기 제 1 엔터티는 상기 제 2 엔터티로부터 ENExposureDetectionSession (get info)를 수신한다. 이후, 상기 제 1 엔터티는 사용자에게 노출 위함에 대해 통지할 수 있다. 이후, 상기 제 1 엔터티는 ENExposureinfo(Day, duration, attenuation)을 상기 제 2 엔터티로 전송한다. 이후, 상기 제 2 엔터티는 확진 진단을 근접하게 할 수 있다.
도 20 에서, 제 1 엔터티는 프래임워크/블루투스 리모트일 수 있으며, 제 2 엔터티는 어플리케이션 리모트일 수 있으며, 제 3 엔터티는 프래임워크/블루투스 로컬일 수 있으며, 제 4 엔터티는 클라우드 (서버)일 수 있으며, 제 5 엔터티는 암호화 리모트일 수 있으며, 제 6 엔터티는 암호화 로컬일 수 있다. 다만, 제 1 엔터티 내지 제 6 엔터티의 용어는 일례이며, 본 명세서에서 기재된 내용에 맞춰 변경될 수 있음은 물론이다.
프라이버시(Privacy)
사용자 프라이버시를 유지하는 것은 ENS Spec.에서 필수적인 요구 사항이며, 프로토콜은 다음과 같은 방법으로 프라이버시를 유지한다.
- 노출 알림 Bluetooth spec.은 근접 감지에 위치를 사용하지 않는다. 즉, 블루투스 beaconing 을 엄격하게 사용하여 근접성을 감지한다.
- 사용자의 롤링 근접 식별자는 평균 15 분마다 변경되며, contact 와 상호 연결되도록 임시 노출 키가 필요하다. 이 동작은 식별자들을 브로드 캐스트 하는 것으로부터 프라이버시 loss의 위험을 줄인다.
- 다른 장치에서 얻은 근접 식별자는 장치에서만 처리된다.
- 사용자는 노출 알림에 기여할지 여부를 결정한다.
- COVID-19 로 진단된 경우, 사용자는 사용자의 동의를 서버와 진단 키를 공유하기 위해 제공해야 한다.
- 사용자는 노출 알림 참여에 대한 투명성(transparency)을 갖는다.
앞서 설명에 이어, 요구 사항들은 GATT 서버에 대한 최소 요구 사항 세트를 나타낸다. 클라이언트와 서버가 모두 지원되는 경우, 다른 GATT 서브-절차들은 사용될 수 있다. 표 4 는 모든 GATT 서버에 의해 요구되는 것 외에 필요한 추가적인 GATT 서브-절차 요구사항을 나타낸다.
표 4에서, C.1은 임시 키 리스트 특성이 노출되면 필수이고, 그렇지 않으면 선택이다.
이 서비스는 Bluetooth LE 전송을 통해서만 동작한다. 이 서비스는 CSS (Core Specification Supplement)에 아직 정의되지 않은 다음 속성 프로토콜 애플리케이션 오류 코드를 정의하지 않는다.
이 서비스에 사용되는 모든 특성들은 LSO (least significant octet first) (즉, little endian)로 전송된다. LSO 의 식별은 GATT Spec. Supplement (GSS) 또는 이 문서의 다른 곳에 지정되어 있다. 이 문서의 표에 형식이 설명되어 있는 경우, LSO 는 표의 맨 위 필드에 있는 첫 번째 옥텟이고, MSO 는 테이블의 맨 아래 필드에 있는 마지막 옥텟이다.
서버는 GAP 주변장치(peripheral) 또는 GAP 브로드캐스터가 된다. 서버가 GAP 주변장치인 경우, 다음 요구 사항이 적용된다.
- 이 서비스는 ≪Primary Service≫로 인스턴스화(instantiate)된다.
- 이 서비스의 한 인스턴스만 장치에 노출된다.
- 서비스 UUID (Universally Unique Identifier)는 ≪Wearable Exposure Notification Service≫로 설정된다.
광고 패킷은 Bluetooth Core Spec.에 의해 허용되는 것처럼 공간 사용 가능 기준에 따라 다수의 AD 타입들을 포함할 수 있다. W-ENS 서비스 데이터는 서버가 연결 가능하거나 신뢰할 수 있는 클라이언트와 관계를 설정하고 새로운 데이터를 사용할 수 있을 때 광고된다. W-ENS 서비스 데이터는 Service Data-16 비트 UUID AD 타입을 사용하며, 포맷은 표 5에 설명된다.
UUID 는 블루투스에서 디바이스에서 제공하는 각 서비스를 구분하는 unique 한 ID 를 의미한다.
광고 패킷에 추가적인 AD 타입이 있는지에 따라 최대 13 개의 UUID(Universally Unique Identifiers)가 표준 광고 패킷에 리스트될 수 있다. 그러나 Bluetooth Core Spec. v5.0 및 그 이상에서 확장된 광고 특징을 사용함으로써 추가적인 값들이 지원될 수 있다. 길이 필드는 W-ENS 서비스 데이터에 포함된다. 이 필드는 길이 필드의 길이를 포함하지 않는 W-ENS 서비스 데이터의 1 옥텟 길이를 포함한다. 예를 들어, W-ENS 서비스 데이터가 단일 ENS 서비스 UUID 만 포함한 경우, 길이 값 (따라서 가능한 최소 길이 값)은 0x06 이다. 서비스 데이터-16 비트 UUID AD 타입 코드 필드는 W-ENS 서비스 데이터에 포함된다. 이 필드는 GAP (Generic Access Profile)에 정의된 1 옥텟 값을 포함한다. 16-비트 서비스 UUID 필드는 W-ENS 서비스 데이터에 포함된다. 이 필드는 2 옥텟 W-ENS 서비스 UUID 값을 포함한다. ENS 플래그 필드는 W-ENS 서비스 데이터에 포함된다. 이 필드는 장치가 연결 가능한지를 나타내는 1 옥텟 값과 다른 특징을 포함한다. 이 필드의 값은 표 6에 정의되어 있다. 표 6은 ENS 플래그 필드의 일례를 나타낸다.
AD 비트에서 전체 UUID 리스트는 지원되는 ENS 서비스 UUID 필드가 UUID 의 전체 또는 불완전 리스트를 포함하는지 여부를 나타낸다. 리스트가 불완전하면, AD 비트는 0 으로 설정되고, 그렇지 않으면 1 로 설정된다. 리스트가 불완전한 경우, 전체 UUID 리스트는 GATT 데이터베이스에서 찾을 수 있다. 이는 전체 콘텐츠에 대해 광고 패킷에서 불충분한 공간이 있을 때 사용될 수 있다.
신뢰할 수 있는 연결 비트는 서버가 클라이언트와 신뢰할 수 있는 연결을 형성하는 능력을 지원하는지 여부와, 지원하는 경우 현재 상태를 지시한다. 비트가 '0b00'으로 설정되면, 서버는 클라이언트와 신뢰할 수 있는 연결을 형성하는 능력을 지원하지 않는다. 비트가 '0b01'로 설정되면, 서버는 클라이언트와 신뢰할 수 있는 연결을 형성하는 능력을 지원하며, 현재 연결을 수락할 수 있는 상태에 있다. 비트가 '0b10'으로 설정되면, 서버는 신뢰할 수 있는 연결을 형성하고 신뢰할 수 있는 클라이언트에 대해 사용할 수 있는 새로운 데이터를 가진다. 비트가 '0b11'로 설정되면, 서버는 신뢰할 수 있는 연결을 형성했지만, 신뢰할 수 있는 클라이언트에 대한 마지막 연결 이후로 사용할 수 있는 새로운 데이터가 없다.
지원되는 ENS 서비스 UUID 필드는 W-ENS 서비스 데이터에 포함된다. 이 필드는 지원되는 노출 알림 시스템을 나타내는 16 비트 UUID 리스트를 포함한다. 이 리스트는 적어도 하나의 16-비트 UUID 를 포함한다. 예를 들어, Apple 및 Google 노출 알림 시스템은 16 비트 UUID 0xFD6F 를 특정한다. 아래 표 5 는 W-ENS 서비스 데이터가 광고될 수 있는 때를 보여준다. ENS 플래그 필드들의 비트들은 데이터의 컨텍스트를 지시하기 위해 사용된다. 표 7은 W-ENS 서비스 데이터에 대한 광고 동작의 일례를 나타낸다.
서버가 최대 연결(bond) 수에 도달하고 클라이언트가 연결(bonding)을 시도하는 경우, Security Manager 페어링 실패 메시지는 에러 코드 Pairing Not Supported 를 반환한다. 새로운 클라이언트와의 본딩(bonding)이 모든 과거 레코드들 및 임시 키를 삭제할지 또는 새로운 클라이언트가 모든 과거 레코드 및 임시적인 키에 액세스할 수 있는지 여부에 대해서는 구현 선택 사항이다.
각각의 노출 알림 서비스에 특정한 광고 데이터의 포맷은 각각의 노출 알림 서비스에 의해 특정되며, 표준의 범위를 벗어난다. 이는 서버가 클라이언트에 의해 설정되고, ENS-특정 광고 데이터를 광고하는 모드에 있을 때 광고된다.
일단 신뢰할 수 있는 클라이언트에 bond 되거나 또는 연결되면, ENS 는 선택된 ENS 디스크립터를 사용하여 선택되고, 어떤 설정들이 설정되고, 선택된 ENS 가 시작된다. 서버는 ENS 에 의해 정의된 광고 패킷 포맷과 인터벌을 사용하여 광고하고, ENS 에 의해 정의된 스캔 인터벌 및 스캔 윈도우를 사용하여 동일한 ENS 타입의 광고 패킷을 스캔한다. 특정 광고 및 스캔 파라미터들이 ENS 에 의해 서버에 대해 정의되지 않은 경우, 클라이언트에 대해 ENS 에서 특정된 동일한 값이 사용되어야 한다.
ENS 시스템은 다양하지만 일반적으로 다음과 유사한 프로토콜을 따른다.
- 서버는 대략 하루에 한 번 회전하는 임시 키에서 한 시간에 여러 번 변경되는 RPI (Rolling Proximity Identifier)를 생성한다.
- 서버는 ENS에서 특정된 형식과 간격으로 RPI 및 다른 데이터를 광고한다.
- 서버는 ENS 에서 특정된 스캔 간격 및 스캔 윈도우를 사용하여 시간, RSSI (Received Signal Strength Indication) 및 다른 데이터와 함께 수신된 RPI 를 기록한다.
예를 들어, Apple/Google ENS 가 선택되고 시작되면, 서버는 Apple/Google 문서에서 특정된 파라미터에 따라 광고하고 스캔한다.
다수의 ENS 들을 지원하는 서버에 대해, 광고하는 동안, 서버는 RPI 를 광고하고 스캔하는 동안 선택된 ENS 를 저장하고, 서버는 수신된 RPI 들을 로깅하는 동안 선택된 ENS 를 저장한다.
이하, W-ENS 서비스에서 사용되는 GATT 특성들 및 디스크립터(descriptor)와 관련된 요구 사항을 정의한다. 달리 명시되지 않는 한 표 8의 각 특성에 대한 인스턴스는 이 서비스 내에서 하나만 허용된다.
특성(characteristic)이 지시되거나 통지될 수 있는 경우, 클라이언트 특성 설정 디스크립터는 Core Spec.에서 요구되는 대로 해당 특성에 포함되어야 한다. 이 서비스에 대한 특성 요구 사항은 표 8 에 기술된다.
표 8 에서, C.1 은 하나 이상의 노출 알림 시스템이 지원되는 경우 필수이며, 그렇지 않은 경우는 제외된다. 필수 또는 선택 사항으로 리스트되지 않은 속성은 이 버전의 서비스에서 제외된다.
ENS 레코드
ENS 레코드 1 특성은 노출 알림 데이터 레코드를 함께 형성하는 두 부분들 중 첫 번째 부분을 전송하는 데 사용되는 가변 길이 구조이다. 선택적 필드의 존재 여부는 플래그 필드의 내용에 따라 다르다. 이 특성의 구조는 표 9에 정의되어 있다.
Flags 필드의 비트는 표 10에 정의되어 있다.
시퀀스 번호 필드의 구조는 표 11에 정의되어 있다.
RSSI 필드의 구조는 표 12에 정의되어 있다.
Time Offset 필드의 구조 (Time Stamp 와의 시간 차이를 지정)는 표 13에 정의되어 있다.
ENS 레코드 2 특성은 노출 알림 레코드의 두 번째 부분을 전송하는 데 사용되는 가변 길이 구조이다. 선택적 필드의 존재는 플래그 필드의 콘텐츠에 의존한다. 이 특성의 구조는 표 14에 정의되어 있다.
Flags 필드의 비트는 표 15에 정의되어 있다.
ENS 특징 특성은 노출 알림 능력과 관련된 지원되는 특징에 대한 정보를 포함한다. 이 특성의 구조는 표 16에 정의되어 있다.
ENS 특징 필드의 비트는 표 17에 정의되어 있다.
지원되는 노출 알림 시스템 특성은 서버가 지원하는 노출 알림 시스템을 나타낸다. 이 특성의 구조는 표 18에 정의되어 있다.
이 디스크립터의 구조는 표 18에 정의된 지원되는 노출 알림 시스템 특성과 동일한 형식을 따른다.
이 버전의 서비스는 한 번에 하나의 노출 알림 시스템만 사용할 수 있도록 허용하므로, 한 번에 하나의 비트만 설정될 수 있다. 클라이언트는 사용할 지원되는 시스템을 선택할 책임이 있으며, 서버가 로밍함에 따라 클라이언트는 사용중인 알림 시스템을 변경할 수 있다. ENS 설정 특성은 현재 선택된 노출 알림 시스템에 특정한 장치 설정을 나타낸다. 이 특성의 구조는 표 19에 정의되어 있다.
ENS 클럭 특성은 장치의 현재 시간을 초 단위로 나타낸다. 클럭 값이 설정된 경우, 이는 초 단위의 절대 시간을 나타낸다. 클럭 값이 설정되지 않은 경우, 이는 상대 시간(초)를 나타낸다. 이 특성의 구조는 표 20에 정의되어 있다.
동작
설정되지 않은 클럭은 0x0000 부터 증가한다. 설정될 수 없는 클럭은 상대 시간을 사용한다. 이런 클릭에 대해, 클라이언트는 카운터로 시간 참조를 설정하기 위해 값을 읽는다. 이러한 클럭의 경우, 클라이언트는 클럭을 현지 시간에 매핑 할 수 있도록 클럭의 현재 값을 읽는다. 설정될 수 있는 클럭은 절대 시간(한 번 설정)을 사용하고, Epoch 에 대한 포맷 (예 : 12:00 AM, 2020 년 1 월 1 일 UTC)을 따른다. 이러한 클럭의 경우, 클라이언트는 클럭의 현재 값을 읽고, 장치 시간 서비스를 사용하여 현재 시간으로 업데이트한다. 리셋(또는 재설정) 또는 전력 손실 시, 클럭은 0x0000 값으로 재설정된다. 이 디스크립터의 구조는 표 21에 정의되어 있다.
이 디스크립터의 구조는 표 22에 정의되어 있다.
임시 키 리스트 특성은 RPI 를 생성하기 위해 서버에서 사용되도록 클라이언트에 의해 제공되는 32 비트 임시 키 리스트를 나타낸다. 이 특성의 구조는 표 23에 정의되어 있다.
레코드 액세스 제어 포인트(record access control point)는 이 서비스와 함께 사용된다.
이 서비스가 동작하려면, 이 서비스를 사용하는 프로파일 또는 다른 어플리케이션이 클라이언트가 지시에 대해 레코드 액세스 제어 포인트 (RACP) 특성을 설정하는 확인해야 한다 (즉, 클라이언트 특성 설정 디스크립터를 통해). 클라이언트는 서버에서 원하는 절차를 실행하기 위해 레코드 액세스 제어 포인트에 쓰기를 수행해야 한다.
레코드 정의
이 서비스의 컨텍스트 내에, 레코드 (ENS 레코드라고도 함)는 ENS 레코드 1 특성으로 구성되며, 대응하는 ENS 레코드 2 특성이 뒤따를 수도 있고 뒤따르지 않을 수도 있다. ENS 레코드 1 특성 뒤에 ENS 레코드 2 특성이 오는 경우, ENS 레코드 1 특성의 플래그 필드에서 세그먼트된 레코드 비트는 '1'로 설정되고, 두 특성 사이의 시퀀스 번호 필드 값은 동일해야 한다. 서버를 구현하는 장치는 승인된 클라이언트에 의해 검색할 수 있도록 ENS 레코드 데이터를 지속적으로 저장해야 한다.
RACP 절차 요구 사항
표 24 및 표 25 는 이 서비스의 컨텍스트에서 RACP (Record Access Control Point) 절차 (Op 코드, 연산자(operator) 및 피연산자(operand))에 대한 요구 사항을 보여준다.
표 24 에서, C.1 이 연산자가 지원되는 경우, 이 피연산자는 이 연산자에 필수이다. 하나의 Op 코드 및 연산자 조합에 대해 지정된 피연산자를 지원한다고 해서 다른 Op 코드 및 연산자 조합에 대해 해당 피연산자가 지원되는 것은 아니다. 하나의 Op 코드에 대해 주어진 연산자에 대한 지원은 다른 Op 코드에 대한 해당 연산자의 지원을 의미하지는 않는다. 필터 타입 및 필터 파라미터가 사용되는 경우, 피연산자의 바이트 순서는 특정된다. 표 25는 RACP 절차 요구 사항-응답의 일례를 나타낸 표이다.
표 26은 RACP 연산자와 피연산자 간의 관계를 보여준다.
'범위 내'연산자를 사용하는 경우, 해당 범위의 최소값은 피연산자에 사용된 필터 타입에 관계없이 범위의 최대 값보다 작거나 같아야 한다.
다음 표는 표 22 에 나열된 세 가지 연산자 (즉, 작거나 같음, 크거나 같음 및 범위 내)에 적용되는 지원되는 필터 타입을 나타낸다. 피연산자 내에서 필터 타입은 필터링의 기반이 되는 ENS 레코드 1 특성의 필드를 지정한다. ENS 데이터 레코드의 사용자 지정 필터링을 활성화하는 RACP 피연산자는 표 27 에 나타나 있다.
RACP 동작 설명
레코드 액세스 제어 포인트는 ENS 데이터의 알림을 제어하는데 사용된다. 절차는 동작을 특정하는 동작 코드 (표 24 및 표 25 참조)와 해당 동작 코드의 컨텍스트 내에서 유효한 연산자(operator) 및 피연산자(operand) (표 26 참조)를 포함하는 이 특성에 쓰기(write)에 의해 트리거된다. 다중-결합(bond)의 경우, 레코드 액세스 제어 포인트의 처리는 모든 결합에서 일관되어야 한다. 즉, 모든 클라이언트에 의해 공유되는 단일의 데이터베이스가 있다.
Operand 의 값은 서비스 별로 정의되기 때문에, RACP 가 이 서비스와 함께 사용될 때, 필터 타입 필드는 다른 기준 (예: Sequence Number 또는 User Facing Time)에 기초하여 유연하게 필터링하는 것을 가능하도록 정의된다.
일부 절차 연산자 (즉, 작거나 같음, 크거나 같음 및 범위 내)는 피연산자의 일부로 필터 타입이 필요하다. 이는 필터링을 수행하는데 사용되는 ENS 레코드 1 특성에서 필드를 특정하기 위해 사용된다.
사용되는 경우, 필터 타입 필드는 항상 피연산자 내에서 적용 가능한 필터 파라미터에 선행한다(precede). 예를 들어, '범위 내' 연산자와 함께 사용되는 경우, 피연산자는 필터 타입이 피연산자의 최하위 옥텟인 <필터 유형> <최소> <최대> 형식을 갖는다. 유효한 필터 타입 값 목록은 표 27 을 참조하기로 한다.
시퀀스 번호 필터 타입을 사용할 때, 피연산자의 포맷은 적용 가능한 시퀀스 번호 값 또는 연산자에 의존하는 값 쌍 뒤의 시퀀스 번호 필터 타입 값이다.
User Facing Time Filter Type 을 사용할 때, 피연산자의 포맷은 적용 가능한 User Facing Time(기준 시간 및 시간 오프셋의 합) 또는 연산자에 의존하는 값 쌍 뒤의 User Facing Time Filter Type 값이다.
저장된 레코드 절차의 보고 수(report number of stored records procedure)
저장된 레코드 동작 코드의 보고 수가 레코드 액세스 제어 포인트에 기록되면, 서버는 필터 기준(filter criteria), 연산자 및 피연산자 값에 기초하여 UINT 16 포맷에서 레코드 수를 계산하고 응답한다. 특정 연산자와 함께 사용할 때 피연산자 요구 사항에 대한 표는 참조되고, 어떤 경우에는 피연산자가 사용되지 않는다. 응답에 보고된 레코드 수는 데이터베이스의 현재 상태에 기초하여 계산되며, 연결 간에 또는 레코드가 지워진 후에 변경될 수 있다. 응답은 저장된 레코드 수 응답 동작 코드의 수를 사용하여 지시된다. 만약 연산 결과 오류 조건이 발생하면, 이는 오류 조건에 대한 피연사자에서 응답 코드 동작 코드와 적절한 응답 코드 값을 사용하여 지시된다.
서버가 요청의 필터 기준과 일치하는 레코드를 찾지 못하면, 서버는 저장된 레코드 응답 동작 코드의 수와 0x0000 으로 설정된 피연산자와 함께 레코드 액세스 제어 포인트를 지시해야 한다.
만약 연산 결과 오류 조건이 발생하면, 이는 오류 조건에 대한 피연산자(operand)에서 응답 코드 동작 코드와 적절한 응답 코드 값을 사용하여 지시된다.
저장된 레코드 삭제 절차
저장된 레코드 삭제 동작 코드가 레코드 액세스 제어 포인트에 기록되면, 서버는 연산자 및 피연산자 값을 기반으로 특정된 ENS 레코드를 삭제할 수 있다. 레코드 삭제는 ENS 레코드 데이터베이스에서 레코드를 영구적으로 삭제하는 것으로 간주된다. 특정 연산자와 함께 사용할 때 피연산자 요구 사항은 표를 참조하고, 어떤 경우에는 피연산자가 사용되지 않는다. 데이터의 민감도로 인해, 서버가 특정 클라이언트에 의해서만 데이터를 삭제하도록 허용하는 것이 인정된다.
서버는 레코드가 ENS 레코드 데이터베이스에서 성공적으로 삭제된 경우 성공의 응답 코드 값과 함께 이 특성을 지시해야 한다.
서버가 요청의 필터 기준과 일치하는 레코드를 찾지 못하는 경우, 서버는 No Records Found 로 설정된 피연산자에서 응답 코드 동작 코드 및 응답 코드 값을 가진 레코드 액세스 제어 포인트를 지시한다.
연산 결과 오류 조건이 발생하면, 이는 오류 조건에 대한 피연산자에서 응답 코드 동작 코드와 적절한 응답 코드 값을 사용하여 지시될 것이다.
저장된 레코드 보고 절차
레포트 저장된 레코드 동작 코드가 레코드 액세스 제어 포인트에 기록되면, 서버는 연산자 및 피연산자에 특정된 필터 기준을 기반으로 선택된 저장된 ENS 레코드 집합을 알려야 한다. 특정 연산자와 함께 사용될 때, 피연산자 요구 사항에 대해 표를 참조하고, 어떤 경우에는 피연산자가 사용되지 않는다. 레코드 전송의 의미는 레코드의 '이동(move)'이 아니라 레코드의 '복사(copy)'이다.
ENS 레코드의 전송은 ENS 레코드 1 특성에 대한 알림을 포함하며, ENS 레코드 1 특성의 세그먼트된 레코드 비트 값에 따라, ENS 레코드 2 특성을 포함할 수 있다. 세그먼트된 레코드를 알릴 때, ENS 레코드 1 특성에 대한 알림은 ENS 레코드 2 특성에 대한 알림에 이어져야 한다.
시간 오프셋 필드는 처음 전송된 ENS 레코드 1 특성에 포함되어야 하며, 시간 오프셋 필드에 값이 변경될 때마다 후속 레코드에도 포함되어야 한다. 그렇지 않으면 시간 오프셋 필드는 선택 사항이다.
레코드 전송 중에 새로운 ENS 레코드가 이용 가능한 경우(즉, 레포트 저장된 레코드 절차가 시작된 후), 서버는 레코드 전송에 이 새로운 레코드를 포함할 수 있다. 이 서비스를 사용하는 프로파일은 고객이 예상했던 것보다 하나의 추가 레코드가 수신될 가능성을 허용하는 데 필요하다.
주어진 요청에 대한 모든 데이터 레코드가 서버에 의해 통지되면, 서버는 Success 로 설정된 피연산자에서 응답 코드 동작 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 표시한다.
서버가 요청의 필터 기준과 일치하는 레코드를 찾지 못하는 경우, 서버는 No Records Found 로 설정된 피연산자에서 응답 코드 동작 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시한다.
연산 결과 오류 조건이 발생하면, 이는 오류 조건에 대한 피연산자에서 응답 코드 동작 코드와 적절한 응답 코드 값을 사용하여 지시된다.
서버가 어떤 이유로 든 완료 전에 데이터 전송을 중단해야 하는 경우, 서버는 Procedure not completed로 설정된 피연산자에서 응답 코드 동작 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시한다.
중단(Abort) 동작 절차
중단 동작 Op 코드가 레코드 액세스 제어 포인트에 기록되면, 서버는 현재 진행중인 RACP 절차를 중지하고 추가 데이터 전송을 중지하기 위해 최선을 다해야 한다.
모든 RACP 절차가 중지되면, 서버는 Success 로 설정된 피연산자에서 응답 코드 동작 코드 및 응답 코드 값을 사용하여 레코드 액세스 제어 포인트를 지시해야 한다.
연산 결과 오류 조건이 발생하면, 이는 오류 조건에 대한 피연산자에서 응답 코드 동작 코드와 적절한 응답 코드 값을 사용하여 지시된다.
일반 오류 처리 절차
특정 동작 코드로 특정되는 오류 처리 절차 외에 다음이 적용된다.
레코드 액세스 제어 포인트 특성에 기록된 동작 코드(Op 코드)가 서버에서 지원되지 않는 경우, 서버는 'Op Code Not Supported'로 설정된 피연산자에서 응답 코드 Op 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시해야 한다.
레코드 액세스 제어 포인트 특성에 기록된 연산자가 유효하지 않은 경우, 서버는 'Invalid Operator'로 설정된 피연산자에서 응답 코드 op 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시해야 한다.
레코드 액세스 제어 지점 특성에 기록된 연산자가 서버에서 지원되지 않는 경우, 서버는 'Operator Not Supported'로 설정된 피연산자에서 응답 코드 op 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시해야 한다.
레코드 액세스 제어 포인트 특성에 기록된 피연산자가 유효하지 않은 경우, 서버는 'Invalid Operator'로 설정된 피연산자에서 응답 코드 op 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시해야 한다.
레코드 액세스 제어 포인트 특성에 기록된 피연산자 내 필터 타입이 서버에서 지원되지 않는 경우, 서버는 'Operand Not Supported'로 설정된 피연산자에서 응답 코드 op 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시해야 한다.
서버가 여기에 명시되지 않은 어떤 이유로 든 절차를 완료할 수 없는 경우, 서버는 'Procedure not completed'로 설정된 피연산자에서 응답 코드 op 코드 및 응답 코드 값과 함께 레코드 액세스 제어 포인트를 지시해야 한다.
서버가 이전에 트리거 된 RACP 동작을 수행하는 동안 (즉, 유효하지 않은 클라이언트 동작으로 인해) 중단 동작 이외의 op 코드를 가지는 요청이 레코드 액세스 제어 포인트에 기록되면, 서버는 'Procedure Already In Progress'로 설정된 속성 프로토콜 어플리케이션 오류 코드로 설정된 에러 응답을 반환한다.
레코드 액세스 제어 포인트 특성에 기록된 Op 코드가 레코드 알림을 요청하고 클라이언트 특성 설정 디스크립터가 알림에 대해 설정되지 않은 경우, 서버는 'Client Characteristic Configuration Descriptor Improperly Configured'로 설정된 속성 프로토콜 어플리케이션 오류 코드(Attribute Protocol Application error code)를 가진 에러 응답을 반환한다.
타임 아웃 절차
레코드 액세스 제어 포인트 특성의 컨텍스트에서, RACP 특성에 대한 쓰기가 성공적으로 완료되면 타임아웃 절차가 시작된다. 해당 절차가 완료되면, 서버는 'Response Code'로 설정된 Op 코드와 함께 RACP 특성을 지시한다.
RACP 절차는 RACP 특성 지시에 뒤따르는 다수의 특성 통지를 포함할 수 있다. 서버가 RACP 특성의 지시를 전송할 때 30 초로 정의된 ATT 트랜잭션 타임아웃(timeout) 내에 승인이 수신되지 않으면, 응답은 타임아웃된 것으로 간주된다. 타임아웃이 발생하면, 서버는 동작과 관련된 추가적인 지시 및 알림 전송을 중지하고, 절차가 실패한 것으로 간주한다.
서버는 노출 또는 위험 계산을 수행하지 않고, 클라이언트가 처리할 수 있도록 요청된 데이터 레코드를 클라이언트에 전송한다. 서버는 ENS 에 의해 허용되는 경우 중복 정보의 저장 또는 전송을 최소화하기 위해 데이터 전처리(pre-processing)를 수행할 수 있다. 데이터 전송 속도를 높이기 위해, 서버는 TBD(to be determined) 바이트의 최소 ATT_MTU 를 사용하여 데이터를 전송한다. 서버는 클라이언트에 의해 지원되는 경우, Core Spec. (v4.2 이상)의 2Mbps PHY 특징을 사용할 수도 있다. 서버는 또한 클라이언트에 의해 지원되는 경우, Core Spec. (v? 이상)의 데이터 길이 확장 특징을 사용할 수 있다. 추가적인 구현-특징 정보는 RPI가 광고될 당시의 온도 또는 펄스 데이터와 같은 데이터 레코드에 포함될 수 있다.
서버는 선택된 노출 알림 시스템에 참여하는 데 필요한 최소한의 정보를 전송해야 한다. 서버는 서버가 위의 내용에서 정의된 정보를 외부로 전송하는 추가 정보를 제공할 때 주의해야 한다. 서버는 ENS 의 데이터 유지(retention) 정책에 따라 데이터를 삭제해야 한다.
이하, ENS 어플리케이션에 유용할 수 있는 추가 GATT 서비스와 관련된 요구 사항을 정의한다.
배터리 서비스는 서버 상에서 클라이언트가 배터리 상태를 확인하는 것을 가능하게 하도록 사용되어야 한다.
서버가 설정될 시간 기반에 대한 능력을 지원하는 경우, 장치 시간 서비스는 클라이언트가 서버와 동기화하는 것을 가능하게 하도록 사용되어야 한다.
장치 정보 서비스는 클라이언트가 서버 상에서 제품 제조업체, 모델 번호, 일련 번호, 하드웨어 및 펌웨어의 개정 정보를 포함하는 공통 장치 데이터를 확인하는 것을 가능하도록 사용되어야 한다.
연결 관리 서비스(Bond Management Service)는 클라이언트가 사용자 인터페이스가 없는 서버 상에서 연결을 삭제하는 것을 가능하도록 사용되어야 한다.
이하, 앞서 살핀 내용을 토대로 ENS 와 관련된 Client(들) 동작, Server 동작, Client-Server 간의 동작에 대해 관련 도면을 참고하여 살펴보기로 한다. 후술할 내용들에 앞서 언급한 내용, 표 등이 적용될 수 있음은 물론이다. 도 21 내지 도 28 에서 점선으로 표시된 단계는 각 도면의 절차에서 포함될 수도 있거나 포함되지 않을 수도 있다.
도 21은 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 21 을 참고하면, 서버는 연결 가능한 W-ENS 비콘에 대해 광고한다(S2101). 그리고, 서버는 클라이언트 1(trusted client)로 호환 가능한 ENS_1 client 와 연결을 전송한다(S2102). 그리고, 상기 클라이언트 1 은 ENS_1 시작을 서버로 전송한다(S2103). 그리고, 상기 서버는 ENS_1-특정 비콘에 대해 광고 및 스캐닝한다(S2104). 그리고, 상기 서버는 RPI 들의 ENS_1-특정 로깅을 수행한다(S2105). 그리고, 상기 서버는 (낮은 듀티 사이클에서) 연결 가능한 W-ENS 비콘들에 대해 광고한다(S2106). 그리고, 상기 서버는 이용 가능한 한 새로운 ENS_1 데이터 레코드를 클라이언트 1 로 연결 및 업로드한다(S2107). 클라이언트 2(new client)는 새로운 디바이스를 자신의 프로파일에 추가한다(S2108). 그리고, 상기 클라이언트 2 는 상기 서버로 제 1 페어링 요청을 전송한다(S2109). 그리고, 상기 서버는 쉐이킹/버튼을 누름으로써 페어링을 확인한다(S2110). 그리고, 상기 서버는 상기 클라이언트 2 로 호환 가능한 ENS_2 client 를 연결한다(S2111). 그리고, 상기 서버는 상기 클라이언트 2 로 서버 특징들을 리드한다(S2112). 그리고, 상기 서버는 ENS_2 setting 을 설정한다(S2113). 그리고, 상기 클라이언트 2 는 상기 서버로 ENS_2 시작을 전송한다(S2114). 그리고, 상기 서버는 ENS_1 & ENS_2 특정 비콘에 대해 광고 및 스캐닝한다(S2115). 그리고, 상기 서버는 RPI 들의 ENS_1 & ENS_2 특정 로깅을 수행한다(S2116). 그리고, 상기 서버는 (낮은 듀티 사이클에서) 연결 가능한 W-ENS 비콘들에 대해 광고한다(S2117). 그리고, 상기 서버는 클라이언트 1 및 2 로 이용 가능한 한 새로운 ENS 1&2 데이터 레코드들을 연결 및 업로드한다(S2118). 그리고, 상기 서버는 연결이 끊어질 때까지 계속한다(S2119).
도 22는 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 22 를 참고하면, 서버는 연결 가능한 W-ENS 비콘에 대해 광고한다(S2201). 클라이언트는 새로운 디바이스를 자신의 프로파일에 추가한다(S2202). 그리고, 상기 클라이언트는 상기 서버로 제 1 페어링 요청을 전송한다(S2203). 그리고, 상기 서버는 쉐이킹/버튼을 누름으로써 페어링을 확인한다(S2204). 그리고, 상기 서버는 상기 클라이언트로 호환 가능한 ENS client 를 연결한다(S2205). 그리고, 상기 서버는 상기 클라이언트로 서버 특징들을 리드한다(S2206). 그리고, 상기 서버는 ENS setting 을 설정한다(S2207). 그리고, 상기 클라이언트는 상기 서버로 ENS 시작을 전송한다(S2208). 그리고, 상기 서버는 ENS-특정 비콘에 대해 광고 및 스캐닝한다(S2209). 그리고, 상기 서버는 RPI 들의 ENS-특정 로깅을 수행한다(S2210). 그리고, 상기 서버는 (낮은 듀티 사이클에서) 연결 가능한 W-ENS 비콘들에 대해 광고한다(S2211). 그리고, 상기 서버는 클라이언트로 이용 가능한 한 새로운 ENS 데이터 레코드들을 연결 및 업로드한다(S2212). 그리고, 상기 클라이언트는 상기 서버로 pause/resume 을 전송한다(S2213). 그리고, 상기 서버는 연결이 끊어질 때까지 계속한다(S2214).
도 23은 본 명세서에서 제안하는 ENS 관련 서버와 클라이언트 간의 흐름도의 일례를 나타낸다.
도 23 을 참고하면, 서버는 연결 가능한 W-ENS 비콘에 대해 광고한다(S2301). 그리고, 클라이언트는 상기 서버로 연결 요청(connection request)을 전송한다(S2302). 그리고, 상기 서버는 상기 클라이언트로 호환 가능한 ENS client 와 연결한다(S2303). 그리고, 상기 서버는 클라이언트로 서버 특징들을 리드(read)한다(S2304). 그리고, 상기 서버는 ENS setting 을 설정한다(S2305). 그리고, 상기 클라이언트는 ENS 를 시작한다(S2306). 그리고, 상기 서버는 ENS-특정 비콘에 대해 광고 및 스캐닝한다(S2307). 그리고, 상기 서버는 RPI 들의 ENS-특정 로깅을 수행한다(S2308). 그리고, 상기 서버는 (낮은 듀티 사이클에서) 연결 가능한 W-ENS 비콘들에 대해 광고한다(S2309). 그리고, 상기 서버는 이용 가능한 한 새로운 ENS 데이터 레코드를 연결 및 업로드한다(S2310). 그리고, 상기 클라이언트는 서버 RPI 들로 노출에 대한 ENS 를 확인하고, 노출 상태를 통지한다(S2311). 그리고, 상기 클라이언트는 상기 서버로 pause/resume을 전송한다(S2312). 그리고, 상기 서버는 연결이 끊어질 때까지 계속한다(S2313).
도 24는 본 명세서에서 제안하는 Client ENS를 제거하는 방법의 일례를 나타낸 순서도이다.
도 24 에 대한 방법의 주체가 서버가 아니고 client 인 경우, 아래 S2101 내지 S2111 단계의 주체는 Client가 될 수 있다.
먼저, (ENS) 서버는 연결 가능한(connectable) W-ENS 비콘에 대해 광고한다(S2401). 그리고, 상기 서버는 ENS Client 에 의해 연결 요청을 수신한다(S2402). 그리고, 상기 서버는 호환 가능한(compatible) ENS Client 와 연결한다(S2403). 그리고, 상기 서버는 서버 특징들을 리드(read)한다(S2404). 그리고, 상기 서버는 서버 ENS setting 에서 Client ENS 를 제거하도록 설정한다(S2405). 그리고, 상기 서버는 Client 와 연결 해지한다(S2406). 그리고, 상기 서버는 남아 있는 설정된 ENS 에 대해 ENS-특정 비콘의 광고 및 스캐닝을 수행한다(S2407). 그리고, 상기 서버는 모든 설정된 ENS 와 호환 가능한 스캔된 RPI 들에 대해 로깅(logging)한다(S2408). 그리고, 상기 서버는 (낮은 듀티 사이클에서) 연결 가능한 W-ENS beacons 들에 대해 광고를 계속한다(S2409). 그리고, 상기 서버는 가능한만큼 새로운 ENS data 레코드들을 연결하고 업로드한다(S2410). 그리고, 상기 서버는 멈출 때까지 남아 있는 모든 설정된 Client ENS 대해 앞서 살핀 S2408 단계 및 S2409 단계를 계속한다(S2411).
도 25는 본 명세서에서 제안하는 Client ENS를 추가하기 위한 절차의 일례를 나타낸 순서도이다.
도 25 에 대한 방법의 주체가 서버가 아니고 client 인 경우, 아래 단계의 주체는 Client 가 될 수 있다.
먼저, 서버는 연결 가능한(connectable) W-ENS 비콘에 대해 광고한다(S2501). 그리고, 상기 서버는 추가적인 ENS Client 에 의해 연결 요청을 수신한다(S2502). 그리고, 상기 서버는 추가적인 호환 가능한(compatible) ENS Client 와 연결한다(S2503). 그리고, 상기 서버는 서버 특징들을 리드(read)한다(S2504). 그리고, 상기 서버는 서버 ENS setting 들에서 2 개 이상의 ENS 를 지원하도록 설정한다(S2505). 그리고, Client 는 ENS 를 시작한다(S2506). 그리고, 상기 서버는 모든 설정된 ENS 와 호환 가능한 ENS-특정 비콘에 대해 광고 및 스캐닝한다(S2507). 그리고, 상기 서버는 모든 설정된 ENS 와 호환 가능한 스캔된 RPI 들에 대해 로깅(logging)한다(S2508). 그리고, 상기 서버는 (낮은 듀티 사이클에서) 연결 가능한 W-ENS beacons 들에 대한 광고를 계속한다(S2509). 그리고, 상기 서버는 Client 들과 Client 의 ENS 에서 이용 가능한만큼 새로운 ENS data 레코드들 연결하고 업로드한다(S2510). 그리고, (use cases 들에 따라) Client 는 잠시 멈추고, 서버를 resume 한다(S2511). 그리고, 상기 서버는 Client 와 연결을 해지한다(S2512). 그리고, 상기 연결 해지 후, 상기 서버는 S2508 단계 및 S2509 단계를 계속한다(S2513). 그리고, 상기 서버는 추가적인 Client 에 의해 멈추어질 때까지/제거될 때까지 모든 설정된 ENS 에 대해 계속한다(S2514). 그리고, 상기 서버는 멈추어질 때까지 모든 남아 있는 설정된 Client ENS에 대해 앞서 살핀 S2508 단계 및 S2509 단계를 계속한다(S2515).
도 26은 본 명세서에서 제안하는 서버와 Client 들 간 흐름도의 일례를 나타낸 도이다.
도 26 에 대한 방법의 주체가 서버가 아니고 client 인 경우, 아래 단계의 주체는 Client 가 될 수 있다.
먼저, Client 1(예: Phone), (Wearable) Server 및 Client 2(예: Phone)은 Client 및 Client 의 ENS 에서 사용할 수 있는 새로운 ENS 데이터 레코드를 연결하고 업로드한다(S2601). 그리고, 상기 서버는 연결 가능한 W-ENS 비콘에 대해 광고 및 스캐닝한다(S2602). 그리고, Client 1 은 상기 서버에 연결하고 데이터 레코드를 얻는다(S2603). 그리고, Client 1 은 상기 서버로 HCI_Create_Connection 메시지를 전송한다(S2604). 그리고, Client 1 은 상기 서버로부터 HCI_Command_Status 메시지를 수신한다(S2605). 그리고, Client 1 과 서버 간에 ENS 데이터 레코드를 업로드한다(S2606). 이후, Client 2 는 상기 서버와 연결하고 데이터 레코드를 획득한다(S2607). 그리고, Client 2 는 서버로 HCI_Create_Connection 메시지를 전송한다(S2608). 그리고, Client 2 는 HCI_Command_Status 를 수신한다(S2609). 그리고, Client 2와 서버 간 ENS data를 업로드한다(S2610).
도 27은 본 명세서에서 제안하는 ENS 관련 절차의 일례를 나타낸 순서도이다.
도 27 에 대한 방법의 주체가 서버가 아니고 client 인 경우, 아래 단계의 주체는 Client 가 될 수 있다.
먼저, 서버는 연결 가능한(connectable) W-ENS 비콘에 대해 광고한다(S2701). 그리고, 상기 서버는 연결 요청을 수신한다(S2702). 그리고, 상기 서버는 호환 가능한(compatible) ENS Client 와 연결한다(S2703). 그리고, 상기 서버는 서버 특징들을 리드(read)한다(S2704). 그리고, 상기 서버는 서버 ENS setting 들을 설정한다(S2705). 그리고, Client 는 ENS 를 시작한다(S2706). 그리고, 상기 서버는 ENS-특정 비콘에 대해 광고 및 스캐닝한다(S2707). 그리고, 상기 서버는 스캔된 RPI 들의 ENS-특정 로깅(logging)을 수행한다(S2708). 그리고, 상기 서버는 (낮은 듀티 사이클에서) 연결 가능한 W-ENS beacon 들에 대해 광고를 계속한다(S2709). 그리고, 상기 서버는 이용 가능한만큼 새로운 ENS data 레코드들을 연결하고 업로드한다(S2710). 그리고, (use cases 들에 따라) Client 는 잠시 멈추고, 서버를 resume 한다(S2711). 그리고, 상기 서버는 Client 와 연결을 해지한다(S2712). 그리고, 상기 연결 해지 후, 상기 서버는 S2708 단계 및 S2709 단계를 계속한다(S2713). 그리고, 상기 서버는 Client 에 의해 멈추어질 때까지 계속한다(S2714).
도 28은 본 명세서에서 제안하는 서버와 Client 간 절차의 일례를 나타낸 흐름도이다.
먼저, Client(예: Phone)와 (Wearable) Server 는 이용 가능한만큼 새로운 ENS 데이터 레코드를 연결하고 업로드한다(S2801). 그리고, 상기 Client 는 연결 가능한 W-ENS 비콘에 대해 광고 및 스캐닝한다(S2802). 그리고, 상기 Client 는 서버로 HCI_Create_Connection 메시지를 전송한다(S2803). 그리고, 상기 Client 는 서버로부터 HCI_Command_Status 메시지를 수신한다(S2804). 그리고, 상기 Client 와 서버 간에 ENS 데이터 레코드를 업로드한다(S2805).
표 28 은 페어링 모드(pairing mode)에 놓였을 때, 웨어러블에 의해 광고되는 비콘의 광고 포맷의 일례를 나타낸다.
표 28 을 참고하면, 웨어러블은 제조하는 동안 Serial Number 및 device secret 이 제공된다. Gateway cloud backend 는 또한 제조 프로세스 동안 사용되는 모든 디바이스들의 Serial Number 및 대응하는 device secret에 접속할 수 있다.
다음, 앞서 살핀 ENS 와 관련된 웨어러블(wearable)의 동작 방법에 대해 보다 구체적으로 살펴본다.
1. 웨어러블이 처음으로 켜지고, 페어링 모드로 진입한다.
2. 웨어러블은 프로비저닝(provisioning) 단계에서 도 19와 같은 포맷으로 광고한다.
3. 인터넷 게이트웨이
- 3.1 비콘을 스캔한다.
- 3.2 디바이스가 프로비저닝(Provisioning)이 필요한지를 결정한다.
- 3.3 게이트웨이는 비콘으로부터 오프셋 12-27 에서 바이트를 추출한다.
- 3.4 추출된 16 바이트를 표 29 에 나타난 바와 같이 장치 ID 해시 엔트리(entry)의 LSB 와 일치시킨다.
- 3.5 게이트웨이가 일치하는 엔트리를 찾으면, 표 29 에서 엔트리를 추출하고, 다음 단계 (4 단계)로 진행한다. 그렇지 않으면, 게이트웨이는 비콘을 무시하고 프로비저닝 프로세스를 중지한다.
4. 게이트웨이가 장치로 프로비저닝을 시작하고, 웨어러블과 GATT 연결을 생성한다.
5. 게이트웨이가 ECDHE 키 교환을 시작한다.
6. ECDHE 키 교환은 128 비트 secret(k)을 도출하기 위해 발생한다.
7. 다른 디바이스가 이 비콘을 복제(replicate)/스푸프(spoof)하고 진짜(authentic) 디바이스로 위장하는 것을 방지하기 위해, 계산된 장치 ID 해시의 16 MSB를 제시할 것이 요청된다.
- 7.1 Wearable은 도출된 비밀 k를 사용하여 16 개의 MSB를 암호화한다.
- 7.2 게이트웨이는 7.1 단계에서 계산된 암호화된 페이로드를 수신하고, 키 k로 해독한다.
- 7.3 게이트웨이가 3.5 단계에서 추출된 엔트리/엔트리들의 MSB 로 웨어러블에 의해 전송된 16 개의 MSB 의 추출된 페이로드를 일치시킬 수 있는 경우, 게이트웨이는 웨어러블이 인증된 것으로 표시한다. 그 밖에, 연결이 끊어지고, 디바이스가 인증 디바이스가 아니기 때문에 프로비저닝에 실패했음을 표시한다. 인증이 성공하면 8 단계로 이동한다.
8. 웨어러블이 성공적으로 인증된 경우, Gateway 는 적절한 ENS 시스템으로 웨어러블을 설정한다. 그리고, 웨어러블은 ENS Spec.에 특정된 광고 간격에서 ENS 비콘 포맷으로 광고하기 시작한다.
9. 웨어러블이 오프로드(offload)할 데이터가 있는 경우, 웨어러블은 도 19 와 같이 비콘 포맷으로 광고하지만 페이로드는 다음과 같이 변경된다.
- 9.1 0x02로 설정된 ENS 플래그를 설정한다.
- 9.2 바이트 12-27 페이로드를 다음과 같이 변경한다.
이를 16 bytes로 자른다.
잘린 해시는 광고된 장치 ID 이며, 15 분마다 비콘에서 업데이트되어야 한다. 인터넷 게이트웨이는 8 단계에서 도출된 암호 k를 공유했기 때문에 디바이스에 의해 브로드캐스트된 고유 ID 를 확인할 수 있다.
웨어러블이 실제 클럭 또는 카운터 기반 클럭을 사용했는지에 따라, 수학식 1 에서 Didh 인 경우 계산을 위해 카운터 또는 시간을 사용할 수 있다. 따라서, Beacon 은 아래 표 30 에 나타난 것과 유사할 수 있다.
ENS 서비스는 백그라운드에서 비콘에 대해 스캔하며, 일반적으로 A/G spec.에 따라 5 분마다 4 초 동안 스캐닝한다. 광고는 다수의 채널들에서 발생한다. 스캔 동안, 웨어러블은 여러 개의 동일한 BLE 비콘을 감지할 수 있다. 웨어러블이 모든 비콘을 계속 저장하면 메모리가 매우 빨리 소진된다. 하나의 family 가 2 개의 유사한 웨어러블들을 구입하고, 2 개의 웨어러블이 하룻밤 사이에 근접해 있는 경우 웨어러블 메모리는 스캔하는 모든 비콘을 저장하기 시작하면 매우 빠르게 가득 차게 될 수 있다는 시나리오를 생각해보자. 따라서, 모든 비콘 페이로드를 저장하는 대신, 웨어러블은 15 분에 대해 일정 시간 동안 쌍의 수(RSSI, timestamp)에 뒤따르는 ENS 페이로드를 한 번 저장하여 스토리지를 최적화할 수 있다. 표 31 은 ENS 페이로드 포맷의 일례를 나타낸다.
Flags 필드의 비트는 아래 표 32와 같이 정의될 수 있다.
본 명세서에서 사용된 용어 "부"는(예를 들면, 제어부 등), 예를 들어, 하드웨어, 소프트웨어 또는 펌웨어(firmware) 중 하나 또는 둘 이상의 조합을 포함하는 단위(unit)를 의미할 수 있다. "부"는, 예를 들어, 유닛(unit), 로직(logic), 논리블록 (logical block), 부품(component), 또는 회로(circuit) 등의 용어와 바꾸어 사용(interchangeably use)될 수 있다. "부"는, 일체로 구성된 부품의 최소 단위 또는 그 일부가 될 수 있다. "부"는 하나 또는 그 이상의 기능을 수행하는 최소 단위 또는 그 일부가 될 수도 있다. "부"는 기계적으로 또는 전자적으로 구현될 수 있다. 예를 들어, "부"는, 알려졌거나 앞으로 개발될, 어떤 동작들을 수행하는 ASIC(application-specific integrated circuit) 칩, FPGAs(field-programmable gate arrays) 또는 프로그램 가능 논리 장치(programmable-logic device) 중 적어도 하나를 포함할 수 있다.
다양한 실시예에 따른 장치(예: 모듈들 또는 그 기능들) 또는 방법(예: 동작들)의 적어도 일부는, 예컨대, 프로그램 모듈의 형태로 컴퓨터로 읽을 수 있는 저장매체(computer-readable storage media)에 저장된 명령어로 구현될 수 있다. 상기 명령어가 프로세서에 의해 실행될 경우, 상기 하나 이상의 프로세서가 상기 명령어에 해당하는 기능을 수행할 수 있다. 컴퓨터로 읽을 수 있는 저장매체는, 예를 들어, 메모리가 될 수 있다.
컴퓨터로 읽을 수 있는 저장매체/컴퓨터로 판독 가능한 기록 매체는, 하드디스크, 플로피디스크, 마그네틱 매체(magnetic media)(예: 자기테이프), 광기록 매체(optical media)(예: CD-ROM(compact disc read only memory), DVD(digital versatile disc), 자기-광 매체(magneto-optical media)(예: 플롭티컬 디스크(floptical disk)), 하드웨어 장치(예: ROM(read only memory), RAM(random access memory), 또는 플래시 메모리 등) 등을 포함할 수 있다. 또한, 프로그램 명령에는 컴과일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함할 수 있다. 상술한 하드웨어 장치는 다양한 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지다.
다양한 실시예에 따른 모듈 또는 프로그램 모듈은 전술된 구성 요소들 중 적어도 하나 이상을 포함하거나, 일부가 생략되거나, 또는 추가적인 다른 구성 요소를 더 포함할 수 있다. 다양한 실시예에 따른 모듈, 프로그램 모듈 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적, 병렬적, 반복적 또는 휴리스틱(heuristic)한 방법으로 실행될 수 있다. 또한, 일부 동작은 다른 순서로 실행되거나, 생략되거나, 또는 다른 동작이 추가될 수 있다.
본 명세서에 사용된 용어 "하나"는 하나 또는 하나 이상으로 정의된다. 또한, 청구 범위에서 "적어도 하나" 및 "하나 이상"과 같은 도입 문구를 사용하는 것은, 동일한 청구항에 "적어도 하나" 및 "하나 이상"과 같은 도입 문구 및 "하나" 같은 불명료한 문구가 포함되어 있는 경우라 할지라도, 불명료한 문구 "하나"에 의한 다른 청구항 요소의 도입이 그러한 요소를 하나만을 포함하는 발명에 대해 그렇게 도입된 청구항 요소를 포함하는 임의의 특정 청구항을 제한한다는 것을 의미하는 것으로 해석되어서는 안된다.
달리 명시하지 않는 한, "제 1" 및 "제 2"와 같은 용어는 그러한 용어가 설명하는 요소들을 임의로 구별하는 데 사용된다. 따라서, 이들 용어는 그러한 요소들의 시간적 또는 다른 우선 순위를 나타내도록 반드시 의도된 것은 아니며, 특정 수단이 서로 다른 청구항들에 열거되어 있다는 단순한 사실만으로 이러한 수단들의 조합이 유리하게 사용될 수 없다는 것을 나타내는 것은 아니다. 따라서, 이들 용어는 그러한 요소의 시간적 또는 다른 우선 순위를 나타내도록 반드시 의도되지는 않는다. 특정 조치가 서로 다른 주장에 인용되었다는 단순한 사실만으로 이러한 조치의 조합이 유용하게 사용될 수 없다는 것을 나타내지는 않는다.
동일한 기능을 달성하기 위한 구성 요소의 배열은 효과적으로 "관련"되어 원하는 기능이 달성된다. 따라서, 특정 기능성을 달성하기 위해 결합된 임의의 2 개의 구성 요소는 구조 또는 중개하는 구성 요소와 관계없이 원하는 기능이 달성되도록 서로 "관련"되는 것으로 간주될 수 있다. 마찬가지로 이와 같이 연관된 두 개의 구성 요소는 원하는 기능을 달성하기 위해 서로 "작동 가능하게 연결"되거나 "작동 가능하게 결합된" 것으로 간주될 수 있다.
또한, 통상의 기술자는 전술한 동작들의 기능성 사이의 경계가 단지 예시적인 것임을 인식할 것이다. 복수의 동작들은 단일 동작으로 결합될 수 있고, 단일 동작은 추가 동작들로 분산될 수 있으며, 동작들은 시간적으로 적어도 부분적으로 겹쳐서 실행될 수 있다. 또한, 대안적인 실시예들은 특정 동작에 대한 복수의 인스턴스들을 포함할 수 있고, 동작들의 순서는 다양한 다른 실시예에서 변경될 수 있다. 그러나, 다른 수정, 변형 및 대안이 또한 가능하다. 따라서, 상세한 설명 및 도면은 제한적인 의미가 아니라 예시적인 것으로 간주되어야 한다.
"X 일 수 있다"는 문구는 조건 X 가 충족될 수 있음을 나타낸다. 이 문구는 또한 조건 X 가 충족되지 않을 수도 있음을 나타낸다. 예를 들어, 특정 구성 요소를 포함하는 시스템에 대한 참조는 시스템이 특정 구성 요소를 포함하지 않는 시나리오도 포함해야 한다. 예를 들어, 특정 동작을 포함하는 방법에 대한 참조는 해당 방법이 특정 구성 요소를 포함하지 않는 시나리오도 포함해야 한다. 그러나 또 다른 예를 들면, 특정 동작을 수행하도록 구성된 시스템에 대한 참조는 시스템이 특정 작업을 수행하도록 구성되지 않은 시나리오도 포함해야 한다.
용어 "포함하는", "갖는", "구성된", "이루어진" 및 "본질적으로 이루어진"은 상호 교환적으로 사용된다. 예를 들어, 임의의 방법은 적어도 도면 및/또는 명세서에 포함된 동작을 포함할 수 있으며, 도면 및/또는 명세서에 포함된 동작만을 포함할 수 있다.
통상의 기술자는 논리 블록들 사이의 경계가 단지 예시적인 것이며, 대안적인 실시 예들이 논리 블록들 또는 회로 소자들을 병합하거나 또는 다양한 논리 블록들 또는 회로 소자들 상에 기능의 대체적인 분해를 부과할 수 있음을 인식할 것이다. 따라서, 여기에 도시된 아키텍처는 단지 예시적인 것이며, 사실 동일한 기능을 달성하는 많은 다른 아키텍처가 구현될 수 있다는 것으로 이해되어야 한다.
또한, 예를 들어, 일 실시예에서, 도시된 예들은 단일 집적 회로 상에 또는 동일한 장치 내에 위치된 회로로서 구현될 수 있다. 대안적으로, 상기 예들은 임의의 수의 개별적인 집적 회로들 또는 적합한 방식으로 서로 상호 접속된 개별 장치들로서 구현될 수 있으며, 다른 변경, 수정, 변형 및 대안들이 또한 가능하다. 따라서, 명세서 및 도면은 제한적인 의미가 아니라 예시적인 것으로 간주되어야 한다.
또한, 예를 들어, 상기 예들 또는 그 일부는, 임의의 적절한 유형의 하드웨어 기술 언어와 같은, 물리적 회로 또는 물리적 회로로 변환 가능한 논리적 표현의 소프트웨어 또는 코드 표현으로서 구현될 수 있다.
또한, 본 명세서는 비 프로그래머블 하드웨어로 구현된 물리적 장치 또는 유닛으로 제한되지 않지만, 일반적으로 본원에서는 '컴퓨터 시스템'으로 표시되는 메인 프레임, 미니 컴퓨터, 서버, 워크스테이션, 개인용 컴퓨터, 노트패드(notepad), 개인용 디지털 정보 단말기(PDA), 전자 게임(electronic games), 자동차 및 기타 임베디드 시스템, 휴대전화 및 다양한 다른 무선 장치 등과 같은, 적절한 프로그램 코드에 따라 동작함으로써 원하는 장치 기능을 수행할 수 있는 프로그램 가능한 장치 또는 유닛에도 적용될 수 있다.
이 명세서에 언급된 시스템, 장치 또는 디바이스는 적어도 하나의 하드웨어 구성 요소를 포함한다.
본 명세서에 설명된 바와 같은 연결들은 예를 들어 중간 장치를 통해 각각의 노드, 유닛 또는 장치로부터 또는 각각의 노드, 유닛 또는 장치로 신호를 전송하기에 적합한 임의의 유형의 연결일 수 있다. 따라서, 묵시적으로 또는 달리 언급되지 않는 한, 연결은 예를 들어 직접 연결 또는 간접 연결일 수 있다. 연결은 단일 연결, 다수의 연결, 단방향 연결 또는 양방향 연결이라는 것을 참조하여 설명되거나 묘사될 수 있다. 그러나, 서로 다른 실시 예들은 연결의 구현을 변화시킬 수 있다. 예를 들어 양방향 연결이 아닌 별도의 단방향 연결을 사용할 수 있으며 그 반대의 경우도 가능할 수 있다. 또한, 다수의 연결은 복수의 신호를 순차적으로 또는 시간 다중화 방식으로 전송하는 단일 연결로 대체될 수 있다. 마찬가지로, 복수의 신호를 전송하는 단일 연결은 이러한 신호의 서브 세트를 전송하는 다양한 연결로 분리될 수 있다. 따라서 신호를 전송하기 위한 많은 옵션들이 존재한다.
통상의 기술자는 논리 블록들 사이의 경계가 단지 예시적인 것이며, 대안적인 실시 예들이 논리 블록들 또는 회로 소자들을 병합하거나 또는 다양한 논리 블록들 또는 회로 소자들 상에 기능의 대체적인 분해를 부과할 수 있음을 인식할 것이다. 따라서, 여기에 도시된 아키텍처는 단지 예시적인 것이며, 사실 동일한 기능을 달성하는 많은 다른 아키텍처가 구현될 수 있다는 것으로 이해되어야 한다.
청구항에서, 괄호 사이에 위치한 임의의 참조 부호는 청구항을 제한하는 것으로 해석되어서는 아니된다. '포함하는'이라는 단어는 청구항에 나열된 요소들 또는 동작들의 존재를 배제하지 않는다.
이상에서 본 명세서의 기술에 대한 바람직한 실시 예가 첨부된 도면들을 참조하여 설명되었다. 여기서, 본 명세서 및 청구 범위에 사용된 용어나 단어는 통상적이거나 사전적인 의미로 한정해서 해석되어서는 아니되며, 본 명세서의 기술적 사상에 부합하는 의미와 개념으로 해석되어야 한다. 본 명세서의 범위는 본 명세서에 개시된 실시 예들로 한정되지 아니하고, 본 명세서는 본 명세서의 사상 및 특허청구범위에 기재된 범주 내에서 다양한 형태로 수정, 변경, 또는 개선될 수 있다.
Claims (1)
- ENS 서비스를 수행하기 위한 방법에 있어서,
서버에 의해, 연결 가능한 ENS 비콘에 대해 광고하는 단계;
클라이언트에 의해, 새로운 디바이스를 상기 클라이언트의 프로파일에 추가하는 단계;
상기 클라이언트에 의해, 상기 서버로 제 1 페어링 요청을 전송하는 단계;
상기 서버에 의해, 상기 클라이언트와 페어링을 확인하여 상기 클라이언트로 호환 가능한 ENS 클라이언트를 연결하는 단계;
상기 서버에 의해, 상기 클라이언트로 상기 서버의 특징을 리드(read)하는 단계;
상기 서버에 의해, ENS 세팅을 설정하는 단계; 및
상기 클라이언트에 의해, 상기 서버로 ENS 시작을 전송하는 단계를 포함하는 방법.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020200115613A KR20220033337A (ko) | 2020-09-09 | 2020-09-09 | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020200115613A KR20220033337A (ko) | 2020-09-09 | 2020-09-09 | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20220033337A true KR20220033337A (ko) | 2022-03-16 |
Family
ID=80937892
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020200115613A KR20220033337A (ko) | 2020-09-09 | 2020-09-09 | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR20220033337A (ko) |
-
2020
- 2020-09-09 KR KR1020200115613A patent/KR20220033337A/ko active Search and Examination
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3420759B1 (en) | A source device broadcasts synchronization information associated with a bluetooth isochronous channel. | |
| US11064423B2 (en) | Systems and methods for wirelessly modifying detection characteristics of portable devices | |
| US20210014679A1 (en) | Identity Obscuration for a Wireless Station | |
| US9900827B2 (en) | Method and apparatus for transmitting and receiving data in wireless communication system | |
| Afaneh | Intro to Bluetooth low energy | |
| US20080181154A1 (en) | Apparatus for and method of low power wireless local area network independent basic service set mode operation | |
| US20210400096A1 (en) | Method and apparatus for receiving audio data by using bluetooth technology | |
| US9930477B2 (en) | Method and apparatus for transmitting and receiving data in wireless communication system | |
| WO2022143071A1 (zh) | 连接建立方法及电子设备 | |
| CN107079402A (zh) | 用于邻域感知网络中的同步的系统和方法 | |
| US12086502B2 (en) | Method for transmitting audio data using short-range communication in wireless communication system, and device for same | |
| CN115989690A (zh) | 近所有者维持 | |
| US20230073658A1 (en) | Privacy protection for sidelink communications | |
| US10492060B2 (en) | Method and device for transmitting/receiving data in wireless communication system | |
| US20230103916A1 (en) | Audio data reception method using short-range wireless communication in wireless communication system, and apparatus therefor | |
| WO2014051430A1 (en) | Method and apparatus for transmitting, receiving and forwarding a gossip message using a gossip network | |
| KR20220033337A (ko) | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 | |
| KR20230097672A (ko) | Ble를 이용하여 의료 데이터를 송수신하기 위한 방법 및 이를 지원하는 장치 | |
| US20220346040A1 (en) | Method for transmitting audio data using short-range wireless communication in wireless communication system, and apparatus therefor | |
| KR20230097608A (ko) | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 | |
| Martelli | Bluetooth low energy | |
| KR20230097633A (ko) | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 | |
| KR20230097629A (ko) | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 | |
| KR20230097617A (ko) | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 | |
| KR20230097637A (ko) | 블루투스에서 노출 알림 서비스를 수행하기 위한 방법 및 이를 지원하는 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination |