KR20170056807A - 무선 통신 시스템에서 데이터를 송수신하기 위한 방법 및 장치 - Google Patents

Abstract

본 발명은 무선 통신 시스템에서 디바이스 간 연결을 형성하기 위한 방법에 있어서, 제 1 디바이스에 의해 수행되는 방법은, 디바이스 디스커버리를 수행하는 단계; 제 2 디바이스와 다른 통신 인터페이스와 관련된 제어 정보를 교환하는 단계; 및 상기 제어 정보에 기초하여 상기 제 2 디바이스와 다른 통신 인터페이스로 연결하기 위한 핸드오버를 수행하는 단계를 포함하여 이루어지는 것을 특징으로 한다.

Description

무선 통신 시스템에서 데이터를 송수신하기 위한 방법 및 장치{APPARATUS AND METHOD FOR TRANSCEIVING A DATA IN A WIRELESS COMMUNICATION SYSTEM}

본 명세서는 무선 통신 시스템에서 데이터를 송수신하기 위한 방법 및 장치에 관한 것으로써, 특히 블루투스 통신을 이용하여 데이터를 송수신하기 위한 방법 및 장치에 관한 것이다.

블루투스는 근거리에서 각종 디바이스들을 무선으로 연결하여 데이터를 주고

받을 수 있는 근거리 무선 기술 규격이다. 블루투스(Bluetooth) 통신을 이용하여 두 기기간 무선 통신을 수행하고자 하는 경우, 사용자(User)는 통신하고자 하는 블루투스(Bluetooth) 디바이스(Device)들을 검색(Discovery)하고 연결(Connection)을 요청하는 절차를 수행한다. 본 발명에서 디바이스는 기기, 장치를 의미할 수 있다.

이때, 사용자는 블루투스 디바이스를 이용하여 사용하고자 하는 블루투스 통신방법에 따라 블루투스 디바이스를 검색한 후 연결을 수행할 수 있다.

블루투스 통신방법에는 블루투스 BR/EDR (Basic Rate/Enhanced Data Rate)방식과 저전력 방식인 블루투스 LE (Low Energy)방식이 있다. 블루투스 BR/EDR 방식은 클래식 블루투스(Classic Bluetooth)라고 호칭될 수 있다. 클래식 블루투스 방식은 베이직 레이트(Basic Rate)를 이용하는 블루투스 1.0부터 2.1로 이어져온 블루투스 기술과 블루투스 2.0에서부터 지원되는 인핸스드 데이터 레이트(Enhanced Data Rate)를 이용하는 블루투스 기술을 포함한다.

블루투스 저전력 에너지(Bluetooth Low energy, 이하 블루투스 LE라고 한다.)기술은 적은 전력을 소모하여 수백 키로바이트의 정보를 안정적으로 제공할 수 있다. 이러한 블루투스 저전력 에너지 기술은 속성 프로토콜(Attribute Protocol)을 활용해서 디바이스(Device) 간 정보를 교환하게 된다. 이러한 블루투스 LE 방식은 헤더의 오버헤드(overhead)를 줄이고 동작을 간단하게 해서 에너지 소비를 줄일 수 있다.

본 발명은 블루투스 통신을 이용하여 다른 통신 인터페이스 발견 및 발견된 다른 통신 인터페이스로 핸드오버를 수행하는 방법을 제공함에 목적이 있다.

또한, 본 발명은

본 발명은 무선 통신 시스템에서 디바이스 간 연결을 형성하기 위한 방법에 있어서, 제 1 디바이스에 의해 수행되는 방법은, 디바이스 디스커버리를 수행하는 단계;

제 2 디바이스와 다른 통신 인터페이스와 관련된 제어 정보를 교환하는 단계; 및 상기 제어 정보에 기초하여 상기 제 2 디바이스와 다른 통신 인터페이스로 연결하기 위한 핸드오버를 수행하는 단계를 포함하여 이루어지는 것을 특징으로 한다.

본 발명은 블루투스 통신을 이용하여 다른 무선 통신 인터페이스와 연결함으로써, 무선 통신 인터페이스의 연결 시간을 단축시킬 수 있다.

또한, 본 발명은 하나의 무선 통신 인터페이스만 활성화 시킨 상태에서 다른 무선 통신 인터페이스를 발견하고, 연결할 수 있어, 결과적으로 디바이스의 전력 소모를 감소시킬 수 있는 효과가 있다.

도 1은 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.

본 발명의 상술한 목적, 특징들 및 장점은 첨부된 도면과 관련된 다음의 상세한 설명을 통해 보다 분명해질 것이다. 다만, 본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시 예들을 가질 수 있는 바, 이하에서는 특정 실시 예들을 도면에 예시하고 이를 상세히 설명하고자 한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 발명과 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.

이하, 본 발명과 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다.

본 명세서에서 설명되는 전자기기에는 휴대폰, 스마트 폰(smart phone), 노트북 컴퓨터(laptop computer), 디지털방송용 단말기, PDA(Personal Digital Assistants), PMP(Portable Multimedia Player), 네비게이션 등이 포함될 수 있다. 그러나, 본 명세서에 기재된 실시예에 따른 구성은 이동 단말기에만 적용 가능한 경우를 제외하면, 디지털 TV, 데스크탑 컴퓨터 등과 같은 고정 단말기에도 적용될 수도 있음을 본 기술분야의 당업자라면 쉽게 알 수 있을 것이다.

본 명세서에서 설명되는 신호는 메시지형태뿐만 아니라 프레임 형태로도 전송될 수 있으며, 무선 통신 인터페이스 및 무선 통신 수단은 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다.

아래 도 1을 제외하고는 본 명세서의 도면에서 도시하지 않았지만, 도면에 대한 설명으로 각 도면을 충분히 작성할 수 있으며, 추후에 각 도면에 대한 설명을 통해 해당 도면을 추가할 수 있도 있다.

도 1은 BLE를 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.

무선 통신 시스템(100)은 적어도 하나의 서버 디바이스(Server Device, 110) 및 적어도 하나의 클라이언트 디바이스(Client Device,120)를 포함한다.

서버 디바이스와 클라이언트 디바이스는 블루투스 저전력 에너지(Bluetooth Low Energy:BLE, 이하 편의상 ‘BLE’로 표현한다.) 기술을 이용하여 블루투스 통신을 수행한다.

먼저, BLE 기술은 블루투스 BR/EDR(Basic Rate/Enhanced Data Rate) 기술과 비교하여, 상대적으로 작은 duty cycle을 가지며 저 가격 생산이 가능하고, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있어 코인 셀(coin cell) 배터리를 이용할 경우 1년 이상 동작이 가능하다.

또한, BLE 기술에서는 디바이스 간 연결 절차를 간소화하였으며, 패킷 사이즈도 블루투스 BR/EDR 기술에 비해 작게 설계되어 있다.

BLE 기술에서, (1) RF 채널수는 40개이며, (2) 데이터 전송 속도는 1Mbps를 지원하며, (3) 토폴로지는 스타 구조이며, (4) latency는 3ms 이며, (5) 최대 전류는 15mA이하이며, (6) 출력 전력은 10mW(10dBm)이하이며, (7) 휴대폰, 시계, 스포츠, 헬스케어, 센서, 기기제어 등의 어플리케이션에 주로 사용된다.

상기 서버 디바이스(110)는 다른 디바이스와의 관계에서 클라이언트 디바이스로 동작할 수 있고, 상기 클라이언트 디바이스는 다른 디바이스와의 관계에서 서버 디바이스로 동작할 수 있다. 즉, BLE 통신 시스템에서 어느 하나의 디바이스는 서버 디바이스 또는 클라이언트 디바이스로 동작하는 것이 가능하며, 필요한 경우, 서버 디바이스 및 클라이언트 디바이스로 동시에 동작하는 것도 가능하다.

상기 서버 디바이스(110)는 데이터 서비스 디바이스(Data Service Device), 마스터(Master) 디바이스, 마스터(Master), 서버, 컨덕터(Conductor), 호스트 디바이스(Host Device), 오디오 소스 디바이스(Audio Source Device), 제 1 디바이스 등으로 표현될 수 있으며, 상기 클라이언트 디바이스는 슬레이브(Slave) 디바이스, 슬레이브(Slave), 클라이언트, 멤버(Member), 싱크 디바이스(Sink Device), 오디오 싱크 디바이스(Audio Sink Device), 제 2 디바이스 등으로 표현될 수 있다.

서버 디바이스와 클라이언트 디바이스는 상기 무선 통신 시스템의 주요 구성요소에 해당하며, 상기 무선 통신 시스템은 서버 디바이스 및 클라이언트 디바이스 이외에도 다른 구성요소를 포함할 수 있다.

상기 서버 디바이스는 클라이언트로부터 데이터를 제공 받고, 클라이언트 디바이스와 직접 통신을 수행함으로써, 클라이언트 디바이스로부터 데이터 요청을 수신하는 경우, 응답을 통해 클라이언트 디바이스로 데이터를 제공하는 디바이스를 말한다.

또한, 상기 서버 디바이스는 클라이언트 디바이스로 데이터 정보를 제공하기 위해 클라이언트 디바이스에게 알림(Notification) 메시지, 지시(Indication) 메시지를 보낸다. 또한, 상기 서버 디바이스는 상기 클라이언트 디바이스로 지시 메시지를 전송하는 경우, 상기 클라이언트로부터 상기 지시 메시지에 대응하는 확인(Confirm) 메시지를 수신한다.

또한, 상기 서버 디바이스는 알림, 지시, 확인 메시지들을 클라이언트 디바이스와 송수신하는 과정에서 출력부(Display Unit)을 통해서 사용자에게 데이터 정보를 제공하거나 입력부(User Input Interface)를 통해 사용자로부터 입력되는 요청을 수신할 수 있다.

또한, 상기 서버 디바이스는 상기 클라이언트 디바이스와 메시지를 송수신하는 과정에서 메모리(memory unit)로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.

또한, 하나의 서버 디바이스는 다수의 클라이언트 디바이스들과 연결될 수 있으며, 본딩(Bonding) 정보를 활용하여 클라이언트 디바이스들과 쉽게 재 연결(또는 접속)이 가능하다.

상기 클라이언트 디바이스(120)는 서버 디바이스에게 데이터 정보 및 데이터 전송을 요청하는 장치를 말한다.

클라이언트 디바이스는 상기 서버 디바이스로부터 알림 메시지, 지시 메시지 등을 통해 데이터를 수신하고, 지시 메시지를 상기 서버 디바이스로부터 수신하는 경우, 상기 지시 메시지에 대한 응답으로 확인 메시지를 보낸다.

상기 클라이언트 디바이스도 마찬가지로 상기 서버 디바이스와 메시지들을 송수신하는 과정에서 출력부를 통해서 사용자에게 정보를 제공하거나 입력부를 통해서 사용자로부터의 입력을 수신할 수 있다.

또한, 상기 클라이언트 디바이스는 상기 서버 디바이스와 메시지를 송수신하는 과정에서 메모리로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.

상기 서버 디바이스 및 클라이언트 디바이스의 출력부, 입력부 및 메모리 등과 같은 하드웨어 구성요소에 대해서는 도 5에서 구체적으로 살펴보기로 한다.

또한, 상기 무선 통신 시스템은 블루투스 기술을 통해 개인 영역 네트워킹(Personal Area Networking:PAN)을 구성할 수 있다. 일 예로, 상기 무선 통신 시스템에서는 디바이스 간 개인적인 피코넷(private piconet)을 확립함으로써 파일, 서류 등을 신속하고 안전하게 교환할 수 있다.

BLE 디바이스(또는 기기)는 다양한 블루투스-관련 프로토콜, 프로파일, 처리 등을 지원하도록 동작 가능할 수 있다.

상기 BLE 기술을 포함하고 있는 전자기기는 상기 BLE 외에도 Wi-Fi, Bluetooth BR/EDR, NFC 등의 다수의 무선 통신 인터페이스(Interface)를 포함하고 있다.

