ব্লুটুথ লো এনার্জি (বিএলই) ডিভাইস

BLE ডিভাইসগুলির জন্য Google Fast Pair Service (GFPS) বাস্তবায়ন Bluetooth Core Specification v4.2 বা তার পরবর্তী সংস্করণের সাথে সামঞ্জস্যপূর্ণ।

ফাস্ট পেয়ার স্পেসিফিকেশনের নিম্নলিখিত সংযোজনটি GFPS-এ শুধুমাত্র লো এনার্জি (LE) এবং লো এনার্জি অডিও (LEA) ডিভাইসগুলির সমর্থনের সুযোগ দেবে।

সামঞ্জস্যের স্তর

স্পেসিফিকেশনে উল্লেখিত “shall”, “must”, “will”, “should”, “may”, এবং “can” কীওয়ার্ডগুলো নিচে ব্যাখ্যা করা হলো:

মেয়াদ বর্ণনা
করবে প্রয়োজনীয়তা নির্ধারণ করতে ব্যবহৃত হয় ।
অবশ্যই প্রকাশ করতে ব্যবহৃত হয়:
পূর্বে উল্লিখিত বাধ্যতামূলক প্রয়োজনীয়তার একটি স্বাভাবিক পরিণতি
অথবা
একটি অবিসংবাদিত তথ্য (যা পরিস্থিতি নির্বিশেষে সর্বদা সত্য)।
ইচ্ছা এটা সত্যি যে - শুধুমাত্র বাস্তব ঘটনার বিবৃতির ক্ষেত্রে ব্যবহৃত হয়।
উচিত সুপারিশ করা হয় যে - এটি বোঝাতে ব্যবহৃত হয় যে একাধিক সম্ভাবনার মধ্যে একটিকে বিশেষভাবে উপযুক্ত হিসেবে সুপারিশ করা হয়েছে, কিন্তু তা আবশ্যক নয়।
মে অনুমতি দেওয়া হয় - বিকল্প অনুমোদনের জন্য ব্যবহৃত হয়।
পারে সক্ষম - কোনো বিবৃতিকে কার্যকারণগতভাবে সম্পর্কিত করতে ব্যবহৃত হয়।

কী-ভিত্তিক জোড়ার বৈশিষ্ট্য

অন্বেষণকারীর পক্ষ থেকে প্রদানকারীর প্রতি বার্তা

কী-ভিত্তিক পেয়ারিং বৈশিষ্ট্যের র রিকোয়েস্ট type 0x00 সিকারটি BLE ডিভাইস স্পেসিফিকেশন সমর্থন করে কিনা তা নির্দেশ করতে বিট 4 ব্যবহার করে এবং সিকারটি LE অডিও সমর্থন করে কিনা তা নির্দেশ করতে বিট 5 ব্যবহার করে।

অক্টেট ডেটা টাইপ বর্ণনা মূল্য বাধ্যতামূলক?
০ uint8 বার্তার ধরণ 0x00 = কী-ভিত্তিক পেয়ারিং অনুরোধ বাধ্যতামূলক
১ uint8 পতাকা
  • বিট ০ (MSB): অপ্রচলিত এবং Seeker দ্বারা উপেক্ষিত।
  • বিট ১: যদি অনুসন্ধানকারী প্রদানকারীকে বন্ডিং শুরু করার জন্য অনুরোধ করে এবং এই অনুরোধে অনুসন্ধানকারীর BR/EDR ঠিকানা থাকে, তাহলে এর মান হবে ১। অন্যথায় এর মান হবে ০।
  • বিট ২: ১, যদি অনুসন্ধানকারী অনুরোধ করেন যে প্রদানকারী বিদ্যমান নামটি অবহিত করবে। অন্যথায় ০।
  • বিট ৩: ১ যদি এটি পূর্ববর্তী তারিখ থেকে অ্যাকাউন্ট কী লেখার জন্য হয়। অন্যথায় ০।
  • বিট ৪: সিকারটি বিএলই ডিভাইস স্পেসিফিকেশন সমর্থন করলে ১। অন্যথায় ০।
  • বিট ৫: সিকারটি এলই অডিও সমর্থন করলে ১। অন্যথায় ০।
  • বিট ৬ ও ৭ ভবিষ্যৎ ব্যবহারের জন্য সংরক্ষিত এবং এগুলো উপেক্ষা করা হবে।
 বিভিন্ন বাধ্যতামূলক
২ - ৭ uint48 হয়:
  • প্রদানকারীর বর্তমান BLE ঠিকানা
  • প্রদানকারীর পরিচয় ঠিকানা
 বিভিন্ন বাধ্যতামূলক
৮ - ১৩ uint48 অনুসন্ধানকারীর বিআর/ইডিআর ঠিকানা বিভিন্ন শুধুমাত্র ফ্ল্যাগ বিট ১ বা ৩ সেট করা থাকলেই উপস্থিত থাকবে।
এন - ১৫ এলোমেলো মান (লবণ) বিভিন্ন বাধ্যতামূলক

প্রদানকারীর পক্ষ থেকে সেবাগ্রহীতার প্রতি বার্তা

