11.5. การเชื่อมต่อ#

เมื่ออุปกรณ์ central เลือก peripheral จากสตรีมโฆษณาและส่ง คำขอเชื่อมต่อ ทั้งสองฝั่งจะออกจากโหมดโฆษณา/สแกน และเข้าสู่ การเชื่อมต่อ วิทยุจะกำหนดเวลาการทำงานบนช่องข้อมูลของ link layer โดยกระโดดสุ่มเทียมระหว่างช่องเหล่านั้นตามลำดับที่ตกลงกันเมื่อเชื่อมต่อ ทุกอย่างเหนือ link layer ไม่ว่าจะเป็น GATT, security, L2CAP ล้วนทำงานบนการเชื่อมต่อที่สร้างขึ้นที่นี่

11.5.1. เหตุการณ์การเชื่อมต่อ#

อุปกรณ์สองตัวในการเชื่อมต่อ BLE ไม่ได้ส่งข้อมูลต่อเนื่องตลอดเวลา ทั้งคู่จะตกลงกันในเรื่อง ช่วงเวลาการเชื่อมต่อ และในทุกช่วงเวลา ทั้งสองฝั่งจะปลุกวิทยุ แลกเปลี่ยนแพ็กเกตที่อยู่ในคิว ยืนยันสิ่งที่ได้รับ แล้วก็กลับไปสแตนด์บาย การแลกเปลี่ยนแต่ละครั้งเรียกว่า เหตุการณ์การเชื่อมต่อ

A timeline with the central on the top track and the peripheral on the bottom track. At each connection interval boundary both tracks show a short pulse labelled "TX/RX". The gap between pulses is labelled "connection interval"; the duration of each pulse is "connection event". The peripheral has a few skipped events labelled "peripheral latency: peripheral may skip if idle".

วิทยุในแต่ละฝั่งจะตื่นเฉพาะในช่วงเหตุการณ์การเชื่อมต่อสั้นๆ โดยทุกอย่างอื่นจะอยู่ในโหมดสลีป peripheral อาจข้ามเหตุการณ์ได้ภายใต้ peripheral latency#

ตัวเลขที่ควบคุมการทำงานเหล่านี้จะถูกเจรจาตอนเชื่อมต่อและ link layer จะบังคับใช้ ค่าเหล่านี้จะปรากฏต่อแอปพลิเคชันทั้งในรูปแบบของตัวปรับแต่งฝั่งคำขอและค่าผลลัพธ์ที่รายงานกลับมา

  • ช่วงเวลาการเชื่อมต่อ ตั้งแต่ 7.5 ms ถึง 4 s ในขั้นตอน 1.25 ms ฝั่ง central จะเลือกค่าตามที่ peripheral ร้องขอ เว้นแต่คำขอนั้นไม่สมเหตุสมผล ช่วงเวลาที่สั้นกว่าจะส่งข้อมูลด้วยเวลาแฝงที่ต่ำกว่าแต่ใช้วิทยุมากกว่า ในขณะที่ช่วงเวลาที่ยาวกว่าจะประหยัดพลังงานแต่ทำให้การรับส่งข้อมูลแต่ละรอบช้าลง

  • Peripheral latency. จำนวนเต็มที่ไม่เป็นลบ N peripheral ได้รับอนุญาตให้ข้ามเหตุการณ์การเชื่อมต่อได้มากถึง N เหตุการณ์เมื่อไม่มีอะไรส่ง โดยกลับไปสลีปแทนที่จะปลุกวิทยุสำหรับการแลกเปลี่ยนที่ว่างเปล่า มีประโยชน์สำหรับ sensor ที่ตื่นขึ้นมารายงานทุกวินาทีแต่ต้องการช่วงเวลาการเชื่อมต่อที่ ตอบสนองได้ ต่ำสำหรับข้อความเร่งด่วนที่เกิดขึ้นไม่บ่อย

  • Supervision timeout. ตั้งแต่ 100 ms ถึง 32 s หากฝั่งใดฝั่งหนึ่งไม่ได้ยินจากอีกฝั่งนานเท่านี้ การเชื่อมต่อจะถูกประกาศว่าสูญหายและทั้งสองฝั่งจะกลับไปโฆษณา/สแกน ค่า timeout จะต้องนานกว่า connection_interval * (1 + peripheral_latency) ซึ่ง link layer จะปฏิเสธค่าที่ละเมิดเงื่อนไขนี้

