SMPD (사양 관리 프로세스 문서)

이 문서는 제목이나 내용에 관계없이 Bluetooth SIG Inc.(“Bluetooth SIG”) 및 Bluetooth 특허/저작권 라이센스 계약 및 Bluetooth 상표 라이센스 계약에 따라 해당 회원이 부여한 라이센스가 적용되는 Bluetooth 사양이 아닙니다.

이 문서는 "있는 그대로" 제공되며 BLUETOOTH SIG, 해당 회원 및 그 계열사는 어떠한 진술이나 보증도 하지 않으며 상품성, 소유권, 비침해, 특정 목적에의 적합성에 대한 보증을 포함하여 명시적이든 묵시적이든 모든 보증을 부인합니다. 이 문서의 내용에는 오류가 없습니다.

법으로 금지되지 않는 범위 내에서 BLUETOOTH SIG, 그 회원 및 그 계열사는 수익 손실, 이익, 데이터 또는 프로그램 또는 비즈니스 손실을 포함하여 이 문서 및 이 문서에 포함된 모든 정보의 사용으로 인해 발생하거나 이와 관련하여 발생하는 모든 책임을 부인합니다. 서비스 중단, 또는 특별, 간접, 결과적, 부수적 또는 징벌적 손해의 경우, 원인과 책임 이론에 관계없이, 그리고 BLUETOOTH SIG, 그 회원 또는 그 계열사가 그러한 손해의 가능성에 대해 통보받은 경우에도 마찬가지입니다.

이 문서는 Bluetooth SIG의 소유입니다. 이 문서에는 Bluetooth SIG 및 해당 회원의 지적 재산에 해당하는 내용이 포함되어 있을 수 있습니다. 이 문서의 제공은 Bluetooth SIG 또는 그 회원의 지적 재산에 대한 라이센스를 부여하지 않습니다.

이 문서는 예고 없이 변경될 수 있습니다.

1. 서론

사양 관리 프로세스 문서(SMPD)는 사양 작성자와 재작성 프로세스를 설명합니다.view새로운 사양을 개발하고 기존 사양을 향상(즉, 채택된 사양에서 기능을 추가 또는 제거하거나 특정 기능을 변경)하고, 채택된 사양을 유지하고, 채택된 사양의 수명 종료를 관리하려면 따라야 합니다. 또한 이 문서에서는view백서를 작성하고 승인합니다.

새로운 사양을 개발하는 것과 기존 사양을 개선하는 것 사이에는 업무 범위의 본질적인 차이로 인해 사양 개발 프로세스에 차이가 있습니다. 이러한 차이점은 이 문서에 강조되어 있습니다.

사양 개발 프로세스에는 다음이 포함됩니다.

기능적 요구사항을 정의하기 위한 요구사항 단계(섹션 3에 설명됨)

개발 및 재개발을 위한 개발 단계(섹션 4에 설명됨)view 명세서
IOP(Interoperable Prototype) 테스트를 통해 사양을 검증하는 검증 단계(섹션 5에 설명됨)

채택/승인을 위해 Bluetooth SIG 이사회(BoD)에 사양을 제시하는 채택/승인 단계(섹션 6에 설명됨)

사양 정오표 프로세스 문서(EPD)[3]는 제안 및 재수정 프로세스를 설명합니다.view사양 정오표를 작성하고 이를 채택된 사양에 대한 정오표 수정(부칙 [2]에 정의됨)으로 승인합니다. 달리 명시하지 않는 한, 이 SMPD에서 정오표에 대한 모든 언급은 사양 정오표를 의미합니다.

1.1 우선순위

Bluetooth SIG, Inc.의 조례(조례) 및 멤버십 계약[2]은 해당 문서와 SMPD의 상충되는 내용보다 우선합니다. 본 문서의 모든 내용에도 불구하고, 이사회는 해당 조치와 결정이 본 문서의 내용을 따르지 않거나 충돌하더라도 조치를 취하고 결정을 내릴 수 있는 궁극적인 재량권과 권한을 보유하며, 본 문서의 어떤 내용도 이사회의 독립적 권한을 제한하거나 제한하지 않습니다. 그리고 재량권.

SMPD의 텍스트와 그림 사이에 충돌이 있는 경우 텍스트가 우선적으로 적용됩니다.

1.2 참조 그룹 및 위원회

이 문서에서는 SG(연구 그룹), EG(전문가 그룹) 및 WG(작업 그룹) 유형의 그룹을 참조합니다. WG에는 WG에 보고하는 하위 그룹이 있을 수도 있습니다. 마찬가지로 이 문서에서는 다음 유형의 위원회가 참조됩니다. Bluetooth 아키텍처 Review 보드(BARB), Bluetooth 테스트 및 상호 운용성(BTI) 및 Bluetooth 인증 Review 보드(BQRB). 이 문서에서는 Bluetooth SIG 기술 직원(BSTS) 및 BoD도 참조합니다.

1.3 위원회 재view및 승인

위원회 재view 재이다view 이는 위원회 구성원(일반적으로 3명)이 지정된 시간(일반적으로 2~3주) 내에 피드백을 제공하기 위해 수행됩니다.view 시간은 자료의 길이와 복잡성, 위원회 내 기타 우선순위에 따라 달라질 수 있습니다. 다시 요청하는 그룹view 그리고 그 재심사를 수행하는 위원회는view 각자는 재계약 기간에 동의합니다.view. 그룹과 위원회 구성원은 Bluetooth SIG 도구를 사용하여 작업의 시작과 끝을 알리고 기록합니다.view. 그룹은 일반적으로 위원회 피드백이 접수되면 이를 처리합니다. 위원회가 다시view 시간이 만료되면 그룹은 위원회 피드백 처리를 완료하고 늦게 도착하는 문제도 고려해야 합니다.view 해당 자료는 위원회의 후속 승인을 받아야 할 수도 있다는 점을 염두에 두고 피드백을 제공합니다.

위원회 승인은 실무그룹 프로세스 문서[4]에 따라 위원회 구성원의 투표를 통해 획득됩니다.

1.4 회원에 대한 통지 및 자료 접근성

본 문서에 따라 회원에게 제공되는 모든 통지는 정기적인 기술 업데이트 등 이메일을 통해 제공될 수 있습니다. 모든 회원에게 제공될 알림은 모든 활성 회원(즉, 회원 자격이 정지, 종료 또는 철회되지 않은 경우)에게 전송됩니다. 알림이 이메일로 전송되면 회원사의 멤버십 계정에 등록하고 이메일 알림 수신을 거부하지 않은 각 개인의 마지막으로 알려진 이메일 주소(Bluetooth SIG의 당시 기록에 반영됨)로 전송됩니다. 이 문서의 어떤 내용도 Bluetooth SIG 내규 또는 Bluetooth SIG와 회원 간의 기타 계약에 따른 통지 제공과 관련된 의무 또는 요구 사항을 변경하지 않습니다.

이 문서가 언급되는 곳마다 web모든 회원이 접근할 수 있는 사이트, 이는 활성 Bluetooth SIG 계정을 가진 개인이 접근할 수 있음을 의미합니다. 활성 계정이 없는 회원은 Bluetooth SIG를 통해 계정을 만들 수 있습니다. web대지.

1.5 템플릿

본 SMPD에 언급된 각 문서 유형(예: 사양, 백서, 테스트 문서)에 대해 Bluetooth SIG는 템플릿을 제공합니다. 템플릿은 본 SMPD에 따라 생성된 각 문서의 기초로 사용되어야 합니다. 올바른 템플릿을 사용하지 않으면 문서가 승인되지 않을 수 있습니다. 템플릿은 Bluetooth SIG에서 사용할 수 있습니다. web사이트 [8].

1.6 사양 유형

Bluetooth SIG 사양에는 여러 유형이 있습니다. 계층적으로 모든 사양은 Bluetooth 핵심 사양에 따라 달라집니다. 전통적인 프로와 같은 사양file에스; 전통적인 프로토콜; 및 GATT 기반 프로files, GATT 기반 서비스 및 GATT 기반 프로토콜은 모두 핵심 사양 내의 기능에 따라 달라집니다. Mesh Model 사양과 같은 기타 사양은 Mesh Pro에 따라 다릅니다.file 사양은 핵심 사양에 따라 달라집니다.

CSS(Core Spec Supplement) 사양은 데이터 유형, 데이터 형식 및 공통 프로페셔널을 정의합니다.file 핵심 사양 및 기타 사양에서 사용되는 서비스 오류 코드는 그 자체로 어떠한 동작도 정의하지 않습니다.

GATT 사양 보충(GSS) 사양은 Pro에서 사용되는 특성 및 설명자 형식을 정의합니다.file및 서비스 자체는 어떠한 동작도 정의하지 않습니다.
MDP(Mesh Device Properties) 사양은 Mesh Pro에서 사용되는 메시 속성을 정의합니다.file 및 메쉬 모델 사양은 자체적으로 어떠한 동작도 정의하지 않습니다.

2. 이상view

이 섹션에서는 다음을 제공합니다.view 모든 세부 사항을 포함하지는 않습니다.

그림 2.1은 사양 관리 프로세스를 구성하는 XNUMX가지 주요 단계를 보여줍니다.

처음 3개 단계는 사양 개발 프로세스 중에 발생하며 요구 사항 단계(섹션 4), 개발 단계(섹션 5), 검증 단계(섹션 6) 및 채택/승인 단계(섹션 7)로 구성됩니다. 그 다음에는 사양 유지 단계(섹션 8)와 사양 수명 종료 단계(섹션 XNUMX)라는 두 가지 채택 후 단계가 이어집니다.

그림 2.2는 사양 개발 프로세스의 XNUMX단계 세부 사항을 보여줍니다. 회색 상자는 각 단계의 주요 결과물을 나타냅니다. 주황색 상자에는 프로세스 마일스톤이 요약되어 있습니다.

요구 사항 단계(섹션 3에 설명됨)에서 새 작업을 시작하라는 제안(NWP(새 작업 제안))은 새 작업이 진행되는 경우 활성화될 사용자 시나리오를 정의하여 사양 개발 프로세스를 시작합니다. NWP가 승인되면 할당된 그룹은 기능 요구 사항 문서(FRD)를 생성합니다. FRD가 승인되어 그룹에 할당되면 개발 단계가 시작됩니다.

개발 단계(섹션 4에 설명됨) 동안 사양 개발은 일련의 단계를 통해 진행됩니다.tages(0.5/DIPD ~ 0.9/CR)를 거쳐 사양의 완전한 초안이 완성됩니다. 0.9/CR 사양은 모든 회원이 사용할 수 있게 된 다음 승인을 위해 사양을 고려하는 이사회에 제출됩니다. 승인되면 검증 단계가 시작됩니다.

사양 개발의 검증 단계(섹션 5에 설명됨) 동안 BoD가 승인한 0.9/CR 사양은 모든 회원이 다시 사용할 수 있습니다.view 확인하고 회원 재view 시작됩니다. 검증은 회원이 구축한 프로토타입 간의 상호 운용성(IOP) 테스트를 통해 수행됩니다. IOP 테스트가 완료되고(사양에 필요한 경우) BARB가 IOP 테스트 보고서를 승인하면 채택/승인 단계가 시작됩니다.

채택/승인 단계(섹션 6에 설명됨) 동안 사양 및 관련 테스트 문서가 완성됩니다. BARB, BQRB 및 BTI 승인을 받았습니다. 최종 사양 패키지는 채택(즉, 최종 승인) 사양을 고려하는 이사회에 제출됩니다.

사양은 이전 단계로 돌아가야 할 수도 있습니다.tage 중요한 변경이 이루어진 경우. 어떤 경우에는 섹션 4.4에 설명된 대로 단계의 일부를 면제하는 것도 가능할 수 있습니다.

사양 유지 단계(섹션 7에 설명됨)는 BoD가 사양을 채택한 후에 시작됩니다. 이 단계에서는 채택된 사양에서 발견된 잠재적인 오류가 보고 및 평가되며, (필요한 경우) 사양에 대한 정오 수정이 이루어집니다. 사양 유지 관리 단계는 사양이 더 이상 사용되지 않거나 철회될 때까지 계속됩니다(다음 단락의 사양 수명 종료 단계 참조).

사양 수명 종료 단계(섹션 8에 설명됨)에서는 채택된 사양을 더 이상 사용하지 않고 철회하는 프로세스를 설명합니다.

3. 요구사항 단계

요구 사항 단계는 NWP(하나 이상의 사용자 시나리오에 대한 작업을 시작하려는 욕구를 명시)로 시작하거나 원하는 새 작업이 이미 WG 헌장에 포함되어 있다는 결정이 나온 후에 시작됩니다. WG가 이미 WG 헌장의 범위 내에 있다고 믿는 새로운 작업을 시작하려는 경우 WG는 섹션 3.1에 정의된 프로세스를 따라 FRD 개발을 직접 진행해야 합니다. 다른 모든 작업 항목의 경우 WG는 섹션 3.2에 정의된 프로세스를 따라야 합니다. FRD는 개발 단계에서 사양을 구축하는 데 사용되는 기능 요구 사항의 범위를 정의합니다. 요구사항 단계는 그림 3.1에 설명되어 있습니다.

3.1 WG 헌장이 적용되는 신규 작업