যখন অনুরোধের বিট ৪ সেট করা থাকে, তখন সিকারকে অতিরিক্ত বন্ডিং বিকল্প প্রদান করার জন্য কী-ভিত্তিক পেয়ারিং বৈশিষ্ট্যের নতুন প্রতিক্রিয়া বার্তা type 0x02 ব্যবহার করা যেতে পারে।

অক্টেট ডেটা টাইপ বর্ণনা মূল্য
০ uint8 বার্তার ধরণ 0x02 = কী-ভিত্তিক পেয়ারিং বর্ধিত প্রতিক্রিয়া
১ uint8 পতাকা
  • বিট ০ (MSB): প্রোভাইডারটি শুধুমাত্র LE ডিভাইস হলে এর মান হবে ১, অন্যথায় ০। যদি বিট ০-কে ১-এ সেট করা হয়, তাহলে সিকার ধরে নেবে যে বিট ১-এর মানও ১-এ সেট করা আছে।
  • বিট ১: প্রোভাইডার যদি এলই বন্ডিং পছন্দ করেন তবে ১, অন্যথায় ০।
  • বিট ২: দ্বিতীয় অ্যাড্রেসের টাইপ র‍্যান্ডম হলে ১, পাবলিক হলে ০।
  • বিট ৩ থেকে ৭ ভবিষ্যৎ ব্যবহারের জন্য সংরক্ষিত এবং এগুলো উপেক্ষা করতে হবে।
 বিভিন্ন
২ uint8 প্রদানকারীর ঠিকানার সংখ্যা
(বর্তমান সংস্করণে, সংখ্যাটির মান ১ বা ২, কারণ সংখ্যাটি ৩ বা তার বেশি হলে আমাদের ব্লক সাইফার মোডকে AES-CTR-এ পরিবর্তন করতে হয়)		 বিভিন্ন
৩ - ৮ অথবা
৩ - ১৪
  • প্রথম ঠিকানাটি হবে প্রাইমারির আইডেন্টিটি অ্যাড্রেস, এবং BR/EDR বন্ডিং পছন্দ করা হলে এটি বন্ডযোগ্য হবে।
  • যদি দ্বিতীয় ঠিকানাটি উপলব্ধ থাকে, তবে সেটিই দ্বিতীয় ঠিকানা হিসেবে জামিনযোগ্য ঠিকানা হবে।
 বিভিন্ন
৯ - ১৫ অথবা ১৫ এলোমেলো মান (লবণ) বিভিন্ন

যে প্রোভাইডার BLE ডিভাইস স্পেসিফিকেশন সমর্থন করে, তাকে সিকারের সক্ষমতা বোঝার জন্য বিট ৪ এবং বিট ৫ পড়তে হবে।

  • যখন বিট ৪-এর মান ০ হবে, তখন প্রোভাইডার বিট ৫ উপেক্ষা করবে এবং type 0x01 ফরম্যাটে সাড়া দেবে।
  • যখন বিট ৪ এর মান ১ হয়,
    • শুধুমাত্র আইন প্রয়োগকারী সংস্থার (LE-only Provider) ক্ষেত্রে, আইন প্রয়োগকারী সংস্থার সাথে বন্ধনের পছন্দ নির্দেশ করতে type 0x02 করে সাড়া দিতে হবে।
    • ডুয়াল মোড প্রোভাইডারের ক্ষেত্রে, এটি BR/EDR অথবা LE বন্ডিং পছন্দ নির্দেশ করতে type 0x02 মাধ্যমে সাড়া দিতে পারে।
  • LE Audio (LEA) ডুয়াল মোড প্রোভাইডারের ক্ষেত্রে, রেফারেন্সের জন্য উদাহরণ: LEA ডুয়াল মোড প্রোভাইডারের সাথে পেয়ারিং দেখুন।

মেসেজ স্ট্রিম পিএসএম (প্রোটোকল সার্ভিস মাল্টিপ্লেক্সর) বৈশিষ্ট্য

BLE ডিভাইসগুলির জন্য মেসেজ স্ট্রিম সমর্থন করতে, ফাস্ট পেয়ার মেসেজ পাঠানো ও গ্রহণের জন্য একটি BLE L2CAP চ্যানেল স্থাপন ও রক্ষণাবেক্ষণ করবে। ফাস্ট পেয়ার L2CAP সার্ভারটি LE ক্রেডিট ভিত্তিক ফ্লো কন্ট্রোল বাস্তবায়ন করবে।

এই বৈশিষ্ট্যটি সিকারকে PSM মানটি পড়তে এবং তারপর সেই PSM মানের মাধ্যমে একটি সুরক্ষিত L2CAP সংযোগ স্থাপন করতে সক্ষম করে।

ফাস্ট পেয়ার সার্ভিসের বৈশিষ্ট্য এনক্রিপ্টেড অনুমতি UUID
মেসেজ স্ট্রিম পিএসএম হ্যাঁ পড়ুন FE2C1239-8366-4814-8EB0-01DE32100BEA
অক্টেট ডেটা টাইপ বর্ণনা মূল্য
০ uint8 রাজ্য
  • 0x00 = অজানা। FP Seeker বেশ কয়েকবার পুনরায় চেষ্টা করবে।
  • 0x01 = সংযোগের জন্য প্রস্তুত
  • 0x02 = অনুপলব্ধ। FP Seeker এইবার সংযোগ করার জন্য এই উপাদানটি ব্যবহার করবে না।
 বিভিন্ন