상기 무선 통신 인터페이스는 무선 통신 모듈, 무선 통신 수단, 무선 통신 기술 등 다양한 용어로 호칭될 수도 있다.

도 2는 디바이스간 무선 통신 인터페이스의 연결 방법의 일 예를 나타낸다.

도 2를 참조하면, 디바이스에 포함된 무선 통신 인터페이스들은 각각의 절차에 따라서 연결(Connection)을 수행한다.

상기 도 2에서 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)가 블루투스 BR/EDR을 통해서 무선 통신을 수행하고자 하는 경우, 상기 제 1 디바이스(200)는 Bluetooth BR/EDR을 통해서 상기 제 2 디바이스(300)의 블루투스 BR/EDR을 검색하고 Capability를 확인, 연결하여 무선 통신을 수행할 수 있다.

이와 동일하게, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)가 NFC(Near Field Communication)를 통해서 무선 통신을 수행하고자 하는 경우, 상기 제 1 디바이스(200)는 NFC를 통해서 상기 제 2 디바이스(300)의 블루투스 BR/EDR을 검색하고 Capability를 확인, 연결하여 무선 통신을 수행하여야 한다.

도 3은 블루투스 통신 아키텍쳐(Architercture)의 일 예를 나타낸 도이다.

도 3a는 블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 프로토콜 스택의 일 예를 나타내며, 도 3b는 블루투스 LE(Low Energy)의 프로토콜 스택의 일 예를 나타낸다.

구체적으로, 블루투스 BR/EDR 프로토콜 스택은 호스트 컨트롤러 인터페이스(Host Controller Interface, HCI, 18)를 기준으로 상부의 컨트롤러 스택(Controller stack, 10)과 하부의 호스트 스택(Host Stack, 20)을 포함할 수 있다.

상기 호스트 스택(또는 호스트 모듈)(20)은 2.4GHz의 블루투스 신호를 받는 무선 송수신 모듈과 블루투스 패킷을 전송하거나 수신하기 위한 하드웨어를 말하며, 상기 컨트롤러 스택(10)인 블루투스 모듈과 연결되어 블루투스 모듈을 제어하고 동작을 수행한다.

상기 호스트 스택(20)은 BR/EDR PHY 계층(12), BR/EDR Baseband 계층(14), 링크 매니저 계층(Link Manager, 16)을 포함할 수 있다.

상기 BR/EDR PHY 계층(12)은 2.4GHz 무선 신호를 송수신하는 계층으로, GFSK (Gaussian Frequency Shift Keying) modulation을 사용하는 경우 79 개의 RF 채널을 hopping 하여 데이터를 전송할 수 있다.

상기 BR/EDR Baseband 계층(14)은 Digital Signal을 전송하는 역할을 담당하며, 초당 1400번 hopping 하는 채널 시퀀스를 선택하며, 각 채널 별 625us 길이의 time slot을 전송한다.

상기 링크 매니저 계층(16)은 LMP(Link Manager Protocol)을 활용하여 Bluetooth Connection의 전반적인 동작(link setup, control, security)을 제어한다.

상기 링크 매니저 계층(16)은 아래와 같은 기능을 수행할 수 있다.

- ACL/SCO logical transport, logical link setup 및 control을 한다.

- Detach: connection을 중단하고, 중단 이유를 상대 디바이스에게 알려준다.

- Power control 및 Role switch를 한다.

- Security(authentication, pairing, encryption) 기능을 수행한다.

상기 호스트 컨트롤러 인터페이스 계층(18)은 Host 모듈과 Controller 모듈 사이의 인터페이스 제공하여 Host 가 command와 Data를 Controller에게 제공하게 하며, Controller가 event와 Data를 Host에게 제공할 수 있도록 해준다.

상기 호스트 스택(또는 호스트 모듈, 20)은 논리적 링크 제어 및 적응 프로토콜(L2CAP, 21), BR/EDR 프로토콜(Protocol, 22), 일반 접근 프로파일(Generic Access Profile, GAP, 23), BR/EDR 프로파일(24)을 포함한다.

상기 논리적 링크 제어 및 적응 프로토콜(L2CAP, 21)은 특정 프로토콜 또는 포로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공할 수 있다.

상기 L2CAP(21)은 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 멀티플렉싱(multiplexing)할 수 있다.

블루투스 BR/EDR의 L2CAP에서는 dynamic 채널 사용하며, protocol service multiplexer, retransmission, streaming mode를 지원하고, Segmentation 및 reassembly, per-channel flow control, error control을 제공한다.

상기 BR/EDR Protocol(22) 및 Profiles(24)은 블루트스 BR/EDR를 이용하는 서비스 (profile)의 정의 및 이들 데이터를 주고 받기 위한 application 프로토콜을 정의하며, 상기 일반 접근 프로파일(Generic Access Profile, GAP, 23)은 디바이스 발견, 연결, 사용자에게 정보를 제공하는 방안을 정의하며, privacy를 제공한다.

상기 도 3의 (b)에 도시된 바와 같이, 블루투스 LE 프로토콜 스택은 타이밍이 중요한 무선장치 인터페이스를 처리하도록 동작 가능한 컨트롤러 스택(Controller stack, 30)과 고레벨(high level) 데이터를 처리하도록 동작 가능한 호스트 스택(Host stack, 40)을 포함한다.

먼저, 컨트롤러 스택(30)은 블루투스 무선장치를 포함할 수 있는 통신 모듈, 예를 들어, 마이크로프로세서와 같은 프로세싱 디바이스를 포함할 수 있는 프로세서 모듈을 이용하여 구현될 수 있다.

호스트 스택은 프로세서 모듈 상에서 작동되는 OS의 일부로서, 또는 OS 위의 패키지(package)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.

일부 사례들에서, 컨트롤러 스택 및 호스트 스택은 프로세서 모듈 내의 동일한 프로세싱 디바이스 상에서 작동 또는 실행될 수 있다.

상기 컨트롤러 스택(30)은 물리 계층(Physical Layer, PHY, 32), 링크 레이어(Link Layer, 34) 및 호스트 컨트롤러 인터페이스(Host Controller Interface, 36)를 포함한다.

상기 물리 계층(PHY, 무선 송수신 모듈, 32)은 2.4 GHz 무선 신호를 송수신하는 계층으로 GFSK (Gaussian Frequency Shift Keying) modulation과 40 개의 RF 채널로 구성된 frequency hopping 기법을 사용한다.

블루투스 패킷을 전송하거나 수신하는 역할을 하는 상기 링크 레이어(34)는 3개의 Advertising 채널을 이용하여 Advertising, Scanning 기능을 수행한 후에 디바이스 간 연결을 생성하고, 37개 Data 채널을 통해 최대 42bytes 의 데이터 패킷을 주고 받는 기능을 제공한다.

본 발명에서는 이러한 Advertising, 또는 Scanning 기능을 이용하여 상기 BLE 외의 다른 무선 통신 인터페이스의 연결 절차를 위한 정보를 디바이스간에 교환할 수 있으며, 상기 교환된 정보를 기초로 상기 다른 무선 통신 인터페이스의 연결 절차를 수행할 수 있다.

상기 호스트 스택은 GAP(Generic Access Profile, 40), 논리적 링크 제어 및 적응 프로토콜(L2CAP, 41), 보안 매니저(Security Manager, SM, 42), 속성 프로토콜(Attribute Protocol, ATT, 440), 일반 속성 프로파일(Generic Attribute Profile, GATT, 44), 일반 접근 프로파일(Generic Access Profile, 25), LT 프로파일(46)을 포함할 수 있다. 다만, 상기 호스트 스택(40)은 이것으로 한정되지는 않고 다양한 프로토콜들 및 프로파일들을 포함할 수 있다.

호스트 스택은 L2CAP을 사용하여 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 다중화(multiplexing)한다.

먼저, L2CAP(Logical Link Control and Adaptation Protocol, 41)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공할 수 있다.

상기 L2CAP(41)은 상위 계층 프로토콜들 사이에서 데이터를 다중화(multiplex)하고, 패키지(package)들을 분할(segment) 및 재조립(reassemble)하고, 멀티캐스트 데이터 송신을 관리하도록 동작 가능할 수 있다.

블루투스 LE 에서는 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, 42)은 디바이스를 인증하며, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.

ATT(Attribute Protocol, 43)는 서버-클라이언트(Server-Client) 구조로 상대 디바이스의 데이터를 접근하기 위한 규칙을 정의한다. ATT에는 아래의 6가지의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 있다.

① Request 및 Response 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보를 요청하기 위한 메시지이며, Response 메시지는 Request 메시지에 대한 응답 메시지로서, 서버 디바이스에서 클라이언트 디바이스로 전송되는 메시지를 말한다.

② Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 특정 동작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.

③ Notification 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.

④ Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지(Confirm message)를 서버 디바이스로 전송한다.

상기 일반 접근 프로파일(GAP, 45)은 블루투스 LE 기술을 위해 새롭게 구현된 계층으로, 블루투스 LE 디바이스들 간의 통신을 위한 역할 선택, 멀티 프로파일 작동이 어떻게 일어나는지를 제어하는데 사용된다.

또한, 상기 일반 접근 프로파일(45)은 디바이스 발견, 연결 생성 및 보안 절차 부분에 주로 사용되며, 사용자에게 정보를 제공하는 방안을 정의하며, 하기와 같은 attribute의 type을 정의한다.

① Service: 데이터와 관련된 behavior의 조합으로 디바이스의 기본적인 동작을 정의

② Include: 서비스 사이의 관계를 정의

③ Characteristics: 서비스에서 사용되는 data 값

④ Behavior: UUID(Universal Unique Identifier, value type)로 정의된 컴퓨터가 읽을 수 있는 포맷

상기 LE 프로파일(46)은 GATT에 의존성을 가지는 profile 들로 주로 블루투스 LE 디바이스에 적용된다. LE 프로파일(46)은 예를 들면, Battery, Time, FindMe, Proximity, Time, Transport Discovery Service(TDS) 등이 있을 수 있다.

상기 일반 속성 프로파일(GATT, 44)은 서비스들의 구성 시에 상기 속성 프로토콜(43)이 어떻게 이용되는지를 설명하는 프로토콜로서 동작 가능할 수 있다. 예를 들어, 상기 일반 속성 프로파일(44)은 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작 가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작 가능할 수 있다.

따라서, 상기 일반 속성 프로파일(44) 및 상기 속성 프로토콜(ATT, 43)은 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.

BLE (Bluetooth Low Energy:BLE )

이하에서, 블루투스 저전력 에너지(Bluetooth Low Energy:BLE)에 대해 간략히 살펴보기로 한다.

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) 값뿐이다.

두 디바이스가 연결되어 있을 때, 두 디바이스들은 다른 역할로 활동한다.

마스터 역할을 수행하는 링크 계층은 마스터로 불리며, 슬레이브 역할을 수행하는 링크 계층은 슬레이브로 불린다. 마스터는 연결 이벤트의 타이밍을 조절하고, 연결 이벤트는 마스터와 슬레이브 간 동기화되는 시점을 말한다.

이하에서, 블루투스 인터페이스에서 정의되는 패킷에 대해 간략히 살펴보기로 한다. 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 Type	Packet Name
0000	ADV_IND
0001	ADV_DIRECT_IND
0010	ADV_NONCONN_IND
0011	SCAN_REQ
0100	SCAN_RSP
0101	CONNECT_REQ
0110	ADV_SCAN_IND
0111 - 1111	Reserved

광고 PDU(Advertising PDU)

아래 광고 채널 PDU 타입들은 광고 PDU로 불리고 구체적인 이벤트에서 사용된다.

ADV_IND: 연결 가능한 비지향성 광고 이벤트

ADV_DIRECT_IND: 연결 가능한 지향성 광고 이벤트

ADV_NONCONN_IND: 연결 가능하지 않은 비지향성 광고 이벤트

ADV_SCAN_IND: 스캔 가능한 비지향성 광고 이벤트

상기 PDU들은 광고 상태에서 링크 계층(Link Layer)에서 전송되고, 스캐닝 상태 또는 개시 상태(Initiating State)에서 링크 계층에 의해 수신된다.

