ເອກະສານຂະບວນການຄຸ້ມຄອງສະເພາະ (SMPD)

ເອກະສານຂະບວນການBluetooth®

• ການແກ້ໄຂ: V27
• ວັນທີທົບທວນ: 2019-05-17
•  ຄຳ ຕິຊົມອີເມວ: BARB-feedback@bluetooth.org

ບົດຄັດຫຍໍ້:
ເອກະສານນີ້ໄດ້ ກຳ ນົດຂັ້ນຕອນການພັດທະນາໃນການສ້າງແລະເສີມຂະຫຍາຍຂໍ້ມູນສະເພາະຂອງ Bluetooth ແລະເອກະສານສີຂາວ.

ປະຫວັດການແກ້ໄຂ

ຜູ້ປະກອບສ່ວນເຂົ້າຮຸ່ນຫຼ້າສຸດ

ເອກະສານສະບັບນີ້, ບໍ່ວ່າຈະເປັນຫົວຂໍ້ຫລືເນື້ອຫາໃດກໍ່ຕາມ, ມັນບໍ່ແມ່ນຫົວຂໍ້ຂໍ້ມູນ Bluetooth ກ່ຽວກັບໃບອະນຸຍາດທີ່ໄດ້ຮັບໂດຍ Bluetooth SIG Inc ("Bluetooth SIG") ແລະສະມາຊິກພາຍໃຕ້ສັນຍາສິດທິບັດ / ລິຂະສິດ Bluetooth ແລະສັນຍາອະນຸຍາດເຄື່ອງ ໝາຍ ການຄ້າ Bluetooth.

ເອກະສານສະບັບນີ້ແມ່ນໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ "ເປັນແລະ", ໃຫຍ່, ສະມາຊິກຂອງມັນ, ແລະຊັບສົມບັດຂອງເຂົາເຈົ້າບໍ່ມີຄວາມຮັບຜິດຊອບ, ຫຼືການຮັບປະກັນ, ຄວາມຈິງ, ຄວາມຈິງຂອງບຸກຄົນ, ຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງ, ເນື້ອໃນຂອງເອກະສານສະບັບນີ້ແມ່ນບໍ່ມີຄວາມຜິດ.

ສຳ ລັບຂໍ້ມູນທີ່ບໍ່ໄດ້ຮັບການອະນຸມັດໂດຍກົດ ໝາຍ, BLUETOOTH SIG, ສະມາຊິກຂອງມັນ, ແລະຊັບສົມບັດຂອງພວກເຂົາແມ່ນຂາດຄວາມຮັບຜິດຊອບທັງ ໝົດ ທີ່ເກີດຂື້ນຈາກຫຼືກ່ຽວຂ້ອງກັບການ ນຳ ໃຊ້ຂໍ້ມູນນີ້ແລະຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ, ການພິຈາລະນາ, ຫຼື ສຳ ລັບພິເສດ, ໂດຍອີງຕາມຄວາມຕ້ອງການ, ຄວາມເປັນເອກະພາບຫຼືຂໍ້ມູນທີ່ມີຜົນກະທົບ, ຍ້ອນວ່າມັນເກີດຂື້ນແລະມີຜົນກະທົບຕໍ່ເລື່ອງຂອງຄວາມຮັບຜິດຊອບ, ແລະເຖິງແມ່ນວ່າຜູ້ທີ່ມີຄວາມຫວັງ, ຜູ້ທີ່ເປັນຕົວຂອງມັນ, ຫຼືຜູ້ທີ່ມີຜົນປະໂຫຍດສູງສຸດກໍ່ຕາມ.

ເອກະສານນີ້ແມ່ນເປັນເຈົ້າຂອງ Bluetooth SIG. ເອກະສານນີ້ອາດຈະມີຫຼືບັນຈຸຫົວຂໍ້ທີ່ເປັນຊັບສິນທາງປັນຍາຂອງ Bluetooth SIG ແລະສະມາຊິກ. ການສະ ໜອງ ເອກະສານສະບັບນີ້ບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ແກ່ຊັບສິນທາງປັນຍາໃດໆຂອງ Bluetooth SIG ຫຼືສະມາຊິກ.

ເອກະສານນີ້ແມ່ນມີການປ່ຽນແປງໂດຍບໍ່ມີການແຈ້ງໃຫ້ຊາບ.

ລິຂະສິດ© 2004–2019 ໂດຍ Bluetooth SIG, Inc. ເຄື່ອງ ໝາຍ ແລະໂລໂກ້ Bluetooth ແມ່ນເປັນເຈົ້າຂອງໂດຍ Bluetooth SIG, Inc. ເຄື່ອງ ໝາຍ ແລະຊື່ຂອງພາກສ່ວນທີສາມອື່ນໆແມ່ນຊັບສົມບັດຂອງເຈົ້າຂອງຂອງພວກເຂົາ.

 

1. ບົດແນະນຳ

ເອກະສານຂະບວນການບໍລິຫານຈັດການສະເພາະ (SMPD) ອະທິບາຍຂັ້ນຕອນຕ່າງ specification ທີ່ຜູ້ຂຽນລາຍລະອຽດແລະຂຽນຄືນໃ່viewers ຕ້ອງປະຕິບັດຕາມເພື່ອພັດທະນາສະເພາະໃand່ແລະເພື່ອເສີມຂະຫຍາຍຂໍ້ກໍານົດສະເພາະທີ່ມີຢູ່ແລ້ວ (ເຊັ່ນ: ການເພີ່ມຫຼືເອົາການທໍາງານອອກຫຼືການປ່ຽນແປງການທໍາງານສະເພາະຢູ່ໃນຂໍ້ກໍານົດທີ່ໄດ້ຮັບຮອງເອົາ), ເພື່ອຮັກສາສະເພາະທີ່ໄດ້ຮັບຮອງເອົາ, ແລະຈັດການຈຸດສິ້ນສຸດຂອງຊີວິດຂອງສະເພາະທີ່ໄດ້ຮັບຮອງເອົາ. ນອກຈາກນັ້ນ, ເອກະສານນີ້ອະທິບາຍເຖິງຂັ້ນຕອນການສ້າງ, reviewແລະອະນຸມັດເອກະສານສີຂາວ.

ມີຄວາມແຕກຕ່າງໃນຂະບວນການພັດທະນາສະເພາະລະຫວ່າງການພັດທະນາວິຊາສະເພາະ ໃໝ່ ແລະການຍົກລະດັບວິຊາສະເພາະທີ່ມີຢູ່ເນື່ອງຈາກຄວາມແຕກຕ່າງທີ່ປະກົດຂຶ້ນໃນຂອບເຂດວຽກງານເຫຼົ່ານັ້ນ; ຄວາມແຕກຕ່າງເຫຼົ່ານັ້ນແມ່ນໄດ້ຖືກຍົກໃຫ້ເຫັນໃນເອກະສານສະບັບນີ້.

ຂະບວນການພັດທະນາສະເພາະປະກອບມີ:

• ໄລຍະຮຽກຮ້ອງຕ້ອງການ (ອະທິບາຍໃນພາກ 3) ເພື່ອ ກຳ ນົດຄວາມຕ້ອງການທີ່ເປັນປະໂຫຍດ
• ໄລຍະການພັດທະນາ (ອະທິບາຍຢູ່ໃນພາກທີ 4) ເພື່ອພັດທະນາແລະພັດທະນາຄືນໃ່view ຂໍ້ມູນສະເພາະ
• ໄລຍະການກວດສອບຄວາມຖືກຕ້ອງ (ອະທິບາຍໃນພາກ 5) ເພື່ອເຮັດໃຫ້ຄວາມຖືກຕ້ອງສະເພາະໂດຍວິທີການທົດສອບແບບທົດລອງແບບທົດລອງ (IOP).
• ໄລຍະການຮັບຮອງເອົາ / ການອະນຸມັດ (ອະທິບາຍໃນພາກ 6) ເພື່ອ ນຳ ສະ ເໜີ ຂໍ້ສະເພາະກ່ຽວກັບສະພາບໍລິຫານ Bluetooth SIG (BoD) ເພື່ອຮັບຮອງເອົາ / ອະນຸມັດ

ເອກະສານຂະບວນການຜິດພາດສະເພາະ (EPD) [3] ອະທິບາຍຂັ້ນຕອນການສະ ເໜີ ແລະສ້າງຄືນໃ່viewມີຂໍ້ຜິດພາດສະເພາະ, ແລະອະນຸມັດພວກມັນເປັນການກວດແກ້ຜິດພາດ (ຕາມທີ່ໄດ້ ກຳ ນົດໄວ້ໃນກົດ[າຍ [2]) ເພື່ອຮັບຮອງເອົາຂໍ້ສະເພາະ. ເວັ້ນເສຍແຕ່ໄດ້ບັນທຶກໄວ້ເປັນຢ່າງອື່ນ, ການອ້າງອີງທັງtoົດຕໍ່ກັບຄວາມຜິດພາດໃນ SMPD ນີ້meanາຍເຖິງຄວາມຜິດພາດສະເພາະ.

1.1 ຄວາມ ສຳ ຄັນ

ກົດ ໝາຍ ຂອງ Bluetooth SIG, Inc (ຂໍ້ຕົກລົງ) ແລະຂໍ້ຕົກລົງສະມາຊິກ [2] ມີຄວາມ ສຳ ຄັນກວ່າເນື້ອໃນທີ່ຂັດແຍ້ງກັນໃນເອກະສານເຫຼົ່ານັ້ນແລະ SMPD. ເຖິງວ່າຈະມີສິ່ງໃດໃນເອກະສານນີ້, BoD ຈະຮັກສາການຕັດສິນໃຈແລະສິດ ອຳ ນາດສູງສຸດໃນການປະຕິບັດແລະຕັດສິນໃຈເຖິງແມ່ນວ່າການກະ ທຳ ແລະການຕັດສິນໃຈເຫຼົ່ານັ້ນບໍ່ປະຕິບັດຕາມ, ຫຼືຂັດແຍ້ງກັບສິ່ງໃດກໍ່ຕາມໃນເອກະສານນີ້, ແລະບໍ່ມີຫຍັງໃນເອກະສານນີ້ ຈຳ ກັດຫຼື ຈຳ ກັດສິດ ອຳ ນາດອິດສະຫຼະຂອງ BoD. ແລະການຕັດສິນໃຈ.

ຖ້າມີຂໍ້ຂັດແຍ່ງລະຫວ່າງຂໍ້ຄວາມໃນ SMPD ແລະຕົວເລກ, ຂໍ້ຄວາມຈະມີຄວາມ ສຳ ຄັນກວ່າ.

1.2 ກຸ່ມແລະຄະນະ ກຳ ມະການທີ່ອ້າງອີງ

ກຸ່ມປະເພດຕໍ່ໄປນີ້ແມ່ນໄດ້ອ້າງອີງຢູ່ໃນເອກະສານນີ້: ກຸ່ມສຶກສາ (SG), ກຸ່ມຜູ້ຊ່ຽວຊານ (EG), ແລະກຸ່ມເຮັດວຽກ (WG). WG ອາດຈະມີກຸ່ມຍ່ອຍທີ່ລາຍງານໃຫ້ WG. ເຊັ່ນດຽວກັນ, ປະເພດຄະນະກໍາມະການຕໍ່ໄປນີ້ແມ່ນໄດ້ອ້າງອີງຢູ່ໃນເອກະສານນີ້: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI), ແລະ Bluetooth Qualification Review ຄະນະ (BQRB). ເອກະສານນີ້ຍັງrefersາຍເຖິງພະນັກງານວິຊາການ Bluetooth SIG (BSTS), ແລະ BoD.

1.3 ຄະນະ ກຳ ມະການviews ແລະການອະນຸມັດ

ຄະນະ ກຳ ມະການຄືນໃ່view ແມ່ນ review ທີ່ດໍາເນີນໂດຍສະມາຊິກຂອງຄະນະກໍາມະການ (ໂດຍປົກກະຕິແລ້ວມີສະມາຊິກ 3 ຄົນ) ເພື່ອໃຫ້ຄໍາຕິຊົມພາຍໃນເວລາທີ່ກໍານົດໄວ້ (ໂດຍປົກກະຕິແມ່ນ 2-3 ອາທິດ), ແນວໃດກໍ່ຕາມview ເວລາອາດຈະແຕກຕ່າງກັນໄປຕາມຄວາມຍາວແລະຄວາມຊັບຊ້ອນຂອງເອກະສານແລະບູລິມະສິດອື່ນ within ພາຍໃນຄະນະກໍາມະການ. ກຸ່ມທີ່ຮ້ອງຂໍຄືນview ແລະຄະນະກໍາມະການດໍາເນີນການ review ແຕ່ລະຄົນຕົກລົງກັນກ່ຽວກັບໄລຍະເວລາຂອງການສ້າງໃ່view. ກຸ່ມແລະສະມາຊິກຄະນະກໍາມະການນໍາໃຊ້ເຄື່ອງມື Bluetooth SIG ເພື່ອແຈ້ງແລະບັນທຶກການເລີ່ມຕົ້ນແລະການສິ້ນສຸດຂອງການເຮັດຄືນໃ່view. ໂດຍທົ່ວໄປກຸ່ມຈະປະມວນຜົນຄໍາຕິຊົມຂອງຄະນະກໍາມະການເມື່ອໄດ້ຮັບມັນ. ເມື່ອຄະນະ ກຳ ມະການຄືນໃ່view ເວລາົດອາຍຸ, ກຸ່ມໄດ້ແກ້ໄຂຄໍາຕອບຂອງຄະນະກໍາມະການໃຫ້ຄົບຖ້ວນ, ແລະຄວນພິຈາລະນາຄືນໃlate່view ຄໍາຄຶດຄໍາເຫັນຢູ່ໃນໃຈວ່າເນື້ອໃນອາດຈະຢູ່ພາຍໃຕ້ການອະນຸມັດຈາກຄະນະກໍາມະການ.

ການອະນຸມັດຂອງຄະນະ ກຳ ມະການແມ່ນໄດ້ຮັບໂດຍການລົງຄະແນນສຽງຂອງສະມາຊິກຄະນະ ກຳ ມະການໃນການປະຕິບັດຕາມເອກະສານຂະບວນການຂອງກຸ່ມເຮັດວຽກ [4].

1.4 ແຈ້ງການເຖິງສະມາຊິກແລະການເຂົ້າເຖິງວັດສະດຸ

ແຈ້ງການທັງ ໝົດ ທີ່ໃຫ້ກັບສະມາຊິກໂດຍປະຕິບັດຕາມເອກະສານນີ້ອາດຈະໄດ້ຮັບການສະ ໜອງ ທາງອີເມວເຊັ່ນການປັບປຸງເຕັກນິກແຕ່ລະໄລຍະ. ການແຈ້ງເຕືອນທີ່ຈະຕ້ອງໃຫ້ແກ່ສະມາຊິກທຸກຄົນຈະຖືກສົ່ງໄປຫາສະມາຊິກທີ່ມີການເຄື່ອນໄຫວທັງ ໝົດ (ເຊັ່ນວ່າສະມາຊິກບໍ່ໄດ້ຖືກໂຈະ, ຍຸບເລີກ, ຫຼືຖອນຕົວ). ເມື່ອການແຈ້ງເຕືອນຖືກສົ່ງຜ່ານທາງອີເມວພວກເຂົາຈະຖືກສົ່ງໄປຫາທີ່ຢູ່ອີເມວທີ່ຮູ້ຈັກສຸດທ້າຍ (ຕາມທີ່ບັນທຶກໄວ້ໃນຂໍ້ມູນບັນທຶກຂອງ Bluetooth SIG ໃນປະຈຸບັນ) ຂອງແຕ່ລະບຸກຄົນທີ່ໄດ້ລົງທະບຽນຢູ່ພາຍໃຕ້ບັນຊີສະມາຊິກຂອງບໍລິສັດສະມາຊິກແລະຜູ້ທີ່ບໍ່ໄດ້ເລືອກອອກຈາກການຮັບແຈ້ງການອີເມວ. ບໍ່ມີຫຍັງໃນເອກະສານສະບັບນີ້ປ່ຽນແປງພັນທະຫລືຂໍ້ ກຳ ນົດຂອງ Bluetooth SIG ກ່ຽວກັບການສະ ໜອງ ການແຈ້ງການພາຍໃຕ້ກົດ ໝາຍ ຫລືຂໍ້ຕົກລົງອື່ນໆລະຫວ່າງ Bluetooth SIG ແລະສະມາຊິກໃດ ໜຶ່ງ.

ບ່ອນໃດທີ່ເອກະສານນີ້refersາຍເຖິງກ webເວັບໄຊທທີ່ສາມາດເຂົ້າເຖິງໄດ້ກັບສະມາຊິກທຸກຄົນ, ອັນນີ້toາຍເຖິງການເຂົ້າຫາບຸກຄົນຜູ້ທີ່ມີບັນຊີ Bluetooth SIG ທີ່ເປີດໃຊ້ຢູ່. ສະມາຊິກຜູ້ທີ່ບໍ່ມີບັນຊີສາມາດສ້າງບັນຊີຜ່ານ Bluetooth SIG webເວັບໄຊ.

1.5 ແມ່ແບບ

ສໍາລັບເອກະສານແຕ່ລະປະເພດ (ຕົວຢ່າງ, ສະເພາະ, ເອກະສານສີຂາວ, ເອກະສານທົດສອບ) ທີ່ກ່າວເຖິງໃນ SMPD ນີ້, Bluetooth SIG ໃຫ້ແມ່ແບບ. ແມ່ແບບຈະຕ້ອງຖືກນໍາໃຊ້ເປັນພື້ນຖານສໍາລັບແຕ່ລະເອກະສານທີ່ຜະລິດໃຫ້ສອດຄ່ອງກັບ SMPD ນີ້. ການໃຊ້ແມ່ແບບທີ່ບໍ່ຖືກຕ້ອງອາດຈະເຮັດໃຫ້ເອກະສານບໍ່ໄດ້ຮັບການອະນຸມັດ. ແມ່ແບບມີຢູ່ໃນ Bluetooth SIG webສະຖານທີ່ [8].

1.6 ປະເພດສະເພາະ

ມີຫຼາຍປະເພດຂອງສະເພາະຂອງ Bluetooth SIG. ລຳ ດັບຊັ້ນ, ສະເປັກທັງdependົດແມ່ນຂື້ນກັບສະເປັກຫຼັກຂອງ Bluetooth. ຂໍ້ມູນຈໍາເພາະເຊັ່ນ: ການສົ່ງເສີມແບບດັ້ງເດີມfiles; ພິທີການດັ້ງເດີມ; ແລະມືອາຊີບທີ່ອີງໃສ່ GATTfiles, ການບໍລິການທີ່ອີງໃສ່ GATT, ແລະພິທີການທີ່ອີງໃສ່ GATT ທັງົດແມ່ນຂຶ້ນກັບລັກສະນະພາຍໃນຂໍ້ກໍານົດຫຼັກ. ລາຍລະອຽດສະເພາະອື່ນ Other, ເຊັ່ນ: ຂໍ້ມູນຈໍາເພາະຂອງ Mesh Model, ແມ່ນຂຶ້ນກັບ Mesh Profile ສະເພາະເຊິ່ງໃນນັ້ນແມ່ນຂື້ນກັບສະເປັກຫຼັກ.

ຂໍ້ມູນ ຈຳ ເພາະຫຼັກຖານເສີມ (CSS) ກຳ ນົດປະເພດຂໍ້ມູນ, ຮູບແບບຂໍ້ມູນ, ແລະໂປຼແກຼມ ທຳ ມະດາfile ແລະລະຫັດຂໍ້ຜິດພາດການບໍລິການທີ່ຖືກນໍາໃຊ້ໂດຍຂໍ້ກໍານົດຫຼັກແລະຂໍ້ກໍານົດສະເພາະອື່ນ and ແລະບໍ່ໄດ້ກໍານົດຕົນເອງພຶດຕິກໍາໃດ any.

ຂໍ້ມູນຈໍາເພາະການສະ ໜອງ GATT Specification (GSS) ກໍານົດລັກສະນະແລະຮູບແບບຄໍາອະທິບາຍທີ່ Pro ຖືກນໍາໃຊ້files ແລະການບໍລິການແລະບໍ່ໄດ້ກໍານົດເອງກ່ຽວກັບພຶດຕິກໍາໃດ.
ຄຸນສົມບັດອຸປະກອນຕາ ໜ່າງ (MDP) ລະບຸຄຸນສົມບັດຂອງຕາ ໜ່າງ ທີ່ໃຊ້ໂດຍ Mesh Profile ແລະຂໍ້ມູນຈໍາເພາະຂອງ Mesh Model ແລະບໍ່ໄດ້ກໍານົດພຶດຕິກໍາຕົວເອງ.

 

2. ເກີນview

ພາກນີ້ໃຫ້ຫຼາຍກວ່າview ຂອງຂະບວນການຕ່າງ is ແລະບໍ່ໄດ້ຕັ້ງໃຈຈະລວມເອົາລາຍລະອຽດທັງົດ.

ຮູບພາບ 2.1 ສະແດງໃຫ້ເຫັນຫົກໄລຍະໃຫຍ່ທີ່ປະກອບເປັນຂະບວນການຄຸ້ມຄອງສະເພາະ.

3 ໄລຍະ ທຳ ອິດແມ່ນເກີດຂື້ນໃນຂັ້ນຕອນການພັດທະນາສະເພາະແລະປະກອບມີໄລຍະຄວາມຕ້ອງການ (ພາກ 4), ໄລຍະການພັດທະນາ (ພາກ 5), ໄລຍະການຮັບຮອງ (ພາກ 6), ແລະຂັ້ນຕອນການຮັບຮອງເອົາ / ການອະນຸມັດ (ພາກ 7). ຕໍ່ໄປນີ້ແມ່ນສອງໄລຍະຫລັງການຮັບຮອງເອົາ: ໄລຍະການ ບຳ ລຸງຮັກສາສະເພາະ (ພາກ 8) ແລະໄລຍະສຸດທ້າຍຂອງຊີວິດສະເພາະ (ພາກ XNUMX).

ຮູບພາບ 2.2 ສະແດງລາຍລະອຽດຂອງສີ່ໄລຍະພາຍໃນຂະບວນການພັດທະນາສະເພາະ. ກ່ອງສີເທົາສະແດງເຖິງເຄື່ອງສົ່ງທີ່ ສຳ ຄັນ ສຳ ລັບແຕ່ລະໄລຍະ. ກ່ອງສີສົ້ມສະຫຼຸບບົດບາດ ສຳ ຄັນຂອງຂະບວນການ.

ໃນໄລຍະຄວາມຕ້ອງການ (ອະທິບາຍໃນພາກ 3), ຂໍ້ສະ ເໜີ ເພື່ອເລີ່ມຕົ້ນເຮັດວຽກ ໃໝ່ (ບົດສະ ເໜີ ວຽກ ໃໝ່ (NWP)) ໄດ້ລິເລີ່ມຂະບວນການພັດທະນາສະເພາະໂດຍ ກຳ ນົດສະຖານະການຂອງຜູ້ໃຊ້ເພື່ອໃຫ້ສາມາດເປີດໃຊ້ງານໄດ້ຖ້າວຽກ ໃໝ່ ໄດ້ຮັບຜົນ. ຖ້າ NWP ໄດ້ຮັບການອະນຸມັດ, ກຸ່ມທີ່ຖືກມອບ ໝາຍ ຈະສ້າງເອກະສານຄວາມຕ້ອງການດ້ານການເຮັດວຽກ (FRD). ເມື່ອ FRD ໄດ້ຮັບການອະນຸມັດແລະມອບ ໝາຍ ໃຫ້ກຸ່ມ, ໄລຍະການພັດທະນາເລີ່ມຕົ້ນ.

ໃນລະຫວ່າງໄລຍະການພັດທະນາ (ອະທິບາຍຢູ່ໃນພາກທີ 4), ການພັດທະນາສະເພາະແມ່ນດໍາເນີນໄປຕາມລໍາດັບຂອງ stages (0.5/DIPD ເປັນ 0.9/CR) ສຸດທ້າຍຢູ່ໃນຮ່າງສະບັບສົມບູນຂອງຂໍ້ກໍານົດ. ຂໍ້ກໍານົດ 0.9/CR ແມ່ນມີໃຫ້ກັບສະມາຊິກທຸກຄົນ, ຫຼັງຈາກນັ້ນສົ່ງໃຫ້ BoD ຜູ້ພິຈາລະນາຂໍ້ກໍານົດສະເພາະສໍາລັບການອະນຸມັດ. ເມື່ອໄດ້ຮັບການອະນຸມັດແລ້ວ, ຂັ້ນຕອນການກວດສອບເລີ່ມຕົ້ນ.

ໃນລະຫວ່າງໄລຍະການກວດສອບຄວາມຖືກຕ້ອງຂອງການພັດທະນາສະເປັກ (ອະທິບາຍຢູ່ໃນພາກທີ 5), ຂໍ້ກໍານົດ 0.9/CR ທີ່ໄດ້ອະນຸມັດໂດຍ BoD ແມ່ນມີໃຫ້ກັບສະມາຊິກທັງtoົດເພື່ອທົບທວນຄືນ.view ແລະກວດສອບຄວາມຖືກຕ້ອງ, ແລະສະມາຊິກ Review ແມ່ນໄດ້ເລີ່ມຕົ້ນ. ການກວດສອບຄວາມຖືກຕ້ອງແມ່ນບັນລຸຜົນໄດ້ໂດຍຜ່ານການທົດສອບການເຮັດວຽກຮ່ວມກັນ (IOP) ລະຫວ່າງຕົ້ນແບບທີ່ສ້າງໂດຍສະມາຊິກ. ເມື່ອການທົດສອບ IOP ສຳ ເລັດແລ້ວ (ຖ້າຕ້ອງການສະເປັກສະເພາະ) ແລະ BARB ອະນຸມັດບົດລາຍງານການທົດສອບ IOP, ຈາກນັ້ນຂັ້ນຕອນການຮັບຮອງເອົາ/ການອະນຸມັດເລີ່ມຕົ້ນ.

ໃນໄລຍະການຮັບຮອງເອົາ / ການອະນຸມັດ (ທີ່ອະທິບາຍໃນພາກທີ 6), ເອກະສານສະເພາະແລະເອກະສານການສອບເສັງທີ່ກ່ຽວຂ້ອງແມ່ນໄດ້ຖືກສະຫລຸບແລ້ວ; ໄດ້ຮັບການອະນຸມັດຈາກ BARB, BQRB, ແລະ BTI; ແລະຊຸດເອກະສານສະເພາະສະບັບສຸດທ້າຍແມ່ນຖືກຍື່ນສະ ເໜີ ຕໍ່ BoD ຜູ້ທີ່ພິຈາລະນາສະເພາະ ສຳ ລັບການຮັບຮອງເອົາ (ໝາຍ ຄວາມວ່າການອະນຸມັດຂັ້ນສຸດທ້າຍ).

ຂໍ້ມູນ ຈຳ ເພາະອາດຈະຕ້ອງການກັບຄືນຫາໄລຍະກ່ອນ ໜ້າ ຫຼືວິນາທີtage ຖ້າມີການປ່ຽນແປງທີ່ສໍາຄັນ. ໃນບາງກໍລະນີ, ມັນອາດຈະເປັນໄປໄດ້ທີ່ຈະສະຫຼະພາກສ່ວນຂອງໄລຍະດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ຢູ່ໃນພາກ 4.4.

ໄລຍະການ ບຳ ລຸງຮັກສາສະເພາະ (ໄດ້ອະທິບາຍໃນພາກ 7) ເລີ່ມຕົ້ນຫຼັງຈາກການ ກຳ ນົດໂດຍຄະນະ ກຳ ມະການບໍລິຫານງານ. ໃນລະຫວ່າງໄລຍະນີ້ຄວາມຜິດພາດທີ່ອາດເກີດຂື້ນທີ່ພົບເຫັນຢູ່ໃນຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາແມ່ນຖືກລາຍງານແລະປະເມີນຜົນ, ແລະ (ຖ້າຕ້ອງການ) ການແກ້ໄຂ Errata ແມ່ນຖືກເຮັດໃຫ້ຖືກຕ້ອງກັບສະເພາະ. ໄລຍະການ ບຳ ລຸງຮັກສາສະເພາະຍັງສືບຕໍ່ຈົນກວ່າຂໍ້ ກຳ ນົດໄດ້ຖືກຄັດເລືອກຫຼືຖອນອອກ (ເບິ່ງໄລຍະສິ້ນສຸດຂອງຊີວິດໂດຍສະເພາະໃນວັກຕໍ່ໄປນີ້).

ໄລຍະສຸດທ້າຍຂອງຊີວິດໂດຍສະເພາະ (ໄດ້ອະທິບາຍໃນພາກ 8) ອະທິບາຍຂັ້ນຕອນໃນການອະທິບາຍແລະການຖອນເງິນສະເພາະທີ່ໄດ້ຮັບຮອງເອົາ.

 

3. ໄລຍະຄວາມຕ້ອງການ

ຄວາມຕ້ອງການໄລຍະເລີ່ມຕົ້ນບໍ່ວ່າດ້ວຍ NWP (ເຊິ່ງບອກເຖິງຄວາມປາຖະ ໜາ ທີ່ຈະລິເລີ່ມການເຮັດວຽກກ່ຽວກັບສະຖານະການ ໜຶ່ງ ຂອງຜູ້ໃຊ້ຫຼືຫຼາຍກວ່ານັ້ນ) ຫຼືຫຼັງຈາກ ກຳ ນົດວ່າວຽກ ໃໝ່ ທີ່ຕ້ອງການໄດ້ຖືກປົກຄຸມແລ້ວໂດຍກົດບັດ WG ຂອງພວກເຂົາ. ຖ້າ WG ຕ້ອງການເລີ່ມຕົ້ນວຽກ ໃໝ່ ທີ່ມັນເຊື່ອວ່າຢູ່ໃນຂອບເຂດຂອງກົດ ໝາຍ WG ຂອງຕົນ, WG ຕ້ອງປະຕິບັດຕາມຂັ້ນຕອນທີ່ໄດ້ ກຳ ນົດໄວ້ໃນພາກ 3.1 ເພື່ອ ດຳ ເນີນການໂດຍກົງຕໍ່ການພັດທະນາ FRD. ສຳ ລັບລາຍການເຮັດວຽກອື່ນໆ, WG ຕ້ອງປະຕິບັດຕາມຂັ້ນຕອນທີ່ໄດ້ ກຳ ນົດໄວ້ໃນພາກ 3.2. FRD ກຳ ນົດຂອບເຂດຂອງຂໍ້ ກຳ ນົດທີ່ເປັນປະໂຫຍດທີ່ຖືກ ນຳ ໃຊ້ເພື່ອສ້າງສະເພາະໃນໄລຍະການພັດທະນາ. ໄລຍະຄວາມຕ້ອງການແມ່ນສະແດງຢູ່ໃນຮູບ 3.1.