১ - ২ uint16 PSM-এর মান 0x80 এবং 0xFF-এর মধ্যবর্তী পরিসরে থাকতে হবে। বিভিন্ন

দ্রষ্টব্য: TWS-এর দুটি উপাদান রয়েছে: প্রাইমারি এবং সেকেন্ডারি। নির্দিষ্ট পরিস্থিতিতে এই উপাদানগুলোর ভূমিকা বিনিময়যোগ্য। ধরা যাক, A হলো প্রাইমারি উপাদান এবং B হলো সেকেন্ডারি উপাদান। A উপাদানের ব্যাটারি শেষ হয়ে যাওয়ার কারণে, B উপাদানটিকে প্রাইমারি উপাদানের ভূমিকা গ্রহণ করতে হয় এবং এই পরিস্থিতিকে role switch বলা হয়।

role switch পর, যদি প্রোভাইডার ফাস্ট পেয়ার মেসেজ স্ট্রিম পরিচালনা করতে না পারে, তবে এটি স্বতঃপ্রণোদিত হয়ে বিদ্যমান L2CAP সংযোগটি বিচ্ছিন্ন করে দেবে। এরপর ফাস্ট পেয়ার সিকার নতুন প্রাইমারি কম্পোনেন্টের সাথে L2CAP মেসেজ স্ট্রিম সংযোগটি পুনরায় স্থাপন করতে পারবে।

অতিরিক্ত পাসকি বৈশিষ্ট্য

এই বৈশিষ্ট্যটির উদ্দেশ্য হলো অতিরিক্ত উপাদানগুলিতে MITM সুরক্ষা প্রদান করা।

CSIS ভুয়া সদস্য MITM সুরক্ষা

পেয়ারিং প্রক্রিয়ার অংশ হিসেবে ফাস্ট পেয়ারের জন্য MITM সুরক্ষার প্রয়োজন হয়। যেহেতু CSIS MITM সুরক্ষা প্রদান করে না, তাই একাধিক কম্পোনেন্টের জন্য FP-এর বর্তমান ডিজাইনটিকে অতিরিক্ত কম্পোনেন্টগুলোতে MITM সুরক্ষা প্রদানের জন্য সম্প্রসারিত করতে হবে।

বৈশিষ্ট্য সংজ্ঞা

ফাস্ট পেয়ার সার্ভিসের বৈশিষ্ট্য এনক্রিপ্টেড অনুমতি UUID
অতিরিক্ত পাসকি হ্যাঁ পড়ুন, লিখুন, অবহিত করুন FE2C123A-8366-4814-8EB0-01DE32100BEA

বার্তা

মেসেজ ফরম্যাটটি রিড, রাইট এবং নোটিফাই অপারেশনের ক্ষেত্রে প্রয়োগ করা হয়।

এনক্রিপ্টেড ডেটা ফরম্যাট

এনক্রিপ্ট করা ডেটা ফাস্ট পেয়ার গ্যাট (Fast Pair GATT) সংযোগ ব্যবহার করে পাঠানো হয়।

অক্টেট ডেটা টাইপ বর্ণনা মূল্য
০-১৫ uint128 এনক্রিপ্টেড অতিরিক্ত পাসকি ব্লক বিভিন্ন
কাঁচা ডেটা ফরম্যাট

শেয়ার্ড সিক্রেট ব্যবহার করে এনক্রিপ্ট করা ডেটা ডিক্রিপ্ট করার পর, ফরম্যাটটি নিম্নরূপ হয়।

অক্টেট ডেটা টাইপ বর্ণনা মূল্য
০ uint8 বার্তার ধরণ অন্যতম
  • 0x00 = অনুসন্ধানকারীর পাসকি
  • 0x01 = প্রোভাইডারের পাসকি
১-৩ uint24 ৬-সংখ্যার পাসকি বিভিন্ন
৪-৯ uint48 লক্ষ্য বন্ধন উপাদান ঠিকানা বিভিন্ন
১০ uint8 স্ট্যাটাস কোড, এটি শুধুমাত্র রিড অপারেশনের জন্য ব্যবহৃত হয়। অন্যতম
  • 0x00 = সাফল্য
  • 0x01 = অপেক্ষাধীন। সময়সীমা শেষ না হওয়া পর্যন্ত FP সিকার পুনরায় চেষ্টা করবে।
  • 0x02 = ব্যর্থতা। FP Seeker পুনরায় চেষ্টা করা বন্ধ করেছে।
১১-১৫ এলোমেলো মান (লবণ) বিভিন্ন

