Тодорхойлолтын менежментийн үйл явцын баримт бичиг (SMPD)

Энэхүү баримт бичиг нь гарчиг, агуулгаас үл хамааран Bluetooth SIG Inc. ("Bluetooth SIG") болон түүний гишүүдийн Bluetooth Патент / Зохиогчийн эрхийн лицензийн гэрээ болон Bluetooth худалдааны тэмдгийн лицензийн гэрээний дагуу олгосон лицензүүдэд хамаарах Bluetooth-ийн тодорхойлолт биш юм.

ЭНЭ БАРИМТ БИЧИГ "ОДОО" ХЭРЭГЖҮҮЛЖ БАЙНА, BLUETOOTH ТЭМДЭГЛЭЛ, ТҮҮНИЙ ГИШҮҮД, ТЭДНИЙ АЖИЛЛАГААЧД ТӨЛӨӨЛӨЛ, БАТАЛГАА БУРУУЛАХГҮЙ БАЙНА ЭНЭ БАРИМТ БИЧГИЙН АГУУЛГА ҮНЭГҮЙ.

ХУУЛИЙН ХОРИГЛОЛГҮЙ ТЭМДЭГЛЭЛ, BLUETOOTH SIG, ТҮҮНИЙ ГИШҮҮД, ЭНЭ БАРИМТ БИЧЛЭГ, ОРНОТ ОРНО, ОРНО, ОРНО, ОРНО, ОРНО, ОРНО, ОРНО, ОРНО, ОРНО, ОРЧУУЛГА, ЭНЭ БАРИМТ БИЧИГ, АШИГЛАЛТТАЙ ХОЛБООТОЙ ҮҮСЭХ, БҮХ ХАРИУЦЛАГА ХЭЛЭХГҮЙ БАЙНА. ХАРИУЦЛАГЫН ОНОЛЫГ ХАРИУЦЛАГА, ЭСВЭЛ ОНЦГОЙ, ШУУРГҮЙ, ШУУРГААРГҮЙ, ОЙРТОЙ БАЙГУУЛЛАГА, ЦЭВЭРЛЭХ Хохирол, БЛЮТҮҮТ ГЭРЭЛ БОЛОН ТҮҮНИЙ ГИШҮҮД, ЭСВЭЛИЙН ХЭРЭГЛЭЛИЙН ХЭРЭГТЭВ

Энэхүү баримт бичиг нь Bluetooth SIG-ийн өмчлөл юм. Энэхүү баримт бичиг нь Bluetooth SIG болон түүний гишүүдийн оюуны өмч болох сэдвийг агуулсан эсвэл хамарсан байж болно. Энэхүү баримт бичгийг тавьснаар Bluetooth SIG эсвэл түүний гишүүдийн оюуны өмчийн аливаа лиценз олгохгүй.

Энэхүү баримт бичгийг мэдэгдэлгүйгээр өөрчлөх боломжтой.

1. Танилцуулга

Тодорхойлолтын менежментийн процессын баримт бичиг (SMPD) нь тодорхойлогч зохиогчид болон дахин боловсруулсан процессуудыг тодорхойлдогviewШинэ техникийн үзүүлэлтүүдийг боловсруулж, одоо байгаа техникийн үзүүлэлтүүдийг сайжруулахын тулд (өөрөөр хэлбэл батлагдсан тодорхойлолтонд функцийг нэмэх, хасах эсвэл тодорхой функцийг өөрчлөх), баталсан техникийн нөхцлийг хадгалах, батлагдсан техникийн нөхцлийн ашиглалтын хугацааг зохицуулах үүргийг гүйцэтгэх ёстой. Нэмж дурдахад энэхүү баримт бичигт дахин бүтээх үйл явцыг тайлбарласан болноviewбөглөх, цагаан хуудсыг батлах.

Эдгээр даалгаврын хамрах хүрээний угаасаа ялгаатай байдлаас шалтгаалан техникийн тодорхойлолтыг боловсруулах явцад шинэ тодорхойлолт боловсруулах, одоо байгаа үзүүлэлтүүдийг сайжруулах хооронд ялгаа бий; эдгээр ялгааг энэ баримт бичигт онцолсон болно.

Тодорхойлолтыг боловсруулах үйл явцад дараахь зүйлс орно.

Функциональ шаардлагыг тодорхойлох шаардлагын үе шат (3-р хэсэгт тайлбарласан)
Хөгжүүлж, дахин боловсруулах хөгжлийн үе шат (4 -р хэсэгт тайлбарласан)view техникийн үзүүлэлтүүд

Хамтран ажиллах боломжтой прототип (IOP) туршилтаар техникийн нөхцлийг баталгаажуулах баталгаажуулалтын үе шат (5-р хэсэгт тайлбарласан)
Bluetooth SIG-ийн Төлөөлөн Удирдах Зөвлөлд (BoD) танилцуулах / батлуулахаар техникийн тодорхойлолтыг танилцуулах / батлах үе шат (6-р хэсэгт тайлбарласан).

Specification Errata Process баримт бичиг (EPD) [3] нь санал болгох, дахин боловсруулах үйл явцыг тодорхойлдогviewтехникийн тодорхойлолтын алдааг олж, тэдгээрийг батлагдсан техникийн нөхцлийн дагуу алдааны залруулга гэж батлах (Дүрэм [2] -д заасан). Хэрэв өөрөөр заагаагүй бол энэхүү SMPD дэх алдааны талаархи бүх лавлагаа нь техникийн тодорхойлолтын алдааг илэрхийлнэ.

1.1 Давуу эрх

Bluetooth SIG, Inc-ийн Дүрэм (Дүрэм) ба гишүүнчлэлийн гэрээнүүд [2] нь эдгээр баримт бичиг болон SMPD-д агуулагдах зөрчилтэй агуулгаас давуу эрхтэй байна. Энэхүү баримт бичигт заасан аливаа зүйлийг үл харгалзан ТХ нь эдгээр баримт бичигт заасан ямар нэгэн зүйл дагаж мөрдөөгүй буюу зөрчилдөхгүй байсан ч энэхүү баримт бичигт юу ч байсан ТХ-ны хараат бус эрх мэдлийг хязгаарлаж, хязгаарлаагүй ч гэсэн арга хэмжээ авч, шийдвэр гаргах бүрэн эрх, эрх мэдлээ хадгалж үлддэг. болон үзэмж.

Хэрэв SMPD дээрх текст ба зургийн хооронд ямар нэгэн зөрчилдөөн байвал текстийг тэргүүлэх байр суурь эзэлнэ.

1.2 Лавлагааны бүлгүүд, хороод

Энэхүү баримт бичигт дараах төрлийн бүлгүүдийг дурдсан болно: Судалгааны бүлэг (SG), Шинжээчдийн бүлэг (EG), Ажлын хэсэг (АХ). АХ нь АХ -д мэдээлдэг дэд бүлэгтэй байж болно. Үүнтэй адилаар энэхүү баримт бичигт дараахь төрлийн хороодыг дурдсан болно: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI), Bluetooth Qualification Review Зөвлөл (BQRB). Энэхүү баримт бичиг нь Bluetooth SIG -ийн техникийн ажилтнууд (BSTS) болон Удирдах зөвлөлд хамаарна.

1.3 Хороо дахинviews ба зөвшөөрлүүд

Нэг хороо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 Core Specification -ээс хамаарна. Уламжлалт мэргэжлийн зэрэг техникийн үзүүлэлтүүдfiles; уламжлалт протокол; болон GATT-д суурилсан мэргэжлийнfiles, GATT-д суурилсан үйлчилгээ, GATT-д суурилсан протоколууд нь Цөмийн тодорхойлолтын онцлогоос хамаарна. Mesh загварын үзүүлэлтүүд гэх мэт бусад үзүүлэлтүүд нь Mesh Pro -ээс хамаардагfile тодорхойлолт нь үндсэн үзүүлэлтээс хамаарна.

Үндсэн тодорхойлолтын нэмэлт (CSS) тодорхойлолт нь өгөгдлийн төрөл, өгөгдлийн формат, нийтлэг програмыг тодорхойлдогfile болон үндсэн техникийн үзүүлэлтүүд болон бусад техникийн үзүүлэлтүүдэд ашиглагддаг үйлчилгээний алдааны кодууд нь ямар ч зан үйлийг өөрөө тодорхойлдоггүй.

GATT тодорхойлолтын нэмэлт (GSS) тодорхойлолт нь Pro -ийн ашигладаг шинж чанар, тодорхойлогчийн форматыг тодорхойлдог.files and Services бөгөөд ямар ч зан үйлийг өөрөө тодорхойлдоггүй.
Mesh Device Properties (MDP) үзүүлэлт нь Mesh Pro -ийн ашигладаг торон шинж чанарыг тодорхойлдогfile болон Mesh Model -ийн техникийн үзүүлэлтүүд бөгөөд ямар ч зан үйлийг өөрөө тодорхойлдоггүй.

2. гаруйview

Энэ хэсэг нь хэтрүүлэн өгдөгview үйл явцын талаар болон бүх нарийн ширийн зүйлийг агуулаагүй болно.

Зураг 2.1-д Техникийн нөхцөлийн менежментийн процессыг бүрдүүлэгч зургаан үндсэн үе шатыг харуулав.

Эхний дөрвөн үе шат нь техникийн тодорхойлолтыг боловсруулах явцад явагдах бөгөөд Шаардлагын үе шат (3-р хэсэг), Хөгжлийн үе шат (4-р хэсэг), Баталгаажуулалтын үе шат (5-р хэсэг), Батлах / батлах үе шат (6-р хэсэг) -ээс бүрдэнэ. Үүний дараа үрчлэлтийн дараахь хоёр үе шат үргэлжилнэ: Техникийн нөхцлийн засвар үйлчилгээний үе шат (7-р хэсэг) ба техникийн тодорхойлолтын ашиглалтын хугацаа дуусах үе шат (8-р хэсэг).

Зураг 2.2-т техникийн тодорхойлолтыг боловсруулах үйл явцын дөрвөн үе шатыг нарийвчлан харуулав. Саарал хайрцгууд нь үе шат бүрийн гол үр дүнг харуулдаг. Улбар шар өнгийн хайрцгуудад үйл явцын чухал үе шатуудыг нэгтгэн харуулав.

Шаардлагын үе шатанд (3-р хэсэгт тайлбарласан) шинэ ажил эхлүүлэх санал (Шинэ ажлын санал (NWP)) нь шинэ ажил эхлэвэл идэвхжүүлэх хэрэглэгчийн хувилбаруудыг тодорхойлж тодорхойлолтыг боловсруулах үйл явцыг эхлүүлдэг. Хэрэв NWP батлагдсан бол хуваарилагдсан бүлэг нь үйл ажиллагааны шаардлагын баримт бичгийг (FRD) үүсгэдэг. FRD батлагдаж бүлэгт хуваарилагдсаны дараа Хөгжлийн үе шат эхэлнэ.

Хөгжүүлэлтийн үе шатанд (4 -р хэсэгт тайлбарласан) техникийн тодорхойлолтын боловсруулалт s дарааллаар дамждагtages (0.5/DIPD -ээс 0.9/CR хүртэл) техникийн тодорхойлолтын бүрэн төслийг боловсруулсан болно. 0.9/CR -ийн тодорхойлолтыг бүх гишүүдэд танилцуулж, дараа нь Удирдлагын зөвлөлд хүргүүлж, техникийн нөхцлийг батална. Зөвшөөрөгдсөний дараа баталгаажуулалтын үе шат эхэлнэ.

Техникийн тодорхойлолтыг боловсруулах баталгаажуулалтын үе шатанд (5-р хэсэгт тайлбарласан) БХ-ны зөвшөөрсөн 0.9/CR-ийн тодорхойлолтыг бүх гишүүдэд дахин танилцуулах боломжтой болгоно.view мөн баталгаажуулж, гишүүн Review эхэлж байна. Баталгаажуулалтыг гишүүдийн бүтээсэн прототипүүдийн хоорондох харилцан үйлчлэл (IOP) туршилтаар хийдэг. IOP -ийн туршилтыг хийж дууссаны дараа (хэрэв тодорхойлолтонд шаардлагатай бол) BARB нь IOP -ийн туршилтын тайланг баталсны дараа үрчлэлт/батлах үе шат эхэлнэ.

Үрчлэх / батлах үе шатанд (6-р хэсэгт тайлбарласан) тодорхойлолт, холбогдох туршилтын баримт бичгийг эцэслэн боловсруулсан болно; BARB, BQRB, BTI зөвшөөрлийг хүлээн авсан; мөн техникийн тодорхойлолтын эцсийн багцыг батлах тодорхойлолтыг авч үзсэн ТХГ-т хүргүүлнэ (өөрөөр хэлбэл эцсийн зөвшөөрөл).

Тодорхойлолт нь өмнөх үе шат эсвэл үе рүү буцах шаардлагатай байж магадгүй юмtagд мэдэгдэхүйц өөрчлөлт оруулсан тохиолдолд. Зарим тохиолдолд 4.4 -р хэсэгт тайлбарласан үе шатны нэг хэсгийг цуцлах боломжтой байж болно.

Техникийн тодорхойлолтын засвар үйлчилгээний үе шат (7-р хэсэгт тайлбарласан болно) нь техникийн тодорхойлолтыг BoD баталсны дараа эхэлнэ. Энэ үе шатанд батлагдсан техникийн тодорхойлолтоос гарч болзошгүй алдаануудыг мэдээлж, үнэлэх ба (хэрэв шаардлагатай бол) тодорхойлолтын дагуу алдаа засах болно. Техникийн үзүүлэлтийг засварлах үе шат нь техникийн тодорхойлолтыг хүчингүй болгох эсвэл хүчингүй болгох хүртэл үргэлжилнэ (Дараах догол мөрөөс техникийн ашиглалтын хугацаа дуусах үе шатыг үзнэ үү).

Тодорхойлолтын ашиглалтын хугацаа дуусах үе шат (8-р хэсэгт тайлбарласан) нь батлагдсан техникийн нөхцлийг цуцлах, буцаах үйл явцыг тодорхойлдог.

3. Шаардлагын үе шат

Шаардлагын үе шат нь NWP-ээс (хэрэглэгчийн нэг буюу хэд хэдэн хувилбар дээр ажил эхлүүлэх хүслийг илэрхийлдэг) эсвэл хүссэн шинэ бүтээлийг АХ-ны дүрмэнд аль хэдийн хамрагдсан болохыг тогтоосны дараа эхэлнэ. Хэрэв АХ нь АХ-ны дүрмийн хүрээнд аль хэдийн орсон гэж үзсэн шинэ ажил эхлүүлэхийг хүсвэл АХ нь БХ-ийг боловсруулж эхлэхийн тулд 3.1-р хэсэгт тодорхойлсон үйл явцыг дагаж мөрдөх ёстой. Ажлын бусад бүх зүйлийн хувьд АХ нь Хэсэг 3.2-т тодорхойлсон процессыг дагаж мөрдөх ёстой. Хөгжлийн үе шатанд техникийн нөхцлийг бүрдүүлэхэд ашигладаг функциональ шаардлагуудын хамрах хүрээг FRD тодорхойлдог. Шаардлагын үе шатыг Зураг 3.1-д үзүүлэв.

3.1 АХ-ны дүрэмд хамрагдсан шинэ ажил

АХ нь шинэ ажил эхлүүлэхийг хүсч, нэмж оруулахыг хүссэн чиг үүрэг нь АХ-ны дүрмийн хүрээнд аль хэдийн орсон гэж үндэслэлтэй итгэж байгаа тохиолдолд АХ нь BARB-д нэн даруй мэдэгдсэн тохиолдолд FRD дээр ажиллаж эхлэх боломжтой. АХ нь BARB-д мэдэгдэлдээ санал болгож буй шинэ бүтээлийн тодорхойлолт, АХ дүрмийн хуулбарыг шинэ ажлыг эхлүүлэх эрхийг олгосон хэлээр оруулна.

Хэрэв BARB АХ-ын шинжилгээг няцаавал АХ нь БХ-ны ажлыг зогсоож Хэсэг 3.2-т заасан NWP процессыг үргэлжлүүлэх ёстой. Хэрэв BARB АХ-ын дүн шинжилгээг зөвшөөрвөл АХ нь BSTS-д нэн даруй мэдэгдэх болно (имэйлээр specification.manager@bluetooth.com хаягаар) ба BSTS нь дараагийн BoD хэлэлцэх асуудалд оруулах болно.

АХ нь BSTB-д мэдэгдэлдээ BARB-д өгсөн мэдээллээ оруулна. Хэрэв ТХ нь АХ-ийн шинжилгээг няцаавал АХ нь БХ-ны ажлыг зогсоож, Хэсэг 3.2-т заасан NWP процессыг үргэлжлүүлэх ёстой. Хэрэв ТХ нь АХ-ийн шинжилгээг зөвшөөрвөл АХ Хэсгийн 3.3-т заасны дагуу БХБ-тай үргэлжлүүлэн ажиллаж болно.

3.2 Шинэ ажлын санал (NWP)

