شروع به اشتراک گذاری طرح داده تلفن همراه

واژه شناسی

  • GTAF : عملکرد برنامه ترافیک گوگل. یک سرویس Google که API اشتراک گذاری طرح داده را پیاده سازی می کند و از طرف برنامه های Google با DPA ها تعامل دارد. برنامه‌های Google می‌توانند از GTAF برای اطلاعات طرح داده کاربر درخواست کنند. از طرف دیگر، اگر برنامه‌های Google با GTAF ثبت نام کنند، GTAF می‌تواند به‌روزرسانی‌هایی درباره طرح داده کاربر ارسال کند.
  • MSISDN : شماره دایرکتوری مشترکین بین‌المللی ایستگاه موبایل، شماره‌ای که به طور منحصربه‌فردی اشتراک یک شبکه تلفن همراه را شناسایی می‌کند. بیشتر به عنوان شماره تلفن شناخته می شود.
  • نقطه پایانی CPID : سرویسی است که توسط اپراتورهای شبکه تلفن همراه پیاده‌سازی می‌شود که یک شناسه طرح حامل (CPID) تولید می‌کند که می‌تواند برای جستجوی اطلاعات طرح داده کاربر استفاده شود. CPID به برنامه اجازه می دهد تا جزئیات طرح داده کاربر را بدون دسترسی به MSISDN کاربر جویا شود. ما روش تولید CPID را در زیر توضیح می دهیم.
  • کلید کاربر : کلید کاربر رشته ای است که می تواند برای شناسایی طرح داده کاربر استفاده شود. این می تواند CPID یا MSISDN برای برنامه هایی باشد که به MSISDN دسترسی دارند.
  • DPA : Data Plan Agent، سرویسی است که توسط اپراتورهای شبکه تلفن همراه پیاده‌سازی شده و اطلاعات طرح داده‌های کاربر را با GTAF به اشتراک می‌گذارد. DPA می تواند با استفاده از ترکیبی از ارسال داده با استفاده از Google Mobile Data Plan Sharing API و اجرای Data Plan Agent API اطلاعات را با GTAF به اشتراک بگذارد. DPA می تواند به صورت اختیاری به عنوان نقطه پایانی CPID نیز عمل کند.
  • UE : تجهیزات کاربر، دستگاهی که توسط کاربر استفاده می شود.

زبان مورد نیاز

کلمات کلیدی "باید"، "نباید"، "الزامی"، "باید"، "نباید"، "باید"، "نباید"، "توصیه شده"، "ممکن است" و "اختیاری" در این راهنماها عبارتند از همانطور که در RFC 2119 توضیح داده شده است تفسیر شود.

به اشتراک گذاری طرح داده تلفن همراه

در سطح بالا، اشتراک گذاری طرح داده تلفن همراه شامل سه بخش است:

  1. مکانیزمی برای ایجاد و به روز رسانی شناسه طرح حامل (CPID) که می تواند به عنوان کلید کاربر استفاده شود. برنامه هایی که به MSISDN دسترسی دارند، MSISDN می توانند از آن به عنوان کلید کاربر استفاده کنند.
  2. Google Mobile Data Plan Sharing API که به DPA اجازه می‌دهد اطلاعات مربوط به طرح داده کاربر را به Google ارسال کند. به عنوان مثال، اگر DPA بخواهد کاربر را از یک پیشنهاد مطلع کند، می تواند GTAF را مطلع کند که به نوبه خود به کاربر اطلاع می دهد.
  3. یک Data Plan Agent API که توسط DPA پیاده سازی شده است که به GTAF اجازه می دهد تا اطلاعات مربوط به طرح داده کاربر را از DPA پرس و جو کند. به عنوان مثال، اگر برنامه ای بخواهد موجودی طرح داده فعلی را به کاربر نمایش دهد، می تواند GTAF را پرس و جو کند که به نوبه خود از DPA درخواست می کند.