প্রাথমিক (প্রথম সংযুক্ত উপাদান) হলো ফাস্ট পেয়ার সিকার এবং অতিরিক্ত সংযুক্ত উপাদানগুলোর মধ্যে সেতুবন্ধন। এর বৈশিষ্ট্য নিম্নলিখিত নির্দেশিকা অনুসরণ করবে:

  • ফাস্ট পেয়ার সিকার থেকে রাইট রিকোয়েস্ট পেলে, প্রোভাইডার যা করবে তা হলো
    • যে কম্পোনেন্টটি বন্ড করা হচ্ছে তার অ্যাড্রেস সেট করুন।
    • যে কম্পোনেন্টটি বন্ড করা হচ্ছে, সেটিতে পাসকি পাঠান।
    • স্ট্যাটাস কোড পেন্ডিং, 0x01 এ সেট করুন।
  • সংযুক্ত করা হচ্ছে এমন কম্পোনেন্ট থেকে পাসকি পাওয়ার আগে কোনো রিড রিকোয়েস্ট পেলে, প্রোভাইডার একটি মেসেজ ফেরত দেবে যাতে থাকবে
    • পাসকি, যেকোনো মান
    • যে উপাদানটি সংযুক্ত করা হচ্ছে তার ঠিকানা
    • অপেক্ষাধীন অবস্থা কোড, 0x01
  • প্রোভাইডার ফাস্ট পেয়ার সিকার-কে নোটিফিকেশন পাঠানোর আগে, রিড রিকোয়েস্টের ফলাফল সেট করে।
    • সংযুক্ত করা হচ্ছে এমন কম্পোনেন্ট থেকে পাসকি
    • যে উপাদানটি সংযুক্ত করা হচ্ছে তার ঠিকানা
    • সফলতার স্ট্যাটাস কোড, 0x00
  • প্রোভাইডার প্রান্তে কোনো অপূরণীয় ত্রুটি ঘটলে, ফলাফল সেট করুন।
    • পাসকি, যেকোনো মান
    • যে উপাদানটি সংযুক্ত করা হচ্ছে তার ঠিকানা
    • ব্যর্থতার স্থিতি কোড, 0x02

আরও বিস্তারিত তথ্যের জন্য MITM ডায়াগ্রাম ১ এবং MITM ডায়াগ্রাম ২ দেখুন।

LE ডিভাইসের প্রয়োজনীয়তা

এলই বিজ্ঞাপন

ডিসকভারেবল মোড বা নন-ডিসকভারেবল মোডের জন্য, প্রোভাইডার ফাস্টপেয়ার ডেটা প্রচারের জন্য আরপিএ ব্যবহার করবে।

বন্ধন ক্ষমতা

LE-সক্ষম ডিভাইসগুলির জন্য, সিকারকে অবশ্যই বিদ্যমান LE সংযোগের সাথে একটি বন্ড তৈরি করতে হবে। ফাস্ট পেয়ার কী-ভিত্তিক পেয়ারিং যাচাইকরণ সফলভাবে সম্পন্ন করার পর, প্রোভাইডার RPA-এর সাথে বন্ডিংয়ের অনুমতি দেবে এবং ফাস্ট পেয়ার পাসকী যাচাইকরণের জন্য IO সক্ষমতাকে DisplayYesNo-তে সেট করবে।

LEA ডিভাইসের প্রয়োজনীয়তা

LEA বিজ্ঞাপন

ডুয়াল মোড ডিভাইসগুলির জন্য: ডিসকভারেবল মোডের ক্ষেত্রে, প্রোভাইডার আইডেন্টিটি অ্যাড্রেস সহ ফাস্ট পেয়ার ডেটা অ্যাডভার্টাইজ করবে। নন-ডিসকভারেবল মোডের ক্ষেত্রে, প্রোভাইডার RPA সহ ফাস্ট পেয়ার ডেটা অ্যাডভার্টাইজ করবে। ব্যাকওয়ার্ড কম্প্যাটিবিলিটির জন্য পুরোনো ডিভাইসগুলিকে সাপোর্ট করতে লিগ্যাসি অ্যাডভার্টাইজমেন্ট (BT 4.2) ব্যবহার করার জন্য জোরালোভাবে সুপারিশ করা হচ্ছে। যখনই ডিভাইসটি ফ্যাক্টরি রিসেট করা হবে, তখন IRK পরিবর্তন করা আবশ্যক।

নন-ডুয়াল মোড ডিভাইসগুলির জন্য: ডিসকভারেবল মোড বা নন-ডিসকভারেবল মোড যাই হোক না কেন, প্রোভাইডার ফাস্টপেয়ার ডেটা প্রচারের জন্য RPA সহ এক্সটেন্ডেড অ্যাডভার্টাইজিং (BT 5.0) ব্যবহার করবে।

FP পরিষেবা ডেটা ধারণকারী LE সংযোগযোগ্য বিজ্ঞাপনে ব্লুটুথ অ্যাডাপ্টার প্রোফাইল (BAP 1.0.1) এবং কমন অডিও প্রোফাইলের আবশ্যকতা মেনে CAS UUID অন্তর্ভুক্ত থাকতে হবে।

প্রোভাইডার, ডিসকভারেবল মোড নির্বিশেষে, সার্ভিস ডেটা (AD টাইপ 0x16) অথবা ১৬-বিট সার্ভিস ক্লাস UUID-সমূহে (AD টাইপ 0x02 বা 0x03) CAS UUID (0x1853) অন্তর্ভুক্ত করার মাধ্যমে LEA সক্ষমতা নির্দেশ করতে পারে।

