بدء مشاركة خطة بيانات الجوّال

المصطلحات

  • GTAF: وظيفة تطبيق حركة المرور من Google إحدى خدمات Google التي تنفّذ واجهة برمجة التطبيقات الخاصة بمشاركة خطط البيانات وتتفاعل مع مشغّلي شبكات الجوّال نيابةً عن تطبيقات Google يمكن لتطبيقات Google طلب معلومات خطة البيانات الخاصة بالمستخدم من GTAF. بدلاً من ذلك، إذا سجّلت تطبيقات Google بياناتها لدى GTAF، يمكن أن يرسل GTAF تحديثات حول خطة بيانات المستخدم.
  • MSISDN: رقم دليل المشتركين الدوليين في محطات الجوّال، وهو رقم يحدّد بشكل فريد اشتراكًا في شبكة جوّالة. ويُعرف هذا المعرّف باسم رقم الهاتف.
  • نقطة نهاية CPID: هي خدمة ينفّذها مشغّلو شبكات الجوّال وتنشئ معرّف خطة مشغّل شبكة الجوّال (CPID) يمكن استخدامه للبحث عن معلومات خطة بيانات المستخدم. يتيح معرّف CPID لأي تطبيق إمكانية طلب تفاصيل خطة بيانات المستخدم بدون الوصول إلى رقم MSISDN الخاص به. نوضّح أدناه إجراءات إنشاء معرّفات CPID.
  • مفتاح المستخدم: مفتاح المستخدم هو سلسلة يمكن استخدامها لتحديد خطة بيانات المستخدم. يمكن أن يكون هذا المعرّف هو CPID أو MSISDN للتطبيقات التي يمكنها الوصول إلى رقم MSISDN.
  • وكيل خطة البيانات (DPA): هي خدمة تنفّذها شركات تشغيل شبكات الجوّال وتشارك معلومات خطة بيانات المستخدم مع "إطار عمل Google للوصول إلى الإنترنت". يمكن لمزوّد خدمة البيانات مشاركة المعلومات مع GTAF من خلال استخدام مزيج من إرسال البيانات باستخدام Google Mobile Data Plan Sharing API وتنفيذ Data Plan Agent API. يمكن أن يعمل DPA كنقطة نهاية CPID أيضًا بشكل اختياري.
  • UE: الجهاز الذي يستخدمه المستخدم.

لغة المتطلبات

يجب تفسير الكلمات الرئيسية "يجب" و"يجب ألا" و"مطلوب" و"يجب" و"يجب ألا" و"يُستحسن" و"لا يُستحسن" و"موصى به" و"يجوز" و "اختياري" الواردة في هذه الأدلة على النحو الموضّح في RFC 2119.

Mobile Data Plan Sharing

بشكل عام، تتضمّن ميزة "مشاركة خطة بيانات الجوّال" ثلاثة أجزاء:

  1. آلية لإنشاء وتعديل معرّف خطة مشغّل شبكة الجوّال (CPID) يمكن استخدامه كمفتاح مستخدم يمكن للتطبيقات التي يمكنها الوصول إلى رقم MSISDN استخدامه كمفتاح مستخدم.
  2. واجهة برمجة تطبيقات لمشاركة خطة البيانات على الأجهزة الجوّالة من Google تتيح لمشغّل شبكة الجوّال إرسال معلومات حول خطة بيانات المستخدم إلى Google على سبيل المثال، إذا أراد شريك المعالجة إعلام المستخدم بعرض ترويجي، يمكنه إعلام إطار عمل GTAF الذي يرسل بدوره إشعارًا إلى المستخدم.
  3. واجهة برمجة تطبيقات لوكيل خطة البيانات تنفّذها "وكالة خطة البيانات" وتسمح لـ GTAF بالاستعلام من "وكالة خطة البيانات" عن معلومات حول خطة بيانات المستخدم. على سبيل المثال، إذا أراد أحد التطبيقات عرض رصيد خطة البيانات الحالية للمستخدم، يمكنه طلب البحث من GTAF الذي يطلب البحث بدوره من DPA.

