עמלה

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

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

תהליך עמלה
איור 1: תהליך היצירה – רמה גבוהה

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

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

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

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

קבלת פרטים על הנציבות

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

הגדרות התקינה

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

אימות (attestation) של הנציב

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

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

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

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

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

הקצאת רשת

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

זיהוי תפעולי

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

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

יצירת פנייה

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

תהליך העמלה הושלם

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