스캐닝 PDU(Scanning PDU)

아래 광고 채널 PDU 타입은 스캐닝 PDU로 불리며, 하기에서 설명되는 상태에서 사용된다.

SCAN_REQ: 스캐닝 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.

SCAN_RSP: 광고 상태에서 링크 계층에 의해 전송되며, 스캐닝 상태에서 링크 계층에 의해 수신된다.

개시 PDU(Initiating PDU)

아래 광고 채널 PDU 타입은 개시 PDU로 불린다.

CONNECT_REQ: 개시 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.

데이터 채널 PDU(Data Channel PDU)

데이터 채널 PDU는 16 비트 헤더, 다양한 크기의 페이로드를 가지고, 메시지 무결점 체크(Message Integrity Check:MIC) 필드를 포함할 수 있다.

앞에서 살펴본, BLE 기술에서의 절차, 상태, 패킷 포맷 등은 본 명세서에서 제안하는 방법들을 수행하기 위해 적용될 수 있다.

도 4는 본 발명의 일 실시예에 따른 디바이스의 내부 블록도를 나타낸다.

상기 도 4에 도시된 바와 같이, 상기 제 1 디바이스(200) 및 상기 제 2 디바이스(300)는 네트워크 인터페이스(Network Interface, 210, 310), 출력부(220, 320), 입력부(230, 330), 제어부(240, 340), 멀티미디어 모듈(250, 350), 제1 저장부(260, 360) 및/또는 제2 저장부(270, 370)를 포함할 수 있다.

상기 도 4에 표시된 디바이스의 내부 블록도는 다른 구성 요소(모듈, 블록, 부)를 더 포함할 수도 있고, 상기 도 4의 구성 요소 중 일부가 생략될 수도 있다.

상기 네트워크 인터페이스(Network Interface, 210, 310), 상기 출력부(220, 320), 입력부(230, 330), 제어부(240, 340), 멀티미디어 모듈(250, 350), 제1 저장부(260, 360) 및/또는 제2 저장부(270, 370)는 본 명세서에서 제안하는 방법을 수행하기 위해서 기능적으로 연결되어 있다.

상기 네트워크 인터페이스(210, 310)는 다양한 네트워크 기술(또는 수단)을 이용하여 디바이스들간의 데이터 전송이 가능한 유닛(또는 모듈)을 말한다.

상기 네트워크 인터페이스(210, 310)는 다시 에너지 효율 인터페이스(212, 312) 및/또는 외부 인터페이스(214, 314)를 포함할 수 있다.

상기 에너지 효율 인터페이스(212, 312)는 저 전력 무선 통신을 위한 네트워크 기술을 사용하는 유닛(또는 모듈)로써, 연결하고자 하는 다른 디바이스를 검색하거나 데이터 전송을 할 수 있다(예를 들면, BLE(Bluetooth Low Energy)).

상기 외부 인터페이스(214, 314)는 상기 에너지 효율 인터페이스(212, 312)외의 무선 통신을 위한 인터페이스(또는 무선 통신 수단)를 말한다.

본 발명에서, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 상기 에너지 효율 인터페이스(212, 312)를 통해서 상기 외부 인터페이스(214, 314)의 연결을 위한 정보를 송수신 할 수 있으며, 이를 통해서 상기 외부 인터페이스(214, 314)의 연결 절차를 수행할 수 있다.

상기 출력부(220, 320)는 디바이스의 상태 정보 및 메시지 교환 정보 등을 화면을 통해서 사용자에게 제공하기 위한 모듈을 말한다.

상기 입력부(230, 330)는 화면 버튼과 같이 사용자의 입력을 상기 제어부(240, 340)에게 제공하여 디바이스의 동작을 사용자가 제어할 수 있게 하는 모듈을 말한다.

상기 멀티미디어 모듈(250, 350)은 다양한 종류의 멀티미디어 재생을 위한 모듈을 말하며, 상기 멀티미디어 모듈은 상기 제어부(240, 340)내에 구현될 수도 있으며, 상기 제어부(240, 340)와는 별도로 구현될 수 있다.

상기 제1 저장부(260, 360)는 다양한 종류의 데이터를 저장할 수 있는 비 휘발성 물리적 장치를 말한다.

상기 제2 저장부(270, 370)는 다양한 종류의 데이터가 임시적으로 저장되는 휘발성 성격을 물리적 장치를 말한다.

상기 도 4에는 도시 되지 않았지만, 상기 제1 디바이스(200) 및 상기 제 2 디바이스(300)는 전원 공급부를 포함할 수 있으며, 상기 전원 공급부는 제어부의 제어 하에 외부의 전원 및/또는 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급할 수 있다.

앞서 살펴본 것처럼, BLE 기술에서는 작은 duty cycle을 가지며, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있어, 상기 전원 공급부는 적은 출력 전력으로도(10mW(10dBm)이하) 각 구성요소들의 동작에 필요한 전원을 공급할 수 있다.

블루투스 LE에서 connection procedure(연결 절차)에 대해 간략히 살펴보고, 이 일례로서, 블루투스 LE에서 객체 전송 서비스를 제공하는 방법을 살펴보기로 한다.

도 5는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.

서버는 클라이언트로 3개의 광고 채널을 통해 광고 메시지를 전송한다(S510).

상기 서버는 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)를 상기 서버로 전송한다(S520).

이를 통해, 상기 서버와 클라이언트 간에 Link Layer(LL)의 연결이 확립(establish)된다.

이후, 상기 서버와 상기 클라이언트는 보안 설립 절차를 수행한다.

상기 보안 설립 절차는 Secure Simple Pairing으로 해석되거나 이를 포함하여 수행될 수 있다.

즉, 상기 보안 설립 절차는 Phase 1 단계 내지 Phase 3 단계를 거쳐 수행될 수 있다.

구체적으로, 서버와 클라이언트 간에 페어링 절차(Phase 1)를 수행한다(S530).

상기 페어링 절차는 클라이언트가 서버로 페어링 요청(Pairing Request)을 전송하고, 서버가 클라이언트로 페어링 응답(Pairing Response)을 전송한다.

다음, Phase 2로서, 서버와 클라이언트 간에 레거시 페어링(Legacy Pairing) 또는 Secure Connections를 수행한다(S540).

다음, SSP Phase 3으로서, 서버와 클라이언트 간에 키 분배(Key Distribution) 절차를 수행한다(S550).

이를 통해, 서버와 클라이언트 간에 보안 연결이 확립되고, 암호화된 데이터를 송수신할 수 있게 된다.

도 6은 블루투스 저전력 에너지 기술에서 데이터를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.

객체 전송 서비스(Object Delivery Service or Object Transfer Service)는 블루투스 통신에서 벌크 데이터(bulk data)와 같은 객체 또는 데이터를 송/수신하기 위해 BLE에서 지원하는 서비스를 말한다.

서버 디바이스와 클라이언트 디바이스 간에 블루투스 연결 설정을 위해 광고 과정 및 스캐닝 과정이 진행된다.

먼저, 서버 디바이스는 상기 서버 디바이스 관련 정보를 알리기 위해 클라이언트 디바이스로 광고 메시지를 전송한다(S610).

상기 광고 메시지는 광고 PDU(PACKet Data Unit), 광고 패킷, 광고, 광고 프래임, 광고 물리 채널 PDU 등으로 표현될 수 있다.

상기 광고 메시지는 서버 디바이스에서 제공하는 서비스 정보(서비스 이름 포함), 서버 디바이스의 이름, 제조자 데이터 등을 포함할 수 있다.

또한, 상기 광고 메시지는 브로드캐스트 방식 또는 유니캐스트(unicast) 방식으로 상기 클라이언트 디바이스로 전송될 수 있다.

이후, 상기 클라이언트 디바이스는 서버 디바이스 관련 보다 자세한 정보를 알기 위해 스캔 요청(Scan Request) 메시지를 상기 서버 디바이스로 전송한다(S620).

상기 스캔 요청 메시지는 스캐닝(Scanning) PDU, 스캔 요청 PDU, 스캔 요청, 스캔 요청 프래임, 스캔 요청 패킷 등으로 표현될 수 있다.

이후, 상기 서버 디바이스는 상기 상기 클라이언트 디바이스로부터 수신된 스캔 요청 메시지에 대한 응답으로 스캔 응답(Scan Response) 메시지를 상기 클라이언트 디바이스로 전송한다(S630).

상기 스캔 응답 메시지에는 상기 클라이언트 디바이스에서 요청한 서버 디바이스 관련 정보가 포함된다.

광고 과정 및 스캐닝 과정이 종료하는 경우, 상기 서버 디바이스와 상기 클라이언트 디바이스는 S640~S670 단계에 해당하는 연결 개시(Initiating Connection) 과정, 데이터 교환(Data Exchange) 과정을 수행한다.

구체적으로, 상기 클라이언트 디바이스는 상기 서버 디바이스와 블루투스 통신 연결을 위해 상기 서버 디바이스로 연결 요청(Connect Request) 메시지를 전송한다(S640).

상기 연결 요청 메시지는 연결 요청 PDU, 개시(Initiation) PDU, 연결 요청 프래임, 연결 요청 등으로 표현될 수 있다.

S640 단계를 통해, 상기 서버 디바이스와 상기 클라이언트 디바이스 간에 블루투스 연결이 확립되며, 이후 상기 서버 디바이스와 상기 클라이언트 디바이스는 데이터를 교환하게 된다. 상기 데이터 교환 과정에서 데이터는 데이터 채널 PDU를 통해 송수신될 수 있다.

상기 클라이언트 디바이스는 데이터 채널(Data Channel) PDU를 통해 객체 데이터 요청을 상기 서버 디바이스로 전송한다(S650). 상기 데이터 채널 PDU는 데이터 요청 메시지, 데이터 요청 프래임 등으로 표현될 수 있다.

이후, 상기 서버 디바이스는 상기 클라이언트 디바이스에서 요청하는 (특정) 데이터를 데이터 채널 PDU를 통해 상기 클라이언트 디바이스로 전송한다(S660).

여기서, 상기 데이터 채널 PDU는 Attribute protocol에서 정의한 방식으로 상대 디바이스에게 데이터를 제공하거나 데이터 정보를 요청하기 위해 사용된다.

이후, 상기 서버 디바이스에서 데이터의 변경이 발생하는 경우, 상기 서버 디바이스는 데이터의 변경을 알리기 위해 상기 클라이언트 디바이스로 데이터 채널 PDU를 통해 데이터 변경 지시(Data Changed Indication) 정보를 전송한다(S670).

이후, 상기 클라이언트 디바이스는 변경된 데이터를 찾기 위해 상기 서버 디바이스로 변경된 객체 정보를 요청한다(S680).

이후, 상기 서버 디바이스는 상기 변경된 데이터 정보 요청에 대한 응답으로 상기 클라이언트 디바이스로 상기 서버 디바이스에서 변경된 데이터 정보를 전송한다(S690).

이후, 상기 클라이언트 디바이스는 상기 수신된 변경된 데이터 정보와 현재 상기 클라이언트 디바이스가 가지고 있는 데이터 정보와 비교 분석을 통해 변경된 데이터를 찾는다.

다만, 상기 클라이언트 디바이스는 변경된데이터를 찾을 때까지 S680 및 S690 단계를 반복적으로 수행한다.

이후, 상기 호스트 디바이스와 상기 클라이언트 디바이스 간에 연결 상태가 유지될 필요가 없는 경우, 상기 호스트 디바이스 또는 상기 클라이언트 디바이스는 해당 연결 상태를 종료(Disconnect)시킬 수 있다.

도 7은 블루투스 BR/EDR 기술에서 연결 절차 방법의 일 예를 나타낸 흐름도이다.

도 7에 도시된 바와 같이, 블루투스 BR/EDR에서의 연결 절차(connection procedure)는 아래와 같은 단계들로 구성될 수 있다.

상기 연결 절차는 페어링 절차(pairing procedure)로도 표현될 수 있다.

블루투스 페어링 절차(pairing procedure)는 대기 상태(Standby State)와 연결 상태(Connected State)로만 구분된다.