Аливаа гишүүн, АХ, СГ, ЭБ нь NWP үүсгэж, илгээж болно (Bluetooth SIG -ээр дамжуулан webсайт [10]). NWP нь хамгийн багадаа [8] -д заасан албан ёсны загварыг ашиглан дараахь мэдээллийг агуулсан байх ёстой.

Хэрэглэгчийн хувилбарууд
FRD -ийг хөгжүүлэх, ямар чиглэлээр (ямар чиглэлээр) ажиллах тухай гишүүдийн амлалт (жишээ нь, Contributor, Author, ReviewТийм ээ, прототип хийх)

FRD ажлын удирдлага санал болгосон
FRD-ийн ажилд санал болгосон бүлгийн даалгавар
Анхан шатны зохиогчийн и-мэйл хаяг

Жич: NWP үйл явцын талаархи удирдамжийг Bluetooth SIG дээр авах боломжтой webсайт [10].

БСТС нь БЦГ-ыг хөгжүүлэх явцад дараахь ажлуудыг гүйцэтгэнэ.

Зохиолч (ууд) хүлээн авснаа мэдэгдэж (ихэвчлэн хүлээн авснаас хойш хуанлийн долоон хоногийн дотор) өгч, дараагийн алхмуудыг тоймлон харуул.

Шаардлагатай бол NWP нь тодорхой, бүрэн дүүрэн байхын тулд зохиогч (ууд) -той хамтран ажиллана уу. Энэ нь NWP-ийн хэд хэдэн давталтыг шаардаж магадгүй юм.
Хэрэв NWP нь батлагдсан Bluetooth техникийн үзүүлэлтүүдийн алдааны талаархи мэдэгдлийг агуулсан бол зохиогчтой хамтран ажиллана уу file алдааны системд оруулах.
Хэрэв NWP нь аль хэдийн хийгдэж дууссан эсвэл аль хэдийн дууссан бүтээлийг хуулбарлаж болзошгүй байгааг анзаарсан бол бусад бүтээлийн зохиогч (зохиолч) -д үнэлгээ өгөхдөө мэдэгдээрэй.

NWP -ийг NWP -д илгээх webсайт бүх гишүүдэд нээлттэй.
NWP -ийг дахин ашиглах боломжтой байгааг бүх гишүүдэд мэдэгдээрэйview мөн FRD -ийг хөгжүүлэх гишүүдийн нэмэлт амлалт шаардлагатай эсэх.

Гишүүд зохиогчтой холбогдож асуулт асуух эсвэл NWP-тэй холбоотой санал хүсэлт өгөх боломжтой.

Наад зах нь гурван гишүүн компаниуд ҮХ-ийг батлахаар нэр дэвшигч болохын тулд үүссэн FRD-ийг бөглөхөд оролцох үүрэг хүлээх ёстой бөгөөд дор хаяж нэг гишүүн компани нь Associate эсвэл Promoter гишүүн байх ёстой. АББ-ийг баталсны дараа ТХ нь NWP-ийг одоо байгаа бүх гишүүдийн АХ дэд бүлэгт эсвэл SG-д FRD дээр ажиллах хуваарилна (Хэсэг 3.3-т тайлбарласан болно). Хэрэв тохирох АХ дэд бүлэг эсвэл SG байхгүй бол түүнийг үүсгэж болно.

Гишүүний үүрэг амлалтыг хангалттай авсан NWP-ийн хувьд BSTS нь дараахь нэмэлт ажлуудыг гүйцэтгэнэ.

ТББ-ыг батлах санал гаргахаас 13-аас доошгүй хоногийн өмнө BWB-д батламж хүлээгдэж байгаа талаар BARB-д мэдэгдэж, NWP-ийг томилохыг санал болгосон бүлэгт мэдэгдэнэ. Энэ нь санал болгож буй бүлэг, NWP-ийг аль хэдийн хийсэн ажилд хамрагдсан эсэх гэх мэт чиглэлээр санал хүсэлт гаргах боломжийг олгох үүднээс хийгдэж байна.

Бэлэн болсон NWP-ийг BoD-д оруулна уу.

Хэрэв NWP-ийг бүлэгтэй холбоогүй гишүүд ирүүлсэн бол гишүүдийн аль нэг нь NWP-г BoD-д танилцуулах ажлыг зохион байгуул.
Хэрэв NWP-ийг бүлгээс ирүүлсэн бол бүлгийн дарга NWP-г BoD-д танилцуулах ажлыг зохион байгуул.

БХБ-ийн хуралдаанд NWP-ийг томилохыг санал болгож буй BARB дарга, бүлгийн дарга нарыг урь.
Хэрэв NWP-ийг ТУЗ зөвшөөрч, томилсон бол түүнд хуваарилагдсан бүлэгтээ мэдэгдэх; зохиогч (ууд); NWP-д холбогдох FRD-ийг боловсруулах үүрэг хүлээсэн гишүүд гэж тодорхойлсон; хэрэв NWP-ийг бүлэг санал болговол үр дүнгийн бүлэг ба дараагийн алхамууд.

NWP -ийг Удирдах зөвлөл баталсны дараа NWP -ийн статусыг шинэчилнэ үү webсайт.

Аливаа УБХ -ийг ТУЗ өөрийн үзэмжээр татгалзаж болноampНөөцийн хязгаарлагдмал байдлаас шалтгаалан хэрэв ажил аль хэдийн бүрэн дууссан бол уг ажил нь Bluetooth SIG -ийн удирдах баримт бичгийн хамрах хүрээнээс гадуур байна (жишээ нь, Application Programming Interface (API)) [2], эсвэл санал болгож буй ажил нь filed алдаатай байдлаар. Хэрэв NWP -ээс татгалзсан бол BSTS нь зохих FRD -ийг боловсруулах үүрэг хүлээсэн гэж зохиогч (ууд), NWP -д тодорхойлсон гишүүдэд, хэрэв NWP -ийг бүлэг санал болговол энэ бүлэгт мэдэгдэнэ. Мэдэгдэлд татгалзсан шалтгааныг оруулах болно. Зохиогч (үүд), үүрэг хүлээсэн гишүүд, бүлэг нь татгалзсан хариу өгөхийг эсэргүүцэн гомдол гаргахын тулд Удирдах зөвлөлийн хэлэлцэх асуудлын талаар цаг гаргаж болно.

Хэрэв гишүүн эсвэл бүлэг нь батлагдсан тодорхойлолтоос онцлог шинж чанарыг хасахыг санал болгохыг хүсвэл бүлэг эсвэл гишүүн нь NWP бэлтгэх ёстой. NWP нь зайлуулалтыг арын нийцтэй байдал, харилцан уялдаатай байдалд үзүүлэх нөлөөллийн дүн шинжилгээ, туршилтын тохиолдлуудад үзүүлэх нөлөөллийн дүн шинжилгээг багтаасан байх ёстой.

NWP нь CSS, GSS эсвэл MDP техникийн үзүүлэлтүүдийг сайжруулахад шаардагддаггүй: ихэвчлэн CSS, GSS эсвэл MDP-ийн техникийн шинэчлэлтүүд нь өөр өөрийн NWP-тэй бусад техникийн шинэчлэлтүүдээс үүдэлтэй байдаг.

3.3 Функциональ шаардлагын баримт бичиг (FRD)

FRD нь хэрэглэгчийн хувилбарыг идэвхжүүлэх функциональ шаардлагыг тодорхойлдог. FRD нь дор хаяж [8] -д заасан албан ёсны загварыг ашиглан дараахь зүйлийг агуулсан байх ёстой.

Хэрэглэгчийн хувилбарууд
Хэрэглэгчийн хувилбар дээр үндэслэсэн функциональ шаардлага

Үр дүнгийн тодорхойлолтыг боловсруулах гишүүдийн үүрэг амлалт
Хүлээгдэж буй үүрэг ролийн хувьд гишүүдээс нэмэлт загвар дэмжлэг авах
Үр дүнгийн тодорхойлолтыг боловсруулах АХ санал болгосон.

FRD хөгжүүлэх

FRD-ийг томилогдсон бүх гишүүн АХ дэд бүлэг эсвэл BGS-ийн редакцийн дэмжлэгтэй SG гишүүд үүсгэдэг. FRD-ийн хөгжилд оролцох хүсэлтэй гишүүн бүр бүлэгт нэгдэж болно.

ҮХХ нь дор хаяж хоёроос (XNUMX-ийг нь дэмжиж байгаа) Associate- эсвэл Promoter-ийн түвшний гишүүн компаниудын үр дүнгийн тодорхойлолтыг боловсруулахад оролцох амлалтыг зааж өгөх ёстой. БХБ-ыг өргөн мэдүүлсэн АХ эсвэл СЗ нь БХБ-д тодорхойлсон зорилтот салбарын сегментийг төлөөлж буй бүлгийн гишүүн компаниудын өргөн дэмжлэгийг авахыг хичээх ёстой.

FRD -д санал болгож буй шинэ функцийг аль болох олон тээвэрлэлт болон одоо байгаа төхөөрөмжүүд дээр дэмжих ёстой. Үүнд, жишээ ньample, GATT-д суурилсан дэмждэгfileҮндсэн хурд/Өргөтгөсөн өгөгдөл дамжуулах хурд (BR/EDR) болон Bluetooth Бага энерги (LE) тээвэрлэлтийн аль алины үйлчилгээ ба үйлчилгээ. Хэрэв шинэ функцэд тээвэрлэлтэнд хангалттай гишүүний дэмжлэг байхгүй бол, жишээ ньampТээвэрлэлтийн ашиглалтыг тодорхойлох үүрэг хүлээгээгүй гишүүд эсвэл нэг буюу хэд хэдэн үүрэгт IOP туршилтын платформ хангалтгүй байгаа тул энэхүү тээврийн дэмжлэгийг FRD -ээс хасч болно.

Өөр үндэслэлгүй бол шинэ функц, profiles, үйлчилгээ нь 3.3.2 -т заасан хоцрогдсон нийцтэй байдлын шаардлагыг хангасан байх ёстой.

Ажлын хэсэг эсвэл АХ нь FRD -ийг BARB -д дахин хүргүүлэх ёстойview ба зөвшөөрөл. BARB нь инженерийн дүгнэлтээ үндэслэн FRD -ийг батлах эсвэл татгалзах ёстой. Хэрэв BARB зөвшөөрсөн бол FRD -ийг бүх гишүүдэд танилцуулж, бэлэн байгаа тухай мэдэгдлийг BSTS гаргана.

CSS, GSS эсвэл MDP техникийн нөхцлийг сайжруулахын тулд FRD-г шаарддаггүй: ихэвчлэн CSS, GSS эсвэл MDP-ийн техникийн шинэчлэлтүүд нь өөр өөрсдийн FRD-тэй бусад техникийн шинэчлэлтүүдээс үүдэлтэй байдаг.

Буцах нийцтэй байдлын шаардлага

BR / EDR-ийн арын нийцтэй байдал

BR / EDR ажиллагааны хувьд арын тохирох шаардлагыг Bluetooth Core Specification v1.1 ба түүнээс дээш хувилбаруудын BR / EDR хэсэгтэй харилцан ажиллах гэж тодорхойлсон болно.

Bluetooth Low Energy-тэй нийцтэй байдал

LE ажиллагааны хувьд арын тохирох шаардлагыг Bluetooth Core Specification v4.0 ба түүнээс дээш хувилбарын LE хэсэгтэй харилцан ажиллах гэж тодорхойлсон болно.

Үндсэн тодорхойлолтоос бусад техникийн үзүүлэлтүүдийн арын нийцтэй байдал

Bluetooth -ийн үндсэн үзүүлэлтээс бусад техникийн үзүүлэлтүүдийн хувьд тухайн хувилбарын хоцрогдсон нийцтэй байдлыг ижил үндсэн хувилбарын дугаартай өмнөх бүх хувилбаруудтай хадгалах ёстой. Жишээ ньample, 1.3 хувилбар нь 1.2, 1.1, 1.0 хувилбаруудтай нийцэж байх ёстой боловч 2.0 хувилбар нь 1.0, 1.1, 1.2, 1.3 хувилбаруудтай нийцэхгүй байж магадгүй юм. Үндсэн техникийн тодорхойлолтын үндсэн хувилбарын тоог нэмэгдүүлэх нь өмнөх хувилбаруудтай уялдан нийцсэн гэсэн үг биш гэдгийг анхаарна уу.

Хоцрогдсон нийцтэй байдлын шаардлагаас чөлөөлөх

Ажлын хэсэг эсвэл АХ нь үндэслэлийг тайлбарласан тохиолдолд тодорхой функцийг хоцрогдсон нийцтэй байдлын шаардлагаас чөлөөлөхийг санал болгож болно. Жишээ ньampХэрэв энэ функц нь зах зээлд нэвтрүүлэх түвшин бага байгааг харуулсан эсвэл харилцан уялдаатай холбоотой асуудлуудаас болж функцийг өөрчлөхөөс илүү функцийг устгах эсвэл солих нь дээр. Ажлын хэсэг эсвэл АХ нь FRD -д батлагдсан BARB -ээс баталсан FRD -ийн хоцрогдсон нийцтэй байдлын чөлөөлөлтийг агуулсан байх ёстой. BARB-ээр батлагдсан аливаа чөлөөлөлтийг 0.9/CR S дээр батлуулахаар Удирдах зөвлөлд танилцуулнаtage.

3.4 Ажлын хэсгийн дүрэм

BARB одоо байгаа АХ-д хуваарилагдахаар санал болгож буй FRD-г батлахдаа АХ нь шинэ функцийг хамрах хүрээг нэмэгдүүлэхийн тулд дүрмэндээ шинэчилсэн найруулгын төсөл боловсруулсан байх ёстой (хэрэв АХ нь АХ-ны дүрмийн шинэчлэл гэж АХ-ын дүн шинжилгээг өмнө нь батлаагүй бол). шаардлагагүй). Гэсэн хэдий ч BARB нь шинэ АХ-д хуваарилагдахаар санал болгож буй FRD-г батлахад BARB болон СЗ-д заасан функцийг хөгжүүлэх сонирхолтой гишүүд дүрмийн хүрээнд багтсан шинэ чиг үүргийн хамт шинэ АХ-ны дүрмийн төслийг бэлтгэх ёстой. .

АХ -ны шинэ буюу шинэчилсэн найруулгын дүрмийг бэлтгэсний дараа үүнийг дахин BARB -д ирүүлэх ёстойview ба зөвшөөрөл. BARB дүрмийг баталсны дараа АХ -ны шинэ буюу шинэчлэгдсэн дүрмийн төслийг Удирдах зөвлөлд оруулж батлуулах болно.

ТХ нь дүрмийг баталсны дараа ТХ-оос техникийн тодорхойлолт боловсруулах ажлыг томилсон АХ нь энэхүү СТХ-д шаардлагатай шинэчлэлт, тодруулга шаардагдах тохиолдолд БХБ-ийг бэлтгэсэн бүлэгтэй нягт хамтран ажиллах ёстой. Хэрэв Хөгжлийн үе шатанд FRD шинэчлэлт хийх шаардлагатай бол Хэсэг 3.3 ба энэ хэсэгт заасан процессуудыг дагаж мөрдөх ёстой; Гэсэн хэдий ч тодорхойлолтын боловсруулалт нь FRD ба WG дүрмийн шинэчлэлтүүдтэй зэрэгцэн тохиолдож болно.

3.5 Шаардлагууд Үе шатнаас гарах шаардлага

Шаардлагын үе шат дууссан бөгөөд Хөгжлийн үе шат нь FRD-д шаардлагатай хамрах хүрээ бүхий АХ дүрмийг ТХБ-аар баталгаажуулж, баталж, дараахь шаардлагыг хангасан үед эхэлнэ.

NWP нь BoD-ээр батлагдсан эсвэл NWP нь шаардлагагүй гэж BoD зөвшөөрсөн.

FRD ба холбогдох АХ дүрмийг BARB батлав.

4. Хөгжлийн үе шат

Хөгжлийн үе шатанд хуваарилагдсан АХ (ууд) нь шинэ тодорхойлолтыг бий болгож, эсвэл одоо байгаа тодорхойлолтыг сайжруулдаг. FRD нь шинэ эсвэл сайжруулсан Bluetooth техникийн шаардлагыг тодорхойлдог. Техникийн зохицуулалтын стандартад тавигдах шаардлагуудтай үндэслэлгүй холбоогүй функцийг ашиглахыг хориглоно. Зорилго нь Хөгжлийн үе шатны төгсгөлд Баталгаажуулалтын үе шатанд (0.9-р хэсэгт тайлбарласан) бэлэн болсон 5 / CR тодорхойлолтыг бий болгох явдал юм.
Хөгжүүлэлтийн үе шатанд техникийн тодорхойлолт (эсвэл тодорхойлолтыг сайжруулах) гурван секундын дотор урагшилдагtages.

Шинэ техникийн хувьд гурван stages нь:

0.5 Сtage
0.7 Сtage

0.9 Сtage

Тодорхойлолтыг сайжруулахын тулд гурван stages нь:

Сайжруулах саналын баримт бичгийн төсөл (DIPD) С.tage

Сайжруулах саналын эцсийн баримт бичиг (FIPD) Stage
Өөрчлөлтийн хүсэлт (CR) Stage

