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

v1.3

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

GATT स्पेसिफ़िकेशन

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

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

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

पुष्टि करना

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

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

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

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

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

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

  • पहली बार पेयर करने पर, जो प्रोवाइडर पहले से ही 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: बीकन पैरामीटर पढ़ें 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) के पहले 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	डेटा आईडी	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	बाइट अरे	अतिरिक्त डेटा	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 वाली विशेषता पर राइट ऑपरेशन करना होगा. सेवा देने वाली कंपनी यह पुष्टि करती है कि एक बार पुष्टि करने के लिए दी गई कुंजी, डिवाइस पर सेव की गई किसी भी खाता कुंजी से मेल खाती है.

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

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

अनुरोध पूरा होने पर, सेवा देने वाली कंपनी टेबल 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	टाइम आउट की संख्या	घंटी बजने का बचा हुआ समय, डेसीसेकंड में. अगर डिवाइस की घंटी बजना बंद हो गई है, तो 0000 वैल्यू दिखनी चाहिए.

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

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

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

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

प्रमाणीकरण सेगमेंट को 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 के निर्देश वाले सेक्शन में बताए गए हैं. सटीक जानकारी का पता लगाने वाली सुविधा का इस्तेमाल करना ज़रूरी नहीं है.

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

सटीक जानकारी का पता लगाने वाली सुविधा का फ़्लो

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

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

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

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

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

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

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

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

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

सटीक जानकारी का पता लगाने वाली सुविधा से जुड़ी कार्रवाइयां

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

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

टेबल 8: सटीक जानकारी का पता लगाने वाली सुविधा के ऑपरेशन.

Ranging Capability Request ऑपरेशन

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

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

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

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

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

सटीक जानकारी का पता लगाने वाली सुविधा के लिए, रेंजिंग टेक्नोलॉजी की खास बातें

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

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

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

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

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

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

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

हर कॉन्फ़िगरेशन आईडी, पहले से तय किए गए यूडब्ल्यूबी कॉन्फ़िगरेशन पैरामीटर का एक सेट होता है. इसके बारे में सार्वजनिक तौर पर जानकारी दी गई है. सटीक जानकारी का पता लगाने वाली सुविधा के लिए, जवाब देने वाले डिवाइस में config Id 6 की सुविधा होनी चाहिए. साथ ही, config Id 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. Compute 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. Compute nonce = LRx || LSx.
7. Compute (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. Compute nonce = LRx || LSx.
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag).

आईडी रोटेशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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