블루투스 페어링이 완료된 디바이스는 상기 연결 상태(Connected State)가 되고, 접속이 종료된 장치는 대기 상태(Standby State)로 동작한다.

또한, 블루투스 디바이스들은 특정 디바이스와 연결 절차를 통해 연결 되었다가, 이후 재 연결하기 위해 재 연결 절차를 수행할 수 있다.

재 연결 절차는 연결 절차와 동일한 절차를 통해 수행될 수 있다.

구체적으로, 마스터 디바이스는 전원이 입력되면 기본적으로 대기 상태에 진입한다.

이후, 블루투스를 연결하기 위해 주변 디바이스들을 발견하기 위한 인쿼리(Inquiry) 절차(S711)를 수행한다.

즉, 마스터 디바이스는 주변의 연결할 수 있는 디바이스(슬레이브)를 발견(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이라고 한다.)를 마스터 디바이스로 전송할 수 있다.

상기 인쿼리 절차를 통해서 주변의 연결 가능한 블루투스 디바이스를 찾아내면, 페이징 절차(S712)를 수행한다.

상기 페이징 절차(S712)는 상기 인쿼리 절차를 통해서 주변의 연결 가능한 블루투스 디바이스를 찾아내면, 어드레스와 클럭 정보 등으로 호핑 시퀸스를 동기화하여 실제 커넥션을 수행하는 단계를 말한다.

구체적으로, 상기 페이징 절차는 (1) 마스터 디바이스가 슬레이브 디바이스로 Page를 전송하는 단계, (2) 슬레이브 디바이스가 마스터 디바이스로 Slave Page Response를 전송하는 단계, (3) 마스터 디바이스가 슬레이브 디바이스로 Master Page Response를 전송하는 단계로 구분될 수 있다.

상기 인쿼리 절차와 상기 페이징 절차가 완료되면, 마스터 디바이스와 슬레이브 디바이스는 보안 설립(Security Establishment) 단계(S714)를 수행하고, 이후 L2CAP 연결 및 서비스 디스커버리(Service Discovery) 단계(S715)를 수행한다.

상기 보안 설립 단계를 수행하기 전에, 마스터 디바이스와 슬레이브 디바이스는 I(Input)/O(Output) 능력을 서로 교환한다(S713).

이는 I/O capability request와 I/O capability response를 통해 수행될 수 있다.

또한, 상기 보안 설립 단계는 후술할 Secure Simple Pairing 절차를 포함하거나 같은 의미로 해석될 수도 있다.

상기 L2CAP(Logical Link Control and Adaption Protocol)은 패킷 방식의 프로토콜로서 UDP 프로토콜과 비슷한 특징을 가지고 있다. 기본 최대 672byte의 패킷 사이즈를 가지지만 통신이 시작되면 최대 65,535 byte까지 변경이 가능하다.

상기 L2CAP연결 및 서비스 디스커버리 단계를 수행한 후, 마스터 디바이스는 사용자로부터 입력받은 데이터를 슬레이브 디바이스로 전송할 수 있다(S716).

이와 같은 연결 절차를 수행한 마스터 디바이스와 슬레이브 디바이스는 일정 시간 동안 서로 간의 데이터 교환이 없게 되면, 에너지 소모를 방지하기 위하여 슬립(Sleep) 상태로 전환되며, 연결 상태는 종료하게 된다.

이후, 마스터 디바이스와 슬레이브 디바이스가 다시 데이터를 송/수신하기 위해서는 재 연결 절차를 수행한다.

재 연결 절차는 앞서 살핀 연결 절차와 동일한 단계를 통해 수행될 수 있다.

도 8은 디바이스의 무선 통신 인터페이스 구조의 일 예를 나타낸다.

도 8을 참조하면, 본 발명에서 상기 제 1 디바이스 (200)와 상기 제 2 디바이스 (300)는 BLE 모듈을 제외한 모든 무선 통신 인터페이스를 슬립(Sleep) 상태로 설정한 채 동작할 수 있다.

구체적으로 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE, Wi-Fi Direct, WiGig, Bluetooth BR/EDR, Wi-Fi 등과 같은 다양한 무선 통신 인터페이스(또는 수단)를 포함하고 있다.

상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 상기 다양한 무선 통신 인터페이스 중 BLE를 제외한 나머지 무선 통신 인터페이스는 슬립(Sleep) 상태로 설정되어 있다.

이때, 상기 제 1 디바이스(200) 또는 상기 제 2 디바이스(300)가 Wi-Fi Direct, WiGig, Bluetooth BR/EDR 등과 같은 무선 통신 인터페이스를 사용하고자 하는 경우, 상기 BLE를 통해서 사용하고자 하는 무선 통신 인터페이스의 Capability 정보를 교환하여 무선 통신 인터페이스를 연결할 수 있다.

예를 들면, 상기 제 1 디바이스(3000)가 Wi-Fi Direct를 이용하여 Miracast, 또는 Print와 같은 서비스를 수행하고자 하는 경우, 상기 제 1 디바이스(200)는 상기 제 2 디바이스(300)의 Wi-Fi Direct의 사용 가능 여부를 BLE를 통하여 협상(Negotiation)한 뒤, Wi-Fi Direct의 연결에 필요한 정보들을(예를 들어, 청취 채널(Listen Channel), BSSID, IEEE MAC addr) 교환할 수 있다.

이후, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 상기 교환된 정보들에 기초하여 Wi-Fi Direct 연결을 수행할 수 있다.

또한, 상대 디바이스의 무선 통신 인터페이스에 대한 Capability 정보를 검색할 수 있음과 동시에 상기 무선 통신 인터페이스에 대한 Enable, Disable 또는 Connection과 같은 제어도 가능할 수 있으며, 연결된 후에는 연결된 무선 통신 인터페이스를 통해 실제 데이터를 송수신할 수 있다.

이와 같은 방법을 통해서, 무선 통신 인터페이스가 사용되지 않는 경우에는 상기 BLE를 제외한 무선 통신 인터페이스를 슬립 상태로 둘 수 있어 모든 무선 통신 인터페이스가 웨이크업 상태에 있는 경우보다 소비 전력을 감소 시킬 수 있다.

또한, BLE 를 통해 무선 통신 인터페이스의 연결 정보를 획득할 수 있으므로 무선 통신 인터페이스의 연결 절차 및 시간을 줄일 수 있다.

도 9는 무선 통신 인터페이스의 정보를 제공하는 방법의 일 예를 나타낸 흐름도 이다.

도 9를 참조하면, 제 1 디바이스(200)는 제 2 디바이스(300)로부터 상기 제 2 디바이스(300)에 포함된 무선 통신 인터페이스와 관련된 정보를 전송 받고, 필요에 따라 상기 제 1 디바이스(200)는 상기 제 2 디바이스(300)에게 상세 정보를 요청하여 정보를 제공받을 수 있는 프로토콜(Protocol) 형태의 방법이다.

구체적으로, 상기 제 2 디바이스(300)는 BLE 기술을 통해서 상기 제 2 디바이스에 포함된 무선 통신 인터페이스의 정보를 상기 제 1 디바이스(200)에게 전송하며, 상기 제 1 디바이스(200)는 상기 제 2 디바이스(300)로부터 전송된 정보를 기초로 상기 제 2 디바이스(300)가 지원 가능한 무선 통신 인터페이스의 정보를 획득할 수 있다.

상기 제 2 디바이스(300)가 상기 제 1 디바이스(200)에게 전송하는 무선 통신 인터페이스의 정보는 비트 마스크(Bit Mask) 형태로 전송될 수 있다.

상기 비트 마스크 형태는 상기 제 2 전자기기(300)가 어떤 무선 통신 인터페이스를 지원하는지, 어떤 서비스에 대한 지원이 가능한지가 비트(bit)형태로 나타나 있다.

아래 표 2은 상기 비트 마스크 형태의 일 예를 나타내고 표 3은 각 비트가 나타내는 무선 인터페이스 종류의 일 예를 나타낸다.

7th bit	6th bit	5th bit	4th bit	3rd bit	2nd bit	1st bit
0	1	0	1	1	1	0

Bit	Network Interface
1st bit	Wi - Fi
2nd bit	Wi - Fi Direct
3rd bit	WFDS Print
4th bit	WFDS Display
5th bit	Wi - Fi Display
6th bit	NFC
7th bit	Classic Bluetooth
8th bit	WiGig
9th bit	Zigbee
10th bit	Future Interface

상기 표 2의 비트 마스크의 각 비트 값을 통해 상기 제 2 디바이스(300)는 자신이 지원 가능한 무선 인터페이스 또는 서비스를 상기 제 1 디바이스(200)에게 알릴 수 있다.

즉, 상기 표 2에서 2번째, 3번째, 4번째, 6번째 비트의 값이 1이므로, 상기 제 2 디바이스(300)는 상기 제 1 디바이스(200)에게 Wi-Fi Direct, WFDS Print, WFDS Display, NFC를 지원할 수 있다는 것을 알려줄 수 있다.

상기 무선 인터페이스의 정보를 수신한 상기 제 1 디바이스(200)는 무선 인터페이스에 대한 상세 정보(또는 추가 정보)가 필요한 경우, 상기 제 2 디바이스(300)에게 무선 통신 인터페이스에 대한 상세 정보(또는 추가 정보)를 요청할 수 있다.

상기 제 1 디바이스(200)로부터 상세 정보 요청을 받은 상기 제 2 디바이스(300)는 요청 받은 무선 통신 인터페이스에 대한 상세 정보(또는 추가 정보)를 상기 제 1 디바이스에게 전송할 수 있다.

상기 상세 정보는 무선 인터페이스의 정보 또는 무선 인터페이스가 제공하는 서비스의 상세 정보(또는 추가 정보)가 포함될 수 있다.

도 10은 무선 통신 인터페이스 관련 세부 정보를 포함하는 데이터 포맷의 일 예를 나타낸 도이다.

도 10을 참조하면, 상기 세부 정보는 정보의 종류를 나타내는 정보 타입 필드와 정보의 상세 정보를 포함하고 있는 상세 정보 필드로 구성되어 있다. 예를 들어, 상기 제 1 디바이스(200)가 상기 제 2 디바이스(300)에게 Classic Bluetooth의 상세 정보를 요청한 경우, 상기 제 2 디바이스(300)는 상기 도 10의 데이터 포맷을 사용하여 상기 제 1 디바이스(200)에게 상기 Classic Bluetooth의 상세정보를 전송할 수 있다.

구체적으로, 상기 제 2 디바이스(300)가 상기 제 1 디바이스(200)에게 Classic Bluetooth 연결을 위한 Address 및 디바이스 종류에 대한 상세 정보를 전송하고자 하는 경우, 상기 정보 타입에 Address 또는 디바이스의 Type의 정보라는 것을 나타내는 값이 포함되고, 상기 상세 정보에는 Adress 값 또는 디바이스 Type을 나타내는 값이 포함될 수 있다.

아래 표 4은 상기 상세 정보를 구성하는 파라미터의 일 예를 나타낸다.

