KR20080014788A

KR20080014788A - 신뢰할 수 있는 매체를 통한 무선 ｕｓｂ（ｗｕｓｂ） 접속수립

Info

Publication number: KR20080014788A
Application number: KR1020077027204A
Authority: KR
Inventors: 피르도시 브헤사니아; 글렌 토마스 슬릭; 랜돌 에드워드 올
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-06-10
Filing date: 2006-06-12
Publication date: 2008-02-14
Also published as: WO2006135872A3; US20060149858A1; WO2006135872A2

Abstract

신뢰할 수 있는 매체(trusted medium)를 통한 신뢰할 수 없는 매체(untrusted medium)(예컨대, 무선) 장치 구성을 위한 확장 가능한 아키텍처. 이 아키텍처는 유선 접속과 같은 신뢰할 수 있는 매체를 이용하여 접속 장치와 호스트 장치 간의 무선 USB(WUSB: wireless universal serial bus) 접속을 수립하는 시스템 및 방법을 포함한다. 일 구현에서, 상기 접속 장치는 상기 신뢰할 수 있는 매체를 통하여 상기 호스트 장치에 연결 요구(association request)를 송신한다. 이 연결 요구는 상기 접속 장치의 WUSB 컴포넌트와 관련된 장치 속성들을 포함한다. 그에 응답하여, 상기 호스트 장치는 상기 연결 요구를 구문분석(parse)하고 유효성 검사(validate)하고 WUSB를 이용한 접속을 위한 접속 속성들을 판정한다. 상기 호스트 장치는 상기 신뢰할 수 있는 매체를 통하여 상기 접속 장치에 상기 접속 속성들을 갖는 응답을 송신한다. 상기 접속 속성들을 이용하여, 상기 접속 장치는 상기 WUSB 컴포넌트를 구성하고 상기 호스트 장치와의 WUSB 접속을 수립한다.

신뢰할 수 있는 매체(trusted medium), WUSB(wireless universal serial bus), 연결 요구(association request), 장치 속성, 접속 속성

Description

신뢰할 수 있는 매체를 통한 무선 ＵＳＢ（ＷＵＳＢ） 접속 수립{ESTABLISHING WIRELESS UNIVERSAL SERIAL BUS(WUSB) CONNECTI0N VIA A TRUSTED MEDIUM}

<발명의 개요>

다음은 본 발명의 일부 양태들에 대한 기본적인 이해를 제공하기 위해 본 발명의 간략화한 개요를 제시한다. 이 개요는 본 발명의 광범위한 개관은 아니다. 그것은 본 발명의 중요한/결정적인 구성요소들을 식별하거나 본 발명의 범위를 기술하려고 하는 것이 아니다. 그것의 유일한 목적은 나중에 제시되는 보다 상세한 설명의 서두(prelude)로서 본 발명의 일부 개념들을 간략화한 형태로 제시하기 위한 것이다.

이하에서는 신뢰할 수 있는 매체(trusted medium)를 통한 신뢰할 수 없는 매체(untrusted medium)(예컨대, 무선) 장치 구성을 위한 확장 가능한 아키텍처에 대하여 설명한다. 이 아키텍처는 신뢰할 수 없는 매체(예컨대, 무선 접속)를 이용하는 장치를 연결(associate)시키기 위해 이용될 수 있다. 연결은 신뢰할 수 있는 매체, 예를 들면, 유선 접속을 이용하여 실행된다.

이 아키텍처는 유선 접속과 같은 신뢰할 수 있는 매체를 이용하여 접속 장치와 호스트 장치 간의 무선 USB(WUSB: wireless universal serial bus) 접속을 수립하는 시스템 및 방법을 포함한다. 일 구현에서, 상기 접속 장치는 상기 신뢰할 수 있는 매체를 통하여 상기 호스트 장치에 연결 요구(association request)를 송신한다. 이 연결 요구는 상기 접속 장치의 WUSB 컴포넌트와 관련된 장치 속성들을 포함한다. 그에 응답하여, 상기 호스트 장치는 상기 연결 요구를 구문분석(parse)하고 유효성 검사(validate)하고 WUSB를 이용한 접속을 위한 접속 속성들을 판정한다. 상기 호스트 장치는 상기 신뢰할 수 있는 매체를 통하여 상기 접속 장치에 상기 접속 속성들을 갖는 응답을 송신한다. 상기 접속 속성들을 이용하여, 상기 접속 장치는 상기 WUSB 컴포넌트를 구성하고 상기 호스트 장치와의 WUSB 접속을 수립한다.

도 1은 본 발명의 일 양태에 따른 연결 아키텍처를 도시한 블록도이다.

도 2는 본 발명의 일 양태에 따른 연결 요구를 도시한 도면이다.

도 3은 본 발명의 일 양태에 따른 연결 응답을 도시한 도면이다.

도 4는 본 발명의 일 양태에 따른 연결 관리 시스템을 도시한 블록도이다.

도 5는 본 발명의 일 양태에 따른 연결 관리 시스템을 도시한 블록도이다.

도 6은 본 발명의 일 양태에 따른 연결 핸들러 시스템을 도시한 블록도이다.

도 7은 본 발명의 일 양태에 따른 연결 드라이버 시스템을 도시한 블록도이다.

도 8은 본 발명의 일 양태에 따른 장치의 연결 방법을 도시한 흐름도이다.

도 9는 본 발명의 일 양태에 따른 장치의 연결을 용이하게 하는 방법을 도시 한 흐름도이다.

도 10은 본 발명의 일 양태에 따른 USB 접속을 통한 장치의 연결 방법을 도시한 흐름도이다.

도 11은 도 10의 방법을 더 설명하는 흐름도이다.

도 12는 도 10 및 11의 방법을 더 설명하는 흐름도이다.

도 13은 본 발명의 일 양태에 따른 연결 관리 방법을 도시한 흐름도이다.

도 14는 본 발명의 일 양태에 따른 연결 관리 방법을 도시한 흐름도이다.

도 15는 도 14의 방법을 더 설명하는 흐름도이다.

도 16은 도 14 및 15의 방법을 더 설명하는 흐름도이다.

도 17은 본 발명의 일 양태에 따른 연결 핸들러 방법을 도시한 흐름도이다.

도 18은 본 발명이 기능할 수 있는 예시적 운영 환경을 예시한다.

도 19는 PONG 시스템의 일례를 도시한다.

도 20은 운영 체제의 장치 관리자 아키텍처에 대한 USB 드라이버 스택의 예를 도시한다.

도 21은 WUSB 장치가 호스트 장치에 접속하는 동작들의 예를 도시한다.

도 22는 본 명세서에서 설명된 시스템을 이용하여 WUSB 장치와 호스트 장치를 접속시키는 프로세스의 예를 도시한다.

도 23은 본 명세서에서 설명된 특정 데이터 구조를 이용하여 장치를 연결시키는 프로세스의 예를 도시한다.

이제 도면들을 참조하여 본 발명을 설명한다. 도면들의 전체에 걸쳐서 유사한 구성요소들을 나타내기 위해 유사한 참조 번호들이 사용된다. 다음 설명에서는, 설명을 목적으로, 본 발명의 철저한 이해를 제공하기 위하여 다수의 특정 상세들이 설명된다. 그러나, 본 발명은 이들 특정 상세 없이도 실시될 수 있음을 분명히 알 수 있다. 그 밖의 경우에, 본 발명의 설명을 용이하게 하기 위하여 주지의 구조 및 장치들은 블록도 형태로 나타내어진다.

본원에서 사용될 때, "컴포넌트(component)", "핸들러(handler)", "모델(model)", "시스템(system)" 등의 용어들은 하드웨어든, 하드웨어와 소프트웨어의 조합이든, 소프트웨어든, 실행중인 소프트웨어든, 컴퓨터 관련 엔티티를 나타내도록 의도되어 있다. 예를 들면, 컴포넌트는 프로세서 상에서 실행중인 프로세스, 프로세서, 개체(object), 실행 파일(executable), 실행 스레드(thread of execution), 프로그램, 및/또는 컴퓨터일 수 있지만, 이에 제한되는 것은 아니다. 예시로서, 서버 상에서 실행중인 애플리케이션 및 상기 서버는 컴포넌트일 수 있다. 프로세스 및/또는 실행 스레드 내에 하나 이상의 컴포넌트들이 존재할 수 있고 컴포넌트는 하나의 컴퓨터에 국한(localize)되거나 및/또는 2 이상의 컴퓨터 사이에 분산(distribute)될 수 있다. 또한, 이들 컴포넌트들은 각종의 데이터 구조가 저장되어 있는 각종의 컴퓨터 판독가능 매체로부터 실행될 수 있다. 컴포넌트들은 이를테면 하나 이상의 데이터 패킷들을 갖는 신호(예컨대, 로컬 시스템에서, 또는 분산 시스템에서 다른 컴포넌트와 상호작용하거나, 및/또는 인터넷과 같은 네트워크를 가로질러 상기 신호를 통하여 다른 시스템들과 상호작용하는 하나의 컴포넌트 로부터의 데이터)에 따라서 로컬 및/또는 원격 프로세스들을 통하여 통신할 수 있다. 컴퓨터 컴포넌트들은 본 발명에 따라서, 예를 들면, 컴퓨터 판독가능 매체 상에 저장될 수 있고, 여기서 컴퓨터 판독가능 매체는 ASIC(application specific integrated circuit), CD(compact disc), DVD(digital video disk), ROM(read only memory), 플로피 디스크, 하드 디스크, EEPROM(electrically erasable programmable read only memory) 및 메모리 스틱을 포함하지만, 이에 제한되는 것은 아니다.

또한, "신뢰할 수 있는 매체(trusted medium)"는 신뢰할 수 없는 매체를 연결시키기 위하여 그를 통하여 연결 정보가 전송될 수 있는 신뢰할 수 있는 매체를 나타낸다. 신뢰할 수 있는 매체의 예로는, 직렬 접속, 병렬 접속 및/또는 USB(universal serial bus) 접속 등이 있지만, 이에 제한되는 것은 아니다. "신뢰할 수 없는 매체(untrusted medium)"는 신뢰를 수립하기 위하여 연결되고 있는 매체를 나타낸다. 블루투스 및/또는 IEEE 802.11과 같은 무선 접속(들)이 신뢰할 수 없는 매체의 예들이다.

도 1을 참조하면, 본 발명의 일 양태에 다른 연결 아키텍처(100)가 예시되어 있다. 이 아키텍처(100)는 신뢰할 수 없는 매체(예컨대, 무선 접속)를 이용하는 장치(110)를 연결시키기 위해 이용될 수 있다. 연결은 신뢰할 수 있는 매체, 예를 들면, 유선 접속을 이용하여 실행된다.

"연결 요구(association request)"는 연결을 개시하기 위하여 장치(110)로부터 드라이버(120)로 송신되는 데이터의 블록을 나타낸다. 그 후 연결 요구는 연결 관리자(130)에 전송될 수 있고 연결 관리자(130)는 그 연결 요구를 적절한 핸들러(140)에 전송한다. "연결 응답(association response)"은 연결을 완료하기 위하여(예컨대, 성공함 및/또는 성공하지 못함) 드라이버(120)로부터 장치(110)로 송신되는 데이터의 블록을 나타낸다.

아키텍처(100)는 신뢰할 수 없는 매체(예컨대, 무선 접속)를 통하여 (예컨대, 안전하게) 통신하기 위해 장치(110)의 구성을 용이하게 할 수 있다. 장치(110)의 구성은, 적어도 부분적으로, 신뢰할 수 있는 매체(예컨대, 유선 접속)를 통하여 교환된 정보에 기초할 수 있다. 일 예에서, 장치(110)는 연결 요구를 드라이버(120)에 송시하고 드라이버(120)로부터 연결 응답을 수신한다. 만일 연결이 성공하면, 연결 응답은, 예를 들면, 장치(110)가 신뢰할 수 없는 매체를 통하여 (예컨대, 안전하게) 통신할 수 있게 하는 구성 정보(예컨대, 암호화 키)를 포함할 수 있다. 만일 연결이 성공하지 못하면, 연결 응답은, 예를 들면, 오류 정보를 포함할 수 있다.

일 예에서, 장치(110)는 USB 접속도 포함하는 무선-가능(wireless-enabled) 디지털 카메라이다. USB 접속(신뢰할 수 있는 매체)은 디지털 카메라의 무선 접속(신뢰할 수 없는 매체)을 구성하기 위해 이용될 수 있다. 예를 들면, 아키텍처(100)를 통하여 디지털 카메라에 전송할 무선 프로파일을 선택 및/또는 생성하기 위해 "새로운 하드웨어 발견(found new hardware)" 마법사가 이용될 수 있다. 일단 프로파일 정보가 USB 접속을 통하여 디지털 카메라에 전송되면, USB 접속은 분리될 수 있고 디지털 카메라는 무선 접속을 통하여 통신할 수 있다.

예를 들면, 드라이버(120)는 장치(110)로부터 신뢰할 수 있는 매체를 통하여 수신된 접속 요구를 연결 관리자(130)에 전달(channel)할 수 있다. 드라이버(120)는 또한 연결 관리자(130)로부터 수신된 연결 응답을 신뢰할 수 있는 매체를 통하여 장치(110)에 제공할 수 있다. 다른 예에서, 드라이버(120)는 응답 요구를 생성하여 연결 관리자(130)에 제공한다. 옵션으로(optionally), 드라이버(120)는 또한 응답 요구의 발행을 위한 적절한 시간을 판정할 수 있다.

또 다른 예에서, 복수의 신뢰할 수 없는 매체를 구성하기 위해 특정 드라이버(120)가 이용될 수 있다. 예를 들면, 복수의 신뢰할 수 없는 매체를 통하여 통신하는 복수의 장치들(110)에 USB 접속을 통하여 통신하기 위해 드라이버(120)가 이용될 수 있다.

연결 관리자(130)는 연결 데이터를 적절한 컴포넌트들에 제공한다. 연결 관리자(130)는 드라이버(120)로부터 연결 요구를 수신할 수 있다. 적어도 부분적으로, 연결 요구 내의 라우팅 정보에 기초하여, 연결 관리자(130)는 연결 요구와 관련된 정보를 처리를 위한 특정 핸들러(140)에 제공할 수 있다. 일단 특정 핸들러(140)가 연결 요구의 처리를 완료하면, 그 핸들러(140)는 연결 응답을 연결 관리자(130)에 제공할 수 있다. 적어도 부분적으로, 연결 응답 내의 라우팅 정보에 기초하여, 연결 관리자(130)는 연결 응답을 요구 드라이버(120)에 제공할 수 있다.

핸들러(140)는 장치 설치를 구현하는 서비스(도시되지 않음)와 인터페이스한다. 일 예에서, 핸들러(140)는 연결 요구의 명시 지식(explicit knowledge)을 갖고 있는 아키텍처(100)의 유일한 컴포넌트이다. 핸들러(140)는, 적어도 부분적으 로, 아래에서 상세히 설명되는, 연결 요구의 콘텐츠에 기초하여 액션을 취한다. 예를 들면, 액션(들)은 연결 요구에 의해 수립하려고 하는 접속 유형에 의존할 수 있다. 일단 특정 핸들러(140)가 연결 요구의 처리를 완료하면, 그 핸들러(140)는 연결 응답을 연결 관리자(130)에 제공할 수 있다.

아키텍처(100)는 하나 이상의 핸들러(140)와 관련된 식별 정보를 저장하는 핸들러 레지스트리(150)를 포함할 수 있다. 연결 관리자(130)는 핸들러 레지스트리(150)에 저장된 식별 정보를 이용하여 복수의 핸들러(140) 중 어느 것에 특정 연결 요구를 제공할지를 판정할 수 있다.

또한, 아키텍처(100)는, 옵션으로, 하나 이상의 드라이버(120)와 관련된 식별 정보를 저장하는 드라이버 레지스트리(160)를 포함할 수 있다. 연결 관리자(130)는 드라이버 레지스트리(160)에 저장된 식별 정보를 이용하여 하나 이상의 드라이버(120) 중 어느 것을, 예를 들면, 초기화(아래에서 설명됨) 중에 인스턴스화(instantiate)할지를 판정할 수 있다.

단일 엔티티로서 도시되어 있지만, 숙련된 당업자라면 장치(110)가 연결 요구를 송신 및/또는 수신하는 개체 및 궁극적으로 호스트와 연결되는 개체(예컨대, 대상 장치(target device))를 포함할 수 있다는 것을 알 것이다.

일 예에서, 아키텍처(100)는 단지 하나의 연결 요구 및 관련 연결 응답을 지원한다. 이 예에서, 연결을 용이하게 하기 위해 장치(110)로부터 요구되는 정보는 연결 요구에 포함(embed)된다. 유사하게, 연결을 용이하게 하기 위해 장치(100)에 대하여 요구되는 정보는 연결 응답에 포함된다.

