Find Hub नेटवर्क ऐक्सेसरी की खास जानकारी

v1.3

Find Hub नेटवर्क (FHN) ऐक्सेसरी स्पेसिफ़िकेशन में, बीकन वाले ब्लूटूथ लो एनर्जी (BLE) डिवाइसों को ट्रैक करने के लिए, पूरी तरह सुरक्षित तरीके के बारे में बताया गया है. इस पेज पर, FHN को Fast Pair की खास बातों के एक्सटेंशन के तौर पर बताया गया है. अगर सेवा देने वाली कंपनियों के पास ऐसे डिवाइस हैं जो FHN के साथ काम करते हैं और वे उन डिवाइसों के लिए जगह की जानकारी ट्रैक करने की सुविधा चालू करना चाहती हैं, तो उन्हें इस एक्सटेंशन को चालू करना चाहिए.

GATT की खास बातें

फ़ास्ट पेयर सेवा में, एक और सामान्य एट्रिब्यूट (GATT) की विशेषता जोड़ी जानी चाहिए. इसका सिमैंटिक इस तरह होना चाहिए:

फ़ास्ट पेयर सेवा की विशेषता	एन्क्रिप्ट किया गया	अनुमतियां	यूयूआईडी
बीकन की कार्रवाइयां	नहीं	पढ़ने, लिखने, और सूचना पाने का ऐक्सेस	FE2C1238-8366-4814-8EB0-01DE32100BEA

टेबल 1: FHN के लिए फ़ास्ट पेयर सेवा की विशेषताएं.

पुष्टि करना

इस एक्सटेंशन के लिए ज़रूरी कार्रवाइयां, लिखने की कार्रवाई के तौर पर की जाती हैं. इन्हें चुनौती-जवाब के तरीके से सुरक्षित किया जाता है. कोई भी कार्रवाई करने से पहले, सीक करने वाले डिवाइस को टेबल 1 में मौजूद विशेषता से रीड ऑपरेशन करना होता है. इससे बफ़र इस फ़ॉर्मैट में मिलता है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	प्रोटोकॉल के मेजर वर्शन का नंबर	0x01
1 - 8	बाइट अरे	एक बार इस्तेमाल किया जाने वाला रैंडम नॉनस	अलग-अलग होती है

हर रीड ऑपरेशन से अलग नॉनस जनरेट होना चाहिए. साथ ही, एक नॉनस सिर्फ़ एक ऑपरेशन के लिए मान्य होना चाहिए. अगर ऑपरेशन पूरा नहीं होता है, तब भी नॉनस को अमान्य कर देना चाहिए.

इसके बाद, सीक करने वाला व्यक्ति एक बार इस्तेमाल होने वाली पुष्टि करने की कुंजी का हिसाब लगाता है. इसका इस्तेमाल, बाद में लिखने के अनुरोध में किया जाता है. पुष्टि करने की कुंजी का हिसाब, टेबल 2 से 5 में बताए गए तरीके से लगाया जाता है. अनुरोध की गई कार्रवाई के आधार पर, सीक करने वाला व्यक्ति इनमें से एक या एक से ज़्यादा कुंजियों के बारे में जानकारी देता है:

• खाते की कुंजी: यह 16 बाइट की फ़ास्ट पेयर खाते की कुंजी होती है. इसके बारे में फ़ास्ट पेयर के स्पेसिफ़िकेशन में बताया गया है.

• मालिकाना हक वाले खाते की कुंजी: जब कोई व्यक्ति पहली बार Beacon Actions की सुविधा को ऐक्सेस करता है, तब सेवा देने वाली कंपनी, मौजूदा खाता कुंजियों में से किसी एक को मालिकाना हक वाले खाते की कुंजी के तौर पर चुनती है. चुनी गई मालिकाना हक वाले खाते की कुंजी को तब तक नहीं बदला जा सकता, जब तक सेवा देने वाली कंपनी के डिवाइस को फ़ैक्ट्री रीसेट न कर दिया जाए. जब सेवा देने वाली कंपनी के डिवाइस में खाता कुंजियों के लिए उपलब्ध मुफ़्त स्लॉट खत्म हो जाते हैं, तब उसे मालिकाना हक वाले खाते की कुंजी को नहीं हटाना चाहिए.

  • पहली बार पेयर करने पर, जो प्रोवाइडर पहले से ही FHN की सुविधा के साथ काम करते हैं या फ़ैक्ट्री रीसेट के बाद पेयर करने पर इस सुविधा के साथ काम करते हैं वे पहली खाता कुंजी चुनते हैं. ऐसा इसलिए, क्योंकि पेयरिंग के दौरान, सीक करने वाला डिवाइस जब प्रोविज़निंग की स्थिति को पढ़ता है, तब यही एकमात्र मौजूदा खाता कुंजी होती है.

  • अगर किसी सेवा देने वाली कंपनी को डिवाइस को पहले से पेयर करने के बाद FHN की सुविधा मिलती है (उदाहरण के लिए, फ़र्मवेयर अपडेट के ज़रिए), तो वह मौजूदा खाता कुंजी में से कोई भी कुंजी चुन सकती है. फ़र्मवेयर अपडेट के बाद, पहली खाता कुंजी को चुनना सही है. इसका इस्तेमाल, बीकन ऐक्शन की विशेषता से प्रोविज़निंग की स्थिति को पढ़ने के लिए किया जाता है. हालांकि, यह मान लिया जाता है कि अपडेट करने वाला व्यक्ति, मौजूदा समय में सेवा देने वाली कंपनी का मालिक है.

• एफ़ेमरल आइडेंटिटी की (ईआईके): यह 32 बाइट की एक ऐसी कुंजी होती है जिसे सीक करने वाला व्यक्ति, एफ़एचएन की सुविधा चालू करने की प्रोसेस के दौरान रैंडम तरीके से चुनता है. इस कुंजी का इस्तेमाल, क्रिप्टोग्राफ़िक कुंजियां पाने के लिए किया जाता है. इन कुंजियों का इस्तेमाल, जगह की जानकारी वाली रिपोर्ट को एंड-टू-एंड एन्क्रिप्ट करने के लिए किया जाता है. सीक करने वाला व्यक्ति, इसे कभी भी बैकएंड को नहीं दिखाता.

• रिकवरी कुंजी: इसे SHA256(ephemeral identity key || 0x01) के तौर पर तय किया जाता है. इसमें पहले आठ बाइट शामिल होते हैं. यह कुंजी बैकएंड पर सेव होती है. साथ ही, सीक करने वाला व्यक्ति इसका इस्तेमाल करके ईआईके को वापस पा सकता है. हालांकि, इसके लिए उपयोगकर्ता को डिवाइस पर मौजूद बटन दबाकर सहमति देनी होगी.

• रिंग की: इसे SHA256(ephemeral identity key || 0x02) के तौर पर तय किया जाता है. इसे पहले आठ बाइट तक छोटा किया जाता है. कुंजी को बैकएंड पर सेव किया जाता है. साथ ही, ढूंढने वाला व्यक्ति इसका इस्तेमाल सिर्फ़ डिवाइस को बजाने के लिए कर सकता है.

• ट्रैकिंग सुरक्षा की अवांछित कुंजी: इसे SHA256(ephemeral identity key || 0x03) के तौर पर तय किया गया है. इसे पहले आठ बाइट में छोटा किया गया है. यह कुंजी बैकएंड पर सेव की जाती है. साथ ही, इसे सिर्फ़ अनचाही ट्रैकिंग से सुरक्षा मोड को चालू करने के लिए इस्तेमाल किया जा सकता है.

कार्रवाइयां

टेबल 2 से 5 में, विशेषता के लिए लिखे गए डेटा का फ़ॉर्मैट दिया गया है. इस सेक्शन में, हर ऑपरेशन के बारे में ज़्यादा जानकारी दी गई है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x00: बीकन पैरामीटर पढ़ें 0x01: Read provisioning state 0x02: Set ephemeral identity key 0x03: कुछ समय के लिए इस्तेमाल की जाने वाली आइडेंटिटी की कुंजी हटाएं
1	uint8	डेटा का साइज़	अलग-अलग होती है
2 - 9	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) के पहले 8 बाइट
10 - var	बाइट अरे <0	अतिरिक्त डेटा	0x00: n/a 0x01: n/a 0x02: 32 बाइट, जो कुछ समय के लिए पहचान की कुंजी होती है. इसे खाते की कुंजी के साथ AES-ECB-128 का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया जाता है. अगर सेवा देने वाली कंपनी के पास पहले से ही एक एफ़ेमरल आइडेंटिटी कुंजी सेट है, तो SHA256(current ephemeral identity key || the last nonce read from the characteristic) के पहले 8 बाइट भी भेजें 0x03: SHA256(ephemeral identity key || the last nonce read from the characteristic) के पहले 8 बाइट

दूसरी टेबल: बीकन प्रोविज़निंग का अनुरोध.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x04: उपयोगकर्ता की सहमति से, कुछ समय के लिए मान्य पहचान कुंजी को पढ़ना
1	uint8	डेटा का साइज़	0x08
2 - 9	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length) के पहले 8 बाइट

टेबल 3: बीकन प्रोविज़निंग कुंजी रिकवरी अनुरोध.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x05: रिंग 0x06: Read ringing state
1	uint8	डेटा का साइज़	अलग-अलग होती है
2 - 9	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) के पहले 8 बाइट
10 - var	बाइट अरे	अतिरिक्त डेटा	0x05: चार बाइट, जिनसे कॉल की घंटी बजने की स्थिति, घंटी बजने की अवधि, और घंटी की आवाज़ के बारे में पता चलता है. 0x06: n/a

चौथी टेबल: कॉल करने का अनुरोध.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x07: अनचाही ट्रैकिंग से सुरक्षा देने वाला मोड चालू करें 0x08: अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड को बंद करें
1	uint8	डेटा का साइज़	अलग-अलग होती है
2 - 9	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) के पहले 8 बाइट
10 - var	बाइट अरे	अतिरिक्त डेटा	0x07: कंट्रोल फ़्लैग का 1 बाइट (ज़रूरी नहीं) 0x08: SHA256(ephemeral identity key || the last nonce read from the characteristic) के पहले 8 बाइट

पांचवीं टेबल: अनचाही ट्रैकिंग से सुरक्षा के लिए अनुरोध.

लिखने की प्रोसेस पूरी होने पर, टेबल 6 में दी गई सूचनाएं ट्रिगर होती हैं.

0x05: रिंग की स्थिति में बदलाव के अलावा किसी अन्य डेटा आईडी वाली सूचनाएं, सूचना ट्रिगर करने वाले राइट लेन-देन के पूरा होने से पहले भेजी जानी चाहिए. इसका मतलब है कि राइट अनुरोध के लिए रिस्पॉन्स पीडीयू भेजे जाने से पहले सूचनाएं भेजी जानी चाहिए.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी <0	0x00: बीकन पैरामीटर पढ़ें 0x01: Read provisioning state 0x02: Set ephemeral identity key 0x03: कुछ समय के लिए इस्तेमाल की जाने वाली आइडेंटिटी की कुंजी हटाएं 0x04: उपयोगकर्ता की सहमति से, कुछ समय के लिए मान्य पहचान कुंजी को पढ़ना 0x05: रिंग की स्थिति में बदलाव 0x06: Read ringing state 0x07: अनचाही ट्रैकिंग से सुरक्षा देने वाला मोड चालू करें 0x08: अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड को बंद करें
1	uint8	डेटा का साइज़	अलग-अलग होती है
2 - 9	बाइट अरे	पुष्टि करना	हर ऑपरेशन के हिसाब से ज़्यादा जानकारी
10 - var <	बाइट अरे <0	अतिरिक्त डेटा	0x00: 8 बाइट, जो ट्रांसमिशन पावर, घड़ी की वैल्यू, एन्क्रिप्शन का तरीका, और रिंगिंग की सुविधाओं के बारे में बताते हैं. इन्हें AES-ECB-128 का इस्तेमाल करके, खाते की कुंजी (शून्य पैडिंग) के साथ एन्क्रिप्ट (सुरक्षित) किया जाता है 0x01: 1 बाइट, जो प्रोविज़निंग की स्थिति के बारे में बताती है. इसके बाद, लागू होने पर मौजूदा कुछ समय के लिए मान्य आईडी (20 या 32 बाइट) 0x04: 32 बाइट, जो कुछ समय के लिए पहचान की कुंजी होती है. इसे AES-ECB-128 का इस्तेमाल करके, खाते की कुंजी से एन्क्रिप्ट (सुरक्षित) किया जाता है 0x05: 4 बाइट, जो बदलाव के लिए नई स्थिति और ट्रिगर के बारे में जानकारी देती हैं 0x06: तीन बाइट, जो यह दिखाती हैं कि कौनसे कॉम्पोनेंट बज रहे हैं और बजने के लिए कितने डेसीसेकंड बचे हैं अन्य डेटा आईडी में अतिरिक्त डेटा नहीं है