بقیه این صفحه اصطلاحات طرح داده و جزئیات نحوه ایجاد CPID را معرفی می کند. Google Mobile Data Plan Sharing API و Data Plan Agent API Specification در ادامه آمده است.

اصطلاحات طرح داده

طرح یک planStatus تعریف شده در API باید بتواند طرح های داده ای را که توسط اپراتورها به کاربران ارائه می شود را نشان دهد. API از تعریف طرح‌های داده‌ای پشتیبانی می‌کند که با نرخ متفاوتی برای تمام ترافیک به مجموعه‌ای از URLها از کاربران هزینه می‌کنند (به عنوان مثال، تمام ترافیک *.acmefake.com با نرخ متفاوتی شارژ می‌شود). API همچنین از طرح‌های داده پشتیبانی می‌کند که نرخ‌های متفاوتی را برای انواع خاصی از اقدامات در یک برنامه ارائه می‌دهند. ما به این برنامه های داده فرعی می گوییم. نمونه‌ای از طرح داده‌های زیر برنامه ارائه مرور ویدیویی رایگان (یعنی نرخ صفر) است، در حالی که تماشای ویدیوها در برنامه، داده‌ها را از موجودی داده‌های مشترک کسر می‌کند. سپس برنامه ویدیویی باید بتواند این اطلاعات را هنگام جستجو برای اطلاعات طرح داده یاد بگیرد.

در اینجا برخی از اصطلاحات مربوط به طرح های داده را معرفی می کنیم. شکل 1 نمونه هایی از طرح های داده ای را ارائه می دهد که معرف مفاهیمی هستند که می خواهیم دریافت کنیم.

طرح داده: بسته خدمات تلفن همراه سطح بالا که مشترک خریداری می کند. این می تواند به سادگی "10 گیگابایت داده تلفن همراه برای 30 روز" باشد یا می تواند به عنوان مجموعه ای از مؤلفه ها تعریف شود که به عنوان ماژول نیز شناخته می شود. یک طرح داده دارای:

  • نام طرح داده ، مانند "ACME Red".
  • شناسه طرح داده ، برای ارجاع به طرح، به عنوان مثال در هنگام خرید استفاده می شود.
  • زمان انقضا ، زمانی که طرح داده منقضی می شود.
  • دسته بندی طرح ، چه طرح یک طرح پیش پرداخت باشد یا یک طرح پس پرداخت.

ماژول پلان: جزء یک طرح داده. به طور خاص یک ماژول پلان دارای:

  • نام ماژول ، مانند "شب های ویدیوی رایگان".
  • حداکثر نرخ ، پهنای باندی که توسط این ماژول به کاربر ارائه می شود.
  • Flex Time Windows ، پنجره های زمانی که در طی آن می توان به کاربر تخفیف ارائه داد.

  • دسته ترافیک ماژول طرح (PMTC) ، شرحی از ترافیک داده ای که یک ماژول برای آن اعمال می شود. PMTC می تواند به اندازه *تمام ترافیک اینترنت * یا به اندازه ترافیک ایجاد شده/مصرف شده توسط یک یا چند برنامه کاربردی، وب سایت یا حتی سفرهای کاربر در یک برنامه خاص باشد. نمونه هایی از نوع دوم عبارتند از "موسیقی نامحدود"، "بسته داده های ویدئویی 100 مگابایتی (VDP)"، "داده های بازی نامحدود" و "مرور نامحدود ویدئو". برای تسهیل تعریف PMTC، ما PMTC های زیر را تعریف کرده ایم: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE 1 , MUSIC, GAMING, SOCIAL, MESSAGING MESSAGING و PMTC_UNSPECIFIED.

  • حجم داده یا محدودیت زمانی ، پس از فعال شدن، زمانی که حجم داده یا محدودیت زمانی (در مورد برنامه های مبتنی بر زمان، به عنوان مثال، 600 دقیقه دسترسی به اینترنت در 7 روز آینده) فراتر رود، ماژول طرح منقضی می شود. در شکل 1 زیر، مشترک می تواند یک ماژول طرح را به عنوان بخشی از "ACME Blue" خریداری کند که 1 گیگابایت ترافیک عمومی کاربر را فراهم می کند که باید در عرض یک هفته پس از فعال سازی قبل از انقضا استفاده شود.