도 2를 참조하면, 본 발명의 일 양태에 따른 연결 요구(200)가 예시되어 있다. 연결 요구(200)는 연결 요구 헤더(210) 및 하나 이상의 연결 요구 속성(들)(220)(예컨대, 속성 유형, 길이 및 데이터)을 포함한다. 속성은 연결 요구 및/또는 응답 내의 단일 항목이다. 예를 들면, 연결 요구 헤더(210)는 연결 요구 속성(들)(220)에 관하여 아래에서 설명되는 것들과 포맷이 유사한 전역적으로 정의된(globally defined) 요구 속성(들)의 세트를 포함한다.

일 예에서, 연결 요구(들) 및/또는 연결 응답(들)은 구문분석-가능(parse-able) 스트림으로 편성된다. 이 스트림은 일련의 속성(들)을 포함하고 각 속성은 정의된 유형 및 관련 데이터를 갖는다. 이것은 아키텍처의 유연성(flexibility) 및 확장성(extensibility)을 용이하게 한다. 예시적인 속성 구조가 표 1에 제시되어 있다:

바이트 오프셋	필드 길이	필드 이름	설명
0	2	AttributeType	특정 속성을 설명하는 식별자
2	2	AttributeDataLength	이 속성의 데이터 필드의 바이트 길이
4	0-0xFFFF	Data	이 특정 속성에 대한 데이터

이 예시적인 속성 구조는, 예를 들면, 다음과 같이 정의될 수 있다:

일 예에서, 스트림 자체에 의해 사용되도록 의도되어 있고(예컨대, 다수의 연결 유형들에 공통), 임의의 특정 연결 유형에 특정하지 않은 몇몇 사전 정의된 속성 유형들이 있다.

AttributeType 값	속성 이름	AttributeDataLength	설명
0x0000	AssociationType	Sizeof(GUID)	이것은 데이터가 따라야 할 연결의 유형의 식별자이다. 그것은 핸들러가 정의될 때 정의되는 고유 GUID이다. 이 값은 2가지 목적으로 이용될 수 있다. 첫째로 그것은 어떤 소프트웨어 컴포넌트가 연결 요구를 처리(handle)해야하는지를 정의한다(예컨대,블루투스 핸들러). 둘째로, 그것은 다음에 올 속성들에 대한 범위를 정의한다. 그 이유는 대부분의 속성 유형들은 그들의 AssociationType에 관하여 고유해야 하기 때문이다.
0x0001	Length	4	이것은 AssociationType 및 Length 속성들을 포함하는, 요구 또는 응답의 총 길이이다.
0x0002	MaximumResponseLength	4	이것은 연결 응답의 최대 지원되는 바이트 길이이다. 이것은, 예를 들면, 장치의 자원 제약들에 의해 결정될 수 있다.
0x0003	AssociationStatus	4	이것은 연결에 대한 상태이고 응답에 포함된다.
0x0004- 0x1000	예비(RESERVED)	0-0xFFFF	이 예에서, 이들 AttributeType 값들은 장래의 사용을 위해 예비되고 어떤 AssociationType 특정 속성들을 위해서도 사용되지 않는다.

예시적인 연결 상태 값들은 다음과 같다:

값	이름	설명
0x0000	ASSOCIATION_SUCCESS	연결이 성공적으로 완료되었고, 응답이 유효하다.
0xC001	ERROR_MALFORMED_ASSOCIATION_REQUEST	연결 요구가 정확하게 형성되지 않았다.
0xC002	ERROR_ASSOCIATION_TYPE_NOT_SUPPORTED	연결 요구에서 지정된 연결 유형은 등록된 핸들러를 갖고 있지 않다.

연결 요구

이 예에서, 연결 요구는 일련의 속성들이다. 제1 속성은 연결 유형(AssociationType)이다. 이것은 어느 핸들러에 요구가 인도(direct)되어야 하는지를 식별하기 위해 사용된다. 이 예에서, 이 값은 핸들러에 의해 정의되는 GUID(또는 핸들러와 관련된 어떤 사양)이다. 예를 들면, 블루투스 장치를 연결시키기 위하여, 블루투스 특정 GUID, 및 자신이 그 특정 GUID를 처리한다는 것을 지정한 핸들러가 있을 수 있다.

연결 요구 내의 제2 속성은 길이(length)이다. 이것은 AssociationType 및 Length 필드 자체를 포함하는 이 요구 내의 모든 속성들의 총 길이이다. 이것은 구문분석에 도움을 주기 위해 이용되고, 따라서 컴포넌트가 특정 AssociationType에 흥미가 없다면, 그것은 요구 내의 각 속성을 구문분석해야 하는 것과는 대조적으로 전체 요구를 건너뛸(skip over) 수 있다.

이 예에서, length의 바로 다음에 오는 속성(들)은 단순한 장치들이 최소의 처리로 기본 연결을 구현할 수 있도록(예컨대, 펌웨어 없이 실리콘만의 해법(silicon-only solutions)을 갖는 장치(들)) 하기 위하여 신중하게 정의된다. 이를 달성하기 위하여, 원하는 데이터를 추출하기 위하여 구조 내의 사전 정의된 오프셋으로 간단히 점프할 수 있다면 유용할 수 있다. 따라서, 이 예에서, length의 바로 다음에 오는 속성들은 기본 연결을 수행하기 위해 필요한 데이터의 최소량을 포함한다. 또한, 그 속성들은 사전 정의된 순서로 배치되고 항상 존재할 수 있다. 일 예에서, 이 필요한 데이터의 사실상 전부가 단일 속성 내에 포함된다. 이 예에서, 연결 요구 내의 오프셋에 영향을 미치지 않도록 이들 기본 속성들의 끝에 임의의 가변 길이 필드들이 위치한다.

다른 예에서, 각각이 소량의 데이터를 포함하는 수 개의 속성들이 이용된다. 따라서, 예를 들면, 확장된 기능성을 제공하기 위하여 임의의 수의 속성(들)(만일 있다면)이 다음에 올 수 있다는 것을 이해해야 할 것이다.

연결 응답

도 3을 참조하면, 본 발명의 일 양태에 따른 연결 응답(300)이 예시되어 있다. 연결 응답(300)은 연결 응답 헤더(310) 및 0, 또는 1 이상의 연결 응답 속성(들)(320)을 포함한다. 예를 들면, 연결 응답 헤더(310)는 연결 응답 속성(들)(320)에 관하여 아래에서 설명되는 것들과 포맷이 유사한 전역적으로 정의된 응답 속성(들)의 세트를 포함할 수 있다.

연결 응답 속성(320)은 속성 유형, 길이, 및 데이터를 포함하는 하나의 데이터(a piece of data)이다. 위에서 논의된 연결 요구와 유사하게, 일 예에서, 연결 응답은 일련의 속성들이다. 이 예에서, 제1 속성은 연결 유형(AssociationType)이다. 이것은 이 응답을 초래한 연결 요구의 AssociationType을 반향(echo)시키기 위해 이용된다.

연결 응답 내의 제2 속성은 길이(length)이다. 이것은 AssociationType 및 length 필드 자체를 포함하는 이 응답 내의 모든 속성들의 총 길이이다. 이것은 구문분석에 도움을 주기 위해 이용되고, 따라서 컴포넌트가 특정 AssociationType에 흥미가 없다면, 그것은 응답 내의 각 속성을 구문분석해야 하는 것과는 대조적으로 응답을 건너뛸 수 있다.

연결 응답의 제3 속성은 연결 상태(AssociationStatus)이다. 이것은 연결 요구의 결과에 대하여 장치에 통지하기 위해 사용된다. 이 예에서, 연결 처리가 성공하였다면, 이 값은 0x0000일 것이고, 이것은 장치가 연결 응답 내의 속성들을 계속해서 판독할 수 있다는 것을 의미한다. 만일 그 값이 0xc0001이면, 호스트는 그 특정 AssoclationType을 처리할 수 있는 핸들러를 찾을 수 없을 것이다. 이 경우, 장치는 연결 응답 내의 후속 속성들에 대하여 어떤 가정도 하지 않아야 한다.

AssociationStatus의 바로 다음에 오는 속성(들)은 위에서 논의한 바와 같이 단순한 장치들이 최소의 처리로 기본 연결을 구현할 수 있도록 하기 위해 신중하게 정의될 수 있다. 이 예에서, 이를 달성하기 위하여, 원하는 데이터를 추출하기 위하여 구조 내의 사전 정의된 오프셋으로 간단히 점프할 수 있는 것이 필요하다. 따라서 이들 속성들은 기본 연결을 수행하기 위해 필요한 데이터의 최소량을 포함한다. 그것들은 또한 이 예에서 사전 정의된 순서로 배치되고 항상 존재한다. 연결 응답 내의 오프셋에 영향을 미치지 않도록 이들 기본 속성들의 끝에 임의의 가변 길이 필드들이 위치한다. 확장된 기능성을 제공하기 위하여 임의의 수의 속성들(만일 있다면)이 다음에 올 수 있다.

도 4를 참조하면, 본 발명의 일 양태에 따른 연결 관리 시스템(400)이 예시되어 있다. 연결 관리 시스템(400)은 관리자 통신 컴포넌트(420) 및 핸들러 식별 컴포넌트(430)를 포함하는 연결 관리자(410)를 포함한다. 이 시스템(400)은 또한 핸들러 레지스트리(150), 및, 옵션으로, 드라이버 레지스트리(160)를 포함한다.

연결 관리자(410)는 연결 데이터(예컨대, 연결 요구(들) 및/또는 연결 응답(들))를 적절한 컴포넌트들(예컨대, 핸들러 및/또는 드라이버)에 제공하는 책임이 있다. 관리자 통신 컴포넌트(420)는 드라이버(들)(도시되지 않음)로부터 연결 요구(들)를 수신할 수 있다. 관리자 통신 컴포넌트(420)는 연결 요구의 적어도 일부(예컨대, 연결 요구 헤더)를 핸들러 식별 컴포넌트(430)에 제공할 수 있다.

관리자 통신 컴포넌트(420)에 의해 제공된 정보 및 핸들러 레지스트리(150)에 저장된 식별 정보에 기초하여, 핸들러 식별 컴포넌트(430)는 연결 요구가 제공되어야 할 특정 핸들러(도시되지 않음)를 식별한다. 일 예에서, 연결 관리자(410)는 핸들러 식별 컴포넌트(40)에 의해 식별된 핸들러를 로딩한다. 다른 예에서, 핸들러(들)는 초기화(아래에서 보다 상세히 논의됨)에서 로딩된다. 그 후, 관리자 통신 컴포넌트(420)는 연결 요구와 관련된 정보를 핸들러 식별 컴포넌트(430)에 의해 식별된 핸들러에 제공한다.

일단 핸들러가 연결 요구를 처리하면, 핸들러는 연결 응답을 관리자 통신 컴포넌트(420)에 제공한다. 관리자 통신 컴포넌트(420)는 그 후 연결 응답을 요구 드라이버에 제공한다.

일 예에서, 연결 관리자(410)는 연결 요구를 유효성 검사(validate)한다. 예를 들면, 연결 관리자(410)는 적격(well-formed)인지 여부를 판정할 수 있다. 만일 요구가 적격이 아니면, 연결 관리자(410)는 연결 요구가 기형(malformed)임을 지시하는 연결 응답(예컨대, 상태 속성이 ERROR_MALFORMED_ASSOCIATI0N_REQUEST로 설정됨)을 생성하고 그 연결 응답을 요구 드라이버에 제공할 수 있다. 이 예에서, 연결 관리자(410)는 연결 요구가 적격인지를 판정하기 위해 다음의 조건들(criteria)을 이용한다:

a. 요구 길이는 적어도 Association Type 및 Length 속성들을 유지할 만큼 크다(예컨대, 36 바이트);

b. 제1 속성은 Association Type이고 그것의 길이는 적절한 사이즈이다(예컨대, 특정 핸들러와 관련된 GUID(globally unique identifier)에 기초하여);

c. 제2 속성은 Length이고 적절한 사이즈를 갖는다(예컨대, ULONG);

d. Length 속성의 값은 Association Type 및 Length 속성들보다 크고(예컨대, 36 바이트), 요구의 길이보다 작거나 그와 같다;

e. 다음에 오는 각 속성은 요구 내의 그것의 현 위치에 추가될 때 Length 속성 내의 값보다 큰 값으로 되지 않는 길이를 갖는다;

f. 정확히 하나의 연결 유형(association type) 속성 및 정확히 하나의 Length 속성이 요구 내에 존재한다.

다음으로, 연결 관리자(410)는 연결 요구에 포함된 특정 연결 유형에 대하여 등록된 핸들러가 있는지를 판정한다(예컨대, 핸들러 레지스트리(150)에 저장된 GUID). 만일 핸들러가 발견되지 않으면, 연결 관리자(410)는 요구된 연결 유형이 지원되지 않음을 지시하는 연결 응답을 생성하고 그 연결 응답을 요구 드라이버에 제공할 수 있다.

만일 핸들러가 발견되면, 이 예에서, 연결 관리자(410)는 연결 요구를 구문분석하고 속성(들)의 목록을 추출할 수 있다. 연결 관리자(410)는 그 후 추출된 속성(들)의 목록을 특정 핸들러에 제공할 수 있다.

만일 연결 관리자(410)가 추출된 속성(들)의 목록을 특정 핸들러에 제공하는 데 성공하지 못하면, 연결 관리자(410)는 특정 핸들러가 응답하지 않았음을 지시하는 연결 응답을 생성하고 그 연결 응답을 요구 드라이버에 제공할 수 있다.

만일 연결 관리자(410)가 추출된 속성(들)의 목록을 특정 핸들러에 제공하는 데 성공하면, 핸들러에 의한 처리의 완료 시에, 이 예에서, 연결 관리자(410)는 핸들러로부터 연결 응답 속성 목록을 수신하다. 연결 관리자(410)는 연결 응답 속성 목록이 적격인지를 판정할 수 있다. 예를 들면:

a. 정확히 하나의 상태 속성이 있다;

b. Length 속성 및 연결 유형 속성이 존재하지 않는다(예컨대, 연결 관리자(410)에 의해 추가될);

c. 연결 요구가 최대 응답 길이 속성을 포함하면, 속성들의 총 사이즈는 그 값보다 작아야 한다.

만일 응답이 적격이면, 연결 관리자(410)는, 적어도 부분적으로, 연결 응답 속성 목록에 기초하여 연결 응답(예컨대, 바이트 어레이)을 생성한다. 예를 들면, 연결 관리자(410)는:

a. 응답 속성 목록 내의 모든 속성들의 총 사이즈를 추가할 수 있고;

b. 연결 유형 및 길이 속성들을 위하여 필요한 사이즈를 추가할 수 있고;

c. 응답을 유지할 만큼 큰 버퍼를 할당할 수 있고;

d. 버퍼 내의 제1 속성을 연결 요구로부터의 연결 유형으로 설정할 수 있고;

e. 계산된 응답 길이를 이용하여 버퍼에 길이 속성을 추가할 수 있고;

f. 연결 상태 속성을 추가할 수 있고;

g. 각각의 추가 속성을 목록에 있던 순서로 추가할 수 있다.

연결 관리자(410)는 그 후 연결 응답을 요구 드라이버에 제공할 수 있다.

일 예에서, 연결 관리자는 다음의 인터페이스를 구현한다:

연결 처리를 시작하기 위하여 드라이버(들)에 의해 SendAssociationRequest()가 호출된다. 연결 응답은 장치에 용이하게 반송(sent back)될 수 있는 바이트 어레이로서 반환된다. 일 예에서, AssociationResponse를 자유롭게 하는(free) 것은 드라이버의 책임이다.

도 5를 참조하면, 본 발명의 일 양태에 따른 연결 관리 시스템(500)이 예시되어 있다. 이 시스템(500)은 연결 관리자(510), 핸들러 레지스트리(150), 드라이버 레지스트리(160) 및 초기화 컴포넌트(520)를 포함한다.

연결 관리자(510)는, 이전에 논의한 바와 같이, 연결 데이터(예컨대, 연결 요구(들) 및/또는 연결 응답(들))를 적절한 컴포넌트들(예컨대, 핸들러 및/또는 드라이버)에 제공하는 책임이 있다. 그러나, 이 예에서, 초기화 컴포넌트(520)는 드라이버 레지스트리(160)에 저장된 정보를 이용하여, 예를 들면, 시스템(500)의 초기화 중에, 하나 이상의 드라이버들(도시되지 않음) 중 어느 것을 초기화할지를 판정할 수 있다. 예를 들면, 드라이버(들)는 컴퓨터 시스템(도시되지 않음)의 구성 동안에 등록될 수 있다(예컨대, 수동으로 및/또는 자동으로).