WG가 새로운 작업을 시작하기를 원하고 추가하려는 기능이 이미 WG 헌장의 범위 내에 있다고 합리적으로 믿는 경우, WG는 즉시 BARB에 통보하는 조건으로 FRD에 대한 작업을 시작할 수 있습니다. WG는 제안된 새 작업에 대한 설명과 새 작업을 시작할 권한을 부여하는 언어가 강조 표시된 WG 헌장 사본을 BARB에 보내는 통지에 포함합니다.

BARB가 WG의 분석을 거부하는 경우 WG는 FRD 작업을 중단하고 섹션 3.2에 설명된 NWP 프로세스를 진행해야 합니다. BARB가 WG의 분석을 승인하면 WG는 즉시 BSTS에 통보하고(사양.manager@bluetooth.com으로 이메일을 통해) BSTS는 해당 항목을 다음 이사회 안건에 추가합니다.

WG는 BARB에 제공한 것과 동일한 정보를 BSTS에 대한 통지에 포함시킵니다. 이사회가 WG의 분석을 거부하는 경우 WG는 FRD에 대한 작업을 중단하고 섹션 3.2에 설명된 NWP 프로세스를 진행해야 합니다. 이사회가 WG의 분석을 승인하면 WG는 섹션 3.3에 설명된 대로 FRD에 대한 작업을 계속할 수 있습니다.

3.2 신규 작업 제안(NWP)

모든 회원, WG, SG 또는 EG는 Bluetooth SIG를 통해 NWP를 작성하고 제출할 수 있습니다. web사이트 [10]). NWP에는 최소한 [8]에 제공된 공식 템플릿을 사용하여 다음에 대한 정보가 포함되어야 합니다.

사용자 시나리오
FRD 개발에 대한 회원의 약속 및 영역(예: 기여자, 저자, 재원)view어, 프로토타이핑)
FRD 작업의 리더십 제안
FRD 작업을 위한 제안된 그룹 할당
주 저자의 이메일 주소

메모: NWP 프로세스에 대한 지침은 Bluetooth SIG에서 확인할 수 있습니다. web사이트 [10].

BSTS는 NWP 개발 과정에서 다음과 같은 작업을 수행합니다.

작성자에게 수령 확인서를 제공하고(일반적으로 수령 후 7일 이내) 다음 단계에 대한 개요를 제공합니다.
필요한 경우 작성자와 협력하여 NWP가 명확하고 완전하도록 하세요. 이를 위해서는 NWP를 여러 번 반복해야 할 수도 있습니다.
NWP에 채택된 Bluetooth 사양의 오류에 대한 설명이 포함되어 있는 경우 작성자와 협력하여 file 정오표 시스템에 항목을 입력합니다.
NWP가 이미 진행 중이거나 이미 완료된 작업을 잠재적으로 복제하고 있다는 사실이 발견되면 평가를 위해 다른 작업의 작성자에게 알리십시오.
NWP를 NWP에 게시 web모든 회원이 이용할 수 있는 사이트입니다.

NWP를 다시 사용할 수 있음을 모든 구성원에게 알립니다.view 그리고 FRD 개발을 위한 추가 회원의 약속이 필요한지 여부.

회원은 저자에게 연락하여 NWP에 관한 질문을 하거나 피드백을 제공할 수 있습니다.

NWP가 이사회 승인 후보가 되려면 최소한 3.3개 이상의 회원사가 FRD 결과 완료에 참여하기로 약속해야 하며, 최소한 XNUMX개의 회원사가 준회원 또는 발기인 회원이어야 합니다. 이사회가 NWP를 승인하면 이사회는 NWP를 기존 전체 구성원 WG 하위 그룹 또는 SG에 할당하여 FRD 작업을 수행하게 합니다(섹션 XNUMX에 설명됨). 적절한 WG 하위 그룹이나 SG가 존재하지 않는 경우 새로 생성될 수 있습니다.

충분한 회원 헌신이 있는 NWP의 경우 BSTS는 다음과 같은 추가 작업을 수행합니다.

NWP가 이사회 승인을 받기로 제안되기 최소 13일 전에 BARB 및 NWP 할당이 권장되는 그룹에 계류 중인 NWP 승인을 통보합니다. 이는 제안된 그룹, NWP가 기존 작업에서 이미 다루어지고 있는지 여부 등의 영역에 대한 피드백 기회를 제공하기 위해 수행됩니다.
완성된 NWP를 이사회에 제출합니다.

그룹에 소속되지 않은 구성원이 NWP를 제출하는 경우 구성원 중 한 명이 NWP를 이사회에 제출하도록 주선합니다.

그룹이 NWP를 제출하는 경우 그룹 의장이 NWP를 이사회에 제출하도록 주선합니다.
BARB 의장과 NWP가 임명하도록 추천된 그룹의 의장을 이사회에 초대합니다.
NWP가 이사회에 의해 승인되고 할당된 경우 할당된 그룹에 통보합니다. 저자(들); NWP에서 해당 FRD 개발에 전념하는 것으로 확인된 회원; NWP가 그룹에 의해 제안된 경우 결과 및 다음 단계에 대한 그룹입니다.

NWP가 BoD에서 승인된 후 NWP의 상태를 업데이트합니다. web대지.

모든 NWP는 이사회 재량에 따라 거부될 수 있습니다.amp파일, 리소스 제한으로 인해 작업이 이미 완전히 완료된 경우 해당 작업은 Bluetooth SIG 관리 문서(예: API(응용 프로그래밍 인터페이스))[2]의 범위를 벗어나거나 제안된 작업이 filed 정오표로. NWP가 거부되면 BSTS는 작성자, NWP에서 식별된 회원에게 해당 FRD 개발을 약속한 것으로 알리고 NWP가 그룹에 의해 제안된 경우 해당 그룹에 알립니다. 통지에는 거부 사유가 포함됩니다. 작성자, 헌신적인 구성원 또는 그룹은 거부에 대해 항소하기 위해 이사회 안건에 대한 시간을 요청할 수 있습니다.

구성원이나 그룹이 채택된 사양에서 기능 제거를 제안하려는 경우 그룹이나 구성원은 NWP를 준비해야 합니다. NWP에는 테스트 사례에 대한 영향 분석을 포함하여 제거가 이전 버전과의 호환성 및 상호 운용성에 미치는 영향에 대한 분석이 포함되어야 합니다.

CSS, GSS 또는 MDP 사양을 개선하는 데에는 NWP가 필요하지 않습니다. 일반적으로 CSS, GSS 또는 MDP 사양에 대한 업데이트는 자체 NWP가 있는 다른 사양에 대한 업데이트로 인해 발생합니다.

3.3 기능적 요구사항 문서(FRD)

FRD는 사용자 시나리오를 활성화하기 위한 기능적 요구 사항을 정의합니다. FRD에는 최소한 [8]에 제공된 공식 템플릿을 사용하여 다음에 대한 정보가 포함되어야 합니다.

사용자 시나리오
사용자 시나리오에 따른 기능 요구 사항
결과 사양을 개발하겠다는 회원의 약속
예상되는 역할에 대한 구성원의 선택적 프로토타입 지원
결과 사양 개발을 위해 WG를 권장함

FRD 개발

FRD는 BSTS의 편집 지원을 받아 지정된 전체 구성원 WG 하위 그룹 또는 SG 구성원에 의해 생성됩니다. FRD 개발 참여에 관심이 있는 회원이라면 누구나 그룹에 가입할 수 있습니다.

FRD는 결과 사양 개발에 참여하겠다는 최소 2개(3개 권장)의 Associate 또는 Promoter 수준 회원사로부터의 약속을 나타내야 합니다. FRD를 제출하는 WG 또는 SG는 FRD에서 식별된 의도된 목표 산업 분야를 대표하는 그룹 회원사로부터 광범위한 지원을 얻으려고 노력해야 합니다.

FRD에서 제안된 새로운 기능은 가능한 한 많은 전송 및 기존 장치에서 지원 가능해야 합니다. 여기에는 예를 들어ample, GATT 기반 프로 지원file기본 속도/확장 데이터 속도(BR/EDR) 전송과 Bluetooth 저에너지(LE) 전송 모두에 대한 서비스 및 서비스를 제공합니다. 예를 들어 새로운 기능에 전송에 대한 회원 지원이 부족한 경우amp전송 사용을 정의하려는 회원의 약속이 부족하거나 하나 이상의 역할에 대한 IOP 테스트 플랫폼 수가 잠재적으로 부족하기 때문에 해당 전송에 대한 지원이 FRD에서 제외될 수 있습니다.

달리 정당화되지 않는 한, 새로운 기능인 Profile및 서비스는 섹션 3.3.2에 설명된 이전 버전과의 호환성 요구 사항을 준수해야 합니다.

WG 또는 SG는 재확인을 위해 FRD를 BARB에 제출해야 합니다.view 그리고 승인. BARB는 엔지니어링 판단에 따라 FRD를 승인하거나 거부해야 합니다. BARB가 승인하면 FRD는 모든 회원에게 공개되며 BSTS는 FRD의 가용성에 대한 통지를 발행합니다.

CSS, GSS 또는 MDP 사양을 개선하는 데에는 FRD가 필요하지 않습니다. 일반적으로 CSS, GSS 또는 MDP 사양에 대한 업데이트는 자체 FRD가 있는 다른 사양에 대한 업데이트로 인해 발생합니다.

이전 버전과의 호환성 요구 사항

BR/EDR에 대한 하위 호환성

BR/EDR 작동의 경우 이전 버전과의 호환성 요구 사항은 Bluetooth 핵심 사양 v1.1 이상의 BR/EDR 부분과의 상호 운용으로 정의됩니다.

Bluetooth Low Energy에 대한 하위 호환성

LE 작동의 경우 이전 버전과의 호환성 요구 사항은 Bluetooth 핵심 사양 v4.0 이상의 LE 부분과의 상호 운용으로 정의됩니다.

핵심 사양 이외의 사양에 대한 하위 호환성

Bluetooth 핵심 사양 이외의 사양의 경우 해당 버전의 하위 호환성은 동일한 주요 버전 번호를 가진 모든 이전 버전과 유지되어야 합니다. 예를 들어amp파일에 따르면 버전 1.3은 버전 1.2, 1.1, 1.0과 호환되어야 하지만 버전 2.0은 버전 1.0, 1.1, 1.2, 1.3과 호환되지 않을 수 있습니다. 핵심 사양의 주요 버전 번호가 증가한다고 해서 이전 버전과의 호환성이 부족하다는 의미는 아닙니다.

이전 버전과의 호환성 요구 사항 면제

WG 또는 SG는 정당성이 제공되는 경우 이전 버전과의 호환성 요구사항에서 특정 기능을 면제하도록 제안할 수 있습니다. 예를 들어amp즉, 해당 기능이 시장 채택률이 낮은 것으로 나타나거나 상호 운용성 문제로 인해 기능을 수정하는 것보다 제거하거나 교체하는 것이 더 좋습니다. WG 또는 SG는 FRD의 승인 시 BARB가 승인한 FRD의 이전 버전과의 호환성 면제를 포함해야 합니다. BARB가 승인한 모든 면제 사항은 0.9/CR S에서 승인을 위해 이사회에 제출됩니다.tage.

3.4 실무그룹 헌장

BARB가 기존 WG에 할당되도록 제안된 FRD를 승인하면 해당 WG는 범위에 새로운 기능을 추가하기 위해 헌장 업데이트 초안을 준비해야 합니다(BoD가 이전에 WG 헌장 업데이트가 다음과 같다는 WG의 분석을 승인한 경우 제외). 필수는 아닙니다). 그러나 BARB가 새로운 WG에 할당되도록 제안된 FRD를 승인하면 FRD에 설명된 기능 개발에 관심이 있는 BARB 및 회원은 헌장 범위에 포함된 새로운 기능을 포함하는 새로운 WG에 대한 헌장 초안을 준비해야 합니다. .

신규 또는 업데이트된 WG 헌장이 준비되면 재검토를 위해 BARB에 제출해야 합니다.view 그리고 승인. BARB가 헌장을 승인하면 신규 또는 업데이트된 WG 헌장의 초안이 승인을 위해 이사회에 제출됩니다.

BoD가 헌장을 승인하면, BoD가 사양 개발 작업을 할당한 WG는 해당 FRD에 필요한 업데이트나 설명이 필요한 경우 FRD를 준비한 그룹과 긴밀히 협력해야 합니다. 개발 단계 중에 FRD 업데이트가 필요한 경우 섹션 3.3과 이 섹션에 설명된 프로세스를 따라야 합니다. 그러나 사양 개발은 FRD 및 WG 헌장 업데이트와 병행하여 이루어질 수 있습니다.

3.5 요구사항 단계 종료 요구사항

FRD에 필요한 범위가 포함된 WG 헌장이 이사회에 의해 확인 또는 승인되고 다음 요구 사항이 충족되면 요구 사항 단계가 완료되고 개발 단계가 시작됩니다.

NWP는 이사회의 승인을 받았거나 이사회가 NWP가 불필요하다는 데 동의했습니다.
FRD 및 해당 WG 헌장은 BARB의 승인을 받았습니다.

4. 개발 단계

개발 단계 동안 할당된 WG는 새로운 사양을 생성하거나 기존 사양을 향상시킵니다. FRD는 새롭거나 향상된 Bluetooth 사양의 요구 사항을 정의합니다. FRD의 요구 사항과 합리적으로 관련되지 않은 기능은 사양에서 허용되지 않습니다. 목표는 개발 단계가 끝날 때 검증 단계(섹션 0.9에 설명됨)를 위한 준비가 된 5/CR 사양을 만드는 것입니다.
개발 단계 동안 사양(또는 사양 향상)은 3초를 거쳐 발전합니다.tag에스.