Parameter	Description
Device Address value	Device를 구별해주는 unique ID 값
Device Address type	어떤 종류의 무선 인터페이스에 해당하는 Address인지를 구별
Device Address length	Device Address value의 길이
Device Class	장치가 어느 장치부류에 속하는지를 가리킨다. (ex: Print, Head set 등)
Security Information	Pairing 시 보안을 위하여 주고 받는 정보
Synch Code	두 장치의 Synch를 맞추기 위해 주고 받는 값
Scan Window Interval	장치가 다른 장치들이 보내는 신호를 수신하기 위하여 Listening하는 주기를 나타냄
Link Address	두 장치 사이의 무선 연결이 이루어진 경우 Link를 구별하는 ID 값
Clock	장치의 Native Clock
Scan Mode	장치가 다른 장치들이 보내는 신호를 수신하기 위하여Listening하는 패턴을 나타냄.
Connection Start	특정 무선 인터페이스를 이용한 장치간의 연결을 지시하는 명령
Number of connections	특정 무선 인터페이스에 연결되어 있는 기기의 수
Device Status	특정 무선 인터페이스의 on/off 상태 등 기기 상태
Carrier Bitmask	기기가 가진 무선 인터페이스의 종류를 나타내는 값
Listen Channel	검색 단계에서 P2P가 서로의 데이터를 교환하는 채널
Channel Class	Wi-Fi 등에서 사용되는 주파수 대역 (2.4GHz / 5GHz / 60GHz)
SSID	무선 기기와 AP 간에 접속용 식별자
P2P Capability	P2P Group에 연결이 가능한지 여부를 나타냄
Configuration Method	External Interface 에 종족적인 연결 방법 (e.g., WSCIE (Wi-Fi))
Supported Rate	Tx Rate
Peer addr	Peer Device의 External Interface Address
Channel Information	Supported Channel List 또는 Channel Map 등, 전반적인 Channel에 관한 정보
Operating Channel	두 기기가 연결되어 데이터를 교환하는 채널
Connection Status	기기가 타 기기와 연결되어 있는지, 어떤 기기와 연결되어 있는지에 대한 정보
Active Period	인터페이스가 Active 상태와 Sleep 상태를 번갈아 가면서 동작할 경우 Active 상태인 시간 값
Sleep Period	인터페이스가 Active 상태와 Sleep 상태를 번갈아 가면서 동작할 경우 Sleep 상태인 시간 값
Packet Transmission Interval	인터페이스가 주기적으로 packet을 보내도록 설정되어 있을 경우 두 packet 사이의 시간 값
Service UUID(Universal Unique Identifier)	디바이스 및 각 인터페이스가 제공하는 서비스들에 대한 UUID

이와 같은 비트 마스크 형태로 정보를 전송할 경우, 전체 패킷(Packet)의 길이를 줄여 에너지 효율을 높이는 효과를 발생시킬 수 있다.

무선 통신 인터페이스의 정보를 제공하는 방법의 또 다른 일 예를 살펴본다.

구체적으로 상기 제 1 디바이스(200) 또는 상기 제 2 디바이스(300)는 각 디바이스가 지원하는 무선 통신 인터페이스에 대한 정보를 데이터 스트림을 통해 교환할 수 있다.

상기 데이터 스트림은 헤더(Header) 부분과 페이로드(Payload) 부분으로 나뉜다.

상기 헤더(Header) 부분에는 상기 무선 통신 인터페이스의 요약 정보가 포함되며, 페이로드 부분에는 각 무선 통신 인터페이스의 상세 정보가 포함된다.

상기 요약 정보는 각 디바이스가 지원 가능한 무선 통신 인터페이스의 개수 정보 및/또는 각 무선 통신 인터페이스의 상세 정보가 위치하는 오프셋(Offset) 값이 포함된다.

즉, 상기 헤더 부분에 상기 무선 통신 인터페이스의 요약 정보뿐만 아니라, 디바이스가 지원 가능한 무선 통신 인터페이스의 개수 정보가 포함되어 있다.

상기 인터페이스의 요약 정보는 각 무선 통신 인터페이스에 대한 정보 오프셋들로 구성되어 있으며, 각 정보 오프셋들은 인터페이스 인티케이터(Interface Indicator) 필드와 상세 정보 위치 오프셋 필드로 구성되어 있다.

상기 인터페이스 인디케이터 필드는 각 디바이스에 포함되어 있는 무선 통신 인터페이스 종류와 관련된 정보가 포함되어 있고, 상기 상세 정보 위치 오프셋 필드는 특정 무선 인터페이스의 세부정보가 페이로드의 어느 위치에 포함되어 있는지에 대한 정보가 포함되어 있다.

상기 페이로드 부분은 무선 통신 인터페이스 상세 정보 필드들로 구성되어 있으며, 각각의 무선 통신 인터페이스 상세 정보 필드는 정보의 종류를 나타내는 정보 타입 필드와 상기 정보의 종류에 해당하는 상세 정보를 포함하는 필드로 구성되어 있다.

상기 상세 정보 필드는 상기 표 3에 도시된 파라미터들이 포함될 수 있다.

도 11은 블루투스의 GATT(Generic Attribute Profile) 구조를 나타낸 도이다.

블루투스 GATT는 두 BLE 장치간에 서비스(Service), 특성(Characteristic)을 이용해서 데이터를 주고 받는 방법을 정의한 것이다.

상기 GATT를 통해, 서버 디바이스에서 클라이언트 디바이스로, 클라이언트 디바이스에서 서버 디바이스로 특성에 대한 데이터를 전송할 수 있는 명령이 제공된다. 이는 특성의 UUID를 지정하거나 정보 검색 명령에서 제공되는 핸들 값을 통해 값을 읽을 수 있다.

또한, GATT는 알림 및 표시를 제공할 수 있다. 클라이언트 디바이스는 서버 디바이스에서 특정 특성에 대한 알림을 요청할 수 있으며, 서버 디바이스는 사용 가능할 때마다 해당 값을 클라이언트 디바이스에 전송할 수 있다.

도 11을 참조하면, 하나의 Profile은 여러 개의 서비스(Service)로 구성되어 있으며, 각각의 서비스는 다수의 특성으로 구성되어 있다.

하나의 특성은 하나의 값과 n개의 디스크립터(Descriptor)를 포함하고, 각각의 디스크립터는 특성의 값을 기술한다.

도 11은 GATT 구조에 포함되어 있는 정보의 형태를 나타내는 것으로써, 서비스(Service)와 특성(Characteristic)으로 나누어져 있다.

상기 서비스(Service)는 상기 서비스의 타입을 나타내는 Attribute Type, 서비스 UUID 및/또는 상기 서비스의 정보를 읽기만 할 수 있는지 수정할 수 있는지를 나타내는 Attribute Permission 값을 포함하고 있다.

상기 특성(Characteristic)은 상기 서비스에 대한 각각의 특성 값을 정의하고 있다. 구체적으로 각각 특성에 대한 타입(Type), UUID 및/또는 Attribute Permission 값을 포함하고 있다.

본 발명에서는 무선 통신 인터페이스에 대한 정보가 상기 GATT 구조로 디바이스에 저장되어 있으며, 상기 저장되어 있는 GATT 구조의 정보를 상대방 디바이스로부터 읽어오거나, 전송 받을 수 있다.

아래 표 5는 본 발명의 블루투스 GATT 구조에서 사용되는 특성(Characteristic) 값의 일 예를 나타낸다.

Parameter	Description
Device Address value	Device를 구별해주는 unique ID 값
Device Address type	어떤 종류의 무선 인터페이스에 해당하는 Address인지를 구별
Device Address length	Device Address value의 길이
Device Class	장치가 어느 장치부류에 속하는지를 가리킨다. (ex: Print, Head set 등)
Security Information	Pairing 시 보안을 위하여 주고 받는 정보
Synch Code	두 장치의 Synch를 맞추기 위해 주고 받는 값
Scan Window Interval	장치가 다른 장치들이 보내는 신호를 수신하기 위하여 Listening하는 주기를 나타냄
Link Address	두 장치 사이의 무선 연결이 이루어진 경우 Link를 구별하는 ID 값
Clock	장치의 Native Clock
Scan Mode	장치가 다른 장치들이 보내는 신호를 수신하기 위하여Listening하는 패턴을 나타냄.
Connection Start	특정 무선 인터페이스를 이용한 장치간의 연결을 지시하는 명령
Number of connections	특정 무선 인터페이스에 연결되어 있는 기기의 수
Device Status	특정 무선 인터페이스의 on/off 상태 등 기기 상태
Carrier Bitmask	기기가 가진 무선 인터페이스의 종류를 나타내는 값
Listen Channel	검색 단계에서 P2P가 서로의 데이터를 교환하는 채널
Channel Class	Wi-Fi 등에서 사용되는 주파수 대역 (2.4GHz / 5GHz / 60GHz)
SSID	무선 기기와 AP 간에 접속용 식별자
P2P Capability	P2P Group에 연결이 가능한지 여부를 나타냄
Configuration Method	External Interface 에 종족적인 연결 방법 (e.g., WSCIE (Wi-Fi))
Supported Rate	Tx Rate
Peer addr	Peer Device의 External Interface Address
Channel Information	Supported Channel List 또는 Channel Map 등, 전반적인 Channel에 관한 정보
Operating Channel	두 기기가 연결되어 데이터를 교환하는 채널
Connection Status	기기가 타 기기와 연결되어 있는지, 어떤 기기와 연결되어 있는지에 대한 정보
Active Period	인터페이스가 Active 상태와 Sleep 상태를 번갈아 가면서 동작할 경우 Active 상태인 시간 값
Sleep Period	인터페이스가 Active 상태와 Sleep 상태를 번갈아 가면서 동작할 경우 Sleep 상태인 시간 값
Packet Transmission Interval	인터페이스가 주기적으로 packet을 보내도록 설정되어 있을 경우 두 packet 사이의 시간 값

ATT 구조의 무선 통신 인터페이스 정보를 통해서 다른 디바이스의 무선 통신 인터페이스의 정보를 읽어올 수 있으며, 읽어온 상기 무선 통신 인터페이스 정보를 기초로 상기 무선 통신 인터페이스의 연결 절차를 수행할 수 있다.

도 12는 블루투스 LE 연결 과정을 통해서 무선 통신 인터페이스의 정보를 제공하는 방법 및 데이터 포맷의 일 예를 나타낸 흐름도이다.

두 디바이스가 BLE 페어링(Pairing)을 위한 Advertising 과정을 통해서 BLE 외의 무선 통신 인터페이스의 정보를 요청 및 제공받을 수 있다.

구체적으로, 상기 제 1 디바이스(200)는 BLE 페어링 전에 스캐닝 상태(Scanning State)로 존재하며, 상기 제 2 디바이스(300)는 광고 상태(Advertising State)로 존재한다.

상기 광고 상태에 있는 상기 제 2 디바이스(300)는 BLE 연결 절차를 수행하기 위해서 Advertising Channel을 통해 광고 메시지(Advertising message)를 상기 제 1 디바이스(200)에게 전송할 수 있다(S1210).

상기 광고 메시지는 주변의 BLE 기능을 가진 디바이스들에게 상기 제 2 디바이스(300)를 알리기 위해 사용되며, 가능한 무선 통신 인터페이스의 정보가 포함될 수 있다.

상기 광고 메시지에 포함된 상기 무선 통신 인터페이스의 정보는 비트 마스크(Bit_Mask)형태 또는 데이터 스트림의 인터페이스 요약 정보가 포함될 수 있다.

상기 도 13의 (a)는 상기 광고 메시지의 PDU(Packet Data Unit)의 일 예를 나타낸 것으로써, 상기 제 2 디바이스(300)의 무선 통신 인터페이스의 정보가 비트 마스크 형태로 포함되어 있는 것을 살펴볼 수 있다.

상기 AdvA 필드는 상기 광고 메시지의 PDU가 어떤 타입의 PDU인지를 나타내는 값이 포함되어 있으며, 본 실시예에서 광고 메시지의 PDU는 아래 타입의 PDU가 될 수 있다.

- ADV_IND

- ADV_NONCONN_IND

- ADV_SCAN_IND

- EXTENDED_ADV_IND

- LONG_ADV_NONCONN_IND

위의 EXTENDED_ADV_IND 및 LONG_ADV_NONCONN_IND는 데이터 길이가 확장된 상기 ADV_IND 및 ADV_NONCONN_IND 타입이다.

상기 AdvData 필드는 상기 무선 통신 인터페이스의 정보가 포함되는 것으로써, 정보 유형을 나타내는 Type 필드와 상기 Type에 해당되는 정보 값이 포함되는 Bitmask 필드를 포함한다.

상기 Type 필드는 Supported Tech, Status 또는 Availability 정보 중 하나가 포함될 수 있다. 상기 Supported Tech 필드는 지원 가능한 무선 통신 인터페이스 정보를 포함하고, 상기 Status 필드는 지원 가능한 무선 통신 인터페이스의 동작 상태 정보를, 상기 Availability 필드는 상기 지원 가능한 무선 통신 인터페이스가 이용가능한지 여부와 관련된 정보를 포함할 수 있다.