टेबल 6: बीकन सेवा का जवाब.

टेबल 7 में, कार्रवाइयों से मिलने वाले संभावित GATT गड़बड़ी कोड दिए गए हैं.

कोड	ब्यौरा	नोट
0x80	प्रमाणीकृत नहीं किया गया	यह तब दिखता है, जब लिखने का अनुरोध करने पर पुष्टि नहीं हो पाती. इसमें वह मामला भी शामिल है जब पुराने नॉनस का इस्तेमाल किया गया हो.
0x81	अमान्य मान	यह तब दिखता है, जब कोई अमान्य वैल्यू दी गई हो या मिले हुए डेटा में बाइट की संख्या उम्मीद से ज़्यादा हो.
0x82	उपयोगकर्ता की सहमति नहीं ली गई	यह तब दिखता है, जब डिवाइस पेयरिंग मोड में न हो और डेटा आईडी 0x04: Read ephemeral identity key with user consent के साथ राइट अनुरोध के जवाब में दिखाया गया हो.

टेबल 7: GATT के गड़बड़ी कोड.

बीकन के पैरामीटर को पढ़ना

सीकर, प्रोवाइडर से बीकन के पैरामीटर के बारे में क्वेरी कर सकता है. इसके लिए, उसे टेबल 2 में दिए गए अनुरोध के साथ डेटा आईडी 0x00 वाली विशेषता पर राइट ऑपरेशन करना होगा. Provider यह पुष्टि करता है कि दी गई एक बार इस्तेमाल होने वाली पुष्टि करने की कुंजी, डिवाइस पर सेव की गई किसी भी खाता कुंजी से मेल खाती है.

पुष्टि न होने पर, Provider, पुष्टि न होने की गड़बड़ी का मैसेज दिखाता है.

अनुरोध पूरा होने पर, सेवा देने वाली कंपनी, टेबल 6 में दिए गए जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x00 होता है. डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह से बनाती है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	कैलिब्रेट की गई पावर	0 मीटर पर मिली कैलिब्रेट की गई पावर (यह वैल्यू [-100, 20] की रेंज में होती है). इसे पूर्णांक के तौर पर दिखाया जाता है. इसका रिज़ॉल्यूशन 1 dBm होता है.
1 - 4	uint32	घड़ी का समय	सेकंड में घड़ी की मौजूदा वैल्यू (बिग एंडियन).
5	uint8	कर्व चुनना	एन्क्रिप्शन के लिए इस्तेमाल किया जा रहा इलिप्टिक कर्व: 0x00 (डिफ़ॉल्ट): SECP160R1 0x01: SECP256R1 (इसके लिए, एक्सटेंडेड विज्ञापन की सुविधा ज़रूरी है)
6	uint8	घटक	रिंग करने की सुविधा वाले कॉम्पोनेंट की संख्या: 0x00: इससे पता चलता है कि डिवाइस में घंटी बजने की सुविधा नहीं है. 0x01: इससे पता चलता है कि सिर्फ़ एक कॉम्पोनेंट में रिंगटोन बजने की सुविधा है. 0x02: इससे पता चलता है कि बाएं और दाएं, दोनों ईयरबड अलग-अलग बज सकते हैं. 0x03: इससे पता चलता है कि तीन कॉम्पोनेंट, बाएं और दाएं ईयरबड और केस, अलग-अलग रिंग कर सकते हैं.
7	uint8	घंटी बजने की सुविधाएं	इन विकल्पों का इस्तेमाल किया जा सकता है: 0x00: रिंगटोन की आवाज़ चुनने की सुविधा उपलब्ध नहीं है. 0x01: रिंगटोन के वॉल्यूम को चुनने की सुविधा उपलब्ध है. अगर यह सुविधा सेट की गई है, तो सेवा देने वाली कंपनी को रिंग ऑपरेशन में बताए गए तीन वॉल्यूम लेवल स्वीकार करने होंगे और उन्हें मैनेज करना होगा.
8-15	बाइट अरे	पैडिंग (जगह)	AES एन्क्रिप्शन के लिए ज़ीरो पैडिंग.

डेटा को एईएस-ईसीबी-128 का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए. इसके लिए, उस खाते की कुंजी का इस्तेमाल किया जाना चाहिए जिसका इस्तेमाल अनुरोध की पुष्टि करने के लिए किया गया था.

प्रमाणीकरण सेगमेंट, HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

बीकन की प्रॉविज़निंग की स्थिति को पढ़ना

सीकर, प्रोवाइडर से बीकन की प्रोविज़निंग की स्थिति के बारे में क्वेरी कर सकता है. इसके लिए, उसे टेबल 2 में दिए गए डेटा आईडी 0x01 के साथ, अनुरोध वाली विशेषता पर राइट ऑपरेशन करना होगा. Provider यह पुष्टि करता है कि दी गई एक बार इस्तेमाल होने वाली पुष्टि करने की कुंजी, डिवाइस पर सेव की गई किसी भी खाता कुंजी से मेल खाती है.

पुष्टि न होने पर, प्रोवाइडर पुष्टि न होने की गड़बड़ी दिखाता है.

अनुरोध पूरा होने पर, सेवा देने वाली कंपनी, टेबल 6 से मिले जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x01 होता है. सेवा देने वाली कंपनी, डेटा सेगमेंट को इस तरह से बनाती है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	प्रोविज़निंग की स्थिति	यह एक बिटमास्क है, जिसमें ये वैल्यू होती हैं: बिट 1 (0x01): अगर डिवाइस के लिए कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी की सेट की गई है, तो इसे सेट करें. बिट 2 (0x02): यह तब सेट होता है, जब दी गई पुष्टि करने की एक बार इस्तेमाल की जा सकने वाली कुंजी, मालिक के खाते की कुंजी से मेल खाती हो.
1 - 20 या 32	बाइट अरे	मौजूदा कुछ समय के लिए मान्य आइडेंटिफ़ायर	यह 20 या 32 बाइट का होता है. यह इस बात पर निर्भर करता है कि एन्क्रिप्शन के लिए किस तरीके का इस्तेमाल किया जा रहा है. यह डिवाइस के लिए सेट किए गए मौजूदा इफ़ेमरल आईडी को दिखाता है.

पुष्टि करने वाले सेगमेंट को HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी कुंजी सेट करना

अगर किसी ऐसे सेवा देने वाले व्यक्ति या कंपनी को FHN बीकन के तौर पर इस्तेमाल करना है जिसके लिए यह सुविधा चालू नहीं है या सेवा देने वाले किसी ऐसे व्यक्ति या कंपनी के लिए, कुछ समय के लिए इस्तेमाल होने वाले पहचान के तौर पर इस्तेमाल होने वाले कुंजी को बदलना है जिसके लिए यह सुविधा पहले से चालू है, तो ढूंढने वाला व्यक्ति या कंपनी, टेबल 2 में दिए गए अनुरोध के साथ-साथ डेटा आईडी 0x02 वाले अनुरोध को भी लिखती है. सेवा देने वाला व्यक्ति या कंपनी यह पुष्टि करती है कि:

• पुष्टि के लिए एक बार इस्तेमाल होने वाली दी गई कुंजी, मालिक के खाते की कुंजी से मेल खाती हो.
• अगर कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी की कुंजी का हैश दिया गया था, तो हैश की गई कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी की कुंजी, कुछ समय के लिए इस्तेमाल होने वाली मौजूदा आइडेंटिटी की कुंजी से मेल खाती है.
• अगर कुछ समय के लिए इस्तेमाल होने वाली पहचान की कुंजी का हैश नहीं दिया गया है, तो पुष्टि करें कि Provider को पहले से ही FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है.

पुष्टि न होने पर, प्रोवाइडर पुष्टि न होने की गड़बड़ी दिखाता है.

सफल होने पर, मैच की गई खाता कुंजी का इस्तेमाल करके, AES-ECB-128 डिक्रिप्ट करके, कुछ समय के लिए इस्तेमाल की जाने वाली आइडेंटिटी की को वापस पाया जाता है. इस कुंजी को डिवाइस पर सेव किया जाना चाहिए. इसके बाद, प्रोवाइडर को FHN फ़्रेम का विज्ञापन दिखाना शुरू कर देना चाहिए. बीएलई कनेक्शन बंद होने के तुरंत बाद, कुछ समय के लिए इस्तेमाल की जाने वाली नई आइडेंटिटी की लागू हो जाती है. प्रोवाइडर, डेटा आईडी 0x02 के साथ टेबल 6 से मिले जवाब की सूचना देता है.

प्रमाणीकरण सेगमेंट, HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

अस्थायी पहचान कुंजी मिटाएं

Provider के बीकन वाले हिस्से को अनप्रोविज़न करने के लिए, Seeker, विशेषता पर राइट ऑपरेशन करता है. इसमें टेबल 2 से अनुरोध होता है, जिसमें डेटा आईडी 0x03 होता है. सेवा देने वाली कंपनी पुष्टि करती है कि:

• पुष्टि के लिए एक बार इस्तेमाल होने वाली दी गई कुंजी, मालिक के खाते की कुंजी से मेल खाती हो.
• हैश की गई कुछ समय के लिए इस्तेमाल होने वाली पहचान कुंजी, कुछ समय के लिए इस्तेमाल होने वाली मौजूदा पहचान कुंजी से मेल खाती है.

अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो यह बिना पुष्टि वाली गड़बड़ी दिखाता है.

पुष्टि हो जाने पर, प्रोवाइडर कुंजी को भूल जाता है और FHN फ़्रेम का विज्ञापन दिखाना बंद कर देता है. प्रोवाइडर, टेबल 6 से मिले जवाब के साथ सूचना देता है. इसमें डेटा आईडी 0x03 होता है. पुष्टि करने वाले सेगमेंट को HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

उपयोगकर्ता की सहमति से, कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी कुंजी को पढ़ सकता है

यह विकल्प सिर्फ़ खोई हुई कुंजी को वापस पाने के लिए उपलब्ध है, क्योंकि कुंजी को सिर्फ़ Seeker डिवाइस पर स्थानीय तौर पर सेव किया जाता है. इसलिए, यह सुविधा सिर्फ़ तब उपलब्ध होती है, जब डिवाइस पेयरिंग मोड में हो या डिवाइस पर किसी बटन को दबाने के बाद कुछ समय तक (यह उपयोगकर्ता की सहमति मानी जाती है).

सीकर को बैकएंड पर रिकवरी की सेव करनी होगी, ताकि वह क्लियरटेक्स्ट की को वापस पा सके. हालांकि, यह ईआईके को सेव नहीं करता है.

ईआईके को पढ़ने के लिए, सीक करने वाला डिवाइस, विशेषता पर लिखने की कार्रवाई करता है. इसमें टेबल 3 से अनुरोध होता है, जिसका डेटा आईडी 0x04 होता है. सेवा देने वाली कंपनी पुष्टि करती है कि:

• हैश की गई रिकवरी कुंजी, अनुमानित रिकवरी कुंजी से मेल खाती है.
• डिवाइस, ईआईके रिकवरी मोड में है.

पुष्टि न होने पर, प्रोवाइडर पुष्टि न होने की गड़बड़ी दिखाता है.

अगर डिवाइस दूसरे डिवाइस से जोड़ने वाले मोड में नहीं है, तो Provider, No User Consent की गड़बड़ी दिखाता है.

अनुरोध पूरा होने पर, सेवा देने वाली कंपनी टेबल 6 में दिए गए जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x04 होता है.

प्रमाणीकरण सेगमेंट, HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

रिंग ऑपरेशन