일 예에서, 시스템 초기화 시에, 초기화 컴포넌트(520)는, 적어도 부분적으로 드라이버 레지스트리(160) 및 핸들러 레지스트리(150)에 각각 저장된 정보에 기초하여 드라이버(들) 및 핸들러(들)를 식별한다. 그 후, 초기화 컴포넌트(520)는 식별된 핸들러(들) 및 식별된 드라이버(들)의 인스턴스들을 생성한다.

이 예에서, 핸들러들 각각에 대하여, 연결 관리자(510)는 연결 유형 카운트를 검색(retrieve)하고 관련 저장 버퍼를 할당한다(예컨대, association type count* sizeof(GUID)). 이 버퍼는 핸들러로부터 연결 유형들을 검색하는 데 이용될 수 있다. 다른 예에서, 핸들러는 저장 공간을 할당하고 그것을 연결 관리자에 제공한다.

연결 유형들은 핸들러가 지원하는 특정 연결 유형들을 나타내는 GUID들의 어레이일 수 있다. 검색된 GUID들의 각각에 대하여, 핸들러 레지스트리에 저장된 GUID 대 핸들러 매핑들(GUID to Handler mappings)의 목록에 엔트리가 추가될 수 있다. 예를 들면:

이 매핑들의 목록은 그 후 연결 관리자(510)에 의해 적절한 핸들러로의 연결 요구들의 라우팅을 결정하는 데 이용될 수 있다.

이 예에서, 일단 핸들러들이 생성되고 그들의 연결 유형들이 발견되면, 초기화 컴포넌트(520)는 드라이버들을 활성화한다. 활성화(activation)는 핸들러들이 발견되어 로딩될 때까지 연결 요구(들)가 수신되지 않도록 핸들러들이 로딩된 후에 발생한다. 예를 들면, 드라이버를 활성화하기 위하여, "Start()" 메서드가 호출될 수 있다.

다음으로, 도 6을 참조하면, 본 발명의 일 양태에 따른 연결 핸들러 시스템(600)이 예시되어 있다. 이 시스템(600)은 요구 컴포넌트(620), 응답 컴포넌트(630) 및 연결 프로세서(640)를 포함하는 핸들러(610)를 포함한다.

핸들러(610)는 (아마도 다른 컴포넌트(들)(도시되지 않음)와 함께) 연결 요구를 소비하고 연결 요구와 관련된 정보를 생성한다.

예를 들면, 요구 컴포넌트(620)는 연결 관리자(도시되지 않음)로부터 연결 요구와 관련된 정보(예컨대, 연결 요구 및/또는 구문분석된 속성들의 목록)를 수신할 수 있다. 요구 컴포넌트(620)는 연결 요구와 관련된 정보의 콘텐츠를 구문분석하여 어떤 액션(들)을 취할지를 판정할 수 있다. 연결 프로세서(640)는 서비스(650)를 통하여 액션(들)을 용이하게 한다. 액션(들)은, 예를 들면, 수립하려고 하는 접속 유형에 의존할 수 있다. 일단 액션(들)이 완료되면, 연결 프로세서(640)는 연결에 관한 정보를 응답 컴포넌트(630)에 제공할 수 있다. 응답 컴포넌트(630)는 그 후 연결 응답과 관련된 정보(예컨대, 연결 응답 및/또는 속성들의 목록)를 생성할 수 있고 이 정보는 연결 관리자에 제공될 수 있다.

일 예에서, 복수의 핸들러(610)가 다음의 COM 인터페이스를 구현한다:

이 예에서, "관리자(manager)"는 연결 관리자에의 인터페이스 포인터이다. 또한, "AssociationTypes"는 PONG 핸들러가 처리할 수 있는 AssociationType GUID들의 어레이를 반환한다. 유사하게, "AssociationTypeCount"는 PONG 핸들러가 처리할 수 있는 AssociationType들의 수이다. "HandleAssociationRequest()"는 연결 관리자가 핸들러(610)가 지원한다고 보고한 연결 요구를 수신할 때 연결 관리자에 의해 호출된다. "RequestAttributes"는 속성 구조들의 목록이다. 핸들러(610)는 장치(도시되지 않음)에 반환될 속성들인 속성 구조들의 목록인 ResponseAttributes를 반환하는 데 필요한 메모리를 할당할 것으로 기대된다.

다른 예에서, 핸들러(610)는 장치에 관한 정보를, 예를 들면, 대상 매체(target medium)에서 그 장치가 발견되면 나중에 설치하기 위해 데이터베이스에 저장한다. 예를 들면, 특정 핸들러(610)는 Wi-Fi 대상 매체에 관련될 수 있다. 이 예에서, Wi-Fi 대상 매체를 이용하기를 원하는 장치(들)는 속성 목록들의 형태로 연결 요구(들)를 송신하고 연결 응답(들)을 수신한다. 속성 목록들은 핸들러(610)에 의해 연결 관리자에 제공될 수 있고 연결 관리자는 그 후 연결 응답을 형성할 수 있다.

아래 표 9, 10 및 11에 관련하여, "속성(attribute)"은 속성 요소와 관련된 친근한 이름(friendly name)을 나타낸다. "속성 ID(Atrribute ID)"는 속성 목록에서 속성 요소를 식별하기 위해 사용되는 식별자(예컨대, 번호)이다. "길이(Length)"는 속성 요소 내의 데이터의 길이를 나타낸다. 속성 길이들은 변할 수 있고 및/또는 고정될 수 있고, 이 예에서는, 바이트로 표현된다. 길이 값은 또한 최대 길이를 특정할 수 있다. 연결 응답에서, 일 예에서는, 고정 길이가 이용되어 그 값에의 오프셋이 결정적(deterministic)일 수 있고; 응답을 구문문석하는 장치의 능력을 돕는다. 속성의 실제 값은 데이터에 대하여 할당된 전체 길이까지 사용하지 않을 수 있다. 이들 경우에, 추가 필드가 속성 데이터의 실제 길이를 특정할 수 있다. "허용 값들(Allowed Values)"은 장치에 의해 지원될 값들을 기술하는 허용 값 필드를 나타낸다. 만일 허용 값이 요구된다면, 그것은 그 값이 속성 목록에 포함되면 장치가 그 값을 지원해야 함을 의미한다. 표 9, 10 및/또는 11에서 다르게 기술하지 않는 한, 값들은 요구되는 것으로 가정되어야 한다. 만일 허용 값이 옵션(optional)이면, 장치는 그 값을 지원할 필요는 없지만, 그것이 속성 목록에 포함되는 것에 준비되어 있어야 한다. 옵션 값들은 이 사양의 다음 버전에서 필요하게 될 수 있다.

무선 프로토콜

IEEE 802.11 표준 세트는 2가지 네트워크 유형을 정의한다: 암호화(encrypted) 네트워크(예컨대, WEP 네트워크) 및 비암호화(unencrypted) 네트워크. WEP 프로토콜의 잘 알려진 취약성 때문에, 무선 업계는 WEP 프로토콜에서의 키 결함(key deficiencies)을 다루기(address) 위한 메커니즘으로서 IEEE 802.1x 표준에 대한 지원을 구현하였고, 그것들은 사용자 인증, 암호화 키 관리 및 암호화 키 분배이다. WEP-암호화 네트워크의 경우, 사용자는 암호화 키를 제공할 필요가 있고 802.1x 가능 네트워크의 경우 사용자가 유효한 자격 증명(valid credential)(예컨대, 디지털 인증서 또는 사용자명(username) 및 암호(password))을 갖고 있다면 키는 자동으로 제공된다. 암호화되어 있는 802.11 네트워크의 경우, 이것은 사용자가 WEP 키를 입력할 필요가 있는지 또는 네트워크가 802.1x를 지원하여 사용자가 그것을 입력할 필요가 없는지를 연역적으로 판정하는 것이 현재는 가능하지 않기 때문에 가용성(usability) 문제를 제기한다.

암호적으로 취약한 것으로 드러난 WEP 알고리즘의 근원적인 취약성을 다루기 위해, Wi-Fi 보호 액세스(WPA: Wi-Fi Protected Access)라 불리는, 802.11 표준 세트에 대한 보안 강화가 도입되었다. WPA는 또한 WPA-가능(WPA-capable) 액세스 지점(access point)들이 그들의 비컨 프레임(beacon frame)에 포함시키는 정보 요소를 특정함으로써 최초 802.11 표준의 가용성 문제들의 일부를 다룬다. 이 정보 요소는 특히 네트워크가 사용자에게 WPA 사전 공유 키 모드(WPA-PSK: WPA pre-shared key mode)라 불리는 암호화 키를 입력할 것을 요구하는지 또는 "WPA 모드"라 불리는, 사용자의 인증서 덕분에 키가 자동으로 제공되는지를 기술한다.

WEP( Wired Equivalent Privacy )

WEP는 IEEE 802.11 표준에 의해 정의되고 유선 네트워크에 상당하는 데이터 기밀성의 수준을 제공하도록 의도되어 있다. 무선 LAN 네트워크의 특성으로 인해, 네트워크에의 물리적 액세스를 모니터하는 보안 인프라(security infrastructure)를 구현하는 것이 어려울 수 있다. 물리적 접속이 요구되는 유선 네트워크와 달리, 무선 액세스 지점(AP)의 범위 내의 누구든지 프레임을 송신 및 수신할 수 있을 뿐만 아니라 송신되고 있는 다른 프레임들을 청취하려고 할 수 있다고 생각된다. 이것은 무선 LAN 프레임들의 도청(eavesdropping) 및 원격 엿보기(remote sniffing)를 매우 용이하게 한다.

WEP는 무선 노드들 간에 송신되는 데이터를 암호화함으로써 데이터 기밀성 서비스를 제공한다. 802.11 프레임에 대한 WEP 암호화는 802.11 프레임의 MAC 헤더에 WEP 플래그를 설정함으로써 나타내어진다. WEP는 무선 프레임의 암호화된 부분에 무결성 체크 값(ICV: integrity check value)을 포함시킴으로써 임의 오류들에 대한 데이터 무결성을 제공한다.

다음의 표들은 WEP가 정의하는 2개의 공유 키들을 예시한다:

키 유형	설명
멀티캐스트/전역(global) 키	무선 AP로부터 그것의 접속된 무선 클라이언트들 모두로의 멀티캐스트 및 브로드캐스트 트래픽을 보호하는 데 도움을 주는 암호화 키.
유니캐스트 세션 키	무선 클라이언트와 무선 AP 간의 유니캐스트 트래픽 및 무선 클라이언트에 의해 무선 AP로송신되는 멀티캐스트 및 브로드캐스트 트래픽을 보호하는 데 도움을 주는 암호화 키.

WEP 암호화는 40비트 및 104비트 암호화 키를 갖는 RC4 대칭 스트림 암호(symmetric stream cipher)를 이용한다.

Wi - Fi 보호 액세스( WPA : Wi - Fi Protected Access )

WPA는 WEP의 보안 특징들을 개량하기 위해 설계된 Wi-Fi 표준이다. WEP와 달리, WPA에서는 802.1x 인증이 요구된다. WPA에 의하면, 유니캐스트 암호화 키 및 전역 암호화 키 양쪽 모두의 키 재생성(rekeying)이 요구된다. 유니캐스트 암호화 키의 경우, TKIP(Temporal Key Integrity Protocol)는 모든 프레임에 대해 키를 변경하고, 이 변경은 무선 끌라이언트와 무선 액세스 지점(AP) 간에 동기화된다. 전역 암호화 키의 경우, WPA는 무선 AP가 변경된 키를 접속된 무선 클라이언트들에 알리는 기능을 포함한다.

TKIP는 WEP를 WEP 알고리즘보다 강력한 암호화 알고리즘으로 대체한다. TKIP는 또한 암호화 키들이 결정된 후 보안 구성의 확인; 각 프레임에 대한 유니캐스트 암호화 키의 변경 동기화; 및 각각의 사전 공유 키 인증을 위해 고유한 시작 유니캐스트 암호화 키의 결정을 제공한다.

WPA는 또한 8바이트 메시지 무결성 코드(MIC)를 계산하는 알고리즘을 지정하는 "Michael"로 알려진 방법을 이용한다. MIC는 IEEE 802.11 프레임의 데이터 부분과 4바이트 무결성 체크 값(ICV) 사이에 놓인다. MIC 필드는 프레임 데이터 및 ICV와 함께 암호화된다.

WPA는 그것의 완료 시에 IEEE의 802 11 표준으로 대체될 임시 표준이다.

Wi - Fi 핸들러

연결 유형(association type)은 연결 요구 및 연결 응답의 헤더 부분에 포함된 속성이고, 데이터 속성들과는 별개이다. 이 속성은 연결 관리자에 의해 연결 요구(들)를 정확한 핸들러에 전송하는 데 이용된다. 이 예에서, Wi-Fi 핸들러(610)는 다음의 요구되는 연결 유형을 갖는다:

속성:	속성 ID	길이	R/O	허용 값들
연결 유형	0x0000	16B	R	F55BDC92-7827-4C91-B784-0EC8A152FADA

연결 요구의 데이터 부분은 연결 유형에 특정한 속성들을 포함한다. 다음의 표는 연결 관리자가 Wi-Fi 핸들러(610)에 전송할 수 있는 예시적 속성들을 식별한다:

속성:	속성 ID	길이	R/0	허용 값들
MAC 주소	0x1001	6B	O	장치 상의 802.11 인터페이스에 대응하는 48 비트 값
네트워크 인증 유형 플래그들	0x1002	2B	R	이들 플래그들은 장치가 어느 유형의 네트워크 인증 유형들이 지원되는지를 통신할 수 있게 한다. (1 = 지원됨, 0 = 지원되지 않음): 이 필드의 값은 다음의 값들 중 하나 이상의 비트단위 OR이다: 0x0001 = 개방(Open) 0x0002 = WPAPSK 0x0004 = 공유(Shard) 0x0008 = WPA 0x0010 = WPA-NONE 0x0020 = WPA2 모든 다른 값들은 예비되고 0으로 설정될 것이다.
데이터 암호화 유형 플래그들	0x1003	2B	R	이들 플래그들은 장치가 어느 유형의 "데이터 암호화 유형"이 지원되는지를 통신할 수 있게 한다. (1 = 지원됨, 0 = 지원되지 않음): 이 필드의 값은 다음의 값들 중 하나 이상의 비트단위 OR이다: 0x0001 = WEP 0x0002 = TKIP 0x0004 = AES 모든 다른 값들은 예비되고 0으로 설정될 것이다.
접속 유형 플래그들	0x1004	1B	R	이들 플래그들은 장치가 어느 유형의 "접속 유형"이 지원되는지를 통신할 수 있게 한다. (1 = 지원됨, 0 = 지원되지 않음): 이 필드의 값은 다음의 값들 중 하나 이상의 비트단위 OR이다: 0x01 = ESS 0x02 = IBSS 모든 다른 값들은 예비되고 0으로 설정될 것이다.

MAC 주소

MAC 주소는 MAC 주소의 48비트 값을 포함하는 6바이트 값이다. 예를 들면, OxOO OxO7 OxE9 Ox4C OxA8 Ox1C.＼

네트워크 인증 유형 플래그들( Network Authentication Type Flags )

이 플래그 세트는 장치가 어느 "네트워크 인증 유형" 유형들이 지원되는지를 신호하게 한다. 이 정보는 진단 목적으로 이용될 수 있다. 만일 장치가 요구되는 속성들을 지원하지 못하면, 사용자에게 이를 통지하고 그 문제를 정정하기 위한 액션 가능한 지시를 제공할 수 있다. 이 예에서, 이 필드의 값은 다음의 값들 중 하나 이상의 비트단위(bitwise) OR이다:

0x0001 = 개방(Open)

0x0002 = WPAPSK

0x0004 = 공유(Shard)

0x0008 = WPA

0x0010 = WPA-NONE

0x0020 = WPA2

이 예에서, 다른 값들은 예비되고 0으로 설정된다.

데이터 암호화 유형 플래그들( Data Encryption Type Flags )

이 플래그 세트는 장치가 어느 "데이터 암호화 유형" 유형들이 지원되는지를 신호하게 한다. 이 정보는 진단 목적으로 이용될 수 있다. 만일 장치가 요구되는 속성들을 지원하지 못하면, 사용자에게 이를 통지하고 그 문제를 정정하기 위한 액션 가능한 지시를 제공할 수 있다. 이 예에서, 이 필드의 값은 다음의 값들 중 하나 이상의 비트단위 OR이다:

0x0001 = WEP

0x0002 = TKIP

0x0004 = AES

이 예에서도, 다른 값들은 예비되고 0으로 설정된다.

접속 유형 플래그들( Connection Type Flags )

이 플래스 세트는 장치가 어느 "접속 유형" 유형들이 지원되는지를 신호하게 한다. 이 정보는 진단 목적으로 이용된다. 만일 장치가 요구되는 속성들을 지원하지 못하면, 사용자에게 이를 통지하고 그 문제를 정정하기 위한 액션 가능한 지시를 제공할 수 있다. 이 필드의 잘은 다음의 값들 중 하나 이상의 비트단위 OR이다:

0x01 = ESS(Extended Service Set)

0x02 = IBSS(Independent Basic Service Set)

이 예에서, 다른 값들은 예비되고 0으로 설정된다.

적어도 부분적으로, 핸들러(610)의 서비스(650)와의 상호작용에 기초하여, 응답 컴포넌트(630)는 연결 응답과 관련된 정보를 생성한다. Wi-Fi 핸들러의 예에서 계속하여, 표 11은 예시적인 연결 응답 속성들을 식별한다. 이 예의 속성 목록 내의 속성들의 길이들은 고정된다. 따라서, 장치 제조업자는 적절한 오프셋으로 쉽사리 점프하여 응답 내의 임의의 주어진 속성의 값을 판독할 수 있다. 오프셋은 속성의 시작을 나타낸다.

속성:	속성 ID	길이	R/O	허용 값들
SSID (오프셋=x0013)	0x2001	32B	R	길이가 0에서 32개인 문자들의 문자열이고, 인쇄 가능한 8비트 ASCII 문자들로 이루어짐
SSID 길이 (오프셋=x0034)	0x2002	1B	R	SSID 속성의 길이를 바이트로 나타내는 0-32 사이의 정수 값
네트워크 키 (오프셋=x0036)	0x2003	64B	R	길이가 0에서 64개인 8비트 ASCII 문자들의 문자열. 보다 상세는 섹션 5.6.2의 네트워크 키 속성 설명에 포함되어 있음
네트워크 키 길이 (오프셋=x0077)	0x2004	1B	R	네트워크 키 속성의 길이를 바이트로 나타내는 6-64 사이의 정수 값
자동 제공 키 (802 1x) (오프셋=x0079)	0x2005	1B	R	부정(no)에 대해서는 0, 긍정(yes)에 대해서는 1은 인증 유형과 대응해야 한다. 상세에 대해서는 설명 참조
네트워크 인증 유형: (오프셋=x007B)	0x2006	2B	R	이들 플래그는 네트워크 인증 유형들을 규정한다. 한번에 하나의 플래그만 설정될 것이다. 응답은 다음 값들 중 하나일 것이다: 0x0001 = 개방(Open) 0x0002 = WPAPSK 0x0004 = 공유(Shard) 0x0008 = WPA 0x0010 = WPA-NONE 0x0020 = WPA2 모든 다른 값들은 예비되고 0으로 설정될 것이다.
데이터 암호화 유형 (오프셋=x007E)	0x2007	2B	R	이들 플래그는 "데이터 암호화 유형"을 규정한다. 한번에 하나의 플래그만 설정될 것이다. 응답은 다음 값들 중 하나일 것이다: 0x0001 = WEP 0x0002 = TKIP 0x0004 = AES 모든 다른 값들은 예비되고 0으로 설정될 것이다.
접속 유형 (오프셋=x0081)	0x2008	1B	R	이들 플래그는 "접속 유형"을 규정한다. 한번에 하나의 플래그만 설정될 것이다. 응답은 다음 값들 중 하나일 것이다: 0x01 = ESS 0x02 = IBSS 모든 다른 값들은 예비되고 0으로 설정될 것이다.

SSID

SSID는 이전에 논의한 바와 같이 브로드캐스팅 무선 네트워크에서 이용되는 문자열이다.

네트워크 키( Network Key )

네트워크 키는 네트워크를 안전하게 위해 사용되는 문자열이다. 이 예에서, 다음의 속성들은 네트워크 키의 허용 값들에 대한 제약으로서 배치된다. 장치는 다음의 구성들을 수락하거나 거절하도록 준비되어야 할 것이다.

네트워크 인증 유형	데이터 인증 유형	유효 네트워크 키 값
WPA	TKIP	0-63 ASCII 문자, 64 HEX 문자
WPA	AES	0-63 ASCII 문자, 64 HEX 문자
개방(Open)	WEP	5 또는 13 ASCII 문자, 10 또는 26 HEX 문자

WEP 키

데이터 인증(data auth) 유형이 WEP인 경우, 네트워크 키는 40비트 또는 104비트 WEP 키의 ASCII 또는 HEX 표현이다. 유형은 문자열의 길이에 의해 결정될 수 있다.

WPAPSK 패스 구문( pass pharase )

만일 네트워크 키 속성이 0-63 문자 ASCII 문자열이고 "네트워크 인증 유형" 속성이 WPA이면, 네트워크 키 속성은 WPA 바이너리 키를 도출하는 패스 구문으로서 이용된다.

자동 제공 키( Key Provided Automatically )(802.1x)

"자동 제공 키(802.1x)" 속성은 네트워크 키가 801.x를 통하여 제공되는지 여부를 기술한다. 무선 네트워크를 안전하게 하기 위해 WPA-PSK, 또는 WEP가 이용되는 경우에 이것은 전형적으로 0으로 설정된다.

네트워크 인증 유형( Network Authentication Type )

네트워크 인증 유형은 특정 네트워크를 연결하기 위해 어떤 유형의 보안 메커니즘이 요구되는지를 지시한다. 이 플래그 세트는 다음의 메커니즘들 중 어느 것이 이용되는지를 지정한다.

0x0001 = 개방(Open)

0x0002 = WPAPSK

0x0004 = 공유(Shard)

0x0008 = WPA

0x0010 = WPA-NONE

0x0020 = WPA2

이 예에서, 다른 값들은 예비되고 0으로 설정된다. 중요한 것은, 연결 요구와 달리, 이들 플래그는 상호 배타적이다 - 주어진 시간에 하나의 플래그만 설정될 수 있다.

데이터 암호화 유형( Data Encryption Type )

이 값은 무선 네트워크에 의해 전개되는 암호화 메커니즘을 지정한다. 이 플래그 세트는 다음의 메커니즘들 중 어느 것이 이용되는지를 지정한다:

0x0001 = WEP

0x0002 = TKIP

0x0004 = AES

모든 다른 값들은 예비되고 0으로 설정된다. 중요한 것은, 연결 요구와 달리, 이들 플래그는 상호 배타적이다 - 주어진 시간에 하나의 플래그만 설정될 수 있다.

접속 유형( Connection Type )

접속 유형은 무선 네트워크의 유형을 정의한다. 이 플래그 세트는 다음의 메커니즘들 중 어느 것이 이용되는지를 지정한다:

0x01 = ESS

0x02 = IBSS

모든 다른 값들은 예비되고 0으로 설정된다. 이들 플래그는 상호 배타적이다.

다음으로 도 7을 참조하면, 본 발명의 일 양태에 따른 연결 드라이버 시스템(700)이 예시되어 있다. 이 시스템(700)은 신뢰할 수 있는 매체 통신 컴포넌트(720) 및 드라이버 통신 컴포넌트(730)를 포함하는 드라이버(710)를 포함한다.

신뢰할 수 있는 매체 통신 컴포넌트(720)는 신뢰할 수 있는 매체(예컨대, USB 접속)를 통하여 장치(740)와 인터페이스한다. 일 예에서, 신뢰할 수 있는 매체 통신 컴포넌트(720)는 장치(740)로부터 연결 요구를 수신한다(예컨대, 장치 열거(device enumeration)와 무관한 시간에 개시된 연결 요구). 다른 예에서, 신뢰할 수 있는 매체 통신 컴포넌트(720)는 연결 요구를 발행하기 위한 요구의 통지를 수신한다. 그 후, 드라이버(710)는 드라이버 통신 컴포넌트(730)를 통하여 연결 관리자(도시되지 않음)에 송신되는 연결 요구를 생성한다.

일 예에서, 드라이버(들)(710)는 다음의 인터페이스를 구현한다:

"관리자(Manager)"는 드라이버가 SendAssociationRequest를 호출할 수 있도록 하는 연결 관리자에의 인터페이스 포인터이다. Start()는 연결 관리자가 드라이버가 새로운 연결 요구들을 검출 및 발행하는 것을 시작하기를 원할 때 연결 관리자에 의해 호출된다. Stop()은 연결 관리자가 드라이버가 새로운 연결 요구들을 발행하는 것을 중지하기를 원할 때(즉, 사용자가 특정 신뢰할 수 있는 매체를 통한 연결을 디스에이블하기를 원할 때) 연결 관리자에 의해 호출된다.

일 예에서, 특정 드라이버(710)는 USB 신뢰할 수 있는 매체에 관련될 수 있다. 신뢰할 수 없는 매체를 이용하기를 원하는 장치(들)는 드라이버(710)를 통하여 안전하게 연결 요구(들)를 송신하고 연결 응답(들)을 수신한다.

장치 열거와 무관하게 연결 요구들이 생성될 수 있는, 동적인 연결 기능성(dynamic association functionality)을 구현하는 장치(들)의 경우, 일 예에서는, 옵션인 인터럽트 IN 엔드포인트가 있다. 이 엔드포인트는 새로운 연결 요구들의 통지를 용이하게 한다. 이 옵션인 엔드포인트에 대한 표준 엔드포인트 설명자를 표 14에서 찾을 수 있다:

오프셋	필드	사이즈	값	설명
0	bLength	1	07h	이 설명자의 바이트 사이즈
1	bDescriptorType	1	05h	엔드포인트(ENDPOINT) 설명자 유형
2	bEndpointAddress	1	81-8Fh	USB 장치 상의 이 엔드포인트의 주소. 이 주소는 1과 15 사이의 엔드포인트 번호이다. 비트 0..3 엔드포인트 번호 비트 4..6 예비, 0이어야 한다 비트 7 1=In
3	bmAttributes	1	03h	이것은 인터럽트 엔드포인트이다
4	wMaxPacketSize	2	00??h	최대 데이터 전송 사이즈
6	bInterval	2	??h	데이터 전송을 위해 엔드포인트를 폴링하는 간격. 밀리초로 표현된다. 1 내지 255의 범위 내에 있어야 한다. 권장되는 값은 255이다.

만일 장치의 인터페이스가 옵션인 엔드포인트를 포함하지 않으면, 연결은 열거 시간(enumeration time)에만 발생할 것이다. 만일 그러한 장치가 연결 프로세스를 개시하기를 원하면, 그것은 장치 개시(device initiated) USB 리셋을 행해야 할 것이다. 이로 인해 장치가 호스트에 의해 재열거(re-enumerate)될 것이고, 그 시점에서 호스트는 장치로부터 연결 요구(들)를 검색할 것이다. 다른 예에서, 장치는 또한 장치가 원할 때 연결 기능이 오고 갈 수 있게 하는 HUB 기능성을 구현할 수 있다.

제어 엔드포인트는 연결 인터페이스를 지원하는 장치에 대한 유일한 필수 엔드포인트이므로, 필요한 데이터 전송은 그 엔드포인트를 통하여 일어난다. 이 예에서, 이들 전송은 연결 클래스 요구의 형태로 되어 있다.

표 15는 일 예에서 장치에 의해 지원되어야 하는 연결 클래스 요구들의 목록을 도시한다.

요구	값	섹션
GET_ASSOCIATION_INFORMATION	0x01	0
GET_ASSOCIATION_REQUEST	0x02	0
SET_ASSOCIATION_RESPONSE	0x03	0

GET _ ASSOCIAT10N _ INFORMATION

이 요구는 장치로부터 연결 정보 구조를 검색한다. 이 연결 정보는 REQUEST_INFO 블록들의 목록을 포함한다. 각 REQUEST_INFO 블록은 장치가 발행하기를 원하는 단일 연결 요구에 속한다:

bmRequestType 10100001B bRequest GET_ASSOCIATION_INFORMATION wValue 0x0000 wIndex 인터페이스 wLength 요구된 데이터의 길이 Data ASSOCIATION_INFORMATION

표 17은 예시적 ASSOCIAT10N_INFORMATION 구조를 예시한다:

오프셋	필드	사이즈	값	설명
0	PendingRequestCount	1	0x00-0xff	이 구조의 말미에 리스트되어 있는 계류중 요구들의 수
1	Flags	2	표 18 참조	표 18 참조
3	RequestInfoArray	Sizeof(REQEUST_INFO) *PendingRequestCount	0x000000- 0xffffffff	REQUEST_INFO 구조들의 어레이(도 19 참조)

표 18은 연결 정보 플래그(Association Information Flag) 정보를 제공한다:

플래그 이름	플래그 값	설명
AdditionalRequests	0x0001	만일 이 플래그가 설정되면, 그것은 장치가 현재의 세트 후에 계류중인 추가 연결 요구들을 가질 수 있음을 나타낸다. 이것이 설정되면 호스트가 연결 요구들의 현재의 세트가 처리된 후에 또 다른 GET_ASSOCIATION_INFORMATION을 송신하게 된다. 그것들은 명시적 순서화 관심(ordering concerns)을 갖고 있거나, 혹은 특정 응답의 결과로서 요구를 발행할 수 있는 장치들에게 유용할 수 있다. 만일 이것이 설정되지 않으면, 그것은 호스트가 또 다른 GET_ASSOCIATION_INFORMATION 요구를 발행할 필요가 없음을 호스트에게 지시한다.

표 19는 예시적인 REQUEST_INFO 구조를 예시한다:

오프셋	필드	사이즈	값	설명
0	RequestID	1	0x00-0xff	이 필드는 특정 연결 요구를 식별한다. 이 값은 요구를 검색하거나 응답을 송신하는 데 사용될 것이다.
1	RequestSize	4	0x00000000 -0xffffffff	이것은 특정 연결 요구의 바이트 사이즈이다.

연결 요구 취득( GET ASSOCIAT10N REQUEST )

이 요구는 장치로부터 특정 연결 요구를 검색한다. 이 요구는 wValue 필드 내의 RequestID 값에 의해 식별된다:

bmRequestType 10100001B bRequest GET_ASSOCIATION_INFORMATION wValue RequestID BlockNumber wIndex 인터페이스 wLength 요구된 데이터의 길이 Data 연결 요구(Association Request)

이 예에서, 요구 블록은 4KB 데이터 블록이다. 제어 전송의 최대 전송 사이즈는 64KB이므로, 각 GET_ASSOCIAT10N_REQUEST에서는 이론적으로 16개의 요구 블록들이 전송된다. 전송될 데이터의 실제 양은 wLength 필드에 의해 지정된다. wValue 필드에 지정된 BlockNumber는 이 제어 전송에 대한 시작 블록 수를 식별한다. 따라서, 이 예에서, 장치(540)는 오프셋 BlockNumber*4KB에서 시작하고 wLength 바이트를 전송하는 RequestID에 의해 지정된 요구에 대한 연결 요구 데이터를 반환해야 한다.

연결 응답 설정( SET ASSOCIAT10N RESPONSE )

이 요구는 wValue 필드 내의 RequestID에 의해 식별된 특정 연결 요구에 대한 응답을 송신한다:

bmRequestType 00100001B bRequest SET_ASSOCIATION_INFORMATION wValue RequestID TransferFlags wIndex 인터페이스 wLength 응답 데이터의 길이 Data 연결 응답(Association Response)

이 예에서, TransferFlags 값은 표 22에서 발견되는 값들 중 0 이상의 비트단위 OR이다:

플래그 이름	플래그 값	설명
LastBlock	0x01	이 플래그가 설정되면, 그것은 이것이 이 특정 연결 응답에 대한 데이터를 포함하는 최종 제어 전송임을 나타낸다. 이것은 큰 응답들에 대한 제어 전송의 연결(chaining)을 용이하게 한다.

연결 인터럽트 IN 메시지(들)( Association interrupt _ in message (s))

NewAssociationRequest

이 인터럽트 IN 메시지는 장치가 처리될 필요가 있는 새로운 또는 수정된 연결 요구(들)를 갖고 있음을 호스트에 지시한다. 이 메시지를 수신하면, 호스트는 GET_ASSOCIAT10N_INFORMATION 요구를 발행하고, 그에 따라서 요구들을 처리할 수 있다.

오프셋	필드	사이즈	값	설명
0	bMessageType	1	50h	새로운 연결 요구 이벤트
1	bRequestCount	1	0x00- 0xff	후속 GET_ASSOCIATION_INFORMATION에서 반환될 수 있는 계류중 요구들의 수. 이 필드는 실제로 호스트에게는 연결 정보를 수신하기 위하여 할당할 필요가 있는 버퍼가 얼마나 큰지를 판정하기 위한 힌트이다.