3.1 ການເຮັດວຽກ ໃໝ່ ປົກຄຸມດ້ວຍກົດບັດ WG

ເມື່ອ WG ຕ້ອງການເລີ່ມຕົ້ນເຮັດວຽກ ໃໝ່ ແລະສົມເຫດສົມຜົນເຊື່ອວ່າການເຮັດວຽກທີ່ມັນຕ້ອງການເພີ່ມແມ່ນຢູ່ໃນຂອບເຂດຂອງກົດ ໝາຍ WG ຂອງຕົນ, WG ອາດຈະເລີ່ມເຮັດວຽກກັບ FRD, ເພາະວ່າພວກເຂົາແຈ້ງໃຫ້ BARB ຊາບທັນທີ. WG ຈະລວມເອົາການແຈ້ງການໃຫ້ BARB ລາຍລະອຽດກ່ຽວກັບວຽກ ໃໝ່ ທີ່ໄດ້ສະ ເໜີ ແລະ ສຳ ເນົາກົດບັດ WG ພ້ອມດ້ວຍພາສາທີ່ເນັ້ນໃສ່ເຊິ່ງອະນຸຍາດໃຫ້ພວກເຂົາເລີ່ມຕົ້ນເຮັດວຽກ ໃໝ່.

ຖ້າ BARB ປະຕິເສດການວິເຄາະຂອງ WG, WG ຕ້ອງຢຸດການເຮັດວຽກກັບ FRD ແລະ ດຳ ເນີນຂັ້ນຕອນ NWP ທີ່ລະບຸໄວ້ໃນພາກ 3.2. ຖ້າ BARB ອະນຸມັດການວິເຄາະຂອງ WG, WG ຈະແຈ້ງ BSTS ທັນທີ (ຜ່ານທາງອີເມວເຖິງ specification.manager@bluetooth.com) ແລະ BSTS ຈະເພີ່ມລາຍການເຂົ້າໃນວາລະການປະຊຸມ BoD ຕໍ່ໄປ.

WG ຈະລວມເອົາການແຈ້ງເຕືອນໃຫ້ກັບ BSTS ຂໍ້ມູນດຽວກັນກັບທີ່ທະນາຄານແຫ່ງສປປລາວມອບໃຫ້. ຖ້າ BoD ປະຕິເສດການວິເຄາະຂອງ WG, WG ຕ້ອງຢຸດເຮັດວຽກກັບ FRD ແລະ ດຳ ເນີນຂັ້ນຕອນ NWP ທີ່ລະບຸໄວ້ໃນພາກ 3.2. ຖ້າ BoD ອະນຸມັດການວິເຄາະຂອງ WG, WG ອາດຈະສືບຕໍ່ເຮັດວຽກກ່ຽວກັບ FRD ດັ່ງທີ່ໄດ້ລະບຸໄວ້ໃນພາກ 3.3.

3.2 ບົດສະ ເໜີ ວຽກ ໃໝ່ (NWP)

ສະມາຊິກທຸກຄົນ, WG, SG, ຫຼື EG ອາດຈະສ້າງແລະສົ່ງ NWP (ຜ່ານ Bluetooth SIG webສະຖານທີ່ [10]). NWP ຕ້ອງປະກອບດ້ວຍ, ຢ່າງ ໜ້ອຍ, ຂໍ້ມູນຂ່າວສານຕໍ່ໄປນີ້ໂດຍໃຊ້ແມ່ແບບທາງການທີ່ສະ ໜອງ ໃຫ້ໃນ [8]:

• ສະຖານະການຂອງຜູ້ໃຊ້
• ຄວາມມຸ່ງັ້ນຂອງສະມາຊິກເພື່ອພັດທະນາ FRD ແລະຢູ່ໃນຂົງເຂດໃດ (ຕົວຢ່າງ: ຜູ້ປະກອບສ່ວນ, ຜູ້ຂຽນ, Reviewເອີ, ການສ້າງຕົ້ນແບບ)
• ສະ ເໜີ ການ ນຳ ພາຂອງວຽກ FRD
• ການແຕ່ງຕັ້ງກຸ່ມທີ່ສະ ເໜີ ໃຫ້ເຮັດວຽກ FRD
• ທີ່ຢູ່ອີເມວຂອງຜູ້ຂຽນຕົ້ນຕໍ

ໝາຍເຫດ: ຄໍາແນະນໍາກ່ຽວກັບຂະບວນການ NWP ແມ່ນມີຢູ່ໃນ Bluetooth SIG webສະຖານທີ່ [10].

BSTS ຈະປະຕິບັດວຽກງານດັ່ງຕໍ່ໄປນີ້ໃນລະຫວ່າງການພັດທະນາ NWP:

• ໃຫ້ຜູ້ຂຽນຮັບຮູ້ການຮັບເອົາ (ໂດຍປົກກະຕິພາຍໃນເຈັດວັນຕາມເວລາປະຕິທິນຂອງການໄດ້ຮັບ) ແລະອະທິບາຍຂັ້ນຕອນຕໍ່ໄປ.
• ຖ້າ ຈຳ ເປັນ, ເຮັດວຽກຮ່ວມກັບຜູ້ຂຽນເພື່ອວ່າ NWP ຈະແຈ້ງແລະຄົບຖ້ວນ. ນີ້ອາດຈະຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງຫຼາຍຄັ້ງຂອງ NWP.
• ຖ້າ NWP ປະກອບມີຄໍາຖະແຫຼງກ່ຽວກັບຄວາມຜິດພາດໃນຂໍ້ກໍານົດ Bluetooth ທີ່ໄດ້ຮັບຮອງເອົາ, ເຮັດວຽກຮ່ວມກັບຜູ້ຂຽນຫາ file ເຂົ້າໄປໃນລະບົບຜິດພາດ.
• ຖ້າສັງເກດເຫັນວ່າ NWP ແມ່ນມີຄວາມອາດສາມາດເຮັດວຽກຊໍ້າຊ້ອນທີ່ ກຳ ລັງ ດຳ ເນີນຢູ່ແລ້ວຫລື ສຳ ເລັດແລ້ວ, ແຈ້ງໃຫ້ຜູ້ຂຽນຮັບຊາບກ່ຽວກັບວຽກອື່ນເພື່ອປະເມີນຜົນຂອງພວກເຂົາ.
• ປະກາດ NWP ໃສ່ NWP webສະຖານທີ່ສາມາດເຂົ້າເຖິງສະມາຊິກທັງຫມົດ.
• ແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຮູ້ວ່າ NWP ແມ່ນມີໃຫ້ກັບຄືນມາໄດ້view ແລະຕ້ອງການຄໍາcommitmentັ້ນສັນຍາຂອງສະມາຊິກເພີ່ມເຕີມເພື່ອພັດທະນາ FRD ຫຼືບໍ່.

ສະມາຊິກອາດຈະຕິດຕໍ່ຜູ້ຂຽນເພື່ອຖາມ ຄຳ ຖາມຫລືໃຫ້ ຄຳ ເຫັນກ່ຽວກັບ NWP.

ຢ່າງ ໜ້ອຍ ສາມບໍລິສັດສະມາຊິກຕ້ອງໄດ້ໃຫ້ ຄຳ ໝັ້ນ ສັນຍາວ່າຈະເຂົ້າຮ່ວມໃນການ ສຳ ເລັດ FRD ທີ່ໄດ້ຮັບ ສຳ ລັບ NWP ເພື່ອກາຍເປັນຜູ້ສະ ໝັກ ເພື່ອການອະນຸມັດຈາກ BoD, ແລະຢ່າງ ໜ້ອຍ ບໍລິສັດສະມາຊິກ ໜຶ່ງ ຄົນຕ້ອງເປັນສະມາຊິກຂອງ Associate ຫຼື Promoter. ພາຍຫຼັງການອະນຸມັດຂອງ NWP, BoD ຈະມອບ ໝາຍ NWP ໃຫ້ແກ່ກຸ່ມຍ່ອຍສະມາຊິກ WG ຫຼື SG ທັງ ໝົດ ທີ່ມີຢູ່ເພື່ອເຮັດວຽກກ່ຽວກັບ FRD (ອະທິບາຍໃນພາກ 3.3). ຖ້າກຸ່ມຍ່ອຍ WG ຫຼື SG ທີ່ ເໝາະ ສົມບໍ່ມີ, ມັນກໍ່ຈະຖືກສ້າງຂື້ນ.

ສຳ ລັບ NWP ທີ່ມີຄວາມຜູກພັນສະມາຊິກພຽງພໍ, BSTS ຈະປະຕິບັດວຽກງານເພີ່ມເຕີມຕໍ່ໄປນີ້:

• ຢ່າງ ໜ້ອຍ 13 ວັນກ່ອນທີ່ NWP ໄດ້ຖືກສະ ເໜີ ໃຫ້ໄດ້ຮັບການອະນຸມັດຈາກ BoD, ແຈ້ງໃຫ້ BARB, ແລະກຸ່ມທີ່ NWP ແນະ ນຳ ໃຫ້ ສຳ ລັບການມອບ ໝາຍ, ໃນການອະນຸມັດ NWP ທີ່ຍັງຄ້າງຢູ່. ນີ້ແມ່ນເຮັດເພື່ອໃຫ້ມີໂອກາດ ສຳ ລັບ ຄຳ ຄິດເຫັນໃນຂົງເຂດຕ່າງໆເຊັ່ນກຸ່ມທີ່ສະ ເໜີ, ບໍ່ວ່າ NWP ແມ່ນໄດ້ຖືກປົກຄຸມໄປແລ້ວໂດຍວຽກທີ່ມີຢູ່ແລ້ວ, etc.
• ຍື່ນສະ ເໜີ NWP ທີ່ເຮັດ ສຳ ເລັດແລ້ວໃຫ້ແກ່ BoD.

1. ຖ້າ NWP ຖືກສົ່ງໂດຍສະມາຊິກທີ່ບໍ່ກ່ຽວຂ້ອງກັບກຸ່ມ, ຈັດແຈງສະມາຊິກ ໜຶ່ງ ໃນສະມາຊິກສະພາ NWP ໃຫ້ແກ່ຄະນະ ກຳ ມະການ BoD.
2. ຖ້າ NWP ຖືກຍື່ນໂດຍກຸ່ມ, ຈັດແຈງໃຫ້ປະທານກຸ່ມ ນຳ ສະ ເໜີ NWP ຕໍ່ BoD.
3. ເຊີນປະທານ BARB ແລະປະທານຂອງກຸ່ມ, ເຊິ່ງ NWP ໄດ້ຖືກແນະ ນຳ ໃຫ້ເຮັດ ສຳ ລັບການມອບ ໝາຍ, ຕໍ່ກອງປະຊຸມ BoD.
4. ຖ້າ NWP ໄດ້ຮັບການອະນຸມັດແລະຖືກມອບ ໝາຍ ຈາກຄະນະ ກຳ ມະການ BoD, ແຈ້ງໃຫ້ກຸ່ມທີ່ຕົນໄດ້ຮັບມອບ ໝາຍ; ຜູ້ຂຽນ; ສະມາຊິກທີ່ໄດ້ລະບຸໃນ NWP ວ່າມີຄວາມຕັ້ງໃຈທີ່ຈະພັດທະນາ FRD ທີ່ສອດຄ້ອງກັນ; ແລະຖ້າ NWP ຖືກສະ ເໜີ ໂດຍກຸ່ມ, ກຸ່ມຂອງຜົນໄດ້ຮັບແລະຂັ້ນຕອນຕໍ່ໄປ.

ຫຼັງຈາກ NWP ໄດ້ຖືກອະນຸມັດໂດຍ BoD, ອັບເດດສະຖານະພາບຢູ່ໃນ NWP webເວັບໄຊ.

NWP ໃດ ໜຶ່ງ ອາດຈະຖືກປະຕິເສດໂດຍ BoD ຕາມການຕັດສິນໃຈຂອງຕົນ, ຕົວຢ່າງ:ample, ເນື່ອງຈາກຂໍ້ຈໍາກັດດ້ານຊັບພະຍາກອນ, ຖ້າວຽກງານໄດ້ສໍາເລັດສົມບູນແລ້ວ, ວຽກດັ່ງກ່າວແມ່ນຢູ່ນອກຂອບເຂດຂອງເອກະສານການຄຸ້ມຄອງຂອງ Bluetooth SIG (ຕົວຢ່າງ, Application Programming Interface (API)) [2], ຫຼືຖ້າວຽກທີ່ສະ ເໜີ ມາຄວນຈະເປັນ filed ເປັນຂໍ້ຜິດພາດ. ຖ້າ NWP ຖືກປະຕິເສດ, BSTS ຈະແຈ້ງໃຫ້ຜູ້ຂຽນ, ສະມາຊິກທີ່ລະບຸໄວ້ໃນ NWP ວ່າມີຄວາມມຸ່ງັ້ນທີ່ຈະພັດທະນາ FRD ທີ່ສອດຄ້ອງກັນ, ແລະຖ້າ NWP ຖືກສະ ເໜີ ໂດຍກຸ່ມ, ກຸ່ມ. ແຈ້ງການດັ່ງກ່າວຈະລວມມີເຫດຜົນອັນໃດທີ່ເຮັດໃຫ້ການປະຕິເສດ. ຜູ້ຂຽນ, ສະມາຊິກຫຼືກຸ່ມທີ່ມີຄວາມມຸ່ງັ້ນອາດຈະຮ້ອງຂໍເວລາໃນວາລະ BoD ເພື່ອຂໍອຸທອນການປະຕິເສດ.

ຖ້າສະມາຊິກຫຼືກຸ່ມຕ້ອງການສະ ເໜີ ການລົບລ້າງຄຸນລັກສະນະ ໜຶ່ງ ຈາກຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາ, ກຸ່ມຫຼືສະມາຊິກຕ້ອງກະກຽມ NWP. NWP ຕ້ອງປະກອບມີການວິເຄາະຜົນກະທົບທີ່ການໂຍກຍ້າຍຈະມີຜົນຕໍ່ກັບຄວາມເຂົ້າກັນໄດ້ທາງດ້ານຫຼັງແລະຄວາມສາມາດເຊື່ອມໂຍງກັນໄດ້, ລວມທັງການວິເຄາະຜົນກະທົບຕໍ່ກໍລະນີທົດສອບ.

NWP ແມ່ນບໍ່ ຈຳ ເປັນ ສຳ ລັບການປັບປຸງຄຸນລັກສະນະສະເພາະຂອງ CSS, GSS, ຫຼື MDP: ໂດຍປົກກະຕິ, ການປັບປຸງຂໍ້ມູນສະເພາະຂອງ CSS, GSS, ຫຼື MDP ແມ່ນມາຈາກການປັບປຸງຂໍ້ມູນສະເພາະທີ່ມີ NWP ຂອງພວກເຂົາເອງ.

3.3 ເອກະສານຄວາມຕ້ອງການດ້ານການເຮັດວຽກ (FRD)

FRDs ກຳ ນົດຄວາມຕ້ອງການທີ່ເປັນປະໂຫຍດເພື່ອເປີດໃຊ້ສະຖານະການຂອງຜູ້ໃຊ້. ຢ່າງ ໜ້ອຍ ສຸດ, FRD ຕ້ອງປະກອບມີຂໍ້ມູນກ່ຽວກັບສິ່ງຕໍ່ໄປນີ້ໂດຍ ນຳ ໃຊ້ຮູບແບບທີ່ເປັນທາງການທີ່ສະ ໜອງ ໃນ [8]:

• ສະຖານະການຂອງຜູ້ໃຊ້
• ຄວາມຕ້ອງການໃນການເຮັດວຽກໂດຍອີງໃສ່ສະຖານະການຂອງຜູ້ໃຊ້
• ຄວາມຕັ້ງໃຈຂອງສະມາຊິກໃນການພັດທະນາສະເພາະຂອງຜົນໄດ້ຮັບ
• ການສະ ໜັບ ສະ ໜູນ ຮູບແບບຕົວເລືອກໂດຍສະມາຊິກ ສຳ ລັບພາລະບົດບາດທີ່ຄາດໄວ້
• ແນະ ນຳ ໃຫ້ WG ພັດທະນາສະເພາະຂອງຜົນໄດ້ຮັບ

ການພັດທະນາ FRD

FRDs ແມ່ນຖືກສ້າງຂື້ນໂດຍສະມາຊິກກຸ່ມຍ່ອຍຂອງ WG ຫຼືສະມາຊິກ SG ທັງ ໝົດ ທີ່ໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ຈາກບັນນາທິການຈາກ BSTS. ສະມາຊິກຜູ້ໃດທີ່ສົນໃຈຢາກເຂົ້າຮ່ວມການພັດທະນາ FRD ສາມາດເຂົ້າຮ່ວມກຸ່ມໄດ້.

FRDs ຕ້ອງໄດ້ຊີ້ບອກເຖິງຄວາມຜູກມັດຈາກຢ່າງ ໜ້ອຍ ສອງ (ເຖິງວ່າສາມຄົນໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ) ບໍລິສັດສະມາຊິກໃນລະດັບຄູ່ຮ່ວມງານ - ຫລືໂປໂມຊັ່ນໃນການເຂົ້າຮ່ວມໃນການພັດທະນາການ ກຳ ນົດຜົນທີ່ໄດ້ຮັບ. WGs ຫຼື SGs ທີ່ສົ່ງ FRD ຄວນພະຍາຍາມທີ່ຈະໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ຢ່າງກວ້າງຂວາງຈາກບໍລິສັດສະມາຊິກກຸ່ມທີ່ເປັນຕົວແທນໃຫ້ພາກສ່ວນອຸດສາຫະ ກຳ ເປົ້າ ໝາຍ ທີ່ມີຈຸດປະສົງທີ່ຖືກ ກຳ ນົດໃນ FRD.

ໜ້າ ທີ່ໃNew່ທີ່ສະ ເໜີ ຢູ່ໃນ FRD ຄວນຈະສະ ໜັບ ສະ ໜູນ ການຂົນສົ່ງແລະອຸປະກອນທີ່ມີຢູ່ເທົ່າທີ່ຈະຫຼາຍໄດ້. ອັນນີ້ລວມເຖິງ, ສໍາລັບຕົວຢ່າງample, ສະ ໜັບ ສະ ໜູນ GATT-based profiles ແລະການບໍລິການທັງການຂົນສົ່ງອັດຕາພື້ນຖານ/ອັດຕາຂໍ້ມູນຂະຫຍາຍ (BR/EDR) ແລະການຂົນສົ່ງ Bluetooth Low Energy (LE). ຖ້າ ໜ້າ ທີ່ໃnew່ຂາດການສະ ໜັບ ສະ ໜູນ ສະມາຊິກພຽງພໍ ສຳ ລັບການຂົນສົ່ງ, ຕົວຢ່າງ:ample ເນື່ອງຈາກການຂາດຄວາມມຸ່ງັ້ນຂອງສະມາຊິກໃນການກໍານົດການນໍາໃຊ້ການຂົນສົ່ງຫຼືຈໍານວນທີ່ບໍ່ພຽງພໍຂອງເວທີການທົດສອບ IOP ສໍາລັບ ໜຶ່ງ ຫຼືຫຼາຍບົດບາດ, ການສະ ໜັບ ສະ ໜູນ ການຂົນສົ່ງນັ້ນອາດຈະບໍ່ຖືກຄິດໄລ່ຈາກ FRD.

ເວັ້ນເສຍແຕ່ວ່າມີເຫດຜົນເປັນຢ່າງອື່ນ, ໜ້າ ທີ່ໃ,່, ມືອາຊີບfiles, ແລະການບໍລິການຕ້ອງປະຕິບັດຕາມຂໍ້ກໍານົດດ້ານຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງທີ່ໄດ້ອະທິບາຍໄວ້ຢູ່ໃນຂໍ້ 3.3.2.

WG ຫຼື SG ຕ້ອງສົ່ງ FRD ໄປຫາ BARB ເພື່ອຮ້ອງຂໍຄືນໃ່view ແລະການອະນຸມັດ. BARB ຕ້ອງອະນຸມັດຫຼືປະຕິເສດ FRD ອີງຕາມການຕັດສິນທາງດ້ານວິສະວະກໍາຂອງມັນ. ຖ້າໄດ້ຮັບການອະນຸມັດຈາກ BARB, FRD ຈະມີໃຫ້ກັບສະມາຊິກທຸກຄົນແລະການແຈ້ງເຕືອນກ່ຽວກັບຄວາມພ້ອມຂອງມັນຈະຖືກອອກໃຫ້ໂດຍ BSTS.

FRDs ແມ່ນບໍ່ ຈຳ ເປັນ ສຳ ລັບການປັບປຸງຄຸນລັກສະນະສະເພາະຂອງ CSS, GSS, ຫຼື MDP: ໂດຍປົກກະຕິ, ການປັບປຸງຂໍ້ມູນສະເພາະຂອງ CSS, GSS, ຫຼື MDP ແມ່ນມາຈາກການປັບປຸງຂໍ້ມູນສະເພາະທີ່ມີ FRDs ຂອງຕົວເອງ.

ຂໍ້ ກຳ ນົດດ້ານຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ

ຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ ສຳ ລັບ BR / EDR

ສຳ ລັບການປະຕິບັດງານ BR / EDR, ຂໍ້ ກຳ ນົດດ້ານຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງຖືກ ກຳ ນົດວ່າເປັນການຕັດກັນກັບສ່ວນ BR / EDR ຂອງລະບົບ Bluetooth Core Specification v1.1 ແລະຕໍ່ມາ.

ຄວາມເຂົ້າກັນໄດ້ກັບຄືນສູ່ລະບົບ Bluetooth Low Energy

ສຳ ລັບການ ດຳ ເນີນງານຂອງ LE, ຂໍ້ ກຳ ນົດດ້ານຄວາມເຂົ້າກັນໄດ້ກັບຄືນຫຼັງແມ່ນຖືກ ກຳ ນົດວ່າເປັນການຕັດກັນກັບສ່ວນ LE ຂອງ Bluetooth Core Specification v4.0 ແລະຕໍ່ມາ.

ຄວາມເຂົ້າກັນໄດ້ກັບທາງຫລັງ ສຳ ລັບສະເພາະນອກ ເໜືອ ຈາກ Core Specification

ສໍາລັບສະເພາະອື່ນ than ທີ່ບໍ່ແມ່ນຂໍ້ກໍານົດຫຼັກຂອງ Bluetooth, ຄວາມເຂົ້າກັນໄດ້ກັບຄືນຂອງລຸ້ນທີ່ໃຫ້ມາຕ້ອງໄດ້ຮັບການຮັກສາໄວ້ກັບທຸກຮຸ່ນກ່ອນ ໜ້າ ທີ່ມີເລກຮຸ່ນທີ່ສໍາຄັນຄືກັນ. ສໍາລັບ example, ຮຸ່ນ 1.3 ຕ້ອງເຂົ້າກັນໄດ້ກັບຮຸ່ນ 1.2, 1.1, ແລະ 1.0, ແຕ່ລຸ້ນ 2.0 ອາດຈະເຂົ້າກັນບໍ່ໄດ້ກັບຮຸ່ນ 1.0, 1.1, 1.2, ແລະ 1.3. ໃຫ້ສັງເກດວ່າການເພີ່ມຂຶ້ນເປັນຈໍານວນຮຸ່ນທີ່ສໍາຄັນຂອງຂໍ້ກໍານົດຫຼັກບໍ່ໄດ້lyາຍເຖິງການຂາດຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງກັບລຸ້ນກ່ອນ ໜ້າ.

ການຍົກເວັ້ນຈາກຂໍ້ ກຳ ນົດດ້ານຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ

WG ຫຼື SG ອາດຈະສະ ເໜີ ໃຫ້ຍົກເວັ້ນການເຮັດວຽກສະເພາະຈາກຄວາມຕ້ອງການຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງຖ້າມີການໃຫ້ເຫດຜົນ. ສໍາລັບ example, ຖ້າຟັງຊັນການເຮັດວຽກສະແດງໃຫ້ເຫັນວ່າມີອັດຕາການຮັບຮອງເອົາຕະຫຼາດຕໍ່າຫຼືເນື່ອງຈາກບັນຫາການເຮັດວຽກຮ່ວມກັນ, ມັນຈະດີກວ່າທີ່ຈະເອົາຫຼືປ່ຽນແທນການທໍາງານແທນທີ່ຈະດັດແປງການທໍາງານ. WG ຫຼື SG ຕ້ອງປະກອບມີການຍົກເວັ້ນຄວາມເຂົ້າກັນໄດ້ກັບຄືນໃນ FRD, ເຊິ່ງໄດ້ຮັບການອະນຸມັດຈາກ BARB ເມື່ອໄດ້ຮັບການອະນຸມັດຈາກ FRD. ການຍົກເວັ້ນໃດ approved ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BARB ຈະຖືກນໍາສະ ເໜີ ໃຫ້ BoD ສໍາລັບການອະນຸມັດຢູ່ທີ່ 0.9/CR Stage.

3.4 ກົດ ໝາຍ ກຸ່ມເຮັດວຽກ

ເມື່ອ BARB ອະນຸມັດ FRD ທີ່ຖືກສະ ເໜີ ໃຫ້ຖືກມອບ ໝາຍ ໃຫ້ກັບ WG ທີ່ມີຢູ່ແລ້ວ, ວ່າ WG ຕ້ອງກະກຽມຮ່າງການປັບປຸງຮ່າງກົດ ໝາຍ ຂອງຕົນເພື່ອເພີ່ມ ໜ້າ ທີ່ ໃໝ່ ໃນຂອບເຂດ (ເວັ້ນເສຍແຕ່ກ່ອນ BoD ໄດ້ອະນຸມັດການວິເຄາະຂອງ WG ວ່າການປັບປຸງ Wter charter ແມ່ນ ບໍ່ຕ້ອງການ). ເຖິງຢ່າງໃດກໍ່ຕາມ, ເມື່ອ BARB ອະນຸມັດ FRD ທີ່ຖືກສະ ເໜີ ໃຫ້ຖືກມອບ ໝາຍ ໃຫ້ເປັນ WG, BARB ແລະສະມາຊິກຜູ້ທີ່ສົນໃຈໃນການພັດທະນາ ໜ້າ ທີ່ທີ່ລະບຸໄວ້ໃນ FRD ຕ້ອງກະກຽມຮ່າງກົດ ໝາຍ ສຳ ລັບ WG ໃໝ່ ພ້ອມກັບ ໜ້າ ທີ່ ໃໝ່ໆ ທີ່ລວມຢູ່ໃນຂອບເຂດຂອງກົດ ໝາຍ. .

ເມື່ອຮ່າງກົດWາຍ WG ສະບັບໃor່ຫຼືສະບັບປັບປຸງຖືກກະກຽມ, ມັນຈະຕ້ອງຖືກສົ່ງໄປຫາ BARB ເພື່ອຮ້ອງຂໍຄືນໃ່view ແລະການອະນຸມັດ. ເມື່ອ BARB ອະນຸມັດກົດບັດ, ຮ່າງຂອງກົດບັດ WG ສະບັບໃor່ຫຼືສະບັບປັບປຸງຈະຖືກສົ່ງໃຫ້ BoD ເພື່ອອະນຸມັດ.

ເມື່ອ BoD ອະນຸມັດກົດ ໝາຍ, WG ທີ່ວຽກພັດທະນາສະເພາະໄດ້ຮັບການມອບ ໝາຍ ຈາກ BoD ຕ້ອງເຮັດວຽກຢ່າງໃກ້ຊິດກັບກຸ່ມຜູ້ທີ່ກະກຽມ FRD ໃນກໍລະນີມີການປັບປຸງຫຼືຄວາມກະຈ່າງແຈ້ງທີ່ ຈຳ ເປັນຕໍ່ FRD. ຖ້າມີຄວາມ ຈຳ ເປັນໃນການປັບປຸງ FRD ໃນໄລຍະການພັດທະນາ, ຂະບວນການທີ່ລະບຸໄວ້ໃນພາກ 3.3 ແລະພາກນີ້ຕ້ອງປະຕິບັດຕາມ; ເຖິງຢ່າງໃດກໍ່ຕາມ, ການພັດທະນາສະເພາະອາດຈະເກີດຂື້ນຄຽງຄູ່ກັບການປັບປຸງກົດ ໝາຍ FRD ແລະ WG.

3.5 ຄວາມຕ້ອງການຄວາມຕ້ອງການໄລຍະການອອກ

ຄວາມຕ້ອງການໄລຍະດັ່ງກ່າວແມ່ນ ສຳ ເລັດແລະໄລຍະການພັດທະນາເລີ່ມຕົ້ນເມື່ອກົດບັດ WG ທີ່ມີຂອບເຂດທີ່ ຈຳ ເປັນ ສຳ ລັບ FRD ແມ່ນໄດ້ຮັບການຢັ້ງຢືນຫຼືອະນຸມັດຈາກ BoD ແລະຂໍ້ ກຳ ນົດດັ່ງຕໍ່ໄປນີ້ໄດ້ຖືກບັນລຸ:

• NWP ໄດ້ຮັບການອະນຸມັດຈາກ BoD, ຫຼື BoD ໄດ້ຕົກລົງວ່າ NWP ແມ່ນບໍ່ ຈຳ ເປັນ.
• ກົດ ໝາຍ FRD ແລະ WG ທີ່ສອດຄ້ອງກັນໄດ້ຖືກອະນຸມັດໂດຍ BARB.

 

4. ໄລຍະການພັດທະນາ

ໃນໄລຍະການພັດທະນາ, WG ທີ່ໄດ້ຮັບມອບ ໝາຍ ຈະສ້າງຂໍ້ ກຳ ນົດ ໃໝ່ ແລະ / ຫຼືຍົກລະດັບສະເພາະຂອງທີ່ມີຢູ່ແລ້ວ. FRD ກຳ ນົດຄວາມຕ້ອງການຂອງຂໍ້ ກຳ ນົດ Bluetooth ທີ່ເສີມ ໃໝ່ ຫຼືເພີ່ມຂື້ນ. ບໍ່ມີການເຮັດວຽກໃດໆທີ່ຖືກອະນຸຍາດໃນຂໍ້ ກຳ ນົດທີ່ບໍ່ກ່ຽວຂ້ອງກັບເຫດຜົນໃນ FRD. ຈຸດປະສົງແມ່ນເພື່ອສ້າງເງື່ອນໄຂສະເພາະ 0.9 / CR ທີ່ກຽມພ້ອມ ສຳ ລັບໄລຍະການກວດສອບຄວາມຖືກຕ້ອງ (ອະທິບາຍໃນພາກ 5) ໃນຕອນທ້າຍຂອງໄລຍະການພັດທະນາ.
ໃນລະຫວ່າງໄລຍະການພັດທະນາ, ຄວາມກ້າວ ໜ້າ ສະເພາະ (ຫຼືການປັບປຸງສະເປັກ) ຜ່ານສາມວິນາທີtages.

ສຳ ລັບສະເປັກໃnew່, ສາມ stages ແມ່ນ:

• 0.5 ສtage
• 0.7 ສtage
• 0.9 ສtage

ສໍາລັບການປັບປຸງສະເປັກ, ສາມວິtages ແມ່ນ:

• ເອກະສານສະ ເໜີ ການປັບປຸງຮ່າງ (DIPD) S.tage
• ເອກະສານບົດສະ ເໜີ ການປັບປຸງສຸດທ້າຍ (FIPD) S.tage
• ຄຳ ຂໍປ່ຽນແປງ (CR) Stage

ແຕ່ລະ stage ແມ່ນໄດ້ອະທິບາຍຕື່ມອີກຢູ່ໃນຫົວຂໍ້ຍ່ອຍທີ່ປະຕິບັດຕາມ. ຮູບ 4.1 ລຸ່ມນີ້ສະແດງໃຫ້ເຫັນເອກະສານຕ່າງ various ທີ່ WG ຈະກະກຽມໃນແຕ່ລະບ່ອນtage.

ຮູບ 4.1: ເກີນview ຂອງຂໍ້ມູນຈໍາເພາະ stagສິ່ງທີ່ເກີດຂຶ້ນໃນໄລຍະການພັດທະນາ

ພາລະບົດບາດຂອງ BARB ຕະຫຼອດຂະບວນການພັດທະນາສະເພາະແມ່ນການໃຫ້ ຄຳ ແນະ ນຳ ແລະການຊ່ວຍເຫຼືອດ້ານວິຊາການ. ເວລາໃດກໍ່ຕາມ, WG ສາມາດຮ້ອງຂໍໃຫ້ທະນາຍຄວາມ BARB ເພື່ອຂໍ ຄຳ ແນະ ນຳ ດ້ານວິຊາການກ່ຽວກັບການພັດທະນາສະເພາະແລະແນວຄວາມຄິດດ້ານສະຖາປັດຕະຍະ ກຳ ເພື່ອ ນຳ ໃຊ້ເຂົ້າໃນສະເພາະ. ໂດຍສະເພາະແລ້ວ, WGs ຈະໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ໃຫ້ຂໍ ຄຳ ຕິຊົມຈາກຕົ້ນສະບັບຈາກ BARB ສຳ ລັບຄຸນລັກສະນະຕ່າງໆທີ່ມີການພິຈາລະນາດ້ານສະຖາປັດຕະຍະ ກຳ ທີ່ຊັບຊ້ອນ.

4.1 0.5/DIPD Stage

ໃນລະຫວ່າງ 0.5/DIPD Stage, WG ຈະພັດທະນາຕໍ່ໄປນີ້ໂດຍໃຊ້ແມ່ແບບຢ່າງເປັນທາງການທີ່ສະ ໜອງ ໃຫ້ຢູ່ໃນ [8]:

1. ສຳ ລັບຂໍ້ ກຳ ນົດສະບັບ ໃໝ່, ຮ່າງເອກະສານສະເພາະຂອງ 0.5, ເຊິ່ງຕ້ອງມີຂໍ້ມູນ ໜ້ອຍ ທີ່ສຸດດັ່ງຕໍ່ໄປນີ້:

• ສະຖາປັດຕະຍະ ກຳ ເພື່ອຕອບສະ ໜອງ ຄວາມຮຽກຮ້ອງຕ້ອງການທີ່ໄດ້ລະບຸໄວ້ໃນ FRD
• ສຳ ລັບພິທີການ, ຈຸດເຂົ້າເຖິງການບໍລິການທີ່ໄດ້ ກຳ ນົດໄວ້
• ສຳ ລັບການບໍລິການ, ຂໍ້ມູນແລະພຶດຕິ ກຳ ທີ່ຖືກເປີດເຜີຍ
• ສໍາລັບ profiles, ພິທີການທີ່ໄດ້ກໍານົດແລະການທໍາງານໄດ້ລະບຸໄວ້

2. ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການ ກຳ ນົດສະເພາະ, ຮ່າງຂອງ DIPD, ເຊິ່ງຕ້ອງມີຂໍ້ມູນ ໜ້ອຍ ທີ່ສຸດດັ່ງຕໍ່ໄປນີ້:

• ພື້ນຫຼັງ: ຂອບເຂດການເຮັດວຽກ, ຈຸດປະສົງທີ່ ນຳ ພາວຽກງານແລະວິທີການສະ ເໜີ ນີ້ສະເພາະກັບຂອບເຂດ
• ເກີນview ການສະເຫນີ: ບົດສະຫຼຸບກ່ຽວກັບ ໜ້າ ທີ່ຂະຫຍາຍ (ເພີ່ມຄວາມຍືດຫຍຸ່ນ, ການປັບປຸງການປະຕິບັດງານ, ແລະອື່ນໆ) ທີ່ສະ ໜອງ ໂດຍ DIPD ລວມທັງ ຄຳ ອະທິບາຍທີ່ຊັດເຈນກ່ຽວກັບວິທີການເຮັດວຽກ ໃໝ່ ທີ່ ເໝາະ ສົມກັບລຸ້ນທີ່ ກຳ ນົດໃນປະຈຸບັນ. ຖ້າ WG ໄດ້ປະເມີນຫລາຍຂໍ້ສະ ເໜີ, ຂໍ້ສະ ເໜີ ເຫຼົ່ານີ້ຄວນຖືກລວມເຂົ້າເພື່ອໃຫ້ໂອກາດຂອງ BARB ສາມາດ ກຳ ນົດວ່າມີຄວາມດຸ ໝັ່ນ ສົມຄວນໃນການເລືອກ ຄຳ ສະ ເໜີ ທີ່ຕ້ອງການ.
• ການຄຸ້ມຄອງຄວາມຕ້ອງການ: ບົດສະຫລຸບຂອງການຄຸ້ມຄອງຂອງຂໍ້ ກຳ ນົດທີ່ເປັນປະໂຫຍດທີ່ສະ ເໜີ ໂດຍການສະ ເໜີ, ໂດຍອ້າງອີງເຖິງຄວາມຕ້ອງການຂອງລະບົບທີ່ ເໝາະ ສົມແລະສະຖານະການ ນຳ ໃຊ້ທີ່ໄດ້ໃຫ້ໃນ FRD ທີ່ກ່ຽວຂ້ອງ.
• ຄຳ ນິຍາມບັນຫາ: ຖະແຫຼງການຂອງບັນຫາທີ່ຖືກແກ້ໄຂໂດຍການສະ ເໜີ
• ເງື່ອນໄຂການຄັດເລືອກ: ຄຳ ຖະແຫຼງການກ່ຽວກັບເງື່ອນໄຂການຄັດເລືອກ / ການປະຕິບັດຈາກເຄື່ອງວັດປະເມີນຜົນທີ່ກ່ຽວຂ້ອງທີ່ໄດ້ ນຳ ພາຂັ້ນຕອນການຄັດເລືອກ
• ເຫດຜົນຂອງການເລືອກ: ການກວດກາຂອງການວັດແທກການປະເມີນຜົນທີ່ຊ່ວຍໃຫ້ທາງເລືອກລະຫວ່າງຂໍ້ສະ ເໜີ ແລະການເປີດເຜີຍການຄ້າຂາຍ
• ລາຍລະອຽດ: ລາຍລະອຽດຂອງ ໜ້າ ທີ່ແລະໂປໂຕຄອນຂະຫຍາຍ. ພາກນີ້ສາມາດປັບຕົວເຂົ້າກັບຄວາມຕ້ອງການທີ່ແຕກຕ່າງກັນໂດຍການເພີ່ມສ່ວນຍ່ອຍທີ່ກ່ຽວຂ້ອງ.

3. ຍຸດທະສາດການທົດສອບ: ລາຍລະອຽດຂອງການທໍາງານທີ່ສະ ເໜີ ໃຫ້ຖືກທົດສອບ (ຫຼືບໍ່ໄດ້ທົດສອບ) ເປັນສ່ວນ ໜຶ່ງ ຂອງໂຄງການຄຸນວຸດທິ Bluetooth ແລະວິທີການທໍາງານທີ່ສະ ເໜີ ໃຫ້ຖືກທົດສອບ (ຕົວຢ່າງ, ຄວາມຄາດຫວັງຢູ່ໃນຕົວທົດສອບຕ່ໍາ) ຫຼືເຄື່ອງທົດສອບເທິງ, ແລະ ຖ້າການກວດຈະຖືວ່າເປັນຄວາມສອດຄ່ອງຫຼືການທົດສອບການເຮັດວຽກຮ່ວມກັນຫຼືການລວມກັນຂອງທັງສອງ). ອັນນີ້ອາດຈະຢູ່ໃນເອກະສານແຍກຕ່າງຫາກຫຼືພາກແຍກຕ່າງຫາກພາຍໃນຂໍ້ກໍານົດ 0.5/DIPD. ສົນທິສັນຍາທີ່ຈະໃຊ້ໃນຍຸດທະສາດການທົດສອບແມ່ນໄດ້ອະທິບາຍໄວ້ໃນຍຸດທະສາດການທົດສອບແລະຄໍາສັບທີ່ຈົບລົງview ເອກະສານ (TSTO) [5].

ຜູ້ຊົມຫຼັກຂອງເອກະສານຢູ່ທີ່ນີ້tage ແມ່ນສະມາຊິກ WG ແລະ BARB ຜູ້ທີ່ກັບມາview ຂໍ້ສະ ເໜີ ທາງດ້ານສະຖາປັດຕະຍະກໍາແລະການຄຸ້ມຄອງຄວາມຕ້ອງການ, ແລະ BTI ຜູ້ນໍາໃ່views ຍຸດທະສາດການທົດສອບ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ເອກະສານຢູ່ທີ່ນີ້tage ບໍ່ມີຈຸດປະສົງທີ່ຈະບັນຈຸຂໍ້ຄວາມທີ່ວາງແຜນໄວ້ເພື່ອລວມຢູ່ໃນຂໍ້ກໍານົດສຸດທ້າຍ.

BSTS ຕ້ອງເຮັດຄືນໃ່view ເອກະສານທັງforົດເພື່ອຄວາມສອດຄ່ອງກັບແນວທາງການຮ່າງຮ່າງ Bluetooth [1] ແລະລະບຸບັນຫາຕ່າງ W ໃຫ້ WG ແກ້ໄຂ. BARB ຕ້ອງເຮັດຄືນໃ່view ຂໍ້ມູນຈໍາເພາະ 0.5/DIPD. ສໍາລັບການປັບປຸງສະເປັກ, BARB ຕ້ອງໄດ້ປັບຄືນໃ່ເຊັ່ນກັນview DIPD ສໍາລັບການປະຕິບັດຕາມຂໍ້ກໍານົດດ້ານການເຂົ້າກັນໄດ້ກັບຄືນໄປບ່ອນໄດ້ອະທິບາຍໄວ້ຢູ່ໃນຂໍ້ 3.3.2. BTI ຕ້ອງເຮັດຄືນໃ່view ຍຸດທະສາດການທົດສອບ.

BARB ຕ້ອງອະນຸມັດຫຼືປະຕິເສດຂໍ້ກໍານົດ 0.5/DIPD ໂດຍອີງຕາມຄໍາຕັດສິນຂອງວິສະວະກໍາ. ຖ້າໄດ້ຮັບການອະນຸມັດຈາກ BARB, ຂໍ້ກໍານົດ 0.5/DIPD ຈະມີຢູ່ໃນ Bluetooth SIG webສະຖານທີ່ໃຫ້ກັບສະມາຊິກທັງiateົດຂອງສະມາຄົມແລະຜູ້ໂຄສະນາແລະການແຈ້ງການມີຢູ່ຈະອອກໃຫ້ໂດຍ BSTS. ທີ່ 0.5/DIPD Stage, ການອະນຸມັດຍຸດທະສາດການສອບເສັງແມ່ນບໍ່ຕ້ອງການ.
ຄ່າ 0.5/DIPD Stage ບໍ່ຈໍາເປັນສໍາລັບການປັບປຸງ CSS, GSS, ຫຼື MDP ສະເພາະ

0.5/DIPD Stage ຄວາມຕ້ອງການອອກ

ຄ່າ 0.5/DIPD Stage ແມ່ນສົມບູນແລະ 0.7/FIPD Stage ເລີ່ມຕົ້ນເມື່ອຂໍ້ກໍານົດການທ່ອງທ່ຽວຕໍ່ໄປນີ້ຖືກຕອບສະ ໜອງ ໄດ້:

• BSTS ໄດ້ ສຳ ເລັດລົງໃ່viewຢູ່ໃນຂໍ້ກໍານົດ 0.5/DIPD ແລະຍຸດທະສາດການທົດສອບ.
• ທະນາຍຄວາມໄດ້ອະນຸມັດຂໍ້ ກຳ ນົດ 0.5 / DIPD.
• BTI ໄດ້ ສຳ ເລັດ ໜ້າ ທີ່ໃ່view ຂອງຍຸດທະສາດການທົດສອບ.
• BSTS ໄດ້ເຮັດການອະທິບາຍຂໍ້ ກຳ ນົດ 0.5 / DIPD ທີ່ຖືກອະນຸມັດໄວ້ໃຫ້ທຸກໆສະມາຊິກຂອງ Associate ແລະ Promoter.

4.2 0.7/FIPD ສtage

ໃນລະຫວ່າງ 0.7/FIPD S.tage, WG ຈະພັດທະນາຕໍ່ໄປນີ້ໂດຍໃຊ້ແມ່ແບບຢ່າງເປັນທາງການທີ່ສະ ໜອງ ໃຫ້ຢູ່ໃນ [8]:

1. ສຳ ລັບຂໍ້ ກຳ ນົດສະບັບ ໃໝ່, ຮ່າງເອກະສານສະເພາະຂອງ 0.7, ເຊິ່ງຕ້ອງມີຂໍ້ມູນ ໜ້ອຍ ທີ່ສຸດດັ່ງຕໍ່ໄປນີ້:

• ລາຍລະອຽດຂອງການປ່ຽນແປງທັງthatົດທີ່ໄດ້ເຮັດຕັ້ງແຕ່ໄດ້ຮັບການອະນຸມັດຈາກ BARB 0.5, ລວມທັງຂໍ້ສະ ເໜີ ໃor່ຫຼືດັດແກ້, ເກນການຄັດເລືອກ, ແລະເຫດຜົນຂອງການເລືອກ. ການປ່ຽນແປງຕ້ອງໄດ້ອະທິບາຍຢູ່ໃນລະດັບດຽວກັນຂອງລາຍລະອຽດຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນ 0.5 Stage.
• ທຸກໆຂໍ້ ກຳ ນົດທີ່ເປັນປະໂຫຍດຈາກ FRD ໄດ້ກ່າວເຖິງ.

2. ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການ ກຳ ນົດ, ຮ່າງກົດ ໝາຍ ວ່າດ້ວຍ FIPD, ເຊິ່ງຕ້ອງມີຂໍ້ມູນ ໜ້ອຍ ທີ່ສຸດຕໍ່ໄປນີ້:

• ລາຍລະອຽດຂອງການປ່ຽນແປງທັງthatົດທີ່ໄດ້ເຮັດຕັ້ງແຕ່ DIPD ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BARB, ລວມທັງຂໍ້ສະ ເໜີ ໃor່ຫຼືດັດແກ້, ເງື່ອນໄຂການຄັດເລືອກ, ແລະເຫດຜົນຂອງການເລືອກ. ການປ່ຽນແປງຕ້ອງໄດ້ອະທິບາຍຢູ່ໃນລະດັບດຽວກັນຂອງລາຍລະອຽດຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນ DIPD Stage.
• ຕາມຄວາມ ຈຳ ເປັນ, ເຂດພັດທະນາຕໍ່ໄປທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 4.1 ກ່ຽວກັບ DIPD.
• ລາຍລະອຽດທີ່ສົມບູນຂອງການປັບປຸງ.
• ລາຍລະອຽດກ່ຽວກັບສະຖາປັດຕະຍະ ກຳ ສະບັບປັບປຸງ.
• ທຸກໆຂໍ້ ກຳ ນົດທີ່ເປັນປະໂຫຍດຈາກ FRD ໄດ້ກ່າວເຖິງ.

3. 0.7 / ເອກະສານການທົດສອບ FIPD, ເຊິ່ງຕ້ອງມີຂໍ້ມູນ ໜ້ອຍ ທີ່ສຸດຕໍ່ໄປນີ້:

• ຊຸດທົດສອບ, ປະກອບມີບັນຊີລາຍຊື່ຂອງຈຸດປະສົງການທົດສອບດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນ TSTO [5].
• ຖະແຫຼງການຄວາມສອດຄ່ອງດ້ານການຈັດຕັ້ງປະຕິບັດ (ICS), ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນ TSTO [5].

ສຳ ລັບການຍົກລະດັບສະເພາະ, ການທົດສອບຊຸດແລະ ICS ອາດຈະຖືກສະ ໜອງ ໃຫ້ເປັນເອກະສານແຍກຕ່າງຫາກຫຼືເປັນພາກສ່ວນເພີ່ມເຕີມໃນ FIPD.

ຜູ້ຊົມຫຼັກຂອງເອກະສານທີ່ຜະລິດຢູ່ນີ້tage ແມ່ນສະມາຊິກ WG ແລະ BARB ຜູ້ທີ່ກັບມາview ລາຍລະອຽດຄົບຖ້ວນຂອງຄຸນສົມບັດຫຼືການປັບປຸງລວມທັງຂໍ້ຄວາມບາງອັນທີ່ວາງແຜນໄວ້ເພື່ອລວມຢູ່ໃນຂໍ້ກໍານົດສຸດທ້າຍ. BTI ແມ່ນຜູ້ຊົມສໍາລັບ review ຂອງເອກະສານການທົດສອບ.

BSTS ຈະກັບຄືນມາview ພາກສ່ວນໃnew່ຫຼືປ່ຽນແປງຂອງຂໍ້ກໍານົດ 0.7/FIPD ແລະເອກະສານທົດສອບເພື່ອຄວາມສອດຄ່ອງກັບແນວທາງການຮ່າງຮ່າງ Bluetooth, ລວມທັງສົນທິສັນຍາພາສາທີ່ Bluetooth SIG ສ້າງຂຶ້ນ. BARB ຈະກັບຄືນມາview ຂໍ້ມູນຈໍາເພາະ 0.7/FIPD

BSTS ຈະຊ່ວຍ WG ໃນການກະກຽມເອກະສານການທົດສອບ 0.7 / FIPD ໂດຍສອດຄ່ອງກັບ TSTO [5].

BTI ຕ້ອງເຮັດຄືນໃ່view ເອກະສານການທົດສອບ 0.7/FIPD. WG ຕ້ອງສະ ໜອງ ຂໍ້ສະເພາະ 0.7/FIPD ໃຫ້ BTI ເປັນບ່ອນອ້າງອີງເມື່ອກັບມາໃຊ້viewຢູ່ໃນເອກະສານການທົດສອບ 0.7/FIPD, ເຊິ່ງ BTI ຈະເຮັດຄືນໃ່view ສອດຄ່ອງກັບຂໍ້ກໍານົດຂອງ BTI Review ລາຍການກວດສອບຂະບວນການ [6].

ຫຼັງຈາກ BARB ສໍາເລັດຂອງຕົນview ຂອງ 0.7/FIPD ໂດຍສະເພາະແລະ BTI ໄດ້ສໍາເລັດການສ້າງໃ່view ຂອງເອກະສານການທົດສອບ 0.7/FIPD, BSTS ຈະເຮັດຄືນໃ່viewຂໍ້ກໍານົດ 0.7/FIPD ມີໃຫ້ກັບສະມາຊິກສະມາຄົມແລະຜູ້ໂຄສະນາທັງົດ.

0.7/FIPD Stage ບໍ່ຈໍາເປັນສໍາລັບການປັບປຸງ CSS, GSS, ຫຼື MDP ສະເພາະ.

0.7/FIPD Stage ຄວາມຕ້ອງການອອກ

0.7/FIPD Stage ແມ່ນສົມບູນແລະ 0.9/CR Stage ເລີ່ມຕົ້ນເມື່ອຂໍ້ກໍານົດການທ່ອງທ່ຽວຕໍ່ໄປນີ້ຖືກຕອບສະ ໜອງ ໄດ້:

• BSTS ໄດ້ ສຳ ເລັດລົງໃ່viewໃນເອກະສານ 0.7/FIPD ແລະເອກະສານທົດສອບ.
• BARB ໄດ້ເຮັດ ສຳ ເລັດແລ້ວviewໃນຂໍ້ກໍານົດ 0.7/FIPD.
• BTI ໄດ້ສໍາເລັດ reviewຢູ່ໃນຫ້ອງທົດສອບ 0.7/FIPD (ຈຸດປະສົງການທົດສອບ) ແລະ 0.7/FIPD ICS.
• BSTS ໄດ້ເຮັດຄືນໃ່viewຂໍ້ກໍານົດ 0.7/FIPD ມີໃຫ້ກັບສະມາຊິກສະມາຄົມແລະຜູ້ໂຄສະນາທັງົດ.

4.3 0.9/CR ສtage

CRs ມີສອງປະເພດຄື: CR Integrated ເຊິ່ງເປັນເອກະສານທີ່ມີການປ່ຽນແປງຂອງຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາທັງ ໝົດ ເຊິ່ງສະແດງໃຫ້ເຫັນການປ່ຽນແປງທັງ ໝົດ ນັບຕັ້ງແຕ່ລຸ້ນກ່ອນແລະ CR ຫຍໍ້ເຊິ່ງແມ່ນເອກະສານທີ່ໃຫ້ ຄຳ ແນະ ນຳ ສຳ ລັບການດັດແປງພຽງແຕ່ພາກສ່ວນທີ່ຖືກກະທົບຂອງ ສະບັບສະເພາະຂອງ CR ທີ່ອີງໃສ່.

ໃນລະຫວ່າງ 0.9/CR Stage, WG ຈະພັດທະນາຕໍ່ໄປນີ້ໂດຍໃຊ້ແມ່ແບບຢ່າງເປັນທາງການທີ່ສະ ໜອງ ໃຫ້ຢູ່ໃນ [8]:

1. ສຳ ລັບການ ກຳ ນົດສະບັບ ໃໝ່, ຮ່າງເນື້ອໃນຄົບຖ້ວນຂອງຂໍ້ ກຳ ນົດສະເພາະ 0.9, ເຊິ່ງຕ້ອງມີຂໍ້ມູນ ໜ້ອຍ ທີ່ສຸດດັ່ງຕໍ່ໄປນີ້:

• ລາຍລະອຽດຂອງການປ່ຽນແປງທັງthatົດທີ່ໄດ້ເຮັດຕັ້ງແຕ່ BARB-reviewຂໍ້ກໍານົດ 0.7 ed (ຫຼືຕັ້ງແຕ່ຂໍ້ກໍານົດ 0.5 ຖ້າການຜະລິດຂໍ້ກໍານົດ 0.7 ໄດ້ຖືກຍົກເວັ້ນ), ລວມທັງອັນໃor່ຫຼື
• ການສະ ເໜີ ແກ້ໄຂ, ເກນການຄັດເລືອກ, ແລະເຫດຜົນຂອງການເລືອກ. ການປ່ຽນແປງຕ້ອງໄດ້ອະທິບາຍຢູ່ໃນລະດັບດຽວກັນຂອງລາຍລະອຽດຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນ 0.5 Stage ແລະ 0.7 Stage.

2. ສຳ ລັບການຍົກລະດັບສະເພາະເຈາະຈົງ:

• ບໍ່ວ່າຈະເປັນ CR ທີ່ປະສົມປະສານ, ເຊິ່ງຕ້ອງມີຂໍ້ມູນຕໍ່ໄປນີ້ຢ່າງ ໜ້ອຍ ສຸດ:
• ລາຍລະອຽດຂອງການປ່ຽນແປງທັງthatົດທີ່ໄດ້ເຮັດຕັ້ງແຕ່ BARB-reviewed FIPD (ຫຼືນັບຕັ້ງແຕ່ DIPD ຖ້າ FIPD ໄດ້ຖືກຍົກເວັ້ນ) ລວມທັງຂໍ້ສະ ເໜີ ໃor່ຫຼືດັດແກ້, ເງື່ອນໄຂການຄັດເລືອກ, ແລະເຫດຜົນຂອງການເລືອກ. ການປ່ຽນແປງຕ້ອງໄດ້ອະທິບາຍຢູ່ໃນລະດັບດຽວກັນຂອງລາຍລະອຽດຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນ DIPD Stage ແລະ FIPD Stage.
• ການປ່ຽນແປງທັງ ໝົດ ທີ່ສະ ເໜີ ຕໍ່ການ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາຜ່ານມາໂດຍໃຊ້ການຕິດຕາມການປ່ຽນແປງ.
• ທັງ ໝົດ errata ດ້ານວິຊາການທີ່ໄດ້ຮັບການອະນຸມັດ (ແຕ່ລະ erratum ອ້າງອີງທີ່ມີຕົວເລກ erratum), ສະແດງໃຫ້ເຫັນການ ນຳ ໃຊ້ການຕິດຕາມການປ່ຽນແປງ, ເຊິ່ງຍັງບໍ່ທັນໄດ້ລວມເຂົ້າໃນສະບັບພາສາສະເພາະທີ່ໄດ້ຮັບຮອງເອົາໃນເມື່ອກ່ອນ, ແລະຂໍ້ຄວາມທີ່ມີຜົນກະທົບທີ່ກ່ຽວຂ້ອງກັບການປັບປຸງສະເພາະ; ຫຼືວ່າຖ້າບໍ່ດັ່ງນັ້ນຈະສົ່ງຜົນກະທົບຕໍ່ການທົດສອບ IOP.

3. ຫຼື CR ຫຍໍ້, ເຊິ່ງຕ້ອງມີຂໍ້ມູນ ໜ້ອຍ ທີ່ສຸດຕໍ່ໄປນີ້:

• ລາຍລະອຽດຂອງການປ່ຽນແປງທັງthatົດທີ່ໄດ້ເຮັດຕັ້ງແຕ່ BARB-reviewed FIPD (ຫຼືນັບຕັ້ງແຕ່ DIPD ຖ້າ FIPD ໄດ້ຖືກຍົກເວັ້ນ) ລວມທັງຂໍ້ສະ ເໜີ ໃor່ຫຼືດັດແກ້, ເງື່ອນໄຂການຄັດເລືອກ, ແລະເຫດຜົນຂອງການເລືອກ. ການປ່ຽນແປງຕ້ອງໄດ້ອະທິບາຍຢູ່ໃນລະດັບດຽວກັນຂອງລາຍລະອຽດຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນ DIPD Stage ແລະ FIPD Stage.
• ການປ່ຽນແປງທັງ ໝົດ ທີ່ສະ ເໜີ ຕໍ່ແຕ່ລະພາກສ່ວນທີ່ຖືກກະທົບແລະວັກຂອງຂໍ້ ກຳ ນົດທີ່ CR ສະ ເໜີ ໃຫ້ປ່ຽນແປງ.
• ທັງ ໝົດ errata ດ້ານວິຊາການທີ່ໄດ້ຮັບການອະນຸມັດ (ແຕ່ລະ erratum ອ້າງອີງທີ່ມີຕົວເລກ erratum), ສະແດງໃຫ້ເຫັນການ ນຳ ໃຊ້ເຄື່ອງ ໝາຍ, ທີ່ຍັງບໍ່ທັນໄດ້ຖືກລວມເຂົ້າກັບສະບັບການ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາໃນເມື່ອກ່ອນ, ແລະຂໍ້ຄວາມທີ່ມີຜົນກະທົບທີ່ກ່ຽວຂ້ອງກັບການປັບປຸງສະເພາະ; ຫຼືວ່າຖ້າບໍ່ດັ່ງນັ້ນຈະສົ່ງຜົນກະທົບຕໍ່ການທົດສອບ IOP.

4. CSS CR (ຖ້າມີຂໍ້ມູນ ໃໝ່ ຕາມຂໍ້ ກຳ ນົດສະເພາະ), ເຊິ່ງອາດຈະຖືກຝັງເຂົ້າໃນ CR ຫຍໍ້ຂອງຂໍ້ ກຳ ນົດ.
5. A GSS CR (ຖ້າມີການສະ ໝັກ ເຂົ້າ ໃໝ່ ໂດຍຂໍ້ ກຳ ນົດສະເພາະ), ເຊິ່ງອາດຈະຖືກຝັງເຂົ້າໃນ CR ຫຍໍ້ຂອງຂໍ້ ກຳ ນົດ.
6. MDP CR (ຖ້າມີຄວາມຕ້ອງການເຂົ້າ ໃໝ່ ໂດຍສະເພາະ), ເຊິ່ງອາດຈະຖືກຝັງເຂົ້າໃນ CR ຫຍໍ້ຂອງຂໍ້ ກຳ ນົດ.
7. 0.9 / CR ເອກະສານການທົດສອບ, ເຊິ່ງຕ້ອງມີຂໍ້ມູນກ່ຽວກັບຂໍ້ມູນຕໍ່ໄປນີ້ຢ່າງ ໜ້ອຍ ສຸດໂດຍໃຊ້ແບບແມ່ແບບຢ່າງເປັນທາງການໃນ [8]:

• ຊຸດທົດສອບ 0.9 / CR ເຊິ່ງລວມມີກໍລະນີທົດສອບທີ່ມີເນື້ອຫາຄົບຖ້ວນແລະຕາຕະລາງການສ້າງແຜນທີ່ທົດສອບທີ່ກ່ຽວຂ້ອງ (TCMT), ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນ TSTO [5].
• ICS 0.9 / CR, ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນ TSTO [5].
• ຖ້າການຕັ້ງຄ່າການທົດສອບຮຽກຮ້ອງໃຫ້ມີຕົວ ກຳ ນົດການສະເພາະ ສຳ ລັບການຈັດຕັ້ງປະຕິບັດພາຍໃຕ້ການທົດສອບ (IUT), ຂໍ້ມູນ eXtra ກ່ຽວກັບການຈັດຕັ້ງປະຕິບັດ 0.9 / CR ສຳ ລັບການທົດສອບ (IXIT).
• ບັນຊີລາຍຊື່ເອກະສານກ່ຽວກັບກໍລະນີທົດສອບ 0.9 / CR (TCRL) (ເປັນທາງເລືອກ ສຳ ລັບການປັບປຸງລະບົບ Core Specification).

8. ການວິເຄາະການຄຸ້ມຄອງການທົດສອບທີ່ຊີ້ບອກວ່າຄວາມຕ້ອງການສະເພາະໃດ ໜຶ່ງ ແມ່ນໄດ້ຖືກທົດສອບຫຼືບໍ່ໄດ້ທົດສອບພາຍໃນ 0.9 / CR Test Suite (ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການລະບຸ, ການວິເຄາະການຄຸ້ມຄອງການທົດສອບຕ້ອງການພຽງແຕ່ປະກອບມີການເຮັດວຽກທີ່ໄດ້ເພີ່ມແລະມີຜົນກະທົບ ໃໝ່ ເທົ່ານັ້ນແລະບໍ່ແມ່ນພື້ນທີ່ທີ່ບໍ່ໄດ້ຮັບຜົນກະທົບຈາກ ສະເພາະຕົ້ນສະບັບ).
9. ແຜນການທົດສອບ IOP.