상기 광고 메시지를 통해서 상기 제 2 디바이스(300)가 지원 가능한 무선 통신 인터페이스가 무엇인지 확인한 상기 제 1 디바이스(200)는 상기 확인된 무선 통신 인터페이스 또는 무선 인터페이스의 정보 중에서 상세 정보가 필요한 경우, 상기 제 2 디바이스(300)에게 무선 통신 인터페이스에 대한 정보를 스캔 요청을 통해 요청한다(S1220).

상기 스캔 요청 PDU는 상기 표 1의 타입 중에서 SCAN_REQ 타입을 가질 수 있으며, 또는 상기 SCAN_REQ의 확장 형태인 LONG_SCAN_REQ 타입을 가질 수 있다.

상기 제 2 디바이스(300)는 요청 받은 무선 통신 인터페이스의 상세 정보를 스캔 응답을 통해서 상기 제 1 디바이스(200)에게 전송할 수 있다(S1230).

상기 도 13의 (b)는 상기 스캔 응답 메시지의 PDU(Packet Data Unit)의 일 예를 나타낸 것으로써, 상기 제 2 디바이스(300)의 무선 통신 인터페이스 상세정보가 상기 스캔 응답 메시지의 PDU에 포함되어 있는 것을 살펴볼 수 있다.

상기 스캔 응답 메시지의 PDU는 AdvA 필드 및 ScanRspData 필드를 포함하고 있다.

상기 AdvA 필드는 상기 스캔 응답 PDU의 타입을 나타내는 것으로써, 상기 표 1의 타입 중에서 SCAN_RSP 타입을 가질 수 있으며, 또는 상기 SCAN_RSP 타입의 확장 형태인 LONG_SCAN_RSP 타입을 가질 수 있다.

상기 ScanRspData 필드는 상기 제 1 디바이스(200)가 요청한 상기 무선 통신 인터페이스의 정보 종류를 나타내는 Type 필드와 상기 정보 종류의 상세 정보를 포함하고 있는 Data 필드를 포함하고 있다.

상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 상기 전송된 상세 정보에 기초하여 상기 무선 통신 인터페이스의 커넥션 절차를 수행할 수 있다(S1240).

도 14는 BLE를 통해서 무선 통신 인터페이스의 정보를 제공하는 방법의 일 예를 나타낸 흐름도이다.

디바이스간 BLE 연결을 통해서 BLE 외의 무선 통신 인터페이스의 정보를 교환하여 커넥션을 형성할 수 있다.

구체적으로 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 앞에서 설명한 BLE 커넥션(또는 Pairing) 절차를 수행하여 BLE 커넥션을 형성한다(S1410).

상기 BLE 커넥션을 형성한 상기 제 1 디바이스(200)는 마스터 디바이스(Master Device)로 동작하게 되고, 상기 제 2 디바이스(300)는 슬레이브 디바이스(Slave Devcie)로 동작하게 된다.

상기 마스터 디바이스와 상기 슬레이브 디바이스의 역할은 상황에 따라 변경될 수 있다.

상기 BLE 커넥션을 형성한 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE와는 다른 무선 통신 인터페이스를 연결하고자 하는 경우, 상기 BLE를 통해서 무선 통신 인터페이스의 정보를 교환할 수 있다(S1420).

이때, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 GATT Profile 등 상기 무선 통신 인터페이스의 정보를 교환할 수 있다.

이후, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 시작 커맨드를 교환하고(S1430), 교환한 정보를 기초로 상기 무선 통신 인터페이스의 연결 절차를 수행하게 된다.

도 15는 BLE를 이용하여 무선 통신 인터페이스의 정보를 제공하는 방법의 일 예를 나타낸 흐름도이다.

두 디바이스가 BLE 페어링(Pairing)을 위한 광고 절차(Advertising Procedure)를 통해서 간단한 무선 통신 인터페이스의 정보를 교환한 뒤, 상기 무선 통신 인터페이스의 상세정보가 필요한 경우, BLE 페어링(Pairing) 후에 상기 무선 통신 인터페이스의 상세 정보를 교환할 수 있다.

구체적으로 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE 페어링 절차를 수행하지 않아 BLE 연결이 되어있지 않고, 상기 제 1 디바이스(200)는 스캐닝 상태(Scanning State)로, 상기 제 2 디바이스(300)는 애드버타이징 상태(Advertising State)로 존재한다.

상기 제 2 디바이스(300)는 광고 메시지의 PDU를 통해서 상기 제 1 디바이스(200)에게 자신이 지원 가능한 무선 통신 인터페이스의 정보를 교환할 수 있다(S1510).

상기 무선 통신 인터페이스의 정보를 교환한 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE 페어링 절차를 수행하여, BLE 링크를 형성할 수 있다(S1520).

이후, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 상기 무선 통신 인터페이스의 상세 정보가 필요한 경우, BLE 링크를 통해서 상기 무선 통신 인터페이스의 상세 정보를 교환할 수 있다(S1530).

상기 무선 통신 인터페이스의 상세 정보를 교환한 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 시작 커맨드를 교환한 뒤(S1540), 상기 무선 통신 인터페이스의 정보에 기초하여 상기 무선 통신 인터페이스의 연결 절차를 수행할 수 있다.

본 명세서에서 적용 가능한 방법들에 사용가능한 데이터 포맷에 대해 살펴본다.

본 명세서에서 사용되는 광고 메세지의 PDU의 또 다른 두 가지 실시예를 살펴볼 수 있다.

광고 메시지의 PDU는 AdvData 필드는 Service Data 필드, SDO ID/SIG ID 필드, Length 필드를 포함할 수 있다.

상기 SDO ID/SIG ID 필드는 무선 통신 인터페이스의 종류를 나타내며, Length 필드는 PDU 필드 또는 Common Header 필드와 SDO Specific Contents 필드의 전체적인 길이를 나타낸다.

아래 표 6는 상기 SDO ID/SIG ID에 포함될 수 있는 무선 통신 인터페이스 종류의 일 예를 나타낸다.

SDO/SIG ID	Description
1	Wi - Fi
2	Wi - Fi Direct
3	WFDS Print
4	WFDS Display
5	Wi - Fi Display
6	NFC
7	Classic Bluetooth
8	WiGig
9	Zigbee
10	Future Interface

AdvData 필드는 PDU 필드를 더 포함할 수 있다.

상기 PDU 필드는 무선 통신 인터페이스의 간단한 정보를 포함하는 필드로써, 상기 무선 통신 인터페이스의 종류에 따라 다른 정보를 포함한다.

만약 상기 무선 통신 인터페이스가 블루투스 BR/EDR인 경우, 상기 PDU 필드는 BR/EDR 헤더 필드 및 Entire Contents 필드를 포함한다.

상기 BR/EDR 헤더 필드는 무선 통신 인터페이스의 상세 정보가 어떤 메시지에 포함되어 있는지를 나타낸다.

아래 표 7는 상기 BR/EDR 헤더의 일 예를 나타낸다.

7th bit	6th bit	5th bit	4th bit	3rd bit	2nd bit	1st bit
MD1	MD0	TBD

아래 표 8은 상기 6번째 7번째 비트에 따른, 무선 통신 인터페이스의 상세 정보 위치의 일 예를 나타낸다.

6번째 비트 값	7번째 비트 값	상세 정보 위치
0	0	No More Data
0	1	More Data in Scan Response
1	0	More Data in GATT information
1	1	More Data in Scan response and GATT information

광고 PDU는 Common Header 필드 및 SDO Specific Content 필드를 더 포함한다.

상기 Common Header 필드는 상기 BR/EDR Header 필드와 동일한 포맷을 가지고 있으며, 상기 SDO Specific Content 필드는 무선 통신 인터페이스의 특정 정보를 얻기 위해 필요한 정보가 포함되어 있을 수 있다.

예를 들어, 상기 무선 통신 인터페이스가 블루투스 BR/EDR인 경우, 상기 SDO Specific Content에는 FHS(Frequency Hopping Synchronization) 정보가 포함되어 있을 수 있다.

이때, Service Data AD 필드는 인터페이스의 종류 별로 상기 Service Data AD 필드를 포함할 수 있고, 데이터 크기를 줄이기 위하여 하나의 Service Data AD 필드만 가장 처음 위치에 포함할 수 있다.

도 16은 블루투스 LE를 통해서 무선 통신 인터페이스의 정보를 제공하는 방법의 또 다른 일 예를 나타내는 흐름도이다.

무선 통신 인터페이스가 비활성화 되어있는 상태에서 블루투스 LE 연결단계를 통해 무선 통신 인터페이스의 간략한 정보를 교환하고, 블루투스 LE 연결 이후, 상위 레이어의 데이터 전송 방법을 통해 상기 무선 통신 인터페이스의 상세 정보를 교환할 수 있다.

구체적으로, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE 연결이 형성되어 있지 않는 상태이다.

상기 제 1 디바이스(200)는 주변의 다른 BLE 통신이 가능한 디바이스를 인식하기 위해서 스캐닝 상태(Scanning State)로 진입하고, 상기 제 2 디바이스(300)는 애드버타이징 상태(Advertising State)로 진입하게 된다.

이때, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)의 무선 통신 인터페이스는 비활성화 상태로 존재한다.

상기 스캐닝 상태의 제 1 디바이스(200)와 애드버타이징 상태의 상기 제 2 디바이스(300)는 지원 가능한 무선 통신 인터페이스의 정보를 BLE 연결이 되지 않은 상태에서 교환할 수 있다(S1610).

상기 무선 통신 인터페이스의 정보는 앞에서 살펴본 다양한 방법으로 교환될 수 있다.

이후, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE 연결 절차를 통해서 BLE 연결 상태로 진입하게 된다.

BLE 연결 상태에서 상기 제 1 디바이스(200)는 GATT data base에 저장된 상기 무선 통신 인터페이스의 상세 정보를 획득하기 위해 상기 제 2 디바이스(300)에게 GATT Read 요청을 전송한다(S1620).

상기 제 2 디바이스(300)는 상기 제 1 디바이스(200)로부터 요청 받은 정보를 GATT Read 응답을 통해 상기 제 1 디바이스(200)에게 전송할 수 있다(S1630).

상기 무선 통신 인터페이스의 정보는 GATT data base에 저장되어 있을 수 있다.

상기 무선 통신 인터페이스의 상세 정보가 포함된 GATT Read 응답을 수신한 상기 제 1 디바이스(200)는 Anchor Point 정보 또는 Delay Value 정보를 교환하기 위해 상기 제 2 디바이스(300)에게 GATT Write 요청을 전송하고(S1640), 상기 GATT Write 요청에 대한 응답으로 GATT Write 응답을 수신한다(S1650).

이때, 상기 Anchor Point 정보와 상기 Delay Value 정보는, 세 가지 방법으로 교환될 수 있다.

첫 번째로, 상기 제 1 디바이스(200)가 자신의 Anchor Point 정보 및/또는 Delay Value 정보를 GATT Write 요청에 포함시켜 상기 제 2 디바이스(300)에게 전송하고, 상기 제 2 디바이스(300)도 자신의 Anchor Point 정보 및/또는 Delay Value 정보를 GATT Write 응답에 포함시켜 상기 제 1 디바이스(200)에게 전송하여 Anchor Point 및/또는 Delay Value 정보를 공유한다.

두 번째로, 상기 제 1 디바이스(200)가 자신의 Anchor Point 정보 및/또는 Delay Value 정보를 GATT Write 요청에 포함시켜 상기 제 2 디바이스(300)에게 전송하고, 상기 제 2 디바이스(300)는 전송된 정보에 맞추어 Anchor Point 및/또는 Delay Value 값을 설정할 수 있다.

세 번째로, 상기 제 2 디바이스(300)가 자신의 Anchor Point 정보 및/또는 Delay Value 정보를 GATT Write 응답에 포함시켜 상기 제 1 디바이스(200)에게 전송하고, 상기 제 1 디바이스(200)는 전송된 정보에 맞추어 Anchor Point 및/또는 Delay Value 값을 설정할 수 있다.

