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

v1.3

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

ध्यान दें: अगर आपको अपने लोकेशन टैग या सुनने में मदद करने वाले डिवाइस को Find Hub Network Accessory के साथ इंटिग्रेट करना है, तो Find Hub डिवाइस का सुझाव देने वाला फ़ॉर्म भरें. अगर आपको कान के ऊपर पहने जाने वाले या TWS हेडफ़ोन में Find Hub की सुविधा जोड़नी है, तो Fast Pair डिवाइस का सुझाव देने वाला फ़ॉर्म भरें.

GATT की खास बातें

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

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

पहली टेबल: FHN के लिए Fast Pair सेवा की विशेषताएं.

पुष्टि करना

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

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

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

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

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

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

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

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

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

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

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

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

कार्रवाइयां

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

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x00: Read beacon parameters 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	बाइट अरे	अतिरिक्त डेटा	0x00: n/a 0x01: n/a 0x02: 32 बाइट, जो कुछ समय के लिए इस्तेमाल की जाने वाली पहचान की कुंजी होती है. इसे खाते की कुंजी के साथ AES-ECB-128 का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया जाता है. अगर सेवा देने वाली कंपनी के पास पहले से ही एक एफ़ेमरल आइडेंटिटी कुंजी सेट है, तो SHA256(current ephemeral identity key || the last nonce read from the characteristic) के पहले आठ बाइट भी भेजें 0x03: SHA256(ephemeral identity key || the last nonce read from the characteristic) के पहले 8 बाइट

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

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x04: Read ephemeral identity key with user consent
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 बाइट

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

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
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	डेटा आईडी	0x00: Read beacon parameters 0x01: Read provisioning state 0x02: Set ephemeral identity key 0x03: कुछ समय के लिए इस्तेमाल की जाने वाली पहचान की कुंजी हटाएं 0x04: Read ephemeral identity key with user consent 0x05: रिंग की स्थिति में बदलाव 0x06: Read ringing state 0x07: अनचाही ट्रैकिंग से सुरक्षा देने वाला मोड चालू करें 0x08: अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड को बंद करें
1	uint8	डेटा का साइज़	अलग-अलग होती है
2 - 9	बाइट अरे	पुष्टि करना	हर कार्रवाई के हिसाब से ज़्यादा जानकारी
10 - var	बाइट अरे	अतिरिक्त डेटा	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 यह पुष्टि करता है कि दी गई एक बार इस्तेमाल होने वाली पुष्टि करने की कुंजी, डिवाइस पर सेव की गई किसी भी खाते की कुंजी से मेल खाती है.

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

अनुरोध पूरा होने पर, सेवा देने वाली कंपनी टेबल 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 बाइट के तौर पर तय किया जाता है.

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

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

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

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

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

प्रमाणीकरण सेगमेंट को 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 फ़्रेम का विज्ञापन दिखाना बंद कर देती है. Provider, टेबल 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 error दिखाता है.

अनुरोध पूरा होने पर, सेवा देने वाली कंपनी टेबल 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 मिनट से ज़्यादा नहीं होना चाहिए. सेवा देने वाली कंपनी इस वैल्यू का इस्तेमाल यह तय करने के लिए करती है कि कॉल कितनी देर तक बजना चाहिए. अगर डिवाइस का कोई कॉम्पोनेंट पहले से बज रहा है, तो टाइम आउट की सुविधा चालू होने पर, वह बंद हो जाएगा. अगर रिंग ऑपरेशन को 0x00 पर सेट किया जाता है, तो टाइम आउट को अनदेखा कर दिया जाता है.
3	uint8	आवाज़	0x00: डिफ़ॉल्ट 0x01: कम 0x02: मीडियम 0x03: ज़्यादा इन वैल्यू का सटीक मतलब, लागू किए जाने के तरीके पर निर्भर करता है.

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

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

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

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

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	रिंग बजने की स्थिति	0x00: शुरू किया गया 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 बाइट के तौर पर तय किया जाता है.

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

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

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

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

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

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