নন-ডিসকভারেবল অ্যাডভার্টাইজমেন্টের ক্ষেত্রে, যদি ব্যাটারি এবং SASS ডেটা অন্তর্ভুক্ত থাকার কারণে লেগ্যাসি অ্যাডভার্টাইজমেন্টে পর্যাপ্ত জায়গা না থাকে, তাহলে স্ক্যান রেসপন্সে CAS UUID অন্তর্ভুক্ত করা বাধ্যতামূলক।

LEA বন্ডিং ক্ষমতা

সিকারকে অবশ্যই বিদ্যমান LE কানেকশনের সাথে বন্ড তৈরি করতে হবে। ফাস্ট পেয়ার কী-ভিত্তিক পেয়ারিং ভেরিফিকেশন সফলভাবে সম্পন্ন করার পর, ডুয়াল মোড প্রোভাইডার আইডেন্টিটি অ্যাড্রেস এবং RPA-এর সাথে বন্ডিংয়ের অনুমতি দেবে, অপরদিকে নন-ডুয়াল মোড প্রোভাইডার শুধু RPA-এর সাথে বন্ডিংয়ের অনুমতি দেবে এবং ফাস্ট পেয়ার পাসকী ভেরিফিকেশনের জন্য IO ক্যাপাবিলিটি DisplayYesNo-তে সেট করবে।

উপাদানগুলির মধ্যে অভ্যন্তরীণ যোগাযোগ চ্যানেল

অতিরিক্ত কম্পোনেন্টগুলোর উপর MITM সুরক্ষা প্রদানের জন্য বিদ্যমান GATT সংযোগটি রাখা হয়। প্রাথমিক বন্ডেড কম্পোনেন্টটি ফাস্ট পেয়ার সিকার এবং এর অবশিষ্ট কম্পোনেন্টগুলোর মধ্যে বার্তা আদান-প্রদানের কাজটি পরিচালনা করবে।

অভ্যন্তরীণ যোগাযোগটি Initial Pair এবং Subsequent Pair জন্য ব্যবহৃত হয়।

  • যখন কী-ভিত্তিক পেয়ারিং প্রক্রিয়াটি প্রাথমিক কম্পোনেন্টে পৌঁছায়, তখন প্রাথমিক কম্পোনেন্টটি তার অবশিষ্ট কম্পোনেন্টগুলোর IO সক্ষমতা পরিবর্তন করার জন্য একটি বার্তা পাঠাবে।
  • ফাস্ট পেয়ার সম্পন্ন হলে, প্রাথমিক কম্পোনেন্টটি তার অবশিষ্ট কম্পোনেন্টগুলোর IO সক্ষমতা রিসেট করার জন্য একটি বার্তা পাঠাবে।
  • অতিরিক্ত পাসকি পদ্ধতি চালানোর সময়, প্রাথমিক উপাদানটি ফাস্ট পেয়ার সিকার এবং এর বাকি উপাদানগুলির মধ্যে পাসকি সরবরাহ পরিচালনা করবে।

IO ক্ষমতা পরিবর্তন করার সময় এসেছে

  • কী-ভিত্তিক পেয়ারিং প্রক্রিয়া সম্পন্ন হলে IO ক্ষমতা DisplayYesNo-তে পরিবর্তন করুন।
    • ডিভাইসটিতে একাধিক উপাদান থাকলে, সমস্ত উপাদানকে DisplayYesNo-তে সেট করতে হবে।
    • একটি ব্যতিক্রম হলো Retroactive Pair , যার ক্ষেত্রে প্রোভাইডার IO ক্যাপাবিলিটি DisplayYesNo-তে পরিবর্তন করবে না এবং যার কী-ভিত্তিক পেয়ারিং রিকোয়েস্টের বিট ৩-এর মান ১-এ সেট করা থাকে; দেখুন সিকার থেকে প্রোভাইডারের কাছে পাঠানো বার্তা।
  • IO ক্ষমতা ডিফল্ট সেটিং-এ পরিবর্তন করুন
    • প্রাথমিক জোড়
      • যদি LE সংযোগ বিচ্ছিন্ন হয়ে যায়, তাহলে ফাস্ট পেয়ার সেশনটি শেষ করুন।
      • প্রাইমারি বন্ডেড হওয়ার পর, ১৫ সেকেন্ডের মধ্যে যদি কোনো অতিরিক্ত পাসকি রাইট রিকোয়েস্ট না আসে, তাহলে ফাস্ট পেয়ার সেশনটি শেষ করে দিন।
      • অতিরিক্ত পাসকি লেখার অনুরোধ পাওয়ার পর, যদি সংযুক্ত হতে থাকা কম্পোনেন্টটি ১৫ সেকেন্ডের মধ্যে সংযুক্ত না হয়, তাহলে ফাস্ট পেয়ার সেশনটি শেষ করে দিন।
      • সমস্ত কম্পোনেন্ট সংযুক্ত হওয়ার পর, ১৫ সেকেন্ডের মধ্যে কোনো অ্যাকাউন্ট কী লেখার অনুরোধ না এলে ফাস্ট পেয়ার সেশনটি শেষ করে দিন।
      • অ্যাকাউন্ট কী লেখার অনুরোধ পাওয়ার পর, ফাস্ট পেয়ার সেশনটি শেষ করার জন্য ১৫ সেকেন্ডের টাইমআউট সেট করুন।
    • পরবর্তী জোড় বাঁধা
      • যদি LE সংযোগ বিচ্ছিন্ন হয়ে যায়, তাহলে ফাস্ট পেয়ার সেশনটি শেষ করুন।
      • প্রাইমারি বন্ডেড হওয়ার পর, ১৫ সেকেন্ডের মধ্যে যদি কোনো অতিরিক্ত পাসকি রাইট রিকোয়েস্ট না আসে, তাহলে ফাস্ট পেয়ার সেশনটি শেষ করে দিন।
      • অতিরিক্ত পাসকি লেখার অনুরোধ পাওয়ার পর, যদি সংযুক্ত হতে থাকা কম্পোনেন্টটি ১৫ সেকেন্ডের মধ্যে সংযুক্ত না হয়, তাহলে ফাস্ট পেয়ার সেশনটি শেষ করে দিন।
      • যখন সমস্ত উপাদান সংযুক্ত হয়ে যাবে, তখন ফাস্ট পেয়ার সেশনটি শেষ করুন।