С бүрtage -ийг дараагийн дэд бүлгүүдэд дэлгэрэнгүй тайлбарласан болно. Доорх зураг 4.1 -д АХ -ны бэлтгэж буй янз бүрийн баримт бичгүүдийг харуулавtage.

Зураг 4.1: Илүүview техникийн тодорхойлолт stagХөгжлийн үе шатанд тохиолддог

Тодорхойлолтыг боловсруулах явцад BARB-ийн үүрэг бол АХ-д зөвлөгөө, техникийн туслалцаа үзүүлэх явдал юм. АЖ-ууд техникийн тодорхойлолтыг боловсруулах, техникийн нөхцөлд ашиглах архитектурын үзэл баримтлалын талаар техникийн зөвлөгөө авахыг хүссэн үедээ BARB-д хүсэлт гаргаж болно. АХ-ууд архитектурын хувьд илүү төвөгтэй шинж чанаруудтай болохын тулд BARB-аас эрт санал авахыг уриалж байна.

4.1 0.5/DIPD Stage

0.5/DIPD -ийн үеэр С.tage, АХ нь [8] -д заасан албан ёсны загваруудыг ашиглан дараахь зүйлийг боловсруулах болно.

Шинэ техникийн хувьд дор хаяж дараахь мэдээллийг агуулсан 0.5 техникийн тодорхойлолтын төсөл.

FRD-д заасан шаардлагыг хангах архитектур

Протоколуудын хувьд үйлчилгээний нэвтрэх цэгүүдийг тодорхойлсон болно
Үйлчилгээ, ил мэдээлэл, зан төлөвийн хувьд
Мэргэжлийн хувьдfiles, протоколыг тодорхойлж, функцийг зааж өгсөн болно

2. Тодорхойлолтыг сайжруулахын тулд дор хаяж дараахь мэдээллийг агуулсан DIPD-ийн төсөлд:

Суурь: Ажлын цар хүрээ, ажлыг удирдан чиглүүлж буй зорилтууд, энэхүү тодорхой санал нь хамрах хүрээтэй хэрхэн нийцэж байгаа талаар
Дууслааview санал: DIPD-ээс өгсөн өргөтгөсөн үйл ажиллагааны хураангуй (нэмэлт уян хатан байдал, сайжруулсан гүйцэтгэл гэх мэт), шинэ функц нь одоогийн техникийн хувилбартай хэрхэн нийцэж байгаа талаархи тодорхой тайлбарыг багтаасан болно. Хэрэв АХ олон саналыг үнэлсэн бол эдгээр саналыг BARB-д давуу эрхийн саналыг сонгоход хангалттай нягт нямбай шалгалт хийсэн эсэхийг тодорхойлох боломжийг олгохын тулд оруулах ёстой.

Шаардлагын хамрах хүрээ: Холбогдох FRD-д заасан системийн зохих шаардлага, ашиглалтын хувилбаруудыг иш татан саналын дагуу өгсөн функциональ шаардлагуудын хамрах хүрээний тойм.
Асуудлын тодорхойлолт: Санал (ууд) -аар шийдвэрлэсэн асуудлын мэдэгдэл
Сонгон шалгаруулалтын шалгуур: Сонгон шалгаруулалтын үйл явцыг удирдан чиглүүлсэн холбогдох үнэлгээний хэмжүүрээс сонгох / гүйцэтгэлийн шалгуур үзүүлэлттэй холбоотой мэдэгдэл

Сонголтын үндэслэл: Саналуудын хоорондох сонголтыг зөвтгөх, харилцан тохиролцоог тодорхойлох үнэлгээний хэмжүүрийг шалгах
Тодорхойлолт: Функциональ байдал, өргөтгөсөн протоколуудын тодорхойлолт. Энэ хэсэг нь холбогдох дэд хэсгүүдийг нэмж өөр өөр хэрэгцээнд дасан зохицож болно.

3. Туршилтын стратеги: Bluetooth -ийн мэргэшүүлэх хөтөлбөрийн хүрээнд туршиж үзэхийг санал болгосон (эсвэл туршиж үзээгүй) функцуудын тодорхойлолт, түүний ажиллагааг хэрхэн туршиж үзэхийг санал болгож байна (жишээ нь, Доод шалгагч (ууд) эсвэл Дээд шалгагч (ууд) дээрх хүлээлт, Хэрэв туршилтыг нийцтэй байдал эсвэл харилцан үйлчлэх туршилт эсвэл хоёуланг нь хослуулсан гэж үзвэл). Энэ нь 0.5/DIPD техникийн тодорхойлолтод тусдаа баримт бичиг эсвэл тусдаа хэсэгт байж болно. Туршилтын стратегид ашиглах дүрмийг Туршилтын стратеги ба нэр томъёонд тайлбарласан болноview баримт бичиг (TSTO) [5].

Энэ баримт бичгийн үндсэн үзэгчидtage бол АХ -ны гишүүд ба BARB юмview архитектурын санал, шаардлагын хамрах хүрээ, мөн BTI -ийг хэнviewтуршилтын стратеги. Ихэнх тохиолдолд энэ баримт бичигtage нь эцсийн тодорхойлолтод оруулахаар төлөвлөсөн текстийг агуулаагүй болно.

BSTS дахин оруулах ёстойview бүх баримт бичгийг Bluetooth боловсруулах удирдамж [1] -тэй нийцүүлж, АХ -ны шийдвэрлэх асуудлыг тодорхойлох. 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 StagCSS, GSS эсвэл MDP -ийн техникийн үзүүлэлтүүдийг сайжруулахад e шаардлагагүй

0.5/DIPD Stage гарах шаардлага

0.5/DIPD Stage дууссан бөгөөд 0.7/FIPD StagДараахь гарах шаардлагыг хангасан тохиолдолд e эхэлнэ.

BSTS дахин дуусгасанview0.5/DIPD -ийн тодорхойлолт ба туршилтын стратеги.

BARB нь 0.5 / DIPD техникийн нөхцлийг батлав.
BTI шинэчилсэн бүртгэлээ хийж дуусгалааview Туршилтын стратеги.
BSTS нь батлагдсан 0.5 / DIPD тодорхойлолтыг Associate and Promoter-ийн бүх гишүүдэд ашиглах боломжтой болгосон.

4.2 0.7/FIPD Stage

0.7/FIPD -ийн үеэр С.tage, АХ нь [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] -д заасны дагуу туршилтын зорилгын жагсаалтаас бүрдсэн Test Suite.
TSTO [5] -д заасны дагуу хэрэгжилтийн нийцлийн мэдэгдэл (ICS).

Тодорхойлолтыг сайжруулахын тулд Test Suite болон ICS-ийг тусад нь баримт бичиг хэлбэрээр эсвэл FIPD-ийн нэмэлт хэсэг болгон өгч болно.

Энэ хэсэгт бэлтгэсэн баримт бичгийн үндсэн үзэгчидtage бол АХ -ны гишүүд ба BARB юмview эцсийн тодорхойлолтод оруулахаар төлөвлөсөн зарим текстийг багтаасан онцлог эсвэл сайжруулалтын талаархи бүрэн тайлбар. BTI бол дахин үзэх үзэгчид юмview туршилтын баримт бичгийн талаар.

BSTS дахин хийх болноview 0.7/FIPD -ийн тодорхойлолт, туршилтын баримт бичгийн шинэ эсвэл өөрчлөгдсөн хэсгүүд нь Bluetooth SIG -ээр тогтоосон хэлний конвенцуудыг багтаасан Bluetooth -ийн зураг төсөл боловсруулах удирдамжтай нийцэж байна. BARB дахин болноview 0.7/FIPD -ийн тодорхойлолт.

BSTS нь АХ-д TSTO [0.7] -ын дагуу 5 / FIPD тестийн баримт бичгийг бэлтгэхэд туслах болно.

BTI дахин хийх ёстойview 0.7/FIPD шалгалтын баримт бичиг. АХ нь 0.7/FIPD -ийн тодорхойлолтыг BTI -д лавлагаа болгон өгөх ёстойview0.7/FIPD туршилтын баримт бичгийг авах бөгөөд үүнийг BTI дахин хийх болноview BTI техникийн тодорхойлолтын дагууview Процесс шалгах хуудас [6].

BARB програмаа дуусгасны дарааview 0.7/FIPD -ийн тодорхойлолт, BTI -ийн шинэчилсэн хувилбарыг дуусгасанview 0.7/FIPD -ийн туршилтын баримт бичгийн BSTS дахин хийх болноviewed 0.7/FIPD -ийн тодорхойлолт нь Associate болон Promoter -ийн бүх гишүүдэд боломжтой.

0.7/FIPD StagCSS, GSS эсвэл MDP -ийн техникийн үзүүлэлтүүдийг сайжруулахад e шаардлагагүй.

0.7/FIPD Stage гарах шаардлага

0.7/FIPD Stage дууссан бөгөөд 0.9/CR S байнаtagДараахь гарах шаардлагыг хангасан тохиолдолд e эхэлнэ.

BSTS дахин дуусгасанview0.7/FIPD -ийн тодорхойлолт, туршилтын баримт бичгийг авах.
BARB дахин дуусгасанview0.7/FIPD -ийн тодорхойлолтыг авах.
BTI дахин боловсрууллааview0.7/FIPD Test Suite (Туршилтын зорилго) ба 0.7/FIPD ICS -ийг ашиглах.
BSTS дахин хийсэнviewed 0.7/FIPD -ийн тодорхойлолт нь Associate болон Promoter -ийн бүх гишүүдэд боломжтой.

4.3 0.9/CR Stage

CR-ийн хоёр төрөл байдаг: Нэгдсэн CR, өмнөх хувилбараас хойш гарсан бүх өөрчлөлтийг харуулсан бүхэлд нь батлагдсан техникийн тодорхойлолтын өөрчлөлтийг хянах баримт бичиг ба товчилсон CR нь зөвхөн нөлөөлөлд өртсөн хэсгүүдийг өөрчлөх зааварчилгаа өгдөг баримт бичиг юм. CR-ийн үндэслэсэн тодорхойлолтын хувилбар.

0.9/CR S үедtage, АХ нь [8] -д заасан албан ёсны загваруудыг ашиглан дараахь зүйлийг боловсруулах болно.

Шинэ техникийн хувьд дор хаяж дараахь мэдээллийг агуулсан 0.9 техникийн тодорхойлолтын агуулгыг бүрэн гүйцэд боловсруулсан төсөл боловсруулах болно.

BARB-re-ээс хойш хийгдсэн бүх өөрчлөлтүүдийн тайлбарviewed 0.7 тодорхойлолт (эсвэл 0.5 тодорхойлолтыг үйлдвэрлэхээс татгалзсан бол 0.7 техникийн тодорхойлолтоос хойш), үүнд шинэ эсвэл
өөрчлөгдсөн санал, сонгон шалгаруулалтын шалгуур, сонголтын үндэслэл. Өөрчлөлтийг 0.5 S -д заасантай ижил нарийвчлалтай тайлбарлах ёстойtage ба 0.7 Stage.

2. Тодорхойлолтыг сайжруулахын тулд:

Наад зах нь дараахь мэдээллийг багтаасан байх ёстой нэгдсэн CR.
BARB-re-ээс хойш хийгдсэн бүх өөрчлөлтүүдийн тайлбарviewed FIPD (эсвэл хэрэв FIPD -ээс татгалзсан бол DIPD -ээс хойш) шинэ эсвэл өөрчилсөн санал, сонгон шалгаруулалтын шалгуур, сонголтын үндэслэл зэргийг багтаасан болно. Өөрчлөлтийг DIPD S -д заасантай ижил түвшинд нарийвчлан тайлбарлах ёстойtage ба FIPD Stage.
Өмнө нь батлагдсан тодорхойлолтод санал болгож буй бүх өөрчлөлтийг өөрчлөлтийг хянах замаар ашиглана уу.
Өмнө нь батлагдсан техникийн тодорхойлолтын хувилбарт хараахан ороогүй өөрчлөлтийг хянах аргыг ашиглан харуулсан бүх алдаатай техникийн алдаанууд (алдаануудын дугаарыг дурдсан тохиолдолд); эсвэл IOP-ийн шинжилгээнд өөрөөр нөлөөлдөг.

3. Эсвэл товчилсон CR, дор хаяж дараахь зүйлийг агуулсан байх ёстой.

BARB-re-ээс хойш хийгдсэн бүх өөрчлөлтүүдийн тайлбарviewed 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 тестийн баримт бичиг:

0.9 / CR тестийн багц, үүнд TSTO [5] -д заасны дагуу агуулгын бүрэн тестийн тохиолдлууд болон холбогдох Тестийн зураглалын хүснэгт (TCMT) багтсан болно.
TSTO [0.9] -д заасны дагуу 5 / CR ICS.
Хэрэв туршилтуудыг тохируулахдаа туршилтын хэрэгжилтэд (IUT) тодорхой параметрүүд шаардлагатай бол 0.9 / CR хэрэгжилтийн eXtra мэдээлэл (IXIT).
0.9 / CR туршилтын тохиолдлын лавлагааны жагсаалт (TCRL) (Core Specification шинэчлэлтүүдийн хувьд заавал биш).

8. 0.9 / CR Test Suite-ийн хүрээнд техникийн тодорхойлолтын аль шаардлагыг шалгасан эсвэл шалгагдаагүйг харуулсан туршилтын хамрах хүрээний шинжилгээ (тодорхойлолтыг сайжруулахын тулд туршилтын хамрах хүрээний шинжилгээнд зөвхөн шинээр нэмсэн, нөлөөлсөн функцийг багтаасан байх ёстой бөгөөд нөлөөлөлд өртөөгүй хэсгүүдийг багтаасан болно. анхны тодорхойлолт).
9. IOP тестийн төлөвлөгөө.

Тодорхойлолтыг сайжруулахын тулд Test Suite, ICS, IXIT-ийг тусад нь баримт бичиг хэлбэрээр эсвэл Товчилсон CR-ийн нэмэлт хэсгүүдээр хангаж болно.

Ихэнх тохиолдолд нэгдсэн буюу товчилсон CR нь техникийн тодорхойлолтын өмнө батлагдсан хувилбар дээр үндэслэсэн байх ёстой, гэхдээ энэ нь хамгийн сүүлийн үеийн завсрын төсөл дээр үндэслэсэн байж болно. Хамгийн сүүлийн үеийн завсрын төслийн тодорхойлолтын хувилбарын дугаар нь баримт бичгийн хувилбартай холбоотой хувилбарын дугаар байх ёстой бөгөөд энэ нь цаг хугацааны явцад өөрчлөгдөхгүй болно. Үгүй бол таних нэмэлт мэдээлэл (баримт бичгийн огноо, а гэх мэт) URL тодорхой "суурь" хувилбарыг тодорхойлохын тулд байнгын байршилд хүргэх ёстой. Хэрэв завсрын ноорог ашигласан бол тухайн CR-ийн өөрчилж буй өгөгдсөн хэсгийн доторх CR-тэй шууд холбоогүй аливаа өөрчлөлтийг оруулах шаардлагатай боловч тэмдэглэгээг ашиглан харуулах шаардлагагүй болно. Хэрэв завсрын төслийн холбогдох хэсгүүдийг дараа нь шинэчилсэн бол CR-ийг завсрын төслийн шинэчлэлтийг тусгаж шинэчлэх шаардлагатай.

Товчлогдсон CR материалыг баталгаажуулалтын үе шатны өмнө иж бүрэн тодорхойлолтын төсөлд тусгаж, туршилтын баримт бичгийг тус тусад нь нэгтгэх боловч эдгээрийг Баталгаажуулах үе эхлэхэд нэгтгэж болно. Хэрэв тодорхойлолтод зориулж олон шинж чанарыг боловсруулж байгаа бол (жишээлбэл, Үндсэн үзүүлэлт), IOP туршилт дууссаны дараа шинж чанаруудыг нэг ноорог болгон нэгтгэх нь зүйтэй болов уу.

BSTS дахин хийх болноview 0.9/CR техникийн тодорхойлолт, туршилтын баримт бичиг нь Bluetooth -ийг боловсруулах удирдамжтай нийцэж байна. Дараа нь BARB дахин болноview 0.9/CR -ийн тодорхойлолт, дараа нь IOP туршилтын төлөвлөгөө (4.3.1 хэсэгт тайлбарласан). 0.9/CR -ийн тодорхойлолтыг АХ -аас BARB -д дахин ирүүлэхээр ирүүлсний дарааview, BSTS нь бүх гишүүдэд дахин нэвтрэх боломжтой болгоноview мөн бэлэн байгаа тухай бүх гишүүдэд мэдэгдэх. Тодорхойлолт боловсруулах явцад энэ үеэс эхлэн БХБГ нь BARB -д ирүүлсэн техникийн тодорхойлолтын төслийг бүх гишүүдэд үе үе мэдэгдэх замаар бүх гишүүдэд хүртээмжтэй болгоно.

Тодорхойлолтыг сайжруулахын тулд АХ нь зөвлөмжийн техникийн шалтгааныг оролцуулан техникийн тодорхойлолтын өмнөх хувилбаруудыг хүчингүй болгох эсвэл буцаан татан буулгах шаардлагатай эсэхийг ТУ-нд санал болгоно.