توضّح بقية هذه الصفحة مصطلحات خطة البيانات وتفاصيل كيفية إنشاء معرّف CPID. في ما يلي مواصفات Google Mobile Data Plan Sharing API وData Plan Agent API.

مصطلحات خطة البيانات

يجب أن يكون مخطط planStatus المحدّد في واجهة برمجة التطبيقات قادرًا على تمثيل خطط البيانات التي يقدّمها مشغّلو شبكات الجوّال للمستخدمين. تتيح واجهة برمجة التطبيقات تحديد خطط بيانات تفرض على المستخدمين رسومًا مختلفة على جميع الزيارات إلى مجموعة معيّنة من عناوين URL (على سبيل المثال، يتم فرض رسوم مختلفة على جميع الزيارات إلى ‎ *.acmefake.com). تتيح واجهة برمجة التطبيقات أيضًا خطط البيانات التي توفّر أسعارًا مختلفة لأنواع معيّنة من الإجراءات في التطبيق. ونطلق على هذه الخطط اسم خطط بيانات التطبيقات الفرعية. ومن الأمثلة على خطط بيانات التطبيقات الفرعية توفير تصفّح مجاني للفيديوهات (أي بدون رسوم)، بينما يؤدي مشاهدة الفيديوهات داخل التطبيق إلى خصم البيانات من رصيد بيانات المشترك. يجب أن يتمكّن تطبيق الفيديو بعد ذلك من التعرّف على هذه المعلومات عند طلب معلومات عن خطة البيانات.

في ما يلي، نقدّم بعض المصطلحات المتعلقة بباقات البيانات. يقدّم الشكل 1 أمثلة على باقات البيانات التي تمثّل المفاهيم التي نريد توضيحها.

خطة البيانات: هي حزمة خدمة الجوّال ذات المستوى الأعلى التي يشتريها المشترك. يمكن أن يكون بسيطًا مثل "10 غيغابايت من بيانات الجوّال لمدة 30 يومًا" أو يمكن تعريفه على أنّه مجموعة من المكوّنات، تُعرف أيضًا باسم الوحدات. تتضمّن خطة البيانات ما يلي:

  • اسم خطة البيانات، مثل "ACME Red"
  • معرّف خطة البيانات، ويُستخدَم للإشارة إلى الخطة، مثلاً أثناء عمليات الشراء
  • وقت انتهاء الصلاحية، وهو الوقت الذي تنتهي فيه صلاحية خطة البيانات.
  • فئة الخطة، سواء كانت خطة دفع مُسبَق أو خطة دفع لاحق.