सीकर, प्रोवाइडर से आवाज़ चलाने के लिए कह सकता है. इसके लिए, उसे विशेषता पर राइट ऑपरेशन करना होगा. इसमें टेबल 4 से मिला अनुरोध शामिल होता है. इसका डेटा आईडी 0x05 होता है. डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह से बनाती है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	रिंग ऑपरेशन	यह एक बिटमास्क है, जिसमें ये वैल्यू होती हैं: बिट 1 (0x01): दाईं तरफ़ वाला बजाएं बिट 2 (0x02): बाईं तरफ़ वाला बजाएं बिट 3 (0x04): रिंग केस 0xFF: सभी कॉम्पोनेंट को रिंग करें 0x00: घंटी बजना बंद करो
1 - 2	uint16	टाइम आउट की संख्या	यह डेसीसेकंड में टाइम आउट होता है. यह शून्य नहीं होना चाहिए और 10 मिनट से ज़्यादा नहीं होना चाहिए. Provider इस वैल्यू का इस्तेमाल यह तय करने के लिए करता है कि डिवाइस को कितनी देर तक बजना चाहिए. इसके बाद, डिवाइस अपने-आप बंद हो जाएगा. अगर डिवाइस का कोई कॉम्पोनेंट पहले से ही बज रहा है, तो टाइम आउट की यह वैल्यू, पहले से लागू वैल्यू को बदल देती है. अगर रिंग ऑपरेशन को 0x00 पर सेट किया जाता है, तो टाइम आउट को अनदेखा कर दिया जाता है.
3	uint8	आवाज़	0x00: डिफ़ॉल्ट 0x01: कम 0x02: मीडियम 0x03: ज़्यादा इन वैल्यू का सटीक मतलब, लागू किए जाने के तरीके पर निर्भर करता है.

अनुरोध मिलने पर, सेवा देने वाली कंपनी यह पुष्टि करती है कि:

• पुष्टि करने के लिए एक बार इस्तेमाल की गई कुंजी, रिंग की कुंजी से मेल खाती है.
• अनुरोध की गई स्थिति, रिंग करने वाले कॉम्पोनेंट से मेल खाती है.

अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो यह बिना पुष्टि वाली गड़बड़ी दिखाता है. हालांकि, अगर सेवा देने वाली कंपनी ने अनचाही ट्रैकिंग से सुरक्षा करने वाली सुविधा चालू की है और अनचाही ट्रैकिंग से सुरक्षा करने वाली सुविधा को ट्रिगर करने वाले अनुरोध में, रिंगिंग की पुष्टि करने वाले फ़्लैग को स्किप करने की सुविधा चालू है, तो सेवा देने वाली कंपनी को उस जांच को स्किप करना चाहिए. प्रमाणीकरण का डेटा अब भी Seeker को देना होगा. हालांकि, इसे किसी भी वैल्यू पर सेट किया जा सकता है.

रिंगिंग शुरू होने या बंद होने पर, टेबल 6 में दी गई जानकारी के मुताबिक सूचना भेजी जाती है. इसमें डेटा आईडी 0x05 होता है. सूचना में मौजूद कॉन्टेंट के बारे में यहां बताया गया है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	रिंगिंग की स्थिति	0x00: Started 0x01: शुरू या बंद नहीं किया जा सका (अनुरोध किए गए सभी कॉम्पोनेंट, रेंज से बाहर हैं) 0x02: बंद हो गया (टाइम आउट) 0x03: बंद किया गया (बटन दबाकर) 0x04: Stopped (GATT request)
1	uint8	घंटी बजने से जुड़े कॉम्पोनेंट	अनुरोध में तय किए गए, ऐक्टिव तौर पर बज रहे कॉम्पोनेंट का बिटमास्क.
2 - 3	uint16	टाइम आउट की संख्या	घंटी बजने का बचा हुआ समय, डेसीसेकंड में. अगर डिवाइस की घंटी बजना बंद हो गई है, तो 0x0000 वैल्यू दिखनी चाहिए.

प्रमाणीकरण सेगमेंट, HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

अगर डिवाइस पहले से ही रिंग हो रहा है और रिंग करने या बंद करने का अनुरोध मिलता है, तो सेवा देने वाली कंपनी को रिंग होने की स्थिति के साथ एक सूचना भेजनी चाहिए. इसके अलावा, GATT अनुरोध के लिए 0x00: शुरू किया गया या 0x04: बंद किया गया में से कोई एक सूचना भेजनी चाहिए. यह अनुरोध, मौजूदा स्थिति के पैरामीटर को बदल देता है, ताकि रिंग होने की अवधि बढ़ाई जा सके.

अगर डिवाइस में कोई बटन है या उसमें टच सेंसर की सुविधा चालू है, तो कॉल आने पर बजने वाली घंटी को बंद करने के लिए, उस बटन को दबाया जा सकता है.

बीकन के बजने की स्थिति पाना

बीकन की रिंगिंग की स्थिति पाने के लिए, सीक करने वाला डिवाइस, विशेषता पर राइट ऑपरेशन करता है. इसमें टेबल 4 से मिला अनुरोध शामिल होता है. इसका डेटा आईडी 0x06 होता है. Provider यह पुष्टि करता है कि दी गई सिर्फ़ एक बार के लिए मान्य पुष्टि करने वाली कुंजी, रिंग की कुंजी से मेल खाती है.

अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो सेवा देने वाली कंपनी पुष्टि नहीं होने की गड़बड़ी दिखाती है.

अनुरोध पूरा होने पर, सेवा देने वाली कंपनी, टेबल 6 से मिले जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x06 होता है. सेवा देने वाली कंपनी, डेटा सेगमेंट को इस तरह से बनाती है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	घंटी बजने से जुड़े कॉम्पोनेंट	रिंगिंग के अनुरोध में बताए गए कॉम्पोनेंट, जो ऐक्टिव तौर पर रिंग कर रहे हैं.
1 - 2	uint16	टाइम आउट की संख्या	घंटी बजने का बचा हुआ समय, डेसीसेकंड में. ध्यान दें कि अगर डिवाइस की घंटी नहीं बज रही है, तो 0000 वापस भेजा जाना चाहिए.

प्रमाणीकरण सेगमेंट, HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

अनचाही ट्रैकिंग से सुरक्षा का मोड

अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड का मकसद, किसी भी क्लाइंट को सर्वर से कम्यूनिकेट किए बिना, डिवाइसों का गलत इस्तेमाल करने वालों की पहचान करने की सुविधा देना है. डिफ़ॉल्ट रूप से, सेवा देने वाली कंपनी को सभी आइडेंटिफ़ायर को रोटेट करना चाहिए, जैसा कि आईडी रोटेशन में बताया गया है. Find Hub सेवा, Find Hub नेटवर्क के ज़रिए, अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड को चालू करने का अनुरोध भेज सकती है. ऐसा करने से, सेवा देने वाली कंपनी कुछ समय के लिए एक निश्चित MAC पते का इस्तेमाल करती है. इससे क्लाइंट को डिवाइस का पता लगाने और उपयोगकर्ता को अनचाही ट्रैकिंग के बारे में चेतावनी देने की अनुमति मिलती है.

बीकन के अनचाहे ट्रैकिंग से सुरक्षा मोड को चालू या बंद करने के लिए, Seeker, विशेषता पर लिखने की कार्रवाई करता है. इसमें टेबल 5 से किया गया अनुरोध शामिल होता है. इसका डेटा आईडी क्रमशः 0x07 या 0x08 होता है.

अनचाही ट्रैकिंग से सुरक्षा देने वाला मोड चालू करने पर

डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह बनाती है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	कंट्रोल फ़्लैग <0x0	0x01: रिंगिंग की पुष्टि करने की प्रोसेस छोड़ें. इस सेटिंग को चालू करने पर, अवांछित ट्रैकिंग से सुरक्षा मोड में होने पर, रिंगिंग के अनुरोधों की पुष्टि नहीं की जाती. अगर कोई फ़्लैग सेट नहीं किया जा रहा है (बाइट पूरी तरह से शून्य है), तो डेटा सेक्शन को पूरी तरह से हटाया जा सकता है और खाली डेटा सेक्शन भेजा जा सकता है. ये फ़्लैग सिर्फ़ तब तक लागू होते हैं, जब तक ट्रैकिंग सुरक्षा के अनचाहे मोड को बंद नहीं किया जाता.

सेवा देने वाली कंपनी यह पुष्टि करती है कि एक बार इस्तेमाल की जाने वाली पुष्टि करने वाली कुंजी, अनचाही ट्रैकिंग से सुरक्षा देने वाली कुंजी से मेल खाती है. अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो यह पुष्टि नहीं होने की गड़बड़ी दिखाता है.

जब ट्रैकिंग सुरक्षा का अनचाहा मोड चालू होता है, तो बीकन को हर 24 घंटे में एक बार, MAC के निजी पते को रोटेट करने की फ़्रीक्वेंसी को कम करना चाहिए. विज्ञापन में शामिल किए गए कुछ समय के लिए मान्य आइडेंटिफ़ायर को हमेशा की तरह रोटेट करते रहना चाहिए. फ़्रेम टाइप को 0x41 पर सेट किया जाना चाहिए. यह स्थिति, हैश किए गए फ़्लैग सेक्शन में भी दिखती है.

अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड को बंद करते समय

सेवा देने वाली कंपनी पुष्टि करती है कि:

• दी गई पुष्टि करने की कुंजी, अनचाही ट्रैकिंग से सुरक्षा देने वाली कुंजी से मेल खाती है.
• हैश की गई कुछ समय के लिए इस्तेमाल होने वाली पहचान कुंजी, कुछ समय के लिए इस्तेमाल होने वाली मौजूदा पहचान कुंजी से मेल खाती है.

अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो सेवा देने वाली कंपनी, पुष्टि नहीं होने की गड़बड़ी का मैसेज दिखाती है.

अनचाहे ट्रैकिंग सुरक्षा मोड को बंद करने पर, बीकन को सामान्य दर पर फिर से मैक पते को रोटेट करना चाहिए. यह काम, कुछ समय के लिए इस्तेमाल होने वाले आइडेंटिफ़ायर के रोटेशन के साथ सिंक होना चाहिए. फ़्रेम टाइप को वापस 0x40 पर सेट किया जाना चाहिए. यह स्थिति, हैश किए गए फ़्लैग सेक्शन में भी दिखती है.

अनुरोध पूरा होने पर, प्रोवाइडर टेबल 6 से मिले जवाब के साथ सूचना देता है. इसमें डेटा आईडी 0x07 या 0x08 होता है.

प्रमाणीकरण सेगमेंट, HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) के पहले 8 बाइट के तौर पर तय किया जाता है.

सटीक तरीके से ढूंढने की सुविधा

इस सेक्शन में, सटीक नतीजे पाने के लिए ज़रूरी फ़्लो और अन्य कार्रवाइयों के बारे में बताया गया है. GATT की विशेषता और पुष्टि करने के लिए, यहां वही नियम लागू होते हैं जो GATT के निर्देश वाले सेक्शन में बताए गए हैं. सटीक जगह की जानकारी देने वाली सुविधा का इस्तेमाल करना ज़रूरी नहीं है.

खोई हुई चीज़ों की जगह की सटीक जानकारी का पता लगाने की सुविधा, रेंजिंग टेक्नोलॉजी पर निर्भर करती है. यह टेक्नोलॉजी, खोई हुई चीज़ों की जगह की सटीक जानकारी का पता लगाने के लिए इस्तेमाल किए जाने वाले डिवाइसों पर काम करती है. रेंजिंग टेक्नोलॉजी के बारे में जानने के लिए, रेंजिंग: आउट-ऑफ़-बैंड मैसेज सीक्वेंस और पेलोड स्पेसिफ़िकेशन देखें. बाद के सेक्शन में बताया गया है कि इस्तेमाल की गई रेंजिंग टेक्नोलॉजी के आधार पर, खोई हुई चीज़ों की जगह की सटीक जानकारी का पता लगाने की सुविधा किस तरह काम करती है.

Precision Finding की सुविधा का इस्तेमाल करने का तरीका

इस सेक्शन में, सटीक जगह ढूंढने की सुविधा के लिए, FHNA मैसेज फ़्लो के बारे में बताया गया है. पहले फ़िगर में मैसेज फ़्लो दिखाया गया है. साथ ही, पैराग्राफ़ में हर मैसेज के बारे में ज़्यादा जानकारी दी गई है.

पहली इमेज में, सटीक जगह की जानकारी पाने की सुविधा के लिए मैसेज फ़्लो दिखाया गया है