새로운 사양의 경우 세 개의 stages는 다음과 같습니다:

0.5 초tage
0.7 초tage
0.9 초tage

사양 향상을 위해 세 가지tages는 다음과 같습니다:

개선 제안서 초안(DIPD) Stage
최종 개선 제안서(FIPD) Stage
변경 요청(CR) Stage

각 stage에 대해서는 다음 하위 섹션에서 자세히 설명합니다. 아래 그림 4.1은 WG가 매 순간 준비할 다양한 문서를 보여줍니다.tage.

그림 4.1: 이상view 사양의tag개발 단계에서 발생하는 문제

사양 개발 프로세스 전반에 걸쳐 BARB의 역할은 WG에 조언과 기술 지원을 제공하는 것입니다. WG는 언제든지 BARB에 사양 개발 및 사양에 사용될 아키텍처 개념에 관한 기술적 조언을 요청할 수 있습니다. WG는 특히 더 복잡한 아키텍처 고려 사항이 있는 기능에 대해 BARB로부터 초기 피드백을 요청하는 것이 좋습니다.

4.1 0.5/DIPD Stage

0.5/DIPD S 동안tage, WG는 [8]에 제공된 공식 템플릿을 사용하여 다음을 개발합니다.

새로운 사양의 경우 0.5 사양 초안에는 최소한 다음 정보가 포함되어야 합니다.

FRD에 명시된 요구 사항을 충족하는 아키텍처
프로토콜의 경우 서비스 액세스 포인트가 정의됩니다.
서비스의 경우 노출된 데이터 및 행위
프로를 위해files, 식별된 프로토콜 및 지정된 기능

2. 사양 향상을 위해 최소한 다음 정보를 포함해야 하는 DIPD 초안:

배경: 작업 범위, 작업을 안내하는 목표, 이 특정 제안이 범위에 어떻게 부합하는지

위에view 제안 내용: 새로운 기능이 현재 사양 버전에 어떻게 적용되는지에 대한 명확한 설명을 포함하여 DIPD에서 제공하는 확장된 기능(유연성 추가, 성능 향상 등)에 대한 요약입니다. WG가 여러 제안을 평가한 경우 BARB가 선호하는 제안을 선택할 때 충분한 실사가 이루어졌는지 결정할 수 있도록 이러한 제안을 포함해야 합니다.
요구사항 적용 범위: 관련 FRD에 제공된 적절한 시스템 요구 사항 및 사용 시나리오를 참조하여 제안에서 제공한 기능 요구 사항의 적용 범위 요약
문제 정의: 제안에 의해 해결된 문제에 대한 설명

선택 기준: 선택 프로세스를 안내한 관련 평가 지표의 선택/성과 기준에 관한 설명
선택의 정당성: 제안 간의 선택을 정당화하고 장단점을 드러내는 평가 지표에 대한 조사
설명: 기능 및 확장 프로토콜에 대한 설명입니다. 이 섹션은 관련 하위 섹션을 추가하여 다양한 요구에 맞게 조정할 수 있습니다.

3. 테스트 전략: Bluetooth 인증 프로그램의 일부로 테스트하도록 제안된(또는 테스트하지 않음) 기능에 대한 설명과 해당 기능이 테스트되도록 제안된 방법(예: 하위 테스터 또는 상위 테스터에 대한 기대치) 테스트가 적합성, 상호 운용성 테스트 또는 둘의 조합으로 간주되는 경우) 이는 0.5/DIPD 사양 내의 별도 문서나 별도 섹션에 있을 수 있습니다. 테스트 전략에 사용되는 규칙은 테스트 전략 및 용어에 설명되어 있습니다.view 문서(TSTO) [5].

이 문서의 주요 독자는tage는 WG 회원이자 BARB입니다.view 아키텍처 제안 및 요구 사항 적용 범위, 그리고 BTIview테스트 전략입니다. 대부분의 경우 이 문서는tage에는 최종 사양에 포함될 예정인 텍스트가 포함되지 않습니다.

BSTS는 다시 해야 합니다.view Bluetooth 초안 작성 지침[1]과의 일관성을 위해 모든 문서를 작성하고 WG가 해결해야 할 문제를 식별합니다. BARB는 다시해야합니다view 0.5/DIPD 사양. 사양 향상을 위해 BARB는 또한view 섹션 3.3.2에 설명된 이전 버전과의 호환성 요구 사항을 준수하기 위한 DIPD. BTI는 다시 해야 합니다.view 테스트 전략.

BARB는 엔지니어링 판단에 따라 0.5/DIPD 사양을 승인하거나 거부해야 합니다. BARB가 승인하면 0.5/DIPD 사양이 Bluetooth SIG에서 제공됩니다. web모든 Associate 및 Promoter 회원에게 사이트를 공개하고 BSTS에서 사이트 이용 가능 여부를 공지합니다. 0.5/DIPD S에서tage, 테스트 전략의 승인이 필요하지 않습니다.
0.5/DIPD Stage는 CSS, GSS 또는 MDP 사양을 개선하는 데 필요하지 않습니다.

0.5/DIPDStage 종료 요건

0.5/DIPD Stage는 완전하고 0.7/FIPD Stage는 다음 종료 요구 사항이 충족되면 시작됩니다.

BSTS가 다시 완료되었습니다.view0.5/DIPD 사양 및 테스트 전략을 참조하세요.

BARB는 0.5/DIPD 사양을 승인했습니다.
BTI가 재작업을 완료했습니다.view 테스트 전략의
BSTS는 승인된 0.5/DIPD 사양을 모든 Associate 및 Promoter 회원이 사용할 수 있도록 만들었습니다.

4.2 0.7/FIPDStage

0.7/FIPD S 동안tage, WG는 [8]에 제공된 공식 템플릿을 사용하여 다음을 개발합니다.

새로운 사양의 경우 0.7 사양 초안에는 최소한 다음 정보가 포함되어야 합니다.

신규 또는 수정된 제안, 선택 기준 및 선택의 정당성을 포함하여 BARB가 승인한 0.5 이후에 이루어진 모든 변경 사항에 대한 설명입니다. 변경 사항은 0.5 S에서 요구되는 것과 동일한 수준으로 세부적으로 설명되어야 합니다.tage.
FRD의 모든 기능적 요구 사항이 해결되었습니다.

2. 사양 향상을 위해 FIPD 초안에는 최소한 다음 정보가 포함되어야 합니다.

신규 또는 수정된 제안, 선택 기준 및 선택의 정당성을 포함하여 BARB가 승인한 DIPD 이후 이루어진 모든 변경 사항에 대한 설명입니다. 변경 사항은 DIPD S에서 요구하는 것과 동일한 수준으로 자세히 설명되어야 합니다.tage.

필요에 따라 DIPD와 관련하여 섹션 4.1에 설명된 영역을 추가로 개발했습니다.
개선 사항에 대한 완전한 설명입니다.
업데이트된 아키텍처 설명입니다.
FRD의 모든 기능적 요구 사항이 해결되었습니다.

3. 0.7/FIPD 테스트 문서에는 최소한 다음 정보가 포함되어야 합니다.

TSTO [5]에 설명된 테스트 목적 목록으로 구성된 테스트 스위트입니다.

TSTO [5]에 설명된 구현 적합성 선언문(ICS).

사양 향상을 위해 테스트 스위트와 ICS는 별도의 문서로 제공되거나 FIPD의 추가 섹션으로 제공될 수 있습니다.

이번 회의에서 제작된 문서의 주요 독자tage는 WG 회원이자 BARB입니다.view 최종 사양에 포함될 예정인 일부 텍스트를 포함하여 기능 또는 개선 사항에 대한 전체 설명입니다. BTI는 다시 청중입니다view 테스트 문서 중.

BSTS는 다시view 0.7/FIPD 사양의 새로운 부분 또는 변경된 부분 및 Bluetooth SIG에서 확립한 언어 규칙을 포함하여 Bluetooth 초안 작성 지침과의 일관성을 위한 테스트 문서입니다. BARB는 다시view 0.7/FIPD 사양.

BSTS는 TSTO[0.7]에 따라 WG가 5/FIPD 테스트 문서를 준비하는 데 도움을 줄 것입니다.

BTI는 다시 해야 합니다.view 0.7/FIPD 테스트 문서. WG는 재작업 시 참조로 BTI에 0.7/FIPD 사양을 제공해야 합니다.viewBTI가 재검토할 0.7/FIPD 테스트 문서 작성view BTI 사양 Re에 따라view 프로세스 체크리스트 [6].

BARB가 재작업을 완료한 후view 0.7/FIPD 사양 및 BTI의 재작업을 완료했습니다.view 0.7/FIPD 테스트 문서 중 BSTS가 다시 만들 것입니다.view모든 Associate 및 Promoter 회원은 ed 0.7/FIPD 사양을 사용할 수 있습니다.

0.7/FIPD Stage는 CSS, GSS 또는 MDP 사양을 개선하는 데 필요하지 않습니다.

0.7/FIPDStage 종료 요건

0.7/FIPD Stage는 완료되었으며 0.9/CR Stage는 다음 종료 요구 사항이 충족되면 시작됩니다.

BSTS가 다시 완료되었습니다.view0.7/FIPD 사양 및 테스트 문서를 참조하세요.
BARB가 다시 완료했습니다.view0.7/FIPD 사양을 참조하세요.
BTI가 다시 완료했습니다.view0.7/FIPD 테스트 스위트(테스트 목적) 및 0.7/FIPD ICS를 제공합니다.
BSTS가 다시 만들었습니다view모든 Associate 및 Promoter 회원은 ed 0.7/FIPD 사양을 사용할 수 있습니다.

4.3 0.9/CR Stage

CR에는 두 가지 유형이 있습니다. 이전 버전 이후의 모든 변경 사항을 표시하는 전체 채택 사양의 변경 추적 문서인 통합 CR과 영향을 받는 섹션만 수정하기 위한 지침을 제공하는 문서인 단축 CR입니다. CR의 기반이 되는 사양 버전입니다.

0.9/CR S 기간 동안tage, WG는 [8]에 제공된 공식 템플릿을 사용하여 다음을 개발합니다.

새로운 사양의 경우, 최소한 다음에 대한 정보를 포함해야 하는 0.9 사양의 내용 전체 초안입니다.

BARB-re 이후에 이루어진 모든 변경 사항에 대한 설명viewed 0.7 사양(또는 0.5 사양을 생성하는 경우 0.7 사양 이후), 새로운 사양 또는
수정된 제안, 선택 기준 및 선택의 정당성. 변경 사항은 0.5 S에서 요구되는 것과 동일한 수준으로 세부적으로 설명되어야 합니다.tag전자 및 0.7 Stage.

2. 사양 개선의 경우:

최소한 다음 정보를 포함해야 하는 통합 CR입니다.

BARB-re 이후에 이루어진 모든 변경 사항에 대한 설명view신규 또는 수정된 제안, 선택 기준 및 선택의 정당성을 포함하여 FIPD(또는 FIPD가 면제된 경우 DIPD 이후)를 수정했습니다. 변경 사항은 DIPD S에서 요구하는 것과 동일한 수준으로 자세히 설명되어야 합니다.tage와 FIPD Stage.
변경 추적을 사용하여 이전에 채택된 사양에 제안된 모든 변경 사항입니다.
변경 추적을 사용하여 표시된 모든 승인된 기술 정오표(정오표 번호로 참조되는 각 정오표 포함)는 이전에 채택된 사양 버전에 아직 통합되지 않았으며 사양 개선과 관련된 텍스트에 영향을 미칩니다. 또는 IOP 테스트에 영향을 미치는 경우.

3. 또는 최소한 다음 정보를 포함해야 하는 간략한 CR입니다.

BARB-re 이후에 이루어진 모든 변경 사항에 대한 설명view신규 또는 수정된 제안, 선택 기준 및 선택의 정당성을 포함하여 FIPD(또는 FIPD가 면제된 경우 DIPD 이후)를 수정했습니다. 변경 사항은 DIPD S에서 요구하는 것과 동일한 수준으로 자세히 설명되어야 합니다.tage와 FIPD Stage.
CR이 변경을 제안하는 사양의 영향을 받는 각 섹션과 단락에 제안된 모든 변경 사항입니다.
마크업을 사용하여 표시된 모든 승인된 기술 정오표(정오표 번호로 참조되는 각 정오표 포함)는 이전에 채택된 사양 버전에 아직 통합되지 않았으며 사양 개선과 관련된 텍스트에 영향을 미칩니다. 또는 IOP 테스트에 영향을 미치는 경우.

4. 사양의 약식 CR에 포함될 수 있는 CSS CR(사양에서 새 항목이 필요한 경우).
5. 사양의 약식 CR에 포함될 수 있는 GSS CR(사양에서 새 항목이 필요한 경우).
6. 사양의 약식 CR에 포함될 수 있는 MDP CR(사양에서 새 항목이 필요한 경우).
7. [0.9]에 제공된 공식 템플릿을 사용하여 최소한 다음에 대한 정보를 포함해야 하는 8/CR 테스트 문서:

TSTO [0.9]에 설명된 대로 콘텐츠가 완전한 테스트 사례와 관련 TCMT(테스트 사례 매핑 테이블)를 포함하는 5/CR 테스트 스위트입니다.
TSTO [0.9]에 설명된 5/CR ICS.
테스트 구성에 IUT(Implementation Under Test)에 대한 특정 매개변수가 필요한 경우 0.9/CR IXIT(Implementation eXtra Information for Testing)가 필요합니다.

0.9/CR 테스트 사례 참조 목록(TCRL)(핵심 사양 업데이트의 경우 선택 사항).

8. 0.9/CR 테스트 스위트 내에서 어떤 사양 요구 사항이 테스트되거나 테스트되지 않았는지 나타내는 테스트 범위 분석(사양 향상을 위해 테스트 범위 분석에는 새로 추가되고 영향을 받는 기능만 포함되어야 하며 영향을 받지 않는 영역은 포함되지 않아야 함) 원래 사양).
9. IOP 테스트 계획.

사양 향상을 위해 테스트 스위트, ICS 및 IXIT가 별도의 문서로 제공되거나 약식 CR의 추가 섹션으로 제공될 수 있습니다.

대부분의 경우 통합 또는 약식 CR은 이전에 채택된 사양 버전을 기반으로 해야 하지만 최신 중간 초안을 기반으로 할 수도 있습니다. 최신 중간 초안 사양 버전 번호는 고정되어 시간이 지나도 변경되지 않는 문서 버전과 관련된 버전 번호여야 합니다. 그렇지 않은 경우 추가 식별 정보(예: 문서 날짜 및 URL 영구적인 위치로)는 특정 "기준" 버전을 식별하기 위해 제공되어야 합니다. 중간 초안을 사용하는 경우 CR이 수정하는 특정 섹션 내에서 CR과 직접 관련되지 않은 모든 변경 사항이 포함되어야 하지만 마크업을 사용하여 표시할 필요는 없습니다. 나중에 중간 초안의 관련 부분이 업데이트되는 경우 중간 초안에 대한 업데이트 내용을 반영하도록 CR을 업데이트해야 합니다.

이상적으로 축약된 CR 자료는 검증 단계 이전에 각각 전체 사양 초안과 전체 테스트 문서에 통합되지만 검증 단계 시작 시 통합될 수도 있습니다. 사양(예: 핵심 사양)에 대해 여러 기능이 개발되는 경우 IOP 테스트가 완료된 후 기능을 단일 초안으로 통합하는 것이 바람직할 수 있습니다.

BSTS는 다시view Bluetooth 제도 지침과의 일관성을 위한 0.9/CR 사양 및 테스트 문서. 그러면 BARB가 다시view 0.9/CR 사양에 이어 IOP 테스트 계획이 뒤따릅니다(섹션 4.3.1에 설명됨). 0.9/CR 사양이 WG에 의해 BARB에 다시 제출되면view, BSTS는 모든 회원이 다시 액세스할 수 있도록 합니다.view 그리고 모든 회원에게 그 가용성을 알립니다. 사양 개발 프로세스의 이 시점부터 BSTS는 BARB에 제출된 사양의 초안을 모든 회원에게 정기적으로 통지하여 모든 회원이 사용할 수 있도록 할 것입니다.

사양 향상을 위해 WG는 권장 사항에 대한 기술적 이유를 포함하여 이전 버전의 사양을 더 이상 사용하지 않거나 철회해야 하는지 여부를 이사회에 권장합니다.

BARB는 다시view 0.9/CR 사양의 FRD에 제공된 요구 사항 준수, 잠재적인 보안 문제, 규제 문제, Bluetooth 아키텍처와의 적합성 및 사양 향상을 위한 섹션 3.3.2에 설명된 이전 버전과의 호환성 요구 사항 준수에 대한 WG의 분석 .XNUMX. BARB가 잠재적인 보안 문제를 식별하는 경우 BARB는 다시 BSTS에 알립니다.view 보안 전문가 그룹과의 조정 BARB가 규제 관련 영향을 식별하는 경우 BARB는 BSTS에 다시 알릴 것입니다.view 규제위원회 및 Bluetooth SIG의 법률 고문과 협력합니다. BARB는 엔지니어링 판단과 이 단락에 설명된 요소를 고려하여 0.9/CR 사양을 승인하거나 거부해야 합니다.

BTI는 다시view 테스트 커버리지 분석을 고려한 0.9/CR 테스트 문서입니다. BTI는 0.9/CR 테스트 문서를 승인하거나 거부해야 합니다.

BARB가 0.9/CR 사양을 승인한 후 WG는 IOP 테스트 계획을 BARB에 다시 제출합니다.view.

BARB가 승인한 0.9/CR 사양은 이사회에 제출되어 IOP 테스트 시작과 모든 회원에게 0.9/CR 사양 게시를 승인합니다.

잠재적인 법적 문제를 강조하기 위해 WG는 다시 사양을 요청할 수 있습니다.view Bluetooth SIG의 법률 고문(법적view) 필수 법적 재검토 이전view 채택/승인 단계에서 발생합니다. 그러나 사양 향상을 위해 법적view 단축 CR이 아닌 통합 CR에서 수행해야 하며 리소스를 사용할 수 있도록 최대한 미리 예약해야 합니다.

IOP 테스트 계획

WG는 IOP 테스트 이벤트의 검증 단계 동안 사용하기 위해 아래에 정의된 모든 요구 사항을 충족해야 하는 서면 IOP 테스트 계획을 개발합니다. WG는 재검토를 위해 BARB에 IOP 테스트 계획을 제출해야 합니다.view IOP 테스트 이벤트가 시작되기 전. 간단한 사양 향상(특히 테스트 스위트의 테스트 케이스 수정 또는 추가가 필요하지 않은 경우)의 경우 IOP 테스트가 필요하지 않을 수 있으며 WG는 정의된 프로세스를 사용하여 IOP 테스트 면제 요청을 BARB에 제출할 수 있습니다. 섹션 4.4에서.

IOP 테스트 계획에는 다음이 포함되어야 합니다.

모든 새로운 필수, 선택 및 조건부 기능을 확인하는 테스트 사례
각 op 코드에 대해 하나 이상의 테스트 케이스
각 매개변수에 대해 하나 이상의 테스트 케이스
각 패킷 유형에 대해 하나 이상의 테스트 케이스
모든 향상된 기능에 대해 섹션 3.3.2에 나열된 요구 사항이 충족되도록 사양 향상을 위한 하위 호환성 테스트 사례입니다(섹션 4.3.1.1도 참조).

IUT가 정의된 범위를 벗어난 값이나 유효하지 않거나 예상치 못한 것으로 간주되는 동작 측면에 노출되는 테스트 사례(잘못된 동작 테스트 사례). PTS 또는 기타 테스트 도구와 같은 테스터가 잘못된 동작을 시작할 것으로 예상됩니다.
섹션 4.3.1.2에 설명된 대로 IOP 테스트 이벤트에서 사용되는 임시 할당 번호(향후 IOP 테스트 이벤트에서 중복을 피하기 위해 BSTS와 협력하여 선택됨).
섹션 4.3.1.3에 설명된 적용 범위 요구 사항을 고려하여 각 테스트 사례를 통과해야 하는 필요한 독립적 구현 수 식별

WG가 제외해야 한다고 생각하는 테스트 스위트의 테스트 사례 식별 및 제외에 대한 정당성. 여기에는 일반적으로 다음이 포함됩니다. • 미래 보장 테스트 사례(예: 추가 특성, 확장 특성 또는 미래 사용을 위해 예약된(RFU) 비트 또는 필드 사용과 같은 향후 가능한 추가 사항을 수용할 수 있도록 하는 공통 테스트)
• 포함된 다른 테스트의 하위 집합인 테스트 사례
• 여러 다른 사양에 대해 실행되는 테스트와 사실상 동일한 일반 테스트 사례(예: 일반적인 오류 코드 실행)
• 다른 전송을 통해 실행되는 테스트 케이스와 동일한 테스트 목적을 가진 테스트 케이스(예: LE 테스트 케이스와 유사한 BR/EDR 테스트 케이스)
• 구현의 견고성 또는 스트레스 테스트

IOP 테스트 계획에는 일반적인 사용자 시나리오와 유사할 수 있는 보다 복잡한 시퀀스를 함께 묶는 엔드투엔드 테스트 케이스와 같은 IOP 테스트에 고유한 테스트가 포함될 수도 있습니다.

IOP 테스트 계획에 대한 BARB 승인은 필요하지 않지만(IOP 테스트 계획은 각 IOP 테스트 이벤트로 계속 수정 및 개선된다는 점을 이해하여) IOP 테스트 보고서에 대한 BARB 승인이 필요합니다(섹션 5.1.1 참조). . IOP 테스트 계획이 섹션 4.3.1에 정의된 모든 요구 사항을 충족하지 않는 경우 WG는 IOP 테스트 이벤트가 시작되기 전에 알려진 차이에 대한 요약과 각 차이에 대한 이론적 근거를 BARB에 제시해야 합니다.

IOP 테스트 계획 및 테스트 케이스는 기본적으로 관련 사양의 테스트 문서 내의 내용을 기반으로 해야 합니다.

IOP 테스트 이벤트를 효율적으로 만들기 위해 WG는 IOP 테스트 계획 및 모든 관련 테스트 사례를 완료하고 이상적으로는 첫 번째 IOP 테스트 이벤트가 시작되기 최소 한 달 전에 구현자에게 제공되어야 합니다.

이전 버전과의 호환성 테스트 계획
사양 향상을 위해 이전 버전과의 호환성에 대한 IOP 테스트에서는 모든 활성 버전과 더 이상 사용되지 않는 사양 버전에 대한 검증을 고려해야 합니다. Bluetooth 제품에서 일반적으로 발견되는 사양 및 기능은 매우 긴 수명(예: 차량)을 가질 수 있기 때문입니다. WG는 테스트할 버전과 수행할 테스트를 포함하여 필요한 이전 버전과의 호환성 테스트(있는 경우)의 적절한 수준을 분석하고 이 분석을 BARB에 제공해야 합니다. BARB는 다시해야합니다view WG가 IOP 테스트 계획에 통합할 수 있도록 분석 및 권장 변경 사항(있는 경우).

이전 버전과의 호환성 테스트에 참여하는 회원은 이전 사양 버전에 대해 검증된 레거시 장치를 가져오는 것이 좋습니다. WG는 IOP 테스트 보고서에 이전 버전과의 호환성 실패를 보고해야 합니다. 또한 회원사들은 IOP 테스트 장소 이외의 자체 연구실에서 이전 버전과의 호환성 테스트를 수행하고 사양 관련 문제를 WG에 보고하도록 권장됩니다.

IOP 테스트에 사용되는 임시 할당 번호
다른 사양과 중복되거나 충돌하지 않도록 IOP 테스트 이벤트에서 사용될 할당 번호의 임시 할당을 조정하려면 BSTS 및 BARB와 협의해야 합니다. 이러한 임시 값은 IOP 테스트 계획에 포함되어야 하며 채택된 사양에서 사용하도록 할당되지 않습니다.

하나 이상의 새로운 16비트 UUID 값이 제안되는 IOP 테스트의 경우 0x7F00 ~ 0x7FFF 범위 내의 값은 IOP 테스트용으로 예약되어 있습니다.

하나 이상의 새로운 PSM(Fixed Protocol Service Multiplexer) 값이 제안되는 IOP 테스트의 경우 핵심 사양에 지정된 대로 0x0000~0x007F의 유효한 범위 끝에서 시작하는 값이 사용됩니다.

보장 요건
WG는 필요한 수(다음 섹션에 설명된 대로)의 독립적 구현이 각 테스트 케이스를 통과했다는 증거를 BARB에 제공해야 합니다. 필요한 독립적 구현 수에 대한 예외에 대한 WG 요청은 BARB에 제출되는 IOP 테스트 계획에 명시되어야 합니다.

검증과 관련된 모든 부분이 독립적으로, 즉 다른 팀(반드시 다른 회사에서 나올 필요는 없음)에 의해 개발된 경우 구현은 서로 독립적인 것으로 간주됩니다. BSTS는 구현 세부 사항의 익명성과 기밀성을 유지하기 위해 프로토타입이 서로 독립적인 것으로 간주될 수 있는지 여부를 평가하는 데 도움을 줄 수 있습니다.

PTS를 포함한 테스트 도구는 독립적인 구현으로 간주되지 않습니다.

핵심 사양 IOP 적용 범위 요구 사항
핵심 사양 기능은 일반적으로 각 역할이 하나 이상의 다른 역할 또는 가능하면 자체와 상호 운용되도록 설계된 하나 이상의 역할을 정의합니다.

서로 상호 운용되도록 설계된 각 역할 쌍에 대해 각 역할의 최소 3가지 독립적 구현이 보완 역할의 3가지 독립적 구현과 상호 운용된다는 것을 입증해야 합니다.

동일한 역할의 다른 장치와 상호 운용할 수 있는 각 역할에 대해 해당 역할에 대한 최소 3개의 독립적인 구현은 해당 역할에서 서로 상호 작용할 수 있음을 입증해야 합니다.

서비스 사양 IOP 적용 범위 요구 사항
최소 3개의 독립적인 서비스 구현은 PTS일 수 있는 최소 하나의 클라이언트 구현과 상호 운용된다는 것을 입증해야 합니다.

찬성file 및 프로토콜 사양 IOP 적용 범위 요구 사항
찬성file 프로토콜 사양은 일반적으로 각 역할이 하나 이상의 다른 역할 또는 자체적으로 상호 운용되도록 설계된 하나 이상의 역할을 정의합니다.