UI ইঙ্গিত লুকান

যখন হেডসেটটি পেয়ারিংয়ের জন্য প্রস্তুত থাকবে না, তখন প্রোভাইডার পরবর্তী পেয়ারিং UI প্রদর্শন না করার জন্য সিকারকে নির্দেশ দিতে অ্যাকাউন্ট কী ডেটার জন্য UI লুকানোর ইঙ্গিত সেট করতে type 0b0010 ব্যবহার করবে (দেখুন অ্যাডভার্টাইজিং পেলোড: ফাস্ট পেয়ার অ্যাকাউন্ট ডেটা )।

LE অডিও ডিভাইসের প্রয়োজনীয়তা

ব্লুটুথের প্রয়োজনীয়তা

অ্যান্ড্রয়েড, এলই অডিও হেডসেটের সুপারিশগুলো দেখুন।

সিটিকেডি সাপোর্ট

ডুয়াল মোড ডিভাইসের ক্ষেত্রে, LE থেকে BR/EDR পর্যন্ত CTKD বাধ্যতামূলক এবং এটি BAP-এর প্রয়োজনীয়তার সাথে সঙ্গতিপূর্ণ।

লক্ষ্য ঘোষণা

একটি পেরিফেরাল ডিভাইস একটি পেয়ার করা সেন্ট্রাল ডিভাইস থেকে সংযোগ আহ্বান করার জন্য টার্গেটেড অ্যানাউন্সমেন্ট ব্যবহার করবে। CAP 1.0 টেবিল 8.4 (পৃষ্ঠা 48/58) অনুযায়ী, সংযোগ ব্যবস্থাপনার জন্য BAP এবং CAP-এ টার্গেটেড অ্যানাউন্সমেন্ট-এর সংজ্ঞা দেওয়া হয়েছে।

GATT EATT সার্ভার সমর্থন

যখন ডিভাইসটি বন্ডেড থাকে, তখন EATT কেন্দ্রীয় ডিভাইসটিকে সমান্তরালভাবে একাধিক GATT ট্রানজ্যাকশন পাঠাতে দেয়। CSIP সমর্থনকারী ডিভাইসের ক্ষেত্রে, এটি প্রোফাইল কানেকশনের পারফরম্যান্স বৃদ্ধি করে এবং তারপরে শীঘ্রই অন্যান্য বাডগুলোর জন্য CSIP বন্ডিং প্রক্রিয়া শুরু করে।

যদি প্রোভাইডারটি কোনো একক ডিভাইস না হয়ে CSIP বাস্তবায়নসহ একটি সমন্বিত সেট হয়, তাহলে সার্ভিস ডিসকভারির সংখ্যা কমাতে এবং সংযোগের গতি বাড়াতে প্রোভাইডারটির ব্লুটুথ ৫.১-এ সংজ্ঞায়িত GATT ক্যাশিং বাস্তবায়ন করা উচিত।

দ্রুত জোড়া লাগানোর প্রয়োজনীয়তা

এলই বিজ্ঞাপন

ডিসকভারেবল মোড বা নন-ডিসকভারেবল মোডের ক্ষেত্রে, যদি ডিভাইসটিতে একাধিক কম্পোনেন্ট থাকে, তবে প্রাইমারি কম্পোনেন্টটি ফাস্ট পেয়ার ডেটা অ্যাডভার্টাইজ করবে। যদি ডিভাইসটি পরবর্তী পেয়ারিংয়ের জন্য প্রস্তুত না থাকে, তবে সেকেন্ডারি কম্পোনেন্টটি বর্ধিত ফিচারগুলোর জন্য ফাস্ট পেয়ার ডেটা অ্যাডভার্টাইজ করতে পারে। ‘হাইড UI ইন্ডিকেশন’ দেখুন।

গ্যাট পরিষেবা দৃশ্যমানতা

সকল LE ট্রান্সপোর্ট GATT সংযোগের জন্য GATT ডাটাবেস একই হবে। LE অডিও পরিষেবা (0x184E) ফাস্ট পেয়ার সংযোগের GATT ডাটাবেসে অন্তর্ভুক্ত থাকবে।