시스템(100), 장치(110), 연결 관리자(120), 드라이버(140), 핸들러 레지스트리(150), 드라이버 레지스트리(160), 시스템(400), 연결 관리자(410), 관리자 통신 컴포넌트(420), 핸들러 식별 컴포넌트(430), 연결 관리자(510), 초기화 컴포넌트(520), 시스템(600), 핸들러(610), 요구 컴포넌트(620), 응답 컴포넌트(630), 연결 프로세서(640), 서비스(650), 시스템(700), 드라이버(710), 신뢰할 수 있는 매체 통신 컴포넌트(720), 드라이버 통신 컴포넌트(730) 및/또는 장치(740)는 그 용어가 본 명세서에서 정의되어 있는 바와 같이 컴퓨터 컴포넌트들일 수 있다는 것을 알아야 할 것이다.

도 8-18을 간단히 살펴보면, 본 발명에 따라서 구현될 수 있는 방법들이 예시되어 있다. 설명의 간결함을 위하여, 이 방법들은 일련의 블록들로서 도시되고 설명되어 있지만, 본 발명은 이 블록들의 순서에 의해 제한되지 않는다는 것을 이해하고 인식해야 할 것이다. 일부 블록들은, 본 발명에 따라서, 본 명세서에서 도시되고 설명된 것과 다른 순서로 및/또는 다른 블록들과 동시에 일어날 수 있기 때문이다. 또한, 본 발명에 따른 방법들을 구현하기 위해 예시된 모든 블록들이 요구되지 않을 수도 있다.

본 발명은 일반적으로 하나 이상의 컴포넌트들에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어와 관련하여 기술될 수 있다. 일반적으로, 프로그램 모들은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 개체, 컴포넌트, 데이터 구조 등을 포함한다. 전형적으로 프로그램 모듈들의 기능성은 다양한 실시예들에서 원하는 대로 조합 또는 분배될 수 있다.

도 8을 참조하면, 본 발명의 일 양태에 따른 장치의 연결 방법(800)이 예시되어 있다. 단계(810)에서, 신뢰할 수 있는 매체(예컨대, USB)를 통하여 접속(예컨대, 장치의 접속)이 수립된다. 단계(820)에서, 예를 들면, 장치 및/또는 관련 드라이버에 의해, 연결 요구가 발행된다. 단계(830)에서, 연결 응답과 관련된 정보가 수신된다(예컨대, 드라이버로부터). 이 정보는, 예를 들면, 연결 관리자로부터 수신된 연결 응답을 포함할 수 있다. 대안적으로, 이 정보는 연결 관리자로부터 수신된 연결 응답의 일부를 포함할 수 있다.

단계(840)에서, 연결이 성공하였는지에 대한 판정이 행해진다. 만일 단계(840)에서의 판정이 아니오(NO)이면, 더 이상의 처리가 행해지지 않는다. 만일 단계(840)에서의 판정이 예(YES)이면, 신뢰할 수 없는 매체(예컨데, 무선 접속)를 통하여 접속(예컨대, 장치를 접속)하기 위해 연결 응답과 관련된 정보가 이용된다.

다음으로 도 9를 참조하면, 본 발명의 일 양태에 따른 장치의 연결을 용이하게 하는 방법(900)이 예시되어 있다. 단계(910)에서, 연결 요구와 관련된 정보가 수신된다. 단계(920)에서, 연결 요구가 수신되었는지에 대한 판정이 행해진다. 만일 단계(920)에서의 판정이 아니오이면, 연결 요구가 생성되고, 처리는 단계(940)에서 계속된다. 만일 단계(920)에서의 판정이 예이면, 수신된 연결 요구가, 예를 들면, 연결 관리자에 송신된다.

단계(950)에서, 연결 응답이, 예를 들면, 연결 관리자로부터 수신된다. 단계(960)에서, 연결 응답과 관련된 정보가 요구 장치에 제공된다. 예를 들면, 이 정보는 전체 연결 응답 및/또는 연결 응답의 일부를 포함할 수 있다.

다음으로, 도 10-12를 참조하면, 본 발명의 일 양태에 따른 USB 접속을 통한 장치의 연결 방법(1000)이 예시되어 있다. 단계(1004)에서, 장치가 열거되고 및/또는 새로운 연결 요구 이벤트가 발행된다. 단계(1008)에서, GET_ASSOCIATI0N_INFORMATION 요구가, 예를 들면, 드라이버에 의해, 장치에 송신된다. 단계(1012)에서, 총 연결 정보의 사이즈가, 예를 들면, 드라이버에 의해 결정된다(예컨대, 사이즈 = 3 + sizeof(REQUEST_INFO)*PendingRequestCount).

단계(1016)에서, 연결 정보의 실질적으로 전부가, 예를 들면, 드라이버에 의해 수신되었는지에 대한 판정이 행해진다. 만일 단계(1016)에서의 판정이 아니오이면, 처리는 단계(1008)에서 계속된다. 만일 단계(1016)에서의 판정이 예이면, 단계(1020)에서, PendingRequestCount가 0보다 큰지에 대한 판정이 행해진다. 만일 단계(1020)에서의 판정이 아니오이면, 더 이상의 처리가 일어나지 않는다.

만일 단계(1020)에서의 판정이 예이면, 단계(1024)에서, 처리하기 위한 요구가 식별된다(예컨대, 드라이버에 의해). 단계(1028)에서, 전송(예컨대, 연결 요구)의 사이즈가 판정된다. 단계(1032)에서, GET_ASSOCIATI0N_REQUEST가 송신된다. 단계(1036)에서, 요구 데이터가 더 있는지에 대한 판정이 행해진다. 만일 단계(1036)에서의 판정이 예이면, 처리는 단계(1028)에서 계속된다. 만일 단계(1036)에서의 판정이 아니오이면, 단계(1040)에서, 요구된 연결이 처리되고 연결 응답이 생성된다(예컨대, 연결 관리자 및/또는 핸들러에 의해).

단계(1040)에서, 연결 응답 전송의 사이즈가 판정된다. 단계(1048)에서, SET_ASSOCIATI0N_TEESPONSE가 송신된다. 단계(1052)에서, 응답 데이터가 더 있는지에 대한 판정이 행해진다. 만일 단계(1052)에서의 판정이 예이면, 처리는 단계(1044)에서 계속된다. 만일 단계(1052)에서의 판정이 아니오이면, 단계(1056)에서, 요구가 더 있는지에 대한 판정이 행해진다.

만일 단계(1056)에서의 판정이 예이면, 처리는 단계(1024)에서 계속된다. 만일 단계(1056)에서의 판정이 아니오이면, 단계(1060)에서 연결 정보에서 추가 요구 플래그가 송신되었는지에 대한 판정이 행해진다. 만일 단계(1060)에서의 판정이 예이면, 처리는 단계(1008)에서 계속된다. 만일 단계(1060)에서의 판정이 아니오이면, 더 이상의 처리가 행해지지 않는다.

다음으로 도 13을 참조하면, 본 발명의 일 양태에 따른 연결 관리 방법(1300)이 예시되어 있다. 단계(1310)에서, 연결 요구가, 예를 들면, 드라이버로부터 수신된다. 단계(1320)에서, 연결 요구에 대한 핸들러가 식별된다. 단계(1340)에서, 그 연결 요구에 대한 핸들러가 존재하는지에 대한 판정이 행해진다. 만일 단계(1340)에서의 판정이 아니오이면, 단계(1350)에서, 연결 응답의 실패가 생성되고, 처리는 단계(1360)에서 계속된다.

만일 단계(1340)에서의 판정이 예이면, 단계(1370)에서, 연결 요구와 관련된 정보가 핸들러에 송신된다. 예를 들면, 정보는 연결 요구 및/또는 연결 요구의 일부(예컨대, 속성 목록(들))를 포함할 수 있다.

단계(1380)에서, 연결 응답과 관련된 정보가 핸들러로부터 수신된다. 단계(1360)에서, 연결 응답이 요구 드라이버에 제공된다.

도 14-16을 참조하면, 본 발명의 일 양태에 따른 연결 관리 방법(1400)이 예시되어 있다. 단계(1404)에서, 연결 요구가, 예를 들면, 드라이버로부터 수신된다. 단계(1408)에서, 연결 요구가 유효성 검사된다. 단계(1412)에서, 연결 요구가 적격인지에 대한 판정이 행해진다. 만일 단계(1412)에서의 판정이 아니오이면, 단계(1416)에서, 기형 연결 요구를 지시하는 연결 응답이 생성되고, 처리는 단계(1420)에서 계속된다.

만일 단계(1412)에서의 판정이 예이면, 단계(1424)에서, 연결 요구에 대한 핸들러를 찾는다. 단계(1428)에서, 핸들러가 발견되었는지에 대한 판정이 행해진다. 만일 단계(1428)에서의 판정이 아니오이면, 단계(1432)에서, 지원되지 않는 연결 유형을 지시하는 연결 응답이 생성되고, 처리는 단계(1420)에서 계속된다.

만일 단계(1428)에서의 판정이 예이면, 단계(1436)에서, 연결 요구가 구문분석되고 속성(들)의 목록이 작성된다. 단계(1440)에서, 속성 목록이 식별된 핸들러에 송신된다. 단계(1444)에서, 응답 정보가 핸들러로부터 수신된다. 단계(1448)에서, 연결이 성공하였는지에 대한 판정이 행해진다. 만일 단계(1448)에서의 판정이 아니오이면, 단계(1452)에서, 적절한 오류 상태를 지시하는 연결 응답이 생성되고, 처리는 단계(1420)에서 계속된다.

만일 단계(1448)에서의 판정이 예이면, 단계(1456)에서, 응답 포맷이 유효성 검사된다. 단계(1460)에서, 응답이 적격인지에 대한 판정이 행해진다. 만일 단계(1460)에서의 판정이 아니오이면, 단계(1464)에서, 적절한 오류 상태를 지시하는 연결 응답이 생성되고, 처리는 단계(1420)에서 계속된다.

만일 단계(1460)에서의 판정이 예이면, 단계(1468)에서, 핸들러로부터의 응답에 기초하여 연결 응답이 생성된다. 단계(1420)에서, 연결 응답은 요구 드라이버에 제공되고, 더 이상의 처리는 행해지지 않는다.

도 17을 참조하면, 본 발명의 일 양태에 따른 연결 핸들러 방법(1700)이 예시되어 있다. 단계(1710)에서, 연결 요구와 관련된 정보(예컨대, 속성 목록)가, 예를 들면, 연결 관리자로부터 수신된다. 단계(1720)에서, 연결 요구가 처리된다. 단계(1730)에서, 응답 정보가 연결 관리자에게 제공된다.

본 발명의 다양한 양태들에 대한 추가 컨텍스트를 제공하기 위하여, 도 18 및 다음의 설명은 본 발명의 다양한 양태들이 구현될 수 있는 적합한 운영 환경(1810)에 대한 간략한 일반 설명을 제공하도록 의도되어 있다. 본 발명은 하나 이상의 컴퓨터 또는 다른 장치들에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어의 일반적인 컨텍스트에서 기술될 수 있지만, 숙련된 당업자라면 본 발명이 다른 프로그램 모듈들과 조합하여 및/또는 하드웨어와 소프트웨어의 조합으로서 구현될 수도 있다는 것을 알 것이다. 그러나, 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 또는 특정 데이터 유형을 구현하는 루틴, 프로그램, 개체, 컴포넌트, 데이터 구조 등을 포함한다. 운영 환경(1810)은 적합한 운영 환경의 일례일 뿐이며, 본 발명의 사용 범위 또는 기능에 관해 어떠한 제한을 제시하고자 하는 것이 아니다. 본 발명과 함께 사용하기에 적합할 수 있는 잘 알려진 컴퓨터 시스템, 환경 및/또는 구성의 다른 예로는 퍼스널 컴퓨터, 서버 컴퓨터, 핸드-헬드 또는 랩톱 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 프로그램가능한 가전제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템이나 장치를 포함하는 분산 컴퓨팅 환경 등이 있지만 이에 제한되는 것은 아니다.

도 18과 관련하여, 본 발명의 다양한 양태들을 구현하는 예시적인 환경(1810)은 컴퓨터(1812)를 포함한다. 컴퓨터(1812)는 처리 장치(1814), 시스템 메모리(1816), 및 시스템 버스(1818)를 포함한다. 시스템 버스(1818)는 시스템 메모리(1816)을 포함하지만 이에 제한되지 않는 시스템 구성요소들을 처리 장치(1814)에 연결한다. 처리 장치(1814)는 다양한 이용 가능한 프로세스들 중 어느 것이라도 될 수 있다. 듀얼 마이크로프로세서 및 기타 멀티프로세서 아키텍처들도 처리 장치(1814)로서 이용될 수 있다.

시스템 버스(1818)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스 또는 외부 버스, 및/또는 각종 이용 가능한 버스 아키텍처 중 임의의 것을 이용하는 로컬 버스를 포함하는 몇몇 유형의 버스 구조 중 어느 것이라도 될 수 있다. 예로서, 이러한 아키텍처는 8비트 버스, ISA(Industry Standard Architecture) 버스, MCA(Micro-Channel Architecture) 버스, EISA(Enhanced ISA) 버스, IDE(Intelligent Drive Electronics), VESA 로컬 버스(VLB), PCI(Peripheral Component Interconnect), USB(Universal Serial Bus), AGP(Advanced Graphics Port), PCMCIA(Personal Computer Memory Card International Association) 버스, 및 SCSI(Small Computer Systems Interface) 등을 포함하지만 이에 제한되는 것은 아니다.

시스템 메모리(1816)는 휘발성 메모리(1820) 및 비휘발성 메모리(1822)를 포함한다. 시동 중과 같이 컴퓨터(1812) 내의 구성요소들 사이의 정보 전송을 돕는 기본 루틴을 포함하는 기본 입/출력 시스템(BIOS)은 비휘발성 메모리(1822)에 저장되어 있다. 예로서, 비휘발성 메모리(1822)는, ROM(read only memory), PROM(programmable ROM), EPROM(electrically programmable ROM), EEPROM(electrically erasable ROM), 또는 플래시 메모리를 포함할 수 있지만, 이에 제한되는 것은 아니다. 휘발성 메모리(1820)는 외부 캐시 메모리로서 작용하는 RAM(random access memory)을 포함한다. 예로서, RAM은 SRAM(synchronous RAM), DRAM(dynamic RAM), SDRAM(synchronous DRAM), DDR SDRAM(double data rate SDRAM), ESDRAM(enhanced SDRAM), SLDRAM(Synhlink DRAM), 및 DRRAM(direct Rambus RAM)과 같은 다수의 형태로 이용 가능하지만, 이에 제한되는 것은 아니다.

컴퓨터(1812)는 또한 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장매체를 포함한다. 도 18은 예를 들어 디스크 저장장치(1824)를 도시한다. 디스크 저장장치(1824)는 자기 디스크 드라이브, 플로피 디스크 드라이브, 테이프 드라이브, 재즈(Jaz) 드라이브, 집(Zip) 드라이브, LS-100 드라이브, 플래시 메모리 카드, 또는 메모리 스틱을 포함하지만, 이에 제한되는 것은 아니다. 또한, 디스크 저장장치(824)는 CD-ROM(compact disk ROM device), CD-R 드라이브(CD recordable drive), CD-RW 드라이브(CD rewritable drive) 또는 DVD-ROM(digital versativle disk ROM drive)과 같은 광 디스크 드라이브를 포함하는, 그러나 이에 제한되지 않는, 다른 저장 매체와 별개로 또는 그와 조합하여 저장 매체를 포함할 수 있다. 디스크 저장장치(1824)를 시스템 버스(1818)에 접속하는 것을 용이하게 하기 위하여, 통상적으로 인터페이스(1826)와 같은 이동식 또는 비이동식 인터페이스가 이용된다.

도 18은 사용자와 적당한 운영 환경(1810)으로 기술된 기본 컴퓨터 자원들 간에 매개물로서 기능하는 소프트웨어를 기술한다는 것을 이해해야 할 것이다. 그러한 소프트웨어는 운영 체제(1828)를 포함한다. 디스크 저장장치(1824) 상에 저장될 수 있는 운영 체제(1828)는 컴퓨터 시스템(1812)의 자원들을 제어 및 할당하도록 기능한다. 시스템 애플리케이션들(1830)은 시스템 메모리(1816)에 또는 디스크 저장장치(1824) 상에 저장된 프로그램 모듈들(1832) 및 프로그램 데이터(1834)를 통하여 운영 체제(1828)에 의한 자원들의 관리를 이용한다. 본 발명은 각종 운영 체제 또는 운영 체제들의 조합으로 구현될 수 있다는 것을 이해해야 할 것이다.