शुरुआत करने वाला डिवाइस वह डिवाइस होता है जिसमें Find Hub ऐप्लिकेशन इंस्टॉल होता है और जिसमें सटीक जगह की जानकारी पाने की सुविधा चालू होती है. शुरुआत करने वाला डिवाइस वह डिवाइस होता है जो दूसरे डिवाइस को ढूंढने की कोशिश कर रहा होता है.

रेस्पॉन्डर डिवाइस वह डिवाइस होता है जिसे इनीशिएटर डिवाइस ढूंढने की कोशिश कर रहा होता है.

शुरुआत करने वाला डिवाइस, जवाब देने वाले डिवाइस को रेंजिंग की सुविधा के बारे में अनुरोध करने वाला मैसेज भेजता है. इसमें रेंजिंग की उन टेक्नोलॉजी की सूची होती है जिनके बारे में वह जवाब देने वाले डिवाइस से जानना चाहता है. जवाब देने वाला डिवाइस, रेंजिंग की सुविधा के बारे में जवाब देने वाली सूचना भेजता है. इसमें रेंजिंग की उन टेक्नोलॉजी के बारे में जानकारी होती है जो काम करती हैं और उनकी क्षमताएं क्या हैं. जवाब देने वाला डिवाइस, सिर्फ़ वह जानकारी शामिल करेगा जिसका अनुरोध शुरुआत करने वाले डिवाइस ने किया है. क्षमताओं की सूची को, जवाब देने वाले डिवाइस की पसंदीदा रेंजिंग टेक्नोलॉजी की प्राथमिकता के आधार पर क्रम से लगाया जाएगा. सूची में सबसे ऊपर मौजूद टेक्नोलॉजी की प्राथमिकता सबसे ज़्यादा होगी.

इसके बाद, शुरू करने वाला डिवाइस, रेंजिंग कॉन्फ़िगरेशन मैसेज भेजेगा. इसमें, वह हर रेंजिंग टेक्नोलॉजी के लिए कॉन्फ़िगरेशन तय करेगा जिसके साथ उसे रेंजिंग करनी है. यह मैसेज मिलने के बाद, रेस्पॉन्डर डिवाइस को दिए गए कॉन्फ़िगरेशन का इस्तेमाल करके, लागू होने वाली टेक्नोलॉजी के लिए रेंजिंग शुरू करनी होगी. जवाब देने वाला डिवाइस, रेंजिंग कॉन्फ़िगरेशन के जवाब की सूचना वापस भेजेगा. इसमें यह जानकारी होगी कि रेंजिंग की हर टेक्नोलॉजी सही तरीके से शुरू हुई है या नहीं. रेंजिंग की कुछ टेक्नोलॉजी को, रेंजिंग सेशन को पूरा करने के लिए, इनीशिएटर और रेस्पॉन्डर, दोनों डिवाइसों पर चालू करना होता है. वहीं, कुछ टेक्नोलॉजी के लिए, इसे सिर्फ़ इनीशिएटर डिवाइस पर चालू करना ज़रूरी होता है. हालांकि, रेस्पॉन्डर डिवाइस को ऐसी टेक्नोलॉजी के लिए, रेंजिंग सेशन पूरा होने का जवाब देना होता है. रेंजिंग टेक्नोलॉजी के खास व्यवहार के बारे में ज़्यादा जानकारी, बाद के सेक्शन में दी गई है.

जब खोजने वाले डिवाइस को सटीक जगह की जानकारी पाने की सुविधा वाला सेशन बंद करना होता है, तो वह जवाब देने वाले डिवाइस को 'रेंजिंग बंद करें' मैसेज भेजता है. इससे यह पता चलता है कि किन रेंजिंग टेक्नोलॉजी को रेंजिंग बंद करनी चाहिए. जवाब देने वाला डिवाइस, StopRangingResponse सूचना के साथ जवाब देगा. इससे पता चलेगा कि उसने अनुरोध की गई रेंजिंग टेक्नोलॉजी के साथ रेंजिंग को बंद कर दिया है.

अगर सटीक जगह की जानकारी पाने के सेशन के बीच में, FHNA BLE GATT कम्यूनिकेशन चैनल डिसकनेक्ट हो जाता है, लेकिन कुछ रेंजिंग टेक्नोलॉजी अब भी रेंजिंग कर रही हैं, तो जवाब देने वाला डिवाइस टाइमआउट मैकेनिज़्म लागू करेगा. इससे यह पक्का किया जा सकेगा कि वह हमेशा के लिए रेंजिंग न करे. जानकारी, इस्तेमाल के हर उदाहरण पर निर्भर करेगी.

ध्यान दें कि जवाब देने वाले डिवाइस को यह नहीं मानना चाहिए कि कार्रवाइयों का क्रम हमेशा एक जैसा होगा. उदाहरण के लिए, जवाब देने वाले डिवाइस में एक के बाद एक, रेंजिंग की सुविधा से जुड़े कई अनुरोधों को प्रोसेस करने की क्षमता होनी चाहिए. इसके अलावा, इसमें रेंजिंग की सुविधा से जुड़े अनुरोध से पहले ही, रेंजिंग कॉन्फ़िगरेशन से जुड़े अनुरोध को प्रोसेस करने की क्षमता भी होनी चाहिए.

Precision Finding Operations

टेबल 8 में, इस दस्तावेज़ में बताई गई FHNA की कार्रवाइयां दिखाई गई हैं. ये कार्रवाइयां, सटीक तरीके से ढूंढने की सुविधा के लिए ज़रूरी हैं. हर सब-सेक्शन में, हर ऑपरेशन के लिए FHNA मैसेज के बारे में बताया गया है. वहीं, अतिरिक्त डेटा फ़ील्ड का कॉन्टेंट, रेंजिंग: आउट-ऑफ़-बैंड मैसेज सीक्वेंस और पेलोड स्पेसिफ़िकेशन के बारे में बताता है.

कार्रवाई	डेटा आईडी	ब्यौरा
रेंजिंग की सुविधा के लिए अनुरोध	0x0A	यह क्षमता के लिए अनुरोध करने की कार्रवाई है. इसे अनुरोध करने वाला डिवाइस, जवाब देने वाले डिवाइस को भेजेगा. इस ऑपरेशन के डेटा कॉन्टेंट में, रेंजिंग की उन सभी टेक्नोलॉजी की सूची दी जाएगी जिनके बारे में Initiator को Responder डिवाइस से जानकारी चाहिए.
Ranging Capability Response	0x0A	यह रेंजिंग की सुविधा के अनुरोध के जवाब में भेजी गई सूचना है. इसमें रेंजिंग की सुविधा के लिए काम करने वाली हर टेक्नोलॉजी के बारे में जानकारी होती है. इस टेक्नोलॉजी के लिए, अनुरोध करने वाले व्यक्ति ने अनुरोध किया था.
रेंजिंग कॉन्फ़िगरेशन	0x0B	रेंजिंग कॉन्फ़िगरेशन ऑपरेशन में, रेंजिंग टेक्नोलॉजी के लिए कॉन्फ़िगरेशन शामिल होते हैं. ये वे टेक्नोलॉजी होती हैं जिनके साथ, इनीशिएटर डिवाइस, रेस्पॉन्डर डिवाइस के साथ रेंजिंग शुरू करना चाहता है.
रेंजिंग कॉन्फ़िगरेशन का जवाब	0x0B	यह रेंजिंग कॉन्फ़िगरेशन ऑपरेशन के लिए सूचना का जवाब है. इसमें यह जानकारी होती है कि क्या Responder डिवाइस, दिए गए कॉन्फ़िगरेशन के आधार पर, अनुरोध की गई रेंजिंग टेक्नोलॉजी के साथ रेंजिंग शुरू कर पाया है.
RFU	0x0C	इस डेटा आईडी का इस्तेमाल नहीं किया जाता है. इसे आने वाले समय में इस्तेमाल करने के लिए रिज़र्व किया गया है.
रेंजिंग बंद करें	0x0D	स्टॉप रेंजिंग ऑपरेशन, इनीशिएटर डिवाइस से भेजा जाता है. इसमें यह जानकारी होती है कि रिस्पॉन्डर डिवाइस को किन रेंजिंग टेक्नोलॉजी के साथ रेंजिंग बंद करनी है.
रेंजिंग रिस्पॉन्स बंद करें	0x0D	यह स्टॉप रेंजिंग ऑपरेशन के लिए सूचना का जवाब है. इसमें यह डेटा होता है कि रेंजिंग की किसी खास टेक्नोलॉजी के लिए स्टॉप ऑपरेशन पूरा हुआ या नहीं.

टेबल 8: सटीक जगह की जानकारी पाने की सुविधा से जुड़ी कार्रवाइयां.

Ranging Capability Request ऑपरेशन

टेबल 9 में, रेंजिंग की सुविधा के अनुरोध वाले मैसेज के बारे में बताया गया है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x0A - Ranging Capability Request operation
1	uint8	डेटा का साइज़	बदलता रहता है
2	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	यह एचएमएसी-एसएचए256(खाता कुंजी, प्रोटोकॉल का मेजर वर्शन नंबर || विशेषता से पढ़ा गया आखिरी नॉन्स || डेटा आईडी || डेटा की लंबाई || अतिरिक्त डेटा) के पहले 8 बाइट होते हैं.
10	बाइट अरे	अतिरिक्त डेटा	Ranging: Out-of-band message sequence and payload स्पेसिफ़िकेशन में बताए गए Ranging Capability Request मैसेज (हेडर और पेलोड, दोनों)

टेबल 9: रेंजिंग की सुविधा के लिए अनुरोध.

Ranging Capability Response ऑपरेशन

टेबल 10 में, रेंजिंग की सुविधा के बारे में जानकारी देने वाले मैसेज के बारे में बताया गया है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x0A: Ranging Capability Response
1	uint8	डेटा का साइज़	बदलता रहता है
2	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	यह HMAC-SHA256(खाता कुंजी, प्रोटोकॉल का मेजर वर्शन नंबर || विशेषता से पढ़ा गया आखिरी नॉन्स || डेटा आईडी || डेटा की लंबाई || अतिरिक्त डेटा || 0x01) के पहले 8 बाइट होते हैं.
10	बाइट अरे	अतिरिक्त डेटा	Ranging Capability Response मैसेज, जैसा कि Ranging: Out-of-band message sequence and payload स्पेसिफ़िकेशन (हेडर और पेलोड, दोनों) में बताया गया है

टेबल 10: रेंजिंग की क्षमता के बारे में जवाब.

रेंजिंग कॉन्फ़िगरेशन ऑपरेशन

टेबल 11 में, रेंजिंग कॉन्फ़िगरेशन मैसेज के बारे में बताया गया है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x0B - Set Ranging Configuration
1	uint8	डेटा का साइज़	बदलता रहता है
2	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	यह एचएमएसी-एसएचए256(खाता कुंजी, प्रोटोकॉल का मेजर वर्शन नंबर || विशेषता से पढ़ा गया आखिरी नॉन्स || डेटा आईडी || डेटा की लंबाई || अतिरिक्त डेटा) के पहले 8 बाइट होते हैं.
10	बाइट अरे	अतिरिक्त डेटा	Ranging Configuration मैसेज, जैसा कि Ranging: Out-of-band message sequence and payload स्पेसिफ़िकेशन (हेडर और पेलोड, दोनों) में बताया गया है

टेबल 11: रेंजिंग कॉन्फ़िगरेशन.

रेंजिंग कॉन्फ़िगरेशन के जवाब से जुड़ी कार्रवाई

टेबल 12 में, रेंजिंग कॉन्फ़िगरेशन के रिस्पॉन्स मैसेज के बारे में बताया गया है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x0B - Set Ranging Configuration Response
1	uint8	डेटा का साइज़	बदलता रहता है
2	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	यह HMAC-SHA256(खाता कुंजी, प्रोटोकॉल का मेजर वर्शन नंबर || विशेषता से पढ़ा गया आखिरी नॉन्स || डेटा आईडी || डेटा की लंबाई || अतिरिक्त डेटा || 0x01) के पहले 8 बाइट होते हैं.
10	बाइट अरे	अतिरिक्त डेटा	Ranging Configuration Response मैसेज, जैसा कि Ranging: Out-of-band message sequence and payload स्पेसिफ़िकेशन (हेडर और पेलोड, दोनों) में बताया गया है