وحدة الخطة: هي أحد مكونات خطة البيانات. تتضمّن وحدة الخطة ما يلي:

  • اسم الوحدة، مثل "ليالي مشاهدة الفيديو مجانًا"
  • الحد الأقصى لمعدّل نقل البيانات: معدّل نقل البيانات الذي توفّره هذه الوحدة للمستخدم.
  • فترات الوقت المرنة: هي فترات زمنية يمكن خلالها تقديم خصم للمستخدم.

  • فئة زيارات وحدة الخطة (PMTC): وصف لزيارات البيانات التي تنطبق عليها الوحدة. يمكن أن يكون مقياس PMTC عامًا مثل *كل زيارات الإنترنت *أو محدّدًا مثل الزيارات التي يتم إنشاؤها/استهلاكها من خلال تطبيق واحد أو أكثر أو مواقع إلكترونية أو حتى رحلات المستخدمين داخل تطبيق واحد. تشمل أمثلة هذا النوع الأخير "موسيقى غير محدودة" و"حزمة بيانات فيديو بسعة 100 ميغابايت (VDP)" و"بيانات ألعاب غير محدودة" و "تصفّح فيديوهات غير محدود". لتسهيل تحديد فئات PMTC، حدّدنا فئات PMTC التالية: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE1, MUSIC, GAMING, SOCIAL, MESSAGING وPMTC_UNSPECIFIED.

  • حجم البيانات أو الحدّ الزمني: بعد تفعيل وحدة الخطة، تنتهي صلاحيتها عند استيفاء أحد الشرطين، أي حجم البيانات أو الحدّ الزمني (في حالة الخطط المستندة إلى الوقت، مثل تجاوزت 600 دقيقة من استخدام الإنترنت خلال الأيام السبعة القادمة. في الشكل 1 أدناه، يمكن للمشترك شراء وحدة خطة، كجزء من "ACME Blue"، توفّر 1 غيغابايت من زيارات المستخدمين العامة التي يجب استخدامها في غضون أسبوع من التفعيل قبل انتهاء صلاحيتها.

خطة نموذجية لواجهة Data Plan API

الشكل 1. خطط بيانات نموذجية

إنشاء CPID

تستخدم إطار عمل GTAF مفتاح المستخدم لتحديد المشترك عند التواصل مع DPA. يمكن للتطبيقات التي يمكنها الوصول إلى رقم MSISDN الخاص بالمستخدم استخدام هذا الرقم كـ user_key. من ناحية أخرى، تحتاج التطبيقات التي لا يمكنها الوصول إلى رقم MSISDN إلى إنشاء معرّف خطة مشغّل شبكة الجوّال (CPID) بدون الكشف عن رقم MSISDN الخاص بالمستخدم. في ما يلي، سنشرح الآلية التي تحدّد معرّف CPID.

مسار مكالمة CPID

الشكل 2: مسار المكالمة لإنشاء CPID

  1. يستخدم أحد تطبيقات Google في الجهاز تطبيقًا داخليًا من Google لواجهة برمجة التطبيقات من أجل استرداد عنوان URL لنقطة نهاية CPID من GTAF. يتم تحديد هوية مشغّل شبكة الجوّال باستخدام عنوان IP العام الخاص بالجهاز ورمز البلد (MCC) ورمز شبكة الجوّال (MNC) لشريحة SIM النشطة. في حالة مشغّلي شبكات الجوّال الافتراضية (MVNO)، سيستخدم Google اسم موفّر الخدمة (SPN) وGID1 لتحديد مشغّل شبكة الجوّال الافتراضية.
  2. يرسل العميل طلب GET HTTP إلى نقطة نهاية CPID. يمكن للمشغّل إتاحة إرسال الطلب عبر HTTPS.
  3. يجوز للمشغّل استخدام وظيفة فحص الحزمة الكاملة لتحديد الطلب وإدراج رقم هاتف المستخدم في الطلب كعنوان HTTP.
  4. تتلقّى نقطة نهاية CPID الطلب، وتنشئ CPID، وتعرض CPID لجهاز المستخدم مع وقت البقاء (TTL) الذي يوضّح المدة التي يمكن لجهاز المستخدم استخدام CPID خلالها.

يمكن للمشغّل أيضًا استخدام عناوين IP بدلاً من أسماء النطاقات في عنوان URL لنقطة نهاية CPID إذا كان ذلك مفضّلاً. قد تكون عناوين IP في مساحة عناوين خاصة، ولكن يجب أن تكون متاحة لعملاء Google داخل شبكة المشغّل.

على المشغّل تقديم المعلومات التالية إلى Google كجزء من عملية الإعداد: 1. عنوان URL الخاص بمعرّف الشريك (CPID_URL) الذي ستتواصل معه التطبيقات للحصول على معرّفات الشركاء. عنوان CPID_URL واحد إلزامي، ولكن يمكن للمشغّل تقديم عناوين URL متعددة لزيادة التوفّر. 1. قائمة بادئات عناوين IP التي يملكها المشغّل ورمز البلد الذي يتمّ فيه تشغيل شبكة الجوّال (MCC) ورموز الشبكة التي يتمّ فيها تشغيل شبكة الجوّال(MNC) التي يريد المشغّل ربطها بعناوين URL الخاصة بمعرّف مقدّم المحتوى (CPID) المقدَّمة إذا كان مشغّل الشبكة يستخدم اسم موفّر الخدمة (SPN) أو المعرّف GID1 للتمييز بين مشغّلي شبكات الجوّال الافتراضية (MVNO) في شبكته، عليه تقديم هذه المعلومات أيضًا. ستستخدم Google هذه المعلومات لمطابقة العملاء مع نقاط نهاية CPID المقابلة، كما هو موضّح في الخطوة 1 من الشكل 2.

يكون تنسيق الطلب كما يلي: GET CPID_URL لأسباب قديمة، يجب أن تكون نقطة نهاية CPID قادرة على التعامل مع طلب مثل ما يلي:

GET CPID_URL?app={app_id}

يمكن لنقطة نهاية CPID تجاهل مَعلمة عنوان URL {app_id} عند إنشاء CPID. ومع ذلك، يجب أن يكون قادرًا على التعامل مع طلب يحتوي على المَعلمة.

قد يتضمّن الطلب إلى نقطة نهاية CPID العنوان Accept-Language. في حال تضمين العنوان، يجب أن تستخدم السلاسل القابلة للقراءة في التحديثات التي يرسلها DPA باستخدام Mobile Data Plan Sharing API الإعدادات المتوفّرة في طلب CPID.

في كل مرة يرسل فيها العميل طلب GET CPID_URL، يجب أن يتلقّى معرّفًا جديدًا. إذا تم إنشاء CPID بنجاح، يجب أن يعرض نقطة نهاية CPID استجابة 200 OK. يجب أن يحتوي نص الاستجابة على مثال CPIDResponse.

{
    "cpid": "<CPID_string>",
    "ttlSeconds": 2592000
}

يجب أن يكون معرّف المحتوى الذي تم إرجاعه صالحًا لمدة ttlSeconds ثانية. ستعمل GTAF على ترميز معرّف CPID وفقًا RFC2396 في المكالمات اللاحقة إلى DPA.

في حال حدوث خطأ، يجب أن تعرض نقطة نهاية CPID خطأ HTTP مع نص استجابة يجب أن يحتوي على مثال ErrorResponse. تتوفّر قائمة بقيم السبب المحتملة ورموز أخطاء HTTP هنا.

{
    "errorMessage": "<error message>",
    "cause": "INVALID_NUMBER"
}

على وجه الخصوص، إذا تم تلقّي طلب CPID لمستخدم لا ينتمي إلى شبكة المشغّل (على سبيل المثال، مستخدم ينتمي إلى مشغّل آخر ولكنّه يتجوّل على الشبكة التي يقدّمها نقطة نهاية CPID هذه) أو لم يوافق على مشاركة معلومات خطة البيانات مع Google، يجب أن تعرض نقطة نهاية CPID رمز حالة HTTP 403.

إنشاء معرّف CPID

الطريقة المُقترَحة التي يمكن لنقطة نهاية CPID اتّباعها لإنشاء CPID هي:

CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))