Data Plan API Sample Plan

شکل 1. نمونه طرح های داده.

ایجاد CPID

GTAF از کلید کاربر برای شناسایی مشترک هنگام برقراری ارتباط با DPA استفاده می کند. برنامه هایی که به MSISDN کاربر دسترسی دارند می توانند از آن به عنوان user_key استفاده کنند. از سوی دیگر، برنامه هایی که به MSISDN دسترسی ندارند، نیاز به ایجاد شناسه طرح حامل (CPID) بدون کشف MSISDN کاربر دارند. در ادامه، مکانیسمی را که یک CPID را ایجاد می کند، شرح می دهیم.

جریان تماس CPID

شکل 2: جریان فراخوانی برای ایجاد CPID.

  1. یک برنامه Google در UE از یک API داخلی Google برای بازیابی URL نقطه پایانی CPID از GTAF استفاده می کند. اپراتور با استفاده از آدرس IP عمومی مشتری و MCC+MNC سیم کارت فعال شناسایی می شود. در مورد MVNO ها، گوگل از SPN و GID1 برای تعیین MVNO استفاده می کند
  2. مشتری یک درخواست HTTP GET به نقطه پایانی CPID صادر می کند. اپراتور ممکن است از ارسال درخواست از طریق HTTPS پشتیبانی کند.
  3. اپراتور ممکن است از تابع Deep Packet Inspection خود برای شناسایی درخواست و تزریق شماره تلفن کاربر به درخواست به عنوان یک هدر HTTP استفاده کند.
  4. نقطه پایانی CPID درخواست را دریافت می‌کند، CPID را می‌سازد، و CPID را با زمان حیات (TTL) به UE برمی‌گرداند که نشان می‌دهد UE برای چه مدت می‌تواند از این CPID استفاده کند.

اپراتور همچنین ممکن است از آدرس های IP به جای نام دامنه در URL نقطه پایانی CPID استفاده کند، اگر ترجیح داده شود. آدرس‌های IP ممکن است در فضای آدرس خصوصی باشند، اما باید توسط مشتریان Google در داخل شبکه اپراتورها قابل دسترسی باشند.

اپراتور باید اطلاعات زیر را به عنوان بخشی از فرآیند ورود به Google ارائه دهد: 1. CPID_URL که برنامه‌ها برای دریافت CPID با آن تماس خواهند گرفت. یک CPID_URL اجباری است، اما اپراتور می‌تواند چندین URL را برای افزایش دسترسی ارائه کند. 1. فهرست پیشوندهای IP که اپراتور دارد و کد کشور تلفن همراه (MCC) و کد(های) شبکه تلفن همراه (MNC) که اپراتور می خواهد به CPID_URL های ارائه شده نگاشت شود. اگر اپراتور از SPN یا GID1 برای تشخیص MVNOها در شبکه خود استفاده کند، اپراتور باید این اطلاعات را نیز ارائه دهد. همانطور که در مرحله 1 شکل 2 نشان داده شده است، Google از این اطلاعات برای تطبیق مشتریان با نقاط پایانی CPID مربوطه استفاده خواهد کرد.

فرمت درخواست این است: 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 با موفقیت انجام شود، نقطه پایانی CPID باید یک پاسخ 200 OK را ارائه دهد. بدنه پاسخ باید شامل یک نمونه از CPDRsponse باشد.

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

CPID برگشتی باید برای ttlSeconds ثانیه معتبر باشد. GTAF در تماس‌های بعدی با DPA، CPID را در هر RFC2396 رمزگذاری می‌کند.