टेबल 12: रेंजिंग कॉन्फ़िगरेशन रिस्पॉन्स.

रेंजिंग ऑपरेशन बंद करें

टेबल 13 में, स्टॉप रेंजिंग मैसेज के बारे में बताया गया है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x0D - रेंजिंग स्टॉप
1	uint8	डेटा का साइज़	बदलता रहता है
2	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	एचएमएसी-SHA256(खाता कुंजी, प्रोटोकॉल का मेजर वर्शन नंबर || विशेषता से पढ़ा गया आखिरी नॉन्स || डेटा आईडी || डेटा की लंबाई) के पहले 8 बाइट.
10	बाइट अरे	अतिरिक्त डेटा	Stop Ranging मैसेज, जैसा कि Ranging: Out-of-band message sequence and payload स्पेसिफ़िकेशन (हेडर और पेलोड, दोनों) में बताया गया है

टेबल 13: स्टॉप रेंजिंग.

रेंजिंग रिस्पॉन्स ऑपरेशन बंद करें

टेबल 14 में, स्टॉप रेंजिंग रिस्पॉन्स मैसेज के बारे में बताया गया है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x0D - Ranging Stop Response
1	uint8	डेटा का साइज़	बदलता रहता है
2	बाइट अरे	पुष्टि के लिए एक बार इस्तेमाल की जाने वाली कुंजी	यह HMAC-SHA256(खाता कुंजी, प्रोटोकॉल का मेजर वर्शन नंबर || विशेषता से पढ़ा गया आखिरी नॉन्स || डेटा आईडी || डेटा की लंबाई || अतिरिक्त डेटा || 0x01) के पहले 8 बाइट होते हैं.
10	बाइट अरे	अतिरिक्त डेटा	Ranging: Out-of-band message sequence and payload स्पेसिफ़िकेशन में बताए गए Stop Ranging Response मैसेज (हेडर और पेलोड, दोनों)

टेबल 14: स्टॉप रेंजिंग रिस्पॉन्स.

रास्ते की सटीक जानकारी देने वाली सुविधा के साथ अनचाही ट्रैकिंग से सुरक्षा

जब अनचाही ट्रैकिंग से सुरक्षा का मोड चालू होता है, तब अनचाही ट्रैकिंग से सुरक्षा वाले सेक्शन में बताए गए तरीके के मुताबिक, रिंग करने वाले मैसेज के लिए पुष्टि की जांच को स्किप करने का तरीका, इस सुविधा के साथ काम करने वाले डिवाइसों के लिए, इस दस्तावेज़ में बताए गए सभी सटीक ढूंढने वाले मैसेज पर भी लागू होता है.

Precision Finding के लिए, रेंजिंग टेक्नोलॉजी के बारे में खास जानकारी

इस सेक्शन में, टेक्नोलॉजी से जुड़ी जानकारी होती है.

अल्ट्रा-वाइडबैंड (यूडब्ल्यूबी) की खास बातें

UWB के बारे में खास जानकारी.

सटीक जगह की जानकारी पाने की सुविधा का लेवल

रेंजिंग टेक्नोलॉजी के तौर पर यूडब्ल्यूबी का इस्तेमाल करने वाले सटीक जगह की जानकारी ढूंढने की सुविधा के सेशन में, दूरी और दिशा, दोनों की जानकारी दिख सकती है. रेंजिंग इंटरवल कम से कम 240 मि॰से॰ होना चाहिए. हालांकि, बेहतर तरीके से दिशा-निर्देश पाने के लिए, 96 मि॰से॰ का इंटरवल इस्तेमाल करने का सुझाव दिया जाता है.

कॉन्फ़िगरेशन आईडी

यू डब्ल्यूबी के लिए, आउट-ऑफ़-बैंड कॉन्फ़िगरेशन के लिए एक्सचेंज किए गए डेटा में, कॉन्फ़िगर किए जा सकने वाले सभी पैरामीटर का पूरा सेट मौजूद नहीं है. यू डब्ल्यूबी को यू डब्ल्यूबी रेंजिंग सेशन शुरू करने के लिए, इन पैरामीटर की ज़रूरत होती है. चुने गए कॉन्फ़िगरेशन आईडी के हिसाब से, कुछ पैरामीटर अपने-आप चुने जाते हैं.

हर कॉन्फ़िगरेशन आईडी, पहले से तय किए गए यूडब्ल्यूबी कॉन्फ़िगरेशन पैरामीटर का एक सेट होता है. इसे सार्वजनिक तौर पर उपलब्ध दस्तावेज़ों में शामिल किया जाता है. सटीक जगह की जानकारी ढूंढने की सुविधा के लिए, जवाब देने वाले डिवाइस में कॉन्फ़िगरेशन आईडी 6 का इस्तेमाल किया जाना चाहिए. साथ ही, कॉन्फ़िगरेशन आईडी 3 का इस्तेमाल करना ज़रूरी नहीं है.

यूडब्ल्यूबी की सुविधा शुरू करने और जवाब देने वाला डिवाइस

सटीक जगह की जानकारी ढूंढने की सुविधा के लिए, इस दस्तावेज़ में जिस डिवाइस को शुरू करने वाला डिवाइस बताया गया है वह यूडब्ल्यूबी रेस्पॉन्डर होगा. साथ ही, इस दस्तावेज़ में जिस डिवाइस को रेस्पॉन्डर डिवाइस बताया गया है वह यूडब्ल्यूबी शुरू करने वाला डिवाइस होगा. ऐसा इसलिए है, क्योंकि यूडब्ल्यूबी की सुविधा शुरू करने वाले डिवाइस में, यूडब्ल्यूबी की सुविधा का जवाब देने वाले डिवाइस की तुलना में कम बैटरी खर्च होती है. साथ ही, ज़्यादातर मामलों में, जवाब देने वाला डिवाइस एक ऐसा पेरिफ़ेरल होगा जिसमें बैटरी सीमित होगी.

इसका मतलब है कि रेंजिंग केपबिलिटी रिस्पॉन्स मैसेज में, जवाब देने वाले डिवाइस को यह बताना होगा कि वह यूडब्ल्यूबी इनिशिएटर की भूमिका निभा सकता है.

यूडब्ल्यूबी से जुड़े अन्य पैरामीटर

• Channel 9 का इस्तेमाल किया जा सकता हो
• बेहतर मार्गदर्शन के लिए, 96 मि॰से॰ की रेंजिंग इंटरवल का सुझाव दिया जाता है. अगर ऐसा नहीं होता है, तो 240 मि॰से॰ का इंटरवल होना ज़रूरी है.
• बैटरी बचाने के लिए, स्लॉट की अवधि 1 मि॰से॰ रखने का सुझाव दिया जाता है. हालांकि, 2 मि॰से॰ की अवधि भी इस्तेमाल की जा सकती है.
• UWB चिप, कम से कम FIRA v1.2 + P-STS के मुताबिक होनी चाहिए.
• बीपीआरएफ़ ज़रूरी है. एचपीआरएफ़ का इस्तेमाल करने का सुझाव दिया जाता है, लेकिन यह ज़रूरी नहीं है. सपोर्ट किए गए या चुने गए मोड का पता, सपोर्ट किए गए या चुने गए प्रीऐंबल इंडेक्स से चलता है.
• सेशन की सुरक्षा का टाइप: P-STS

BLE चैनल साउंडिंग (सीएस) के बारे में खास जानकारी

BLE CS के बारे में खास जानकारी.

सटीक जगह की जानकारी पाने की सुविधा का लेवल

सीएस को रेंजिंग टेक्नोलॉजी के तौर पर इस्तेमाल करने वाले सटीक जानकारी देने वाले फ़ाइंडिंग सेशन से, सिर्फ़ दूरी का पता चलेगा. फ़िलहाल, दिशा की जानकारी नहीं दी जाती है.

डिवाइसों के बीच बॉन्ड होना ज़रूरी है

अगर डिवाइसों को एक-दूसरे से नहीं जोड़ा गया है, तो चैनल साउंडिंग का इस्तेमाल करके, खोई हुई चीज़ों की जगह की सटीक जानकारी का पता लगाने वाली सुविधा काम नहीं करेगी. अनुरोध करने वाले और जवाब देने वाले डिवाइस के बीच पहले से कोई बॉन्ड होना ज़रूरी है. इस स्पेसिफ़िकेशन में, डिवाइसों के बीच बॉन्ड बनाने का कोई तरीका नहीं बताया गया है. इसके बजाय, इस्तेमाल के उदाहरण के डेवलपर को डिवाइसों के बीच यह बॉन्ड बनाना होता है.

सीएस के लिए, जवाब देने वाले पक्ष को कार्रवाई करनी होगी

यूडब्ल्यूबी में, दोनों डिवाइसों को यूडब्ल्यूबी स्टार्ट रेंजिंग और स्टॉप रेंजिंग एपीआई को साफ़ तौर पर कॉल करना होता है. हालांकि, सीएस के लिए, सिर्फ़ शुरू करने वाले डिवाइस को ब्लूटूथ स्टैक को कॉल करके सीएस रेंजिंग शुरू करनी होती है. जवाब देने वाले डिवाइस पर बाकी इनिशियलाइज़ेशन, ब्लूटूथ (बीटी) का इस्तेमाल करके इन-बैंड में होता है. इसका मतलब है कि सीएस के लिए रेंजिंग कॉन्फ़िगरेशन मैसेज या स्टॉप रेंजिंग मैसेज मिलने पर, अगर बीटी चालू है, तो जवाब देने वाले डिवाइस को कुछ भी करने की ज़रूरत नहीं है. उसे सिर्फ़ रेंजिंग कॉन्फ़िगरेशन रिस्पॉन्स मैसेज की सूचना देनी होती है. जवाब देने वाला डिवाइस, उन मैसेज का इस्तेमाल यूआई को अपडेट करने के लिए ट्रिगर के तौर पर कर सकता है. यूआई में स्क्रीन मौजूद होती है. इसके अलावा, स्क्रीन मौजूद न होने पर भी, डिवाइस की स्थिति के बारे में विज़ुअल फ़ीडबैक देने के लिए इसका इस्तेमाल किया जा सकता है. उदाहरण के लिए, डिवाइस के एलईडी को ब्लिंक करना.

वाई-फ़ाई एनएएन आरटीटी

वाई-फ़ाई एनएएन आरटीटी के बारे में खास जानकारी.

सटीक जगह की जानकारी पाने की सुविधा का लेवल

रेंजिंग टेक्नोलॉजी के तौर पर वाई-फ़ाई एनएएन आरटीटी का इस्तेमाल करने वाले सटीक जगह ढूंढने की सुविधा के सेशन में, सिर्फ़ दूरी का मेज़रमेंट किया जाएगा. फ़िलहाल, दिशा की जानकारी नहीं दी जाती है.

BLE RSSI

BLE RSSI के बारे में खास जानकारी.

सटीक जगह की जानकारी पाने की सुविधा का लेवल

सिर्फ़ BLE RSSI का इस्तेमाल करके सटीक तरीके से ढूंढने की सुविधा वाले सेशन में, दूरी या दिशा की जानकारी नहीं मिल पाएगी. ऐसा इसलिए, क्योंकि BLE RSSI, दूरी का सटीक अनुमान लगाने वाली टेक्नोलॉजी नहीं है. इसके बजाय, उपयोगकर्ता को यह जानकारी दिखेगी कि डिवाइस आस-पास है या दूर है.

विज्ञापन वाले फ़्रेम

प्रोविज़निंग के बाद, सेवा देने वाली कंपनी को हर दो सेकंड में कम से कम एक बार, FHN फ़्रेम का विज्ञापन दिखाना होगा. अगर फ़ास्ट पेयर फ़्रेम का विज्ञापन दिखाया जाता है, तो सेवा देने वाली कंपनी को फ़ास्ट पेयर के सामान्य विज्ञापनों में, FHN फ़्रेम को इंटरलीव करना चाहिए. उदाहरण के लिए, हर दो सेकंड में, सेवा देने वाली कंपनी को सात Fast Pair विज्ञापन और एक FHN विज्ञापन दिखाना चाहिए.

FHN विज्ञापनों के लिए, ब्लूटूथ ट्रांसमिट पावर को कम से कम 0 dBm पर सेट किया जाना चाहिए.