사용자는 입력 장치(들)(1836)를 통하여 명령 또는 정보를 컴퓨터(1812)에 입력한다. 입력 장치들(1836)은 마우스, 트랙볼(trackball), 스타일러스, 터치 패드와 같은 포인팅 장치, 키보드, 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너, TV 튜너 카드, 디지털 카메라, 디지털 비디오 카메라, 웹 카메라 등을 포함하지만, 이에 제한되지 않는다. 이들 및 기타 입력 장치는 인터페이스 포트(들)(1838)를 경유하여 시스템 버스(1818)를 통하여 처리 장치(1814)에 접속된다. 인터페이스 포트(들)(1838)는, 예를 들면, 직렬 포트, 병렬 포트, 게임 포트, USB(universal serial bus)를 포함한다. 출력 장치(들)(1840)는 입력 장치(들)(1836)와 동일한 유형의 포트들의 일부를 이용한다. 따라서, 예를 들면, USB 포트는 컴퓨터(1812)에 입력을 제공하고, 컴퓨터(1812)로부터 출력 장치(1840)로 정보를 출력하는 데 이용될 수 있다. 출력 어댑터(1842)는, 여러 출력 장치들(1840) 중에서, 특별한 어댑터들을 필요로 하는, 모니터, 스피커, 및 프린터와 같은 몇몇 출력 장치들(1840)이 있다는 것을 예시하기 위해 제공되어 있다. 출력 어댑터들(1842)은 예로서 출력 장치(1840)와 시스템 버스(1818) 간에 접속 수단을 제공하는 비디오 및 사운드 카드를 포함하지만 이에 제한되는 것은 아니다. 원격 컴퓨터(들)(1844)와 같은 다른 장치들 및/또는 장치들의 시스템들이 입력 및 출력 둘 다의 성능들을 제공한다는 것에 유의해야 할 것이다.

컴퓨터(1812)는 원격 컴퓨터(들)(1844)와 같은 하나 이상의 원격 컴퓨터들에의 논리적 접속들을 이용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(들)(1844)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 워크스테이션, 마이크로프로세서 기반 가전 기기, 피어 디바이스 또는 기타 일반적인 네트워크 노드 등일 수 있고, 통상적으로 컴퓨터(1812)에 관련하여 기술된 구성요소들의 다수 또는 전부를 포함한다. 간결함을 위하여, 메모리 저장장치(1846)만이 원격 컴퓨터(들)(1844)와 함께 도시되어 있다. 원격 컴퓨터(들)(1844)는 네트워크 인터페이스(1848)를 통하여 컴퓨터(1812)에 논리적으로 접속되고 그 후 통신 접속(1850)을 통하여 물리적으로 접속된다. 네트워크 인터페이스(1848)는 LAN(local-area networks) 및 WAN(wide-area networks)과 같은 통신 네트워크들을 포함한다. LAN 기술은 FDDI(Fiber Distributed Data Interface), CDDI(Copper Distributed Data Interface), 이더넷/IEEE 802.3, 토큰 링/IEEE 802.5 등을 포함한다. WAN 기술은 포인트-투-포인트 링크, ISDN(Integrated Services Digital Networks) 및 그 변형들과 같은 회로 스위칭 네트워크, 패킷 스위칭 네트워크, 및 DSL(Digital Subscriber Lines)을 포함하지만, 이에 제한되는 것은 아니다.

통신 접속(들)(1850)은 네트워크 인터페이스(1848)를 버스(1818)에 접속하기 위해 이용되는 하드웨어/소프트웨어를 나타낸다. 설명의 명료함을 위하여 컴퓨터(1812) 내부에 통신 접속(1850)이 도시되어 있지만, 그것은 컴퓨터(1812) 외부에 있을 수도 있다. 네트워크 인터페이스(1848)에의 접속에 필요한 하드웨어/소프트웨어는, 단지 예시를 위하여, 정규 전화 등급 모뎀를 포함하는 모뎀들, 케이블 모뎀 및 DSL 모뎀, ISDN 어댑터, 및 이더넷 카드와 같은 내장 및 외장 기술을 포함한다.

일 실시예에서, 무선 USB(WSB) 지원을 포함하는 플러그 앤 고(PONG: Plug and Go) 아키텍처로서 확장 가능한 아키텍처가 구현될 수 있다. 도 19는 PONG 시스템(1900)의 일례를 보여준다. 관리자(1905)는 데이터를 정확한 파티(party)들에 전달하는 것을 용이하게 하도록 구성된 중앙 컴포넌트이다. 관리자(1905)는 드라이버 데이터(예컨대 dll들)를 프로세스 내에 로딩할 수 있다. 예를 들면, 관리자(1905)는 드라이버 등록에 기초하여 드라이버 데이터를 로딩할 수 있다. 관리자(1905)가 드라이버로부터 요구 블록을 수신하면, 요구 헤더를 보고 그 요구 유형에 대한 적절한 핸들러를 로딩할 수 있다. 핸들러 또는 드라이버는 시스템 시동 시에 로딩될 수 있다. 요구 블록은 처리를 위해 핸들러에 제공된다. 일단 핸들러가 완료되면, 응답 블록이 관리자(1905)를 통하여 드라이버에 반환된다.

드라이버들(1920-1922)은 일부 형태의 하드웨어, 또는 또 다른 소프트웨어 컴포넌트와 인터페이스하는 책임이 있다. 드라이버들(1920-1922)은 관리자(1905)로부터의 요구들을 신뢰할 수 있는 매체를 통하여 장치들에 전달(channel)하는 책임이 있다.

드라이버들(1920-1922) 각각은 새로운 요구가 발행되어야 하는 때를 검지하고, 그것은 요구를 검색 또는 생성한다. 이 요구는 관리자(1905)에 전달되고 관리자는 나중에 드라이버에 응답을 반환할 것이다.

복수의 핸들러들이 동일 드라이버를 이용할 수 있다(즉, 복수의 대상 매체가 동일한 신뢰할 수 있는 매체를 이용할 수 있다). 드라이버들(1920-1922)은 요구 블록 또는 응답 블록의 상세에 대한 어떤 지식도 필요로 하지 않을 수 있다.

핸들러들(1910-1912)은 장치 설치/연결을 구현하는 서비스와 인터페이스하는 책임이 있다. 핸들러들(1910-1912)은 대상 매체에 직접 관련될 수 있고 그 특정 대상 매체에 대한 요구 블록 내의 속성들에 대한 명시 지식을 가질 필요가 있는 유일한 컴포넌트일 수 있다. 다른 컴포넌트들에 의해서도 사용될 수 있는 전역 속성들이 있다.

핸들러들(1910-1912)은 무선 매체와 같은 임의 유형의 대상 매체를 처리하도록 구성될 수 있다. 도 19에 도시된 바와 같이, 핸들러(1912)는 WUSB 매체를 처리하도록 구성된다. WUSB는 무선 USB 주변 장치들을 무선 USB 호스트들에 접속시키기 위한 USB-lF(USB Implementors Form)에 의해 정의된 무선 프로토콜이다. WUSB 프로토콜은 초광대역(UWB: ultra wide band)의 상부에 MBOA(Multiband OFDM Alliance) MAC(media access control) 계층 상에서 작용하도록 지정되어 있다. 핸들러들(1910-1912) 중 어느 하나가 관리자(1905)로부터 요구 블록을 수신하면, 그 핸들러는 콘텐츠를 구문분석하여 적절한 액션을 판정할 것이다.

PONG 시스템(1900)은 장치들이 WUSB와 관련된 속성들을 포함하는 요구 및 응답을 송신할 수 있게 한다. 장치로부터 핸들러로 전달된 요구의 경우, 속성 목록은 연결 유형, 접속 장치 ID, 접속 키, 장치 셋업 클래스 GUID, 지원되는 대역 그룹, 인터그레이터 사이트(integrator site) URL 등을 포함할 수 있다. 연결 유형은 요구 및 응답의 헤더 부분에 포함된 속성이고, 데이터 속성들과는 별개이다. 연결 유형 속성은 관리자에 의해 요구들을 정확한 핸들러에 전송하는 데 이용된다. 표 24는 연결 유형 속성의 사양 예를 보여준다.

속성 이름:	속성 ID:	길이	M/O	허용 값들
연결 유형	0x0000	16B	M	59ACFDCB-153E-41ef-8111-FA19CFE42B1E

표 24 및 아래 표들에서의 용어들은 다음과 같이 정의된다:

속성 이름( Attribute name ): 속성 요소와 관련된 친근한 이름.

속성 ID ( Attribute ID ): 이 번호는 속성 목록 내의 속성 요소를 식별하는 데 이용된다.

길이( Length ): 속성 요소 내의 데이터의 길이. 속성 길이는 변하거나 고정될 수 있고 바이트로 표현된다. 길이 값은 또한 최대 길이를 지정할 수 있다. 연결 응답에서는, 고정 길이가 이용되어 그 값에의 오프셋이 결정적(deterministic)일 수 있고, 응답을 구문문석하는 장치의 능력을 돕는다. 속성의 실제 값은 데이터에 대하여 할당된 전체 길이까지 사용하지 않을 수 있다. 이 경우에, 추가 필드가 속성 데이터의 실제 길이를 지정한다.

M/O: 이 필드는 변수가 필수인지 옵션인지를 전달한다. 필수 속성 요소들은 항상 속성들의 목록에 포함될 것이다. 옵션인 값은 반드시 존재하지는 않을 것이다. "필수(Mandatory)" 및 "옵션(Optional)"은 M 또는 0로 표현된다.

허용 값들( Allowed Values ): 이 허용 값 필드는 장치에 의해 지원될 값들을 기술한다. 만일 허용 값이 요구되면, 그것은 그 허용 값이 속성 목록에 포함되면 장치가 그 값을 지원한다는 것을 의미한다. 표에서 다르게 기술되지 않는 한, 값들은 요구되는 것으로 추정되어야 한다. 만일 허용 값이 옵션이면, 장치는 그 값을 지원할 필요가 없지만, 그것이 속성 목록에 포함되는 것에 준비되어 있어야 한다. 옵션 값들은 이 사양의 장래 버전에서 필요하게 될 수 있다.

요구의 데이터 부분은 속성 유형에 특정한 속성들을 포함할 수 있다. 표 25는 WUSB에 전송될 수 있는 요구 속성들의 예를 보여준다:

속성 이름:	속성 ID:	길이	M/O	허용 값들
접속 장치 ID (CDID)	0x1000	16B	O	128B 고유 장치 ID. 이 ID는 호스트에 대하여 장치를 고유하게 식별한다. 만일 속성이 없거나, 그 값이 모두 0이면, 장치 ID는 호스트에 의해 연결 응답에서 공급될 것이다.
접속 키(CK)	0x1001	16B	O	재접속을 수립하는 데 이용될 128비트 키. 만일 이 속성이 없거나, 그 값이 모두 0이면, 접속 키는 호스트에 의해 연결 응답에서 공급될 것이다.
장치 셋업 클래스 GUID	0x1002	16B	O	이 GUID는 정보들에서 이용될 때 장치의 클래스를 나타낸다.
지원되는 대역 그룹들	0x1003	2B	O	장치에 의해 어느 UWB 대역 그룹들이 지원되는지를 보고하는 2 바이트 비트-마스크.
인터그레이터 사이트 URL	0x1004	가변	O	USB-IF 증명 장치 인터그레이터의 목록 상의 장치의 상세를 포함하는 특정 위치를 가리키는 URL.

접속 장치 ID(CDID: Connection Device ID)는 무선 USB 장치의 장치 ID이다. 만일 장치에 미리 장치 ID가 할당되었다면(공장, 이전의 연결 시도, 사용자 입력 등 어느 것으로부터든), 그 장치는 동일한 ID를 이용하기를 원할 수 있다. 기존의 ID를 재사용함으로써, 호스트는 그 장치를 전에 보았던 것을 알고 다르게 거동할 수 있다. 그것은 또한 복수의 호스트와 동시에 연결될 수 있는 장치들에 대하여 그것을 더 용이하게 할 수 있다. 예를 들면, CDID는 장치가 복수의 호스트들에 걸쳐서 동일 CDID를 유지하거나, 또는 그것이 이미 이 호스트와 연결되어 있음을 나타내기를 원하면 그 장치에 송신될 수 있다. 호스트는 이 값을 덮어쓰기(overwrite)하거나, 또는 이 값을 재사용할 수 있다.

만일 이 속성이 없거나, 그 값이 모두 0이면, 호스트는 장치가 새로운 장치 ID를 필요로 한다고 추정할 것이다. 호스트는 이 고유 ID를 생성하고 그것을 연결 응답에서 장치에 반환할 것이다.

접속 키(CK: Connection Key)는 상호 인증을 용이하게 하고 WUSB 사양에서 기술된 세션 암호화 키들을 생성하기 위해 사용될 것이다. CK는 장치가 하드-코딩된 접속키(hard-coded connection key)를 가질 필요가 있으면 그 장치에 송신될 수 있다. 장치는 생성된 키를 저장할 능력이 없으면(NVRAM이 없음) 요구 내에 이 속성을 포함시키길 원할 수 있다. 그러나, 장치들이 이들 키를 하드코딩하는 것은 권장되지 않고, 오히려 장치들은 보다 양호한 보안을 위하여 호스트가 그것들을 동적으로 생성하도록 해야 한다.

만일 이 속성이 없거나, 그 값이 모두 0이면, 호스트는 장치가 CK가 생성되는 것을 필요로 한다고 추정할 것이고 연결 응답에서 CK를 반환할 것이다.

장치 셋업 클래스(Device Setup Class) GUID는 지원되는 셋업 클래스 GUID들 중 하나이다. 연결 요구에서 이 값을 제공하는 것은 그 장치에 대한 적절한 아이콘들의 표시를 가능케 하고, 또는 어떤 시스템 또는 사용자 정의 정책을 구현하는 것을 가능케 한다. 이 값은 어떤 유형의 장치가 연결 중인지를 판정하기 위해 사용될 수 있다. GUID는 아이콘, 설명 등과 같은 것들을 판정하기 위해 호스트 상의 설치된 장치 셋업 클래스에 대하여 매치시키기 위해 사용될 수 있다. 이것은 또한 사용자가 특정 장치를 식별하는 것을 돕기 위해 임의의 UI에 적절한 정보를 표시하는 것을 도울 것이다.

지원되는 대역 그룹(Supported Band Groups)은 호스트 라디오가 채널을 고를 때 어느 채널을 선택해야 하는지를 판정하는 데 사용될 수 있다. 예를 들면, 지원되는 대역 그룹은 호스트에 의해 그것이 어떤 PHY 채널들을 사용할 수 있는지를 판정하는 데 이용될 수 있다. 장치로부터 이 정보가 없으면, 호스트는 대역 그룹 1 내의 채널로 변경해야 할 것이다. 그 이유는 그것이 모든 장치들에 의해 지원되도록 요구되는 유일한 대역 그룹이기 때문이다. 이로 인해 모든 호스트 및 장치들이 대역 그룹 1을 사용하기로 선택하게 될 것이고, 따라서 그 채널들에 꽉 들어차서 다른 대역 그룹들의 값이 감소하게 될 것이다. 만일 이 정보가 연결 시에 호스트에 전달되면, 호스트는 아마도 호스트에 접속할 수 있는 모든 장치들에 대한 지원 채널들을 알 것이고, 따라서 호스트는 아마도 다른 대역 그룹 내의 채널들을 선택할 수 있을 것이다.

비트 위치 내의 1은 관련된 PHY 대역 그룹 내의 모든 대역 및 채널이 지원된다는 것을 지시한다. 비트 위치 0에서의 1은 대역 그룹 1 내의 모든 대역이 지원된다는 것을 지시한다.

인터그레이터 사이트(Integrator Site) URL은 UI에서 USB-IF 웹사이트 상의 그 장치의 상세에의 링크를 제공함으로써 그 장치에 관한 정보를 사용자에게 제공하기 위해 이용될 수 있다.

표 26은 WUSB 장치에 전송될 수 있는 응답 속성들의 예를 보여준다. 표에는 오프셋들의 예가 도시되어 있다. 또한, 헤더 속성들은 속성 목록의 처음 19 바이트에 할당될 수 있다.

속성 이름:	속성 ID:	길이	M/O	허용 값들
접속 호스트 ID (CHID) (오프셋=0x13)	0x2000	16B	M	128B 고유 호스트 ID. 이 ID는 장치에 대하여 호스트를 고유하게 식별한다.
접속 장치 ID (CDID) (오프셋=0x23)	0x1000	16B	M	128B 고유 장치 ID. 이 ID는 호스트에 대하여 장치를 고유하게 식별한다. 만일 장치가 연결 요구에서 이 속성을 지정하였다면, 이 값은 동일할 것이다.
접속 키(CK) (오프셋=0x33)	0x1001	16B	M	재접속을 수립하는 데 이용될 128비트 키. 만일 장치가 연결 요구에서 이 속성을 지정하였다면, 이 값은 동일할 것이다.
선호 채널들	0x2001	16B	O	이것은 호스트가 채널들을 선택할 때 이용할 채널 선택 우선순위를 나타낼 것이다. 이 정보를 이용하여, 장치는 선호 채널들을 먼저 스캔함으로써 검색 시간을 최소화하기 위하여 호스트를 찾을 때 스캔할 채널들의 순서를 변경할 것이다.
호스트 영역	0x2002	16B	O	호스트가 어느 영역에서 동작하고 있는지를 알리는 호스트로부터의 지시. 이것은 만일 상이한 국가들 또는 영역이 전력, 범위, 주파수 등에 관하여 장치에 대한 상이한 동작 제한을 지정할 경우 필요할 수 있다.