서로 상호 운용되도록 설계된 각 역할 쌍에 대해 각 역할에 대한 최소한 두 개의 독립적인 구현은 보완적인 역할의 두 개의 독립적인 구현과 상호 운용된다는 것을 입증해야 합니다.

동일한 역할의 다른 장치와 상호 운용할 수 있는 각 역할에 대해 해당 역할에 대한 최소 3개의 독립적인 구현은 해당 역할에서 서로 상호 작용한다는 것을 입증해야 합니다.

모델 사양 IOP 적용 범위 요구 사항
최소한 3개의 독립적인 서버 모델 또는 제어 모델 구현은 최소한 하나의 클라이언트 구현(PTS일 수 있음)과 상호 운용된다는 것을 입증해야 하며, 최소한 하나의 클라이언트 모델 구현은 최소한 하나의 서버 모델 구현 및 PTS와 상호 운용된다는 것을 입증해야 합니다.

사양 버전 번호 지정

0.9/CR S 기간 동안tage, WG는 채택 시 사양에 적용될 버전 번호와 관련하여 이사회에 제시할 권장 사항을 준비해야 합니다.

사양 버전은 새 기능이나 업데이트된 기능을 포함하는 전체 릴리스 버전과 기술 및 편집 정오표를 통합하지만 새 기능이나 업데이트된 기능을 포함하지 않는 유지 관리 릴리스 버전("dot-Z 버전"이라고도 함)의 두 가지 유형으로 분류됩니다. 특징. 전체 릴리스 버전에는 2.1 또는 5.0과 같이 XY 형식의 두 부분 번호가 있는 반면, 유지 관리 릴리스 버전에는 2.1.2와 같은 XYZ 형식의 세 부분 번호가 있습니다. Z 값은 0이 될 수 없습니다.

두 버전 중 하나는 "상위 버전", 다른 하나는 "하위 버전"이라고 합니다. 이는 다음 규칙에 따라 결정됩니다.

X 구성 요소가 다른 경우 X 값이 더 높은 것이 "상위 버전"입니다.
X 구성 요소는 동일하지만 Y 구성 요소가 다른 경우 Y 값이 더 높은 것이 "상위 버전"입니다.
XY 구성 요소는 동일하지만 Z 구성 요소가 다른 경우 Z 값이 더 높은 것이 "상위 버전"입니다. 이 목적을 위해 두 부분으로 구성된 숫자 XY는 세 부분으로 구성된 숫자 XY0으로 처리됩니다.

예를 들어amp파일에서 버전 번호는 가장 낮은 버전에서 가장 높은 버전 순서대로 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2입니다. CSS의 경우 업데이트할 때마다 버전 번호의 X 구성 요소만 증가합니다.

이사회 승인 전제조건
사양 개발 단계가 끝나면 승인을 위해 0.9/CR 사양을 BoD에 제출하기 전에 다음 요구 사항을 충족해야 합니다.

WG는 테스트 범위 분석을 완료했습니다.
BSTS가 다시 완료되었습니다.view0.9/CR 사양 및 테스트 문서를 참조하세요.
BARB는 0.9/CR 사양을 승인했습니다.
BARB는 사양의 약식 CR에 포함될 수 있는 CSS CR(사양에서 새 항목이 필요한 경우)을 승인했습니다.
BARB는 GSS CR 및 MDP CR을 승인했습니다(사양에 따라 새 항목이 필요한 경우).
BTI는 IXIT와 함께 0.9/CR 테스트 스위트, ICS 및 TCRL을 승인했습니다(테스트 스위트에서 테스트를 수행하려면 IXIT가 필요한 경우). TCRL은 현재 선택 사항입니다.tage 핵심 사양에 대한 업데이트입니다.
WG는 재검토를 위해 BARB에 IOP 테스트 계획을 제출했습니다.view (BARB가 테스트를 면제하지 않은 경우)

이사회에 제출되는 문서에는 BARB 승인 0.9/CR 사양이 포함되어야 하며, 이사회에 제출되는 프레젠테이션에는 다음이 포함되어야 합니다.

IOP 테스트 또는 섹션 4.3.1에 정의된 요구 사항을 면제해 달라는 알려진 요청
사양이 지원하는 전송 목록(예: BR/EDR, LE 등)
사양 향상을 위해 WG가 요청하는 이전 버전과의 호환성 요구 사항(섹션 3.3.2에 설명됨)에서 면제됩니다.
사양 개선을 위해 채택된 사양에 적용할 버전 번호에 대한 WG의 권장 사항
사양 향상의 경우, 이전 버전 사양의 폐기 또는 철회가 권장되거나 권장되지 않는 기술적인 이유와 정당성을 포함하여 채택된 사양의 이전 버전에 대한 WG의 수명 종료 권장 사항 추천을 위해
BARB 또는 BTI 회원의 해결되지 않은 심각한 우려 사항(예: 승인 중 투표 불가 이유, 재계약으로 인한 우려 사항)view 테스트 문서 또는 0.9/CR 사양이 FRD 또는 헌장 범위를 벗어난다는 우려)
Pro 준비 상황file BSTS에서 준비한 Tuning Suite(PTS) 또는 채택과 관련된 기타 필수 도구

BoD는 BTI가 0.9/CR 테스트 문서를 승인하기 전, 그리고 WG가 IOP 테스트 계획이 섹션 2에 정의된 요구 사항을 충족하는지 확인하기 전에 조례[0.9]에서 요구하는 대로 IOP 테스트를 위한 4.3.1/CR 사양을 승인하도록 선택할 수 있습니다. 0.9. 또한 이사회는 BTI의 0.9/CR 테스트 문서 승인에 따라 IOP 테스트를 위한 XNUMX/CR 사양 승인을 조건으로 할 수도 있습니다.

0.9/CRStage 종료 요건
0.9/CR Stage가 완료되고 BoD가 IOP 테스트 시작을 승인하면 검증 단계가 시작됩니다.

4.4 사양 개발 프로세스 면제

WG는 다음 프로세스 단계 중 하나 이상을 면제하도록 요청할 수 있습니다.

0.5/DIPD Stage
0.7/FIPD Stage
검증 단계 내 IOP 테스트

면제를 요청하려면 WG는 Bluetooth SIG[8]에서 제공하는 프로세스 면제 템플릿을 사용해야 하며 재승인이 필요한 각 위원회(예: BARB 또는 BTI)에 면제 요청을 제출해야 합니다.view 또는 초안 사양이나 관련 테스트 문서를 즉시 승인합니다.tage WG가 면제를 제안하고 각 위원회가 면제 요청을 승인해야 합니다.

면제 요청에는 다음이 포함되어야 합니다.

s의 신분증tagWG가 포기하고 싶어하는 e(들)
왜 s인지에 대한 정당화tage(s)는 포기되어야 합니다
재작업이 필요한 각 위원회(즉, BTI 및/또는 BARB)의 식별view 그리고 면제 요청을 승인하세요

면제를 고려하는 위원회는 면제 요청을 결정하기 전에 WG 대표가 SMPD 절차 면제를 정당화하는 프레젠테이션을 하도록 요구할 수 있습니다.

면제가 여러 단계의 면제를 요청하고 면제의 일부가 거부되고 일부가 승인된 경우, 위원회의 응답에는 면제 요청의 어느 단계가 승인되었고 어느 단계가 거부되었는지 명시해야 합니다. 면제 요청이 거부된 경우, 거부 통지에는 거부 사유가 포함되어야 합니다.

5. 검증 단계

검증 단계 동안 WG는 BARB re에 대한 IOP 테스트 보고서를 제공할 목적으로 0.9/CR 사양에 대한 IOP 테스트를 수행합니다.view 그리고 승인. 가능할 때마다 통합 초안 사양에 대해 사양 개선에 대한 IOP 테스트를 수행해야 합니다. 또한 회원 Re는view조례[2]에서 요구하는 대로 이 단계에서 시작됩니다.

사양(또는 개선 사항)에 IOP 테스트가 필요하지 않은 경우 섹션 4.4에 설명된 프로세스를 사용하여 검증 단계 내의 IOP 테스트가 면제될 수 있습니다.

IOP 테스트(하나 이상의 이벤트일 수 있음) 과정 전반에 걸쳐 WG는 Bluetooth SIG의 문제 추적 시스템을 사용하여 문제를 추적하고 초안 사양, 테스트 문서 및 IOP 테스트 계획에 대한 업데이트를 통합하기 위해 반복해야 합니다. IOP 테스트가 끝나면 WG는 모든 문제를 해결하기 위해 초안 사양 및 테스트 문서에 대한 업데이트를 완료하고 IOP 테스트 보고서를 준비하여 BARB에 제출해야 합니다.view 그리고 승인. 이는 그림 5.1에 설명되어 있습니다.

검증 단계 중에는 시작될 수 있는 여러 활동이 있습니다. 이러한 활동은 동시에 발생할 수 있으며 다음을 포함합니다.

이사회 승인 0.9/CR 사양은 Member Re 시작 알림과 함께 BSTS를 통해 모든 회원에게 제공됩니다.view 정관에서 요구하는 기간.
필요한 모든 업데이트는 CSS(사양의 약식 CR에 포함될 수 있음)에 통합됩니다.
특성 또는 설명자 정의는 IOP 테스트를 위한 PTS뿐만 아니라 GSS 사양에도 통합되어 있습니다.
메쉬 속성 정의는 IOP 테스트를 위한 PTS뿐만 아니라 MDP 사양에도 통합되어 있습니다.
BSTS는 IOP 테스트를 준비하기 위해 IOP 플랫폼 등록 및 결과 입력 도구를 활성화합니다.
필요한 경우 IOP 테스트(섹션 5.1 참조).
Review IOP 테스트 결과로 제출된 의견과 문제를 포함한 의견과 문제가 처리되고 변경 사항이 초안 사양에 통합됩니다.

5.1 IOP 테스트

IOP 테스트의 주요 목적은 예를 들어 사양을 검증하는 것입니다.ample, 텍스트 내의 정확성과 모호성을 확인하고, 다시view기본적인 설계 오류 및 누락을 확인하고 사양 개발 프로세스 초기에 개발된 이전에 확립된 요구 사항에 대한 검증을 제공합니다. IOP 테스트로 인해 초안 사양이 변경될 수 있으며 필요한 모든 테스트를 완료하려면 여러 IOP 테스트 이벤트가 필요할 수 있습니다.

WG 외부 구성원에게 IOP 테스트에 참여할 수 있는 기회를 제공하는 것이 중요합니다. view 초안을 개발한 WG 구성원에게 명확하지 않을 수 있는 사양의 모호한 영역을 밝힐 수 있습니다. 각 IOP 테스트 이벤트 전에 BSTS는 이벤트 세부 정보, 최신 초안 사양, 테스트 스위트 및 IOP 테스트 계획을 제공하고 이상적으로는 각 이벤트 한 달 전에 모든 회원에게 알립니다. IOP 테스트 이벤트에 사용되는 업데이트된 초안 사양, 테스트 스위트 및 IOP 테스트 계획은 각 이벤트가 시작되기 최소 1주일 전에 제공되어야 합니다.

IOP 테스트 중에 플랫폼의 쌍별 조합은 테스트 실행을 시도하고 IOP 테스트 참가자는 각 테스트의 통과/실패 결과와 의견을 기록합니다. 이러한 결과에 대한 익명화된 요약(예: "플랫폼 A", "플랫폼 B" 등 참조) 및 의견은 IOP 테스트 이벤트 중에 수집되며 IOP 도중 및 이후에 WG 구성원에게 제공됩니다. 테스트 이벤트. IOP 테스트 중에 발생한 의견이나 실패를 더 잘 이해하기 위해 추가 정보가 필요한 경우 BSTS는 제출 회원으로부터 추가 정보를 수집하기 위한 중개자 역할을 할 수 있습니다.

가능하다면 PTS는 HCI(호스트 컨트롤러 인터페이스) 위의 모든 계층에서 플랫폼을 사용한 IOP 테스트를 지원하고 해당 계층에 대한 IOP 테스트 이벤트에 나타나도록 업데이트되어야 합니다. IOP 테스트 이벤트에는 다른 테스트 도구도 있을 수 있습니다. PTS 또는 기타 테스트 도구(있는 경우)를 사용한 테스트 결과 요약이 IOP 테스트 보고서에 포함되어야 합니다.

IOP 테스트는 프로토타입 구현을 제공하려는 모든 회원에게 공개되지만 Bluetooth SIG는 Bluetooth SIG와의 계약(참여 및 기밀 유지 계약 포함) 수락에 따라 참여를 조건으로 할 수 있습니다. WG는 IOP 테스트 중에 발견된 문제를 처리 및 해결하고 영향을 받은 문서를 업데이트하는 일을 담당합니다. WG가 승인한 변경 사항은 각 IOP 테스트 이벤트에서 사용할 초안 사양 및 테스트 문서에 대한 업데이트로 통합되어야 합니다.

검증 단계 이전에 WG는 WG 회원에게만 공개되는 이벤트에서 예비 IOP 테스트를 수행할 수 있지만, 비공식 테스트 결과는 IOP 테스트 결과에 포함되지 않을 수 있습니다.