উদাহরণ: LEA ডুয়াল মোড প্রোভাইডারের সাথে পেয়ারিং

দৃশ্যকল্প ১ - যখন অনুসন্ধানকারী LEA সমর্থন করে না

প্রোভাইডারকে অবশ্যই সেই সিকারের সাথে ব্যাকওয়ার্ড কম্প্যাটিবিলিটি বজায় রাখতে হবে যা LEA সমর্থন করে না।

উপাদান
  • প্রদানকারী: A2DP/HFP/LEA
  • অনুসন্ধানকারী: A2DP/HFP
প্রাথমিক জোড়া / পরবর্তী জোড়ার জন্য প্রত্যাশিত আচরণ
  • প্রোভাইডার আইডেন্টিটি অ্যাড্রেস (প্রাথমিক) বা আরপিএ (পরবর্তী) সহ ফাস্ট পেয়ার পরিষেবা ডেটা (0xFE2C) প্রচার করে।
    • লিগ্যাসি বিজ্ঞাপন ব্যবহার করুন
  • সিকার প্রাথমিক বা পরবর্তী পেয়ারিংয়ের জন্য আইডেন্টিটি অ্যাড্রেস সহ প্রোভাইডারের অ্যাডভার্টাইজমেন্ট গ্রহণ করে।
  • অনুসন্ধানকারী কী-ভিত্তিক পেয়ারিং অনুরোধ পাঠায়
    • কী-ভিত্তিক পেয়ারিং অনুরোধের ফ্ল্যাগ বিট-৫ এর মান ০ সেট করা হয়।
  • প্রোভাইডার নিম্নলিখিতগুলির মধ্যে যেকোনো একটিতে পাবলিক অ্যাড্রেস সহ কী-ভিত্তিক পেয়ারিং প্রতিক্রিয়া পাঠায়:
    • যদি মেসেজ টাইপ 0x01 ব্যবহার করা হয়, তাহলে অ্যাড্রেসটি পাবলিক অ্যাড্রেস হবে।
    • যদি বার্তা প্রকার 0x02 ব্যবহার করা হয়
      • বিট-০ এর মান হবে ০
      • বিট-১ এর মান ০ হবে
      • ঠিকানাটি সর্বজনীন ঠিকানা হবে।
  • দ্য সিকার বিআর/ইডিআর পরিবহনের সাথে বন্ধন তৈরি করে।
    • BR/EDR-এর জন্য IO সক্ষমতা DisplayYesNo-তে সেট করা আছে।
  • অনুসন্ধানকারী এবং প্রদানকারী ফাস্ট পেয়ার পাসকি যাচাইকরণ প্রক্রিয়া সম্পন্ন করে।

দৃশ্যকল্প ২ - যখন অনুসন্ধানকারী LEA-কে সমর্থন করে

উপাদান
  • সরবরাহকারী
    • A2DP/HFP/LEA সমর্থন করুন
    • একক উপাদান
  • অনুসন্ধানকারী
    • SupportA2DP/HFP/LEA
প্রাথমিক জোড়া / পরবর্তী জোড়ার জন্য প্রত্যাশিত আচরণ
  • প্রোভাইডার আইডেন্টিটি অ্যাড্রেস (প্রাথমিক) বা আরপিএ (পরবর্তী) সহ ফাস্ট পেয়ার পরিষেবা ডেটা (0xFE2C) প্রচার করে।
    • লিগ্যাসি বিজ্ঞাপন ব্যবহার করুন
  • অনুসন্ধানকারী কী-ভিত্তিক পেয়ারিং অনুরোধ পাঠায়
    • কী-ভিত্তিক পেয়ারিং অনুরোধের ফ্ল্যাগ বিট-৫ এর মান ১ এ সেট করা হয়।
  • প্রোভাইডার 0x02 মেসেজ টাইপ সহ কী-ভিত্তিক পেয়ারিং প্রতিক্রিয়া পাঠায়।
    • বিট-০ এর মান হবে ০
    • বিট-১ হবে ১
    • ঠিকানাটি হলো পরিচয় ঠিকানা
  • সিকারটি LE ট্রান্সপোর্টে বিদ্যমান LE সংযোগের সাথে বন্ড তৈরি করে।
    • CTKD-এর দিক LE থেকে BR/EDR পর্যন্ত।
    • LE-এর জন্য IO সক্ষমতা DisplayYesNo-তে সেট করা আছে।
  • অনুসন্ধানকারী এবং প্রদানকারী ফাস্ট পেয়ার পাসকি যাচাইকরণ প্রক্রিয়া সম্পন্ন করে।

দৃশ্যকল্প ৩ - যখন অনুসন্ধানকারী LEA এবং CSIP জড়িত থাকাকে সমর্থন করে

উপাদান
  • সরবরাহকারী
    • A2DP/HFP/LEA সমর্থন করুন
    • একাধিক উপাদান
      • প্রাথমিক উপাদান হল BR/EDR/LE
      • দ্বিতীয় উপাদানটি শুধুমাত্র LE-এর জন্য।
  • অনুসন্ধানকারী
    • A2DP/HFP/LEA সমর্থন করুন