اگر خطایی رخ دهد، نقطه پایانی 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 با استفاده از کلید secret رمزگذاری می کند. مهر زمانی باید با زمانی که CPID منقضی می شود مطابقت داشته باشد. خروجی رمزگذاری شده Base64 کدگذاری شده است. علاوه بر این، زمانی که CPID در یک URL استفاده می شود، باید برای مدیریت کاراکترهای خاص (/+=) مورد استفاده در Base64 کدگذاری شده باشد. به ویژه هنگامی که GTAF با DPA تماس می گیرد یا زمانی که DPA با API اشتراک گذاری طرح داده تلفن همراه تماس می گیرد، CPID باید با URL رمزگذاری شده باشد. مزیت تولید CPID با استفاده از این رویکرد این است که DPA و CPID نقطه پایانی نیازی به داشتن پایگاه داده ای از CPID ها و MSISDN های معتبر ندارند.

بسته به موقعیت یک اپراتور خاص، ممکن است اجرای نقطه پایانی CPID غیر ضروری باشد. یک چالش خاص که اغلب با آن مواجه شده است دسترسی به MSISDN در نقطه پایانی CPID است. ما خوشحالیم که درس های آموخته شده توسط اپراتورها را به اشتراک می گذاریم. لطفا در صورت مواجهه با هر گونه چالش با ما تماس بگیرید.

الزامات امنیتی

اپراتور باید تمام اقدامات احتیاطی لازم را برای محافظت از اطلاعات خصوصی مشترکین خود انجام دهد. به طور خاص، برای به حداقل رساندن قرار گرفتن در معرض شماره تلفن مشترکین، نقطه پایانی CPID باید در محدوده امنیتی شما باشد. علاوه بر این، برای مواردی که اپراتور از DPI استفاده می کند، اپراتور باید MSISDN را قبل از تزریق آن به درخواست HTTP رمزگذاری کند. اگر نقطه پایانی CPID محیط امنیتی شما نیست (به عنوان مثال، زمانی که نقطه پایانی CPID بر روی یک ابر عمومی مستقر شده است)، اپراتور نباید MSISDN را از طریق اینترنت عمومی در فضای آزاد ارسال کند. اپراتور می تواند یک VPN بین DPI و نقطه پایانی CPID ایجاد کند (شکل 1 را ببینید) یا MSISDN را قبل از تزریق آن در هدر رمزگذاری کند. رویکرد اخیر فرض می‌کند که نقطه پایانی CPID می‌تواند هدر تزریق‌شده را رمزگشایی کند تا MSISDN را قبل از تولید CPID بازیابی کند. علاوه بر این، اپراتور باید از کلید مخفی استفاده شده برای تولید CPID محافظت کند و این کلید را طبق سیاست های امنیتی اپراتور بچرخاند.

در دسترس بودن و ظرفیت مورد نیاز

اگر مشتریان نتوانند یک CPID را بازیابی کنند، نمی توانند به هیچ اطلاعاتی از Mobile Data Plan API دسترسی داشته باشند. به همین دلیل، اپراتور باید اقدامات لازم را برای اطمینان از در دسترس بودن نقطه پایانی CPID انجام دهد. چنین اقداماتی شامل داشتن چندین نمونه از توابع نقطه پایانی CPID و DPI و داشتن افزونگی فیزیکی، سایت و شبکه برای هر دو عملکرد است و اطمینان از کافی بودن منابع و ظرفیت سیستم. علاوه بر این، نقطه پایانی CPID و همچنین تابع DPI که هدر را تزریق می‌کند باید ظرفیت کافی برای مدیریت بار تمام مشتریان Google درخواست کننده CPID داشته باشد. نقطه پایانی CPID می تواند از مقادیر بزرگتر در فیلد ttlSeconds استفاده کند تا فرکانس تولید CPID را کاهش دهد. گوگل استفاده از مقدار TTL 30 روزه را توصیه می کند.

یادداشت

  1. VIDEO_OFFLINE PMTC به این معنی است که این طرح فقط برای آفلاین خوب است (به عنوان مثال، کیفیت کیفیت پخش جریان بسیار بد). مستقل از پنجره FlexTime است. ↩