एफ़एचएन फ़्रेम में एक सार्वजनिक पासकोड होता है. इसका इस्तेमाल, लोकेशन की रिपोर्ट को एन्क्रिप्ट (सुरक्षित) करने के लिए किया जाता है. ऐसा कोई भी क्लाइंट कर सकता है जो क्राउडसोर्सिंग नेटवर्क में योगदान देता है. एलिप्टिक कर्व वाले दो तरह के कुंजियां उपलब्ध हैं: 160-बिट की कुंजी, जो लेगसी BLE 4 फ़्रेम के साथ काम करती है या 256-बिट की कुंजी, जिसके लिए एक्सटेंडेड विज्ञापन क्षमताओं के साथ BLE 5 की ज़रूरत होती है. Provider's implementation से यह तय होता है कि कौनसा कर्व इस्तेमाल किया जाएगा.

एफ़एचएन फ़्रेम का स्ट्रक्चर इस तरह होता है.

ऑक्टेट	मान	ब्यौरा
0	0x02	लंबाई
1	0x01	फ़्लैग किए गए डेटा टाइप की वैल्यू
2	0x06	फ़्लैग डेटा
3	0x18 या 0x19	लंबाई
4	0x16	सेवा के डेटा के डेटा टाइप की वैल्यू
5	0xAA	16-बिट वाला सेवा यूयूआईडी
6	0xFE	...
7	0x40 या 0x41	FHN फ़्रेम टाइप, जिसमें ट्रैकिंग सुरक्षा मोड की अनचाही जानकारी दी गई है
8..27		20 बाइट का कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर
28		हैश किए गए फ़्लैग

टेबल 15: 160-बिट कर्व के साथ काम करने वाला FHN फ़्रेम.

टेबल 16 में, 256-बिट वाले कर्व के लिए बाइट ऑफ़सेट और वैल्यू दिखाई गई हैं.

ऑक्टेट	मान	ब्यौरा
0	0x02	लंबाई
1	0x01	फ़्लैग किए गए डेटा टाइप की वैल्यू
2	0x06	फ़्लैग डेटा
3	0x24 या 0x25	लंबाई
4	0x16	सेवा के डेटा के डेटा टाइप की वैल्यू
5	0xAA	16-बिट वाला सेवा यूयूआईडी
6	0xFE	...
7	0x40 या 0x41	FHN फ़्रेम टाइप, जिसमें ट्रैकिंग सुरक्षा मोड की अनचाही जानकारी दी गई है
8..39		32 बाइट का कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर
40		हैश किए गए फ़्लैग

टेबल 16: 256-बिट कर्व के साथ काम करने वाला FHN फ़्रेम.

कुछ समय के लिए मान्य आइडेंटिफ़ायर (ईआईडी) का हिसाब लगाना

AES-ECB-256 की मदद से, इस डेटा स्ट्रक्चर को एन्क्रिप्ट (सुरक्षित) करके एक रैंडम नंबर जनरेट किया जाता है. इसके लिए, पहचान की कुछ समय के लिए इस्तेमाल होने वाली कुंजी का इस्तेमाल किया जाता है:

ऑक्टेट	फ़ील्ड	ब्यौरा
0 - 10	पैडिंग (जगह)	Value = 0xFF
11	K	रोटेशन पीरियड एक्स्पोनेंट
12 - 15	TS[0]...TS[3]	यह बीकन टाइम काउंटर है. यह 32-बिट बिग-एंडियन फ़ॉर्मैट में होता है. इसमें K सबसे कम बिट मिटा दिए जाते हैं.
16 - 26	पैडिंग (जगह)	Value = 0x00
27	K	रोटेशन पीरियड एक्स्पोनेंट
28 - 31	TS[0]...TS[3]	यह बीकन टाइम काउंटर है. यह 32-बिट बिग-एंडियन फ़ॉर्मैट में होता है. इसमें K सबसे कम बिट मिटा दिए जाते हैं.

टेबल 17: छद्म यादृच्छिक संख्या बनाना.

इस कैलकुलेशन का नतीजा 256-बिट नंबर होता है, जिसे r' के तौर पर दिखाया जाता है.

बाकी कैलकुलेशन के लिए, SECP160R1 या SECP256R1 का इस्तेमाल, एलिप्टिक कर्व क्रिप्टोग्राफ़िक ऑपरेशनों के लिए किया जाता है. SEC 2: Recommended Elliptic Curve Domain Parameters में कर्व की परिभाषाएं देखें. इसमें Fp, n, और G की परिभाषाएं दी गई हैं. इनके बारे में आगे बताया गया है.

r' को अब r = r' mod n कैलकुलेट करके, फ़ाइनल फ़ील्ड Fp में प्रोजेक्ट किया जाता है. आखिर में, R = r * G का हिसाब लगाएं. यह कर्व पर मौजूद एक पॉइंट है, जो इस्तेमाल की जा रही सार्वजनिक पासकोड को दिखाता है. बीकन, Rx का विज्ञापन दिखाता है. यह R का x कोऑर्डिनेट है. इसे बीकन के कुछ समय के लिए उपलब्ध आइडेंटिफ़ायर के तौर पर इस्तेमाल किया जाता है.

हैश किए गए फ़्लैग

हैश किए गए फ़्लैग फ़ील्ड का हिसाब इस तरह लगाया जाता है (बिट सबसे अहम से लेकर सबसे कम अहम तक के क्रम में होते हैं):

• बिट 0-4: आरक्षित (शून्य पर सेट किए गए).
• पांचवें और छठे बिट से, डिवाइस के बैटरी लेवल के बारे में पता चलता है. जैसे:
  • 00: बैटरी लेवल दिखाने की सुविधा काम नहीं करती
  • बैटरी लेवल सामान्य है
  • 10: बैटरी लेवल कम है
  • 11: बैटरी का लेवल बहुत कम है (बैटरी को जल्द ही बदलना होगा)
• अगर बीकन, ट्रैकिंग सुरक्षा के अनचाहे मोड में है, तो बिट 7 को 1 पर सेट किया जाता है. अगर ऐसा नहीं है, तो इसे 0 पर सेट किया जाता है.

इस बाइट की फ़ाइनल वैल्यू बनाने के लिए, इसे SHA256(r) के सबसे कम अहम बाइट के साथ xor किया जाता है.

ध्यान दें कि r को कर्व के साइज़ के हिसाब से अलाइन किया जाना चाहिए. अगर इसका प्रज़ेंटेशन 160 या 256 बिट से छोटा है, तो सबसे अहम बिट के तौर पर शून्य जोड़ें. अगर इसका प्रज़ेंटेशन 160 या 256 बिट से बड़ा है, तो सबसे अहम बिट को छोटा किया जाना चाहिए.

अगर बीकन, बैटरी लेवल की जानकारी देने की सुविधा के साथ काम नहीं करता है और वह अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड में नहीं है, तो उसे विज्ञापन से इस बाइट को पूरी तरह से हटाने की अनुमति है.

ईआईडी की मदद से एन्क्रिप्शन

किसी मैसेज को एन्क्रिप्ट करने के लिए m, साइट पर मौजूद व्यक्ति (जिसने बीकन से Rx पढ़ा है) यह तरीका अपनाएगा:

1. ईआईडी कैलकुलेट करने के तरीके सेक्शन में बताए गए तरीके के मुताबिक, s में से कोई भी रैंडम नंबर Fp चुनें.
2. कंप्यूट S = s * G.
3. कर्व के समीकरण में वैल्यू डालकर R = (Rx, Ry) की वैल्यू का हिसाब लगाएं. साथ ही, संभावित नतीजों में से कोई भी Ry वैल्यू चुनें.
4. 256-बिट वाली AES कुंजी k = HKDF-SHA256((s * R)x) की गणना करें. इसमें (s * R)x, कर्व मल्टिप्लिकेशन के नतीजे का x कोऑर्डिनेट है. सॉल्ट की जानकारी नहीं दी गई है.
5. मान लें कि URx और LRx, बिग-एंडियन फ़ॉर्मैट में Rx के ऊपरी और निचले 80 बिट हैं. इसी तरह, S के लिए USx और LSx तय करें.
6. कंप्यूट nonce = LRx || LSx.
7. कंप्यूट (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
8. मालिक को (URx, Sx, m’, tag) भेजें. ऐसा हो सकता है कि यह काम किसी ऐसी रिमोट सेवा के ज़रिए किया जा रहा हो जिस पर भरोसा नहीं किया जा सकता.

ईआईडी का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) की गई वैल्यू को डिक्रिप्ट (सुरक्षित तरीके से बदलना) करना

मालिक का क्लाइंट, जिसके पास EIK और रोटेशन पीरियड का एक्सपोनेंट होता है, मैसेज को इस तरह डिक्रिप्ट करता है:

1. URx दिए जाने पर, बीकन टाइम काउंटर की वह वैल्यू पाएं जिस पर URx आधारित है. ऐसा, मालिक के क्लाइंट कंप्यूटिंग Rx की वैल्यू के आधार पर किया जा सकता है. इसके लिए, हाल ही के समय और आने वाले समय के लिए बीकन टाइम काउंटर की वैल्यू का इस्तेमाल किया जाता है.
2. URx जिस बीकन टाइम काउंटर वैल्यू पर आधारित है उसे देखते हुए, r की अनुमानित वैल्यू का हिसाब लगाएं. यह वैल्यू, ईआईडी के हिसाब लगाने वाले सेक्शन में बताई गई है.
3. R = r * G की गिनती करें और पुष्टि करें कि यह, देखने वाले व्यक्ति या कंपनी के दिए गए URx की वैल्यू से मेल खाता है.
4. कर्व के समीकरण में वैल्यू डालकर S = (Sx, Sy) की वैल्यू का हिसाब लगाएं. साथ ही, संभावित नतीजों में से कोई भी Sy वैल्यू चुनें.
5. k = HKDF-SHA256((r * S)x) की गणना करें, जहां (r * S)x, कर्व मल्टिप्लिकेशन के नतीजे का x कोऑर्डिनेट है.
6. कंप्यूट nonce = LRx || LSx.
7. कंप्यूट m = AES-EAX-256-DEC(k, nonce, m’, tag).

आईडी रोटेशन

FHN फ़्रेम का विज्ञापन दिखाने के लिए, हल किया जा सकने वाला (आरपीए) या हल नहीं किया जा सकने वाला (एनआरपीए) BLE पता इस्तेमाल किया जाना चाहिए. LE Audio (LEA) डिवाइसों के लिए, आरपीए ज़रूरी है. साथ ही, इसे अन्य डिवाइसों के लिए भी इस्तेमाल करने का सुझाव दिया जाता है. हालांकि, लोकेटर टैग के लिए ऐसा करना ज़रूरी नहीं है, क्योंकि वे बॉन्डिंग का इस्तेमाल नहीं करते.

फ़ास्ट पेयर विज्ञापन, FHN विज्ञापन, और उनसे जुड़े BLE पते एक साथ रोटेट होने चाहिए. औसतन हर 1024 सेकंड में रोटेशन होना चाहिए. जिस सटीक समय पर बीकन, नए आइडेंटिफ़ायर का विज्ञापन दिखाना शुरू करता है उसे विंडो में रैंडमाइज़ किया जाना चाहिए.

रोटेशन के समय को रैंडमाइज़ करने का सुझाव दिया गया है. इसके लिए, रोटेशन के अगले अनुमानित समय (अगर रैंडमाइज़ेशन लागू नहीं किया गया था) को सेट करें. साथ ही, इसमें 1 से 204 सेकंड के बीच का पॉज़िटिव रैंडमाइज़्ड टाइम फ़ैक्टर जोड़ें.

जब डिवाइस, अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड में हो, तब FHN विज्ञापन का बीएलई पता तय होना चाहिए. हालांकि, FP के ऐसे विज्ञापन के लिए आरपीए को रोटेट करते रहना चाहिए जो आस-पास के डिवाइसों को नहीं दिखता (जैसे, Fast Pair). अलग-अलग प्रोटोकॉल के लिए अलग-अलग पतों का इस्तेमाल किया जा सकता है.

बिजली चले जाने के बाद डेटा वापस पाना