BARB дахин болноview АХ -ны 0.9/CR техникийн тодорхойлолт нь FRD -д заасан шаардлагад нийцэж байгаа эсэх, аюулгүй байдлын аливаа болзошгүй асуудлууд, зохицуулалтын асуудлууд, Bluetooth архитектуртай нийцэж байгаа эсэх, техникийн үзүүлэлтүүдийг сайжруулахын тулд Хэсэг 3.3.2 -т заасан хоцрогдсон нийцтэй байдлын шаардлагыг хангаж байгаа эсэх. .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 -ийн тодорхойлолтыг баталсны дараа АХХ нь IOP туршилтын төлөвлөгөөг BARB -д дахин оруулахаар илгээдэг.view.

BARB-ээр батлагдсан 0.9 / CR-ийн тодорхойлолтыг IOP-ийн туршилт эхлэх, 0.9 / CR-ийн тодорхойлолтыг бүх гишүүдэд хэвлэн нийтлэхийг зөвшөөрөх зорилгоор ТУЗ-д танилцуулж байна.

Хууль эрх зүйн болзошгүй асуудлуудыг тодруулахын тулд АХ -үүд дахин тодорхойлолт шаардаж болноview Bluetooth SIG -ийн хуулийн зөвлөхөөр (хуульview) заавал дагаж мөрдөх хууль ёсны өмнөview Үрчлэлт/батлах үе шатанд явагддаг. Гэсэн хэдий ч техникийн үзүүлэлтүүдийг сайжруулахын тулд хууль эрх зүйнview Үүнийг нэгдсэн CR дээр хийх ёстой (товчилсон CR -ээс ялгаатай нь) бөгөөд үүнийг нөөц бололцоог бүрдүүлэхийн тулд аль болох урьдчилан төлөвлөх ёстой.

IOP тестийн төлөвлөгөө

АХ нь IOP туршилтын арга хэмжээнд баталгаажуулалтын үе шатанд ашиглахын тулд доор тодорхойлсон бүх шаардлагыг хангасан байх ёстой IOP тестийн төлөвлөгөө боловсруулна. АХ -үүд IOP тестийн төлөвлөгөөгөө дахин BARB -д ирүүлэх ёстойview IOP тестийн үйл явдал эхлэхээс өмнө. Техникийн тодорхойлолтыг сайжруулахын тулд (ялангуяа Туршилтын багцад туршилтын тохиолдлыг өөрчлөх, нэмэх шаардлагагүй) IOP тест хийх шаардлагагүй байж магадгүй бөгөөд АХ нь тодорхойлсон процессыг ашиглан IOP тестээс татгалзах хүсэлтийг BARB -д гаргаж болно. 4.4 -р хэсэгт.

IOP тестийн төлөвлөгөөнд дараахь зүйлийг багтаасан байх ёстой.

Бүх шинэ заавал, нэмэлт, нөхцөлт шинж чанаруудыг шалгахын тулд хэргийг туршиж үзээрэй
Оп код бүрийн хувьд дор хаяж нэг туршилтын тохиолдол
Параметр бүрийн хувьд дор хаяж нэг туршилтын тохиолдол
Багцын төрөл тус бүрт дор хаяж нэг туршилтын тохиолдол
Бүх сайжруулсан функцэд 3.3.2-т жагсаасан шаардлагыг хангахын тулд тодорхойлолтыг сайжруулах арын тохирох тестийн тохиолдлууд (мөн Хэсэг 4.3.1.1-ийг үзнэ үү).
IUT нь тодорхойлогдсон мужаас гаднах утга эсвэл хүчин төгөлдөр бус эсвэл гэнэтийн гэж тооцогдох зан үйлийн талбарт өртсөн тестийн тохиолдол (Хүчин төгөлдөр бус зан байдлын тестийн тохиолдол). PTS эсвэл бусад туршилтын хэрэгсэл гэх мэт шалгагч нь аливаа хүчин төгөлдөр бус үйлдлийг санаачлагч байх болно гэж найдаж байна.
Хэсэг 4.3.1.2-т заасны дагуу IOP туршилтын арга хэмжээнд ашиглах түр зуурын хуваарилагдсан дугааруудыг (BSTS-тэй уялдуулж удахгүй болох IOP туршилтын арга хэмжээнүүд давхцахгүй байх үүднээс сонгосон).
Хэсэг 4.3.1.3-т тодорхойлсон хамрах хүрээний шаардлагыг харгалзан туршилтын тохиолдол бүрийг давах шаардлагатай шаардлагатай бие даасан хэрэгжилтийн тоог тодорхойлох.
АХ-аас хасах шаардлагатай гэж үзсэн Тестийн цуглуулга дахь туршилтын тохиолдлыг тодорхойлж, тэдгээрийг хасах үндэслэл. Үүнд ихэвчлэн орно: • Ирээдүйн нотолгооны туршилтын тохиолдлууд (жишээлбэл, нэмэлт шинж чанарууд, өргөтгөл шинж чанарууд эсвэл Ирээдүйд ашиглахад зориулж нөөцлөгдсөн (RFU) бит эсвэл талбар ашиглах гэх мэт ирээдүйн боломжит нэмэлтүүдийг багтаах боломжтой нийтлэг тестүүд)
• Бусад орсон тестүүдийн дэд хэсэг болох тестийн тохиолдлууд
• Өөр хэд хэдэн техникийн нөхцлөөр ажилладаг тестүүдтэй бараг ижил ерөнхий тестийн тохиолдлууд (жишээлбэл, нийтлэг алдааны кодыг өдөөх)
• Өөр тээврийн хэрэгслээр дамжин өнгөрөх туршилтын тохиолдлуудтай ижил туршилтын тохиолдлууд (жишээлбэл, LE тестийн тохиолдолтой төстэй BR / EDR тестийн тохиолдол)
• Хэрэгжилтийн бат бөх эсвэл стресс тест

IOP тестийн төлөвлөгөөнд IOP тестийн өвөрмөц тестийг багтааж болно, жишээлбэл хэрэглэгчийн ердийн сценарийг санагдуулж болох илүү төвөгтэй дарааллыг нэгтгэсэн төгсгөлийн төгсгөлийн тестийн тохиолдол гэх мэт.

IOP тестийн төлөвлөгөөг BARB батлах шаардлагагүй боловч (IOP тестийн төлөвлөгөө цаашид өөрчлөгдөж сайжрах болно гэдгийг ойлгосноор), IOP тестийн тайланг BARB зөвшөөрөх шаардлагатай (5.1.1 хэсгийг үзнэ үү) . Хэрэв IOP тестийн төлөвлөгөө нь 4.3.1-р хэсэгт тодорхойлсон бүх шаардлагыг хангаагүй бол АХ нь IOP-ийн туршилтын үйл явц (ууд) эхлэхээс өмнө BARB-д мэдэгдэж байсан аливаа хэлбэлзлийн хураангуй болон дисперс бүрийн үндэслэлийг танилцуулах ёстой.

IOP тестийн төлөвлөгөө, туршилтын тохиолдлууд нь үндсэндээ холбогдох тодорхойлолтын тестийн баримт бичгийн агуулгад үндэслэсэн байх ёстой.

IOP тестийн үйл явдлыг үр дүнтэй болгохын тулд АХ нь IOP-ийн тестийн төлөвлөгөө болон холбогдох бүх тестийн тохиолдлуудыг бөглөж, IOP-ийн анхны туршилтаас нэгээс доошгүй сарын өмнө хэрэгжүүлэгчид ашиглах боломжтой байх ёстой.

Тохиромжтой байдлыг хойшлуулах тест хийхээр төлөвлөж байна
Тодорхойлолтыг сайжруулахын тулд хоцрогдсон нийцтэй байдлын IOP тест нь техникийн бүх идэвхтэй болон хуучирсан хувилбаруудын эсрэг баталгаажуулалтыг авч үзэх ёстой, учир нь Bluetooth бүтээгдэхүүнүүдэд түгээмэл хэрэглэгддэг техникийн үзүүлэлтүүд болон функцууд нь маш урт хугацааны үйлчилгээтэй байж болно (жишээлбэл, тээврийн хэрэгсэл). Ажлын хэсэг нь аль хувилбарыг туршиж үзэх, ямар туршилт хийх зэрэг шаардлагатай нийцсэн туршилтын зохих түвшинг шинжлэх ёстой бөгөөд энэхүү шинжилгээг BARB -д өгөх ёстой. BARB дахин хийх ёстойview АХ -ны IOP туршилтын төлөвлөгөөнд оруулах өөрчлөлтийг (хэрэв байгаа бол) дүн шинжилгээ хийж, санал болгох.

Ухаж буй нийцлийн тестэд оролцож буй гишүүдийг өмнөх техникийн хувилбар (ууд) -ын шаардлага хангасан хуучин төхөөрөмжүүдийг авчрахыг уриалж байна. АХ нь IOP-ийн туршилтын тайлан дахь нийцтэй байдлын доголдлыг мэдээлэх ёстой. Гишүүн компаниудыг IOP туршилтын арга хэмжээ болох газраас гадуур өөрийн лабораторид арын нийцлийн туршилтыг хийж, тодорхойлолттой холбоотой асуудлуудыг АХ-д мэдээлэхийг уриалж байна.

IOP тест хийхэд ашигласан түр олгосон дугаарууд
IOP-ийн туршилтын арга хэмжээнд ашиглах хуваарьт дугаарын түр хуваарилалтыг зохицуулахын тулд BSTS ба BARB-тэй зөвлөлдөх шаардлагатай бөгөөд ингэснээр бусад техникийн үзүүлэлтүүдтэй давхцахгүй, зөрчилдөхгүй. Эдгээр түр зуурын утгыг IOP-ийн туршилтын төлөвлөгөөнд тусгасан байх ёстой бөгөөд батлагдсан техникийн тодорхойлолтод ашиглах хуваарилалт өгөхгүй.

Нэг буюу хэд хэдэн шинэ 16-битийн UUID утгыг санал болгож буй IOP тестийн хувьд 0x7F00-ээс 0x7FFF хүртэлх утгыг IOP-ийн туршилтанд зориулж хадгална.

Нэг буюу хэд хэдэн шинэ Fixed Protocol Service Multiplexer (PSM) утгыг санал болгож буй IOP тестийн хувьд үндсэн тодорхойлолтод заасны дагуу 0x0000-аас 0x007F хүртэлх хүчинтэй хязгаарын төгсгөлөөс эхлэн утгыг ашиглана.

Хамрах хүрээний шаардлага
АХ нь BARB-д бие даасан хэрэгжилтийн шаардагдах тоог (дараах хэсгүүдэд тайлбарласны дагуу) туршилтын тохиолдол бүрт тэнцсэн болохыг нотлох баримт өгөх ёстой. Шаардлагатай тооны бие даасан хэрэгжилтээс үл хамаарах АХ-ын аливаа хүсэлтийг BARB-д ирүүлсэн IOP тестийн төлөвлөгөөнд тусгасан байх ёстой.

Баталгаажуулалттай холбоотой бүх хэсгүүдийг бие даан, өөрөөр хэлбэл өөр өөр багуудаар боловсруулсан (өөр өөр компаниудаас заавал ирэхгүй байх ёстой) бол хэрэгжилтийг бие биенээсээ хараат бус гэж үздэг. BSTS нь үл мэдэгдэх байдал, хэрэгжилтийн нууцлалыг хадгалахын тулд анхны загварыг бие биенээсээ хараат бус гэж үзэж болох эсэхийг үнэлэхэд тусалж болно.

Туршилтын хэрэгслүүд, түүний дотор PTS нь бие даасан хэрэгжилт гэж тооцогдохгүй болохыг анхаарна уу.

Гол тодорхойлолт IOP-ийн хамрах хүрээ
Гол тодорхойлолтын шинж чанар нь дүр бүр нь нэг буюу хэд хэдэн өөр үүрэг гүйцэтгэж эсвэл өөртэйгөө харилцан ажиллахаар төлөвлөгдсөн нэг буюу хэд хэдэн дүрийг тодорхойлдог.

Бие биетэйгээ хамтран ажиллахаар төлөвлөсөн хос үүрэг тус бүрийн хувьд дор хаяж гурван бие даасан хэрэгжилтийг харилцан гүйцэтгэсэн гурван бие даасан хэрэгжилттэй хамтран ажиллахыг харуулсан байх ёстой.

Ижил дүрээр өөр төхөөрөмжтэй хамтран ажиллах боломжтой үүрэг тус бүрийн хувьд дор хаяж гурван бие даасан хэрэгжилт нь тухайн дүрээрээ бие биетэйгээ харьцаж болохыг харуулах ёстой.

Үйлчилгээний тодорхойлолт IOP хамрах хүрээ
Дор хаяж гурван бие даасан үйлчилгээний хэрэгжилт нь дор хаяж нэг үйлчлүүлэгчийн хэрэгжилттэй хамтран ажиллахаа харуулах ёстой бөгөөд энэ нь PTS байж болно.

Profile болон протоколын тодорхойлолт IOP -ийн хамрах хүрээний шаардлага
Profile протоколын тодорхойлолтууд нь дүр бүр нь нэг буюу хэд хэдэн үүргийг өөрөөрөө эсвэл өөртэй нь хамтран ажиллахаар бүтээгдсэн байдаг.

Бие биетэйгээ хамтран ажиллахаар төлөвлөсөн хос үүрэг тус бүрийн хувьд дор хаяж хоёр бие даасан хэрэгжилт нь нэмэлт үүргийн хоёр бие даасан хэрэгжилттэй харилцан үйлчилж байгааг харуулах ёстой.

Ижил дүрээр өөр төхөөрөмжтэй хамтран ажиллах боломжтой үүрэг тус бүрийн хувьд дор хаяж гурван бие даасан хэрэгжилт нь тухайн дүрээрээ бие биетэйгээ харьцаж байгааг харуулах ёстой.

Загварын тодорхойлолт IOP хамрах хүрээ
Дор хаяж гурван бие даасан серверийн загвар эсвэл хяналтын загварын хэрэгжилт нь дор хаяж нэг үйлчлүүлэгчийн хэрэгжүүлэлттэй (өөрөөр хэлбэл PTS байж болно) харилцан ажиллахаа, дор хаяж нэг үйлчлүүлэгчийн загвар хэрэгжилт нь дор хаяж нэг серверийн загвар хэрэгжүүлэлт болон PTS-тэй харилцан үйлчилж байгааг харуулах ёстой.

Хувилбарын хувилбарын дугаарлалт

0.9/CR S үедtagд, АХ нь батлахдаа техникийн тодорхойлолтод хэрэглэх хувилбарын дугаарыг Удирдах зөвлөлд танилцуулах зөвлөмжийг бэлтгэх ёстой.

Техникийн үзүүлэлтүүдийн хувилбарууд нь хоёр төрөлд хуваагдана: бүрэн хувилбарууд, үүнд шинэ буюу шинэчлэгдсэн функцууд, засвар үйлчилгээний хувилбарууд (мөн "цэг-Z хувилбарууд" гэж нэрлэдэг), эдгээр нь техникийн болон редакторийн алдааг нэгтгэсэн боловч шинэ, шинэчлэгдээгүй болно. онцлог шинж чанарууд. Бүрэн хувилбарын хувилбарууд нь XY хэлбэрийн 2.1, 5.0 зэрэг хоёр хэсэгтэй дугаартай байдаг бол засвар үйлчилгээний хувилбарууд 2.1.2 гэх мэт XYZ хэлбэрийн гурван хэсэгтэй дугаартай байдаг. Z-ийн утга 0 байж болохгүй.

Аливаа хоёр хувилбарын хувьд нэгийг нь "дээд хувилбар", нөгөөг нь "доод хувилбар" гэж нэрлэдэг. Үүнийг дараах дүрмийн дагуу тодорхойлно.

Хэрэв X бүрэлдэхүүн хэсгүүд хоорондоо ялгаатай байвал X-ийн утга өндөр нь "өндөр хувилбар" болно.
Хэрэв X бүрэлдэхүүн хэсгүүд ижил боловч Y бүрэлдэхүүн хэсгүүд хоорондоо ялгаатай байвал Y-ийн утга ихтэй хэсэг нь “өндөр хувилбар” болно.
Хэрэв XY бүрэлдэхүүн хэсгүүд ижил боловч Z бүрэлдэхүүнүүд хоорондоо ялгаатай байвал Z-ийн утга ихтэй хэсэг нь “өндөр хувилбар” болно. Хоёр хэсэг бүхий XY дугаарыг энэ зорилгоор гурван хэсэгтэй XY0 тоо гэж үздэг.

Жишээ ньample, дараах хувилбаруудын дугаарууд нь хамгийн бага хувилбараас хамгийн өндөр хувилбар хүртэл байх болно: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. CSS -ийн хувьд шинэчлэлт бүр хувилбарын дугаарын зөвхөн X бүрэлдэхүүн хэсгийг нэмэгдүүлдэг.

BoD батлах урьдчилсан нөхцөл
Техникийн тодорхойлолтыг боловсруулах үе шатны төгсгөлд 0.9 / CR тодорхойлолтыг ТУЗ-д батлуулахаар хүргүүлэхээс өмнө дараахь шаардлагыг хангасан байх ёстой.