IOP 테스트를 시작할 의도로 발표된 IOP 날짜 및 장소를 포함하여 첫 번째 IOP 테스트 이벤트에 이르는 모든 단계를 따르지만 테스트 이벤트 시작 전에 이사회 승인을 확보하지 못한 경우가 발생할 수 있습니다. 이 경우, 이사회는 IOP 테스트 시작을 승인하기 전에 수집된 테스트 결과를 포함하는 것을 승인할 수 있습니다. 단, 수집된 결과는 이사회가 승인한 동일한 사양 및 테스트 스위트를 기반으로 합니다.

CSS, GSS 또는 MDP 사양을 개선하는 데에는 IOP 테스트가 필요하지 않습니다.

IOP 테스트 보고서
IOP 테스트가 완료된 후 WG는 필요한 수의 독립 플랫폼이 필수 테스트를 통과했음을 입증할 목적으로 IOP 테스트 보고서를 BARB에 제출해야 합니다. BARB는 다시해야합니다view IOP 테스트 보고서를 승인하거나 거부하고 투표 초안 사양 패키지를 이사회에 제출하기 전에 추가 IOP 테스트가 필요한 경우 WG에 알립니다. BSTS와 WG는 보고서를 BARB에 제출하기 전에 IOP 테스트 보고서에 회원 식별 정보가 나타나지 않도록 해야 합니다.

IOP 테스트 보고서에는 다음이 포함되어야 합니다.

날짜 및 위치를 포함하여 검증 단계 동안 발생한 모든 IOP 테스트 이벤트 목록입니다.
PTS 사용 여부를 포함하여 각 IOP 행사에 참여한 회원사 및 독립 플랫폼의 수입니다.
각 이벤트에 사용된 사양, 테스트 스위트 및 IOP 테스트 계획 버전 목록입니다.
모든 테스트 사례가 최소 통과 기준을 충족하는지 여부를 설명하는 요약입니다.
섹션 4.3.1에 정의된 IOP 테스트 계획 요구 사항의 모든 차이에 대한 요약과 각 차이에 대한 근거.
테스트 스위트의 테스트 케이스에 대한 PTS 적용 범위 요약입니다.
IOP 테스트 계획의 모든 테스트 케이스(역호환성 테스트 포함) 목록, 테스트 통과 횟수, 테스트 실패 횟수, 요구 사항이 충족되지 않은 이유에 대한 설명을 포함하여 테스트 케이스당 최소 기준 충족 여부 만났다.
각 이벤트의 문제, 의견, 질문 요약(해당 항목 포함) filed IOP 테스트 중 사양에 대한 비교) 및 사양과 테스트 문서에 대한 영향.

5.2 검증 단계 종료 요구 사항

BARB가 IOP 테스트 보고서를 승인하고(BARB가 테스트를 면제하지 않은 경우) 다음 요구 사항이 모두 충족되면 검증 단계가 완료되고 승인/채택 단계가 시작됩니다.

BSTS는 Member Re의 모든 회원이 사용할 수 있도록 승인된 0.9/CR 사양을 만들었습니다.view 조례에서 요구하는 대로 모든 회원에게 그 가용성을 알렸습니다.
IOP 테스트 중에 식별되고 테스트에 영향을 미치는 모든 문제가 통합되어 테스트되었습니다.
WG는 IOP 테스트를 완료했습니다(BARB에서 테스트를 면제하지 않은 경우).

6. 채택/승인 단계

채택/승인 단계에서는 사양 및 관련 테스트 문서가 확정되고 BARB, BQRB 및 BTI 승인이 수신되고 제안된 채택 날짜에 대한 통지가 채택을 위해 이사회에 제출된 사양 초안의 최종 버전과 함께 발행됩니다( 투표 초안), 최종 사양 패키지가 이사회에 제출됩니다. Member Re의 최소 기간 이후view 내규 [2])에서 요구하는 사항이 충족되면 이사회는 채택일에 채택 사양을 고려할 것입니다. 채택 후 사양이 게시되고 자격 시스템이 활성화됩니다. 채택/승인 단계는 그림 6.1에 설명되어 있습니다.

6.1 투표 초안

투표 초안은 업데이트(검증 단계에서 제공)를 필수 사양 문서에 통합하고 새 사양의 최종 초안을 준비하여 생성됩니다. 사양 향상을 위해 BSTS는 검증 단계 이전에 아직 완료되지 않은 경우 하나 이상의 CR을 이전에 채택된 사양의 상위 버전(섹션 4.3.2 참조)에 통합하여 통합 사양을 생성합니다.

이 단계에서 사양이 변경되고 WG, BARB 또는 BTI가 변경 사항에 추가 IOP 테스트가 필요하다고 결정하면 사양은 WG가 추가 테스트를 수행할 수 있도록 검증 단계의 IOP 테스트 부분으로 돌아갑니다. 채택/승인 단계 동안 다음 문서가 완료되어 채택 날짜 이전에 이사회에 제공됩니다.

투표 초안
이전에 채택되지 않은 경우 관련 사양(또는 향상) 유형에 필요한 모든 지원 사양(예: CSS, GSS, MDP)
사양 개선을 위해 투표 초안에서 제안된 변경 사항을 보여주는 채택된 사양 버전의 변경 추적 버전
충족되지 않은 이전 버전과의 호환성 요구 사항(섹션 3.3.2에 설명된 대로)에 대한 WG의 설명 및 면제에 대한 정당성
충족되지 않은 IOP 테스트 계획 요구 사항(섹션 4.3.1에 설명됨)에 대한 WG의 설명 및 IOP 테스트 보고서와 함께 편차에 대한 정당성( 블루투스 SIG web대지)
0.9/CR S 이후 변경 사항을 강조하는 정당화와 함께 채택된 사양의 이전 버전을 더 이상 사용하지 않거나 철회하기 위한 WG의 권장 사항tage 임종 권고
0.9/CR 사양 이후 특징이나 기능에 대한 변경 사항을 WG에서 준비한 요약(있는 경우)
WG가 작성한 사양이 이사회가 승인한 헌장(있는 경우)의 범위를 벗어났다는 BARB 회원들이 제기한 우려 사항을 BARB가 준비한 요약
법적 재검토에서 아직 해결되지 않은 법적 문제 목록view (만약 있다면)
투표 초안 사양의 테스트 범위에 대한 WG 승인 요약과 함께 BTI 승인 테스트 모음입니다. 테스트 대상이 아닌 기능이 새로 추가되거나 수정되는 경우 누락에 대한 서면 근거가 필요합니다.
BTI 승인 ICS 및 IXIT(사양에서 요구하는 경우)
BTI와 BQRB 모두에서 승인한 TCRL
TCRL의 테스트 사례가 테스트 도구에서 지원되지 않는지 여부를 포함하여 도구 준비 상태(예: PTS 및 기타 테스트 도구, Bluetooth Launch Studio)에 관해 BTI와 함께 BSTS가 준비한 보고서입니다.
필요한 모든 할당 번호에 대해 WG에서 준비한 요약
BSTS와 WG가 준비한 채택 체크리스트는 이 섹션의 모든 결과물이 모두 완료되었음을 보여줍니다.
기타 이사회가 요청하는 모든 정보

채택/승인 단계에서 WG는 Bluetooth SIG의 문제 추적 시스템을 사용하여 초안 사양 및 테스트 문서에 대한 문제와 의견을 캡처하여 투표 초안 사양의 최종 결정에서 이를 설명해야 합니다. 사양 개선을 위해서는 승인된 모든 관련 정오표(즉, 아직 통합되지 않은 승인된 정오표)를 통합해야 하며 추적된 변경 사항을 사용하여 식별해야 합니다.

WG는 법적 재심을 위해 최종 사양 초안을 BSTS에 제출해야 합니다.view. 새로운 사양에 대해서는 법적view 전체 사양이 포함됩니다. 사양 향상을 위해view 주로 사양의 변경된 부분에 중점을 둘 것입니다. 법적 재검토의 목적view 이는 주로 WG가 고려하고 해결하려고 노력해야 하는 법적 위험을 식별하는 것입니다. 법적 피드백은 심각도에 따라 분류됩니다. 선택적 법적 재계약인 경우view 0.9/CR S에서 수행되었습니다.tage, 법적 재신청을 위해 제출된 버전view 해당 버전 이후에 발생한 모든 변경 사항(WG 또는 BSTS에 의해 생성됨)을 추적된 변경 사항으로 표시해야 합니다. 법적 재심사가 완료되면view, WG와 BSTS는 피드백이 초안 사양에 통합되는 데 동의합니다. 법무팀에서 아직 해결되지 않은 법적 의견이 있는 경우view 초안 사양에 대해 WG 의장은 이사회 안건에 대한 결의안에 동의할 시간을 요청할 수 있습니다.

법적 재검토와 병행하여view, WG는 재검토를 위해 사양 초안을 BARB에 제출해야 합니다.view. BARB에 처음 제출하면 BSTS는 모든 회원에게 사양 초안이 BARB에 다시 제출되었음을 알립니다.view Member Re에서도 사용 가능합니다.view. WG가 BARB re-re에 대한 초안 사양에 대한 업데이트를 제출하는 경우view, BSTS는 정기적으로 모든 회원에게 추가 공지를 보내드립니다.

BARB re가 완료되면view, WG와 BARB는 초안 사양에 포함되는 피드백에 동의할 것입니다.

법적으로 다시view 실질적인 변경이 발생하면 추가 재검토가 필요합니다.view BARB가 필요할 수 있습니다. 마찬가지로, BARB가 다시view 실질적인 변경이 발생하면 BSTS는 추가적인 법적 조치가 있는지 결정합니다.view 이러한 변경 사항이 필요합니다. 법적 재심사가 완료되면view 그리고 BARB 다시view, BARB는 투표 초안을 승인하거나 거부해야 합니다.

테스트 문서 업데이트가 필요한 경우 BSTS는 WG가 테스트 문서를 업데이트하도록 지원합니다. BTI는 테스트 문서를 승인하거나 거부해야 합니다. BTI의 승인을 받은 경우 BTI는 TCRL을 마무리하는 데 도움을 주고 이 문서를 관련 ICS, IXIT 및 테스트 스위트와 함께 BQRB에 전달합니다. BSTS는 이사회가 투표 초안(채택 날짜) 채택에 대해 투표하려고 할 때 이사회 회의 날짜를 추정하고 TCRL에 사용할 BTI를 제공합니다. 사양에 대한 BARB 승인, 모든 테스트 문서(테스트 스위트, TCRL, ICS 및 IXIT 포함)에 대한 BTI 승인, TCRL에 대한 BQRB 승인은 채택 날짜 또는 그 이전에 이루어져야 합니다.

BSTS는 투표 초안의 최종 확정 및 가용성과 채택 날짜를 모든 회원에게 알립니다. 채택 날짜는 회원이 이사회 승인을 받은 60/CR 사양을 통지받은 후 0.9일 이내에 설정됩니다.view 정관에 따라 이사회에서 기간을 단축하고, 정관에 따라 채택일을 공지한 후 최소 14일 이내에 회원에게 제공합니다. 여러 CR이 투표 초안에 통합된 경우 Member Re가 시작됩니다.view 이사회가 승인한 가장 최근 CR이 회원에게 통보된 날짜입니다.

회원들에게 채택 날짜를 공지한 후 이사회가 승인한 투표 초안의 인쇄상의 오류에 대한 수정이 허용됩니다. 사양 채택 일정은 그림 6.2에 나와 있습니다.

6.2 할당된 번호

Bluetooth SIG는 Bluetooth SIG 할당 번호에 공개적으로 사용 가능한 할당 번호 세트를 유지합니다. web사이트 [7]. 이렇게 할당된 숫자는 다양한 숫자 공간(중복되지 않은 관련 숫자 집합)으로 그룹화됩니다. 할당된 번호는 서로 다른 번호 공간에서 다른 할당 번호와 중복될 수 있지만, 번호 공간 내의 번호는 재사용이 허용되지 않습니다. 다양한 숫자 공간은 할당된 숫자의 사용법을 정의하는 사양에 정의되어 있습니다.

BARB가 IOP 테스트 보고서를 승인한 후 WG는 최종 사양에서 요구하는 숫자 공간 내에서 새로운 숫자 할당을 위해 BARB에 요청을 제출합니다. BARB는 다시view 요청을 받고 BSTS와 협력하여 할당된 번호를 결정합니다. BARB 승인 후 BSTS는 할당된 번호를 Bluetooth SIG 할당 번호에 공개적으로 게시하도록 일정을 잡습니다. web사양 채택 후 일주일 이내에 사이트 [7].

Bluetooth SIG 할당 번호에 할당 번호가 게시되면 web사이트 또는 채택된 사양 내에서 발생하는 경우 할당된 번호는 변경할 수 없습니다(값이나 의미가 변경되지 않음). 어떤 이유로 인해 사용할 수 없게 되면 예약된 값이 되어 재사용이 허용되지 않습니다.

6.3 채택/승인 단계 종료 요구 사항

승인/채택 단계는 BoD가 사양을 채택하고 다음과 같은 채택 후 활동이 완료되면 완료됩니다.

BSTS는 Bluetooth SIG에서 최종 할당 번호를 공개적으로 공개했습니다. web대지.
BSTS는 Bluetooth SIG에서 채택된 사양을 공개적으로 공개했습니다. web대지
BSTS는 관련 사양에 필요한 모든 지원 문서(예: CSS, GSS, MDP)를 Bluetooth SIG에 공개했습니다. web대지.
BSTS는 Bluetooth SIG의 모든 회원이 사용할 수 있도록 관련 테스트 문서를 만들었습니다. web대지.
사양 개선을 위해 BSTS는 새로 채택된 버전의 모든 변경 사항을 포함하여 이전에 채택된 사양 버전의 유익한 변경 추적 버전을 만들고 Bluetooth SIG의 모든 회원이 사용할 수 있도록 했습니다. web대지.
BSTS는 자격 시스템을 활성화했습니다.
BSTS는 채택된 사양과 모든 지원 문서의 가용성을 모든 회원에게 알렸습니다.