विज्ञापन दिखाने के समय, एफ़ेमरल आइडेंटिफ़ायर को हल करना, उसकी क्लॉक वैल्यू से जुड़ा होता है. इसलिए, अगर बिजली चली जाती है, तो यह ज़रूरी है कि प्रोवाइडर अपनी क्लॉक वैल्यू को वापस पा सके. हमारा सुझाव है कि प्रोवाइडर, अपनी मौजूदा क्लॉक वैल्यू को दिन में कम से कम एक बार नॉनवॉलेटाइल मेमोरी में लिखे. साथ ही, बूट होने के समय प्रोवाइडर, एनवीएम की जांच करे. इससे यह पता चलेगा कि कोई ऐसी वैल्यू मौजूद है या नहीं जिससे शुरुआत की जा सके. एफ़ेमरल आइडेंटिफ़ायर को हल करने वाले लोग, एक तय समयसीमा में आइडेंटिफ़ायर को हल करेंगे. इससे क्लॉक में मामूली अंतर और बिजली चले जाने की वजह से होने वाली समस्या को ठीक किया जा सकेगा.

हालांकि, प्रोवाइडर को अब भी क्लॉक ड्रिफ्ट को कम करने की पूरी कोशिश करनी चाहिए, क्योंकि समस्या ठीक करने के लिए समयसीमा सीमित है. कम से कम एक और क्लॉक सिंक्रनाइज़ेशन का तरीका लागू किया जाना चाहिए. जैसे, नॉन-डिस्कवरेबल फ़ास्ट पेयर फ़्रेम का विज्ञापन दिखाना या मैसेज स्ट्रीम लागू करना.

फ़ास्ट पेयर की सुविधा लागू करने के दिशा-निर्देश

इस सेक्शन में, फ़ास्ट पेयर की सुविधा लागू करने के खास पहलुओं के बारे में बताया गया है. ये पहलू, उन प्रोवाइडर पर लागू होते हैं जो FHN की सुविधा देते हैं.

लोकेटर टैग से जुड़े दिशा-निर्देश

• अगर प्रोवाइडर को पेयर किया गया था, लेकिन पांच मिनट के अंदर FHN की सुविधा चालू नहीं हुई या डिवाइस के पेयर होने के दौरान OTA अपडेट लागू किया गया, लेकिन FHN की सुविधा चालू नहीं हुई, तो प्रोवाइडर को फ़ैक्ट्री कॉन्फ़िगरेशन पर वापस जाना चाहिए. साथ ही, सेव किए गए खाते के कुंजियों को मिटा देना चाहिए.
• प्रोवाइडर के पेयर हो जाने के बाद, उसे अपना मैक पता तब तक नहीं बदलना चाहिए, जब तक कि FHN की सुविधा चालू न हो जाए या पांच मिनट न बीत जाएं.
• अगर डिवाइस से कुछ समय के लिए इस्तेमाल होने वाली पहचान की कुंजी मिटा दी जाती है, तो डिवाइस को फ़ैक्ट्री रीसेट करना चाहिए. साथ ही, सेव की गई खाता कुंजियों को भी मिटा देना चाहिए.
• Provider को सामान्य ब्लूटूथ पेयरिंग अनुरोधों को अस्वीकार करना चाहिए और सिर्फ़ फ़ास्ट पेयर पेयरिंग को स्वीकार करना चाहिए.
• सेवा देने वाली कंपनी को एक ऐसा तरीका उपलब्ध कराना होगा जिससे उपयोगकर्ता, डिवाइस को फ़ैक्ट्री रीसेट किए बिना कुछ समय के लिए विज्ञापन दिखाना बंद कर सकें. उदाहरण के लिए, बटनों के किसी कॉम्बिनेशन को दबाना.
• डिवाइस बंद होने के बाद, उसे फ़ास्ट पेयर के ऐसे फ़्रेम का विज्ञापन दिखाना चाहिए जिन्हें खोजा नहीं जा सकता. ऐसा तब तक होना चाहिए, जब तक रीड बीकन पैरामीटर को अगली बार चालू नहीं किया जाता. इससे Seeker को डिवाइस का पता लगाने और घड़ी को सिंक करने में मदद मिलती है. भले ही, घड़ी में काफ़ी अंतर आ गया हो.
• फ़ास्ट पेयर की सुविधा वाले ऐसे फ़्रेम का विज्ञापन करते समय, यूज़र इंटरफ़ेस (यूआई) के इंडिकेटर चालू नहीं होने चाहिए जिन्हें खोजा नहीं जा सकता.
• फ़ास्ट पेयर की सुविधा वाले ऐसे फ़्रेम का विज्ञापन नहीं किया जाना चाहिए जिन्हें खोजा जा सकता है. ऐसा तब नहीं किया जाना चाहिए, जब प्रोवाइडर को FHN के लिए प्रोविज़न किया गया हो.
• सेवा देने वाली कंपनी को, बिना पुष्टि किए किसी भी तरीके से पहचान ज़ाहिर करने वाली जानकारी (जैसे, नाम या पहचान करने वाले) को सार्वजनिक नहीं करना चाहिए.

क्लासिक ब्लूटूथ डिवाइस के लिए दिशा-निर्देश

इस सेक्शन में, क्लासिक ब्लूटूथ डिवाइसों के खास पहलुओं के बारे में बताया गया है. ये डिवाइस, FHN के साथ काम करते हैं.

पहले से जुड़े डिवाइसों के लिए, FHN की सुविधा चालू करना

सीकर के साथ पेयर करने पर, प्रोवाइडर को हमेशा FHN के लिए उपलब्ध नहीं कराया जाता. हालांकि, कुछ समय बाद ऐसा किया जाता है. ऐसे में, प्रोवाइडर के पास GATT कनेक्शन बनाने के लिए ज़रूरी, बीएलई मैक पते का अप-टू-डेट वर्शन नहीं हो सकता. प्रोवाइडर को, सीकर के लिए कम से कम एक तरीका उपलब्ध कराना होगा, ताकि वह पहले से पेयर किए गए डिवाइस का बीएलई पता पा सके:

• Provider, समय-समय पर फ़ास्ट पेयर खाते में मौजूद डेटा दिखा सकता है. इससे Seeker, BLE स्कैन करके अपना पता ढूंढ सकता है.
  यह तरीका उन प्रोवाइडर के लिए सही है जिन्होंने मैसेज स्ट्रीम लागू नहीं की है.
• Provider, इस डेटा को क्लासिक ब्लूटूथ पर फ़ास्ट पेयर मैसेज स्ट्रीम के ज़रिए उपलब्ध करा सकता है.
  यह तरीका उन Provider के लिए सही है जो ब्लूटूथ से कनेक्ट होने के दौरान, फ़ास्ट पेयर फ़्रेम का विज्ञापन नहीं करते.

दोनों तरीकों का इस्तेमाल करने से, उपयोगकर्ता के लिए डिवाइस को FHN के लिए उपलब्ध कराने की संभावना बढ़ जाती है.

फ़ास्ट पेयर की सुविधा के लिए मैसेज स्ट्रीम

डिवाइस बनाने वाली कंपनी, फ़ास्ट पेयर मैसेज स्ट्रीम को लागू कर सकती है. साथ ही, इसका इस्तेमाल करके, डिवाइस ढूंढने वाले व्यक्ति को डिवाइस की जानकारी के बारे में सूचना दे सकती है. मैसेज स्ट्रीम लागू करने से, इस सेक्शन में बताई गई कुछ सुविधाएं चालू हो जाती हैं.

सेवा देने वाली कंपनी को, मैसेज स्ट्रीम शुरू होने पर डिवाइस की जानकारी वाले मैसेज एक बार भेजने चाहिए.

फ़र्मवेयर वर्शन (डिवाइस की जानकारी का कोड 0x09) और ट्रैकिंग की सुविधा

जब फ़र्मवेयर अपडेट के ज़रिए, क्रेडेंशियल देने वाले को FHN की सुविधा मिलती है, तो कनेक्ट किया गया Seeker, उपयोगकर्ता को इसकी सूचना दे सकता है. साथ ही, उसे इस सुविधा को चालू करने का विकल्प दे सकता है. ऐसा न होने पर, उपयोगकर्ता को FHN प्रोविज़निंग शुरू करने के लिए, ब्लूटूथ डिवाइसों की सूची पर मैन्युअल तरीके से जाना होगा.

इसके लिए, सेवा देने वाली कंपनी को फ़र्मवेयर वर्शन प्रॉपर्टी (कोड 0x09) का इस्तेमाल करना चाहिए. इससे वह फ़र्मवेयर वर्शन को दिखाने वाली स्ट्रिंग वैल्यू की जानकारी दे पाएगी. इसके अलावा, सेवा देने वाली कंपनी को उस प्रोटोकॉल के साथ काम करना चाहिए जिससे सेवा लेने वाले व्यक्ति को फ़र्मवेयर अपडेट की वजह से, क्षमता में हुए बदलावों के बारे में पता चल सके.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डिवाइस की जानकारी का इवेंट	0x03
1	uint8	फ़र्मवेयर का वर्शन	0x09
2 - 3	uint16	अतिरिक्त डेटा का साइज़	अलग-अलग होती है
var	बाइट अरे	वर्शन स्ट्रिंग	अलग-अलग होती है

टेबल 18: डिवाइस की जानकारी देने वाला इवेंट: अपडेट किया गया फ़र्मवेयर वर्शन.

क्षमता अपडेट करने का अनुरोध (0x0601) मिलने पर, अगर सेवा देने वाली कंपनी ने FHN ट्रैकिंग की सुविधा चालू की है, तो उसे टेबल 12 में दिखाए गए तरीके से जवाब देना चाहिए.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डिवाइस की क्षमता को सिंक करने का इवेंट	0x06
1	uint8	FHN ट्रैकिंग	0x03
2 - 3	uint16	अतिरिक्त डेटा का साइज़	0x0007
4	uint8	FHN की प्रोविज़निंग की स्थिति	अगर कोई खाता नहीं जोड़ा गया है, तो 0x00; अगर किसी खाते से जोड़ा गया है, तो 0x01
5 - 10	बाइट अरे	डिवाइस का मौजूदा बीएलई एमएसी पता	अलग-अलग होती है

टेबल 19: डिवाइस की क्षमता सिंक करने से जुड़ा इवेंट: ट्रैकिंग की सुविधा जोड़ी गई.

मौजूदा एफ़ेमरल आइडेंटिफ़ायर (डिवाइस की जानकारी देने वाला कोड 0x0B)

जब प्रोवाइडर को FHN के लिए प्रोविज़न किया जाता है, तब वह मौजूदा एफ़ेमरल आइडेंटिफ़ायर (कोड 0x0B) का इस्तेमाल करके, मौजूदा ईआईडी और क्लॉक वैल्यू की जानकारी दे सकता है. इससे, क्लॉक में अंतर आने पर (उदाहरण के लिए, बैटरी खत्म होने की वजह से) सीक करने वाले व्यक्ति के डिवाइस को सिंक किया जा सकता है. ऐसा न होने पर, सीक करने वाला व्यक्ति इस काम के लिए ज़्यादा महंगा और कम भरोसेमंद कनेक्शन शुरू करता है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डिवाइस की जानकारी का इवेंट	0x03
1	uint8	मौजूदा कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर	0x0B
2 - 3	uint16	अतिरिक्त डेटा का साइज़	0x0018 या 0x0024
4 - 7	बाइट अरे	घड़ी का समय	उदाहरण: 0x13F9EA80
8 - 19 या 31	बाइट अरे	मौजूदा ईआईडी	उदाहरण: 0x1122334455667788990011223344556677889900

टेबल 20: डिवाइस की जानकारी देने वाला इवेंट: घड़ी सिंक करना.

फ़ैक्ट्री रीसेट करें

फ़ैक्ट्री रीसेट की सुविधा वाले डिवाइसों के लिए: अगर फ़ैक्ट्री रीसेट किया जाता है, तो सेवा देने वाली कंपनी को बीकन भेजना बंद करना होगा. साथ ही, उसे कुछ समय के लिए इस्तेमाल होने वाली पहचान की कुंजी और सेव की गई सभी खाता कुंजियां मिटानी होंगी. इनमें मालिक के खाते की कुंजी भी शामिल है.

फ़ैक्ट्री रीसेट (मैन्युअल या प्रोग्राम के हिसाब से) के बाद, सेवा देने वाली कंपनी को Fast Pair की सुविधा का विज्ञापन तुरंत नहीं दिखाना चाहिए. इससे, उपयोगकर्ता के डिवाइस मिटाने के तुरंत बाद, पेयरिंग की प्रोसेस शुरू होने से रोकी जा सकेगी.