АХ туршилтын хамрах хүрээний шинжилгээг хийж дуусгасан.
BSTS дахин дуусгасанview0.9/CR техникийн тодорхойлолт, туршилтын баримт бичгийг авах.
BARB нь 0.9 / CR тодорхойлолтыг батлав.
BARB нь техникийн тодорхойлолтын Товчилсон CR-д суулгаж болох CSS CR-ийг (хэрэв тодорхойлолтод шинэ бичилт хийх шаардлагатай бол) батлав.
BARB нь GSS CR ба MDP CR-ийг батлав (хэрэв техникийн нөхцлөөр шинэ бичлэг оруулах шаардлагатай бол).
BTI нь 0.9/CR Test Suite, ICS, TCRL -ийг IXIT -тэй хамт (IXIT нь Test Suite -ийн туршилтыг хийхэд шаардлагатай бол) баталсан. Энэ тохиолдолд TCRL нь заавал биш юмtage -ийн үндсэн үзүүлэлтүүдийн шинэчлэлтийг авах.
АХХ нь IOP тестийн төлөвлөгөөгөө дахин BARB -д хүргүүлсэнview (хэрэв туршилтыг BARB -аас татгалзахгүй бол).

ТХ-нд танилцуулсан баримт бичигт BARB-ээр батлагдсан 0.9 / CR тодорхойлолтыг багтаасан байх ба ТХ-нд танилцуулга нь дараахь зүйлийг агуулсан байх ёстой.

IOP тестээс татгалзах тухай мэдэгдсэн аливаа хүсэлт эсвэл Хэсэг 4.3.1-д тодорхойлсон аливаа шаардлага
Тодорхойлолтыг дэмжиж буй тээврийн жагсаалт (жишээлбэл, BR / EDR, LE гэх мэт)
Тодорхойлолтыг сайжруулахын тулд АХ-аас шаардаж буй нийцтэй байдлын шаардлагуудаас чөлөөлөх (Хэсэг 3.3.2-т тайлбарласан болно).
Тодорхойлолтыг сайжруулахын тулд АХ-аас хувилбарын дугаарыг батлагдсан тодорхойлолтод хэрэглэх зөвлөмжийг өгөх болно
Тодорхойлолтыг сайжруулахын тулд АХ-ын батлагдсан техникийн тодорхойлолтын өмнөх хувилбар (ууд) -ын ашиглалтын хугацаа дуусах үеийн зөвлөмж, түүний дотор техникийн тодорхойлолтуудын өмнөх хувилбарыг цуцлах, цуцлахыг зөвлөдөггүй техникийн үндэслэл, үндэслэлийг оруулна. зөвлөмжийн хувьд
BARB эсвэл BTI -ийн гишүүдээс шийдвэрлэгдээгүй аливаа ноцтой асуудал (жишээлбэл, зөвшөөрлийн явцад ямар ч санал өгөхгүй байх шалтгаан, дахин санал хураалтын үр дүнд үүссэн асуудал)view туршилтын баримт бичиг, эсвэл 0.9/CR -ийн тодорхойлолт нь FRD эсвэл дүрмийн хамрах хүрээнээс гадуур байгаа эсэх)
Pro -ийн бэлтгэл байдалfile BSTS -ийн бэлтгэсэн Tuning Suite (PTS) эсвэл үрчлэхтэй холбоотой бусад шаардлагатай хэрэгслүүд

БХ нь 0.9 / CR тестийн баримт бичгийг батлахаас өмнө болон АХ IOP тестийн төлөвлөгөө нь 2-т тодорхойлсон шаардлагыг хангасан болохыг АХ баталгаажуулахаас өмнө Дүрмийн дагуу [0.9] IOP туршилтын 4.3.1 / CR тодорхойлолтыг батлахаар сонгож болно. 0.9. BoD нь 0.9 / CR тестийн баримт бичгийг BTI баталсны дараа IOP тестийн XNUMX / CR тодорхойлолтыг баталж болно.

0.9/CR Stage гарах шаардлага
0.9/CR Stage дууссан бөгөөд баталгаажуулалтын үе шат нь Удирдлагын зөвлөл IOP туршилтыг эхлүүлэхийг зөвшөөрснөөр эхэлнэ.

4.4 Тодорхойлолтыг боловсруулах процессоос татгалзах

АХ нь дараахь үйл явцын нэг буюу хэд хэдэн алхамаас татгалзахыг хүсч болно:

0.5/DIPD Stage
0.7/FIPD Stage
Баталгаажуулалтын үе шатны хүрээнд IOP тест хийх

Ажлаас чөлөөлөгдөх хүсэлт гаргахын тулд АХХ нь Bluetooth SIG [8] -аас өгсөн үйл явцаас чөлөөлөх загварыг ашиглаж, дахин гаргах шаардлагатай хороо бүрт (өөрөөр хэлбэл BARB эсвэл BTI) чөлөөлөх хүсэлтийг илгээх ёстой.view эсвэл техникийн тодорхойлолтын төсөл эсвэл холбогдох туршилтын баримт бичгийг stagАХ -аас татгалзах санал тавьсан бөгөөд эдгээр хороо тус бүр татгалзах хүсэлтийг батлах ёстой.

Оруулах хүсэлтэд дараахь зүйлийг багтаасан байх ёстой.

S -ийн таних тэмдэгtagАХ -аас татгалзахыг хүсч буй e (s)
Яагаад сtage (s) -ээс татгалзах ёстой
Дахин бүртгүүлэх шаардлагатай хороо бүрийн тодорхойлолт (өөрөөр хэлбэл BTI ба/эсвэл BARB)view мөн чөлөөлөх хүсэлтийг зөвшөөрнө

Энэхүү чөлөөлөлтийг хэлэлцэж буй хороо нь чөлөөлөх хүсэлтийг шийдвэрлэхээс өмнө АХ-ийн төлөөлөгчөөс SMPD процессоос чөлөөлөгдсөнийг зөвтгөх танилцуулга хийхийг шаардаж болно.

Хэрэв олон алхамаас татгалзахыг хүссэн хүсэлтээс татгалзаж, нэг хэсэг нь татгалзаж, хэсэг нь батлагдвал хорооны хариу нь чөлөөлөх хүсэлтийн аль шатыг баталж, аль нь татгалзсаныг зааж өгөх ёстой. Хэрэв татгалзах хүсэлтийг татгалзсан тохиолдолд татгалзсан мэдэгдэлд татгалзсан шалтгааныг багтаасан байх ёстой.

5. Баталгаажуулалтын үе шат

Баталгаажуулалтын үе шатанд АХХ нь 0.9/CR тодорхойлолт дээр IOP туршилтыг хийж, BARB -ийн IOP тестийн тайланг хүргэх болно.view ба зөвшөөрөл. Боломжтой бол техникийн үзүүлэлтүүдийн сайжруулалтын IOP туршилтыг нэгдсэн техникийн тодорхойлолтын эсрэг хийх ёстой. Үүнээс гадна гишүүн Review, Дүрэм [2] -д заасны дагуу энэ үе шатанд эхэлдэг.

Хэрэв техникийн тодорхойлолт (эсвэл сайжруулалт) нь IOP тест хийхийг шаарддаггүй бол Баталгаажуулалтын үе шат дахь IOP-ийн шалгалтаас Хэсэг 4.4-т тайлбарласан үйл явцыг ашиглан татгалзаж болно.

IOP тест хийх явцад (энэ нь нэг буюу хэд хэдэн үйл явдал байж болно) АХХ нь Bluetooth SIG -ийн асуудлыг хянах системийг ашиглан асуудлыг хянаж, төслийн тодорхойлолт, туршилтын баримт бичиг, IOP туршилтын төлөвлөгөөний шинэчлэлтийг оруулахын тулд давтах ёстой. IOP тест дууссаны дараа АХ нь бүх асуудлыг шийдвэрлэхийн тулд техникийн тодорхойлолт, туршилтын баримт бичгийн төслийн шинэчлэлтийг хийж, IOP тестийн тайланг бэлтгэн BARB -д дахин өгөх ёстой.view ба зөвшөөрөл. Үүнийг Зураг 5.1 -д үзүүлэв.

Баталгаажуулах үе шатанд хэд хэдэн үйл ажиллагаа эхэлж болно. Эдгээр үйл ажиллагаа зэрэгцэн явагдах ба дараахь зүйлийг багтааж болно.

ГХБ-аас баталсан 0.9/CR-ийн тодорхойлолтыг BSTS гишүүн бүх гишүүдэд танилцуулж, гишүүнчлэлийг эхлүүлэх тухай мэдэгдсэн болно.view дүрэмд заасан хугацаа.
Шаардлагатай аливаа шинэчлэлийг CSS-т оруулсан болно (тэдгээрийг тодорхойлолтын товчилсон CR-д суулгаж болно).
Онцлог шинж чанар эсвэл тодорхойлогч тодорхойлолтыг GSS техникийн тодорхойлолт, IOP тестийн PTS-т оруулсан болно.
Mesh property тодорхойлолтыг MDP-ийн тодорхойлолт, IOP-ийн туршилтын PTS-т оруулсан болно.
BSTS нь IOP тест хийхэд бэлтгэх зорилгоор IOP платформыг бүртгэх, үр дүнг оруулах хэрэгслийг идэвхжүүлдэг.
Шаардлагатай бол IOP-ийн шинжилгээ (Хэсэг 5.1-ийг үзнэ үү).
Review IOP тестийн үр дүнд оруулсан сэтгэгдлүүд болон асуудлуудыг боловсруулж, техникийн тодорхойлолтын төсөлд оруулсан болно.

5.1 IOP тест

IOP тестийн гол зорилго нь техникийн тодорхойлолтыг жишээ нь баталгаажуулах явдал юмample, текст доторх нарийвчлал, ойлгомжгүй байдлыг шалгах, дахинviewдизайны үндсэн алдаа, дутагдалыг олж тогтоох, техникийн тодорхойлолтыг боловсруулах явцад өмнө нь боловсруулсан урьд өмнө тогтоосон шаардлагуудын дагуу баталгаажуулалт хийх. IOP тест нь төслийн тодорхойлолтод өөрчлөлт оруулах бөгөөд шаардлагатай бүх туршилтыг дуусгахын тулд IOP туршилтын олон арга хэмжээ шаардлагатай байж магадгүй юм.

АХ -ны гаднах гишүүдэд бие даасан шалгалт өгдөг тул IOP шинжилгээнд хамрагдах боломжийг олгох нь чухал юм view төслийг боловсруулсан АХ -ны гишүүдэд ойлгомжгүй байж болох тодорхой бус талбаруудыг илрүүлж чадна. IOP туршилтын арга хэмжээ бүрийн өмнө BSTS нь үйл явдлын дэлгэрэнгүй мэдээлэл, хамгийн сүүлийн ноорог тодорхойлолт, Test Suite, IOP тестийн төлөвлөгөөг бэлэн болгож, бүх гишүүдэд арга хэмжээ болохоос нэг сарын өмнө хамгийн сайн мэдэгдэх болно. IOP тестийн арга хэмжээнд ашигласан шинэчилсэн ноорог тодорхойлолт, Test Suite, IOP тестийн төлөвлөгөө нь арга хэмжээ бүрийн өмнө дор хаяж нэг долоо хоногийн өмнө бэлэн байх ёстой.

IOP туршилтын үеэр платформуудын хос хослолууд нь тестийг хийхийг оролдох бөгөөд IOP тестийн оролцогчид тест, шалгалтын дүнгийн давсан / бүтэлгүйтсэн дүнг тэмдэглэнэ. Эдгээр үр дүнгийн нэрээ нууцалсан хураангуйг (жишээлбэл, "Платформ А", "Платформ Б" гэх мэт) болон бусад тайлбарыг IOP тестийн арга хэмжээний үеэр цуглуулж, АШ-ын гишүүдэд IOP-ийн үеэр болон дараа нь танилцуулах болно. туршилтын арга хэмжээ. IOP тестийн үеэр гарсан аливаа тайлбар, алдаа дутагдлын талаар илүү сайн ойлголттой болохын тулд нэмэлт мэдээлэл шаардлагатай бол BSTS нь илгээгч гишүүнээс нэмэлт мэдээлэл цуглуулах зуучлагчийн үүрэг гүйцэтгэж болно.

Боломжтой бол Host Controller Interface (HCI) дээрх бүх давхаргын платформ бүхий IOP туршилтыг дэмжихийн тулд PTS-ийг шинэчилж, эдгээр давхаргын туршилтын арга хэмжээнд оролцох хэрэгтэй. Туршилтын бусад арга хэрэгсэл нь IOP тестийн арга хэмжээнд оролцож болно. PTS эсвэл бусад туршилтын хэрэгслээр хийсэн туршилтын үр дүнгийн хураангуйг (хэрэв байгаа бол) IOP тестийн тайланд оруулах ёстой.

IOP туршилт нь анхны загварыг хэрэгжүүлэхийг хүссэн бүх гишүүдэд нээлттэй байх болно, гэхдээ Bluetooth SIG нь Bluetooth SIG-тэй гэрээ байгуулах (оролцоо ба нууцлалын гэрээг оруулаад) оролцох болзлыг тавьж болно. АХ нь IOP туршилтын явцад илэрсэн асуудлыг боловсруулах, шийдвэрлэх, нөлөөлөлд өртсөн баримт бичгийг шинэчлэх үүрэгтэй; АХ-аас баталсан өөрчлөлтийг IOP-ийн туршилтын арга хэмжээ бүрт ашиглах техникийн тодорхойлолтын төсөл, туршилтын баримт бичгийн шинэчлэлт болгон оруулах ёстой.

Баталгаажуулалтын үе шат эхлэхээс өмнө АХ -ууд зөвхөн АХ-ны гишүүдэд нээлттэй арга хэмжээнд IOP-ийн урьдчилсан туршилтыг хийж болох боловч албан бус туршилтын үр дүнг IOP-ийн шинжилгээний хариунд оруулахгүй байж болно.

IOP туршилтыг эхлүүлэхээр төлөвлөсөн IOP-ийн огноо, байршлыг багтаасан IOP-ийн анхны туршилтын өмнөх бүх алхамыг дагаж мөрдөж магадгүй юм, гэхдээ BoD-ийн зөвшөөрлийг туршилтын арга хэмжээ эхлэхээс өмнө баталгаажуулаагүй байсан. Энэ тохиолдолд BoD нь IOP-ийн туршилтыг эхлүүлэхээр BoD-ээс зөвшөөрөл авахаас өмнө цуглуулсан туршилтын үр дүнг оруулахыг зөвшөөрч болох бөгөөд хэрэв цуглуулсан үр дүн нь ижил тодорхойлолт, Test Suite-ийг BoD-ээр батлуулсны үндсэн дээр хийгдсэн бол.

CSS, GSS эсвэл MDP техникийн үзүүлэлтүүдийг сайжруулахын тулд IOP тест хийх шаардлагагүй.

IOP туршилтын тайлан
IOP туршилт дууссаны дараа АХХ нь шаардлагатай тооны бие даасан платформ шаардлагатай туршилтыг давсан болохыг харуулах зорилгоор IOP тестийн тайланг BARB -д ирүүлэх ёстой. BARB дахин хийх ёстойview IOP тестийн тайланг батлах эсвэл татгалзах, мөн санал хураалтын төслийн тодорхойлолтын багцыг Удирдах зөвлөлд оруулахаас өмнө нэмэлт IOP тест хийх шаардлагатай бол АХ -д мэдэгдэх болно. BSTB болон АХ нь тайланг BARB-д оруулахаас өмнө IOP туршилтын тайланд гишүүдийг таних мэдээлэл гараагүй байх ёстой.

IOP тестийн тайланд дараахь зүйлийг багтаасан байх ёстой.

Баталгаажуулалтын үе шатанд гарсан бүх IOP туршилтын үйл явдлын жагсаалт, тэдгээрийн огноо, байршлыг багтаасан болно.
PTS ашигласан эсэх зэрэг IOP арга хэмжээ бүрт оролцсон гишүүн компаниудын тоо, бие даасан платформууд.
Арга хэмжээ бүрт ашигласан техникийн тодорхойлолт, Test Suite, IOP тестийн төлөвлөгөөний хувилбаруудын жагсаалт.
Бүх туршилтын тохиолдлууд хамгийн бага нэвтрэх шалгуурыг хангаж байгаа эсэхийг харуулсан гүйцэтгэх хураангуй.
4.3.1-р хэсэгт тодорхойлсон IOP туршилтын төлөвлөгөөний шаардлагуудаас гарсан зөрчлүүдийн хураангуй ба хэлбэлзэл бүрийн үндэслэл.
Test Suite-ийн туршилтын тохиолдлуудын PTS-ийн хамрах хүрээ.
IOP тестийн төлөвлөгөөнөөс авсан бүх тестийн тохиолдлуудын жагсаалт (үүнд нийцсэн тестүүд орно), шалгалтын тэнцсэн тоо, туршилтын алдааны тоо, тестийн тохиолдлуудад хамгийн бага шалгуур хангасан эсэх, яагаад шаардлага тавиагүйг тайлбарласан болно. уулзав.
Үйл явдал бүрийн асуудал, сэтгэгдэл, асуултуудын хураангуй (тэдгээрийг оруулаад) filed IOP туршилтын явцад техникийн тодорхойлолтын эсрэг) болон техникийн үзүүлэлт, туршилтын баримт бичигт үзүүлэх нөлөөллийн эсрэг.