Bluetooth SIG는 사양 채택 후 1주일 이내에 이러한 채택 후 활동을 완료할 계획입니다.

7. 사양 유지 단계

사양 유지 단계는 채택/승인 단계가 완료된 후 시작됩니다. 사양 또는 관련 테스트 문서에서 문제(예: 모호한 표현 또는 기술적 오류)가 발견되면 Bluetooth SIG Errata 도구를 사용하여 정오표 제안을 생성하여 문서화해야 합니다. 사양 정오표 제안은 EPD [3]에 따라 처리, 분류 및 승인됩니다. 테스트 스위트 정오표는 TSTO [5]에 따라 처리되고 분류됩니다. SMPD와 EPD 또는 TSTO 사이에 충돌이 있는 경우 SMPD가 우선합니다.

사양 정오표는 최종 채택된 Bluetooth 사양의 기술 또는 편집 오류를 수정하는 데에만 사용해야 합니다. 기능의 추가, 변경 및 제거는 이 문서의 앞부분에 정의된 사양 향상 프로세스를 통해서만 이루어질 수 있습니다.

7.1 신속한 정오표 처리

EPD[3]에 정의된 프로세스에 따라 정오표가 승인되면 WG, BARB 또는 BSTS는 긴급하다고 간주되어 신속히 처리되어야 한다고 권고할 수 있습니다. 이런 일이 발생하면 BSTS는 WG 또는 BARB와 함께 이사회에 권장 사항을 제시합니다. 이사회는 권고안을 수락할지 거부할지 결정합니다. 권장 사항이 수락되면 BSTS는 승인된 정오표를 즉시 정오표 템플릿[8]에 통합하고 담당 WG와 협력하여 재작업을 위해 WG에 제출할 긴급 정오표 수정을 마무리합니다.view 그리고 승인.

오버view 신속한 정오표 처리 과정은 그림 7.1에 나와 있습니다.

채택일 이전에 다음 문서를 작성하여 이사회에 제공해야 합니다.

BARB가 승인한 긴급 정오표 수정 초안.
충족되지 않은 이전 버전과의 호환성 요구 사항(섹션 3.3.2에 설명된 대로)에 대한 WG의 설명과 면제에 대한 정당성.
법적 재검토에서 아직 해결되지 않은 법적 문제 목록view (있는 경우).
BTI 승인 테스트 스위트, ICS 및 IXIT(정오표에서 요구하는 경우).
BTI 및 BQRB 승인 TCRL(정오표에서 요구하는 경우)
TCRL의 테스트 케이스가 테스트 도구에서 지원되지 않는지 여부를 포함하여 도구 준비 상태(예: PTS 및 기타 테스트 도구, Bluetooth Launch Studio)에 관해 BTI와 함께 BSTS가 작성한 보고서(정오표에서 요구하는 경우) ).
BSTS와 WG가 작성한 채택 체크리스트는 이 섹션의 결과물이 모두 완료되었음을 보여줍니다.
이사회가 요청한 기타 모든 정보.

BSTS는 담당 WG와 협력하여 신속 정오표 수정 초안을 마무리하고 재작업을 위해 담당 WG에 제출할 버전을 생성합니다.view 그리고 승인.

WG는 법적 재심을 위해 신속 정오표 정정을 BSTS에 제출해야 합니다.view. 법적 재심사가 완료되면view, WG와 BSTS는 신속 정오표 수정에 피드백을 포함시키는 데 동의합니다. 법무팀에서 아직 해결되지 않은 법적 의견이 있는 경우view 신속한 정오표 수정에 대해 WG 의장은 이사회 안건에 대한 시간을 요청하여 결의안을 위한 이사회 의견을 구할 수 있습니다.

법적 재검토와 병행하여view, WG는 재빠른 정오표 수정을 BARB에 제출해야 합니다.view. 긴급 에라타 정정이 BARB에 제출되면 BSTS는 모든 회원이 다시 액세스할 수 있도록 합니다.view 그리고 모든 회원에게 그 가용성을 알립니다. BARB re가 완료되면view, WG와 BARB는 신속 정오표 수정에 피드백을 통합하는 데 동의합니다.

법적으로 다시view 실질적인 변경이 발생하면 추가 재검토가 필요합니다.view BARB가 필요할 수 있습니다. 마찬가지로, BARB가 다시view 실질적인 변경이 발생하면 BSTS는 추가적인 법적 조치가 있는지 결정합니다.view 이러한 변경 사항이 필요합니다. 법적 재심사가 완료되면view 그리고 BARB 다시view, BARB는 긴급 정오표 수정을 승인하거나 거부해야 합니다.

테스트 문서 업데이트가 필요한 경우 BSTS는 WG가 테스트 문서를 업데이트하도록 지원합니다. BTI가 테스트 문서를 승인하면 BTI는 TCRL을 마무리하는 데 도움을 주고 해당 문서를 관련 ICS, IXIT 및 테스트 스위트와 함께 BQRB에 전달합니다. BSTS는 채택 날짜를 추정하고 TCRL에 사용할 수 있도록 BTI에 제공합니다. 신속 정오표 수정에 대한 BARB 승인, 모든 테스트 문서(해당하는 경우 테스트 스위트, TCRL, ICS 및 IXIT 포함)에 대한 BTI 승인, TCRL에 대한 BQRB 승인은 채택 날짜 또는 그 이전에 이루어져야 합니다.

BSTS는 긴급 에라타 정정의 최종화 및 가용성과 제안된 채택 날짜를 모든 회원에게 알릴 것입니다. 채택일자는 내규[2]에 따라 모든 회원에게 정하여 공지하며, 채택일은 회원에게 공지한 날로부터 최소 14일 이후로 한다. 제안된 채택 날짜에 대한 통지가 회원들에게 제공된 후, 이사회는 제안된 채택 날짜에 대한 추가 통지를 제공하지 않고 필요한 14일을 기다리지 않고 신속 정오표 수정의 철자 오류 수정을 승인할 수 있습니다.

Bluetooth SIG는 채택된 긴급 정오표 수정을 공개적으로 공개할 예정이며 채택 후 1주일 이내에 그렇게 할 계획입니다. 이용 가능 여부는 BSTS에서 모든 회원에게 공지합니다.

신속 정오표 프로세스는 이사회가 신속 정오표 수정을 채택하고 다음 채택 후 활동이 완료되면 완료됩니다.

BSTS는 채택된 긴급 정오표 수정 및 관련 테스트 문서(정오표에서 요구하는 경우)를 Bluetooth SIG에 공개적으로 공개했습니다. web대지.
BSTS는 자격 시스템을 활성화했습니다(정오표에서 요구하는 경우).
BSTS는 신속 정오표 수정이 채택되었음을 모든 회원에게 알렸습니다.

이러한 활동이 완료되면 정오표 수정은 섹션 7.2에 설명된 대로 계획된 사양 개선의 일부로 또는 향후 유지 관리 릴리스의 일부로 영향을 받는 사양에 통합되도록 일정이 잡힙니다.

7.2 유지보수 릴리스 프로세스(.Z 사양)

대략 매년 BSTS는 기술/높음 또는 기술/중요로 분류되고 아직 활성 사양의 텍스트에 포함되지 않은 승인된 정오표(정오표 정정이라고 함)가 있는지 여부를 결정합니다(예: 더 이상 사용되지 않거나 철회되지 않은 채택된 사양) 정오표 분류 정의는 부록 A를 참조하십시오. 사양 소유자(사양을 유지하기 위해 인가받은 WG 또는 사양을 유지하기 위해 인가받은 WG가 없는 경우 BARB)는 승인된 정오표를 통합하기 위해 활성 사양의 조기 유지 관리 릴리스를 요청할 수도 있습니다. BSTS 결정 또는 사양 소유자의 요청에 따라 유지 관리 릴리스 프로세스가 시작됩니다.

오버view 유지 관리 릴리스 프로세스는 오류!에 설명되어 있습니다. 참조 소스를 찾을 수 없습니다.

유지 관리 릴리스 프로세스가 시작될 때 BSTS는 사양 소유자, BARB 및 BTI와 함께 정오표 수정 사항을 게시된 사양 버전에 통합하기 위한 계획을 개발하고 이사회에 제시합니다. 제안된 계획에는 정오표 수정이 사양의 유지 관리 릴리스(예: .Z 버전)에 통합될 것인지, 아니면 이미 진행 중인 사양 향상(예: XY 버전)에 통합될 것인지 명시해야 합니다. 제안된 계획에서는 채택된 사양 버전 간에 새로운 필수 기능이 추가되었는지 여부, 다음 사양 개선이 채택되도록 계획된 예상 시간 및 기타 요소를 고려해야 합니다.

이사회의 계획 승인에 따라 BSTS는 사양 소유자와 함께 모든 기술/중간, 기술/높음 및 기술/중요한 정오표 수정 사항을 "유지 관리 릴리스 초안"이라고 하는 초안 사양에 통합하는 작업을 진행합니다. 편집 또는 기술/낮은 정오표 정정의 경우 정오표 정정이 두 개 이상의 사양 버전에 적용되는 경우 BoD가 달리 명시하지 않는 한 BSTS는 해당 버전의 다음 업데이트 시 해당 정오표를 가장 최근의 상위 사양 버전에만 통합합니다. . 정오표 수정 사항을 통합하는 것 외에는 유지 관리 릴리스 초안에 어떤 변경 사항도 포함될 수 없습니다. 각 유지 관리 릴리스 초안은 게시된 사양의 이전에 채택된 버전에 대해 제안된 변경 사항을 표시하기 위해 변경 추적을 사용하여 통합된 모든 정오표 수정 사항을 식별해야 합니다.

유지 관리 릴리스 초안의 각 정오표 수정에 대해 제안된 통합 시기는 테스트 스위트 영향에 따라 다릅니다. 테스트 스위트에 영향을 주지 않는 모든 정오표 수정은 즉시 통합될 수 있지만 테스트 스위트에 영향을 미치는 정오표 수정은 즉시 통합될 수 있습니다. 타이밍이 TCRL 업데이트와 일치하도록 처리됩니다.

BTI와 BSTS는 유지 관리 릴리스 초안에 테스트 스위트에 영향을 미치는 정오표 수정 사항을 포함하기 위한 기한을 정할 것입니다. 이 마감일은 일반적으로 다음 주요 TCRL 릴리스의 계획된 승인 날짜로부터 3~6개월 전입니다. 포함 기한을 놓친 테스트 스위트 영향에 대한 정오표 수정은 다음 연간 TCRL 릴리스의 일부로 처리됩니다. 따라서 이전 릴리스를 요청하지 않는 한 기술적/높은 수준 또는 기술적/중요한 정오표 수정이 사양 업데이트에 포함되는 최대 시간은 약 15~18개월입니다.

사양 소유자는 법적 재검토를 위해 최종적으로 승인한 유지보수 릴리스 초안을 제출해야 합니다.view. 법적 재view 주로 사양의 변경된 부분에 중점을 둘 것입니다. 법적 재심사가 완료되면view, 사양 소유자와 BSTS는 피드백이 유지 관리 릴리스 초안에 통합되는 데 동의합니다. 법무팀에서 아직 해결되지 않은 법적 의견이 있는 경우view 유지보수 릴리스 초안에서 사양 소유자는 이사회 안건에 대한 시간을 요청하여 해결에 대한 이사회 의견을 구할 수 있습니다.

법적 재검토와 병행하여view, 사양 소유자는 재차 확인을 위해 유지보수 릴리스 초안을 BARB에 제출해야 합니다.view. 유지 관리 릴리스 초안이 BARB에 제출되면 BSTS는 모든 회원이 다시 액세스할 수 있도록 합니다.view 그리고 모든 회원에게 그 가용성을 알립니다. BARB re가 완료되면view, 사양 소유자와 BARB는 피드백이 초안 사양에 통합되는 데 동의합니다.

법적으로 다시view 실질적인 변경이 발생하면 추가 재검토가 필요합니다.view BARB가 필요할 수 있습니다. 마찬가지로, BARB가 다시view 실질적인 변경이 발생하면 BSTS는 추가적인 법적 조치가 있는지 결정합니다.view 이러한 변경 사항이 필요합니다. 법적 재심사가 완료되면view 그리고 BARB 다시view, BARB는 유지 관리 릴리스 초안을 승인하거나 거부해야 합니다. BARB가 승인하면 이것이 투표 초안이 됩니다.

테스트 문서에 영향을 미치는 정오표 수정과 해당 테스트 정오표가 다가오는 TCRL 릴리스에 맞춰 처리될 경우 BSTS는 사양 소유자 및 BTI와 협력하여 테스트 문서를 업데이트합니다. BTI가 테스트 문서를 승인하면 BSTS는 채택 날짜를 추정하고 TCRL에 사용할 수 있도록 제안된 채택 날짜를 BTI에 제공합니다. BTI는 관련 ICS, IXIT 및 테스트 스위트와 함께 TCRL을 BQRB에 제공합니다. 사양에 대한 BARB 승인, 모든 테스트 문서(해당되는 경우 테스트 스위트, TCRL, ICS 및 IXIT 포함)에 대한 BTI 승인 및 TCRL에 대한 BQRB 승인은 채택 날짜 또는 그 이전에 이루어져야 합니다.