अगर सेवा देने वाली कंपनी को 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 नेटवर्क के ज़रिए, ट्रैकिंग से सुरक्षा देने वाले मोड को चालू करने का ऐसा अनुरोध भेज सकती है जिसकी ज़रूरत नहीं है. ऐसा करने से, सेवा देने वाली कंपनी कुछ समय के लिए एक तय मैक पते का इस्तेमाल करती है. इससे क्लाइंट को डिवाइस का पता लगाने और उपयोगकर्ता को संभावित अनचाही ट्रैकिंग के बारे में चेतावनी देने की अनुमति मिलती है.

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

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

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

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

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

अनचाहे ट्रैकिंग सुरक्षा मोड के चालू होने पर, बीकन को हर 24 घंटे में एक बार, मैक पते को रोटेट करने की फ़्रीक्वेंसी को कम करना चाहिए. विज्ञापन में दिखाए गए कुछ समय के लिए उपलब्ध आइडेंटिफ़ायर को हमेशा की तरह रोटेट करते रहना चाहिए. फ़्रेम टाइप को 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 ऐप्लिकेशन इंस्टॉल है. साथ ही, सटीक जगह की जानकारी ढूंढने की सुविधा इसी डिवाइस पर चालू की गई थी. डिवाइस ढूंढने की प्रोसेस शुरू करने वाले डिवाइस को इनिशिएटर कहा जाता है.

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

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

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

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

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

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

Precision Finding Operations

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

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

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

रेंजिंग की सुविधा के अनुरोध का ऑपरेशन

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

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

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

Ranging Capability Response ऑपरेशन

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

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

टेबल 10: जवाब में संख्या की जानकारी देने की सुविधा.

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

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

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	डेटा आईडी	0x0B - Set Ranging Configuration
1	uint8	डेटा का साइज़	बदलता रहता है
2	बाइट अरे	सिर्फ़ एक बार के लिए मान्य पुष्टि करने की कुंजी	यह HMAC-SHA256(खाता कुंजी, प्रोटोकॉल का मुख्य वर्शन नंबर || विशेषता से पढ़ा गया आखिरी नॉनस || डेटा आईडी || डेटा की लंबाई || अतिरिक्त डेटा) के पहले 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	बाइट अरे	अतिरिक्त डेटा	स्टॉप रेंजिंग मैसेज, जैसा कि रेंजिंग: आउट-ऑफ़-बैंड मैसेज सीक्वेंस और पेलोड स्पेसिफ़िकेशन (हेडर और पेलोड, दोनों) में बताया गया है

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

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

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

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

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

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

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

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

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

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

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

सटीक जगह की जानकारी का लेवल

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

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

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

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

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

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

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

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

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

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

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

सटीक जगह की जानकारी का लेवल

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

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

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

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

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

Wi-Fi NAN RTT

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

सटीक जगह की जानकारी का लेवल

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

BLE RSSI

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

सटीक जगह की जानकारी का लेवल

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

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

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

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

ध्यान दें: हमारा सुझाव है कि डिवाइस के लो पावर मोड में होने पर भी, FHN फ़्रेम का विज्ञापन दिखाया जाए. इससे डिवाइस के खो जाने पर उसे ढूंढने में मदद मिलती है. बैटरी खत्म होने की वजह से डिवाइस बंद होने पर, कुछ डिवाइसों के लिए विज्ञापन दिखाना संभव नहीं हो सकता. ऐसे मामलों में, हमारा सुझाव है कि आप डिवाइस को समय-समय पर चालू करें और कुछ समय के लिए विज्ञापन दिखाएं. उदाहरण के लिए, हर 10 मिनट में डिवाइस को चालू करें और 10 सेकंड के लिए विज्ञापन दिखाएं.

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

ध्यान दें: 256-बिट कुंजियों का इस्तेमाल करने का मतलब है कि BLE 5 को सपोर्ट न करने वाले पुराने फ़ोन, विज्ञापन दिखाने वाले डिवाइसों को स्कैन और उनकी रिपोर्ट नहीं कर सकते. इससे नेटवर्क का साइज़ कम हो जाता है.

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