5.2 Баталгаажуулалтын үе шатанд гарах шаардлага

Баталгаажуулалтын үе шат дууссан бөгөөд BARB нь IOP-ийн туршилтын тайланг баталж (тестийг BARB-ээс чөлөөлөөгүй бол) батлах / үрчлэх үе шат эхэлнэ.

BSTS нь баталсан 0.9/CR -ийн тодорхойлолтыг гишүүн гишүүдийн бүх гишүүдэд ашиглах боломжтой болгосонview Дүрэмд заасны дагуу бүх гишүүдэд бэлэн байгаа тухай мэдэгдсэн болно.
IOP туршилтын явцад тогтоогдсон, туршилтын нөлөө бүхий бүх асуудлыг нэгтгэж, туршиж үзсэн болно.
АХ нь IOP-ийн туршилтыг хийж дууссан (туршилтыг BARB татгалзаагүй бол).

6. Батлах / батлах үе шат

Үрчлүүлэх/батлах үе шатанд тодорхойлолт, холбогдох туршилтын баримт бичгийг эцэслэн боловсруулж, BARB, BQRB, BTI -ийн зөвшөөрлийг хүлээн авч, үрчлүүлэх огнооны талаар мэдэгдэл гаргаж, батлахын тулд Удирдах зөвлөлд өгсөн техникийн төслийн эцсийн хувилбарыг гаргана. Саналын төсөл), мөн эцсийн техникийн багцыг Удирдах зөвлөлд хүргүүлнэ. Re гишүүний хамгийн бага хугацаа дууссаны дарааview Дүрэмд заасан [2]) шаардлагыг хангасан тохиолдолд Удирдах зөвлөл нь үрчлэлтийн огноонд батлах тодорхойлолтыг авч үзэх болно. Хүлээн авсны дараа тодорхойлолтыг нийтэлж, мэргэшлийн системийг идэвхжүүлнэ. Хүүхэд үрчлэх/батлах үе шатыг Зураг 6.1 -д үзүүлэв.

6.1 Санал хураалтын төсөл

Санал хураалтын төслийг шаардлагатай техникийн нөхцлийн баримт бичигт шинэчлэлтүүдийг (Баталгаажуулалтын үе шатанд оруулсан) тусгаж, шинэ техникийн тодорхойлолтын эцсийн төслийг бэлтгэх замаар бий болгодог. Тодорхойлолтыг сайжруулахын тулд BSTS нь баталгаажуулалтын үе шатнаас өмнө дуусаагүй бол нэг буюу хэд хэдэн CR (s) -ийг өмнө нь батлагдсан техникийн тодорхойлолтын дээд хувилбарт нэгтгэх замаар нэгдсэн тодорхойлолтыг бий болгоно (Хэсэг 4.3.2-ийг үзнэ үү).

Хэрэв энэ үе шатанд техникийн тодорхойлолтод өөрчлөлт орсон бол АХ, BARB, эсвэл BTI нь аливаа өөрчлөлтөнд нэмэлт IOP туршилт хийх шаардлагатай болохыг тогтоовол тухайн үзүүлэлт нь нэмэлт туршилтыг хийх АХ-ны Баталгаажуулалтын үе шатны IOP туршилтын хэсэг рүү буцах болно. Хүүхэд үрчлэх / батлах үе шатанд дараахь баримт бичгийг бүрдүүлж, үрчлэгдсэн өдрөөс өмнө ТХ-нд танилцуулах болно.

Санал хураалтын төсөл
Холбогдох техникийн тодорхойлолт (эсвэл сайжруулах) төрөлд шаардагдах бүх дэмжлэгийн тодорхойлолтыг (өөрөөр хэлбэл CSS, GSS, MDP)
Тодорхойлолтыг сайжруулахын тулд Санал авах төсөлд санал болгож буй өөрчлөлтийг харуулсан батлагдсан тодорхойлолтын хувилбарын өөрчлөлтийг дагаж мөрдөх хувилбар
Ажиллагааны шаардлагыг хангаагүй хоцрогдсон нийцтэй байдлын шаардлагыг (Хэсэг 3.3.2-т заасны дагуу) АХ-ийн тодорхойлолт ба чөлөөлөх үндэслэл
IOP тестийн төлөвлөгөөний шаардлагыг хангаагүй байгаа (Хэсэг 4.3.1 -д заасны дагуу) АХ -ны тайлбар, IOP туршилтын тайлангийн хамт ямар нэгэн хазайлтын үндэслэл (хуулбарын линкийг оруулснаар өгч болно) Bluetooth SIG webсайт)
0.9/CR S -ээс хойших өөрчлөлтийг онцлон тэмдэглэсэн техникийн тодорхойлолтын өмнөх хувилбар (ууд) -ыг хүчингүй болгох, цуцлах талаар АХ -ны зөвлөмж.tage амьдралын төгсгөлийн талаархи зөвлөмж
0.9 / CR-ийн тодорхойлолтоос хойшхи функцууд болон функцүүдийн өөрчлөлтийн талаар АХ-ны бэлтгэсэн хураангуй (хэрэв байгаа бол)
АХ-ны гаргасан тодорхойлолт нь ТХ-ны баталсан дүрмийн хамрах хүрээнээс гадуур байгаа талаар BARB-ийн гишүүдийн тавьсан асуудалд BARB-ээс бэлтгэсэн тойм (хэрэв байгаа бол)
Хууль тогтоомжоос шийдвэрлэгдээгүй үлдсэн асуудлуудын жагсаалтview (хэрэв байгаа бол)
BTI-ээр батлагдсан Тестийн багц, АХ-аас батлагдсан Санал өгөх төслийн техникийн даалгаврын туршилтын хамрах хүрээний тойм. Шинжилгээнд хамрагдаагүй функцийг шинээр нэмж оруулсан эсвэл өөрчилсөн тохиолдолд орхигдуулахыг бичгээр тайлбарлах шаардлагатай
BTI-ээр батлагдсан ICS ба IXIT (хэрэв тодорхойлолтод шаардлагатай бол)
BTI ба BQRB хоёулаа баталсан TCRL
BSTS-ээс BTI-ийн хамт багаж хэрэгслийн бэлэн байдлын байдлын талаар гаргасан тайлан (жишээлбэл, PTS болон бусад туршилтын хэрэгслүүд, Bluetooth Launch Studio), үүнд TCRL-д туршилтын тохиолдлууд туршилтын хэрэгслээр дэмжигдээгүй тохиолдолд.
АЖ-аас бэлтгэсэн шаардлагатай бүх дугаарын хураангуй
БХБ ба АХ-аас боловсруулсан үрчлэлтийн хяналтын жагсаалт, энэ хэсгийн бүх үр дүнгийн ажил дууссан болохыг харуулсан болно
ТХ-ны хүссэн бусад бүх мэдээлэл

Үрчлэх / батлах үе шатанд АХ нь Bluetooth SIG-ийн асуудал хянах системийг ашиглан техникийн тодорхойлолт, туршилтын баримт бичгийн төсөлтэй холбоотой асуудал, тайлбарыг авахын тулд санал өгөх төслийн тодорхойлолтыг эцэслэхэд тооцох ёстой. Тодорхойлолтыг сайжруулахын тулд холбогдох бүх батлагдсан алдааг (өөрөөр хэлбэл батлагдсан алдааг нэгтгэж амжаагүй байгаа) нэгтгэх ёстой бөгөөд хянагдсан өөрчлөлтийг ашиглан тодорхойлох ёстой.

АХ нь хууль тогтоомжийн хувьд эцсийн тодорхойлолтын төслийг БХБГ -т өгөх ёстойview. Шинэ техникийн хувьд хууль эрх зүйнview тодорхойлолтыг бүхэлд нь багтаасан болно. Тодорхойлолтыг сайжруулахын тулд дахинview үндсэндээ техникийн тодорхойлолтын өөрчлөгдсөн хэсгүүдэд анхаарлаа хандуулах болно. Хууль эрх зүйн зорилгоview АХ -ны авч үзэх, шийдвэрлэхийг эрэлхийлэх ёстой хууль эрх зүйн эрсдэлийг тодорхойлох явдал юм. Хууль ёсны санал хүсэлтийг ноцтой байдлыг харгалзан ангилна. Хэрэв нэмэлт хууль эрх зүйн дахинview 0.9/CR S дээр хийсэнtagд, хууль ёсны дагуу дахин оруулахаар оруулсан хувилбарview Энэ хувилбараас хойш хийгдсэн бүх өөрчлөлтийг (АХ эсвэл БХХТ -ээс үүсгэсэн) дагаж мөрдөх өөрчлөлтүүдээр харуулах ёстой. Хууль тогтоомжийг боловсруулж дууссаны дарааview, Ажлын хэсэг болон БХБГ -ын зүгээс төслийн тодорхойлолтод тусгах санал хүсэлтийг хүлээн зөвшөөрнө. Хууль эрх зүйн талаас шийдвэрлэгдээгүй хууль зүйн тайлбар байвалview тодорхойлолтын төслийн талаар АХ -ны дарга шийдвэр гаргах талаар зөвшилцөхийн тулд Удирдах зөвлөлийн хэлэлцэх асуудалд цаг гаргаж болно.

Хууль эрх зүйн шинэчлэлтэй зэрэгцэнview, АХ нь техникийн тодорхойлолтын төслийг BARB -д дахин хүргүүлэх ёстойview. BARB -д анх ирүүлсний дараа BSTS тодорхойлолтын төслийг BARB -д дахин оруулахаар илгээсэн тухай бүх гишүүдэд мэдэгдэнэ.view мөн үүнийг Re гишүүнд ашиглах боломжтойview. Хэрэв АХХ нь BARB-ийг дахин боловсруулах техникийн тодорхойлолтын төслийн шинэчлэлтийг ирүүлсэн болview, BSTS нь бүх гишүүдэд үе үе нэмэлт мэдэгдэл илгээх болно.

BARB дахин дууссаны дарааview, Ажлын хэсэг, BARB нь төслийн тодорхойлолтод тусгах санал хүсэлтийг хүлээн зөвшөөрнө.

Хэрэв хууль ёсны дагууview ямар нэгэн мэдэгдэхүйц өөрчлөлтийг бий болгодог, нэмэлтview BARB шаардлагатай байж магадгүй. Үүний нэгэн адил, хэрэв BARB дахинview аливаа ноцтой өөрчлөлтийг бий болгосноор БХАТГ нь хууль эрх зүйн нэмэлт өөрчлөлт оруулах эсэхийг тодорхойлноview эдгээр өөрчлөлтийг хийх шаардлагатай байна. Хууль тогтоомжийг боловсруулж дууссаны дарааview ба BARB дахинview, BARB нь санал хураах төслийг батлах эсвэл татгалзах ёстой.

Хэрэв шалгалтын баримт бичгийг шинэчлэх шаардлагатай бол БСТС АХ-т шалгалтын баримт бичгийг шинэчлэхэд тусална. BTI нь тестийн баримт бичгийг батлах эсвэл татгалзах ёстой. BTI батлавал BTI нь TCRL-ийг эцэслэхэд тусалж, холбогдох баримт бичиг, ICS, IXIT, Test Suite-ийн хамт BQRB-д хүргэх болно. ТХБ нь Санал өгөх төслийг (батлах огноо) батлахад санал өгөхөөр ТУЗ-ийн хурлын товыг тооцоолж, TCRL-д ашиглах BTI-г өгөх болно. Техникийн тодорхойлолтыг BARB батлах, бүх туршилтын баримт бичгүүдийг BTI зөвшөөрөл (Test Suite, TCRL, ICS, IXIT орно), TCRL-ийн BQRB зөвшөөрөл нь үрчлэгдсэн огнооноос өмнө эсвэл өмнө хийгдэх ёстой.

BSTS нь бүх гишүүдэд санал хураах төсөл болон үрчлэлтийн огнооны бэлэн байдал, бэлэн байдлын талаар мэдээлэх болно. Хууль батлах 60/CR техникийн тодорхойлолтын талаар гишүүдэд мэдэгдсэнээс хойш 0.9 хоногийн өмнө батлах огноог тогтооно.view Дүрэмд заасны дагуу Удирдах зөвлөл нь хугацааг богиносгодог бөгөөд батлах огноог мэдэгдсэнээс хойш дор хаяж 14 хоногийн дараа гишүүдэд дүрмийн дагуу өгдөг. Санал авах төсөлд олон тооны CR -ийг нэгтгэсэн тохиолдлуудын хувьд гишүүн Re -ийн эхлэл болноview ТУЗ-ийн хамгийн сүүлд баталсан НИТ-ийн талаар гишүүдэд мэдэгдсэн огноо.

Хүүхэд үрчлэх огнооны талаар гишүүдэд мэдэгдсэний дараа Санал хураалтын төсөлд бичсэн бичгийн алдаанд BoD-ээр батлагдсан залруулгыг зөвшөөрнө. Specification Adoption timeline-ийг Зураг 6.2-т харуулав.

6.2 Өгөгдсөн дугаарууд

Bluetooth SIG нь Bluetooth SIG оноосон дугаарууд дээр олон нийтэд зориулагдсан дугааруудыг хадгалдаг webсайт [7]. Эдгээр хуваарилагдсан тоонуудыг янз бүрийн тооны орон зайд бүлэглэв (давхардалгүй холбогдох тооны багц). Өгөгдсөн тоонууд өөр өөр орон зайд хуваарилагдсан бусад тоонуудтай давхцаж болох боловч тоон доторх дугаарыг дахин ашиглахыг зөвшөөрдөггүй. Төрөл бүрийн тооны орон зайг оноосон тоонуудын хэрэглээг тодорхойлсон тодорхойлолтод тодорхойлсон болно.

BARB нь IOP туршилтын тайланг баталсны дараа АХХ нь эцсийн тодорхойлолтод заасан тооны орон зайд шинэ дугаар олгох хүсэлтийг BARB -д ирүүлнэ. BARB дахин болноview хүсэлт, BSTS -тэй хамтран томилогдсон дугаарыг тодорхойлох. BARB зөвшөөрсний дараа BSTS өгсөн дугаарыг хэвлэн нийтлэх хуваарийг Bluetooth SIG оноосон дугаар дээр нийтэд нээлттэй болгох болно. webтодорхойлолт батлагдсанаас хойш нэг долоо хоногийн дотор [7] сайт.

Өгөгдсөн дугаарыг Bluetooth SIG оноосон дугаар дээр нийтэлсний дараа webСайт эсвэл батлагдсан техникийн тодорхойлолт гарсан тохиолдолд өгсөн тоонууд нь өөрчлөгдөхгүй байхаар хийгдсэн (утга, утгаар нь өөрчлөхгүй). Хэрэв тэд ямар нэгэн шалтгаанаар ашиглах боломжгүй болсон бол тэдгээр нь нөөц үнэт зүйл болж, дахин ашиглахыг зөвшөөрдөггүй.

6.3 Батлах / батлах үе шатаас гарах шаардлага

Баталгаажуулалт / үрчлэлтийн үе шат нь ТХ-ны тодорхойлолтыг баталж, үрчлэлтийн дараах дараахь ажлууд дуусахад дуусна.

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 нь үрчлэлтийн дараахь үйл ажиллагааг тодорхойлолтыг баталснаас хойш нэг долоо хоногийн дотор хийхээр төлөвлөж байна.

7. Техникийн нөхцөлийн засвар үйлчилгээний үе шат

Тодорхойлолтын засвар үйлчилгээний үе шат нь батлах / батлах үе шат дууссаны дараа эхэлнэ. Хэрэв тодорхойлолт эсвэл холбогдох туршилтын баримт бичигтэй холбоотой асуудлууд (жишээлбэл, үг хэллэгийн эргэлзээтэй байдал эсвэл техникийн алдаа) илэрсэн бол тэдгээрийг Bluetooth SIG Errata хэрэгслийг ашиглан алдаатай саналуудыг бий болгож баримтжуулсан байх ёстой. Тодорхойлолтын алдаатай саналуудыг БЦГ-ын дагуу боловсруулж, ангилж, батална [3]. Test Suite-ийн тогтворгүй байдлыг TSTO-ийн дагуу боловсруулж ангилдаг [5]. Хэрэв SMPD ба EPD эсвэл TSTO-ийн хооронд ямар нэгэн зөрчилдөөн байвал SMPD нь тэргүүлэх ач холбогдол өгдөг.

Техникийн тодорхойлолтын зөрчлийг зөвхөн эцсийн батлагдсан Bluetooth үзүүлэлтүүдийн техникийн болон редакцийн алдааг засахад ашиглах ёстой. Функцийг нэмэх, өөрчлөх, хасах нь зөвхөн энэхүү баримт бичигт өмнө тодорхойлсон техникийн нөхцлийг сайжруулах үйл явцын тусламжтайгаар хийгддэг.