প্রাথমিক জোড়া / পরবর্তী জোড়ার জন্য প্রত্যাশিত আচরণ
  • প্রাথমিক উপাদানটি আইডেন্টিটি অ্যাড্রেস (প্রাথমিক) বা আরপিএ (পরবর্তী) সহ ফাস্ট পেয়ার পরিষেবা ডেটা (0xFE2C) প্রচার করে।
    • লিগ্যাসি বিজ্ঞাপন ব্যবহার করুন
  • সিকার প্রাথমিক কম্পোনেন্টের কাছে কী-ভিত্তিক পেয়ারিং অনুরোধ পাঠায়।
    • কী-ভিত্তিক পেয়ারিং অনুরোধের ফ্ল্যাগ বিট-৫ এর মান ১ এ সেট করা হয়।
  • প্রাথমিক উপাদানটি 0x02 বার্তা প্রকার সহ একটি কী-ভিত্তিক পেয়ারিং প্রতিক্রিয়া পাঠায়।
    • বিট-০ এর মান হবে ০
    • বিট-১ হবে ১
    • ঠিকানাগুলো নিচে দেওয়া হলো :
      • প্রথম ঠিকানাটি হলো প্রাথমিক উপাদানের পরিচয় ঠিকানা।
      • দ্বিতীয় অ্যাড্রেসটি হলো সেকেন্ডারি কম্পোনেন্টের জন্য বন্ডেবল অ্যাড্রেস, এবং সেকেন্ডারি কম্পোনেন্টটি CSIP অ্যাডভার্টাইজমেন্ট করার জন্যও এই অ্যাড্রেসটি ব্যবহার করে।
  • সিকারটি বিদ্যমান LE সংযোগে প্রাথমিক উপাদানের সাথে বন্ধন তৈরি করে।
    • CTKD-এর দিক LE থেকে BR/EDR পর্যন্ত।
    • LE-এর জন্য IO সক্ষমতা DisplayYesNo-তে সেট করা আছে।
  • সিকার সেকেন্ডারি কম্পোনেন্টের সাথে বন্ড তৈরি করে, যার অ্যাড্রেসটি কী-বেসড পেয়ারিং এক্সটেন্ডেড রেসপন্স থেকে প্রাপ্ত।
    • IO সক্ষমতা অবশ্যই DisplayYesNo হতে হবে, অন্যথায় পেয়ারিং অনুরোধটি প্রত্যাখ্যান করা হবে।
  • অনুসন্ধানকারী এবং প্রদানকারী গৌণ উপাদানটি জোড়া লাগানোর জন্য MITM সুরক্ষা পদ্ধতি অনুসরণ করে, প্রদানকারী উভয় পরিস্থিতিতেই তা বাস্তবায়ন করবে।
  • অনুসন্ধানকারী দ্বিতীয় উপাদানটির সাথে সংযুক্ত না হওয়া পর্যন্ত অপেক্ষা করে।

MITM-এর জন্য অনুক্রমিক ডায়াগ্রাম

এই সেশনের উদ্দেশ্য হলো MITM সুরক্ষা পদ্ধতির ক্রম বর্ণনা করা।

নোটিফিকেশনের মাধ্যমে সংযুক্ত করা হচ্ছে এমন কম্পোনেন্ট থেকে পাসকি নিন।

রিডের মাধ্যমে বন্ড করা কম্পোনেন্ট থেকে পাসকি নিন।

পরিচিত সমস্যা

FP for LEA-কে Android V (Android 15)-এর সাথে কাজ করার জন্য অপ্টিমাইজ করা হয়েছে।

অন্যদিকে, আমরা এমন অনেক হেডসেটের ক্ষেত্রে সমস্যার সম্মুখীন হয়েছি যেগুলো LEA সাপোর্ট করলেও সেগুলোতে সঠিক Fast Pair over LEA ইমপ্লিমেন্টেশন নেই (অর্থাৎ শুধু Fast Pair over Classic রয়েছে)। বিশেষ করে, উদাহরণস্বরূপ, যখন প্রোভাইডারের RPA সঠিক Identity Resolving Key (IRK) দ্বারা জেনারেট করা হয় না এবং অ্যাড্রেসটি রিজলভ করা যায় না। যদিও আমরা সব ধরনের হেডসেট কনফিগারেশনের একটি সম্পূর্ণ তালিকা পরীক্ষা করতে পারিনি, আমাদের সীমিত পরীক্ষায় বিভিন্ন সমস্যা উঠে এসেছে, যার মধ্যে রয়েছে ইয়ারবাডের ব্যাটারি নোটিফিকেশন দেখাতে ব্যর্থ হওয়া, Audio Switching (SASS) ফাংশনালিটির অভাব, ব্যাপক হারে প্রাথমিক ও পরবর্তী পেয়ারিং ব্যর্থতা এবং আরও অনেক কিছু।

অতএব, আমরা অংশীদারদের জোরালোভাবে পরামর্শ দিচ্ছি যেন তারা ডুয়াল মোড সমর্থনকারী নতুন এবং বিদ্যমান উভয় ডিভাইসের জন্যই (ওভার-দ্য-এয়ার আপডেটের মাধ্যমে) ফাস্ট পেয়ার-এলইএ স্পেসিফিকেশনটি বাস্তবায়ন করেন।