ऑक्टेट	मान	ब्यौरा
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 फ़्रेम.

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

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

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

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

ध्यान दें: डिवाइस में, सेकंड में समय बताने वाला 32-बिट टाइम काउंटर होता है.

ध्यान दें: रोटेशन पीरियड एक्सपोनेंट तय होता है और इसे 10 पर सेट किया जाता है. यह 1024 सेकंड के बराबर होता है.

इस कैलकुलेशन का नतीजा 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: बैटरी लेवल दिखाने की सुविधा काम नहीं करती
  • 01: बैटरी का सामान्य लेवल
  • 10: बैटरी लेवल कम है
  • 11: बैटरी का लेवल बहुत कम है (बैटरी को जल्द ही बदलना होगा)
• अगर बीकन, ट्रैकिंग सुरक्षा के अनचाहे मोड में है, तो बिट 7 को 1 पर सेट किया जाता है. अगर ऐसा नहीं है, तो इसे 0 पर सेट किया जाता है.

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

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

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

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

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

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

1. ईआईडी कैलकुलेट करने के तरीके सेक्शन में बताए गए तरीके के मुताबिक, Fp में मौजूद कोई भी रैंडम नंबर s चुनें.
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 फ़्रेम का विज्ञापन दिखाने के लिए, हल किए जा सकने वाले (आरपीए) या हल नहीं किए जा सकने वाले (एनआरपीए) बीएलई पते का इस्तेमाल करना ज़रूरी है. LE Audio (LEA) डिवाइसों के लिए, आरपीए ज़रूरी है. साथ ही, इसका इस्तेमाल अन्य डिवाइसों के लिए भी किया जा सकता है. हालांकि, यह उन लोकेटर टैग के लिए ज़रूरी नहीं है जो बॉन्डिंग का इस्तेमाल नहीं करते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

पहले से जुड़े डिवाइसों के लिए FHN प्रॉविज़निंग

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

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

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

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

Provider, Fast Pair मैसेज स्ट्रीम को लागू कर सकता है. साथ ही, इसका इस्तेमाल करके Seeker को डिवाइस की जानकारी के बारे में सूचना दे सकता है. मैसेज स्ट्रीम लागू करने से, इस सेक्शन में बताई गई कुछ सुविधाएं चालू हो जाती हैं.

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

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

जब फ़र्मवेयर अपडेट के ज़रिए, Provider में 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 के स्पेसिफ़िकेशन में बताई गई "अलग की गई स्थिति" से मेल खाता है.
• ऐक्सेसरी की जानकारी वाले ऑपकोड लागू करने के लिए दिशा-निर्देश:
  • Get_Product_Data को कंसोल से मिला मॉडल आईडी दिखाना चाहिए. साथ ही, इसे आठ बाइट की ज़रूरत के हिसाब से शून्य से पैड किया जाना चाहिए. उदाहरण के लिए, मॉडल आईडी 0xFFFFFF को 0x0000000000FFFFFF के तौर पर दिखाया जाता है.
  • Get_Manufacturer_Name और Get_Model_Name की वैल्यू, कंसोल में दी गई वैल्यू से मेल खानी चाहिए.
  • अगर डिवाइस के टाइप के हिसाब से कोई दूसरी कैटगरी ज़्यादा सही नहीं है, तो Get_Accessory_Category, "Location Tracker" की सामान्य वैल्यू दिखा सकता है.
  • 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 में, फ़र्मवेयर का नया वर्शन अपडेट होना चाहिए.
• आस-पास मौजूद डिवाइस कंसोल में, कंपैनियन ऐप्लिकेशन सेट होना चाहिए. इसमें फ़र्मवेयर अपडेट करने का इंटेंट होना चाहिए.
• Provider को फ़र्मवेयर के वर्शन में बदलाव GATT की सुविधा लागू करनी चाहिए.

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

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

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

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

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