상기 Anchor Point는 무선 통신 인터페이스의 연결 절차를 언제 시작할 것 인지와 관련된 정보이고, 상기 Delay Value는 상기 GATT Write 응답을 전송 또는 수신한 이후에 얼마 뒤에 무선 통신 인터페이스의 연결 절차를 시작할 것 인지와 관련된 정보이다.

상기 세 가지 방법 중 하나의 방법으로 Anchor Point 또는 Delay Value를 공유한 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 비활성화 되어 있는 무선 통신 인터페이스를 연결시키기 위해 활성화 시킨다.

이후, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 Anchor Point로 설정되어 있는 시기 또는 상기 GATT Write 응답의 수신/전송으로부터 Delay Value 만큼 지난뒤에 상기 무선 통신 인터페이스의 연결 절차를 수행하여(S1660), 상기 무선 통신 인터페이스의 연결 상태가 된다.

또한, 별도의 채널 맵 파라미터를 두어서 핸드오버 전의 채널맵을 기반으로 핸드오버 후에 채널 맵을 형성할지, 새롭게 채널 맵을 형성할 지 결정하여 효율적으로 채널 맵을 생성할 수 있다.

상기 채널 맵 파라미터는 핸드오버 전의 채널 맵을 기반으로 핸드오버 후에 채널 맵을 구성할지, 아니면 새롭게 채널 맵을 구성할지 여부를 나타낸다.

일예로서, 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE 커넥션을 형성하고 있다. 상기 BLE 커넥션을 형성한 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 BLE 통신을 위한 채널 맵을 형성하고 있을 수 있다.

이후, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 앞에서 설명한 실시예 중 하나를 통해 Bluetooth BR/EDR로 핸드오버 절차를 수행하여, Bluetooth BR/EDR 커넥션을 형성하게 된다.

이때, 상기 제 1 디바이스(200)와 상기 제 2 디바이스(300)는 상기 핸드오버 절차를 통해서 상기 채널 맵 파라미터 값을 교환한다.

상기 제 1 디바이스(200) 및 상기 제 2 디바이스(300)는 상기 채널 맵 파라미터의 값이 True로 셋팅되어 있으면, 핸드오버 전의 채널 맵을 기반으로 채널 맵을 구성하고, 상기 채널 맵 파라미터의 값이 Fasle 값으로 셋팅되어 있으면, 새로운 채널 맵을 구성하여 Bluetooth BR/EDR 통신을 수행하게 된다.

다음으로, TDS(Transport Discovery Service)에 대해 간략히 살펴보고, 본 명세서에서 제안하는 정보들 및 이를 전송하기 위한 방법으로, TDS 관련하여 살펴본다.

The Transport Discovery Service (TDS) enables a device using Bluetooth low energy wireless technology to expose services that are available on a transport other than Bluetooth low energy. The term 'transport' when used in the context of this specification describes a communication technology that can be used for data transfers between a Server and Client. When used together with a higher level specification (e.g., a specification which references and makes use of TDS), the information provided by this service can be used to facilitate discovery and utilization of BR/EDR or transports not defined by the Bluetooth SIG such as those defined by the Wi-Fi Allianceor other organizations. This service is designed such that it can be used by other organizations to describe their own transport and services using their own incremental requirements.

Service Advertising Data

This section defines the advertising data requirements for TDS.

Transport Discovery Data AD Type

This section describes the contents of and requirements for the Transport Discovery Data AD Type that enables a Client to determine the role of the device (i.e., whether it is seeking a service (Seeker) or providing a service (Provider) available on a specific transport), the organization and transport associated with the supported service and other information such as the transport state and other features.

The Transport Discovery Data AD Type shall be present in the Advertising Data (i.e., AdvData) and may also be present in the Extended Inquiry Response (EIR). EIR and Advertising Packets may be of different sizes and may contain different information within the Transport Discovery Data AD Type.

The definition of the Transport Discovery Data AD Type is shown in Table 9

Refer to Section 3.2 for details regarding byte ordering.

Fields		Data Type	Size (octets)	Requirement
Transport Discovery Data AD Type Code (Section 3.1.1)		uint8	1	M
Device Name (or Friendly Name)
Previous Connection Block
Encryption Block
Transport Block (1 or more) 26. (Section 3.1.2)	Organization ID (Section 3.1.2.1)	uint8	1	M
	Specific Tech Method
	TDS Flags (Section 3.1.2.2)	8bit	1	M
	Transport Data Length (Section 3.1.2.3)	uint8	1	M
	Transport Data (Section 3.1.2.4)	Variable	Variable (see Note 1)	O

Transport Discovery Data AD Type

Note 1: Typically 0-26 (inclusive of the Flags AD Type), however larger values may be supported in future updates of the Core Specification.

Transport Discovery Data AD Type Code Field

The Transport Discovery Data AD Type Code field shall be included in the Transport Discovery Data AD Type.

This field shall contain the 1 octet Transport Discovery Data AD Type Code value as defined in the Generic Access Profile (GAP).

Device Name Field

본 명세서는 DoT Discovery(또는 TDS)에서 디바이스 이름 필드를 추가할 것을 제안한다.

즉, TDS 절차에서 디바이스 이름 필드를 송수신할 수 있다.

즉, 이는 블루투스 연결 전인 광고 메시지를 통해, 또는 연결 후인 광고 메시지 등을 통해 전송될 수 있다.

만약, Device Name 또는 Device Type이 없을 경우, 사용자는 DoT Discovery 검색 결과 목록의 장치들이 어떤 장치인지 알지 못하기 때문에 편의성이 결여됨.

type	Value
Uint8	1: TV 2: Phone 3: Watch 4: Laptop 5: PC 6: Audio 7: Accessary 8: Gateway (or AP) ...
String	Friendly Name

Previous Connection Block Field

또한, 본 명세서는 이전 연결 블록 필드를 TDS 절차(DoT discovery)에서 제공할 것을 제안한다.

DoT 수행 장치와 대상 장치가 이미 Wi-Fi 등으로 연결되어 있지만, User는 모르는 상태일 경우가 발생 가능.

따라서 DoT Discovery에서 이를 알려주고 필요시 해당 connection을 끊을 수 있도록 제공.

즉, 이전 연결 블록 필드는 표 11과 같이, 연결된 상태, 연결된 기술, 연결된 서비스와 관련된 정보를 제공할 수 있다.

따라서, 상기 이전 연결 블록 필드를 통해 TDS 수행장치(또는 DoT 수행장치)는 (다른 인터페이스로) 연결 대상 장치와의 연결 상태를 알 수 있고, 이전 연결을 종료시킬 수도 있다.

50. Fields		51. Data Type	52. value	53.
54. Previous Connection Block	55. Connected Status	56. bits	57. 0b00 : Known 58. 0b01 : Already Connected 59. 0b10 : Not Connected 60. 0b11 : RFU	61.
	62. Connected Tech	63. Uint8	64. Specific Tech Method와 동일 65. - 0x01: Wi-Fi Infrastructure - 0x02: Wi-Fi Direct (P2P) - 0x03: Zigbee - 0x04: Zigbee PRO - 0x05: Zigbee IP - 0x06: Z-Wave - 0x07: NFC - 0x08: RoLa - 0x09: ANT+ 66.	67. 현재 이미 연결되어 있는 통신 인터페이스 종류
	68. Connected Service	69. Uint8	70. 0x01: Wi-Fi Display (Miracast) 71. 0x02: Wi-Fi Direct Service 72. 0x03: Wi-Fi Docking 73. 0x04: Zigbee Lighting 74. 0x05: Zigbee Smart Grid 75. 0x06: File Sharing 76. 0x07: BR/EDR Handsfree 77. 0x08: BR/EDR Audio 78. 등등	79. 이미 연결되어 있는 서비스 종류

Encryption Block Field

또한, 본 명세서는 TDS 절차에서 암호화 블록 필드를 추가할 것을 제안한다.

해당 DoT Advertisement는 아래와 같이 Encryption Block를 포함할 수 있음.

암호화 블록 필드는 표 12와 같이 블록 길이, 암호화 사용 여부, 암호화 키, 허가된 디바이스 리스트 관련 정보들을 포함할 수 있다.

80. Fields		81. Data Type	82. value	83.
84. Encryption Block	85. Block Length	86. uint8	87.	88.
	89. Encryption Use	90. 2 bit	91. 0b00 : All Allowed 92. 0b01 : Encryption Only 93. 0b10 : Permission Only 94. 0b11 : Both Used	95.
	96. Encryption Key	97. xx	98. 보안 키	99. Encryption Use가 01 또는 11일 경우에만 사용
	100. Permitted List	101. Addr_List	102. 본 DoT Adv 수신이 허가된 장치 주소 목록. 103. (복수의 장치 주소 허용)	104.

Transport Block

A Transport Block includes the following fields: Organization ID, TDS Flags, Transport Data Length, and Transport Data.

One or more Transport Block(s) may be present in the Transport Discovery Data AD Type.

The value of the fields in this section relate only to the transport which the block describes (i.e., they pertain only to that Transport Block).

The data contained in the Transport Block shall be able to be fully parsed by Clients even if size or other restrictions require that full data is in the GATT database.

for details on how this block may be repeated in case there are multiple services (perhaps from the same or different transports) that need to be advertised simultaneously in available space.

Organization ID Field

The Organization ID field shall be included in the Transport Block.

This field shall contain a 1 octet Organization ID value from the Bluetooth SIG Assigned Numbers with the value set to the appropriate organization. for details on how multiple services (related to the same or different Organization IDs) can be advertised in the same packet.

The values of this field defined in this version of the specification are shown in Table 13 Refer to the Bluetooth SIG Assigned Numbers for a complete list of assigned numbers.

Value	Definition
0x00	Reserved for Future Use (RFU)
0x01	Bluetooth SIG
0x02 - 0xFF	RFU at the time of this writing. Refer to Bluetooth SIG Assigned Numbers [3] for complete list.

신규추가항목 : Specific Tech Method 또한, 본 명세서는 무선 통신 인터페이스 별로 구분될 수 있는 특정 기술 방법을 표 14와 같이 제공한다.

Value	Definition
0x01 ~ n	Specific Tech Method (Wi-Fi 경우 Wi-Fi와 Wi-Fi Direct 등으로 다수의 통신기술이 존재. 따라서 아래와 같이 별도의 통신기술 분류 또는 이름이 필요) Ex) - 0x01: Wi-Fi Infrastructure - 0x02: Wi-Fi Direct (P2P) - 0x03: Zigbee - 0x04: Zigbee PRO - 0x05: Zigbee IP - 0x06: Z-Wave - 0x07: NFC - 0x08: RoLa - 0x09: ANT+
String	또는 위 내용을 문자열 형태로 Text 기반 기술이름 명기도 가능

TDS Flags Field

The TDS Flags field shall be included in the Transport Block.

This field shall contain a 1 octet value that represents the role of the device and information about its state and supported features.

Bits defined as RFU shall be set to 0.

The values of this field are defined as:

또한, 본 명세서는 전송 블록 내 포함되는 TDS 플래그에 지원되는 기술에서의 역할을 나타내는 필드를 새롭게 정의할 것을 제공한다.

즉, 디스커버리되는 다른 무선 통신 인터페이스에서의 역할을 알아야 접속 가능여부를 파악할 수 있게 된다.

Bits	Definition
0-1	Role: 0b00: Not specified 0b01: Seeker Only 0b10: Provider Only 0b11: Both Seeker and Provider
2	Transport Data Incomplete: 0: False 1: True
3-4	Transport State: 0b00: Off 0b01: On 0b10: Temporarily Unavailable 0b11: RFU
5-7	Reserved for future use
신규	Role of Supported Tech - 탐색될 다른 통신의 역할이 있어야 접속 가능한지 알 수 있음 0b00: Unknown 0b01: Master (or Coordinator, or Server, or Sync) 0b10 : Slave (or Station, or Client, or Node) 0b11: Both Supported