تجمع نقطة نهاية CPID بين رقم MSISDN واللغة التي يرسلها العميل في عنوان Accept-Language وطابع زمني عالي الدقة، ثم تشفّرها باستخدام خوارزمية AES وباستخدام secretkey. يجب أن يتوافق الطابع الزمني مع وقت انتهاء صلاحية معرّف المحتوى الشريك (CPID). ويتم ترميز الناتج المشفّر باستخدام Base64. بالإضافة إلى ذلك، عند استخدام معرّف المحتوى الخاص بالشريك في عنوان URL، يجب أن يكون عنوان URL بترميز عنوان URL للتعامل مع الأحرف الخاصة (/+=) المستخدَمة في Base64. ويجب أن يكون معرّف الشريك (CPID) بترميز عنوان URL، خاصةً عندما تستدعي أداة GTAF "اتفاقية معالجة البيانات" أو عندما تستدعي "اتفاقية معالجة البيانات" واجهة برمجة التطبيقات "مشاركة خطة بيانات الجوّال". من مزايا إنشاء CPID باستخدام هذا النهج أنّه ليس من الضروري أن يتضمّن كل من نقطة نهاية DPA ونقطة نهاية CPID قاعدة بيانات تتضمّن أرقام CPID وأرقام MSISDN صالحة.