अनचाही ट्रैकिंग को रोकना

सर्टिफ़ाइड FHN डिवाइसों को, अनचाहे लोकेशन ट्रैकर का पता लगाने (डीयूएलटी) के लिए, क्रॉस-प्लैटफ़ॉर्म स्पेसिफ़िकेशन के लागू करने वाले वर्शन में दी गई ज़रूरी शर्तों को भी पूरा करना होगा.

डीयूएलटी के स्पेसिफ़िकेशन का पालन करने के लिए, एफएचएन से जुड़े ज़रूरी दिशा-निर्देश:

• FHN के साथ काम करने वाले किसी भी डिवाइस को Nearby Device Console में रजिस्टर किया जाना चाहिए. साथ ही, उसमें "हब ढूंढें" सुविधा चालू होनी चाहिए.
• डिवाइस में, ऐक्सेसरी के मालिक के अलावा किसी और व्यक्ति के लिए उपलब्ध सेवा और DULT स्पेसिफ़िकेशन के लागू किए गए वर्शन में बताई गई सुविधा लागू होनी चाहिए. इसमें ऐक्सेसरी की जानकारी से जुड़ी कार्रवाइयां और ऐक्सेसरी के मालिक के अलावा किसी और व्यक्ति के लिए उपलब्ध कंट्रोल शामिल हैं.
• DULT स्पेसिफ़िकेशन में बताई गई बैकवर्ड कंपैटिबिलिटी की अवधि के दौरान, इस दस्तावेज़ में बताए गए विज्ञापन वाले फ़्रेम में कोई बदलाव नहीं किया गया है.
• इस दस्तावेज़ में बताई गई "अनचाही ट्रैकिंग से सुरक्षा का मोड", DULT के स्पेसिफ़िकेशन में बताई गई "अलग स्थिति" से मेल खाता है.
• ऐक्सेसरी की जानकारी वाले ऑपकोड लागू करने के लिए दिशा-निर्देश:
  • Get_Product_Data को कंसोल से मिला मॉडल आईडी दिखाना चाहिए. साथ ही, इसे आठ बाइट की ज़रूरत के हिसाब से शून्य से पैड किया जाना चाहिए. उदाहरण के लिए, मॉडल आईडी 0xFFFFFF को 0x0000000000FFFFFF के तौर पर दिखाया जाता है.
  • Get_Manufacturer_Name और Get_Model_Name की वैल्यू, कंसोल में दी गई वैल्यू से मेल खानी चाहिए.
  • अगर डिवाइस के टाइप के हिसाब से कोई दूसरी कैटगरी ज़्यादा सही नहीं है, तो Get_Accessory_Category, "लोकेशन ट्रैकर" की सामान्य वैल्यू दिखा सकता है.
  • Get_Accessory_Capabilities को यह बताना होगा कि इसमें रिंग करने की सुविधा के साथ-साथ, बीएलई आइडेंटिफ़ायर लुकअप की सुविधा भी काम करती है.
  • Get_Network_ID को Google का आइडेंटिफ़ायर (0x02) दिखाना चाहिए.
• Get_Identifier ओपकोड लागू करने के लिए दिशा-निर्देश:
  • उपयोगकर्ता के 'पहचान' मोड को चालू करने के बाद, यह कार्रवाई सिर्फ़ पांच मिनट तक मान्य जवाब देगी. इसके लिए, बटन को एक साथ दबाना ज़रूरी है. विज़ुअल या ऑडियो सिग्नल से उपयोगकर्ता को यह पता चलना चाहिए कि सेवा देने वाली कंपनी ने उस मोड में एंट्री कर ली है. उस मोड को चालू करने के लिए, मॉडल के हिसाब से निर्देश Google को देने होंगे. ऐसा सर्टिफ़िकेट पाने के लिए करना ज़रूरी है. साथ ही, निर्देशों में कोई भी अपडेट या बदलाव करने से कम से कम 10 दिन पहले ऐसा करना होगा.
  • जवाब इस तरह से बनाया जाता है: मौजूदा कुछ समय के लिए मान्य आइडेंटिफ़ायर के पहले 10 बाइट, इसके बाद HMAC-SHA256(recovery key, the truncated current ephemeral identifier) के पहले 8 बाइट.
• एनएफ़सी पर आइडेंटिफ़ायर लागू करने के लिए दिशा-निर्देश:
  • यूआरएल के तौर पर, find-my.googleapis.com/lookup का इस्तेमाल करें.
  • e पैरामीटर के तौर पर, Get_Identifier के लिए बनाए गए जवाब का इस्तेमाल करें. यह हेक्स कोड में होना चाहिए.
  • pid पैरामीटर के तौर पर, Get_Product_Data के लिए बनाए गए जवाब का इस्तेमाल करें. यह जवाब, हेक्स कोड में होना चाहिए.
• डिवाइस में आवाज़ करने वाला कॉम्पोनेंट होना चाहिए और उसमें घंटी बजाने की सुविधा होनी चाहिए. डीयूएलटी के स्पेसिफ़िकेशन के मुताबिक, आवाज़ करने वाले डिवाइस से कम से कम 60 फ़ोन की पीक लाउडनेस वाली आवाज़ निकलनी चाहिए. यह आईएसओ 532-1:2017 के मुताबिक तय की गई है.
• Sound_Start ओपकोड को लागू करने के लिए दिशा-निर्देश:
  • इस निर्देश से, सभी उपलब्ध कॉम्पोनेंट में घंटी बजनी चाहिए.
  • ज़्यादा से ज़्यादा वॉल्यूम का इस्तेमाल किया जाना चाहिए.
  • हमारा सुझाव है कि रिंग बजने की अवधि 12 सेकंड होनी चाहिए.
• लोकेटर टैग में एक ऐसा सिस्टम होना चाहिए जिससे उपयोगकर्ता, डिवाइस को फ़ैक्ट्री रीसेट किए बिना कुछ समय के लिए विज्ञापन दिखाना बंद कर सकें. उदाहरण के लिए, बटनों के कॉम्बिनेशन को दबाना.
  • बंद करने के निर्देशों को सार्वजनिक तौर पर उपलब्ध यूआरएल में दस्तावेज़ के तौर पर सेव किया जाना चाहिए. साथ ही, सर्टिफ़िकेट पाने के लिए, Google को यह यूआरएल देना ज़रूरी है. इसके अलावा, निर्देशों में कोई भी अपडेट या बदलाव करने से कम से कम 10 दिन पहले, Google को इसकी जानकारी देनी होगी.
  • यूआरएल में स्थानीय भाषा की सुविधा काम करनी चाहिए. क्लाइंट के हिसाब से, भाषा को क्वेरी पैरामीटर ("hl=en") के तौर पर या "accept-language" एचटीटीपी हेडर का इस्तेमाल करके उपलब्ध कराया जाएगा.

स्विच किए जा सकने वाले प्रोटोकॉल के लिए दिशा-निर्देश

• एक समय में सिर्फ़ एक प्रोटोकॉल का इस्तेमाल किया जाना चाहिए. पक्का करें कि डिवाइस पर एक से ज़्यादा नेटवर्क एक साथ काम न कर रहे हों. यह ज़रूरी है, ताकि अलग-अलग प्रोटोकॉल के बीच उपयोगकर्ता के संवेदनशील डेटा को एक साथ न मिलाया जाए.
• हमारा सुझाव है कि डिवाइस में हार्ड रीसेट का वर्कफ़्लो शामिल करें. इससे उपयोगकर्ता, डिवाइस को किसी दूसरे नेटवर्क से फिर से सेट अप कर पाएगा.
• किसी डिवाइस को नेटवर्क से अपडेट करने की प्रोसेस, उपयोगकर्ता के लिए आसान होनी चाहिए. साथ ही, यह सभी नेटवर्क के लिए एक जैसी होनी चाहिए. उपयोगकर्ता को यह चुनने का विकल्प मिलना चाहिए कि उसे कौनसे नेटवर्क का इस्तेमाल करना है. इसके लिए, उसे किसी एक नेटवर्क को प्राथमिकता देने की ज़रूरत नहीं होनी चाहिए. इस फ़्लो को Google की टीम से मंज़ूरी मिलनी चाहिए.

फ़र्मवेयर अपडेट

ओटीए अपडेट की प्रोसेस और डिस्ट्रिब्यूशन को पार्टनर को मैनेज करना चाहिए. इसके लिए, उसे अपने मोबाइल या वेब ऐप्लिकेशन के वर्कफ़्लो का इस्तेमाल करना चाहिए.

फ़ास्ट पेयर की सुविधा, उपयोगकर्ता को सूचनाएं भेजने में मदद करती है. इससे, उपलब्ध ओटीए अपडेट के बारे में जानकारी मिलती है. इस सुविधा का इस्तेमाल करने के लिए:

• Nearby Device Console में, फ़र्मवेयर का नया वर्शन अपडेट होना चाहिए.
• आस-पास मौजूद डिवाइसों के कंसोल में, कंपैनियन ऐप्लिकेशन सेट होना चाहिए. इसमें फ़र्मवेयर अपडेट करने का इंटेंट होना चाहिए.
• सेवा देने वाली कंपनी को फ़र्मवेयर वर्शन GATT विशेषता लागू करनी चाहिए.

ट्रैकिंग को रोकने के लिए, फ़र्मवेयर के वर्शन की जानकारी देने वाली विशेषता का ऐक्सेस सीमित होना चाहिए. डिवाइस को ढूंढने वाला ऐप्लिकेशन, सबसे पहले प्रोविज़निंग की स्थिति को पढ़ेगा और इस स्पेसिफ़िकेशन में बताई गई पुष्टि करने वाली कुंजी देगा. इसके बाद ही, फ़र्मवेयर के वर्शन को पढ़ेगा. यह उसी कनेक्शन पर किया जाएगा. अगर फ़र्मवेयर के वर्शन को पढ़ने की कोशिश की जाती है और प्रोवाइडर न तो बॉन्ड किया गया है और न ही उसी कनेक्शन पर पुष्टि की गई कोई कार्रवाई पूरी हुई है, तो प्रोवाइडर को पुष्टि न होने की गड़बड़ी का मैसेज दिखाना चाहिए.

इनके साथ काम करता है

Find Hub नेटवर्क इस्तेमाल करने के लिए, जगह की जानकारी वाली सेटिंग और ब्लूटूथ चालू करना ज़रूरी है. इसके लिए, मोबाइल नेटवर्क या इंटरनेट कनेक्शन ज़रूरी है. यह सुविधा, Android 9 या उसके बाद के वर्शन वाले डिवाइसों पर काम करती है. साथ ही, यह सुविधा कुछ देशों में ऐसे लोगों के लिए उपलब्ध है जो उम्र से जुड़ी ज़रूरी शर्तें पूरी करते हैं.

बदलावों का लॉग

FHN वर्शन	तारीख	टिप्पणी
v1		अर्ली ऐक्सेस के लिए, FHN स्पेसिफ़िकेशन की शुरुआती रिलीज़.
v1.1	Feb 2023	अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड के बारे में साफ़ तौर पर बताया गया है. अनचाही ट्रैकिंग से सुरक्षा मोड में होने पर, बजने के अनुरोधों की पुष्टि करने की सुविधा को स्किप करने का विकल्प जोड़ा गया.
v1.2	अप्रैल 2023	मालिक के एग्रीमेंट की परिभाषा को अपडेट किया गया. लोकेटर टैग में बिजली गुल होने की समस्या ठीक करने के लिए सुझाव जोड़ा गया. मैक पते को रैंडमाइज़ करने की सुविधा के बारे में ज़्यादा जानकारी जोड़ी गई. अनचाही ट्रैकिंग से सुरक्षा वाले मोड में, MAC पते के रोटेशन के बारे में ज़्यादा जानकारी जोड़ी गई है. लोकेटर टैग को बंद करने का तरीका उपलब्ध कराने के बारे में दिशा-निर्देश जोड़ा गया.
v1.3	दिसंबर 2023	लोकेटर टैग से दिखने वाली पहचान से जुड़ी जानकारी के बारे में ज़्यादा जानकारी जोड़ी गई है. अनचाही ट्रैकिंग को रोकने के लिए, खास जानकारी को लागू करने की ज़रूरी शर्त जोड़ी गई है. स्विच किए जा सकने वाले प्रोटोकॉल वाले डिवाइसों के लिए दिशा-निर्देश जोड़े गए.