ສຳ ລັບການຍົກລະດັບການ ກຳ ນົດສະເພາະ, ຊຸດ Suite, ICS, ແລະ IXIT ອາດຈະຖືກສະ ໜອງ ໃຫ້ເປັນເອກະສານແຍກຕ່າງຫາກຫຼືເປັນພາກສ່ວນເພີ່ມເຕີມໃນ Abbreviated CR.

ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ເອກະສານປະສົມປະສານຫຼືຫຍໍ້ CR ຄວນອີງໃສ່ສະບັບທີ່ໄດ້ຮັບຮອງເອົາໃນເມື່ອກ່ອນ, ແຕ່ມັນຍັງອາດຈະອີງໃສ່ຮ່າງລະດັບປານກາງຫຼ້າສຸດ. ຕົວເລກສະບັບຮ່າງລະບຸສະບັບຮ່າງລະດັບປານກາງຫຼ້າສຸດແມ່ນຕົວເລກສະບັບທີ່ກ່ຽວຂ້ອງກັບເອກະສານສະບັບ ໜຶ່ງ ທີ່ຖືກແຊ່ແຂງແລະນັ້ນຈະບໍ່ປ່ຽນແປງຕາມເວລາ. ຖ້າບໍ່ດັ່ງນັ້ນ, ຂໍ້ມູນການລະບຸເພີ່ມເຕີມ (ເຊັ່ນວ່າວັນທີເອກະສານແລະ a URL ເຖິງສະຖານທີ່ຖາວອນ) ຕ້ອງໄດ້ຮັບການສະ ໜອງ ເພື່ອ ກຳ ນົດສະບັບ“ ພື້ນຖານ” ສະເພາະ. ຖ້າຮ່າງຮ່າງລະດັບປານກາງຖືກ ນຳ ໃຊ້, ທຸກໆການປ່ຽນແປງທີ່ບໍ່ກ່ຽວຂ້ອງໂດຍກົງກັບ CR ພາຍໃນພາກໃດ ໜຶ່ງ ທີ່ CR ກຳ ລັງດັດແປງຕ້ອງປະກອບ, ແຕ່ບໍ່ ຈຳ ເປັນຕ້ອງສະແດງໃຫ້ເຫັນໂດຍ ນຳ ໃຊ້ເຄື່ອງ ໝາຍ. ຖ້າສ່ວນທີ່ກ່ຽວຂ້ອງຂອງຮ່າງລະດັບປານກາງໄດ້ຖືກປັບປຸງຕໍ່ມາ, CR ຕ້ອງໄດ້ຮັບການປັບປຸງເພື່ອສະທ້ອນໃຫ້ເຫັນເຖິງການປັບປຸງຂອງຮ່າງລະດັບປານກາງ.

ໂດຍຫລັກການແລ້ວ, ເອກະສານຫຍໍ້ CR ຖືກລວມເຂົ້າໃນຮ່າງເອກະສານສະເພາະຂອງເອກະສານສະເພາະແລະເອກະສານການທົດສອບທີ່ສົມບູນຕາມ ລຳ ດັບ, ກ່ອນການຢັ້ງຢືນໄລຍະ, ແຕ່ພວກມັນອາດຈະປະສົມປະສານກັນໃນຕອນເລີ່ມຕົ້ນຂອງໄລຍະການກວດສອບຄວາມຖືກຕ້ອງ. ຖ້າມີຫລາຍໆຄຸນລັກສະນະທີ່ ກຳ ລັງຖືກພັດທະນາ ສຳ ລັບສະເພາະ (ຕົວຢ່າງຫຼັກການສະເພາະ), ມັນອາດຈະເປັນຄວາມຕ້ອງການທີ່ຈະລວມເອົາຄຸນລັກສະນະຕ່າງໆເຂົ້າໃນຮ່າງດຽວຫຼັງຈາກການທົດສອບ IOP ແລ້ວ.

BSTS ຈະກັບຄືນມາview ເອກະສານ 0.9/CR ແລະເອກະສານທົດສອບເພື່ອຄວາມສອດຄ່ອງກັບແນວທາງການຮ່າງຮ່າງ Bluetooth. ຈາກນັ້ນ BARB ຈະກັບມາໃ່view ຂໍ້ກໍານົດ 0.9/CR ປະຕິບັດຕາມພາຍຫຼັງໂດຍແຜນການທົດສອບ IOP (ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 4.3.1). ເມື່ອ WG ໄດ້ສົ່ງຂໍ້ກໍານົດ 0.9/CR ໂດຍ WG ຫາ BARBview, BSTS ຈະເຮັດໃຫ້ມັນສາມາດເຂົ້າເຖິງໄດ້ສໍາລັບສະມາຊິກທັງtoົດທີ່ຈະເຂົ້າມາໃ່view ແລະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຂອງການມີຂອງມັນ. ຈາກຈຸດນີ້ໄປຂ້າງ ໜ້າ ໃນຂະບວນການພັດທະນາສະເປັກ, BSTS ຈະເຮັດຮ່າງຮ່າງຂອງສະເປັກທີ່ສົ່ງໃຫ້ BARB ໃຫ້ກັບສະມາຊິກທຸກຄົນດ້ວຍແຈ້ງການເປັນແຕ່ລະໄລຍະທີ່ສົ່ງໃຫ້ສະມາຊິກທຸກຄົນ.

ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການ ກຳ ນົດ, WG ຈະແນະ ນຳ ໃຫ້ BoD ບໍ່ວ່າຈະເປັນການອະນຸມັດຫຼືການຖອດຖອນສະບັບກ່ອນ, ລວມທັງເຫດຜົນດ້ານວິຊາການ ສຳ ລັບ ຄຳ ແນະ ນຳ.

BARB ຈະກັບຄືນມາview ການວິເຄາະຂອງ WG ກ່ຽວກັບການປະຕິບັດຕາມຂໍ້ກໍານົດຂອງ 0.9/CR ກັບຂໍ້ກໍານົດທີ່ໄດ້ໃຫ້ໄວ້ໃນ FRD, ບັນຫາຄວາມປອດໄພທີ່ອາດເກີດຂຶ້ນ, ບັນຫາດ້ານກົດລະບຽບ, ຄວາມສອດຄ່ອງກັບສະຖາປັດຕະຍະກໍາ Bluetooth, ແລະສໍາລັບການປັບປຸງສະເປັກ, ການປະຕິບັດຕາມຂໍ້ກໍານົດດ້ານການເຂົ້າກັນໄດ້ກັບຄືນມາໄດ້ອະທິບາຍໄວ້ໃນພາກ 3.3.2 .XNUMX. ຖ້າ BARB ລະບຸບັນຫາຄວາມປອດໄພທີ່ອາດຈະເກີດຂຶ້ນ, BARB ຈະແຈ້ງໃຫ້ BSTS ຮັບຊາບຄືນview ແລະການປະສານງານກັບກຸ່ມຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພ; ແລະຖ້າ BARB ລະບຸຄວາມກ່ຽວຂ້ອງກັບກົດລະບຽບໃດ ໜຶ່ງ, BARB ຈະແຈ້ງໃຫ້ BSTS ກັບຄືນມາໃຊ້ໃ່view ແລະປະສານງານກັບຄະນະກໍາມະການຄຸ້ມຄອງແລະທີ່ປຶກສາດ້ານກົດBluetoothາຍຂອງ Bluetooth SIG. BARB ຕ້ອງອະນຸມັດຫຼືປະຕິເສດຂໍ້ກໍານົດ 0.9/CR ໂດຍອີງຕາມການຕັດສິນທາງດ້ານວິສະວະກໍາແລະພິຈາລະນາປັດໃຈທີ່ອະທິບາຍໄວ້ໃນວັກນີ້.

BTI ຈະກັບຄືນມາview ເອກະສານການທົດສອບ 0.9/CR ຄຳ ນຶງເຖິງການວິເຄາະການຄຸ້ມຄອງການທົດສອບ. BTI ຕ້ອງອະນຸມັດຫຼືປະຕິເສດເອກະສານການທົດສອບ 0.9/CR.

ຫຼັງຈາກ BARB ອະນຸມັດຂໍ້ກໍານົດ 0.9/CR, WG ໄດ້ສົ່ງແຜນການທົດສອບ IOP ໄປໃຫ້ BARB ສໍາລັບ re.view.

ຂໍ້ ກຳ ນົດ 0.9 / CR ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BARB ແມ່ນສະ ເໜີ ຕໍ່ BoD ເພື່ອອະນຸມັດການເລີ່ມຕົ້ນຂອງການທົດສອບ IOP ແລະການເຜີຍແຜ່ຂໍ້ ກຳ ນົດ 0.9 / CR ຕໍ່ສະມາຊິກທັງ ໝົດ.

ເພື່ອເນັ້ນໃຫ້ເຫັນບັນຫາທາງດ້ານກົດpotentialາຍທີ່ອາດເກີດຂຶ້ນໄດ້, WGs ອາດຈະຮ້ອງຂໍເອົາຂໍ້ມູນສະເພາະຄືນໃ່view ໂດຍທີ່ປຶກສາດ້ານກົດBluetoothາຍຂອງ Bluetooth SIG (review) ກ່ອນການບັງຄັບໃຊ້ກົດາຍview ເກີດຂຶ້ນໃນລະຫວ່າງໄລຍະການຮັບຮອງເອົາ/ການອະນຸມັດ. ແນວໃດກໍ່ຕາມ, ສໍາລັບການປັບປຸງສະເປັກ, ກົດreາຍໃre່view ຄວນຈະເຮັດຢູ່ໃນ CR ແບບປະສົມປະສານ (ກົງກັນຂ້າມກັບ CR ຫຍໍ້) ແລະອັນນີ້ຄວນຈະຖືກກໍານົດເວລາລ່ວງ ໜ້າ ໃຫ້ຫຼາຍເທົ່າທີ່ຈະຫຼາຍໄດ້ເພື່ອໃຫ້ມີແຫຼ່ງຂໍ້ມູນ.

ແຜນການທົດສອບ IOP

WG ຈະພັດທະນາແຜນການທົດສອບ IOP ເປັນລາຍລັກອັກສອນທີ່ຕ້ອງຕອບສະ ໜອງ ທຸກຄວາມຕ້ອງການທີ່ໄດ້ກໍານົດໄວ້ຂ້າງລຸ່ມນີ້ສໍາລັບການນໍາໃຊ້ໃນໄລຍະການຮັບຮອງຢູ່ໃນເຫດການທົດສອບ IOP. WGs ຕ້ອງສົ່ງແຜນການທົດສອບ IOP ຫາ BARB ເພື່ອຮ້ອງຂໍຄືນໃ່view ກ່ອນເຫດການທົດສອບ IOP ເລີ່ມ. ສໍາລັບການປັບປຸງສະເປັກງ່າຍ simple (ໂດຍສະເພາະອັນທີ່ບໍ່ຈໍາເປັນຕ້ອງດັດແປງຫຼືເພີ່ມກໍລະນີທົດສອບໃດ ໜຶ່ງ ຢູ່ໃນຫ້ອງທົດສອບ), ການທົດສອບ IOP ອາດຈະບໍ່ຈໍາເປັນ, ແລະ WG ອາດຈະສົ່ງຄໍາຮ້ອງຂໍໄປຫາ BARB ສໍາລັບການຍົກເວັ້ນຈາກການທົດສອບ IOP ໂດຍການນໍາໃຊ້ຂະບວນການທີ່ກໍານົດໄວ້. ຢູ່ໃນພາກ 4.4.

ແຜນການທົດສອບ IOP ຕ້ອງປະກອບມີ:

1. ຄະດີທົດສອບເພື່ອກວດສອບຄຸນລັກສະນະ ໃໝ່ ທີ່ບັງຄັບ, ທາງເລືອກແລະເງື່ອນໄຂ
2. ຢ່າງຫນ້ອຍກໍລະນີທົດສອບ ສຳ ລັບແຕ່ລະລະຫັດ op
3. ຢ່າງຫນ້ອຍກໍລະນີທົດສອບ ສຳ ລັບແຕ່ລະພາລາມິເຕີ
4. ຢ່າງ ໜ້ອຍ ກໍລະນີທົດສອບ ສຳ ລັບແຕ່ລະປະເພດແພັກເກັດ
5. ກໍລະນີທົດສອບຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ ສຳ ລັບການຍົກລະດັບສະເພາະເພື່ອໃຫ້ຂໍ້ ກຳ ນົດທີ່ລະບຸໄວ້ໃນພາກ 3.3.2 ແມ່ນຕອບສະ ໜອງ ໄດ້ ສຳ ລັບທຸກ ໜ້າ ທີ່ທີ່ໄດ້ຮັບການປັບປຸງ (ເບິ່ງໃນພາກ 4.3.1.1)
6. ກໍລະນີທົດສອບທີ່ IUT ປະເຊີນກັບຄຸນຄ່າທີ່ຢູ່ນອກຂອບເຂດທີ່ໄດ້ ກຳ ນົດໄວ້ຫຼືດ້ານພຶດຕິ ກຳ ທີ່ຖືວ່າບໍ່ຖືກຕ້ອງຫຼືບໍ່ຄາດຄິດ (ກໍລະນີທົດສອບພຶດຕິ ກຳ ທີ່ບໍ່ຖືກຕ້ອງ). ໃຫ້ສັງເກດວ່າມັນຄາດວ່ານັກທົດສອບເຊັ່ນ: PTS ຫຼືເຄື່ອງມືທົດສອບອື່ນໆຈະເປັນຜູ້ລິເລີ່ມການກະ ທຳ ທີ່ບໍ່ຖືກຕ້ອງ.
7. ຕົວເລກທີ່ໄດ້ຮັບມອບ ໝາຍ ຊົ່ວຄາວ (ຖືກຄັດເລືອກໂດຍປະສານສົມທົບກັບ BSTS ເພື່ອຫລີກລ້ຽງການຊໍ້າຊ້ອນໃນເຫດການທົດສອບ IOP ທີ່ຈະມາເຖິງ) ເພື່ອ ນຳ ໃຊ້ໃນເຫດການທົດສອບ IOP, ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 4.3.1.2.
8. ການ ກຳ ນົດ ຈຳ ນວນການຈັດຕັ້ງປະຕິບັດທີ່ເປັນເອກະລາດເຊິ່ງຕ້ອງໄດ້ຜ່ານແຕ່ລະກໍລະນີທົດສອບ, ໂດຍ ຄຳ ນຶງເຖິງຂໍ້ ກຳ ນົດການຄຸ້ມຄອງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 4.3.1.3
9. ການ ກຳ ນົດບັນດາກໍລະນີທົດສອບຕ່າງໆໃນຊຸດທົດສອບທີ່ WG ເຊື່ອວ່າຄວນຈະຖືກຍົກເວັ້ນແລະການໃຫ້ເຫດຜົນ ສຳ ລັບການຍົກເວັ້ນຂອງພວກເຂົາ. ສິ່ງເຫຼົ່ານີ້ລວມມີ: •ການທົດສອບການພິສູດໃນອະນາຄົດ (ຕົວຢ່າງ, ການທົດສອບທົ່ວໄປເພື່ອໃຫ້ການເພີ່ມເຕີມໃນອະນາຄົດທີ່ເປັນໄປໄດ້, ເຊັ່ນຄຸນລັກສະນະເພີ່ມເຕີມ, ລັກສະນະຂະຫຍາຍ, ຫຼືການ ນຳ ໃຊ້ສະຫງວນຫຼືການ ນຳ ໃຊ້ສະຫງວນໃນອະນາຄົດ (RFU).
   •ຄະດີການທົດສອບເຊິ່ງເປັນຊຸດຍ່ອຍຂອງການທົດສອບທີ່ລວມເຂົ້າມາ
   •ກໍລະນີທົດສອບທົ່ວໄປທີ່ຄ້າຍຄືກັນກັບການທົດສອບທີ່ໃຊ້ ສຳ ລັບສະເພາະຫຼາຍຢ່າງ (ຕົວຢ່າງ: ລະຫັດຂໍ້ຜິດພາດທົ່ວໄປ)
   •ກໍລະນີທົດສອບທີ່ມີຈຸດປະສົງທົດສອບດຽວກັນກັບກໍລະນີທົດສອບທີ່ແລ່ນຜ່ານການຂົນສົ່ງອື່ນ (ຕົວຢ່າງ, ກໍລະນີທົດສອບ BR / EDR ທີ່ຄ້າຍກັບກໍລະນີທົດສອບ LE)
   •ການທົດສອບຄວາມເຂັ້ມແຂງຫຼືຄວາມກົດດັນຂອງການຈັດຕັ້ງປະຕິບັດ

ແຜນການທົດສອບ IOP ຍັງອາດຈະປະກອບມີການທົດສອບທີ່ເປັນເອກະລັກໃນການທົດສອບ IOP ເຊັ່ນ: ກໍລະນີທົດສອບໃນຕອນທ້າຍທີ່ຮວບຮວມບັນດາ ລຳ ດັບທີ່ສັບສົນຫຼາຍເຊິ່ງອາດຈະຄ້າຍຄືກັບສະຖານະການຂອງຜູ້ໃຊ້ທົ່ວໄປ.

ເຖິງແມ່ນວ່າການອະນຸມັດຂອງ BARB ຂອງແຜນການທົດສອບ IOP ແມ່ນບໍ່ ຈຳ ເປັນ (ຕາມຄວາມເຂົ້າໃຈວ່າແຜນການທົດສອບ IOP ຈະສືບຕໍ່ປັບປຸງແລະປັບປຸງໃຫ້ດີຂື້ນກັບແຕ່ລະເຫດການທົດສອບ IOP), ແຕ່ຕ້ອງມີການອະນຸມັດຈາກບົດລາຍງານການທົດສອບ IOP ຂອງ BARB (ເບິ່ງພາກ 5.1.1) . ຖ້າແຜນການທົດສອບ IOP ບໍ່ຕອບສະ ໜອງ ຄວາມຮຽກຮ້ອງຕ້ອງການທັງ ໝົດ ທີ່ໄດ້ລະບຸໄວ້ໃນພາກ 4.3.1, WG ຄວນ ນຳ ສະ ເໜີ ບົດສະຫຼຸບກ່ຽວກັບຕົວປ່ຽນແປງທີ່ຮູ້ຈັກແລະເຫດຜົນ ສຳ ລັບແຕ່ລະແນວພັນກັບ BARB ກ່ອນເຫດການທົດສອບ IOP ເລີ່ມຕົ້ນ.

ແຜນການທົດສອບແລະກໍລະນີທົດສອບຂອງ IOP ຄວນອີງໃສ່ເນື້ອໃນທີ່ຢູ່ໃນເອກະສານການທົດສອບສະເພາະຂອງທີ່ກ່ຽວຂ້ອງ.

ເພື່ອເຮັດໃຫ້ກິດຈະ ກຳ ການທົດສອບ IOP ມີປະສິດທິພາບ, WG ຄວນມີແຜນການທົດສອບ IOP ແລະທຸກໆກໍລະນີທົດສອບທີ່ກ່ຽວຂ້ອງ ສຳ ເລັດແລະສາມາດໃຊ້ໄດ້ກັບຜູ້ປະຕິບັດຢ່າງ ໜ້ອຍ ໜຶ່ງ ເດືອນກ່ອນເຫດການທົດສອບ IOP ຄັ້ງ ທຳ ອິດ.

ການວາງແຜນ ສຳ ລັບການທົດສອບຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ
ສໍາລັບການປັບປຸງສະເປັກ, ການທົດສອບ IOP ຂອງຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງຈະຕ້ອງພິຈາລະນາການຢັ້ງຢືນຕໍ່ກັບສະເປັກຂອງສະເປັກທັງactiveົດທີ່ມີການເຄື່ອນໄຫວແລະຖືກຄັດຄ້ານເພາະວ່າສະເປັກແລະການທໍາງານເຫຼົ່ານັ້ນທີ່ພົບເຫັນທົ່ວໄປໃນຜະລິດຕະພັນ Bluetooth ອາດຈະມີອາຍຸຍືນຍາວ (ຕົວຢ່າງ: ພາຫະນະ). WG ຕ້ອງວິເຄາະລະດັບທີ່ເofາະສົມຂອງການທົດສອບຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງທີ່ຈໍາເປັນ (ຖ້າມີ) ລວມທັງສະບັບໃດທີ່ຈະທົດສອບແລະທົດສອບເພື່ອປະຕິບັດ, ແລະສະ ໜອງ ການວິເຄາະນີ້ໃຫ້ກັບ BARB. BARB ຕ້ອງເຮັດຄືນໃ່view ການວິເຄາະແລະແນະນໍາການປ່ຽນແປງ (ຖ້າມີ) ສໍາລັບ WG ເພື່ອລວມເຂົ້າໃນແຜນການທົດສອບ IOP.

ສະມາຊິກທີ່ເຂົ້າຮ່ວມໃນການທົດສອບຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງແມ່ນຖືກສົ່ງເສີມໃຫ້ ນຳ ເອົາອຸປະກອນທີ່ເປັນມໍລະດົກທີ່ມີຄຸນນະພາບທຽບໃສ່ລຸ້ນກ່ອນ ໜ້າ ນີ້. WG ຕ້ອງລາຍງານຄວາມລົ້ມເຫລວດ້ານຄວາມເຂົ້າກັນດ້ານຫລັງໃນບົດລາຍງານການທົດສອບ IOP. ບັນດາບໍລິສັດສະມາຊິກຍັງໄດ້ຮັບການຊຸກຍູ້ໃຫ້ ດຳ ເນີນການທົດສອບຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງໃນຫ້ອງທົດລອງຂອງພວກເຂົາຢູ່ນອກສະຖານທີ່ຂອງເຫດການທົດສອບ IOP ແລະລາຍງານບັນຫາທີ່ກ່ຽວຂ້ອງກັບການ ກຳ ນົດສະເພາະຕໍ່ WG.

ຕົວເລກມອບ ໝາຍ ຊົ່ວຄາວທີ່ໃຊ້ໃນການທົດສອບ IOP
BSTS ແລະ BARB ຕ້ອງໄດ້ຮັບການປຶກສາຫາລືເພື່ອປະສານງານການປະຕິບັດຊົ່ວຄາວຂອງຕົວເລກທີ່ຖືກມອບ ໝາຍ ເຊິ່ງຈະຖືກ ນຳ ໃຊ້ໃນເຫດການທົດສອບ IOP ເພື່ອບໍ່ໃຫ້ມີການຊ້ອນກັນຫຼືການປະທະກັນກັບຂໍ້ສະເພາະອື່ນໆ. ຄ່ານິຍົມຊົ່ວຄາວເຫລົ່ານີ້ຕ້ອງຖືກລວມເຂົ້າໃນແຜນການທົດສອບ IOP ແລະຈະບໍ່ຖືກມອບ ໝາຍ ໃຫ້ ນຳ ໃຊ້ໂດຍສະເພາະທີ່ໄດ້ຮັບຮອງເອົາ.

ສຳ ລັບການທົດສອບ IOP ບ່ອນທີ່ ໜຶ່ງ ຫລືຫຼາຍຄຸນຄ່າ 16-bit UUID ໃໝ່ ກຳ ລັງຖືກສະ ເໜີ, ຄ່າພາຍໃນ 0x7F00 ເຖິງ 0x7FFF ແມ່ນຖືກສະຫງວນໄວ້ ສຳ ລັບການທົດສອບ IOP.

ສຳ ລັບການທົດສອບ IOP ບ່ອນທີ່ ໜຶ່ງ ຫລືຫຼາຍຄຸນຄ່າຂອງການແກ້ໄຂໂປແກຼມ Fixed Protocol Service Multiplexer (PSM) ໃໝ່ ກຳ ລັງຖືກສະ ເໜີ, ຄ່າເລີ່ມຕົ້ນຈາກຊ່ວງຂອງຊ່ວງທີ່ຖືກຕ້ອງຕັ້ງແຕ່ 0x0000 ເຖິງ 0x007F, ດັ່ງທີ່ໄດ້ ກຳ ນົດໄວ້ໃນລະບົບ Core Specification, ຈະຖືກ ນຳ ໃຊ້.

ຂໍ້ ກຳ ນົດການຄຸ້ມຄອງ
WG ຕ້ອງສະ ໜອງ ຫຼັກຖານສະແດງໃຫ້ BARB ວ່າຕົວເລກທີ່ ຈຳ ເປັນ (ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກທີ່ຕິດຕາມ) ຂອງການຈັດຕັ້ງປະຕິບັດທີ່ເປັນເອກະລາດໄດ້ຜ່ານແຕ່ລະກໍລະນີທົດສອບແລ້ວ. ຄຳ ຮ້ອງຂໍຂອງ WG ໃດ ໜຶ່ງ ສຳ ລັບຂໍ້ຍົກເວັ້ນຕໍ່ ຈຳ ນວນການຈັດຕັ້ງປະຕິບັດທີ່ເປັນເອກະລາດຕ້ອງໄດ້ສະແດງໄວ້ໃນແຜນການທົດສອບ IOP ທີ່ສົ່ງໃຫ້ BARB.

ການຈັດຕັ້ງປະຕິບັດຖືວ່າເປັນເອກະລາດເຊິ່ງກັນແລະກັນຕາບໃດທີ່ທຸກພາກສ່ວນທີ່ກ່ຽວຂ້ອງກັບການຢັ້ງຢືນໄດ້ຖືກພັດທະນາຢ່າງເປັນອິດສະຫຼະ, ເຊັ່ນ: ໂດຍທີມງານທີ່ແຕກຕ່າງກັນ (ເຊິ່ງບໍ່ ຈຳ ເປັນຕ້ອງມາຈາກບໍລິສັດທີ່ແຕກຕ່າງກັນ). BSTS ອາດຈະຊ່ວຍໃນການປະເມີນວ່າຮູບແບບຕົ້ນແບບສາມາດຖືວ່າເປັນເອກະລາດຂອງກັນແລະກັນເພື່ອຮັກສາການປິດບັງຊື່ແລະຄວາມລັບຂອງລາຍລະອຽດການຈັດຕັ້ງປະຕິບັດ.

ໃຫ້ສັງເກດວ່າເຄື່ອງມືທົດສອບລວມທັງ PTS ບໍ່ໄດ້ຖືກຖືວ່າເປັນການຈັດຕັ້ງປະຕິບັດເອກະລາດ.

ຄວາມຕ້ອງການຄຸ້ມຄອງສະເພາະຂອງ IOP
ຄຸນລັກສະນະການລະບຸຫຼັກໆໂດຍປົກກະຕິຈະ ກຳ ນົດພາລະບົດບາດ ໜຶ່ງ ຫລືຫຼາຍ ຕຳ ແໜ່ງ ເຊິ່ງແຕ່ລະບົດບາດໄດ້ຖືກອອກແບບມາເພື່ອໃຫ້ມີການໂຕ້ຕອບກັບບົດບາດ ໜຶ່ງ ຫລືຫຼາຍພາລະບົດບາດອື່ນຫລືອາດຈະເຮັດກັບຕົວມັນເອງ.

ສຳ ລັບແຕ່ລະພາລະບົດບາດທີ່ຖືກອອກແບບມາເພື່ອໂຕ້ຕອບເຊິ່ງກັນແລະກັນ, ຢ່າງ ໜ້ອຍ ຕ້ອງມີການປະຕິບັດເອກະລາດສາມຢ່າງຂອງແຕ່ລະບົດບາດຕ້ອງໄດ້ສະແດງອອກເພື່ອໃຫ້ສາມາດເຊື່ອມໂຍງກັນໄດ້ກັບການຈັດຕັ້ງປະຕິບັດສາມເອກະລາດຂອງບົດບາດສົມບູນ.

ສຳ ລັບແຕ່ລະບົດບາດທີ່ສາມາດພົວພັນກັບອຸປະກອນອື່ນທີ່ມີບົດບາດດຽວກັນ, ຢ່າງ ໜ້ອຍ ສາມການປະຕິບັດເອກະລາດຂອງບົດບາດນັ້ນຕ້ອງສະແດງໃຫ້ເຫັນວ່າພວກເຂົາສາມາດພົວພັນກັບກັນແລະກັນໃນບົດບາດນັ້ນ.

ຂໍ້ ກຳ ນົດກ່ຽວກັບການຄຸ້ມຄອງບໍລິການ IOP
ຢ່າງຫນ້ອຍສາມການປະຕິບັດການບໍລິການທີ່ເປັນເອກະລາດຕ້ອງໄດ້ສະແດງໃຫ້ເຫັນວ່າພວກເຂົາເຊື່ອມຕໍ່ກັບການປະຕິບັດລູກຄ້າຢ່າງ ໜ້ອຍ ໜຶ່ງ ຄັ້ງ, ເຊິ່ງອາດຈະແມ່ນ PTS

ໂປຣfile ແລະຂໍ້ກໍານົດພິທີການ IOP ການຄຸ້ມຄອງ
ໂປຣfile ແລະຂໍ້ກໍານົດພິທີການໂດຍປົກກະຕິກໍານົດບົດບາດອັນ ໜຶ່ງ ຫຼືຫຼາຍຢ່າງທີ່ແຕ່ລະບົດບາດຖືກອອກແບບມາເພື່ອເຮັດວຽກຮ່ວມກັນກັບ ໜຶ່ງ ຫຼືຫຼາຍບົດບາດອື່ນ, ຫຼືອາດຈະເຮັດດ້ວຍຕົວມັນເອງ.

ສຳ ລັບແຕ່ລະພາລະບົດບາດທີ່ຖືກອອກແບບມາເພື່ອໂຕ້ຕອບກັບກັນແລະກັນ, ຢ່າງ ໜ້ອຍ ສອງການປະຕິບັດທີ່ເປັນເອກະລາດຂອງແຕ່ລະບົດບາດຕ້ອງສະແດງໃຫ້ເຫັນວ່າພວກເຂົາເຊື່ອມຕໍ່ກັບສອງການປະຕິບັດທີ່ເປັນເອກະລາດຂອງບົດບາດເສີມ.

ສຳ ລັບແຕ່ລະບົດບາດທີ່ສາມາດພົວພັນກັບອຸປະກອນອື່ນທີ່ມີບົດບາດດຽວກັນ, ຢ່າງ ໜ້ອຍ ສາມການປະຕິບັດເອກະລາດຂອງບົດບາດນັ້ນຕ້ອງສະແດງໃຫ້ເຫັນວ່າພວກເຂົາພົວພັນກັບກັນແລະກັນໃນບົດບາດນັ້ນ.

ຂໍ້ ກຳ ນົດກ່ຽວກັບການຄຸ້ມຄອງຂອງ IOP
ຢ່າງຫນ້ອຍສາມຮູບແບບຂອງເຄື່ອງແມ່ຂ່າຍທີ່ເປັນເອກະລາດຫຼືການປະຕິບັດຕົວແບບການຄວບຄຸມຕ້ອງສະແດງໃຫ້ເຫັນວ່າພວກເຂົາເຊື່ອມຕໍ່ກັບການປະຕິບັດຂອງລູກຄ້າຢ່າງ ໜ້ອຍ ໜຶ່ງ ຄັ້ງ (ເຊິ່ງອາດຈະແມ່ນ PTS) ແລະຢ່າງ ໜ້ອຍ ການປະຕິບັດຕົວແບບຂອງລູກຄ້າຕ້ອງສະແດງໃຫ້ເຫັນວ່າມັນມີການເຊື່ອມໂຍງກັບການປະຕິບັດແບບຢ່າງຂອງເຄື່ອງແມ່ຂ່າຍຢ່າງ ໜ້ອຍ ໜຶ່ງ ຄັ້ງແລະ PTS.

ໝາຍ ເລກຮຸ່ນສະເພາະ

ໃນລະຫວ່າງ 0.9/CR Stage, WG ຕ້ອງກະກຽມຄໍາແນະນໍາເພື່ອນໍາສະ ເໜີ ຕໍ່ BoD ກ່ຽວກັບເລກເວີຊັນທີ່ຈະນໍາໃຊ້ກັບຂໍ້ກໍານົດດັ່ງກ່າວເມື່ອໄດ້ຮັບຮອງເອົາ.

ສະບັບຂອງຂໍ້ ກຳ ນົດສະເພາະຫຼຸດລົງເປັນສອງປະເພດ: ລຸ້ນປ່ອຍເຕັມ, ເຊິ່ງປະກອບມີລັກສະນະ ໃໝ່ ຫລືປັບປຸງ ໃໝ່, ແລະລຸ້ນປ່ອຍ ບຳ ລຸງຮັກສາ (ຍັງເອີ້ນວ່າ "ລຸ້ນ dot-Z"), ເຊິ່ງລວມເອົາເຕັກນິກແລະບັນນາທິການທີ່ຜິດພາດ, ແຕ່ບໍ່ລວມເອົາການປັບປຸງ ໃໝ່ ຫຼື ໃໝ່ ຄຸນ​ລັກ​ສະ​ນະ. ລຸ້ນປ່ອຍເຕັມມີຕົວເລກສອງສ່ວນໃນຮູບແບບຂອງ XY ເຊັ່ນ 2.1 ຫຼື 5.0, ໃນຂະນະທີ່ລຸ້ນປ່ອຍ ບຳ ລຸງຮັກສາມີຕົວເລກສາມສ່ວນໃນຮູບແບບຂອງ XYZ, ເຊັ່ນວ່າ 2.1.2. ມູນຄ່າຂອງ Z ບໍ່ສາມາດເປັນ 0.

ສຳ ລັບສອງລຸ້ນ, ໜຶ່ງ ສະບັບແມ່ນ ໝາຍ ເຖິງ "ລຸ້ນທີ່ສູງກວ່າ" ແລະອີກລຸ້ນ ໜຶ່ງ ແມ່ນ "ລຸ້ນຕ່ ຳ ກວ່າ". ສິ່ງນີ້ຖືກ ກຳ ນົດຕາມກົດລະບຽບຕໍ່ໄປນີ້:

• ຖ້າສ່ວນປະກອບ X ແຕກຕ່າງ, ສ່ວນທີ່ມີຄ່າ X ສູງກວ່າແມ່ນ“ ລຸ້ນທີ່ສູງກວ່າ”.
• ຖ້າສ່ວນປະກອບ X ແມ່ນຄືກັນ, ແຕ່ສ່ວນປະກອບ Y ແມ່ນແຕກຕ່າງກັນ, ສ່ວນ ໜຶ່ງ ທີ່ມີຄ່າ Y ສູງກວ່ານັ້ນແມ່ນ“ ລຸ້ນທີ່ສູງກວ່າ”.
• ຖ້າສ່ວນປະກອບຂອງ XY ແມ່ນຄືກັນ, ແຕ່ສ່ວນປະກອບ Z ແມ່ນແຕກຕ່າງກັນ, ສ່ວນ ໜຶ່ງ ທີ່ມີຄ່າ Z ສູງກວ່ານັ້ນແມ່ນ“ ລຸ້ນທີ່ສູງກວ່າ”. ໝາຍ ເລກສອງພາກສ່ວນ XY ແມ່ນ ສຳ ລັບຈຸດປະສົງນີ້, ຖືວ່າເປັນເລກສາມສ່ວນ XY0.

ຕົວຢ່າງampແນວໃດກໍ່ຕາມ, ຕົວເລກຮຸ່ນຕໍ່ໄປນີ້ຈະຢູ່ໃນ ລຳ ດັບຈາກລຸ້ນຕ່ ຳ ສຸດຫາລຸ້ນສູງສຸດ: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. ສໍາລັບ CSS, ການອັບເດດແຕ່ລະອັນເພີ່ມຂຶ້ນພຽງແຕ່ອົງປະກອບ X ຂອງversionາຍເລກເວີຊັນ.

ເງື່ອນໄຂການອະນຸມັດຂອງ BoD
ໃນຕອນທ້າຍຂອງໄລຍະການພັດທະນາສະເພາະຂໍ້ ກຳ ນົດດັ່ງຕໍ່ໄປນີ້ຕ້ອງໄດ້ປະຕິບັດກ່ອນການ ກຳ ນົດສະເພາະ 0.9 / CR ຖືກສົ່ງໃຫ້ BoD ສຳ ລັບການອະນຸມັດ:

• WG ໄດ້ ສຳ ເລັດການວິເຄາະການຄຸ້ມຄອງການທົດສອບ.
• BSTS ໄດ້ ສຳ ເລັດລົງໃ່viewໃນເອກະສານສະເພາະ 0.9/CR ແລະເອກະສານທົດສອບ.
• ທະນາຍຄວາມໄດ້ອະນຸມັດການ ກຳ ນົດ 0.9 / CR.
• ທະນາຍຄວາມໄດ້ອະນຸມັດ CSS CR (ຖ້າມີຂໍ້ສະ ເໜີ ໃໝ່ ທີ່ຕ້ອງການໂດຍສະເພາະ) ເຊິ່ງອາດຈະຖືກຝັງຢູ່ໃນ CR ຫຍໍ້ຂອງຂໍ້ ກຳ ນົດ.
• ທະນາຄານໄດ້ອະນຸມັດ GSS CR ແລະ MDP CR (ຖ້າມີຂໍ້ສະ ເໜີ ໃໝ່ ທີ່ຕ້ອງການໂດຍສະເພາະ).
• BTI ໄດ້ອະນຸມັດ 0.9/CR Test Suite, ICS, ແລະ TCRL, ພ້ອມກັບ IXIT (ສະ ໜອງ ໃຫ້ວ່າ IXIT ແມ່ນຈໍາເປັນເພື່ອດໍາເນີນການທົດສອບໃນ Test Suite). TCRL ແມ່ນທາງເລືອກຢູ່ໃນ s ນີ້tage ສໍາລັບການປັບປຸງຂໍ້ກໍານົດຫຼັກ.
• WG ໄດ້ສົ່ງແຜນການທົດສອບ IOP ຫາ BARB ເພື່ອກວດຄືນview (ຖ້າ BARB ບໍ່ໄດ້ຍົກເວັ້ນການທົດສອບ).

ເອກະສານທີ່ ນຳ ສະ ເໜີ ໃຫ້ BoD ຕ້ອງປະກອບມີຂໍ້ ກຳ ນົດ 0.9 / CR ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BARB, ແລະການ ນຳ ສະ ເໜີ ຕໍ່ BoD ເຊິ່ງຕ້ອງປະກອບມີ:

• ການຮ້ອງຂໍທີ່ຮູ້ຈັກເພື່ອຍົກເວັ້ນການທົດສອບ IOP ຫຼືຂໍ້ ກຳ ນົດໃດ ໜຶ່ງ ທີ່ໄດ້ ກຳ ນົດໄວ້ໃນພາກ 4.3.1
• ບັນຊີລາຍຊື່ຂອງການຂົນສົ່ງທີ່ຂໍ້ມູນສະເພາະໄດ້ສະ ໜັບ ສະ ໜູນ (ເຊັ່ນ: BR / EDR, LE.)
• ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການລະບຸ, ການຍົກເວັ້ນຈາກຂໍ້ ກຳ ນົດດ້ານຄວາມເຂົ້າກັນໄດ້ກັບຄືນ (ອະທິບາຍໃນພາກ 3.3.2) ທີ່ WG ກຳ ລັງຮ້ອງຂໍໂດຍ WG
• ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການລະບຸ, ຄຳ ແນະ ນຳ ຈາກ WG ສຳ ລັບ ຈຳ ນວນລຸ້ນເພື່ອ ນຳ ໃຊ້ກັບຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາ
• ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການ ກຳ ນົດ, ຄຳ ແນະ ນຳ ໃນຕອນທ້າຍຂອງຊີວິດຂອງ WG ສຳ ລັບລຸ້ນກ່ອນ ໜ້າ ນີ້ຂອງຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງ, ລວມທັງເຫດຜົນດ້ານວິຊາການວ່າເປັນຫຍັງການຍໍ້ທໍ້ຫຼືການຖອນເງິນສະບັບໃດ ໜຶ່ງ ຂອງຂໍ້ ກຳ ນົດສະບັບກ່ອນຫຼືບໍ່ຖືກແນະ ນຳ, ແລະເຫດຜົນທີ່ຖືກຕ້ອງ ສຳ ລັບ ຄຳ ແນະ ນຳ
• ທຸກຄວາມກັງວົນທີ່ຮ້າຍແຮງທີ່ຍັງບໍ່ທັນໄດ້ຮັບການແກ້ໄຂຈາກສະມາຊິກ BARB ຫຼື BTI (ຕົວຢ່າງ, ເຫດຜົນສໍາລັບການບໍ່ມີການລົງຄະແນນສຽງໃນລະຫວ່າງການອະນຸມັດ, ຄວາມກັງວົນທີ່ເກີດຈາກ review ຂອງເອກະສານການທົດສອບ, ຫຼືຄວາມກັງວົນວ່າຂໍ້ກໍານົດ 0.9/CR ຢູ່ນອກຂອບເຂດຂອງ FRD ຫຼືກົດບັດກົດາຍ)
• ສະຖານະການກະກຽມຂອງ Profile Tuning Suite (PTS) ຫຼືເຄື່ອງມືທີ່ຈໍາເປັນອື່ນ associated ທີ່ກ່ຽວຂ້ອງກັບການຮັບຮອງເອົາທີ່ໄດ້ກະກຽມໂດຍ BSTS

BoD ອາດຈະເລືອກທີ່ຈະອະນຸມັດການ ກຳ ນົດ 0.9 / CR ສຳ ລັບການທົດສອບ IOP ຕາມທີ່ໄດ້ ກຳ ນົດໄວ້ໃນກົດ ໝາຍ [2], ກ່ອນ BTI ອະນຸມັດເອກະສານການທົດສອບ 0.9 / CR ແລະກ່ອນທີ່ WG ຈະຢືນຢັນວ່າແຜນການທົດສອບ IOP ຕອບສະ ໜອງ ກັບຂໍ້ ກຳ ນົດທີ່ໄດ້ ກຳ ນົດໄວ້ໃນພາກ 4.3.1. .. BoD ຍັງອາດຈະມີເງື່ອນໄຂໃນການອະນຸມັດ 0.9 / CR ໂດຍສະເພາະໃນການທົດສອບ IOP ຕາມການອະນຸມັດຂອງ BTI ຂອງເອກະສານການທົດສອບ 0.9 / CR.

0.9/CR ສtage ຄວາມຕ້ອງການອອກ
0.9/CR Stage ແມ່ນສົມບູນແລະຂັ້ນຕອນການກວດສອບເລີ່ມຕົ້ນເມື່ອ BoD ອະນຸມັດການເລີ່ມທົດສອບ IOP.

4.4 ການຍົກເວັ້ນຂະບວນການພັດທະນາສະເພາະ

WG ອາດຈະຮ້ອງຂໍໃຫ້ຍົກເວັ້ນ ໜຶ່ງ ຫຼືຫຼາຍຂັ້ນຕອນຕໍ່ໄປນີ້:

• ຄ່າ 0.5/DIPD Stage
• 0.7/FIPD Stage
• ການທົດສອບ IOP ພາຍໃນໄລຍະການກວດສອບຄວາມຖືກຕ້ອງ

ເພື່ອຮ້ອງຂໍການສະຫຼະສິດ, WG ຕ້ອງໃຊ້ແມ່ແບບການຍົກເວັ້ນຂະບວນການທີ່ສະ ໜອງ ໃຫ້ໂດຍ Bluetooth SIG [8] ແລະສົ່ງຄໍາຮ້ອງຂໍການສະຫຼະສິດໄປຫາແຕ່ລະຄະນະກໍາມະການ (ຕົວຢ່າງ, BARB ຫຼື BTI) ທີ່ຕ້ອງການຄືນໃ່.view ຫຼືອະນຸມັດຮ່າງເອກະສານສະເພາະຫຼືເອກະສານທົດສອບທີ່ກ່ຽວຂ້ອງຢູ່ທີ່ stage ທີ່ WG ສະ ເໜີ ໃຫ້ສະຫຼະສິດ, ແລະແຕ່ລະຄະນະກໍາມະການເຫຼົ່ານັ້ນຕ້ອງອະນຸມັດຄໍາຮ້ອງຂໍການຍົກເວັ້ນ.

ຄຳ ຮ້ອງຂໍການຍົກເວັ້ນຕ້ອງປະກອບມີດັ່ງຕໍ່ໄປນີ້:

• ການກໍານົດຂອງ s ໄດ້tage (s) ທີ່ WG ຕ້ອງການສະຫຼະສິດ
• ເຫດຜົນວ່າເປັນຫຍັງສtage (s) ຄວນໄດ້ຮັບການຍົກເວັ້ນ
• ການກໍານົດຂອງແຕ່ລະຄະນະກໍາມະການ (ຕົວຢ່າງ, BTI ແລະ/ຫຼື BARB) ທີ່ຕ້ອງການເຮັດຄືນໃ່view ແລະອະນຸມັດຄໍາຮ້ອງຂໍການຍົກເວັ້ນ

ຄະນະ ກຳ ມະການທີ່ພິຈາລະນາການຍົກເວັ້ນອາດຈະຮຽກຮ້ອງໃຫ້ຜູ້ຕາງ ໜ້າ ຂອງ WG ເຮັດການ ນຳ ສະ ເໜີ ເພື່ອຢັ້ງຢືນການຍົກເວັ້ນຂະບວນການ SMPD ກ່ອນການຕັດສິນໃຈ ຄຳ ຮ້ອງຂໍການຍົກເວັ້ນ.

ຖ້າການຍົກເວັ້ນຮຽກຮ້ອງໃຫ້ຍົກເວັ້ນຫຼາຍຂັ້ນຕອນແລະສ່ວນ ໜຶ່ງ ຂອງການຍົກເວັ້ນຖືກປະຕິເສດແລະສ່ວນ ໜຶ່ງ ແມ່ນໄດ້ຮັບການອະນຸມັດ, ຄຳ ຕອບຂອງຄະນະ ກຳ ມະການຕ້ອງຊີ້ບອກວ່າຂັ້ນຕອນໃດໃນ ຄຳ ຮ້ອງຂໍການຍົກເວັ້ນໄດ້ຖືກອະນຸມັດແລະຂັ້ນຕອນໃດຖືກປະຕິເສດ. ຖ້າການຮ້ອງຂໍການຍົກເວັ້ນຖືກປະຕິເສດ, ການແຈ້ງການການປະຕິເສດຕ້ອງປະກອບມີເຫດຜົນຂອງການປະຕິເສດ.

5. ໄລຍະການຮັບຮອງ

ໃນລະຫວ່າງໄລຍະການຮັບຮອງ, WG ຈະດໍາເນີນການທົດສອບ IOP ຕາມຂໍ້ກໍານົດ 0.9/CR ໂດຍມີຈຸດປະສົງເພື່ອສົ່ງບົດລາຍງານການທົດສອບ IOP ສໍາລັບ BARB re.view ແລະການອະນຸມັດ. ເມື່ອໃດກໍ່ຕາມທີ່ເປັນໄປໄດ້, ການທົດສອບ IOP ກ່ຽວກັບການປັບປຸງສະເປັກຄວນຖືກດໍາເນີນຕໍ່ກັບການຮ່າງຂໍ້ກໍານົດສະບັບລວມ. ນອກຈາກນັ້ນ, ສະມາຊິກ Reviewຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນກົດ[າຍ [2], ເລີ່ມຕົ້ນໃນໄລຍະນີ້.

ຖ້າຂໍ້ ກຳ ນົດ (ຫລືການເພີ່ມປະສິດທິພາບ) ບໍ່ ຈຳ ເປັນຕ້ອງມີການທົດສອບ IOP, ດັ່ງນັ້ນການທົດສອບ IOP ພາຍໃນໄລຍະການກວດສອບຄວາມຖືກຕ້ອງອາດຈະຖືກຍົກເວັ້ນໂດຍໃຊ້ຂັ້ນຕອນທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກທີ 4.4.

ຕະຫຼອດໄລຍະການທົດສອບ IOP (ເຊິ່ງອາດຈະເປັນ ໜຶ່ງ ຫຼືຫຼາຍເຫດການ), WG ຄວນຕິດຕາມບັນຫາຕ່າງ using ໂດຍນໍາໃຊ້ລະບົບຕິດຕາມບັນຫາຂອງ Bluetooth SIG ແລະເລົ່າຄືນໃincor່ເພື່ອລວມເອົາການອັບເດດເຂົ້າໃນຮ່າງຂໍ້ກໍານົດສະເພາະ, ເອກະສານການທົດສອບ, ແລະແຜນການທົດສອບ IOP. ເມື່ອການທົດສອບ IOP ສະຫຼຸບ, WG ຕ້ອງເຮັດການອັບເດດສະບັບຮ່າງໃຫ້ລະອຽດແລະເອກະສານທົດສອບເພື່ອແກ້ໄຂທຸກບັນຫາ, ແລະກະກຽມແລະສົ່ງບົດລາຍງານການທົດສອບ IOP ຫາ BARB ເພື່ອກວດຄືນ.view ແລະການອະນຸມັດ. ອັນນີ້ສະແດງໃຫ້ເຫັນຢູ່ໃນຮູບ 5.1.

ໃນໄລຍະການພິສູດຄວາມຖືກຕ້ອງມີຫຼາຍກິດຈະ ກຳ ທີ່ອາດຈະເລີ່ມຕົ້ນ. ກິດຈະ ກຳ ເຫຼົ່ານີ້ອາດຈະເກີດຂື້ນພ້ອມກັນແລະປະກອບມີດັ່ງຕໍ່ໄປນີ້:

• ຂໍ້ ກຳ ນົດ 0.9/CR ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BoD ແມ່ນມີໃຫ້ກັບສະມາຊິກທຸກຄົນໂດຍ BSTS ພ້ອມກັບແຈ້ງການເລີ່ມສະມາຊິກຄືນໃ່.view ໄລຍະເວລາທີ່ຕ້ອງການໂດຍກົດາຍ.
• ທຸກໆການປັບປຸງທີ່ຕ້ອງການແມ່ນຖືກລວມເຂົ້າໃນ CSS (ເຊິ່ງອາດຈະຖືກຝັງເຂົ້າໃນ CR ຫຍໍ້ຂອງຂໍ້ ກຳ ນົດສະເພາະ).
• ຄໍານິຍາມລັກສະນະຫລືຄໍາອະທິບາຍແມ່ນຖືກລວມເຂົ້າໃນການກໍານົດ GSS ເຊັ່ນດຽວກັນກັບ PTS ສໍາລັບການທົດສອບ IOP.
• ຄໍານິຍາມກ່ຽວກັບຄຸນສົມບັດ Mesh ແມ່ນຖືກລວມເຂົ້າໃນການກໍານົດ MDP ເຊັ່ນດຽວກັນກັບ PTS ສໍາລັບການທົດສອບ IOP.
• BSTS ຊ່ວຍໃຫ້ການລົງທະບຽນເວທີຂອງ IOP ແລະເຄື່ອງມືປ້ອນຜົນໄດ້ຮັບເຂົ້າໃນການກະກຽມ ສຳ ລັບການທົດສອບ IOP.
• ການທົດສອບ IOP, ຖ້າຕ້ອງການ (ເບິ່ງພາກ 5.1).
• Review ຄຳ ເຫັນແລະບັນຫາຕ່າງ including, ລວມທັງ ຄຳ ທີ່ສົ່ງມາເປັນຜົນມາຈາກການທົດສອບ IOP, ໄດ້ຖືກປະມວນຜົນແລະການປ່ຽນແປງໄດ້ຖືກລວມເຂົ້າກັບຮ່າງເອກະສານສະເພາະ.

5.1 ການທົດສອບ IOP

ຈຸດປະສົງຫຼັກຂອງການທົດສອບ IOP ແມ່ນເພື່ອກວດສອບຄວາມຖືກຕ້ອງຕາມສະເປັກ, ຕົວຢ່າງ:ample, ກວດເບິ່ງຄວາມຖືກຕ້ອງແລະຄວາມບໍ່ແນ່ນອນພາຍໃນຂໍ້ຄວາມ, reviewສໍາລັບຄວາມຜິດພາດການອອກແບບພື້ນຖານແລະການລະເລີຍ, ແລະການສະ ໜອງ ການກວດສອບຕໍ່ກັບຂໍ້ກໍານົດທີ່ໄດ້ກໍານົດໄວ້ໃນເມື່ອກ່ອນທີ່ພັດທະນາກ່ອນ ໜ້າ ນີ້ໃນຂັ້ນຕອນການພັດທະນາຂໍ້ມູນຈໍາເພາະ. ການທົດສອບ IOP ອາດຈະສົ່ງຜົນໃຫ້ມີການປ່ຽນແປງຂໍ້ກໍານົດຮ່າງແລະເຫດການທົດສອບ IOP ຫຼາຍອັນອາດຈະຈໍາເປັນເພື່ອໃຫ້ສໍາເລັດການທົດສອບທີ່ຈໍາເປັນທັງົດ.

ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ຈະໃຫ້ສະມາຊິກທີ່ຢູ່ນອກ WG ມີໂອກາດເຂົ້າຮ່ວມໃນການທົດສອບ IOP ເພາະວ່າພວກເຂົາສະ ໜອງ ເອກະລາດ view ຂອງສະເປັກສະເພາະແລະສາມາດເປີດເຜີຍພື້ນທີ່ຂອງຄວາມບໍ່ຊັດເຈນໃນສະເພາະທີ່ອາດຈະບໍ່ເປັນຫຼັກຖານໃຫ້ກັບສະມາຊິກຂອງ WG ຜູ້ພັດທະນາຮ່າງ. ກ່ອນເຫດການທົດສອບ IOP ແຕ່ລະຄັ້ງ, BSTS ຈະເຮັດໃຫ້ລາຍລະອຽດເຫດການ, ລາຍລະອຽດສະບັບຮ່າງລ້າສຸດ, ຊຸດທົດສອບ, ແລະແຜນການທົດສອບ IOP ມີຢູ່ແລະຈະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຮູ້ໂດຍສະເພາະ ໜຶ່ງ ເດືອນກ່ອນແຕ່ລະເຫດການ. ສະບັບຮ່າງສະບັບປັບປຸງ, ຊຸດທົດສອບ, ແລະແຜນການທົດສອບ IOP ທີ່ໃຊ້ຢູ່ໃນເຫດການທົດສອບ IOP ຄວນມີໃຫ້ຢ່າງ ໜ້ອຍ ໜຶ່ງ ອາທິດກ່ອນແຕ່ລະເຫດການ.

ໃນລະຫວ່າງການທົດສອບ IOP, ການປະສົມປະສານຂອງເວທີຄູ່ຈະພະຍາຍາມປະຕິບັດການທົດສອບແລະຜູ້ເຂົ້າຮ່ວມການທົດສອບ IOP ຈະບັນທຶກຜົນໄດ້ຮັບທີ່ຜ່ານ / ລົ້ມເຫຼວຂອງແຕ່ລະການທົດສອບແລະຄວາມຄິດເຫັນ. ບົດສະຫລຸບທີ່ບໍ່ລະບຸຊື່ຂອງຜົນໄດ້ຮັບເຫຼົ່ານີ້ (ໂດຍອ້າງອີງໃສ່ຕົວຢ່າງ, "ແພລະຕະຟອມ A", "ເວທີ B", ແລະອື່ນໆ) ແລະ ຄຳ ເຫັນຕ່າງໆຈະຖືກລວບລວມໃນໄລຍະກິດຈະ ກຳ ການທົດສອບ IOP ແລະໃຫ້ສະມາຊິກຂອງ WG ເຂົ້າໃນລະຫວ່າງແລະຫຼັງ IOP ເຫດການທົດສອບ. ໃນກໍລະນີຂໍ້ມູນເພີ່ມເຕີມແມ່ນມີຄວາມ ຈຳ ເປັນເພື່ອໃຫ້ມີຄວາມເຂົ້າໃຈດີຂື້ນກ່ຽວກັບ ຄຳ ເຫັນຫຼືຂໍ້ບົກຜ່ອງຕ່າງໆທີ່ເກີດຂື້ນໃນລະຫວ່າງການທົດສອບ IOP, BSTS ອາດຈະເຮັດ ໜ້າ ທີ່ເປັນຕົວກາງເພື່ອເກັບ ກຳ ຂໍ້ມູນເພີ່ມເຕີມຈາກສະມາຊິກທີ່ສົ່ງ.

ຖ້າເປັນໄປໄດ້, PTS ຄວນໄດ້ຮັບການປັບປຸງເພື່ອສະ ໜັບ ສະ ໜູນ ການທົດສອບ IOP ກັບແພລະຕະຟອມທຸກຊັ້ນທີ່ຢູ່ ເໜືອ ລະບົບອິນເຕີເຟດຂອງ Host Controller (HCI), ແລະມີຢູ່ໃນເຫດການທົດສອບ IOP ສຳ ລັບຊັ້ນເຫຼົ່ານັ້ນ. ເຄື່ອງມືທົດສອບອື່ນໆອາດຈະມີຢູ່ໃນເຫດການທົດສອບ IOP. ບົດສະຫຼຸບກ່ຽວກັບຜົນຂອງການທົດສອບກັບ PTS ຫຼືເຄື່ອງມືທົດສອບອື່ນໆ (ຖ້າມີ) ຄວນຖືກລວມເຂົ້າໃນບົດລາຍງານການທົດສອບ IOP.

ການທົດສອບ IOP ຈະເປີດໃຫ້ສະມາຊິກທຸກຄົນທີ່ຕ້ອງການສະ ເໜີ ການຈັດຕັ້ງປະຕິບັດຕົວຢ່າງ, ເຖິງຢ່າງໃດກໍ່ຕາມ, Bluetooth SIG ອາດຈະມີເງື່ອນໄຂການມີສ່ວນຮ່ວມໃນການຍອມຮັບຂໍ້ຕົກລົງກັບ Bluetooth SIG (ລວມທັງຂໍ້ຕົກລົງການມີສ່ວນຮ່ວມແລະຄວາມລັບ). WG ຮັບຜິດຊອບໃນການປຸງແຕ່ງແລະແກ້ໄຂບັນຫາທີ່ຄົ້ນພົບໃນລະຫວ່າງການທົດສອບ IOP, ແລະປັບປຸງເອກະສານທີ່ຖືກກະທົບ; ການປ່ຽນແປງທີ່ໄດ້ຮັບການອະນຸມັດຈາກ WG ຕ້ອງຖືກລວມເຂົ້າກັບການປັບປຸງຮ່າງເອກະສານສະເພາະແລະເອກະສານການທົດສອບເພື່ອ ນຳ ໃຊ້ໃນແຕ່ລະເຫດການທົດສອບ IOP.

ກ່ອນຂັ້ນຕອນການຢັ້ງຢືນ, WGs ອາດຈະ ດຳ ເນີນການທົດສອບ IOP ເບື້ອງຕົ້ນໃນເຫດການຕ່າງໆທີ່ເປີດໃຫ້ສະມາຊິກຂອງ WG, ເຖິງຢ່າງໃດກໍ່ຕາມຜົນຂອງການທົດສອບທີ່ບໍ່ເປັນທາງການອາດຈະບໍ່ຖືກລວມເຂົ້າໃນຜົນການທົດສອບ IOP.

ມັນອາດຈະເກີດຂື້ນວ່າທຸກບາດກ້າວທີ່ ນຳ ໄປສູ່ເຫດການທົດສອບ IOP ຄັ້ງ ທຳ ອິດແມ່ນປະຕິບັດຕາມ, ລວມທັງວັນທີແລະສະຖານທີ່ IOP ທີ່ຖືກປະກາດໂດຍມີຄວາມຕັ້ງໃຈທີ່ຈະເລີ່ມທົດສອບ IOP, ແຕ່ການອະນຸມັດຂອງ BoD ບໍ່ໄດ້ຮັບປະກັນກ່ອນເຫດການທົດສອບ. ໃນກໍລະນີນີ້, BoD ອາດຈະອະນຸຍາດໃຫ້ມີການລວມເອົາຜົນການທົດສອບທີ່ຖືກເກັບກ່ອນການອະນຸມັດຂອງ BoD ເພື່ອເລີ່ມການທົດສອບ IOP, ເນື່ອງຈາກວ່າຜົນໄດ້ຮັບທີ່ເກັບໄດ້ແມ່ນອີງໃສ່ຂໍ້ມູນສະເພາະແລະ Test Suite ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BoD.

ການທົດສອບ IOP ແມ່ນບໍ່ ຈຳ ເປັນ ສຳ ລັບການປັບປຸງ CSS, GSS, ຫຼື MDP.

ບົດລາຍງານການທົດສອບ IOP
ຫຼັງຈາກການທົດສອບ IOP ສໍາເລັດ, WG ຕ້ອງສົ່ງບົດລາຍງານການທົດສອບ IOP ຫາ BARB ໂດຍມີຈຸດປະສົງສະແດງໃຫ້ເຫັນວ່າຈໍານວນແພລະຕະຟອມເອກະລາດທີ່ຕ້ອງການໄດ້ຜ່ານການທົດສອບທີ່ກໍານົດໄວ້ແລ້ວ. BARB ຕ້ອງເຮັດຄືນໃ່view ແລະອະນຸມັດຫຼືປະຕິເສດບົດລາຍງານການທົດສອບ IOP ແລະຈະແຈ້ງໃຫ້ WG ຮູ້ຖ້າມີການທົດສອບ IOP ເພີ່ມເຕີມກ່ອນທີ່ຈະສົ່ງຊຸດຂໍ້ກໍານົດສະບັບຮ່າງການລົງຄະແນນສຽງໃຫ້ BoD. BSTS ແລະ WG ຕ້ອງຮັບປະກັນວ່າບໍ່ມີຂໍ້ມູນການລະບຸສະມາຊິກປາກົດຢູ່ໃນບົດລາຍງານການທົດສອບ IOP ກ່ອນທີ່ຈະສົ່ງບົດລາຍງານໃຫ້ BARB.

ບົດລາຍງານການທົດສອບ IOP ຕ້ອງປະກອບມີ:

• ບັນຊີລາຍຊື່ຂອງເຫດການທົດສອບ IOP ທັງ ໝົດ ທີ່ເກີດຂື້ນໃນໄລຍະການກວດສອບຄວາມຖືກຕ້ອງລວມທັງວັນທີແລະສະຖານທີ່.
• ຈຳ ນວນບໍລິສັດສະມາຊິກແລະເວທີທີ່ເປັນເອກະລາດທີ່ເຂົ້າຮ່ວມໃນແຕ່ລະເຫດການ IOP ລວມທັງວ່າ PTS ຖືກ ນຳ ໃຊ້.
• ບັນຊີລາຍຊື່ຂອງສະເພາະ, ແບບທົດລອງ, ແລະແບບແຜນການທົດສອບ IOP ທີ່ໃຊ້ໃນແຕ່ລະເຫດການ.
• ບົດສະຫຼຸບຜູ້ບໍລິຫານລະບຸວ່າຄະດີທົດສອບທັງ ໝົດ ຕອບສະ ໜອງ ໄດ້ຕາມເງື່ອນໄຂການຜ່ານຂັ້ນຕ່ ຳ ສຸດຫຼືບໍ່.
• ບົດສະຫຼຸບຂອງການປ່ຽນແປງໃດໆຈາກຂໍ້ ກຳ ນົດຂອງແຜນການທົດສອບ IOP ທີ່ໄດ້ ກຳ ນົດໄວ້ໃນພາກ 4.3.1 ແລະເຫດຜົນ ສຳ ລັບແຕ່ລະຕົວແປ.
• ບົດສະຫລຸບຂອງການຄຸ້ມຄອງ PTS ສຳ ລັບກໍລະນີທົດສອບໃນ Test Suite.
• ບັນຊີລາຍຊື່ຂອງກໍລະນີທົດສອບທັງ ໝົດ (ລວມທັງການທົດສອບຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ) ຈາກແຜນການທົດສອບ IOP, ຈຳ ນວນຂອງໃບທົດສອບ, ຈຳ ນວນຂອງຄວາມລົ້ມເຫຼວຂອງການທົດສອບ, ແລະວ່າເງື່ອນໄຂຕ່ ຳ ສຸດໄດ້ຖືກຕອບສະ ໜອງ ຕໍ່ກໍລະນີທົດສອບລວມທັງ ຄຳ ອະທິບາຍວ່າເປັນຫຍັງຂໍ້ ກຳ ນົດໃດ ໜຶ່ງ ບໍ່ໄດ້ ໄດ້ພົບ.
• ສະຫຼຸບບັນຫາ, ຄຳ ເຫັນແລະ ຄຳ ຖາມຢູ່ໃນແຕ່ລະເຫດການ (ລວມທັງບັນຫາເຫຼົ່ານັ້ນ filed ຕໍ່ກັບສະເປັກລະຫວ່າງການທົດສອບ IOP) ແລະຜົນກະທົບຕໍ່ເອກະສານສະເພາະແລະເອກະສານການທົດສອບ.

5.2 ຄວາມຕ້ອງການອອກຂັ້ນຕອນຂອງການກວດສອບຄວາມຖືກຕ້ອງ

ໄລຍະການຮັບຮອງແມ່ນ ສຳ ເລັດແລະຂັ້ນຕອນການອະນຸມັດ / ການຮັບຮອງເອົາເລີ່ມຕົ້ນເມື່ອ BARB ໄດ້ຮັບຮອງບົດລາຍງານການທົດສອບ IOP (ເວັ້ນເສຍແຕ່ວ່າການທົດລອງຖືກຍົກເວັ້ນໂດຍ BARB) ແລະທຸກຂໍ້ ກຳ ນົດດັ່ງຕໍ່ໄປນີ້ໄດ້ຖືກບັນລຸ:

• BSTS ໄດ້ເຮັດໃຫ້ຂໍ້ກໍານົດ 0.9/CR ທີ່ໄດ້ອະນຸມັດໃຫ້ກັບສະມາຊິກທຸກຄົນສໍາລັບສະມາຊິກ Review ຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນກົດandາຍແລະແຈ້ງສະມາຊິກທຸກຄົນກ່ຽວກັບການມີຢູ່ຂອງມັນ.
• ທຸກໆບັນຫາທີ່ຖືກລະບຸໃນລະຫວ່າງການທົດສອບ IOP, ແລະທີ່ມີຜົນກະທົບຕໍ່ການທົດສອບ, ໄດ້ຖືກລວມເຂົ້າແລະທົດສອບ.
• WG ໄດ້ ສຳ ເລັດການທົດສອບ IOP (ເວັ້ນເສຍແຕ່ວ່າການທົດລອງຈະຖືກຍົກເວັ້ນໂດຍ BARB).

 

6. ຂັ້ນຕອນການຮັບຮອງເອົາ / ການອະນຸມັດ

ໃນລະຫວ່າງໄລຍະການຮັບຮອງເອົາ/ການອະນຸມັດ, ຂໍ້ກໍານົດແລະເອກະສານການທົດສອບທີ່ກ່ຽວຂ້ອງແມ່ນໄດ້ສະຫຼຸບແລ້ວ, BARB, BQRB, ແລະການອະນຸມັດ BTI ແມ່ນໄດ້ຮັບ, ແຈ້ງການສະ ເໜີ ວັນທີການຮັບຮອງເອົາພ້ອມກັບສະບັບສຸດທ້າຍຂອງຮ່າງຂໍ້ກໍານົດທີ່ສົ່ງໃຫ້ BoD ເພື່ອຮັບຮອງເອົາ ( ຮ່າງການລົງຄະແນນສຽງ), ແລະຊຸດຂໍ້ກໍານົດສຸດທ້າຍແມ່ນໄດ້ສົ່ງໃຫ້ BoD. ຫຼັງຈາກໄລຍະເວລາຕໍາ່ສຸດທີ່ຂອງສະມາຊິກ Review ທີ່ກໍານົດໄວ້ໂດຍກົດ[າຍ [2]) ໄດ້ຮັບຄວາມພໍໃຈ, BoD ຈະພິຈາລະນາຂໍ້ກໍານົດສະເພາະສໍາລັບການຮັບຮອງເອົາໃນວັນທີຮັບເອົາ. ຫຼັງຈາກການຮັບຮອງເອົາ, ຂໍ້ກໍານົດໄດ້ຖືກເຜີຍແຜ່ແລະເປີດໃຊ້ລະບົບຄຸນສົມບັດ. ຂັ້ນຕອນການຮັບຮອງເອົາ/ການອະນຸມັດແມ່ນໄດ້ສະແດງຢູ່ໃນຮູບ 6.1.

6.1 ຮ່າງການລົງຄະແນນສຽງ

ຮ່າງການລົງຄະແນນສຽງຖືກສ້າງຂື້ນໂດຍການລວມເອົາການປັບປຸງ (ສະ ໜອງ ໃນໄລຍະການຮັບຮອງເອົາ) ເຂົ້າໃນເອກະສານສະເພາະທີ່ຕ້ອງການ, ແລະກະກຽມຮ່າງຮ່າງສຸດທ້າຍຂອງຂໍ້ ກຳ ນົດສະບັບ ໃໝ່. ສຳ ລັບການຍົກລະດັບສະເພາະ, BSTS ຈະສ້າງການ ກຳ ນົດສະເພາະໂດຍການລວມເອົາ CR ໜຶ່ງ ຫຼືຫຼາຍກວ່ານັ້ນເຂົ້າໄປໃນສະບັບທີ່ສູງກວ່າຂອງການ ກຳ ນົດສະບັບທີ່ໄດ້ຮັບຮອງເອົາມາກ່ອນ (ເບິ່ງພາກ 4.3.2) ຖ້າບໍ່ ສຳ ເລັດກ່ອນຂັ້ນຕອນການກວດສອບຄວາມຖືກຕ້ອງ.

ຖ້າມີການປ່ຽນແປງໃຫ້ກັບສະເພາະໃນໄລຍະນີ້ແລະ WG, BARB, ຫຼື BTI ກຳ ນົດວ່າການປ່ຽນແປງໃດ ໜຶ່ງ ຕ້ອງການການທົດສອບ IOP ເພີ່ມເຕີມ, ຂໍ້ ກຳ ນົດດັ່ງກ່າວຈະກັບຄືນໄປຫາສ່ວນທົດສອບ IOP ຂອງລະດັບຄວາມຖືກຕ້ອງ ສຳ ລັບ WG ເພື່ອ ດຳ ເນີນການທົດສອບເພີ່ມເຕີມ. ໃນໄລຍະການຮັບຮອງເອົາ / ການອະນຸມັດ, ເອກະສານຕໍ່ໄປນີ້ຈະເຮັດໃຫ້ ສຳ ເລັດແລະເຮັດໃຫ້ BoD ກ່ອນວັນຮັບຮອງເອົາ:

• ຮ່າງການລົງຄະແນນສຽງ
• ທຸກໆຂໍ້ສະເພາະທີ່ສະ ໜັບ ສະ ໜູນ (ເຊັ່ນ, CSS, GSS, MDP) ຕາມຄວາມຕ້ອງການ ສຳ ລັບປະເພດສະເພາະ (ຫຼືການເພີ່ມປະສິດທິພາບ) ທີ່ກ່ຽວຂ້ອງ, ຖ້າບໍ່ໄດ້ຮັບຮອງເອົາໃນເມື່ອກ່ອນ
• ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການ ກຳ ນົດສະບັບ, ຮູບແບບການຕິດຕາມການປ່ຽນແປງຂອງສະບັບສະເພາະທີ່ໄດ້ຮັບຮອງເອົາສະແດງໃຫ້ເຫັນການປ່ຽນແປງທີ່ໄດ້ສະ ເໜີ ໃນຮ່າງການລົງຄະແນນສຽງ
• ຄຳ ອະທິບາຍຈາກ WG ກ່ຽວກັບຂໍ້ ກຳ ນົດດ້ານຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ (ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 3.3.2) ທີ່ບໍ່ໄດ້ບັນລຸແລະຄວາມສົມເຫດສົມຜົນ ສຳ ລັບການຍົກເວັ້ນໃດໆ
• ລາຍລະອຽດຈາກ WG ຂອງຄວາມຕ້ອງການແຜນການທົດສອບ IOP ໃດ ໜຶ່ງ (ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 4.3.1) ທີ່ຍັງບໍ່ທັນບັນລຸໄດ້ແລະການໃຫ້ເຫດຜົນວ່າມີການບ່ຽງເບນຕ່າງ along ພ້ອມກັບບົດລາຍງານການທົດສອບ IOP (ເຊິ່ງອາດຈະສະ ໜອງ ໃຫ້ໂດຍການສະ ໜອງ ການເຊື່ອມຕໍ່ຫາສໍາເນົາຢູ່ເທິງ Bluetooth SIG webສະຖານທີ່)
• ຄໍາແນະນໍາຈາກ WG ສໍາລັບການເສື່ອມລາຄາຫຼືການຖອນຕົວຂອງສະບັບກ່ອນ ໜ້າ ໃດ specification ຂອງຂໍ້ກໍານົດທີ່ໄດ້ຮັບຮອງເອົາພ້ອມກັບການໃຫ້ເຫດຜົນ, ເນັ້ນການປ່ຽນແປງນັບຕັ້ງແຕ່ 0.9/CR Stage ຄໍາແນະນໍາໃນຕອນທ້າຍຂອງຊີວິດ
• ບົດສະຫຼຸບ, ກະກຽມໂດຍ WG, ກ່ຽວກັບການປ່ຽນແປງລັກສະນະຫຼືການເຮັດວຽກຕັ້ງແຕ່ສະເພາະ 0.9 / CR (ຖ້າມີ)
• ບົດສະຫຼຸບ, ກະກຽມໂດຍ BARB, ກ່ຽວກັບຄວາມກັງວົນທີ່ຍົກຂຶ້ນໂດຍສະມາຊິກຂອງ BARB ວ່າຂໍ້ ກຳ ນົດທີ່ຜະລິດໂດຍ WG ແມ່ນເກີນຂອບເຂດຂອງກົດ ໝາຍ ທີ່ຖືກອະນຸມັດໂດຍ BoD (ຖ້າມີ)
• ລາຍການບັນຫາກົດunາຍທີ່ຍັງບໍ່ທັນໄດ້ແກ້ໄຂຈາກກົດreາຍview (ຖ້າມີ)
• ຊຸດທົດສອບທີ່ອະນຸມັດໂດຍ BTI, ພ້ອມດ້ວຍບົດສະຫລຸບທີ່ໄດ້ຮັບການອະນຸມັດຈາກ WG ກ່ຽວກັບການຄຸ້ມຄອງການທົດສອບຂອງຂໍ້ ກຳ ນົດກ່ຽວກັບການລົງຄະແນນສຽງ. ໃນກໍລະນີທີ່ມີການເພີ່ມຫລືແກ້ໄຂການເຮັດວຽກ ໃໝ່ ໂດຍບໍ່ມີການຄຸ້ມຄອງການທົດສອບ, ຕ້ອງມີການຂຽນແຈ້ງການເປັນລາຍລັກອັກສອນ ສຳ ລັບການຍົກເລີກ
• ICS ແລະ IXIT ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BTI (ຖ້າຕ້ອງການໂດຍສະເພາະ)
• TCRL ໄດ້ຮັບການອະນຸມັດຈາກທັງ BTI ແລະ BQRB
• ບົດລາຍງານທີ່ກະກຽມໂດຍ BSTS ຮ່ວມກັບ BTI ກ່ຽວກັບສະຖານະຂອງຄວາມພ້ອມຂອງເຄື່ອງມື (ຕົວຢ່າງ, PTS ແລະເຄື່ອງມືທົດສອບອື່ນໆ, Bluetooth Launch Studio) ລວມທັງຖ້າມີກໍລະນີທົດສອບໃດໆໃນ TCRL ບໍ່ໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ຈາກເຄື່ອງມືທົດສອບ
• ບົດສະຫຼຸບ, ກະກຽມໂດຍ WG, ຂອງ ຈຳ ນວນທີ່ຖືກມອບ ໝາຍ ທີ່ ຈຳ ເປັນທັງ ໝົດ
• ລາຍການກວດສອບການຮັບຮອງເອົາການກະກຽມໂດຍ BSTS ແລະ WG ສະແດງໃຫ້ເຫັນວ່າການປົດປ່ອຍໃນພາກນີ້ໄດ້ ສຳ ເລັດແລ້ວ
• ຂໍ້ມູນອື່ນໆທັງ ໝົດ ທີ່ BoD ຮ້ອງຂໍ

ໃນໄລຍະການຮັບຮອງເອົາ / ການອະນຸມັດ, WG ຄວນ ນຳ ໃຊ້ລະບົບຕິດຕາມບັນຫາຂອງ Bluetooth SIG ເພື່ອເກັບ ກຳ ບັນຫາແລະ ຄຳ ເຫັນຕ່າງໆຕໍ່ຮ່າງເອກະສານສະເພາະແລະເອກະສານການທົດສອບເພື່ອໃຫ້ບັນຊີດັ່ງກ່າວຖືກລົງບັນຊີໃນການ ສຳ ເລັດເອກະສານ ກຳ ນົດການລົງຄະແນນສຽງ. ສຳ ລັບການເພີ່ມປະສິດທິພາບຂອງການ ກຳ ນົດ, ທັງ ໝົດ errata ທີ່ໄດ້ຮັບການອະນຸມັດທີ່ກ່ຽວຂ້ອງ (ໝາຍ ຄວາມວ່າ errata ທີ່ໄດ້ຮັບການອະນຸມັດຍັງບໍ່ທັນປະສົມປະສານ) ຕ້ອງໄດ້ລວມເຂົ້າກັນ, ແລະຕ້ອງໄດ້ຮັບການ ກຳ ນົດໂດຍ ນຳ ໃຊ້ການປ່ຽນແປງທີ່ຕິດຕາມ

ອົງການ WG ຕ້ອງສົ່ງຮ່າງຂໍ້ກໍານົດສະບັບສຸດທ້າຍໃຫ້ BSTS ເພື່ອຮັບຮອງທາງກົດາຍview. ສຳ ລັບສະເພາະໃ,່, ກົດreາຍໃ່view ຈະລວມເອົາສະເປັກທັງົດ. ສໍາລັບການປັບປຸງສະເປັກ, review ຈະສຸມໃສ່ຕົ້ນຕໍຢູ່ໃນພາກສ່ວນທີ່ປ່ຽນແປງຂອງສະເປັກ. ຈຸດປະສົງຂອງກົດreາຍຄືນໃ່view ຕົ້ນຕໍແມ່ນເພື່ອກໍານົດຄວາມສ່ຽງທາງດ້ານກົດthatາຍທີ່ WG ຄວນພິຈາລະນາແລະຊອກຫາວິທີແກ້ໄຂ. ຄຳ ຕິຊົມທາງກົດwillາຍຈະຖືກຈັດປະເພດຕາມຄວາມຮຸນແຮງ. ຖ້າເປັນທາງເລືອກທາງກົດreາຍview ໄດ້ປະຕິບັດຢູ່ທີ່ 0.9/CR Stage, ສະບັບທີ່ສົ່ງໃຫ້ສໍາລັບກົດreາຍຄືນໃ່view ຕ້ອງໄດ້ສະແດງ, ຕາມການປ່ຽນແປງທີ່ຕິດຕາມ, ການປ່ຽນແປງທັງthatົດທີ່ໄດ້ເຮັດຕັ້ງແຕ່ສະບັບນັ້ນ (ສ້າງຂຶ້ນໂດຍ WG ຫຼື BSTS). ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view, WG ແລະ BSTS ຈະຕົກລົງເຫັນດີກ່ຽວກັບຄໍາຄິດເຫັນທີ່ຈະຖືກລວມເຂົ້າໃນຮ່າງຂໍ້ກໍານົດສະເພາະ. ຖ້າມີ ຄຳ ເຫັນທາງກົດunາຍທີ່ຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂຈາກທາງກົດreາຍview ຢູ່ໃນຮ່າງຂໍ້ກໍານົດສະເພາະ, ປະທານ WG ອາດຈະຮ້ອງຂໍເວລາໃນວາລະ BoD ເພື່ອຕົກລົງກັນກ່ຽວກັບການແກ້ໄຂ.

ຄຽງຄູ່ກັບກົດreາຍview, ອົງການ WG ຕ້ອງສົ່ງຮ່າງຂໍ້ກໍານົດສະບັບດັ່ງກ່າວໄປຫາ BARB ເພື່ອທົບທວນຄືນview. ພາຍຫຼັງການຍື່ນສະ ເໜີ ເບື້ອງຕົ້ນໃຫ້ BARB, BSTS ຈະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຊາບວ່າຮ່າງຂໍ້ກໍານົດສະບັບດັ່ງກ່າວໄດ້ຖືກສົ່ງໄປໃຫ້ BARB ເພື່ອທົບທວນຄືນ.view ແລະມັນຍັງມີໃຫ້ກັບສະມາຊິກ Review. ຖ້າ WG ຍື່ນສະ ເໜີ ການປັບປຸງຕໍ່ກັບຂໍ້ກໍານົດຮ່າງສໍາລັບ BARB re-review, BSTS ຈະສົ່ງແຈ້ງການເພີ່ມເຕີມໃຫ້ກັບສະມາຊິກທຸກຄົນເປັນແຕ່ລະໄລຍະ.

ພາຍຫຼັງການສໍາເລັດຂອງ BARB review, WG ແລະ BARB ຈະຕົກລົງເຫັນດີກ່ຽວກັບຄໍາຄິດເຫັນທີ່ຈະຖືກລວມເຂົ້າໃນຮ່າງຂໍ້ກໍານົດສະເພາະ.

ຖ້າຖືກຕ້ອງຕາມກົດາຍview ຜົນໄດ້ຮັບໃນການປ່ຽນແປງທີ່ ສຳ ຄັນໃດ ໜຶ່ງ, ເພີ່ມເຕີມຄືນໃ່view ໂດຍ BARB ອາດຈະຕ້ອງການ. ເຊັ່ນດຽວກັນ, ຖ້າຫາກວ່າ BARB review ສົ່ງຜົນໃຫ້ມີການປ່ຽນແປງອັນໃຫຍ່ຫຼວງໃດ ໜຶ່ງ, BSTS ຈະກໍານົດວ່າຈະມີການປັບປຸງກົດadditionalາຍໃadditional່ຫຼືບໍ່view ຂອງການປ່ຽນແປງເຫຼົ່ານັ້ນແມ່ນຕ້ອງການ. ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view ແລະ BARB review, BARB ຕ້ອງອະນຸມັດຫຼືປະຕິເສດຮ່າງການລົງຄະແນນສຽງ.

ຖ້າເອກະສານການສອບເສັງຕ້ອງການການປັບປຸງ, BSTS ຈະຊ່ວຍ WG ໃນການປັບປຸງເອກະສານການສອບເສັງ. BTI ຕ້ອງອະນຸມັດຫລືປະຕິເສດເອກະສານການສອບເສັງ. ຖ້າໄດ້ຮັບການອະນຸມັດຈາກ BTI, BTI ຈະຊ່ວຍໃນການເຮັດສຸດທ້າຍ TCRL ແລະມອບເອກະສານນີ້ໃຫ້ BQRB ພ້ອມກັບ ICS, IXIT ແລະ Test Suite ທີ່ກ່ຽວຂ້ອງ. BSTS ຈະປະເມີນວັນເວລາຂອງກອງປະຊຸມ BoD ເມື່ອ BoD ຕັ້ງໃຈຈະລົງຄະແນນສຽງຮັບຮອງເອົາຮ່າງເອກະສານລົງຄະແນນສຽງ (ວັນຮັບຮອງເອົາ) ແລະໃຫ້ BTI ສຳ ລັບໃຊ້ໃນ TCRL. ການອະນຸມັດຂອງ BARB ກ່ຽວກັບການລະບຸ, ການອະນຸມັດ BTI ຂອງເອກະສານການທົດສອບທັງ ໝົດ (ລວມທັງ Test Suite, TCRL, ICS, ແລະ IXIT), ແລະການອະນຸມັດ BQRB ຂອງ TCRL ຕ້ອງເກີດຂື້ນໃນຫຼືກ່ອນວັນທີຮັບຮອງເອົາ.

BSTS ຈະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຮູ້ກ່ຽວກັບການສະຫຼຸບແລະການມີຢູ່ຂອງຮ່າງການລົງຄະແນນສຽງແລະວັນທີຮັບເອົາ. ວັນທີຮັບເອົາຈະບໍ່ຖືກ ກຳ ນົດໄວກ່ວາ 60 ວັນຫຼັງຈາກສະມາຊິກໄດ້ຮັບແຈ້ງກ່ຽວກັບຂໍ້ ກຳ ນົດ 0.9/CR ທີ່ BoD ອະນຸມັດ, ເວັ້ນເສຍແຕ່ວ່າສະມາຊິກ Review BoD ຫຍໍ້ເວລາໃຫ້ສັ້ນລົງໂດຍສອດຄ່ອງກັບກົດ,າຍ, ແລະຢ່າງ ໜ້ອຍ 14 ມື້ຫຼັງຈາກການແຈ້ງໃຫ້ຊາບກ່ຽວກັບວັນທີຮັບເອົາເປັນສະມາຊິກໃຫ້ສອດຄ່ອງກັບກົດາຍ. ສໍາລັບກໍລະນີທີ່ CRs ຫຼາຍອັນໄດ້ຖືກລວມເຂົ້າເປັນຮ່າງການລົງຄະແນນສຽງ, ການເລີ່ມຕົ້ນຂອງສະມາຊິກ Review ແມ່ນວັນທີທີ່ສະມາຊິກໄດ້ຮັບແຈ້ງກ່ຽວກັບ CR ທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BoD ຫຼ້າສຸດ.

ຫລັງຈາກໄດ້ແຈ້ງການວັນທີຮັບຮອງເອົາໃຫ້ສະມາຊິກແລ້ວ, ການແກ້ໄຂທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BoD ກັບຂໍ້ຜິດພາດໃນການລົງຄະແນນສຽງແມ່ນໄດ້ຮັບອະນຸຍາດ. ກຳ ນົດເວລາການຮັບຮອງເອົາສະເພາະແມ່ນສະແດງຢູ່ໃນຮູບ 6.2.

6.2 ຕົວເລກທີ່ໄດ້ຮັບມອບ ໝາຍ

Bluetooth SIG ຮັກສາຊຸດຕົວເລກທີ່ມອບໃຫ້ສາທາລະນະຢູ່ໃນຕົວເລກທີ່ມອບBluetoothາຍຂອງ Bluetooth SIG webສະຖານທີ່ [7]. ຕົວເລກທີ່ໄດ້ຮັບມອບareາຍເຫຼົ່ານີ້ຖືກຈັດເປັນກຸ່ມໃນຊ່ອງຫວ່າງຕົວເລກຕ່າງ ((ຊຸດຕົວເລກທີ່ກ່ຽວຂ້ອງໂດຍບໍ່ມີການຊໍ້າກັນ). ຕົວເລກທີ່ໄດ້ຮັບມອບmayາຍອາດຈະທັບຊ້ອນກັບຕົວເລກອື່ນ assigned ທີ່ໄດ້ຮັບມອບinາຍຢູ່ໃນພື້ນທີ່ຕົວເລກທີ່ແຕກຕ່າງກັນ, ແຕ່ບໍ່ມີຕົວເລກພາຍໃນພື້ນທີ່ຕົວເລກໃດ ໜຶ່ງ ຖືກອະນຸຍາດໃຫ້ ນຳ ກັບມາໃຊ້ໃ່ໄດ້. ພື້ນທີ່ຕົວເລກຕ່າງ various ໄດ້ຖືກ ກຳ ນົດໄວ້ໃນສະເປັກທີ່ ກຳ ນົດການ ນຳ ໃຊ້ຕົວເລກທີ່ໄດ້ຮັບມອບາຍ.

ຫຼັງຈາກ BARB ອະນຸມັດບົດລາຍງານການທົດສອບ IOP, WG ຈະສົ່ງຄໍາຮ້ອງຂໍໃຫ້ BARB ສໍາລັບການມອບnumbersາຍຕົວເລກໃwithin່ພາຍໃນພື້ນທີ່ຈໍານວນທີ່ຕ້ອງການໂດຍສະເປັກຂັ້ນສຸດທ້າຍ. BARB ຈະກັບຄືນມາview ການຮ້ອງຂໍແລະເຮັດວຽກກັບ BSTS ເພື່ອກໍານົດຕົວເລກທີ່ໄດ້ຮັບມອບາຍ. ພາຍຫຼັງການອະນຸມັດຂອງ BARB, BSTS ຈະ ກຳ ນົດເວລາການເຜີຍແຜ່ຕົວເລກທີ່ໄດ້ຮັບມອບtoາຍໃຫ້ເປີດເຜີຍຕໍ່ສາທາລະນະໃນຕົວເລກ Bluetooth SIG ທີ່ໄດ້ມອບາຍ. webເວັບໄຊທ [[7] ພາຍໃນ ໜຶ່ງ ອາທິດຫຼັງຈາກມີການຮັບຮອງເອົາສະເປັກ.

ເມື່ອການພິມເຜີຍແຜ່ຕົວເລກທີ່ມອບonາຍຢູ່ໃນຕົວເລກທີ່ມອບSາຍຂອງ Bluetooth SIG webເວັບໄຊທ or ຫຼືຢູ່ພາຍໃນຂໍ້ກໍານົດທີ່ໄດ້ຮັບຮອງເອົາ, ຕົວເລກທີ່ໄດ້ຮັບມອບareາຍແມ່ນມີຈຸດປະສົງເພື່ອບໍ່ປ່ຽນແປງ (ເພື່ອບໍ່ປ່ຽນແປງທັງຄ່າຫຼືຄວາມ)າຍ). ຖ້າພວກມັນໃຊ້ບໍ່ໄດ້ດ້ວຍເຫດຜົນບາງອັນ, ພວກມັນຈະກາຍເປັນຄ່າທີ່ສະຫງວນໄວ້ແລະບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ນໍາກັບມາໃຊ້ໃ່.

6.3 ຂໍ້ ກຳ ນົດການອອກຂັ້ນຕອນການຮັບຮອງເອົາ / ການອະນຸມັດ

ໄລຍະການອະນຸມັດ / ການຮັບຮອງເອົາແມ່ນ ສຳ ເລັດເມື່ອ BoD ໄດ້ຮັບຮອງເອົາການ ກຳ ນົດແລະກິດຈະ ກຳ ການຮັບຮອງເອົາຕໍ່ໄປນີ້ໄດ້ ສຳ ເລັດແລ້ວ:

• BSTS ໄດ້ເຮັດໃຫ້ຕົວເລກສຸດທ້າຍທີ່ຖືກມອບpubliclyາຍໃຫ້ສາທາລະນະມີຢູ່ໃນ Bluetooth SIG webເວັບໄຊ.
• BSTS ໄດ້ເຮັດໃຫ້ຂໍ້ກໍານົດທີ່ໄດ້ຮັບຮອງເອົາມີຢູ່ໃນສາທາລະນະໃນ Bluetooth SIG webເວັບໄຊ
• BSTS ໄດ້ເຮັດເອກະສານສະ ໜັບ ສະ ໜູນ ທັງ(ົດ (ຕົວຢ່າງ: CSS, GSS, MDP) ທີ່ຈໍາເປັນສໍາລັບຂໍ້ກໍານົດທີ່ກ່ຽວຂ້ອງທີ່ມີຢູ່ຕໍ່ສາທາລະນະໃນ Bluetooth SIG webເວັບໄຊ.
• BSTS ໄດ້ເຮັດໃຫ້ເອກະສານການທົດສອບທີ່ກ່ຽວຂ້ອງມີໃຫ້ກັບສະມາຊິກທຸກຄົນຢູ່ໃນ Bluetooth SIG webເວັບໄຊ.
• ສໍາລັບການປັບປຸງສະເປັກ, BSTS ໄດ້ມີການປ່ຽນແປງຂໍ້ມູນຂ່າວສານຕິດຕາມການປ່ຽນແປງສະບັບທີ່ໄດ້ຮັບຮອງເອົາໃນເມື່ອກ່ອນດ້ວຍການປ່ຽນແປງທັງmadeົດທີ່ເຮັດໂດຍລຸ້ນໃadopted່ທີ່ໄດ້ຮັບຮອງເອົາແລະເຮັດໃຫ້ມັນມີໃຫ້ກັບສະມາຊິກທຸກຄົນໃນ Bluetooth SIG webເວັບໄຊ.
• BSTS ໄດ້ເປີດໃຊ້ລະບົບຄຸນວຸດທິ.
• BSTS ໄດ້ແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນມີຂໍ້ສະ ເໜີ ທີ່ໄດ້ຮັບຮອງເອົາແລະເອກະສານສະ ໜັບ ສະ ໜູນ ທັງ ໝົດ.

Bluetooth SIG ມີແຜນທີ່ຈະ ສຳ ເລັດກິດຈະ ກຳ ຫຼັງການລ້ຽງດູລູກນີ້ພາຍໃນ ໜຶ່ງ ອາທິດຫລັງຈາກໄດ້ຮັບຮອງເອົາຂໍ້ ກຳ ນົດດັ່ງກ່າວ.

 

7. ໄລຍະການ ບຳ ລຸງຮັກສາສະເພາະ

ໄລຍະການ ບຳ ລຸງຮັກສາສະເພາະເລີ່ມຕົ້ນຫຼັງຈາກການຮັບຮອງເອົາ / ການອະນຸມັດໄລຍະ ສຳ ເລັດ. ຖ້າພົບບັນຫາ (ຕົວຢ່າງ ຄຳ ສັບທີ່ສັບສົນຫຼືຄວາມຜິດພາດທາງວິຊາການ) ກັບເອກະສານສະເພາະຫຼືເອກະສານທົດສອບທີ່ກ່ຽວຂ້ອງ, ພວກເຂົາຕ້ອງໄດ້ຮັບເອກະສານໂດຍການສ້າງຂໍ້ສະ ເໜີ ທີ່ຜິດພາດໂດຍໃຊ້ເຄື່ອງມື Bluetooth SIG Errata. ຂໍ້ສະ ເໜີ erratum ສະເພາະເຈາະຈົງຈະຖືກປຸງແຕ່ງ, ຈັດປະເພດ, ແລະອະນຸມັດຕາມ EPD [3]. erratum Test Suite ແມ່ນຖືກປຸງແຕ່ງແລະຈັດປະເພດຕາມ TSTO [5]. ຖ້າມີຂໍ້ຂັດແຍ່ງໃດໆລະຫວ່າງ SMPD ແລະ EPD ຫຼື TSTO, SMPD ມີຄວາມ ສຳ ຄັນກ່ອນ.

erratum ສະເພາະຕ້ອງຖືກ ນຳ ໃຊ້ເພື່ອແກ້ໄຂຂໍ້ຜິດພາດທາງວິຊາການຫລືບັນນາທິການໃນຂໍ້ສະເພາະທີ່ຖືກຮັບຮອງໃນ Bluetooth ສຸດທ້າຍ. ການເພີ່ມເຕີມ, ການປ່ຽນແປງ, ແລະການ ກຳ ຈັດການ ທຳ ງານສາມາດເຮັດໄດ້ໂດຍວິທີການຂອງຂະບວນການຍົກລະດັບສະເພາະຂອງທີ່ ກຳ ນົດໄວ້ໃນເອກະສານສະບັບນີ້.

7.1 ຂັ້ນຕອນການເຮັດວຽກແບບເລັ່ງດ່ວນ

ເມື່ອຄວາມຜິດພາດໄດ້ຖືກອະນຸມັດຕາມຂະບວນການທີ່ໄດ້ກໍານົດໄວ້ໃນ EPD [3], WG, BARB, ຫຼື BSTS ອາດຈະແນະນໍາໃຫ້ມັນພິຈາລະນາເປັນເລື່ອງຮີບດ່ວນແລະຄວນຈະເລັ່ງລັດ. ເມື່ອສິ່ງນີ້ເກີດຂຶ້ນ, BSTS ພ້ອມກັບ WG ຫຼື BARB ຈະນໍາສະ ເໜີ ຄໍາແນະນໍາຕໍ່ BoD. BoD ຈະຕັດສິນໃຈວ່າຈະຍອມຮັບຫຼືປະຕິເສດຄໍາແນະນໍາ. ຖ້າຄໍາແນະນໍາໄດ້ຮັບການຍອມຮັບ, BSTS ຈະລວມເອົາຂໍ້ຜິດພາດທີ່ໄດ້ຮັບການອະນຸມັດເຂົ້າໄປໃນແມ່ແບບຂໍ້ຜິດພາດ [8] ທັນທີແລະເຮັດວຽກຮ່ວມກັບ WG ທີ່ຮັບຜິດຊອບເພື່ອສະຫຼຸບການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງດ່ວນເພື່ອສົ່ງໃຫ້ WG ສໍາລັບການທົບທວນຄືນໃ່.view ແລະການອະນຸມັດ.

ຫຼາຍກວ່າview ຂອງຂະບວນການຜິດພາດທີ່ເລັ່ງລັດແມ່ນສະແດງໃຫ້ເຫັນຢູ່ໃນຮູບ 7.1.

ເອກະສານຕໍ່ໄປນີ້ຕ້ອງເຮັດໃຫ້ ສຳ ເລັດແລະໃຫ້ເອກະສານ BoD ກ່ອນວັນທີຮັບຮອງເອົາ:

• ຮ່າງຮ່າງທີ່ໄດ້ຮັບການຮັບຮອງຈາກ BARB Expedited Errata Correction.
• ຄຳ ອະທິບາຍຈາກ WG ຂອງຂໍ້ ກຳ ນົດດ້ານຄວາມເຂົ້າກັນໄດ້ດ້ານຫຼັງ (ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 3.3.2) ທີ່ຍັງບໍ່ທັນໄດ້ບັນລຸແລະມີເຫດຜົນ ສຳ ລັບການຍົກເວັ້ນໃດໆ.
• ລາຍການບັນຫາກົດunາຍທີ່ຍັງບໍ່ທັນໄດ້ແກ້ໄຂຈາກກົດreາຍview (ຖ້າມີ).
• ຊຸດທົດສອບທີ່ອະນຸມັດໂດຍ BTI, ICS, ແລະ IXIT (ຖ້າຕ້ອງການໂດຍການເຮັດຜິດພາດ).
• TCT BTI- ແລະ BQRB-អនុម័ត (ຖ້າຕ້ອງການໂດຍ erratum).
• ບົດລາຍງານທີ່ເຮັດ ສຳ ເລັດໂດຍ BSTS ຮ່ວມກັບ BTI ກ່ຽວກັບສະຖານະຂອງຄວາມພ້ອມຂອງເຄື່ອງມື (ຕົວຢ່າງ, PTS ແລະເຄື່ອງມືທົດສອບອື່ນໆ, Bluetooth Launch Studio) ລວມທັງຖ້າມີກໍລະນີທົດສອບໃດໆໃນ TCRL ບໍ່ໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ຈາກເຄື່ອງມືທົດສອບແລະ ຄຳ ອະທິບາຍ (ຖ້າຕ້ອງການໂດຍ erratum ).
• ລາຍການກວດສອບການຮັບຮອງເອົາ ສຳ ເລັດໂດຍ BSTS ແລະ WG ສະແດງໃຫ້ເຫັນວ່າການປົດປ່ອຍໃນພາກນີ້ໄດ້ ສຳ ເລັດແລ້ວ.
• ຂໍ້ມູນອື່ນໆທັງ ໝົດ ທີ່ BoD ຮ້ອງຂໍ.

BSTS ຈະເຮັດວຽກຮ່ວມກັບ WG ທີ່ຮັບຜິດຊອບເພື່ອສະຫຼຸບຮ່າງການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງລັດແລະສ້າງສະບັບເພື່ອສົ່ງໃຫ້ WG ທີ່ຮັບຜິດຊອບເພື່ອແກ້ໄຂຄືນໃ່.view ແລະການອະນຸມັດ.

WG ຕ້ອງສົ່ງການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງລັດໄປຫາ BSTS ເພື່ອໃຫ້ຖືກຕ້ອງຕາມກົດາຍview. ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view, WG ແລະ BSTS ຈະຕົກລົງກັນກ່ຽວກັບຄໍາຄິດເຫັນທີ່ຈະລວມເຂົ້າໃນການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງລັດ. ຖ້າມີ ຄຳ ເຫັນທາງກົດunາຍທີ່ຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂຈາກທາງກົດreາຍview ກ່ຽວກັບການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງດ່ວນ, ປະທານ WG ອາດຈະຮ້ອງຂໍເວລາຢູ່ໃນວາລະ BoD ເພື່ອຊອກຫາຂໍ້ມູນຈາກ BoD ກ່ຽວກັບການແກ້ໄຂ.

ຄຽງຄູ່ກັບກົດreາຍview, WG ຕ້ອງສົ່ງການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງລັດໄປຫາ BARB ເພື່ອຮ້ອງຂໍຄືນໃ່view. ເມື່ອການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງລັດຖືກສົ່ງໄປຫາ BARB, BSTS ຈະເຮັດໃຫ້ສະມາຊິກທັງtoົດສາມາດເຂົ້າຫາມັນໄດ້ອີກ.view ແລະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຂອງການມີຂອງມັນ. ພາຍຫຼັງການສໍາເລັດຂອງ BARB review, WG ແລະ BARB ຈະຕົກລົງກັນກ່ຽວກັບຄໍາຄິດເຫັນທີ່ຈະລວມເຂົ້າໃນການແກ້ໄຂຄວາມຜິດພາດແບບເລັ່ງລັດ.

ຖ້າຖືກຕ້ອງຕາມກົດາຍview ຜົນໄດ້ຮັບໃນການປ່ຽນແປງທີ່ ສຳ ຄັນໃດ ໜຶ່ງ, ເພີ່ມເຕີມຄືນໃ່view ໂດຍ BARB ອາດຈະຕ້ອງການ. ເຊັ່ນດຽວກັນ, ຖ້າຫາກວ່າ BARB review ສົ່ງຜົນໃຫ້ມີການປ່ຽນແປງອັນໃຫຍ່ຫຼວງໃດ ໜຶ່ງ, BSTS ຈະກໍານົດວ່າຈະມີການປັບປຸງກົດadditionalາຍໃadditional່ຫຼືບໍ່view ຂອງການປ່ຽນແປງເຫຼົ່ານັ້ນແມ່ນຕ້ອງການ. ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view ແລະ BARB review, BARB ຕ້ອງອະນຸມັດຫຼືປະຕິເສດການແກ້ໄຂ Errata ແບບເລັ່ງລັດ.

ຖ້າເອກະສານການສອບເສັງຕ້ອງການການປັບປຸງ, BSTS ຈະຊ່ວຍ WG ໃນການປັບປຸງເອກະສານການສອບເສັງ. ພາຍຫຼັງການອະນຸມັດຂອງ BTI ຂອງເອກະສານການທົດສອບ, BTI ຈະຊ່ວຍໃນການເຮັດສຸດທ້າຍ TCRL ແລະສົ່ງເອກະສານດັ່ງກ່າວໃຫ້ BQRB ພ້ອມກັບ ICS, IXIT, ແລະ Suite ທີ່ກ່ຽວຂ້ອງກັບທີ່ ເໝາະ ສົມ. BSTS ຈະປະເມີນວັນຮັບຮອງເອົາແລະສະ ໜອງ ໃຫ້ BTI ເພື່ອໃຊ້ໃນ TCRL. ການອະນຸມັດຂອງ BARB ກ່ຽວກັບການແກ້ໄຂແບບເລັ່ງດ່ວນ Errata, ການອະນຸມັດ BTI ຂອງເອກະສານການທົດສອບທັງ ໝົດ (ລວມທັງ Test Suite, TCRL, ICS, ແລະ IXIT ຕາມທີ່ ເໝາະ ສົມ), ແລະການອະນຸມັດ BQRB ຂອງ TCRL ຕ້ອງເກີດຂື້ນໃນຫຼືກ່ອນວັນທີຮັບຮອງເອົາ.

BSTS ຈະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຊາບກ່ຽວກັບການສະຫລຸບສຸດທ້າຍແລະການມີສິດຂອງການແກ້ໄຂແບບເລັ່ງລັດ Errata ແລະວັນທີຮັບຮອງເອົາ. ວັນທີຮັບຮອງເອົາຈະຖືກ ກຳ ນົດແລະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຊາບຕາມກົດ ໝາຍ [2] ແລະວັນທີຮັບຮອງເອົາຈະຕ້ອງເປັນເວລາຢ່າງ ໜ້ອຍ 14 ວັນຫຼັງຈາກແຈ້ງການໃຫ້ສະມາຊິກ. ຫຼັງຈາກແຈ້ງການກ່ຽວກັບວັນທີຮັບຮອງເອົາທີ່ສະ ເໜີ ໃຫ້ສະມາຊິກ, BoD ອາດຈະອະນຸມັດການແກ້ໄຂຂໍ້ຜິດພາດໃນການແກ້ໄຂໂດຍເລັ່ງດ່ວນໂດຍບໍ່ໄດ້ແຈ້ງໃຫ້ຊາບຕື່ມກ່ຽວກັບວັນທີຮັບຮອງເອົາການສະ ເໜີ ແລະລໍຖ້າ 14 ວັນທີ່ຕ້ອງການ.

Bluetooth SIG ຈະເຮັດໃຫ້ການຮັບຮອງເອົາແບບເລັ່ງດ່ວນ Errata Correction ສາທາລະນະແລະວາງແຜນທີ່ຈະເຮັດແນວນັ້ນພາຍໃນ ໜຶ່ງ ອາທິດຫຼັງຈາກການຮັບຮອງເອົາ. ແຈ້ງການກ່ຽວກັບຄວາມພ້ອມຂອງມັນຈະຖືກອອກໂດຍ BSTS ໃຫ້ສະມາຊິກທຸກຄົນ.

ຂັ້ນຕອນ erratum ແບບເລັ່ງລັດແມ່ນ ສຳ ເລັດສົມບູນເມື່ອ BoD ໄດ້ຮັບຮອງເອົາການແກ້ໄຂຢ່າງໄວວາແລະການປະຕິບັດກິດຈະ ກຳ ຫຼັງການຮັບຮອງເອົາຕໍ່ໄປນີ້ໄດ້ ສຳ ເລັດແລ້ວ:

• BSTS ໄດ້ຮັບຮອງເອົາການແກ້ໄຂຄວາມຜິດພາດທີ່ເລັ່ງລັດແລະເອກະສານການທົດສອບທີ່ກ່ຽວຂ້ອງ (ຖ້າຕ້ອງການໂດຍຄວາມຜິດພາດ) ທີ່ມີຢູ່ຢ່າງເປີດເຜີຍຢູ່ໃນ Bluetooth SIG webເວັບໄຊ.
• BSTS ໄດ້ເປີດໃຊ້ລະບົບຄຸນວຸດທິ (ຖ້າຕ້ອງການໂດຍຜິດພາດ).
• BSTS ໄດ້ແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນມີຄວາມພ້ອມຂອງການແກ້ໄຂຢ່າງໄວວາ Errata Correction.

ໃນເວລາ ສຳ ເລັດກິດຈະ ກຳ ເຫຼົ່ານີ້, ການແກ້ໄຂ Errata ຈະຖືກ ກຳ ນົດໃຫ້ມີການເຊື່ອມໂຍງເຂົ້າກັບສະເພາະຂອງຜົນກະທົບບໍ່ວ່າຈະເປັນສ່ວນ ໜຶ່ງ ຂອງການຍົກລະດັບສະເພາະຂອງການວາງແຜນຫຼືໃນການປ່ອຍ ບຳ ລຸງຮັກສາທີ່ ກຳ ລັງຈະມາເຖິງຕາມທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ 7.2.

7.2 ຂະບວນການປົດປ່ອຍ (.Z ສະເພາະ)

ໂດຍອີງໃສ່ພື້ນຖານປະ ຈຳ ປີ, BSTS ຈະ ກຳ ນົດວ່າມີການແກ້ໄຂຜິດກົດ ໝາຍ ທີ່ຖືກຮັບຮອງ (ອ້າງເຖິງການແກ້ໄຂ Errata) ທີ່ຖືກຈັດປະເພດວ່າເປັນທາງວິຊາການ / ສູງຫຼືດ້ານວິຊາການ / ທີ່ ສຳ ຄັນແລະຍັງບໍ່ທັນໄດ້ລວມເຂົ້າກັບເນື້ອໃນຂອງຂໍ້ ກຳ ນົດທີ່ມີການເຄື່ອນໄຫວໃດໆ (ເຊັ່ນ, ຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາທີ່ບໍ່ໄດ້ຖືກຄັດເລືອກຫຼືຖອນອອກ). ເບິ່ງເອກະສານຊ້ອນທ້າຍ A ສຳ ລັບນິຍາມການຈັດປະເພດ errata. ເຈົ້າຂອງຂໍ້ມູນສະເພາະ (ບໍ່ວ່າຈະເປັນ WG ທີ່ໃຊ້ໃນການຮັກສາຂໍ້ມູນສະເພາະ, ຫຼື BARB ຖ້າບໍ່ມີ WG ເປັນຕົວແທນທີ່ຈະຮັກສາຂໍ້ມູນສະເພາະ) ກໍ່ຍັງສາມາດຮຽກຮ້ອງໃຫ້ມີການປ່ອຍຂໍ້ມູນການ ບຳ ລຸງຮັກສາກ່ອນ ໜ້າ ນີ້ກ່ຽວກັບຂໍ້ມູນທີ່ມີການເຄື່ອນໄຫວເພື່ອປະກອບມີຂໍ້ຜິດພາດທີ່ຖືກອະນຸມັດ. ພາຍຫຼັງການ ກຳ ນົດ BSTS, ຫຼື ຄຳ ຮ້ອງຂໍຂອງເຈົ້າຂອງສະເພາະ, ຂັ້ນຕອນການປ່ອຍ ບຳ ລຸງຮັກສາຈະເລີ່ມຕົ້ນ.

ຫຼາຍກວ່າview ຂອງຂະບວນການປ່ອຍການບໍາລຸງຮັກສາໄດ້ສະແດງໃຫ້ເຫັນໃນຄວາມຜິດພາດ! ບໍ່ພົບແຫຼ່ງອ້າງອີງ.

ໃນຕອນເລີ່ມຕົ້ນຂອງຂັ້ນຕອນການປ່ອຍຮັກສາ, BSTS ຮ່ວມກັບເຈົ້າຂອງສະເພາະ, BARB, ແລະ BTI ຈະພັດທະນາແລະ ນຳ ສະ ເໜີ ແຜນການໃຫ້ BoD ສຳ ລັບການລວມເອົາການແກ້ໄຂ Errata ເຂົ້າໃນສະບັບພາສາສະເພາະທີ່ຖືກເຜີຍແຜ່. ແຜນການທີ່ໄດ້ສະ ເໜີ ຕ້ອງຊີ້ບອກວ່າການແກ້ໄຂ Errata ຈະຖືກລວມເຂົ້າໃນການຮັກສາການປ່ອຍຂໍ້ມູນສະເພາະ (ຕົວຢ່າງ, .Z ຮຸ່ນ) ຫຼືການເພີ່ມປະສິດຕິພາບຂອງການ ກຳ ນົດທີ່ມີຢູ່ໃນຄວາມຄືບ ໜ້າ ແລ້ວຫລືບໍ່ (ຕົວຢ່າງລຸ້ນ XY). ແຜນການທີ່ສະ ເໜີ ຄວນ ຄຳ ນຶງເຖິງວ່າຄຸນລັກສະນະບັງຄັບ ໃໝ່ ໄດ້ເພີ່ມເຂົ້າລະຫວ່າງສະບັບຂອງຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາ, ເວລາທີ່ຄາດຄະເນໄວ້ໃນເວລາທີ່ການເພີ່ມປະສິດທິພາບການ ກຳ ນົດສະບັບຕໍ່ໄປແມ່ນໄດ້ວາງແຜນໄວ້ ສຳ ລັບການຮັບຮອງເອົາ, ແລະປັດໃຈອື່ນໆ.

ພາຍຫຼັງທີ່ໄດ້ຮັບການອະນຸມັດແຜນການຈາກ BoD, BSTS ຮ່ວມກັບເຈົ້າຂອງ Specification ຈະ ດຳ ເນີນການລວມເອົາການແກ້ໄຂດ້ານເຕັກນິກ / ຂະ ໜາດ ກາງ, ສູງສຸດ, ແລະເຕັກນິກ / ທີ່ ສຳ ຄັນເຂົ້າໃນຮ່າງເອກະສານສະເພາະໂດຍອ້າງອີງໃສ່“ ຮ່າງການຮັກສາການປ່ອຍຕົວ”. ສຳ ລັບການແກ້ໄຂບັນນາທິການຫລືດ້ານວິຊາການ / ຕ່ ຳ ສຸດ Errata, ຖ້າວ່າການແກ້ໄຂ Errata ນຳ ໃຊ້ກັບຫຼາຍກວ່າ ໜຶ່ງ ຮຸ່ນຂອງຂໍ້ ກຳ ນົດ, BSTS ຈະ, ເວັ້ນເສຍແຕ່ວ່າ BoD ຊີ້ບອກຢ່າງອື່ນ, ລວມເອົາ errata ເຫຼົ່ານັ້ນເຂົ້າໃນພຽງແຕ່ສະບັບທີ່ມີການ ກຳ ນົດທີ່ສູງກວ່າເກົ່າໃນການປັບປຸງຕໍ່ໄປຂອງລຸ້ນນັ້ນ . ບໍ່ມີການປ່ຽນແປງໃດໆທີ່ຈະຖືກລວມເຂົ້າໃນຮ່າງປັບປຸງການ ບຳ ລຸງຮັກສານອກ ເໜືອ ຈາກການລວມເອົາການແກ້ໄຂ Errata. ຮ່າງເອກະສານກ່ຽວກັບການ ບຳ ລຸງຮັກສາແຕ່ລະຄັ້ງຕ້ອງ ກຳ ນົດການແກ້ໄຂ Errata ທີ່ລວມເຂົ້າກັນທັງ ໝົດ ໂດຍໃຊ້ການຕິດຕາມການປ່ຽນແປງເພື່ອສະແດງການປ່ຽນແປງທີ່ຖືກ ນຳ ສະ ເໜີ ຕໍ່ສະບັບທີ່ໄດ້ຖືກຄັດເລືອກມາກ່ອນ ໜ້າ ນີ້ຂອງຂໍ້ ກຳ ນົດທີ່ໄດ້ຖືກເຜີຍແຜ່.

ໄລຍະເວລາຂອງການລວມເອົາການສະ ເໜີ ສຳ ລັບແຕ່ລະ Errata ແກ້ໄຂໃນຮ່າງການ ບຳ ລຸງຮັກສາຈະຂື້ນກັບຜົນກະທົບຂອງ Test Suite: ການແກ້ໄຂ Errata ທີ່ບໍ່ມີຜົນກະທົບ Test Suite ອາດຈະຖືກລວມເຂົ້າໃນທັນທີ, ແຕ່ວ່າການແກ້ໄຂ Errata ທີ່ມີຜົນກະທົບຕໍ່ Test Suite ຈະເປັນ ປະມວນຜົນເພື່ອໃຫ້ໄລຍະເວລາກົງກັບການປັບປຸງ TCRL.

BTI ແລະ BSTS ຈະ ກຳ ນົດເວລາ ກຳ ນົດ ສຳ ລັບການລວມເອົາການແກ້ໄຂ Errata ກັບຜົນກະທົບຂອງ Suite Test ໃນຮ່າງຮ່າງການ ບຳ ລຸງຮັກສາ. ເສັ້ນຕາຍຄັ້ງນີ້ແມ່ນປົກກະຕິ 3 ຫາ 6 ເດືອນກ່ອນວັນທີອະນຸມັດທີ່ວາງແຜນໄວ້ຂອງການປ່ອຍ TCRL ທີ່ ສຳ ຄັນຕໍ່ໄປ. ການແກ້ໄຂ Errata ກັບຜົນກະທົບຂອງ Suite ທີ່ພາດເວລາ ກຳ ນົດ ສຳ ລັບການລວມເຂົ້າຈະຖືກ ດຳ ເນີນເປັນສ່ວນ ໜຶ່ງ ຂອງການປ່ອຍ TCRL ປະ ຈຳ ປີຕໍ່ໄປ. ເພາະສະນັ້ນ, ເວັ້ນເສຍແຕ່ວ່າມີການຮ້ອງຂໍການປ່ອຍກ່ອນ ໜ້າ ນີ້, ເວລາສູງສຸດ ສຳ ລັບການກວດແກ້ທາງວິຊາການ / ສູງຫລືດ້ານວິຊາການ / ທີ່ ສຳ ຄັນທີ່ຈະຖືກລວມເຂົ້າໃນການປັບປຸງສະເພາະແມ່ນປະມານ 15 ຫາ 18 ເດືອນ.

ເຈົ້າຂອງສະເພາະຕ້ອງຍື່ນສະບັບຮ່າງການບໍາລຸງຮັກສາທີ່ມັນໄດ້ອະນຸມັດເປັນຂັ້ນສຸດທ້າຍສໍາລັບການປັບປຸງທາງດ້ານກົດາຍview. ກົດreາຍຄືນໃ່view ຈະສຸມໃສ່ຕົ້ນຕໍຢູ່ໃນພາກສ່ວນທີ່ປ່ຽນແປງຂອງສະເປັກ. ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view, ເຈົ້າຂອງສະເພາະແລະ BSTS ຈະຕົກລົງເຫັນດີກັບຄໍາຄິດເຫັນທີ່ຈະລວມເຂົ້າໃສ່ໃນຮ່າງການເຜີຍແຜ່ການບໍາລຸງຮັກສາ. ຖ້າມີ ຄຳ ເຫັນທາງກົດunາຍທີ່ຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂຈາກທາງກົດreາຍview ຢູ່ໃນຮ່າງການເຜີຍແຜ່ການບໍາລຸງຮັກສາ, ເຈົ້າຂອງສະເພາະອາດຈະຮ້ອງຂໍເວລາຢູ່ໃນວາລະ BoD ເພື່ອຊອກຫາຂໍ້ມູນເຂົ້າໃສ່ BoD ກ່ຽວກັບການແກ້ໄຂ.

ຄຽງຄູ່ກັບກົດreາຍview, ເຈົ້າຂອງສະເພາະຕ້ອງສົ່ງຮ່າງການເຜີຍແຜ່ການບໍາລຸງຮັກສາໄປໃຫ້ BARB ເພື່ອກວດຄືນview. ເມື່ອສະບັບຮ່າງການບໍາລຸງຮັກສາຖືກສົ່ງໄປຫາ BARB, BSTS ຈະເຮັດໃຫ້ສະມາຊິກທຸກຄົນສາມາດເຂົ້າໄປໃre່ໄດ້view ແລະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຂອງການມີຂອງມັນ. ພາຍຫຼັງການສໍາເລັດຂອງ BARB review, ເຈົ້າຂອງສະເພາະແລະ BARB ຈະຕົກລົງກັນກ່ຽວກັບຄໍາຄິດເຫັນທີ່ຈະຖືກລວມເຂົ້າໃນຮ່າງຂໍ້ກໍານົດສະເພາະ.

ຖ້າຖືກຕ້ອງຕາມກົດາຍview ຜົນໄດ້ຮັບໃນການປ່ຽນແປງທີ່ ສຳ ຄັນໃດ ໜຶ່ງ, ເພີ່ມເຕີມຄືນໃ່view ໂດຍ BARB ອາດຈະຕ້ອງການ. ເຊັ່ນດຽວກັນ, ຖ້າຫາກວ່າ BARB review ສົ່ງຜົນໃຫ້ມີການປ່ຽນແປງອັນໃຫຍ່ຫຼວງໃດ ໜຶ່ງ, BSTS ຈະກໍານົດວ່າຈະມີການປັບປຸງກົດadditionalາຍໃadditional່ຫຼືບໍ່view ຂອງການປ່ຽນແປງເຫຼົ່ານັ້ນແມ່ນຕ້ອງການ. ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view ແລະ BARB review, BARB ຕ້ອງອະນຸມັດຫຼືປະຕິເສດສະບັບຮ່າງການບໍາລຸງຮັກສາ. ຖ້າໄດ້ຮັບການອະນຸມັດຈາກ BARB, ອັນນີ້ຈະກາຍເປັນຮ່າງຮ່າງການລົງຄະແນນສຽງ.

ສຳ ລັບການແກ້ໄຂຂອງ Errata ທີ່ສົ່ງຜົນກະທົບຕໍ່ເອກະສານການທົດສອບ, ແລະບ່ອນທີ່ errata ການທົດສອບທີ່ສອດຄ້ອງກັນຈະຖືກ ດຳ ເນີນການໃນເວລາ ສຳ ລັບການປ່ອຍ TCRL ທີ່ ກຳ ລັງຈະມາເຖິງ, BSTS ຈະເຮັດວຽກກັບເຈົ້າຂອງສະເພາະແລະ BTI ເພື່ອປັບປຸງເອກະສານການທົດສອບ. ເມື່ອການອະນຸມັດ BTI ຂອງເອກະສານການທົດສອບ, BSTS ຈະປະເມີນວັນທີຮັບຮອງເອົາແລະໃຫ້ວັນທີຮັບຮອງເອົາກັບ BTI ເພື່ອ ນຳ ໃຊ້ໃນ TCRL. BTI ຈະຈັດສົ່ງ TCRL ໃຫ້ BQRB ພ້ອມກັບ ICS, IXIT ແລະ Test Suite ທີ່ກ່ຽວຂ້ອງ. ການອະນຸມັດຂອງ BARB ກ່ຽວກັບຂໍ້ ກຳ ນົດ, ການອະນຸມັດ BTI ຂອງເອກະສານການທົດສອບທັງ ໝົດ (ລວມທັງ Test Suite, TCRL, ICS, ແລະ IXIT ຕາມທີ່ ເໝາະ ສົມ), ແລະການອະນຸມັດຂອງ BQRB ກ່ຽວກັບ TCRL ຕ້ອງເກີດຂື້ນໃນຫຼືກ່ອນວັນທີຮັບຮອງເອົາ.

BSTS ຈະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຊາບກ່ຽວກັບການສະຫຼຸບແລະຄວາມພ້ອມຂອງຮ່າງເອກະສານການລົງຄະແນນສຽງແລະວັນທີຮັບຮອງເອົາ. ວັນທີຮັບຮອງເອົາຈະຖືກ ກຳ ນົດແລະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນປະຕິບັດຕາມກົດ ໝາຍ ແລະວັນທີຮັບຮອງເອົາຈະເປັນເວລາຢ່າງ ໜ້ອຍ 14 ວັນຫຼັງຈາກໄດ້ແຈ້ງການແຈ້ງການໃຫ້ສະມາຊິກ. ຫຼັງຈາກແຈ້ງການກ່ຽວກັບວັນຮັບເອົາການສະ ເໜີ ໃຫ້ສະມາຊິກແລ້ວ, BoD ອາດຈະອະນຸມັດການແກ້ໄຂຂໍ້ຜິດພາດຕ່າງໆໃນຮ່າງການລົງຄະແນນສຽງໂດຍບໍ່ໄດ້ແຈ້ງໃຫ້ຊາບຕື່ມກ່ຽວກັບວັນທີຮັບຮອງເອົາການສະ ເໜີ ແລະລໍຖ້າ 14 ວັນທີ່ຕ້ອງການ.

ເອກະສານຕໍ່ໄປນີ້ຕ້ອງເຮັດໃຫ້ ສຳ ເລັດແລະໃຫ້ເອກະສານ BoD ກ່ອນວັນທີຮັບຮອງເອົາ:

• ຮ່າງການລົງຄະແນນສຽງ
• ສະບັບຮ່າງທີ່ມີການປ່ຽນແປງຂອງຮ່າງການລົງຄະແນນສຽງສະແດງໃຫ້ເຫັນການປ່ຽນແປງທັງ ໝົດ ຕໍ່ກັບສະບັບທີ່ໄດ້ຮັບຮອງເອົາຂອງຂໍ້ ກຳ ນົດທີ່ມີຄ່າ XY ດຽວກັນ (ຕົວຢ່າງ: ຖ້າຮ່າງການລົງຄະແນນສຽງຖືກສະ ເໜີ ເປັນຮຸ່ນ 1.4.2, ການປ່ຽນແປງຈະຖືກຕິດຕາມກັບ 1.4.1 ສະບັບຂອງສະເພາະ)
• ຄຳ ແນະ ນຳ ຈາກເຈົ້າຂອງສະເພາະ ສຳ ລັບການເສື່ອມລາຄາຫລືການຖອນເງິນຂອງລຸ້ນກ່ອນໆຂອງຂໍ້ ກຳ ນົດທີ່ໄດ້ຮັບຮອງເອົາພ້ອມກັບການພິສູດ
• ລາຍການບັນຫາກົດunາຍທີ່ຍັງບໍ່ທັນໄດ້ແກ້ໄຂຈາກກົດreາຍview (ຖ້າມີ)
• ຊຸດທົດສອບທີ່ອະນຸມັດໂດຍ BTI, ICS, ແລະ IXIT (ຖ້າຕ້ອງການໂດຍການປ່ອຍຮັກສາ)
• TCT BTI- ແລະ BQRB ທີ່ໄດ້ຮັບການອະນຸມັດ (ຖ້າຕ້ອງການໂດຍການປ່ອຍຮັກສາ)
• ບົດລາຍງານທີ່ເຮັດ ສຳ ເລັດໂດຍ BSTS ຮ່ວມກັບ BTI ກ່ຽວກັບສະຖານະຂອງຄວາມພ້ອມຂອງເຄື່ອງມື (ຕົວຢ່າງ, PTS ແລະເຄື່ອງມືທົດສອບອື່ນໆ, Bluetooth Launch Studio) ລວມທັງກໍລະນີທົດສອບຕ່າງໆໃນ TCRL ທີ່ບໍ່ໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ຈາກເຄື່ອງມືທົດສອບ, ແລະ ຄຳ ອະທິບາຍ (ຖ້າຕ້ອງການຈາກການ ບຳ ລຸງຮັກສາ ປ່ອຍຕົວ)
• ລາຍການກວດສອບການຮັບຮອງເອົາ ສຳ ເລັດໂດຍ BSTS ແລະເຈົ້າຂອງຂໍ້ມູນສະເພາະສະແດງໃຫ້ເຫັນວ່າການປົດປ່ອຍໃນພາກນີ້ໄດ້ ສຳ ເລັດແລ້ວ
• ຂໍ້ມູນອື່ນໆທັງ ໝົດ ທີ່ BoD ຮ້ອງຂໍ

ຂັ້ນຕອນການປົດປ່ອຍ ສຳ ເລັດສົມບູນເມື່ອ BoD ໄດ້ຮັບຮອງເອົາຮ່າງຮ່າງການລົງຄະແນນສຽງແລະກິດຈະ ກຳ ການຮັບຮອງເອົາຕໍ່ໄປນີ້ໄດ້ ສຳ ເລັດແລ້ວ:

• BSTS ໄດ້ເຮັດໃຫ້ຂໍ້ກໍານົດທີ່ໄດ້ຮັບຮອງເອົາແລະເອກະສານການທົດສອບທີ່ກ່ຽວຂ້ອງ (ຖ້າຕ້ອງການໂດຍການອອກແບບການບໍາລຸງຮັກສາ) ມີຢູ່ທົ່ວໄປໃນ Bluetooth SIG webເວັບໄຊ.
• BSTS ໄດ້ມີການປ່ຽນແປງຂໍ້ມູນຂ່າວສານຕິດຕາມການປ່ຽນແປງສະບັບທີ່ໄດ້ຮັບຮອງເອົາໃນເມື່ອກ່ອນດ້ວຍການປ່ຽນແປງທັງincorົດທີ່ລວມຢູ່ໃນສະບັບທີ່ໄດ້ຮັບຮອງເອົາໃavailable່ທີ່ມີໃຫ້ກັບສະມາຊິກທັງonົດຢູ່ໃນ Bluetooth SIG webເວັບໄຊ.
• BSTS ໄດ້ເປີດໃຊ້ລະບົບຄຸນວຸດທິ.
• BSTS ໄດ້ແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນມີຄວາມພ້ອມຂອງເອກະສານສະເພາະແລະເອກະສານສະ ໜັບ ສະ ໜູນ.

Bluetooth SIG ມີແຜນທີ່ຈະ ສຳ ເລັດກິດຈະ ກຳ ຫຼັງການລ້ຽງດູລູກນີ້ພາຍໃນ ໜຶ່ງ ອາທິດຫລັງຈາກໄດ້ຮັບຮອງເອົາຂໍ້ ກຳ ນົດດັ່ງກ່າວ.

ເມື່ອເຮັດ ສຳ ເລັດກິດຈະ ກຳ ເຫຼົ່ານີ້ແລ້ວ, ຂໍ້ ກຳ ນົດສະເພາະແມ່ນຢູ່ໃນໄລຍະການ ບຳ ລຸງຮັກສາສະເພາະຈົນກ່ວາຂໍ້ ກຳ ນົດດັ່ງກ່າວຖືກປະຕິເສດຫຼືຖອດຖອນ, ດັ່ງທີ່ໄດ້ ກຳ ນົດໄວ້ໃນພາກ 8.

 

8. ໄລຍະສຸດທ້າຍຂອງຊີວິດໂດຍສະເພາະ

ຂໍ້ສະເພາະຕ່າງໆອາດຈະຖືກຄັດເລືອກຫຼືຖອນອອກເມື່ອພວກມັນຖືກປ່ຽນແທນໂດຍລຸ້ນ ໃໝ່, ຖືກ ກຳ ນົດວ່າບໍ່ພຽງພໍທາງດ້ານເຕັກນິກ, ຫຼືຍ້ອນເຫດຜົນອື່ນໆ. ຂໍ້ສະເພາະທີ່ຖືກຄັດເລືອກແລະຖອນອອກແມ່ນຖືກຈັດເກັບແລະບໍ່ມີການປັບປຸງອີກຕໍ່ໄປ. ຂໍ້ສະເພາະທີ່ຖືກຄັດເລືອກແລະຖອນອອກແມ່ນໄດ້ຮັບການປະຕິບັດທີ່ແຕກຕ່າງໃນໂຄງການຄຸນວຸດທິ Bluetooth.

ສະມາຊິກ, ກຸ່ມ, ຫຼືຄະນະ ກຳ ມະການໃດ ໜຶ່ງ ສາມາດສົ່ງ ຄຳ ແນະ ນຳ ເພື່ອຄັດຄ້ານຫຼືຖອນການ ກຳ ນົດສະເພາະພ້ອມກັບ ກຳ ນົດເວລາທີ່ກ່ຽວຂ້ອງກັບ BSTS (ຜ່ານທາງອີເມວຫາ

specification.manager@bluetooth.com) ໄດ້ທຸກເວລາ. BSTS ອາດຈະແນະ ນຳ ການເສື່ອມລາຄາຫຼືການຖອນຕົວຂອງສະເປັກແລະ ກຳ ນົດເວລາທີ່ກ່ຽວຂ້ອງ. BSTS ຈະສົ່ງ ຄຳ ແນະ ນຳ ໄປໃຫ້ BARB ແລະກຸ່ມຫຼືຄະນະ ກຳ ມະການທີ່ຮັບຜິດຊອບໃນການຮັກສາຂໍ້ມູນສະເພາະ ສຳ ລັບ review ແລະຄໍາຄຶດຄໍາເຫັນ.

BARB ແລະກຸ່ມຫຼືຄະນະ ກຳ ມະການທີ່ຮັບຜິດຊອບຈະປະເມີນ ຄຳ ແນະ ນຳ ເພື່ອປະຕິເສດຫຼືຖອນຕົວສະເພາະແລະພິຈາລະນາຕໍ່ໄປນີ້ (ບໍ່ໃຊ້ເກີນ ກຳ ນົດ) ຕໍ່ໄປນີ້:

• ມີ ໜ້າ ທີ່ໃນສະບັບທີ່ ກຳ ນົດໄວ້ໃນສະບັບກ່ອນ ໜ້າ ນີ້ທີ່ໃຊ້ແລ້ວຫລືບໍ່ຄວນໃຊ້ບໍ?
• ມີຫນ້າທີ່ບັງຄັບໃຊ້ໃຫມ່ໄດ້ຖືກເພີ່ມເຂົ້າໃນສະບັບຕໍ່ມາບໍ?
• ມີຂໍ້ບົກຜ່ອງຢູ່ໃນຮຸ່ນກ່ອນ ໜ້າ ນີ້ທີ່ບົກຜ່ອງການ ດຳ ເນີນງານຫຼືຄວາມສາມາດໂຕ້ຕອບທີ່ໄດ້ຮັບການແກ້ໄຂໃນຮຸ່ນຕໍ່ມາແລະມີຄວາມ ຈຳ ເປັນທີ່ຈະຕ້ອງກ້າວ ໜ້າ ສະຖານະການຂອງຜູ້ໃຊ້ທີ່ມີຢູ່ບໍ?
• ມີ ໜ້າ ທີ່ເພີ່ມເຕີມໃນຮຸ່ນຕໍ່ມາທີ່ ຈຳ ເປັນເພື່ອກ້າວສູ່ສະຖານະການຂອງຜູ້ໃຊ້ ໃໝ່ ບໍ?
• ມີການປັບປຸງການ ນຳ ໃຊ້ແລະຄວາມສາມາດເຮັດວຽກຮ່ວມກັນໄດ້ໃນສະບັບຕໍ່ມາບໍ?
• ມີການປັບປຸງຄວາມປອດໄພໃນຮຸ່ນຕໍ່ມາບໍ?

ທະນາຍຄວາມແລະກຸ່ມຫຼືຄະນະ ກຳ ມະການທີ່ຮັບຜິດຊອບອາດຈະສະ ເໜີ ຄຳ ແນະ ນຳ ອື່ນ.

ຫຼັງຈາກໄດ້ຮັບຄໍາຕິຊົມຈາກ BARB ຫຼືກຸ່ມຫຼືຄະນະກໍາມະການທີ່ຮັບຜິດຊອບໃນການຮັກສາສະເປັກ, BSTS ຈະສົ່ງຄໍາແນະນໍາແລະຄໍາຕິຊົມໄປໃຫ້ BoD ເພື່ອພິຈາລະນາ. BoD ອາດຈະເຊື້ອເຊີນກຸ່ມຫຼືຄະນະກໍາມະການທີ່ຮັບຜິດຊອບຮັກສາສະເພາະທີ່ໄດ້ຮັບຜົນກະທົບໃຫ້ພົບແລະປຶກສາຫາລືຄໍາແນະນໍາ. BoD ຈະພິຈາລະນາຄໍາແນະນໍາແລະຄໍາຄິດເຫັນແລະອາດຈະເຫັນດີກັບຫຼືດັດແປງການສະ ເໜີ. BoD ຈະຮ້ອງຂໍໃຫ້ BSTS ແຈ້ງສະມາຊິກທັງofົດຂອງການສະ ເໜີ ໃຫ້ຢຸດການຖອນຫຼືຖອນລາຍລະອຽດສະເພາະແລະກໍານົດເວລາທີ່ກ່ຽວຂ້ອງສໍາລັບການກັບຄືນ 30 ວັນ.view ໄລຍະເວລາເພື່ອອະນຸຍາດໃຫ້ສະມາຊິກທຸກຄົນໃຫ້ຄໍາຕິຊົມເພີ່ມເຕີມກ່ອນການຕັດສິນໃຈຂັ້ນສຸດທ້າຍ.

BoD ຈະພິຈາລະນາ ຄຳ ຄິດເຫັນທີ່ໄດ້ຮັບຈາກສະມາຊິກ. ເມື່ອ BoD ອະນຸມັດການຫັກລົບຫຼືການຖອນເງິນສະເພາະ, BSTS ຈະແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຕັດສິນໃຈແລະ ກຳ ນົດເວລາທີ່ກ່ຽວຂ້ອງ.

8.1 ການຫັກລົບ

ເມື່ອຂໍ້ມູນສະເພາະຖືກຄັດເລືອກ, ສິ່ງຕໍ່ໄປນີ້ຈະເກີດຂື້ນ:

• ຂໍ້ມູນສະເພາະຈະບໍ່ຖືກປັບປຸງອີກຕໍ່ໄປ.
• WG ທີ່ຮັບຜິດຊອບຈະກັບຄືນມາview ຄວາມຜິດພາດທີ່ຍັງຄ້າງຄາທັງwrittenົດທີ່ຂຽນຕໍ່ກັບຂໍ້ກໍານົດທີ່ຄັດຄ້ານເພື່ອກໍານົດວ່າພວກມັນນໍາໃຊ້ກັບຂໍ້ກໍານົດສະເພາະອື່ນ other ຫຼືບໍ່. ຂໍ້ຜິດພາດອາດຈະຖືກປະຕິເສດຢູ່ໃນລະບົບຜິດພາດແລະຂຽນຄືນໃagainst່ກົງກັບຂໍ້ກໍານົດທີ່ສາມາດນໍາໃຊ້ໄດ້.
• WG ຫຼື BSTS ຈະສ້າງ errata ເພື່ອປັບປຸງເອກະສານອ້າງອີງທີ່ ຈຳ ເປັນຕໍ່ກັບຂໍ້ສະເພາະທີ່ຖືກຄັດເລືອກໃນຂໍ້ສະເພາະອື່ນໆ.
• BTI ຈະປັບປຸງເອກະສານການທົດສອບທີ່ໃຊ້ໄດ້ເພື່ອຊີ້ບອກເຖິງການເສີຍຫາຍຂອງຂໍ້ສະເພາະ.
• BSTS ຈະອັບເດດ Bluetooth SIG webເວັບໄຊທ with ທີ່ມີຄໍາແນະນໍາກ່ຽວກັບຂໍ້ກໍານົດທາງເລືອກທີ່ຈະໃຊ້.
• errata ໃໝ່ ບໍ່ສາມາດສົ່ງຕໍ່ກັບສະເພາະທີ່ຖືກຄັດເລືອກ.
• ຂໍ້ມູນສະເພາະຈະບໍ່ຖືກອ້າງອີງໃນຂໍ້ມູນສະເພາະໃນອະນາຄົດ.
• BSTS ຈະເກັບເອກະສານສະເພາະຂອງສະບັບທີ່ຖືກຄັດເລືອກໄວ້ເພື່ອໃຫ້ສະມາຊິກເຂົ້າເຖິງຈຸດປະສົງທາງປະຫວັດສາດ.

8.2 ການຖອນເງິນ

ເມື່ອການຖອນຂໍ້ມູນສະເພາະໃດ ໜຶ່ງ, ນອກ ເໜືອ ໄປຈາກຂັ້ນຕອນທີ່ສະ ເໜີ ການຄັດເລືອກ, ສິ່ງຕໍ່ໄປນີ້ຈະເກີດຂື້ນ:

• BTI ຈະປັບປຸງເອກະສານການທົດສອບທີ່ໃຊ້ໄດ້ເພື່ອສະແດງການຖອນຕົວໂດຍສະເພາະ.
• BSTS ຈະອັບເດດ Bluetooth SIG webເວັບໄຊທ with ທີ່ມີຄໍາແນະນໍາກ່ຽວກັບຂໍ້ກໍານົດທາງເລືອກທີ່ຈະໃຊ້.
• BSTS ຈະເກັບເອກະສານສະເພາະຂອງສະບັບທີ່ຖືກ ໝາຍ ໄວ້ວ່າຈະຖືກຖອນ ສຳ ລັບສະມາຊິກເພື່ອເຂົ້າເຖິງຈຸດປະສົງທາງປະຫວັດສາດ.

BoD ອາດຈະເລືອກທີ່ຈະຖອນຕົວສະເພາະໃດ ໜຶ່ງ ໂດຍທັນທີໂດຍບໍ່ຕ້ອງເສີຍຂໍ້ມູນສະເພາະ.

 

9. ຂະບວນການເຮັດເຈ້ຍຂາວ

ເອກະສານສີຂາວຖືກສ້າງຂື້ນເພື່ອຈຸດປະສົງຂໍ້ມູນເທົ່ານັ້ນ. ຂະບວນການເຮັດເຈ້ຍຂາວດັ່ງຕໍ່ໄປນີ້ໃຊ້ໄດ້ກັບ Bluetooth WGs, EGs, SGs, ແລະຄະນະ ກຳ ມະການທັງ ໝົດ. ສ່ວນນີ້ບໍ່ໄດ້ ນຳ ໃຊ້ກັບເອກະສານຂໍ້ມູນ ສຳ ລັບການ ນຳ ໃຊ້ພາຍໃນ Bluetooth SIG ເທົ່ານັ້ນ.

ຂະບວນການນີ້ແມ່ນສະແດງຢູ່ໃນຮູບທີ 9.1 ຂ້າງລຸ່ມນີ້.

ກ່ອນທີ່ກຸ່ມຫຼືຄະນະ ກຳ ມະການໃດຈະເລີ່ມເຮັດເຈ້ຍຂາວທີ່ພວກເຂົາຕັ້ງໃຈຈະຖືກເຜີຍແຜ່ໂດຍ Bluetooth SIG, ກຸ່ມຫຼືຄະນະ ກຳ ມະການຈະກະກຽມທັງການປັບປຸງກົດ ໝາຍ ທີ່ໄດ້ສະ ເໜີ ຂື້ນໂດຍ ກຳ ນົດເນື້ອໃນທີ່ຖືກສະ ເໜີ ຂອງເຈ້ຍຂາວແລະການ ນຳ ສະ ເໜີ ບົດສະ ເໜີ ເຈ້ຍຂາວ.

ການ ນຳ ສະ ເໜີ ບົດສະ ເໜີ ເຈ້ຍຂາວຕ້ອງປະກອບມີຢ່າງ ໜ້ອຍ:

• ຄວາມຕ້ອງການຂອງເຈ້ຍຂາວ
• ບົດສະຫຼຸບຂອງເນື້ອໃນທີ່ສະ ເໜີ ຂອງເຈ້ຍຂາວ
• ຄຳ ອະທິບາຍ ສຳ ລັບເຫດຜົນທີ່ເນື້ອຫາບໍ່ຖືກແນະ ນຳ ໃຫ້ຖືກລວມເຂົ້າເປັນສ່ວນ ໜຶ່ງ ຂອງການ ກຳ ນົດສະເພາະ
• ຜູ້ຊົມທີ່ມີຈຸດປະສົງ
• ແຜນການ ບຳ ລຸງຮັກສາໃດໆ (ໝາຍ ຄວາມວ່າເວລາປະມານກ່ອນການປ່ອຍເຈ້ຍຂາວຄັ້ງຕໍ່ໄປນີ້ອາດຈະມີຄວາມ ຈຳ ເປັນ)
• ຄຳ ແນະ ນຳ ສຳ ລັບວິທີການຈັດການກັບເຈ້ຍຂາວສະບັບກ່ອນ, ຖ້າມີ (ຕົວຢ່າງ: ການເກັບມ້ຽນເອກະສານ)

ການປັບປຸງກົດາຍແລະການສະ ເໜີ ບົດສະ ເໜີ ເຈ້ຍຂາວຕ້ອງຖືກສົ່ງສໍາລັບ BARBview. ຕາມມາview ແລະການອະນຸມັດການປັບປຸງກົດາຍໂດຍ BARB, BSTS ຈະສົ່ງການປັບປຸງກົດາຍສະບັບນີ້ໃຫ້ BoD ເພື່ອການອະນຸມັດພ້ອມກັບການສະ ເໜີ ບົດສະ ເໜີ ປຶ້ມປົກຂາວ.

ຖ້າ BoD ອະນຸມັດການປັບປຸງກົດ ໝາຍ, ກຸ່ມຫລືຄະນະ ກຳ ມະການອາດຈະ ດຳ ເນີນການກັບການພັດທະນາເຈ້ຍຂາວ.

ເມື່ອກຸ່ມຫຼືຄະນະກໍາມະການສໍາເລັດການພັດທະນາປຶ້ມປົກຂາວ, BSTS ຈະດໍາເນີນການບັນນາທິການຄືນໃ່view ເພື່ອຄວາມສອດຄ່ອງກັບແນວທາງການຮ່າງຮ່າງ Bluetooth.

ຫຼັງຈາກການແກ້ໄຂ ຄຳ ເຫັນຂອງ BSTS, ກຸ່ມດັ່ງກ່າວຕ້ອງໄດ້ສົ່ງ ໜັງ ສືຂາວໃຫ້ BSTS ເພື່ອຮັບຮອງທາງກົດາຍview. ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view, ກຸ່ມແລະ BSTS ຈະຕົກລົງເຫັນດີກ່ຽວກັບຄໍາຄິດເຫັນທີ່ຈະລວມເຂົ້າໃນປຶ້ມປົກຂາວ. ຖ້າມີ ຄຳ ເຫັນທາງກົດunາຍທີ່ຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂຈາກທາງກົດreາຍview ຢູ່ໃນເຈ້ຍຂາວ, ປະທານກຸ່ມອາດຈະຮ້ອງຂໍເວລາຢູ່ໃນວາລະ BoD ເພື່ອຊອກຫາຂໍ້ມູນເຂົ້າໃສ່ BoD ກ່ຽວກັບການແກ້ໄຂ.

ຄຽງຄູ່ກັບກົດreາຍview, ກຸ່ມດັ່ງກ່າວຕ້ອງສົ່ງ ໜັງ ສືຂາວໃຫ້ BARB ເພື່ອຂຽນຄືນໃ່view. ໃນຖານະເປັນສ່ວນຫນຶ່ງຂອງ Re ຂອງເຂົາເຈົ້າview, BARB ອາດຈະແນະນໍາວ່າສ່ວນໃດສ່ວນ ໜຶ່ງ ຂອງເຈ້ຍຂາວຄວນຈະຖືກເອົາອອກຈາກເຈ້ຍຂາວແລະລວມເຂົ້າເປັນຂໍ້ກໍານົດສະເພາະຕາມຂະບວນການຢູ່ໃນພາກທີ 3. BARB ອາດຈະຕັດສິນໃຈທີ່ຈະສົ່ງເຈ້ຍຂາວດັ່ງກ່າວໃຫ້ກັບກຸ່ມຫຼືຄະນະກໍາມະການອື່ນອີກ.view. ພາຍຫຼັງການສໍາເລັດຂອງ BARB review, ກຸ່ມແລະ BARB ຈະຕົກລົງເຫັນດີກ່ຽວກັບຄໍາຄິດເຫັນທີ່ຈະລວມເຂົ້າໃສ່ໃນປຶ້ມປົກຂາວ.

ຖ້າຖືກຕ້ອງຕາມກົດາຍview ຜົນໄດ້ຮັບໃນການປ່ຽນແປງທີ່ ສຳ ຄັນໃດ ໜຶ່ງ, ເພີ່ມເຕີມຄືນໃ່view ໂດຍ BARB ອາດຈະຕ້ອງການ. ເຊັ່ນດຽວກັນ, ຖ້າຫາກວ່າ BARB review ສົ່ງຜົນໃຫ້ມີການປ່ຽນແປງອັນໃຫຍ່ຫຼວງໃດ ໜຶ່ງ, BSTS ຈະກໍານົດວ່າຈະມີການປັບປຸງກົດadditionalາຍໃadditional່ຫຼືບໍ່view ຂອງການປ່ຽນແປງເຫຼົ່ານັ້ນແມ່ນຕ້ອງການ. ພາຍຫຼັງ ສຳ ເລັດການສ້າງກົດາຍຄືນໃ່view ແລະ BARB review, BARB ຕ້ອງອະນຸມັດຫຼືປະຕິເສດເຈ້ຍຂາວ.

ຫຼັງຈາກທີ່ BARB ອະນຸມັດເຈ້ຍຂາວ, ເຈ້ຍຂາວທີ່ໄດ້ຮັບການອະນຸມັດຈາກ BARB ຈະຖືກ ນຳ ສະ ເໜີ ໂດຍກຸ່ມຜູ້ຂຽນຫລືຄະນະ ກຳ ມະການໃຫ້ BoD ເພື່ອຂໍອະນຸມັດ.

ຂັ້ນຕອນການຂຽນເອກະສານສີຂາວແມ່ນ ສຳ ເລັດເມື່ອ BoD ໄດ້ອະນຸມັດເຈ້ຍຂາວແລະກິດຈະ ກຳ ພາຍຫຼັງການອະນຸມັດຕໍ່ໄປນີ້ໄດ້ ສຳ ເລັດແລ້ວ:

• BSTS ໄດ້ເຮັດເຈ້ຍຂາວທີ່ໄດ້ຮັບການອະນຸມັດໃຫ້ເຜີຍແຜ່ສູ່ສາທາລະນະໃນ Bluetooth SIG webເວັບໄຊ.
• BSTS ແຈ້ງໃຫ້ສະມາຊິກທຸກຄົນຂອງເຈ້ຍຂາວທີ່ໄດ້ຮັບການອະນຸມັດ.
• ຖ້າເຈ້ຍສີຂາວແມ່ນການປັບປຸງເອກະສານສີຂາວທີ່ມີຢູ່, BSTS ຈະເກັບເອກະສານສະບັບຂາວໃຫ້ສະມາຊິກເພື່ອເຂົ້າເຖິງຈຸດປະສົງທາງປະຫວັດສາດ.

Bluetooth SIG ມີແຜນທີ່ຈະ ສຳ ເລັດກິດຈະ ກຳ ຫລັງການອະນຸມັດພາຍໃນ ໜຶ່ງ ອາທິດຫລັງຈາກໄດ້ຮັບການອະນຸມັດເຈ້ຍຂາວ.

 

10. ເອກະສານອ້າງອີງ

ເອກະສານ Bluetooth ທີ່ອ້າງອີງແມ່ນມີຢູ່ຈາກ Bluetooth webເວັບໄຊ http://www.bluetooth.com.

1. ຄຳ ແນະ ນຳ ກ່ຽວກັບຮ່າງຮ່າງ Bluetooth (ມີຢູ່ໃນ ໜ້າ ເວບໄຊທ໌ແລະເອກະສານກ່ຽວກັບກຸ່ມເຮັດວຽກ, ຢູ່ https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
2. ກົດ ໝາຍ ຂອງ Bluetooth SIG, Inc (ມີຢູ່ໃນ ໜ້າ ເອກະສານການປົກຄອງ, ທີ່ https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
3. ເອກະສານກ່ຽວກັບຂະບວນການເຮັດວຽກຂອງລະບົບ Bluetooth Specification Errata (ມີຢູ່ໃນ ໜ້າ Templates & Documents page, ທີ່ https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
4. ເອກະສານຂະບວນການເຮັດວຽກຂອງກຸ່ມ (ມີຢູ່ໃນ ໜ້າ ເວບໄຊທ໌ແລະເອກະສານກຸ່ມເຮັດວຽກ, ທີ່ https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
5. ຍຸດທະສາດການທົດສອບແລະ ຄຳ ສັບສິ້ນສຸດview ເອກະສານ (ມີຢູ່ໃນ ໜ້າ ຂໍ້ກໍານົດການທົດສອບຄຸນວຸດທິ, ທີ່ https://www.bluetooth.com/specifications/qualification-test-requirements)
6. ລາຍລະອຽດຂອງ BTIview ລາຍການກວດສອບຂະບວນການ (ມີຢູ່ໃນແມ່ແບບກຸ່ມເຮັດວຽກແລະ ໜ້າ ເອກະສານ, ທີ່ https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
7. ຕົວເລກທີ່ມອບ ໝາຍ ໂດຍ Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
8. ແມ່ແບບແລະເອກະສານກຸ່ມທີ່ເຮັດວຽກ (ມີຢູ່ໃນ ໜ້າ ແມ່ແບບແລະເອກະສານກຸ່ມເຮັດວຽກ, ຢູ່ https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
9. ອາຫານເສີມການສະເພາະຂອງ GATT (GSS) (ມີຢູ່ໃນ ໜ້າ ທີ່ສະເພາະຂອງ GATT, ທີ່ https://www.bluetooth.com/specifications/gatt)
10. ຍື່ນສະ ເໜີ Idea ສຳ ລັບສະເພາະເຈາະຈົງ ໃໝ່ https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

 

11. ຄຳ ຫຍໍ້ແລະ ຄຳ ຫຍໍ້

ຕາຕະລາງ A: ຄຳ ຫຍໍ້ແລະ ຄຳ ຫຍໍ້

 

ເອກະສານຊ້ອນທ້າຍ A - ການຈັດປະເພດຄວາມຮຸນແຮງຂອງ Erratum

ເອກະສານຊ້ອນທ້າຍນີ້ສະຫລຸບ ຄຳ ແນະ ນຳ ກ່ຽວກັບການຈັດແບ່ງປະເພດຄວາມຮຸນແຮງ ສຳ ລັບການກວດສອບສະເພາະເຈາະຈົງ. ຕາຕະລາງນີ້ຈະຖືກເພີ່ມເຂົ້າໃນການປັບປຸງ EPD ໃນອະນາຄົດ, ແລະຈາກນັ້ນພາກນີ້ຈະຖືກລຶບອອກ.

 

ອ່ານເພີ່ມເຕີມກ່ຽວກັບຄູ່ມືນີ້ ແລະດາວໂຫຼດ PDF:

ເອກະສານຂະບວນການຄຸ້ມຄອງສະເພາະ (SMPD) - ປັບແຕ່ງ PDF
ເອກະສານຂະບວນການຄຸ້ມຄອງສະເພາະ (SMPD) - PDF ຕົ້ນສະບັບ

ຄໍາຖາມກ່ຽວກັບຄູ່ມືຂອງທ່ານ? ປະກາດໃນຄໍາເຫັນ!

ເອກະສານອ້າງອີງ

• ຄູ່ມືຜູ້ໃຊ້