7.1 Алдаатай үйл явцыг түргэсгэх

EPD [3] -д тодорхойлсон үйл явцын дагуу алдааг батлах үед АХ, БАРБ, БСТС үүнийг яаралтай гэж үзэж, яаравчлахыг зөвлөж болно. Ийм зүйл тохиолдоход БХБХ нь АХ, Барб -ын хамт Зөвлөлийг Удирдах зөвлөлд танилцуулна. Энэхүү зөвлөмжийг хүлээн авах, эсхүл татгалзах эсэхийг Удирдах зөвлөл шийдвэрлэнэ. Хэрэв зөвлөмжийг хүлээн зөвшөөрвөл BSTS нь батлагдсан алдааг эмх замбараагүй байдлын загварт [8] нэн даруй оруулж, хариуцсан АХ -той хамтран АХХ -д дахин боловсруулж өгөх алдааг залруулах ажлыг эцэслэн боловсруулна.view ба зөвшөөрөл.

Нэг гаруйview хурдасгасан алдааны явцыг Зураг 7.1 -д үзүүлэв.

Үрчлэх огнооноос өмнө дараахь бичиг баримтыг бүрдүүлж, ТХ-нд танилцуулах шаардлагатай.

BARB-ийн баталсан алдааг засах ажлыг түргэвчилсэн төсөл.
Ажиллагааны шаардлагыг хангаагүй хоцрогдсон нийцтэй байдлын шаардлагуудыг (Хэсэг 3.3.2-т заасны дагуу) АХ-аас гаргасан тайлбар болон чөлөөлөлтөд хамрагдах үндэслэл.
Хууль тогтоомжоос шийдвэрлэгдээгүй үлдсэн асуудлуудын жагсаалтview (хэрэв байгаа бол).
BTI-ийн баталсан Test Suite, ICS, IXIT (хэрэв алдаатай тохиолдолд шаардлагатай бол).
BTI ба BQRB-ээр батлагдсан TCRL (хэрэв алдаатай байх шаардлагатай бол).
Багаж хэрэгслийн бэлэн байдлын байдлын талаар BSTS-ийн хамт BTI-ийн хамт хийсэн тайлан (жишээлбэл, PTS болон бусад туршилтын хэрэгслүүд, Bluetooth Launch Studio), үүнд TCRL-ийн туршилтын тохиолдлууд тестийн хэрэгслүүд болон тайлбараар дэмжигдээгүй тохиолдолд (хэрэв алдаатай тохиолдолд шаардлагатай бол) ).
БХБ ба АХ-ны боловсруулсан үрчлэлтийн хяналтын жагсаалт, энэ хэсгийн үр дүнгүүд бүгд дууссан болохыг харуулсан болно.
ТХ-ны хүссэн бусад бүх мэдээлэл.

БХБТГ нь хариуцсан АХ -той хамтран Алдааг түргэвчилсэн засварлах төслийг эцэслэн боловсруулж, хариуцсан АХ -д дахин хүргүүлэх хувилбарыг бий болгоно.view ба зөвшөөрөл.

Ажлын хэсэг нь хууль тогтоомжид нийцүүлэхийн тулд Шуурхай алдааны залруулгыг BSTS -д өгөх ёстойview. Хууль тогтоомжийг боловсруулж дууссаны дарааview, Ажлын хэсэг, БХБГХБХБХХГ -аас гаргасан алдааг засварлах ажилд оруулах санал хүсэлтийг хүлээн зөвшөөрнө. Хууль эрх зүйн талаас шийдвэрлэгдээгүй хууль зүйн тайлбар байвалview Алдааг түргэвчилсэн залруулах талаар АХ -ны дарга нь ТУЗ -ийн хэлэлцэх асуудлын талаар шийдвэр гаргаж, ТУЗ -ийн саналыг авахыг хүсч болно.

Хууль эрх зүйн шинэчлэлтэй зэрэгцэнview, АХХ нь түргэн шуурхай алдааны залруулгыг BARB -д дахин оруулах ёстойview. Алдааны алдааг засах залруулгыг BARB -д оруулсны дараа BSTS нь бүх гишүүдэд дахин нэвтрэх боломжтой болгоно.view мөн бэлэн байгаа тухай бүх гишүүдэд мэдэгдэх. BARB дахин дууссаны дарааview, Ажлын хэсэг болон BARB нь түргэвчилсэн алдааны залруулгад оруулах санал хүсэлтийг зөвшөөрнө.

Хэрэв хууль ёсны дагууview ямар нэгэн мэдэгдэхүйц өөрчлөлтийг бий болгодог, нэмэлтview BARB шаардлагатай байж магадгүй. Үүний нэгэн адил, хэрэв BARB дахинview аливаа ноцтой өөрчлөлтийг бий болгосноор БХАТГ нь хууль эрх зүйн нэмэлт өөрчлөлт оруулах эсэхийг тодорхойлноview эдгээр өөрчлөлтийг хийх шаардлагатай байна. Хууль тогтоомжийг боловсруулж дууссаны дарааview ба BARB дахинview, BARB нь Хурдан алдааны залруулгыг батлах эсвэл татгалзах ёстой.

Хэрэв шалгалтын баримт бичгийг шинэчлэх шаардлагатай бол БСТС АХ-т шалгалтын баримт бичгийг шинэчлэхэд тусална. Туршилтын баримт бичгийг BTI баталсны дараа BTI нь TCRL-ийг эцэслэн боловсруулж, холбогдох ICS, IXIT, Test Suite-ийн хамт баримт бичгийг BQRB-д хүргэх болно. BSTS нь үрчлэгдсэн огноог тооцоолж, TCRL-д ашиглахын тулд BTI-д өгөх болно. Түргэвчилсэн алдааны залруулгын BARB зөвшөөрөл, бүх туршилтын баримт бичгүүдийн BTI зөвшөөрөл (үүнд холбогдох Test Suite, TCRL, ICS, IXIT орно), TCRL-ийн BQRB зөвшөөрөл нь үрчлэгдсэн огнооноос өмнө эсвэл өмнө хийгдэх ёстой.

БСТС нь алдааг түргэвчилсэн залруулга, үрчлэгдсэн огноог эцэслэн боловсруулж, ашиглах боломжтой эсэх талаар бүх гишүүдэд мэдээлнэ. Үрчлэх огноог дүрмийн дагуу [2] тогтоож, бүх гишүүдэд мэдэгдэх бөгөөд үрчлэгдсэн огноо нь гишүүдэд мэдэгдэл өгснөөс хойш 14-өөс доошгүй хоногийн дараа байна. Санал болгож буй үрчлэлтийн огнооны талаар гишүүдэд мэдэгдсэний дараа ТУБ нь хурдацтай алдааг засахдаа оруулсан бичгийн алдааны залруулгыг санал болгож буй үрчлэлтийн огнооны талаар нэмэлт мэдэгдэлгүйгээр шаардагдах 14 хоног хүлээлгүйгээр баталж болно.

Bluetooth SIG нь батлагдсан түргэвчилсэн алдааны залруулгыг олон нийтэд нээлттэй болгох бөгөөд үрчлэгдсэнээс хойш нэг долоо хоногийн дотор хийхээр төлөвлөж байна. Энэ талаархи мэдэгдлийг БСТС бүх гишүүдэд өгөх болно.

BoD нь алдааг түргэвчилсэн залруулгыг хэрэгжүүлж, үрчлэлтийн дараах дараахь ажлуудыг хийж гүйцэтгэсэн тохиолдолд түргэвчилсэн алдааны үйл явц дуусна.

BSTS нь батлагдсан Хурдан алдааны залруулга болон холбогдох туршилтын баримт бичгүүдийг (хэрэв алдаа шаардлагатай бол) Bluetooth SIG дээр нийтэд нээлттэй болгосон. webсайт.
BSTS нь мэргэшлийн системийг идэвхжүүлсэн (алдаатай тохиолдолд шаардлагатай бол).
БСТС нь батлагдсан Түргэн алдааг засах боломжтой эсэх талаар бүх гишүүдэд мэдэгдсэн.

Эдгээр үйл ажиллагаа дууссаны дараа Errata залруулалтыг төлөвлөсөн тодорхойлолтыг сайжруулах ажлын хүрээнд эсвэл 7.2 хэсэгт тайлбарласны дагуу удахгүй хийгдэх засвар үйлчилгээний хувилбараар нөлөөлөлд өртсөн үзүүлэлтүүдэд нэгтгэхээр төлөвлөсөн болно.

7.2 Засвар үйлчилгээний хувилбар (.Z үзүүлэлтүүд)

Техникийн / Өндөр, Техникийн / Чухал гэсэн ангилалд багтсан, идэвхтэй техникийн тодорхойлолтын текстэнд хараахан ороогүй батлагдсан алдаанууд байгаа эсэхийг (алдааны залруулга гэж нэрлэдэг) БСТС ойролцоогоор жил бүр тодорхойлно (өөрөөр хэлбэл, хуучраагүй буюу татан аваагүй батлагдсан тодорхойлолт). Алдааны ангиллын тодорхойлолтыг Хавсралт А-аас үзнэ үү. Тодорхойлолтын эзэмшигч (техникийн нөхцлийг хадгалахын тулд АХ, эсвэл АХ дүрмийг дагаж мөрдөхгүй бол BARB) батлагдсан алдааг багтаасан идэвхтэй техникийн нөхцлийг эрт засварлахыг хүсч болно. BSTS-ийн тодорхойлолт эсвэл тодорхойлолтыг эзэмшигчийн хүсэлтээр засвар үйлчилгээ хийх үйл явц эхэлнэ.

Нэг гаруйview засвар үйлчилгээ хийх явцыг Алдаа хэсэгт харуулав. Лавлах эх сурвалж олдсонгүй.

Засвар үйлчилгээний хувилбар эхлэхэд BSTS нь тодорхойлолтын эзэн, BARB, BTI-ийн хамт алдааны залруулгыг хэвлэгдсэн техникийн хувилбарт оруулах төлөвлөгөөг боловсруулж, BoD-д танилцуулна. Санал болгож буй төлөвлөгөөнд Errata залруулгыг техникийн тодорхойлолтод (өөрөөр хэлбэл .Z хувилбар) эсвэл аль хэдийн хийгдэж байгаа техникийн сайжруулалтад (өөрөөр хэлбэл XY хувилбар) оруулах эсэхийг оруулах ёстой. Санал болгож буй төлөвлөгөөнд батлагдсан техникийн тодорхойлолтуудын хувилбаруудын хооронд заавал шинэ шинж чанаруудыг нэмж оруулсан эсэх, дараагийн техникийн сайжруулалтыг батлахаар төлөвлөсөн хугацаа болон бусад хүчин зүйлийг харгалзан үзэх шаардлагатай.

Төлөвлөгөө боловсруулж төлөвлөгөөг баталсны дараа БСТС нь Техникийн нөхцөл эзэмшигчийн хамт Техникийн / Дунд, Техникийн / Өндөр, Техникийн / Шийдвэртэй алдааны бүх залруулгыг "Засвар үйлчилгээний хувилбарын төсөл" гэж нэрлэсэн тодорхойлолтын төсөлд тусгах болно. Редакторын болон техникийн / бага алдаатай залруулгын хувьд алдааны залруулга нь техникийн тодорхойлолтын нэгээс олон хувилбарт хамааралтай бол BoD нь өөрөөр заагаагүй бол BSTS эдгээр алдааг зөвхөн тухайн хувилбарын дараагийн шинэчлэлт дээр хамгийн сүүлийн үеийн техникийн тодорхойлолтын хувилбар болгон нэгтгэх болно. . Засвар үйлчилгээний хувилбарын төсөлд алдаатай залруулга оруулахаас өөр өөрчлөлт оруулахгүй. Засвар үйлчилгээний хувилбар бүр нь хэвлэгдсэн техникийн тодорхойлолтын өмнөх батлагдсан хувилбарт санал болгож буй өөрчлөлтийг харуулахын тулд өөрчлөлтийг хянах аргыг ашиглан бүх оруулсан алдааны залруулгыг тодорхойлох ёстой.

Засвар үйлчилгээний хувилбар дахь алдааны залруулга тус бүрт санал болгож буй хугацааг Туршилтын Suite-ийн нөлөөллөөс хамаарна: Test Suite-ийн нөлөөлөлгүй бүх алдааны залруулгыг нэн даруй оруулж болох боловч тестийн багцад нөлөөлсөн алдааны залруулга нь цаг хугацаа нь TCRL-ийн шинэчлэлттэй давхцаж байхаар боловсруулсан болно.

BTI ба BSTS нь Засвар үйлчилгээний хувилбарт Test Suite-ийн нөлөөлөл бүхий алдаатай залруулгыг оруулах эцсийн хугацааг тогтооно. Энэ хугацаа нь ихэвчлэн TCRL-ийн дараагийн томоохон хувилбарыг төлөвлөсөн батлах өдрөөс 3-6 сарын өмнө хийгддэг. Оруулах эцсийн хугацааг алдсан Test Suite-ийн нөлөөлөл бүхий алдааны залруулгыг дараагийн жил тутмын TCRL хувилбарын хүрээнд боловсруулна. Тиймээс, өмнө нь гаргахыг шаардаагүй тохиолдолд техникийн шинэчлэлийн техникийн / өндөр эсвэл техникийн / алдаатай алдааг засах хамгийн дээд хугацаа нь ойролцоогоор 15-18 сар байна.

Тодорхойлолт эзэмшигч нь хууль ёсны дагуу дахин боловсруулахад эцсийн байдлаар баталсан засвар үйлчилгээний хувилбарын төслийг ирүүлэх ёстойview. Хууль ёсны дахинview үндсэндээ техникийн тодорхойлолтын өөрчлөгдсөн хэсгүүдэд анхаарлаа хандуулах болно. Хууль тогтоомжийг боловсруулж дууссаны дарааview, Техникийн тодорхойлолтын эзэмшигч болон БСТ нь засвар үйлчилгээний хувилбарын төсөлд тусгах санал хүсэлтийг зөвшөөрнө. Хууль эрх зүйн талаас шийдвэрлэгдээгүй хууль зүйн тайлбар байвалview Засвар үйлчилгээний хувилбарын төсөлд Техникийн тодорхойлолт эзэмшигч нь ТУЗ -ийн хэлэлцүүлэгт цаг тухайд нь хүсэлт гаргаж, шийдвэрийн талаар БХ -ны саналыг авах боломжтой.

Хууль эрх зүйн шинэчлэлтэй зэрэгцэнview, Тодорхойлолт эзэмшигч нь засвар үйлчилгээний хувилбарын төслийг BARB -д дахин оруулах ёстойview. Засвар үйлчилгээний хувилбарын төслийг BARB -д ирүүлсний дараа BSTS нь бүх гишүүдэд дахин нэвтрэх боломжтой болгоноview мөн бэлэн байгаа тухай бүх гишүүдэд мэдэгдэх. BARB дахин дууссаны дарааview, Тодорхойлолтын эзэмшигч болон BARB нь техникийн тодорхойлолтын төсөлд тусгах санал хүсэлтийг зөвшөөрнө.

Хэрэв хууль ёсны дагууview ямар нэгэн мэдэгдэхүйц өөрчлөлтийг бий болгодог, нэмэлтview BARB шаардлагатай байж магадгүй. Үүний нэгэн адил, хэрэв BARB дахинview аливаа ноцтой өөрчлөлтийг бий болгосноор БХАТГ нь хууль эрх зүйн нэмэлт өөрчлөлт оруулах эсэхийг тодорхойлноview эдгээр өөрчлөлтийг хийх шаардлагатай байна. Хууль тогтоомжийг боловсруулж дууссаны дарааview ба BARB дахинview, BARB нь засвар үйлчилгээний хувилбарыг батлах эсвэл татгалзах ёстой. Хэрэв BARB зөвшөөрвөл энэ нь санал хураалтын төсөл болно.

Туршилтын баримт бичигт нөлөөлөх алдааны залруулга болон удахгүй болох TCRL хувилбарыг гаргахад холбогдох туршилтын алдааг цаг хугацаанд нь боловсруулах тохиолдолд BSTS нь тодорхойлолтын эзэн болон BTI-тэй хамтран туршилтын баримт бичгийг шинэчлэх болно. Туршилтын баримт бичгийг BTI баталсны дараа BSTS нь үрчлэлтийн огноог тооцоолж, батлагдсан үрчлэлтийн огноог BTI-д TCRL-д ашиглахаар өгнө. BTI нь холбогдох ICS, IXIT, Test Suite-ийн хамт TCRL-ийг BQRB-д хүргэх болно. Техникийн тодорхойлолтыг BARB батлах, бүх туршилтын баримт бичгүүдийг BTI зөвшөөрөл (үүнд холбогдох Test Suite, TCRL, ICS, IXIT орно), TCRL-ийн BQRB зөвшөөрөл нь үрчлэгдсэн огнооноос өмнө эсвэл өмнө хийгдэх ёстой.