aioble.Device.connect() รับพารามิเตอร์ min_conn_interval_us และ max_conn_interval_us เพื่อให้ central สามารถขอช่วงเวลาเฉพาะได้ ค่าจริงที่วิทยุตั้งค่าไว้สามารถอ่านกลับผ่านการกำหนดค่า link layer หลังจากการเชื่อมต่อขึ้นมาแล้ว

11.5.2. ความหมายของ "central" และ "peripheral" ภายในการเชื่อมต่อ#

บทบาทที่กำหนดในช่วงโฆษณาจะคงอยู่หลังจากการเชื่อมต่อขึ้นมาแล้ว:

  • central ขับเคลื่อนจังหวะเวลา โดยเป็นเจ้าของฝั่ง master ของลำดับการกระโดดช่องสัญญาณและเหตุการณ์การเชื่อมต่อ

  • peripheral เป็นฝ่ายตอบสนอง สามารถขอเปลี่ยนพารามิเตอร์การเชื่อมต่อ (เช่น ช่วงเวลาที่ช้าลงเพื่อประหยัดพลังงาน) แต่ central เป็นผู้ตัดสินว่าจะยอมรับหรือไม่

บทบาทเหล่านี้เป็นอิสระจากการโฮสต์ฐานข้อมูล GATT ซึ่งเป็นมิติที่แยกต่างหาก ตามแบบแผน peripheral จะเป็น GATT server และ central จะเป็น GATT client แต่ BLE อนุญาตให้ฝั่งใดก็ได้โฮสต์ GATT services กล้องแทบทุกตัวปฏิบัติตามแบบแผน: peripheral + server สำหรับแอปพลิเคชัน "กล้องเผยแพร่ข้อมูล" และ central + client สำหรับแอปพลิเคชัน "กล้องอ่านจาก sensor"

11.5.3. หน่วยส่งข้อมูลสูงสุด (MTU)#

link layer จะส่งแพ็กเกตที่สั้นตามค่าเริ่มต้น ได้แก่ 27 ไบต์ของ payload ซึ่งมีเพียง 23 ไบต์เท่านั้นที่ GATT ใช้งานได้ นั่นเพียงพอสำหรับการอ่านค่าเล็กๆ หรือคำสั่งสั้นๆ แต่เล็กมากเมื่อเทียบกับข้อมูลหลายไบต์ ทั้งสองฝั่งสามารถเจรจาเพิ่มค่านี้ขึ้น จนถึงขีดจำกัดที่ radio firmware รองรับ (โดยทั่วไปหลายร้อยไบต์บนตัวควบคุมสมัยใหม่)

aioble API ขับเคลื่อนการเจรจาผ่าน aioble.DeviceConnection.exchange_mtu() และผลลัพธ์จะปรากฏบน attribute mtu MTU ที่ใหญ่ขึ้นหมายถึงการรับส่งข้อมูลน้อยรอบสำหรับค่าที่ใหญ่กว่า ~20 ไบต์ โดยแลกกับหน่วยความจำบัฟเฟอร์เพิ่มขึ้นเล็กน้อย

11.5.4. อายุการใช้งาน#

การเชื่อมต่อจะคงอยู่จนกว่าจะเกิดสิ่งใดสิ่งหนึ่งต่อไปนี้:

  • ฝั่งใดฝั่งหนึ่งเรียก disconnect(),

  • supervision timeout หมดอายุ (อยู่นอกพิสัย วิทยุปิด หรืออีกฝ่ายเกิดข้อผิดพลาด) หรือ

  • ความล้มเหลวของ link layer อย่างชัดเจน (encryption ไม่ตรงกัน หรือการจับคู่ถูกปฏิเสธ)

เมื่อการเชื่อมต่อหลุด ทุก GATT operation ที่อยู่ในคิวหรือกำลังดำเนินการอยู่จะยก aioble.DeviceDisconnectedError และบล็อก async with connection ทุกบล็อกที่แอปพลิเคชันอยู่จะออกได้อย่างสะอาด peripheral มักจะตอบสนองโดยกลับไป aioble.advertise() และรอ central ตัวต่อไป ส่วน central จะตอบสนองโดยสแกนใหม่หรือแสดงการตัดการเชื่อมต่อให้แอปพลิเคชันทราบ

อายุการใช้งานเป็นหนึ่งในเหตุผลที่ aioble มีประโยชน์ BLE API แบบ synchronous จะต้องเปิดเผย disconnect callbacks และ event masks แต่เวอร์ชัน asyncio จะเปลี่ยนการตัดการเชื่อมต่อให้เป็น exception ภายใน coroutine ที่กำลังรอ operation ซึ่งนั่นคือสิ่งที่การล้างข้อมูล async with ถูกออกแบบมาเพื่อจัดการ