BSTS는 투표 초안의 최종 확정 및 가용성과 제안된 채택 날짜를 모든 회원에게 알립니다. 채택일자는 세칙에 따라 모든 회원에게 정하여 공지하며, 채택일은 회원에게 공지한 날로부터 최소 14일 이후로 합니다. 제안된 채택일에 대한 통지가 회원들에게 제공된 후 이사회는 제안된 채택일에 대한 추가 통지를 제공하지 않고 필요한 14일을 기다리지 않고 투표 초안의 철자 오류 수정을 승인할 수 있습니다.

채택일 이전에 다음 문서를 작성하여 이사회에 제공해야 합니다.

투표 초안
동일한 XY 값을 갖는 사양의 채택된 버전에 대한 모든 변경 사항을 보여주는 투표 초안의 변경 추적 버전(예: 투표 초안이 버전 1.4.2로 제안된 경우 변경 사항은 1.4.1에 대해 추적됩니다. 사양 버전)
정당화와 함께 채택된 사양의 이전 버전을 더 이상 사용하지 않거나 철회하기 위한 사양 소유자의 권장 사항
법적 재검토에서 아직 해결되지 않은 법적 문제 목록view (만약 있다면)
BTI 승인 테스트 스위트, ICS 및 IXIT(유지 관리 릴리스에서 필요한 경우)
BTI 및 BQRB 승인 TCRL(유지 관리 릴리스에서 필요한 경우)
테스트 도구에서 지원하지 않는 TCRL의 테스트 사례 및 설명(유지 관리에서 필요한 경우)을 포함하여 도구 준비 상태(예: PTS 및 기타 테스트 도구, Bluetooth Launch Studio)에 관해 BTI와 함께 BSTS가 작성한 보고서입니다. 풀어 주다)
BSTS와 사양 소유자가 완료한 채택 체크리스트는 이 섹션의 결과물이 모두 완료되었음을 보여줍니다.
기타 이사회가 요청하는 모든 정보

이사회가 투표 초안을 채택하고 다음과 같은 채택 후 활동이 완료되면 유지 관리 릴리스 프로세스가 완료됩니다.

BSTS는 Bluetooth SIG에서 채택된 사양 및 관련 테스트 문서(유지 관리 릴리스에서 필요한 경우)를 공개적으로 공개했습니다. web대지.
BSTS는 Bluetooth SIG의 모든 회원이 사용할 수 있는 새로 채택된 버전에 통합된 모든 변경 사항을 포함하여 이전에 채택된 사양 버전의 유익한 변경 추적 버전을 만들었습니다. web대지.
BSTS는 자격 시스템을 활성화했습니다.
BSTS는 채택된 사양 및 지원 문서의 가용성을 모든 구성원에게 알렸습니다.

Bluetooth SIG는 사양 채택 후 1주일 이내에 이러한 채택 후 활동을 완료할 계획입니다.

이러한 활동이 완료되면 사양은 섹션 8에 정의된 대로 사양이 더 이상 사용되지 않거나 철회될 때까지 사양 유지 관리 단계에 유지됩니다.

8. 사양 수명 종료 단계

사양은 최신 버전으로 대체되거나 기술적으로 불충분하다고 판단되거나 기타 이유로 더 이상 사용되지 않거나 철회될 수 있습니다. 더 이상 사용되지 않고 철회된 사양은 보관되며 더 이상 업데이트되지 않습니다. 더 이상 사용되지 않거나 철회된 사양은 Bluetooth 자격 프로그램에서 다르게 처리됩니다.

모든 회원, 그룹 또는 위원회는 관련 타임라인과 함께 사양을 폐기하거나 철회하기 위한 권장 사항을 BSTS에 제출할 수 있습니다(이메일을 통해 다음으로 전송).

사양.manager@bluetooth.com) 언제든지 가능합니다. BSTS는 사양 및 관련 타임라인의 폐기 또는 철회를 권장할 수도 있습니다. BSTS는 BARB 및 재규격 사양 유지를 담당하는 그룹 또는 위원회에 권장 사항을 참조합니다.view 그리고 피드백.

BARB와 책임 그룹 또는 위원회는 사양을 더 이상 사용하지 않거나 철회하기 위한 권장 사항을 평가하고 다음(비포괄적) 기준을 고려합니다.

이전 버전의 사양에 더 이상 사용되지 않거나 사용해서는 안 되는 기능이 있습니까?
최신 버전에 새로운 필수 기능이 추가되었습니까?
이전 버전에서 작동이나 상호 운용성을 손상시키는 결함이 이후 버전에서 수정되었으며 기존 사용자 시나리오를 발전시키는 데 필요합니까?
새로운 사용자 시나리오를 발전시키는 데 필요한 이후 버전의 추가 기능이 있습니까?
이후 버전에서는 유용성과 상호 운용성이 향상되었습니까?
이후 버전에는 보안이 개선되었나요?

BARB와 책임 그룹 또는 위원회는 대체 권장 사항을 제안할 수 있습니다.

BARB 또는 사양 유지를 담당하는 그룹이나 위원회로부터 피드백을 받은 후 BSTS는 고려를 위해 권장 사항과 피드백을 이사회에 제출합니다. 이사회는 영향을 받는 사양을 유지 관리하는 그룹이나 위원회를 초대하여 권장 사항을 충족하고 논의할 수 있습니다. 이사회는 권고사항과 피드백을 고려하고 제안에 동의하거나 수정할 수 있습니다. 이사회는 BSTS가 사양을 폐기하거나 철회하라는 제안과 관련 일정을 30일 이내에 모든 구성원에게 통지하도록 요청할 것입니다.view 모든 구성원이 최종 결정을 내리기 전에 추가 피드백을 제공할 수 있는 기간입니다.

이사회는 회원들로부터 받은 피드백을 고려할 것입니다. BoD가 사양의 폐기 또는 철회를 승인하면 BSTS는 모든 구성원에게 결정 및 관련 일정을 알립니다.

8.1 지원 중단

사양이 더 이상 사용되지 않으면 다음과 같은 일이 발생합니다.

사양은 더 이상 업데이트되지 않습니다.
담당 WG는 다음과 같은 조치를 취할 것입니다.view 더 이상 사용되지 않는 사양에 대해 작성된 모든 미해결 정오표를 확인하여 다른 사양에 적용되는지 확인합니다. 정오표는 정오표 시스템에서 거부될 수 있으며 해당 사양에 따라 다시 작성될 수 있습니다.
WG 또는 BSTS는 다른 사양에서 더 이상 사용되지 않는 사양에 대한 필요한 참조를 업데이트하기 위해 정오표를 생성합니다.
BTI는 해당 사양의 사용 중단을 나타내기 위해 해당 테스트 문서를 업데이트합니다.
BSTS는 Bluetooth SIG를 업데이트합니다. web사용할 대체 사양에 관한 지침이 있는 사이트입니다.
더 이상 사용되지 않는 사양에 대해 새로운 정오표를 제출할 수 없습니다.
이 사양은 향후 사양에서 참조되지 않습니다.
BSTS는 회원들이 기록 목적으로 액세스할 수 있도록 더 이상 사용되지 않는 것으로 표시된 사양 버전을 보관합니다.

8.2 철회

사양이 철회되면 지원 중단을 적용하는 단계 외에도 다음이 수행됩니다.

BTI는 사양 철회를 나타내기 위해 해당 테스트 문서를 업데이트할 것입니다.
BSTS는 Bluetooth SIG를 업데이트합니다. web사용할 대체 사양에 관한 지침이 있는 사이트입니다.
BSTS는 회원들이 역사적인 목적으로 접근할 수 있도록 철회된 것으로 표시된 사양 버전을 보관할 것입니다.

BoD는 사양을 먼저 폐기하지 않고 즉시 사양을 철회하도록 선택할 수 있습니다.

9. 백서 프로세스

백서는 정보 제공의 목적으로만 작성되었습니다. 다음 백서 프로세스는 모든 Bluetooth WG, EG, SG 및 위원회에 적용됩니다. 이 섹션은 Bluetooth SIG 내에서만 사용되는 정보 문서에는 적용되지 않습니다.

이 프로세스는 아래 그림 9.1에 설명되어 있습니다.

그룹이나 위원회는 Bluetooth SIG에서 게시하려는 백서 작업을 시작하기 전에 백서 제안 내용을 명확하게 정의하는 제안된 헌장 업데이트와 백서 제안 프리젠테이션을 모두 준비합니다.

백서 제안 프레젠테이션에는 최소한 다음이 포함되어야 합니다.

백서의 필요성
백서에서 제안하는 내용 요약
콘텐츠가 사양의 일부로 포함되지 않는 이유에 대한 설명
의도 된 청중
유지 관리 계획(즉, 본 백서의 다음 릴리스까지 예상 시간이 필요할 수 있음)
이전 버전의 백서 처리 방법에 대한 권장 사항(예: 보관)

BARB 재등록을 위해서는 헌장 업데이트 및 백서 제안 프레젠테이션을 제출해야 합니다.view. 다시view BARB가 헌장 업데이트를 승인하면 BSTS는 지원 백서 제안 프레젠테이션과 함께 승인을 위해 이사회에 헌장 업데이트를 제출합니다.

이사회가 헌장 업데이트를 승인하면 그룹이나 위원회는 백서 개발을 진행할 수 있습니다.

그룹이나 위원회가 백서 개발을 완료하면 BSTS는 편집 재작업을 수행합니다.view Bluetooth 제도 지침과의 일관성을 위해.

BSTS 의견 해결 후, 그룹은 법적 재조사를 위해 백서를 BSTS에 제출해야 합니다.view. 법적 재심사가 완료되면view, 그룹과 BSTS는 피드백을 백서에 반영하는 데 동의합니다. 법무팀에서 아직 해결되지 않은 법적 의견이 있는 경우view 백서에서 그룹 의장은 이사회 안건에 대한 시간을 요청하여 결의에 대한 이사회의 의견을 구할 수 있습니다.

법적 재검토와 병행하여view, 그룹은 다시 BARB에 백서를 제출해야 합니다.view. 그들의 재의 일부로view, BARB는 백서의 일부를 백서에서 제거하고 섹션 3의 프로세스에 따라 사양에 통합해야 하는지 여부를 권장할 수 있습니다. BARB는 또한 재검토를 위해 백서를 다른 그룹이나 위원회에 제출하기로 결정할 수도 있습니다.view. BARB re가 완료되면view, 그룹과 BARB는 피드백이 백서에 포함되는 데 동의합니다.

BARB가 백서를 승인한 후 BARB가 승인한 백서는 저작 그룹 또는 위원회에서 승인을 위해 이사회에 제출됩니다.

이사회가 백서를 승인하고 다음과 같은 승인 후 활동이 완료되면 백서 프로세스가 완료됩니다.

BSTS는 승인된 백서를 Bluetooth SIG에 공개했습니다. web대지.
BSTS는 승인된 백서를 모든 회원에게 공지합니다.
백서가 기존 백서를 개선한 경우, BSTS는 회원들이 역사적 목적으로 접근할 수 있도록 백서 버전을 보관할 것입니다.

블루투스 SIG는 백서 승인 후 1주일 이내에 승인 후 활동을 완료할 계획이다.

10. 참고문헌

참조된 Bluetooth 문서는 Bluetooth에서 확인할 수 있습니다. web대지 http://www.bluetooth.com.

Bluetooth 제도 지침(작업 그룹 템플릿 및 문서 페이지에서 사용 가능) https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Bluetooth SIG, Inc.의 조례(관리 문서 페이지에서 확인 가능) https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Bluetooth 사양 정오표 처리 문서(작업 그룹 템플릿 및 문서 페이지에서 사용 가능) https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
작업 그룹 프로세스 문서(작업 그룹 템플릿 및 문서 페이지에서 사용 가능) https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
테스트 전략 및 용어 이상view 문서(자격 테스트 요구 사항 페이지에서 확인 가능) https://www.bluetooth.com/specifications/qualification-test-requirements)
BTI 사양 다시view 프로세스 체크리스트(작업 그룹 템플릿 및 문서 페이지, https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Bluetooth SIG 할당 번호(https://www.bluetooth.com/specifications/assigned-numbers)
작업 그룹 템플릿 및 문서(작업 그룹 템플릿 및 문서 페이지에서 사용 가능) https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
GATT 사양 보충 자료(GSS)(GATT 사양 페이지에서 제공) https://www.bluetooth.com/specifications/gatt)
새로운 사양에 대한 아이디어 제출 https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. 두문자어 및 약어

표 A: 두문자어 및 약어

부록 A – 정오표 심각도 분류

이 부록에는 사양 정오표에 대한 심각도 분류 지침이 요약되어 있습니다. 이 표는 향후 EPD 개정판에 추가될 예정이며 이후 이 섹션은 삭제됩니다.

이 매뉴얼에 대해 더 자세히 알아보고 PDF를 다운로드하세요:

사양 관리 프로세스 문서(SMPD) – 최적화된 PDF
사양 관리 프로세스 문서(SMPD) – 원본 PDF

매뉴얼에 대한 질문이 있으신가요? 댓글에 게시하세요!

참고문헌

사용자 설명서