עמלה

עמלה ב-Matter היא תהליך ההקצאה של פרטי הכניסה ל-Fabric למכשיר חדש. הנציב הוא המכשיר שמבצע את תהליך העמלה. הנציבות היא המכשיר החדש שצריך להקצות ל-Fabric.

באופן כללי, ניתן לחלק את תהליך העמלה למספר שלבים:

גילוי מכשירים

לפני תחילת תהליך העמלה, הוועדה צריכה להתחיל לפרסם את עצמה. הוועדה יכולה לפרסם את עצמה בכל אחת משלוש השיטות של Commissionable Discovery. הוועדה צריכה גם לספק את המטען הייעודי (payload) של ההדרכה למשתמשים חדשים.

התחברות למכשיר (PASE)

אחרי שהנציב ראה את המודעה ומצא התאמה בין המחלק, הנציב משתמש בקוד הגישה של המטען הייעודי (payriminator) כדי להתחבר למכשיר באמצעות Passcode Authenticated Session Establishment (PASE). זאת השיטה ליצור באופן מאובטח מפתחות ששני המכשירים יוכלו להשתמש בהם לתקשורת. בשלב הזה, הנציב גם מגן על מנגנון מניעת כשל. בעזרת הגנה מפני כשל, אפשר להחזיר את המכשיר למצב המקורי אם ההפעלה לא הושלמה.

קבלת מידע על העמלה

הנציב קורא את כל התיאורים שהוועדה. השדה DescriptorCluster נמצא בנקודת הקצה 0 של המכשיר ומתאר את כל נקודות הקצה (endpoints). הנציב קורא גם את אשכול המידע הבסיסי, שכולל מידע כמו מזהה הספק, מזהה המוצר, שם המוצר והמספר הסידורי. בשלב הזה, הנציב קורא גם את סוג המכשיר של הנציבות, וכך עוזר לשפר את חוויית המשתמש אצל הנציב.

הגדרות תקינה

הנציב מגדיר את המידע על עמידה בתקנות של הנציבות באמצעות הפקודה SetRegulatoryConfig. המידע על עמידה בתקנות כולל מידע כמו הגדרת המיקום (פנים/חיצוניים/שניהם) של המכשיר או הגדרת קוד המדינה.

אימות של הוועדה

המטרה של הליך האימות של הנציבות היא לקבוע אם מכשיר אושר ואם מכשיר Matter מקורי. ה-Commiter מחלץ מהנציבות את אישור האימות של המכשיר (DAC) ואת האישור Product Attestation Intermediate (PAI). האישורים האלה מכילים את מזהה הספק, מזהה המוצר והמפתח הציבורי לאימות. אחרי קבלת האישורים, הנציב ישלח בקשת אימות שאמורה להיות חתומה על ידי המפתח הפרטי לאימות (attestation) והאימות ייעזר בה כדי לאמת את האותנטיות של הנציבות.

בקשה לחתימה על אישור (CSR)

הנציב שולח בקשה לחתימה על אישור (CSR) לוועדה. הנציבות יוצרת זוג מפתחות תפעוליים ייחודיים שישמשו בהמשך Certificate Authenticated Session Establishment (CASE). הנציבות מחזירה את פרטי ה-CSR שלה בחזרה ל-Commissioner.

הוספת אישור תפעולי של צומת (NOC)

הנציב משתמש בפרטי ה-CSR שהתקבלו מהנציבות ומעביר אותם ל-Administrative Domain Manager (ADM) כדי ליצור אישור תפעולי של צומת (NOC) מהימן. הנציב מתקין את אישור הבסיס של הוועדה באמצעות הפקודה AddTrustedRootCertReq, ואז מתקין את האישור התפעולי של הצומת באמצעות הפקודה AddNOC.

ניהול תצורת רשת

הנציב מגדיר את הרשת התפעולית בוועדה. השלב הזה נדרש למכשירי Thread או Wi-Fi. לא צריך לבצע את השלב הזה במכשירי Ethernet שבהם המכשיר כבר מחובר לרשת. הוא משתמש בפקודות ScanNetworks, AddOrUpdateWifiNetwork ו-ConnectNetwork.

גילוי תפעולי

אחרי שמחברים את הצומת החדש שהוזמן לרשת, הנציב משתמש בגילוי תפעולי כדי למצוא את הצומת ברשת התפעולית. גילוי תפעולי הוא התהליך שבו נמצאים צמתים שהוזמנו ברשת התפעולית באמצעות DNS-SD. אם הנציבות היא מכשיר Wi-Fi, היא תשתמש ב-mDNS כדי לגלות את המכשיר.

הגילוי התפעולי עוזר לנציב ולצמתים אחרים ברשת לדעת באיזו כתובת IP ובאיזו יציאה היא משתמשת.

יצירת מפגש פנייה

אחרי שמתגלה הצומת החדש שהוזמן, נוצר סשן CASE בין הנציב לבין המכשיר. הנציבות יזמה את הסשן הזה, והמכשיר יענה לה. בשלב הזה מתבצעת החלפה של אישורי תפעול, והמערכת יוצרת אמון משותף על ידי תיקוף שהם נמצאים באותו מארג לוגי.

תהליך ההכנה הושלם

הנציב משתמש ב-CASE כדי לשלוח את הפקודה CommissioningComplete למכשיר החדש שהוזמן. זה השלב האחרון בתהליך ההזמנה. CommissioningComplete גם מכבה אוטומטית את הטיימר למניעת כשלים. אחרי השלמת ההזמנה, המכשיר פועל כמו כל צומת אחר ברשת התפעול.