TDS Flags Field

The definition and purpose of the bits listed are described in the sections to follow.

Role

The Role bits indicate whether the Transport Block represents a Provider of a service, a Seeker of a service, a combination of Seeker and Provider, or is unspecified.

The Server shall set these bits to an appropriate value for the Transport Block (i.e., whether the role of this specific block is seeking a service, providing a service, acting as a combination of the two, or is unspecified).

Transport Data Incomplete

The Transport Data Incomplete bit indicates whether the Transport Data field contains complete or incomplete data. If incomplete, then all fields of the Transport Block can be found in the in the GATT database. This can be used when there is insufficient space in the Advertising Packet for the entire contents or due to other restrictions.

The Server shall set this bit to 1 if the Transport Data is incomplete and when the complete Transport Block can be found in the GATT database. Otherwise, it shall be set to 0.

Transport State

The Transport State bits indicate whether the transport providing access to the advertised service(s) is Off, On, or Temporarily Unavailable. When the bits are set to Off, the transport is not in a state that can accept a connection, however is available to be changed to the On state (e.g., using the TDS Control Point). When set to On, the transport is in a state that can accept a connection. When the bits are set to Temporarily Unavailable, the transport is in a transient state (e.g., if the device is servicing another request) and will change to Off or On as appropriate. For the case where the bits are set to Temporarily Unavailable, a higher level specification can include a 'hint' of the duration and/or cause of unavailability in the Transport Data or via other means.

Transport Data Length Field

The Transport Data Length field shall be included in the Transport Block.

This field shall contain a 1 octet value that represents the total number of octets in the Transport Data field that follows. This allows a scanning device to determine the length of the variable field that follows, and also allows for extensibility in the future. For example, a Transport Data Length value of 0x10 represents that a 16 octet Transport Data field follows. Similarly, a value of 0x00 represents that the Transport Data field is not present.

Value	Definition
0x00	Transport Data field not present (i.e., 0 octets in length)
0x01 - 0xEF (Note 1)	Number of Octets in Transport Data field
0xF0 - 0xFF	Reserved for Future Use

Transport Data Field

The Transport Data field may be included in the Transport Block.

If used, this field contains organization-specific data and shall be byte-aligned. The value shall fit within the available space in the Advertising Packet. The contents of this field are defined by a higher level specification.

If multiple service identifiers are listed in the Transport Data field, the advertising device should list these in order of descending priority or preference. For example, if the list represents more than one supported service (corresponding to the Provider role), the order represents preferred support (e.g., perhaps a device is capable of transferring data using a faster method as well as a slower legacy method). If the list represents more than one required service (corresponding to the Seeker role), the order represents preferred service order (e.g., perhaps a device requires an immediate service, but also another service that is of lower priority).

Advertising Using Multiple Transport Blocks

The structure of the Transport Block may be repeated in case there are multiple services (on the same or different transports) to advertise simultaneously. The structure may repeat as long as there is space available. These Transport Blocks may be from the same organization or from different organizations.

Where multiple Transport Blocks are used, the advertising device should list these in order of descending priority or preference. For example, if the blocks represent more than one supported service, the order represents preferred support (e.g., perhaps a printer is capable of printing using a faster technology from one organization, but also a slower technology from another organization). If the blocks represent more than one required service, the order represents preferred service order (e.g., perhaps a device requires an immediate service, but also another service that is of lower priority).

Byte Ordering

Where characteristics and descriptors are comprised of multiple bytes (shown in several tables within this document), the Least Significant Octet (LSO) is the topmost field in the tables and the Most Significant Octet (MSO) is the bottommost field in the tables. Refer to Section 1.7 for requirements related to byte transmission order.

Service Characteristics

This section defines requirements related to GATT characteristics and descriptors for this service. Only one instance of each characteristic is permitted within this service.

TDS Control Point

The TDS Control Point characteristic is used to request activation of a transport. Additional Op Codes may be added in the future for other purposes. Figure 4.1 shows an informative example of the flow of a TDS Control Point operation.

TDS 제어 포인트 특성은 전송의 활성화를 요청하기 위해 사용된다.

In this example, the Client writes the Activate Transport Op Code (0x01) to the TDS Control Point. The Server sends a Write Response to acknowledge the write to the TDS Control Point. The Server sets the desired transport into a connection-ready state. The Server sends a TDS Control Point indication with the Requested Op Code (0x01) followed by the Result Code for 'Success' (0x00). The Client sets the desired transport into a connection-ready state and responds with the ATT Confirmation. The Server and Client perform a transport-specific connection procedure.

Only one instance of the TDS Control Point characteristic shall be exposed.

Table 17 shows the required structure of the TDS Control Point characteristic:

Fields	Data Type	Size (octets)	Requirement
Op Code (See Table 4.3)	uint8	1	M
Organization ID	uint8	1	M
Parameter	Variable	0 to 19 octets (see Note 1)	O

Structure of TDS Control Point Characteristic

Note 1: Parameters larger than 19 octets are permitted if a larger MTU is negotiated.

TDS Control Point Procedure Requirements

Table 18 shows the op code requirements for the TDS Control Point characteristic:

또한, 본 명세서는 TDS 제어 포인트의 동작 코드(Op Code)로 전송의 비활성을 요청하기 위한 값을 새롭게 정의한다. 예를 들어, 해당 동작 코드는 이미 wi-fi 등 다른 통신으로 연결되어 있는 장치를 off시킬 경우 사용된다.

Op Code Value	Procedure	Requirement	Organization ID	Parameter
0x00	Reserved for Future Use
0x01	Activate Transport	M	This field shall contain the relevant 1 octet Organization ID.	This field shall contain relevant transport-specific data up to 19 octets (see Note 1).
신규	Inactivate Transport		상동	이미 Wi-Fi 등 다른 통신으로 연결되어있는 장치를 Off 시킬 경우
0x02-0xFF	Reserved for Future Use

TDS Control Point Procedure Requirements

Note 1: Parameters larger than 19 octets are permitted if a larger MTU is negotiated.

Table 19 shows the required structure of the TDS Control Point Indication:

Fields	Data Type	Size (octets)	Requirement
Requested Op Code	uint8	1	M
Result Code	uint8	1	M
Response Parameter (See Table 4.5)	Variable	0 to 19 octets (see Note 1)	O

Structure of TDS Control Point Indication

Note 1: A Response Parameter larger than 19 octets is permitted if a larger MTU is negotiated.

The Response Parameter field, if present, shall contain the relevant 1 octet Organization ID followed by transport-specific data.

The Result Codes that can be sent in a TDS Control Point Indication are defined in Table 20:

Result Code	Definition	Description
0x00	Success	Response for successful operation.
0x01	Op Code Not Supported	Response if unsupported or RFU Op Code is received.
0x02	Invalid Parameter	Response if Parameter received does not meet the requirements of the higher level specification.
0x03	Unsupported Organization ID	Response if unsupported or RFU Organization ID is received.
0x04	Operation Failed	Response if the requested procedure failed for any reason other than those enumerated in this table.
신규추가	Not Allowed	새로 추가한 Encryption Block 조건에 만족되지 않을 경우
신규추가	Role Miss-matched	새로 추가한 Role of Supported Tech 와 부합되지 않을 경우 (예: Master 장치에 Master로써 Handover를 시도할 경우)
0x05-0xFF	Reserved For Future Use

또한, 본 명세서는 TDS 제어 포인트 지시에서 보내질 수 있는 새로운 결과 코드를 제공한다.

새로운 결과 코드값은 '허용되지 않음'과 '역할 불일치'이다.

상기 새로운 결과 코드값을 포함하는 TDS 제어 포인트 지시(indication)은 (1) 본 명세서에서 제안하는 암호화 블록 조건에 만족되지 않을 경우, (2) 본 명세서에서 제안하는 지원되는 기술의 역할에 부합되지 않을 경우 전송될 수 있다.

(2)의 일례로, 마스터 장치에 마스터로써 핸드오버를 시도할 경우일 수 있다.

List of Result Codes associated with the TDS Control Point Indication

A higher level specification may include additional information within the Parameter of the Response Value. It may include, for example, additional details relating to the reason for a failed operation.

Characteristic Behavior

The TDS Control Point is used by a Client to control certain behaviors of the Server.

A procedure is triggered by writing a value that includes an Op Code specifying the operation and this may be followed by a an Organizational ID and Parameter that is valid within the context of that Op Code (see Table 4.3). For the procedure described in the next section, the Server shall indicate the TDS Control Point characteristic along with the Requested Op Code and "Success" or other appropriate Result Code contained in the response as listed in Table 4.5.

Refer also to Section 4.1.4 for information on General Error Handling.

Activate Transport Procedure

When the Activate Transport Op Code is written to the TDS Control Point and the response is "Success", the actions to follow are defined by a higher level specification.

The contents of the organization-specific octets in the parameter for this Op code are defined by a higher level specification.

In the event that an error condition occurs, the applicable Error Response shall be sent.

General Error Handling

Writing an Op Code to the TDS Control Point may result in an ATT Error response or a Control Point Error response as described in the sections to follow.

ATT Error

An ATT Write Request to the TDS Control Point characteristic may be rejected with an Attribute Protocol Error Response under certain conditions as defined in [1]. Reasons for sending an ATT Error Response include but are not limited to Insufficient Encryption, Client Characteristic Configuration Descriptor Improperly Configured, Procedure Already in Progress, or Invalid Attribute Value Length. See also Section 1.6 for Attribute Protocol Application Error codes defined by this service.

Control Point Error

If the ATT Write Request to the control point characteristic was successful but the requested control point procedure could not be performed or could not be completed successfully, an appropriate Result Code from the following sections shall be indicated in the Response Value as described above and in this section.

Op Code Not Supported

The Op Code Not Supported error response shall be indicated if the Op Code written to the control point is not supported by the Server. This includes Op Code values that are reserved for future use.

Invalid Parameter

The Invalid Parameter error response shall be indicated if the value of the parameter written to the control point did not meet the requirements of the service.

Note that a parameter of an incorrect size, including any parameter sent with an Op Code for which no parameter was actually required, should be trapped by an ATT Error response as described in Section 4.1.4.1 and in this case, it should not generate a control point error response.

Unsupported Organization ID

The Unsupported Organization ID error response shall be indicated if the value of the Organization ID written to the control point is RFU or otherwise not supported by the Server.

Operation Failed

The Operation Failed error response shall be indicated if a requested control point procedure failed for any reason not otherwise enumerated.

Procedure Timeout

In the context of the TDS Control Point characteristic, a control point procedure is started when an ATT Write Request to the TDS Control Point characteristic is successful (i.e., when the Server sends the ATT Write Response).

The Server may then use an implementation-specific timeout that should be a maximum of 10 seconds. If the timeout expires before the requested control point procedure has been completed, the Server may abort the service procedure and indicate the Operation Failed error response described.

A control point procedure is not considered started and not queued in the Server when a Write Request to the TDS Control Point characteristic results in an ATT Error response as described.

Abbreviation or Acronym

AD: Advertising Data

AMP: Alternate MAC PHY

MTU: Maximum Transmission Unit

SDP: Service Discovery Protocol

UTF: Unicode Transformation Format

UUID: Universally Unique Identifier

이상에서 설명한 본 발명은, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 있어 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니다.

본 명세서는 블루투스 기술을 이용하여 다른 네트워크 인터페이스를 연결하는 방법을 이용하는데 있다.

110: 서버 디바이스
120: 클라이언트 디바이스

Claims (1)

1. 무선 통신 시스템에서 디바이스 간 연결을 형성하기 위한 방법에 있어서, 제 1 디바이스에 의해 수행되는 방법은,
   디바이스 디스커버리를 수행하는 단계;
   다른 통신 인터페이스와 관련된 제어 정보를 제 2 디바이스와 교환하는 단계; 및
   상기 제어 정보에 기초하여 상기 제 2 디바이스와 다른 통신 인터페이스로 연결을 수행하는 단계를 포함하는 것을 특징으로 하는 방법.

Images