핸들러로부터 장치에 전달된 응답들에 대하여, 속성 목록은 접속 호스트(Connection Host) ID, 접속 장치(Connection Device) ID, 접속 키(connection key), 선호 채널(preferred channels), 호스트 영역(host retion) 등을 포함할 수 있다. 접속 호스트 ID(CHID)는 고유 호스트 ID이다. 장치는 이 ID를 이용하여 호스트의 비컨을 찾아냄으로써, 호스트를 찾아낼 수 있다. 접속 장치 ID(CDID)는 고유 장치 ID이다. 이 ID는 CHID에 의해 지정된 호스트에 대하여 장치를 고유하게 식별한다. 그것은 복수의 호스트에 걸쳐서 고유하다고 보장되지 않는다. 접속 키(CK)는 이 컨텍스트를 이용하여 재접속을 수립하기 위한 것이다. CK는 128비트 CCM 키일 수 있다.

선호 채널(Preferred Channels)은 호스트가 이용하고 있는 선호 채널 순서를 장치에게 알리기 위하여 호스트 응답에서 지정될 수 있다. 이것은 임의의 주어진 채널에 호스트가 있을 상대적 가능성에 관한 힌트를 장치에 제공함으로써 호스트를 검색하는 프로세스를 최적화할 수 있다. 장치는 호스트가 지정한 순서로 호스트를 검색함으로써, 장치가 선형 순서로 스캔하는 것이 아니라, 스캔된 제1 소수의 채널들 중 하나에서 호스트를 찾아낼 가능성이 더 많아지게 할 수 있다.

호스트 영역(Host Region)은 그것이 어떤 영역에서 동작하고 있는지에 관하여 장치에 통지하기 위하여 호스트 응답에서 지정될 수 있다. 장치는 이 정보를 이용하여 그것의 무선 동작 특성을 영역 특정 값으로 변경할 수 있다.

일 실시예에서, 속성 목록 내의 속성들의 길이는 고정될 수 있다. 따라서, 장치 제조업자들은 적절한 오프셋으로 용이하게 점프하여 응답 내의 임의의 주어진 속성의 값을 판독할 수 있다. 오프셋은 속성의 시작을 나타낸다.

다른 속성들은 장치와 핸들러 간의 요구 및 응답을 위해 사용될 수 있다. 이들 다른 속성들은 하드웨어 및 호환가능 ID, 채널 ID, 대역 그룹, 장치 제조업자 문자열, 장치 설명 문자열, 호스트 문자열, 장치의 클래스 GUID, 제조업자 URL, 장치 아이콘, 연결 비밀 키 등을 포함할 수 있다. 연결 비밀 키(association secret key)는 장치에 기입된 PONG 특징 키이다. 장치는 전형적으로 PONG을 통하는 경우를 제외하고 연결 비밀 키를 드러내지 않을 것이다. 다음번에 장치가 부착할 때는, 연결 비밀 키가 검색되어 장치를 인증하는 데 이용된다. 연결 비밀 키의 이용은 사용자에 문의하지 않고 연결 정보를 조용히 업데이트하거나, 장치가 그것의 CDID를 보유하게 하는 것 등과 같은 태스크들을 수행하는 것을 가능케 할 수 있다. 연결 키를 이용하지 않으면, (예컨대, 다른 호스트로부터 획득되거나, 다른 장치로부터 훔치거나 하는 등으로) 동일한 CDID 를 갖는 2개의 장치가 그 장치들이 PC에 접속하는 능력에 영향을 미칠 가능성이 있을 수 있다.

다음은 위에서 설명된 아키텍처 및 WUSB 접속 메커니즘을 이용하여 달성될 수 있는 2가지 시나리오 예이다:

시나리오 1 - WUSB 휴대용 플레이어(Portable Player)와 PC:

토드(Todd)는 윈도즈 미디어 플레이어와 동기하여 작동하는 새로운 유선+무선 USB 휴대용 플레이어를 입수한다. 박스를 열자마자, 그는 플레이어를 꺼내고 포함된 재충전가능한 배터리를 플레이어에 부가한다. 그 후 그는 지시에 따라서 제3자 소프트웨어를 설치한 다음 유선 USB 케이블을 이용하여 플레이어를 PC에 부착하여 배터리를 충전한다. 배터리를 충전하는 동안, 플레이어는 또한 무선 USB 접속을 위하여 PC에 결합되고 심지어 유선 USB를 통하여 장치 동기화를 개시한다.

일단 케이블이 플러그 분리(unplug)되고 장치가 범위 내에 있으면, 사용자는 무선 USB 장치 검출을 위하여 어떤 새로운 대화(dialog)도 보지 않을 것이고 장치는 바로 작동을 시작할 것이다.

시나리오 2 - 휴대 전화(Cell phone) 및 저장 장치와 PC:

잭(Jack)은 미리 연결되어 있는 PC와 WUSB 저장 장치를 갖고 있다. 잭이 그의 WUSB 휴대 전화를 PC와 연결시킬 때, 그는 또한 다른 WUSB 장치들(1개의 자유 접속 슬롯을 갖고 있을 수 있음)를 휴대 전화와 연결시키는 옵션을 얻는다. 이것은 PC의 가치를 증가시키고 최종 사용자의 접속 경험을 단순화한다.

WUSB 장치를 연결시키기 위한 4가지 연결 모델의 예가 아래에 예시를 위하여 포함되어 있다:

UI 접근법(Approach) - 양쪽 시스템에서 접속 버튼을 이용하고(일단 장치들이 근접하면) 근접 내의 쌍을 이룰 수 있는 장치들의 UI 목록으로부터 장치를 식별한다.