БХБХ нь санал хураалтын төсөл, санал болгож буй үрчлэлтийн огноог боловсруулж дууссан эсэх талаар бүх гишүүдэд мэдээлнэ. Үрчлэх огноог дүрмийн дагуу тогтоож, бүх гишүүдэд мэдэгдэх бөгөөд үрчлэгдсэн огноо нь гишүүдэд мэдэгдэл хүргүүлснээс хойш дор хаяж 14 хоногийн дараа байх ёстой. Санал болгож буй үрчлэлтийн огнооны талаар гишүүдэд мэдэгдсэний дараа ТХ нь санал авах төсөл батлахдаа батлагдсан хүүхэд үрчилж авах огнооны талаар нэмэлт мэдэгдэлгүйгээр шаардагдах 14 хоног хүлээлгүйгээр саналын хуудасны найруулга дахь алдааны засварыг баталж болно.

Үрчлэх огнооноос өмнө дараахь бичиг баримтыг бүрдүүлж, ТХ-нд танилцуулах шаардлагатай.

Санал хураалтын төсөл
Санал авах төслийн ижил XY утгатай батлагдсан хувилбарын бүх өөрчлөлтийг харуулсан саналын хуудасны өөрчлөлтийг дагаж мөрдөх хувилбар (жишээлбэл, санал өгөх төслийг 1.4.2 хувилбараар санал болговол өөрчлөлтийг 1.4.1-тэй нийцүүлэн хянах болно. тодорхойлолтын хувилбар)
Батлагдсан техникийн тодорхойлолтын өмнөх хувилбар (хувилбар) -ыг хүчингүй болгох буюу буцаан авах тухай тодорхойлолтыг эзэмшигчийн өгсөн зөвлөмж
Хууль тогтоомжоос шийдвэрлэгдээгүй үлдсэн асуудлуудын жагсаалтview (хэрэв байгаа бол)
BTI-ээр батлагдсан Test Suite, ICS, IXIT (засвар үйлчилгээний хувилбар шаардлагатай бол)
BTI ба BQRB-ээр батлагдсан TCRL (хэрэв засварын ажилд шаардлагатай бол)
Багаж хэрэгслийн бэлэн байдлын байдлын талаар BSTS-ийн хамт BTI-ийн хамт хийсэн тайлан (жишээлбэл, PTS болон бусад туршилтын хэрэгслүүд, Bluetooth Launch Studio), туршилтын хэрэгслүүдээр дэмжигдээгүй TCRL-ийн туршилтын тохиолдлууд, тайлбарууд (засвар үйлчилгээ шаардлагатай бол) суллах)
BSTS болон Техникийн тодорхойлолтын эзэмшигчийн боловсруулсан үрчлэлтийн хяналтын жагсаалт, энэ хэсгийн үр дүнгүүд бүгд дууссан болохыг харуулна
ТХ-ны хүссэн бусад бүх мэдээлэл

ТХ нь Санал хураалтын төслийг баталж, үрчлэлтийн дараах дараахь ажлуудыг хийж дууссаны дараа засварын ажил дуусах болно.

BSTS баталсан тодорхойлолт болон холбогдох туршилтын баримт бичгүүдийг (хэрэв засвар үйлчилгээнд шаардлагатай бол) Bluetooth SIG дээр олон нийтэд нээлттэй болгосон. webсайт.
BSTS нь өмнө баталсан техникийн тодорхойлолтын хувилбарын өөрчлөлтийг хянадаг мэдээллийн хувилбарыг шинээр баталсан хувилбарт оруулсан бүх өөрчлөлтийг Bluetooth SIG-ийн бүх гишүүдэд ашиглах боломжтой болгосон. webсайт.
BSTS нь мэргэшлийн системийг идэвхжүүлсэн.
BSTS нь батлагдсан тодорхойлолт, дагалдах баримт бичигтэй эсэх талаар бүх гишүүдэд мэдэгдсэн.

Эдгээр үйл ажиллагаа дууссаны дараа техникийн тодорхойлолтыг 8-р хэсэгт тодорхойлсны дагуу тодорхойлолтыг хүчингүй болгох эсвэл буцааж татан авах хүртэл Техникийн нөхцөлийн засвар үйлчилгээний үе шатанд хэвээр байна.

8. Техникийн тодорхойлолт Амьдралын төгсгөлийн үе шат

Техникийн нөхцөл хангалтгүй гэж тогтоогдсон эсвэл өөр шалтгаанаар шинэ хувилбаруудаар орлуулснаар техникийн нөхцөлийг хүчингүй болгож эсвэл хасч болно. Хуучирсан ба татан авсан техникийн үзүүлэлтүүдийг архивлаж, шинэчлэхээ больсон. Хуучирсан болон татан авсан техникийн үзүүлэлтүүдийг Bluetooth Мэргэшлийн хөтөлбөрт өөр өөр байдлаар авч үздэг.

Аливаа гишүүн, бүлэг, хороо нь тодорхойлолтыг хүчингүй болгох эсвэл татан буулгах зөвлөмжийг холбогдох хугацаатай хамт БСТС-д илгээж болно (имэйлээр

specation.manager@bluetooth.com) хүссэн үедээ. BSTS нь тодорхойлолт болон холбогдох цаг хугацааны хуваарийг хүчингүй болгох эсвэл цуцлахыг санал болгож болно. BSTS нь зөвлөмжийг BARB болон техникийн тодорхойлолтыг хадгалах үүрэгтэй бүлэг эсвэл хороонд шилжүүлнэ.view болон санал хүсэлт.

BARB ба хариуцлагатай бүлэг эсвэл хороо нь техникийн тодорхойлолтыг хүчингүй болгох, хасах зөвлөмжийг үнэлж дараахь (бүрэн бус) шалгуурыг харгалзан үзнэ.

Техникийн тодорхойлолтын өмнөх хувилбарт хуучирсан эсвэл ашиглах ёсгүй функц байгаа юу?
Дараачийн хувилбаруудад заавал байх ёстой шинэ функцууд нэмэгдсэн үү?
Өмнөх хувилбаруудад үйл ажиллагаа эсвэл харилцан уялдаа холбоог сулруулсан, дараагийн хувилбаруудад засч залруулсан, одоо байгаа хэрэглэгчийн хувилбаруудыг урагшлуулахад шаардлагатай дутагдал дутагдалтай байгаа юу?
Хэрэглэгчийн шинэ хувилбаруудыг сайжруулахад шаардлагатай дараагийн хувилбаруудад нэмэлт функц байгаа юу?
Дараачийн хувилбаруудад ашиглах чадвар, харилцан уялдаатай байдал сайжирсан уу?
Дараагийн хувилбаруудад аюулгүй байдлын сайжруулалт бий юу?

BARB болон хариуцсан бүлэг эсвэл хороо өөр санал зөвлөмж гаргаж болно.

BARB эсвэл техникийн тодорхойлолтыг хадгалах үүрэг хүлээсэн бүлэг, хорооноос санал авсны дараа БХБ нь зөвлөмж, санал хүсэлтийг Удирдах зөвлөлд хэлэлцүүлэхээр ирүүлнэ. Удирдах зөвлөл нь нөлөөлөлд өртсөн техникийн тодорхойлолтыг хадгалах үүрэг хүлээсэн бүлэг, хороог уг зөвлөмжийг хүлээн авч, хэлэлцүүлэхийг урьж болно. Удирдах зөвлөл нь зөвлөмж, санал хүсэлтийг харгалзан үзэх бөгөөд саналыг хүлээн зөвшөөрч, өөрчлөх боломжтой. Удирдах зөвлөл нь 30 хоногийн хугацаатай техникийн тодорхойлолт, холбогдох хугацаа (цаг) -ыг хүчингүй болгох эсвэл цуцлах саналыг бүх гишүүдэд BSTS-аас мэдэгдэхийг шаардах болно.view эцсийн шийдвэр гаргахаасаа өмнө бүх гишүүдэд нэмэлт санал хүсэлт өгөх боломжийг олгох хугацаа.

ТУЗ нь гишүүдээс ирсэн санал хүсэлтийг харгалзан үзэх болно. ТУ тодорхойлолтыг хүчингүй болгох буюу цуцлахыг баталсны дараа БСТС шийдвэр, холбогдох хугацааны талаар бүх гишүүдэд мэдэгдэнэ.

8.1 Элэгдэл

Техникийн тодорхойлолтыг хүчингүй болгосны дараа дараахь зүйл тохиолдох болно.

Тодорхойлолтыг шинэчлэхээ болино.
Хариуцлагатай АХ нь дахин ажиллах болноview бусад техникийн үзүүлэлтүүдэд хамааралтай эсэхийг тодорхойлохын тулд хуучирсан техникийн тодорхойлолтын эсрэг бичсэн бүх алдаанууд. Алдааг алдааны системд татгалзаж, холбогдох техникийн үзүүлэлтүүдийн дагуу дахин бичиж болно.
АХ эсвэл БХБ нь бусад техникийн тодорхойлолтуудад хуучирсан үзүүлэлтүүдийн талаархи шаардлагатай лавлагааг шинэчлэхэд алдаа гаргана.
BTI нь техникийн шалгалтын холбогдох баримт бичгүүдийг шинэчилж, техникийн нөхцлийг цуцалсныг харуулна.
BSTS нь Bluetooth SIG -ийг шинэчлэх болно webашиглах өөр тодорхойлолт (ууд) -ын талаархи удирдамж бүхий сайт.
Шинэ алдааг хуучирсан техникийн нөхцлийн дагуу илгээх боломжгүй болсон.
Ирээдүйн техникийн тодорхойлолтод техникийн тодорхойлолтыг ашиглахгүй.
BSTS нь гишүүдийн түүхэн зорилгоор нэвтрэхэд ашиглах боломжгүй гэж тэмдэглэсэн техникийн тодорхойлолтын хувилбарыг архивлах болно.

8.2 Татгалзах

Тодорхойлолтыг татан авсны дараа элэгдэлд орох үе шатуудаас гадна дараахь зүйлүүд гарч ирнэ.

BTI нь техникийн шалгалтын холбогдох баримт бичгийг шинэчлэн техникийн нөхцлийг цуцалсныг харуулна.
BSTS нь Bluetooth SIG -ийг шинэчлэх болно webашиглах өөр тодорхойлолт (ууд) -ын талаархи удирдамж бүхий сайт.
BSTS нь гишүүдийн түүхэн зорилгоор нэвтрэх эрхээ буцаан татсан гэж тэмдэглэсэн тодорхойлолтын хувилбарыг архивлах болно.

ТХ тодорхойлолтыг хүчингүй болгохгүйгээр техникийн нөхцөлийг нэн даруй буцааж авахаар сонгож болно.

9. Цагаан цаас боловсруулах үйл явц

Цагаан цаасыг зөвхөн мэдээллийн зорилгоор бүтээдэг. Дараахь цагаан цаасны үйл явц нь бүх Bluetooth WG, EG, SG болон хороод хамаарна. Энэ хэсэг нь зөвхөн Bluetooth SIG дотор ашиглах мэдээллийн баримт бичигт хамаарахгүй.

Энэ үйл явцыг доорх Зураг 9.1-д харуулав.

Аливаа бүлэг, хороо нь цагаан цаасан дээр ажиллаж эхлэхээсээ өмнө Bluetooth SIG-ээр хэвлүүлэхээр төлөвлөж байна. Бүлэг эсвэл хороо нь санал болгож буй дүрмийн шинэчлэлтийг цагаан цаасны агуулгыг тодорхой тодорхойлж, цагаан цаасны саналыг танилцуулах болно.

Цагаан цаасны саналыг дор хаяж багтаасан байх ёстой.

Цагаан цаасны хэрэгцээ
Цагаан цаасан дээр санал болгож буй агуулгын тойм
Агуулгыг тодорхойлолтын нэг хэсэг болгон оруулахыг яагаад зөвлөдөггүйг тайлбарласан тайлбар
Зориулалтын үзэгчид
Аливаа засвар үйлчилгээний төлөвлөгөө (өөрөөр хэлбэл энэхүү цагаан цаасыг дараагийн хувилбар гаргахаас өмнө тооцоолсон хугацаа шаардлагатай байж болно)
Цагаан цаасны өмнөх хувилбаруудыг, хэрэв байгаа бол хэрхэн зохицуулах талаар зөвлөмж (жишээлбэл, архивлах)

Дүрмийн шинэчлэл, цагаан цаасан дээр тавьсан саналын танилцуулгыг BARB -д өгөх ёстойview. Дахин хэлэхэдview болон дүрмийн шинэчлэлтийг BARB баталснаар БХБХ нь дүрмийн шинэчлэлтийг Цагаан цаасан дээрх саналын танилцуулгын хамт Удирдах зөвлөлд батлуулахаар ирүүлнэ.

Хэрэв ТХ нь дүрмийн шинэчлэлтийг батлавал бүлэг эсвэл хороо цагаан цаас боловсруулах ажлыг үргэлжлүүлж болно.

Бүлэг эсвэл хороо нь цагаан хуудсыг боловсруулж дуусмагц БСТБ нь редакцийн редактор хийх болноview Bluetooth боловсруулах зааварчилгааг дагаж мөрдөх.

BSTS -ийн тайлбарыг шийдвэрлэсний дараа бүлэг нь цагаан хуудсыг хууль ёсны дагуу хянуулахаар BSTS -д өгөх ёстойview. Хууль тогтоомжийг боловсруулж дууссаны дарааview, групп болон БХБТ нь цагаан хуудсанд оруулах санал хүсэлтийг хүлээн зөвшөөрнө. Хууль тогтоомжоос шийдвэрлэгдээгүй хууль зүйн тайлбар байвалview Цагаан цаасан дээр бүлгийн дарга нь Удирдах зөвлөлийн хэлэлцэх асуудлын талаар шийдвэр гаргаж, ТУЗ -ийн санал авахыг хүсч болно.

Хууль эрх зүйн шинэчлэлтэй зэрэгцэнview, бүлэг цагаан хуудсыг дахин BARB -д ирүүлэх ёстойview. Тэдний нэг хэсэг болгонview, BARB нь 3 -р хэсгийн үйл явцын дагуу цагаан цаасны аль нэг хэсгийг цагаан цааснаас хасч техникийн тодорхойлолтод оруулах эсэхийг зөвлөж болно.view. BARB дахин дууссаны дарааview, групп болон BARB нь санал хүсэлтийг цагаан цаасан дээр тусгах талаар тохиролцох болно.

Хэрэв хууль ёсны дагууview ямар нэгэн мэдэгдэхүйц өөрчлөлтийг бий болгодог, нэмэлтview BARB шаардлагатай байж магадгүй. Үүний нэгэн адил, хэрэв BARB дахинview аливаа ноцтой өөрчлөлтийг бий болгосноор БХАТГ нь хууль эрх зүйн нэмэлт өөрчлөлт оруулах эсэхийг тодорхойлноview эдгээр өөрчлөлтийг хийх шаардлагатай байна. Хууль тогтоомжийг боловсруулж дууссаны дарааview ба BARB дахинview, BARB нь цагаан цаасыг батлах эсвэл татгалзах ёстой.

BARB цагаан хуудсыг баталсны дараа BARB-ээр батлагдсан цагаан цаасыг зохиогчийн бүлэг эсвэл хорооноос ТУЗ-д танилцуулж батлуулна.

Зөвлөлөөс цагаан цаасыг баталж, дараахь баталгааны дараах ажлууд хийгдсэн үед цагаан цаасны үйл явц дуусна.

BSTS нь батлагдсан цагаан хуудсыг Bluetooth SIG дээр олон нийтэд нээлттэй болгосон webсайт.
БСТС нь батлагдсан цагаан цаасны бүх гишүүдэд мэдэгдэнэ.
Хэрэв цагаан цаас нь одоо байгаа цагаан цаасыг сайжруулж байгаа бол BSTS нь гишүүд түүхэн зорилгоор нэвтрэхийн тулд цагаан цаасны хувилбарыг архивлана.

Bluetooth SIG нь баталгааны дараах үйл ажиллагааг цагаан хуудсыг баталснаас хойш нэг долоо хоногийн дотор хийхээр төлөвлөж байна.

10. Лавлагаа

Блютүүтээс лавлагаа авсан 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)
ТХЕХ-ийн тодорхойлолтын нэмэлт (GSS) (GATT-ийн тодорхойлолтын хуудас, дээрээс авах боломжтой https://www.bluetooth.com/specifications/gatt)
Шинэ тодорхойлолтын санааг оруулна уу https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Товчилсон үг ба товчлол

Хүснэгт А: Товчилсон үг ба товчлол

Хавсралт А - Эрратын хүндийн ангилал

Энэхүү хавсралтад техникийн тодорхойгүй байдлын ноцтой байдлын ангиллын удирдамжийг нэгтгэн харуулав. Энэ хүснэгтийг EPD-ийн ирээдүйн хувилбар дээр нэмэх бөгөөд дараа нь энэ хэсгийг устгах болно.

Энэ гарын авлагын талаар дэлгэрэнгүй уншиж, PDF татаж авах:

Тодорхойлолтын менежментийн үйл явцын баримт бичиг (SMPD) - Оновчтой PDF
Тодорхойлолтын менежментийн үйл явцын баримт бичиг (SMPD) - Эх PDF

Таны гарын авлагын талаар асуулт байна уу? Сэтгэгдэл дээр бичээрэй!

Лавлагаа

Хэрэглэгчийн гарын авлага