بناءً على حالة مشغّل معيّن، قد يكون من الصعب تنفيذ نقطة نهاية CPID. من التحديات التي نواجهها بشكل متكرر عدم توفّر إمكانية الوصول إلى رقم MSISDN في نقطة نهاية CPID. يسرّنا أن نشاركك الدروس المستفادة من عملية إعداد المشغّلين. يُرجى التواصل معنا إذا واجهت أي مشاكل.

متطلبات الأمان

على مشغّل الشبكة اتّخاذ جميع الاحتياطات اللازمة لحماية المعلومات الخاصة بالمشتركين. على وجه التحديد، للحدّ من تعرّض أرقام هواتف المشتركين، يجب أن تكون نقطة نهاية CPID داخل محيط الأمان. علاوةً على ذلك، في الحالات التي يستخدم فيها مشغّل الشبكة فحص الحزمة الكاملة (DPI)، يجب أن يشفّر المشغّل رقم MSISDN قبل إضافته إلى طلب HTTP. إذا لم تكن نقطة نهاية CPID هي محيط الأمان (على سبيل المثال، عند نشر نقطة نهاية CPID على سحابة إلكترونية عامة)، يجب ألا ينقل المشغّل رقم MSISDN عبر الإنترنت العام بدون تشفير. يمكن لمشغّل الشبكة إنشاء شبكة VPN بين نقطة نهاية فحص الحزمة الدقيق ونقطة نهاية CPID (راجِع الشكل 1) أو تشفير رقم MSISDN قبل إدراجه في العنوان. يفترض الأسلوب الأخير أنّ نقطة نهاية CPID يمكنها فك تشفير العنوان الذي تم إدخاله لاسترداد رقم MSISDN قبل إنشاء رقم CPID. بالإضافة إلى ذلك، على المشغّل حماية المفتاح السري المستخدَم لإنشاء معرّف المحتوى وتغيير هذا المفتاح وفقًا لسياسات الأمان الخاصة بالمشغّل.

متطلبات التوفّر والسعة

إذا لم يتمكّن العملاء من استرداد معرّف CPID، لن يتمكّنوا من الوصول إلى أي معلومات من واجهة برمجة التطبيقات الخاصة بخطة بيانات الجوّال. لهذا السبب، على المشغّل اتّخاذ التدابير اللازمة لضمان توفّر نقطة نهاية CPID. وتشمل هذه الإجراءات توفير عدة مثيلات لنقطة نهاية CPID ووظائف DPI، وتوفير تكرار مادي وموقعي وشبكي لكلتا الوظيفتين، والتأكّد من كفاية موارد النظام وسعته. بالإضافة إلى ذلك، يجب أن تتوفّر سعة كافية في نقطة نهاية CPID وفي وظيفة DPI التي تُدرِج العنوان للتعامل مع عدد طلبات CPID التي يرسلها جميع عملاء Google. يمكن لنقطة نهاية CPID استخدام قيم أكبر في حقل ttlSeconds لتقليل معدّل تكرار إنشاء CPID. تنصح Google باستخدام قيمة TTL تبلغ 30 يومًا.

ملاحظات

  1. يشير PMTC الخاص بـ VIDEO_OFFLINE إلى أنّ هذه الخطة مناسبة للاستخدام بلا إنترنت فقط (على سبيل المثال، جودة تجربة البث سيئة جدًا). وهي مستقلة عن نافذة FlexTime. ↩