일련 번호(Serial #) 접근법 - 이것은 UI 접근법과 매우 유사하지만 일단 사용자가 UI로부터 장치를 식별하면, 사용자는 보안을 가능케 하기 위해 장치로부터의 일련 번호를 호스트 상에 타이핑 입력해야 한다,

USB 케이블 접근법 - 일반 USB 케이블을 이용하여 무선 USB 장치를 연결시키고자 하는 호스트에 플러그 접속시킨다. 와이어는 연결과 함께 정규 동작 또는 충전을 위해 사용될 수 있다.

USB 플래시 키 - 일반 USB 대용량 저장 장치(Mass Storage device)(예컨대, USB 플래시 장치)를 이용하여 장치와 호스트 간에 식별 및 보안 정보를 저장 및 교환한다.

도 19에 도시된 PONG 시스템(1900)은 특히 USB를 지원하도록 구성될 수 있다. 도 20은 운영 체제의 장치 관리자 아키텍처에 대한 USB 드라이버 스택(2000)의 예를 도시한다. 드라이버 스택(2000)은 PONG 시스템(1900)에서 신뢰할 수 있는 매체로서 USB를 지원하도록 구현될 수 있다. 컴포넌트들(2013-2017)은 운영 체제의 기존 USB 스택이다. 컴포넌트(2010)는 PONG USB 드라이버의 커널(kernel) 컴포넌트이다. 컴포넌트(2006)는 전체 PONG 관리자(1905)에 의해 캡슐화(encapsulate)된 사용자 모드 PONG 드라이버이다.

도 21은 WUSB 장치(2112)가 호스트 장치(2100)에 접속하기 위한 동작들의 예를 도시한다. 접속하는 WUSB 장치(2112)는 WUSB를 이용하여 통신이 가능한 어떤 장치라도 될 수 있다. 전형적으로 접속하는 WUSB 장치(2112)는 또한 신뢰할 수 있는 매체를 이용하여 통신이 가능하다. 위에서 논한 바와 같이, 신뢰할 수 있는 매체는 유선 USB, 직렬(serial), 병렬(parallel), 파이어와이어, 이더넷 등과 같은 유선 접속을 포함할 수 있다. 신뢰할 수 있는 매체는 또한 근거리 무선 통신(NFC: near field communication), 적외선(IR), 또는 다른 수립된 무선 접속과 같은 무선 접속을 포함할 수 있다. 호스트 장치(2100)는 도 19와 관련하여 위에서 논의된 관리자(1905), WUSB 핸들러(1912) 및 드라이버(1912)를 포함한다. 도 21에 도시된 바와 같이, 호스트 장치(2100)는 또한 WUSB를 이용하여 외부 장치에 접속하기 위한 WUSB 컴포넌트(2103) 및 유선 접속을 이용하여 장치에 접속하기 위한 유선 컴포넌트(wired component)(2105)를 포함한다.

호스트 장치(2100)에 접속하기 위해, 접속하는 WUSB 장치는 유선 컴포넌트(2105)를 통하여 드라이버(1921)에 요구를 송신한다. 예를 들면, 접속하는 WUSB 장치(2112)는 유선 USB 케이블을 통하여 유선 컴포넌트(2105)에 접속될 수 있다. 요구는 WUSB 장치(2112)를 호스트 장치(2100)와 연결시키기 위한 정보, 이를테면 위에서 논의된 속성들을 포함한다.

드라이버(1921)는 그 요구를 관리자(1905)에 송신하고, 관리자는 그 요구 내의 정보를 구문분석하고 유효성 검사한다. 특히, 관리자(1905)는 요구 내의 접속의 유형을 판정하고 요구 내의 정보가 그 접속에 관련된 표준에 대하여 유효한지를 판정할 수 있다. 이 예에서, 관리자(1905)는 요구가 WUSB 접속과 관련되어 있다고 판정한다. 관리자(1905)는 요구 내의 장치 속성들을 유효성 검사한다. 만일 요구가 유효하다면, 관리자(1905)는 장치 속성과 같은 WUSB 접속 정보를 WUSB 핸들러(1912)에 제공한다.

WUSB 핸들러(1912)는 요구에 응답하여 접속 정보를 처리하고 호스트 접속 정보를 관리자(1905)에 제공한다. 호스트 접속 정보는 WUSB를 이용하여 접속하는 데 이용되는 접속 속성들을 포함한다. 관리자(1905)는 접속 속성들을 갖는 호스트 접속 정보를 드라이버(1921)에 제공하고, 드라이버는 그 접속 정보를 유선 컴포넌트(2105)를 통하여 접속하는 WUSB 장치(2112)에 송신한다. 그 후 접속하는 WUSB 장치(2112)는 그 접속 정보를 자기 구성(self-configuring) 및 호스트 장치(2100)에 접속하는 데 이용한다. 예를 들면, 접속하는 WUSB 장치(2112)는 WUSB 컴포넌트를 호스트 장치(2100)에 의해 요구되는 구성, 이를테면 채널, 영역 등에 맞추어 조정할 수 있다. 접속하는 WUSB 장치(2112)는 또한 수신된 접속 정보에서 식별된 키, 호스트 ID 및 장치 ID를 이용하여 호스트 장치(2100)에 정보를 송신할 수 있다.

도 22는 여기에서 설명된 시스템을 이용하여 WUSB 장치를 호스트 장치와 접속하기 위한 프로세스(2200)의 예를 도시한다. 예를 들면, 프로세스(2200)는 관리자(1902)에 의해 구현될 수 있다. 블록 2202에서, WUSB 장치로부터의 연결 요구가 식별된다. 연결 요구는 유선 매체와 같은 신뢰할 수 있는 매체를 통하여 수신될 수 있다. 블록 2204에서, 요구가 구문분석되고 콘텐츠가 유효성 검사된다. 요구를 구문분석하는 것은 요구에 포함되어 있는 연결의 유형의 판정을 가능케 한다. 요구는 그 유형에 대응하는 표준에 기초하여 유효성 검사된다. 이 예에서, 연결의 유형은 WUSB이고 요구는 WUSB 표준과 대조하여 유효성 검사된다. 유효성 검사된 요구는 WUSB 표준에 의해 지정되는 장치 속성들을 포함해야 한다.

블록 2206에서, WUSB 장치 속성들은 WUSB 핸들러에 송신된다. 블록 2208에서, 접속 속성들이 WUSB 핸들러로부터 수신된다. 접속 속성들은 WUSB 장치가 호스트 장치에 접속할 수 있게 한다. 블록 2210에서, 접속 속성들은 신뢰할 수 있는 매체를 통하여 WUSB 장치에 송신된다.

다음의 섹션 A-C는 USB 신뢰할 수 있는 매체를 통하여 PONG 시스템에 의해 사용되는 프로토콜에 특유한 것으로 PONG 대상 장치에서 USB를 통하여 PONG을 구현하는 데 필요한 각종 인터페이스 및 엔드포인트 설명자들의 레이아웃을 설명한다.

A. PONG 장치 인터페이스

표 27은 인터페이스 설명자를 나타내는 것으로 USB를 통하여 PONG 장치에 대하여 채워져야 할 값들의 상세를 제공한다. 대부분의 행들에 대하여, 특정 값 또는 값들의 세트가 제공된다. 벤더들은 특정된 범위로부터 선택할 수 있고 모든 다른 값들은 장래의 사용을 위해 예비(RESERVED)될 수 있다.

오프셋	필드	사이즈	값	설명
0	bLength	1	07h	이 설명자의 바이트 사이즈
1	bDescriptorType	1	04h	인터페이스 설명자 유형
2	bInterfaceNumber	1	??h	인덱스 번호를 식별하는 제로 기반(zero-based) 값
3	bAlternateSetting	1	00h	대안 설정들이 필요하지 않다.
4	bNumEndpoints	1	00h 또는 01h	사용되는 엔드포인트들의 수(엔드포인트 제로는 제외). 옵션인 인터럽트 엔드포인트가 요구되지 않으면 00h를 사용하고, 그렇지 않으면 01h를 사용한다.
5	bInterfaceClass	1	ffh	이 인터페이스를 벤더 특정으로 식별하기 위해 ffh를 사용하시오. 마이크로소프트 OS 설명자가 PONG 인터페이스에 대한 마이크로소프트 클래스 코드를 식별하기 위해 사용될 것이다.
6	bInterfaceSubClass	1	00h	00h의 값은 0xff로 설정된 클래스 코드와 함께 사용되어야 한다
7	bInterfaceProtocol	1	00h	00h의 값은 0xff로 설정된 클래스 코드와 함께 사용되어야 한다
8	iInterface	1	00h	이 인터페이스를 설명하는 문자열 설명자의 인덱스.

연결 중인 장치를 식별하기 위해 문자열이 이용될 수 있다. 그 문자열은 USB 문자열 설명자들에 국한(localize)될 수 있다. 좋은 문자열의 일례는 "PONG-무선 USB 마우스(PONG-Wireless USB Mouse)"일 것이다. 일 실시예에서, PONG 인터페이스들은 인터페이스 연결 설명자(Interface Association Descriptor)와 그룹화되지 않는다. USB 장치는 1 구성 당 2 이상의 PONG 인터페이스를 갖도록 구성되지 않을 수 있다.

B. PONG 장치 엔드포인트

참으로 저가인 장치를 허용하기 위해, 제어 엔드포인트가 이용될 수 있고 인터럽트 엔드포인트는 옵션이다(진보된 특징을 위하여). 제어 엔드포인트를 이용하는 것은 또한 저속(Low Speed) USB 장치들을 허용한다. 제어 엔드포인트(엔드포인트 0x00)는 인터페이스 설명자 아래에 설명될 필요가 없고 모든 USB 장치들에 존재해야 한다.

스마트 장치들은 장치 열거가 완료된 후에 연결 기능을 구현하기로 결정할 수 있다. 이를 이루기 위해, 장치는 옵션인 인터럽트 IN 엔드포인트를 구현할 수 있다. 이 엔드포인트는 새로운 연결 요구들의 통지를 용이하게 할 것이다. 이 옵션 엔드포인트에 대한 표준 엔드포인트 설명자의 일례가 표 28에 인터럽트-IN 엔드포인트 설명자로서 도시되어 있다.

오프셋	필드	사이즈	값	설명
0	bLength	1	07h	이 설명자의 바이트 사이즈
1	bDescriptorType	1	05h	엔드포인트 설명자 유형
2	bEndpointAddress	1	81-8Fh	USB 장치 상의 이 엔드포인트의 주소. 이 주소는 1과 15 사이의 엔드포인트 번호이다. 비트 1..3 엔드포인트 번호 비트 4..6 예비, 0이어야 한다 비트 7 1=In
3	bmAttributes	1	03h	이것은 인터럽트 엔드포인트이다
4	wMaxPacketSize	2	00??h	최대 데이터 전송 사이즈
6	bInterval	2	??h	데이터 전송을 위하여 엔드포인트를 폴링하는 간격. 1 내지 255의 범위에 있어야 한다. 권장되는 값은 255이다.

만일 장치의 PONG 인터페이스가 옵션 엔드포인트를 포함하지 않으면, 연결은 열거 시에 일어날 수 있다. 만일 그러한 장치가 연결 프로세스를 개시하기를 원하면, 그것은 장치 개시(device initiated) USB 리셋을 수행할 수 있다. 이것은 그 장치가 호스트에 의해 다시 열거되게 할 수 있고, 그 시점에서 호스트는 장치로부터의 연결 요구들을 검색할 수 있다. 장치는 또한 장치가 오고 가게 하는 HUB 기능을 구현할 수 있다.

C. PONG 클래스 특정 요구

모든 PONG 데이터 전송은 제어 엔드포인트 상에서 일어난다. 이들 전송은 PONG 클래스 요구의 형태로 될 수 있다. 표 29는 PONG 장치에 의해 지원되는 PONG 클래스 요구들의 목록을 보여준다. 요구의 유효 값들이 도시되어 있다.

요구	값	섹션
GET_ASSOCIATION_INFORMATION	0x01	C.1.
GET_ASSOCIATION_REQUEST	0x02	C.2.
SET_ASSOCIATION_RESPONSE	0x03	C.3.

C.1. GET _ ASSOCIAT10N _ INFORMATION

이 요구는 장치로부터 association_information 구조를 검색한다. association_information은 REQUEST_INFO 블록들의 목록을 포함한다. 각 REQUEST_INFO 블록은 장치가 발행하기를 원하는 단일 연결 요구에 속한다. 표 30은 GET_ASSOCIAT10N_INFORMATION 요구의 예를 보여준다.

bmRequestType	bRequest	wValue	wIndex	wLength	데이터
10100001B	GET_ASSOCIATION_INFORMATION	0X0000	인터페이스	요구된 데이터의 길이	ASSOCIATION_ INFORMATION

표 31은 association_information 데이터 구조의 예를 보여준다. 데이터 구조의 처음 소수의 바이트(예컨대, 3 바이트)는 헤드 부분일 수 있다.

오프셋	필드	사이즈	값	설명
0	PendingRequestCount	1	0x00- 0xff	이 구조의 말미에 리스트되어 있는 계류중 요구들의 수
1	Flags	2	표 32 참조	표 32 참조
3	RequestInfoArray	Sizeof(REQUEST_INFO) *PendingRequestCount	0x000000 - 0xffffffff	REQUEST_INFO 구조들의 어레이(표 33 참조)

표 32는 association_information 플래그들의 예를 보여준다.

표 33은 request_info 구조를 보여준다.

C.2. GET _ ASSOCIAT10N _ REQUEST

이 요구는 장치로부터 특정 연결 요구를 검색한다. 이 요구는 wValue 필드 내의 RequestID 값에 의해 식별된다. 표 34는 GET_ASSOCIATION_REQUEST 요구의 예를 보여준다.

bmRequestType	bRequest	wValue	wIndex	wLength	데이터
10100001B	GET_ASSOCIATION_INFORMATION	RequestID BlockNumber	인터페이스	요구된 데이터의 길이	연결 요구

요구 블록은 4KB 데이터 블록일 수 있다. 제어 전송의 최대 전송 사이즈는 64KB에 설정될 수 있다. 따라서, 이론적으로 16개의 요구 블록들이 각 GET_ASSOCIAT10N_REQUEST에서 전송될 수 있다. 전송될 데이터의 실제 양은 wLength 필드에 의해 지정된다. wValue 필드에 지정된 BlockNumber는 이 제어 전송에 대한 시작 블록 번호를 식별한다. 장치는 오프셋 BlockNumber*4KB에서 시작하고 wLength 바이트를 전송하는 RequestID에 의해 지정된 요구에 대한 연결 요구 데이터를 반환할 수 있다.

C.3. SET _ ASSOCIAT10N _ RESPONSE

이 요구는 wValue 필드 내의 RequestID 값에 의해 식별되는 특정 연결 요구에 대한 응답을 송신한다. 표 35는 SET_ASSOCIAT10N_RESPONSE의 예를 보여준다.

bmRequestType	bRequest	wValue	wIndex	wLength	데이터
00100001B	SET_ASSOCIATION_RESPONSE	RequestID TransferFlags	인터페이스	응답 데이터의 길이	연결 응답

TransferFlags 값은 그 값들 중 0 이상의 비트단위 or이다. TransferFlags 값의 예가 표 36에 도시되어 있다.

PONG 시스템은 인터럽트 IN 메시지를 구현할 수 있다. 예를 들면, NewAssociationRequest는 장치가 처리될 필요가 있는 새로운 또는 수정된 연결 요구들을 갖고 있음을 호스트에 지시하는 데 사용될 수 있는 인터럽트 IN 메시지이다. 이 메시지를 수신하면, 호스트는 GET_ASSOCIAT10N_INFORMATION 요구를 발행하고, 그에 따라서 요구들을 처리할 것이다. 표 37은 NewAssociationRequest의 예를 보여준다.

도 23은 여기에서 설명된 특정 데이터 구조들을 이용하여 장치를 연결시키기 위한 프로세스(2300)의 예를 보여준다. 예시적 프로세스(2300)는 호스트가 USB를 이용하여 장치들을 구성하기 위해 PONG 시스템과 같은 확장 가능한 아키텍처에서 구현될 수 있다. 프로세스(2300)는 위에서 논의된 요구들 및 응답들과 관련하여 구현될 수 있다.

블록 2304에서, GET_ASSOCIATI0N_INFORMATION이 송신된다. 일 구현에서, 그 요구는 적어도 3 바이트의 데이터를 포함한다. 블록 2306에서, 총 연결 정보의 사이즈가 결정된다. 그 사이즈는 다음 식에 의해 결정될 수 있다.

사이즈 = 3 + sizeof(REQUEST_INFO)*PendingRequestCount

판정 블록 2308에서, 모든 연결 정보가 수신되었는지에 대한 판정이 행해진다. 만일 그렇지 않다면, 프로세스(2300)는 블록 2304로 되돌아간다. 만일 모든 연결 요구가 수신되었다면, 프로세스(2300)는 판정 블록 2310으로 진행하여 거기서 계류중인 요구(pending request)가 있는지에 대한 판정이 행해질 수 있다. 예를 들면, 그 판정은 PendingRequestCount 데이터 구조가 0보다 큰지를 판정함으로써 행해질 수 있다. 만일 계류중인 요구가 없다면(예컨대, PendingRequestCount = 0), 프로세스(2300)는 종료한다. 만일 계류중인 요구가 있다면, 프로세스(2300)는 블록 2312로 진행하여 거기서 프로세스는 처리할 요구를 선택한다.

블록 2314에서, 전송의 사이즈가 결정된다. 이 사이즈는 다음 식에 의해 결정될 수 있다.

사이즈 = max(남은 바이트, N*4KB (여기서 0 < N <= 16))

블록 2316에서, 적절한 양의 데이터에 대하여 GET_ASSOCIAT10N_REQUEST가 송신된다. RequestID는 연결 정보 내의 것과 일치해야 한다. BlockNumber는 반환될 시작 블록 번호이다. 판정 블록 2318에서, 요구 데이터가 더 있는지에 대한 판정이 행해진다. 만일 그렇다면, 프로세스(2300)는 블록 2314로 되돌아간다. 만일 그렇지 않다면, 프로세스는 블록 2320으로 진행하여 거기서 연결 요구가 처리되고 응답이 생성된다.

블록 2322에서, 응답 전송의 사이즈가 결정된다. 블록 2324에서, 적절한 양의 데이터에 대하여 GET_ASSOCIAT10N_RESPONSE가 송신된다. RequestID는 요구의 그것과 일치해야 한다. 만일 이 전송이 응답의 최종 바이트를 포함한다면, LastBlock이 설정되어야 한다. 판정 블록 2326에서, 데이터가 더 있는지에 대한 판정이 행해진다. 만일 그렇다면, 프로세스(2300)는 블록 2322로 되돌아간다. 만일 더 이상의 데이터가 없다면, 프로세스는 판정 블록 2328에서 계속되고 거기서 요구가 더 있는지에 대한 판정이 행해진다. 만일 그렇다면, 프로세스(2300)는 블록 2312로 되돌아간다. 만일 더 이상의 요구가 없다면, 프로세스는 판정 블록 2330으로 진행하고 거기서 AdditionalRequests 플래그가 연결 정보에서 설정되었는지에 대한 판정이 행해진다. 만일 그렇다면, 프로세스(2300)는 블록 2304로 되돌아간다. 만일 그 플래그가 설정되어 있지 않다면, 프로세스는 종료한다.

PONG 인터페이스를 지원하는 장치가 실제로는 장치 열거 시에 PONG 연결 요구를 송신할 준비가 되어 있지 않을 수도 있다. 예를 들면, 아마도 그 장치는 실제로는 어떤 사유 인터페이스(proprietary interface)를 통하여 PONG을 지원하는 다른 장치들에 대한 어떤 크레들(cradle) 유형이다. USB PONG 장치는 대상 장치가 크레들에 삽입되기 오래 전에 이미 열거되었다. 상술한 시스템들 및 기법들은 PONG 드라이머에게 그것이 새로운 연결 정보를 검색할 필요가 있음을 통지하는 메커니즘을 제공한다.

또한 복수의 연결 요구를 지원하는 특정 장치들이 필요할 수도 있다(예컨대, 복수의 대상 매체를 갖는 장치). 이들 개개의 연결 요구들은 서로에 의존하거나 또는 완전히 독립적일 수 있다. 독립적 연결은 장치가 대상 매체를 연결하는 순서에 대하여 걱정하지 않고 한번에 복수의 대상 매체를 연결하기를 원하는 경우이다. 상술한 시스템들 및 기법들은 호스트로부터 연결 응답을 수신한 후에, 장치가 그 응답의 결과로서 새로운 연결 요구를 발행하기로 결정하는 경우의 시나리오를 지원한다.

위에서 설명된 것은 설명된 본 발명의 예들을 포함한다. 물론, 본 발명을 설명할 목적으로 생각할 수 있는 모든 컴포넌트들 또는 방법들의 조합을 설명하는 것은 불가능하지만, 당 기술분야의 통상의 지식을 가진 자이면 본 발명의 또 다른 많은 조합들 및 변경들이 가능하다는 것을 인지할 수 있다. 따라서, 본 발명은 첨부된 청구항들의 정신 및 범위 내에 드는 모든 그러한 변경, 수정 및 변형들을 포함하도록 의도되어 있다. 또한, 상세한 설명 또는 청구항들에서 "포함한다(includes)"라는 용어가 사용되는 한, 그러한 용어는 "comprising"이라는 용어가 청구항에서 전이구(transitional word)로서 이용될 때 해석되는 것과 같이 "comprising"과 유사한 방식으로 포괄적인 것으로 의도되어 있다.

Claims

장치 실행가능 명령어들이 인코딩되어 있는 하나 이상의 장치 판독가능 매체로서, 상기 장치 실행가능 명령어들은,

신뢰할 수 있는 매체(trusted medium)를 통하여 WUSB(wireless universal serial bus) 장치로부터의 연결 요구(association request)를 식별하는 단계와;

상기 연결 요구를 구문분석(parsing)하는 단계와;

상기 WUSB 장치를 기술하는 장치 속성들(device attributes)을 생성하는 단계와;

상기 장치 속성들을 WUSB 장치들에 대한 핸들러에 송신하는 단계와;

상기 핸들러로부터 접속 속성들(connection attributes)을 수신하는 단계와;

상기 접속 속성들을 상기 신뢰할 수 있는 매체를 통하여 상기 WUSB 장치에 송신하는 단계

를 포함하는 단계들을 수행하기 위한 것인, 하나 이상의 장치 판독가능 매체.
제1항에 있어서,

상기 연결 요구에 포함된 연결 유형 식별자(association type identifier)를 식별하는 단계와;

요구되고 있는 상기 연결의 유형이 WUSB인 것을 판정하는 단계와;

상기 유형에 기초하여 상기 핸들러를 식별하는 단계

를 더 포함하는 하나 이상의 장치 판독가능 매체.
제1항에 있어서, WUSB와 관련된 표준에 기초하여 상기 구문분석된 연결 요구의 유효성을 검사(validating)하는 단계를 더 포함하는 하나 이상의 장치 판독가능 매체.
제1항에 있어서, 상기 WUSB 장치가 상기 접속 속성들에 따라서 무선 매체를 통하여 접속할 수 있게 하는 단계를 더 포함하는 하나 이상의 장치 판독가능 매체.
제1항에 있어서, 상기 신뢰할 수 있는 매체는 유선 매체(wired medium)인 하나 이상의 장치 판독가능 매체.
제1항에 있어서, 상기 신뢰할 수 있는 매체는 유선 USB 접속, 파이어와이어(firewire) 접속, 이더넷(Ethernet) 접속, 직렬 접속, 병렬 접속, 무선 접속, 근거리 무선 통신(NFC: near field communication) 접속, 또는 적외선(IR) 접속 중 적어도 하나를 포함하는 하나 이상의 장치 판독가능 매체.
제1항에 있어서, 상기 장치 속성들은 연결 유형 식별자, 접속 장치 식별자, 접속 키 식별자, 장치 셋업 클래스 GUID, 지원되는 대역 그룹, 또는 인터그레이터 사이트(integrator site) URL 중 적어도 하나를 포함하는 하나 이상의 장치 판독가능 매체.
제1항에 있어서, 상기 접속 속성들은 접속 호스트 식별자, 접속 장치 식별자, 접속 키 식별자, 선호 채널(preferred channels), 또는 호스트 영역(host region) 중 적어도 하나를 포함하는 하나 이상의 장치 판독가능 매체.
WUSB(wireless universal serial bus) 컴포넌트를 포함하는 접속 장치로서,

상기 접속 장치는 연결 요구를 신뢰할 수 있는 매체를 통하여 호스트 장치에 송신하도록 구성되고, 상기 연결 요구는 상기 접속 장치에 관련된 장치 속성들을 포함하고, 상기 접속 장치는 상기 호스트 장치로부터 접속 속성들을 수신하고, 상기 접속 속성들을 이용하여 상기 호스트 장치와의 WUSB 접속을 수립하도록 더 구성된 WUSB 컴포넌트를 포함하는 접속 장치.
제9항에 있어서, 상기 신뢰할 수 있는 매체는 유선 접속인 장치.
제10항에 있어서, 상기 유선 접속을 통하여 상기 호스트 장치와 통신하도록 구성된 유선 컴포넌트(wired component)를 더 포함하는 장치.
제11항에 있어서, 상기 유선 접속은 유선 USB 접속, 파이어와이어 접속, 이 더넷 접속, 직렬 접속, 또는 병렬 접속 중 적어도 하나를 포함하는 장치.
제10항에 있어서, 상기 장치 속성들은 연결 유형 식별자, 접속 장치 식별자, 접속 키 식별자, 장치 셋업 클래스 GUID, 지원되는 대역 그룹, 또는 인터그레이터 사이트 URL 중 적어도 하나를 포함하는 장치.
제10항에 있어서, 상기 접속 속성들은 접속 호스트 식별자, 접속 장치 식별자, 접속 키 식별자, 선호 채널, 또는 호스트 영역 중 적어도 하나를 포함하는 장치.
제10항에 있어서, 상기 접속 장치는 상기 WUSB 컴포넌트를 배열(arrange)하고 상기 접속 속성들을 이용하여 상기 호스트 장치에 접속하도록 더 구성되어 있는 장치.
유선 매체를 통하여 접속되어 있는 접속 장치와 호스트 장치 간의 통신 방법으로서,

상기 접속 장치로부터 상기 유선 매체를 통하여 상기 호스트 장치로, 상기 접속 장치의 WUSB 컴포넌트에 관련된 장치 속성들을 포함하는 연결 요구를 송신하는 단계와;

상기 호스트 장치에 의해, WUSB 접속들에 관련된 접속 속성들을 판정하는 단 계와;

상기 호스트 장치로부터 상기 유선 매체를 통하여 상기 접속 장치로, 상기 접속 속성들을 포함하는 응답을 송신하는 단계와;

상기 접속 장치에 의해, 상기 접속 속성들을 이용하여 상기 호스트 장치와의 접속을 수립하는 단계

를 포함하는 유선 매체를 통하여 접속되어 있는 접속 장치와 호스트 장치 간의 통신 방법.
제16항에 있어서, 상기 장치 속성들은 연결 유형 식별자, 접속 장치 식별자, 접속 키 식별자, 장치 셋업 클래스 GUID, 지원되는 대역 그룹, 또는 인터그레이터 사이트 URL 중 적어도 하나를 포함하는 방법.
제16항에 있어서, 상기 접속 속성들은 접속 호스트 식별자, 접속 장치 식별자, 접속 키 식별자, 선호 채널, 또는 호스트 영역 중 적어도 하나를 포함하는 방법.