امتيازات مشغّل شبكة الجوّال في شريحة UICC

قدّم Android 5.1 آلية لمنح امتيازات خاصة لواجهات برمجة التطبيقات. ما يتناسب مع مالكي تطبيقات بطاقات الدوائر المُدمَجة العامة (UICC). تشير رسالة الأشكال البيانية نظام Android الأساسي يحمّل الشهادات المخزنة على UICC ويمنح الإذن موقعة من خلال هذه الشهادات لإجراء اتصالات بمجموعة من واجهات برمجة التطبيقات الخاصة.

وفّر نظام التشغيل Android 7.0 هذه الميزة للسماح بمصادر تخزين أخرى لقواعد امتيازات مشغّلي شبكة الجوّال في شريحة UICC، ما أدّى إلى زيادة عدد مشغّلي شبكة الجوّال الذين يمكنهم استخدام واجهات برمجة التطبيقات بشكل كبير. للحصول على مرجع لواجهة برمجة التطبيقات، راجِع CarrierConfigManager. وللحصول على التعليمات، راجِع Carrier Configuration.

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

القواعد المتعلقة بـ UICC

إنّ مساحة التخزين على شريحة UICC متوافقة مع مواصفات تحكم الوصول إلى العنصر الآمن في منصّة GlobalPlatform. معرّف التطبيق (AID) على البطاقة هي A00000015141434C00، والقيمة العادية GET DATA يستخدم الأمر لجلب القواعد المخزنة على البطاقة. يمكنك تعديل هذه القواعد من خلال تحديثات البطاقة عبر شبكة غير سلكية (OTA).

التدرّج الهرمي للبيانات

تستخدم قواعد UICC التسلسل الهرمي للبيانات التالي (الحرف المكون من حرفين مجموعة الأرقام الموجودة بين قوسين هي علامة الكائن). كل قاعدة هي REF-AR-DO (E2) وتتألف من سلسلة من REF-DO وAR-DO:

  • يحتوي REF-DO (E1) على DeviceAppID-REF-DO أو تسلسل من DeviceAppID-REF-DO وPKG-REF-DO
    • تخزِّن DeviceAppID-REF-DO (C1) خوارزمية SHA-1. توقيع الشهادة (20 بايت) أو SHA-256 (32 بايت)
    • PKG-REF-DO (CA) هو اسم الحزمة الكامل سلسلة محددة في ملف البيان، بترميز ASCII، الحد الأقصى للطول هو 127 بايت.
  • تم توسيع نطاق "AR-DO" (E3) ليشمل PERM-AR-DO (DB)، وهو وحدة بت من 8 بايت قناع يمثل 64 إذنًا منفصلاً.

في حال عدم توفّر PKG-REF-DO، يعني ذلك أي تطبيق تم توقيعه من خلال الشهادة. تم منحه إذن الوصول وإلا يجب أن يكون كل من الشهادة واسم الحزمة تطابق.

مثال على القاعدة

اسم التطبيق هو com.google.android.apps.myapp وشهادة SHA-1 بالتنسيق السداسي العشري هي:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

القاعدة الموجودة على UICC في السلسلة السداسية هي:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

إتاحة الوصول إلى ملف القاعدة

يتيح Android 7.0 إمكانية قراءة قواعد امتيازات مشغّل شبكة الجوّال من أذونات الوصول. ملف قاعدة (ARF).

يحاول نظام Android الأساسي أولاً اختيار تطبيق قاعدة الوصول (ARA) رقم التعريف الشخصي (ARA) A00000015141434C00. إذا لم يعثر على معرّف AID في شريحة UICC، سيعود إلى ARF عن طريق اختيار معرّف AID بتنسيق PKCS15 A000000063504B43532D3135. يقرأ Android بعد ذلك ملف قواعد التحكم بالوصول (ACRF) على 0x4300 ويبحث عن الإدخالات مع AID FFFFFFFFFFFF. ويتم تجاهل الإدخالات التي تحتوي على معرّفات AID مختلفة، لكي تتمكّن قواعد حالات الاستخدام الأخرى من التوافق مع بعضها.

مثال على محتوى ACRF في سلسلة سداسية عشرية:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

مثال على محتوى ملف شروط التحكّم في الوصول (ACCF):

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

في المثال أعلاه، 0x4310 هو عنوان ACCF، والذي يحتوي على تجزئة الشهادة 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 حملة التطبيقات الموقعة من خلال هذه الشهادة تم منحها امتيازات مشغِّل شبكة الجوّال.

واجهات برمجة التطبيقات المفعّلة

يتوافق Android مع واجهات برمجة التطبيقات التالية.

TelephonyManager

TelephonyCallback

TelephonyCallback يحتوي على واجهات تتضمّن طريقة طلب معاودة الاتصال لإعلام التطبيق المتصل عند تغيير الحالات المسجّلة:

مدير الاشتراكات

SmsManager

  • طريقة السماح للمتصل بإنشاء رسائل SMS واردة جديدة: injectSmsPdu
  • طريقة إرسال رسالة SMS نصية بدون كتابة الرسالة في مقدّم خدمة الرسائل القصيرة: sendTextMessageWithoutPersisting

إدارة إعدادات مشغّل شبكة الجوال

  • طريقة إشعار الضبط التي تم تغييرها: notifyConfigChangedForSubId
  • طريقة الحصول على إعدادات مشغّل شبكة الجوّال للاشتراك التلقائي: getConfig
  • طريقة الحصول على إعدادات مشغّل شبكة الجوّال للاشتراك المحدّد: getConfigForSubId

للحصول على التعليمات، يُرجى الاطّلاع على مقالة ضبط إعدادات مشغّل شبكة الجوَّال.

إدارة تقرير الأخطاء

طريقة بدء إعداد تقرير أخطاء الاتصال، وهو إصدار متخصص من تقرير الأخطاء لا يتضمّن سوى معلومات لتصحيح أخطاء تتعلّق بالاتصال: startConnectivityBugreport

مدير NetworkStats

مدير رسائل SMS

مدير ImsRcsManager

ProvisioningManager

EuiccManager

طريقة التبديل إلى الاشتراك المحدّد (تفعيله): switchToSubscription

CarrierMessagingService

الخدمة التي تتلقّى مكالمات من النظام عند إرسال رسائل SMS ورسائل وسائط متعددة جديدة أو تلقّيها. لتوسيع نطاق هذه الفئة، يجب إدراج الخدمة في ملف البيان باستخدام الإذن android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE وتضمين فلتر أهداف يتضمّن الإجراء#SERVICE_INTERFACE . تشمل الطرق ما يلي:

  • طريقة فلترة الرسائل القصيرة الواردة: onFilterSms
  • طريقة اعتراض الرسائل النصية القصيرة SMS المُرسَلة من الجهاز: onSendTextSms
  • طريقة اعتراض الرسائل القصيرة الثنائية المُرسَلة من الجهاز: onSendDataSms
  • طريقة اعتراض رسائل SMS الطويلة المُرسَلة من الجهاز: onSendMultipartTextSms
  • طريقة اعتراض رسائل الوسائط المتعددة المُرسَلة من الجهاز: onSendMms
  • طريقة تنزيل رسائل الوسائط المتعددة التي تم استلامها: onDownloadMms

CarrierService

هي خدمة تعرض الوظائف الخاصة بمشغّل شبكة الجوّال للنظام. إلى توسيع هذه الفئة، أو الإفصاح عن الخدمة في ملف بيان التطبيق باستخدام إذن android.Manifest.permission#BIND_CARRIER_SERVICES و ضمِّن فلتر أهداف مع الإجراء CARRIER_SERVICE_INTERFACE. إذا كانت الخدمة لها عملية ربط دائمة، اضبط android.service.carrier.LONG_LIVED_BINDING على true في البيانات الوصفية للخدمة.

تربط المنصة CarrierService بعلامات خاصة للسماح بتشغيل عملية خدمة مشغّل شبكة الجوّال في مجموعة التطبيقات الاحتياطية الخاصة. ويؤدي ذلك إلى إعفاء تطبيق خدمة مشغّل شبكة الجوّال من قيود التطبيقات غير النشطة ويزيد من احتمال بقائه قيد التشغيل عندما تكون ملفوظة الجهاز منخفضة. ومع ذلك، إذا تعطّل تطبيق خدمة مشغّل شبكة الجوّال لأي سبب، يفقد جميع الامتيازات المذكورة أعلاه إلى أن تتم إعادة تشغيل التطبيق وإعادة تثبيت الربط. لذلك، من الضروري الحفاظ على ثبات تطبيق خدمة مشغّل شبكة الجوّال.

تشمل الطرق في CarrierService ما يلي:

  • لإلغاء الإعدادات الخاصة بمشغّل شبكة الجوّال وضبطها: onLoadConfig
  • لإبلاغ النظام بتغيير متعمّد قادم في شبكة مشغّل شبكة الجوّال من خلال تطبيق مشغل شبكة الجوال: notifyCarrierNetworkChange

مقدِّم خدمات الاتصال الهاتفي

واجهات برمجة التطبيقات لموفّر المحتوى للسماح بالتعديلات (إدراج، حذف، تحديث، طلب) إلى قاعدة بيانات الاتصالات الهاتفية. يتم تحديد حقول القيم عند Telephony.Carriers لمزيد من التفاصيل، راجع مرجع الفئة Telephony

اقتراح شبكة Wi-Fi

عند إنشاء عنصر WifiNetworkSuggestion، استخدِم ما يلي: الطرق لضبط معرّف الاشتراك أو مجموعة اشتراك:

نظام Android الأساسي

في واجهة UICC يتم اكتشافها، تُنشئ المنصة كائنات UICC داخلية تضمين قواعد امتيازات مشغل شبكة الجوال كجزء من UICC. UiccCarrierPrivilegeRules.java ويحمِّل القواعد ويحلّلها من بطاقة UICC ويخزّنها في ذاكرة التخزين المؤقت. فعندما هناك حاجة إلى التحقق من الامتياز، يقارن UiccCarrierPrivilegeRules شهادة المتصل بقواعدها الخاصة واحدة تلو الأخرى. إذا تمت إزالة UICC، يتم إتلاف القواعد إلى جانب كائن UICC.

التحقُّق

للتحقّق من التنفيذ من خلال مجموعة أدوات اختبار التوافق (CTS) باستخدام CtsCarrierApiTestCases.apk، يجب أن يكون لديك شريحة UICC للمطوّر تتضمّن قواعد UICC الصحيحة أو تتيح استخدام ARF. اطلب من موفّر شرائح SIM الذي تختاره إعداد شريحة UICC للمطوّرين تتضمّن ملف ARF المناسب كما هو موضّح في هذا القسم، واستخدِم شريحة UICC هذه لإجراء الاختبارات. تشير رسالة الأشكال البيانية لا تتطلب UICC خدمة شبكة جوّال نشطة لاجتياز اختبارات CTS.

تجهيز UICC

على نظام التشغيل Android 11 والإصدارات الأقدم، CtsCarrierApiTestCases.apk هو موقَّعة من قِبل aosp-testkey بقيمة تجزئة 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81

بدءًا من نظام التشغيل Android 12، سيكون CtsCarrierApiTestCases.apk موقَّعة من قِبل cts-uicc-2021-testkey، قيمة التجزئة CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0

لإجراء اختبارات واجهة برمجة التطبيقات لمشغّل شبكة الجوّال من CTS في Android 12، يحتاج الجهاز إلى استخدام شريحة SIM مع مشغّل شبكة جوّال CTS الامتيازات التي تستوفي المتطلبات المحددة في أحدث إصدار من الطرف الثالث مواصفات ملف اختبار GSMA TS.48.

يمكن أيضًا استخدام شريحة SIM نفسها مع الإصدارات الأقدم من Android 12.

تعديل الملف الشخصي لشريحة SIM الخاصة بـ CTS

  1. الإضافة: امتيازات مشغّل شبكة الجوّال لاختبار CTS في ملف master لقاعدة الوصول إلى التطبيق (ARA-M) أو ملف ARF يجب أن يكون كلا التوقيعين تم ترميزها في قواعد امتيازات مشغّل شبكة الجوّال:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. التجزئة2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. الإنشاء: ملفات ADF USIM الأساسية (EFs) غير متوفرة في TS.48 ومطلوبة لـ CTS:
    1. EF_MBDN (6FC7)، حجم السجل: 28، رقم السجل: 4
      • قانع
        1. التسجيل 1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF...FF
    2. EF_EXT6 (6FC8)، حجم السجل:13، رقم السجل: 1
      • المحتوى: 00FF...FF
        1. EF_MBI‏ (6FC9)، حجم السجلّ: 4، رقم السجلّ: 1
      • المحتوى: Rec1:‏ 01010101
        1. EF_MWIS (6FCA)، حجم السجلّ: 5، رقم السجلّ: 1
      • المحتوى: 0000000000
  3. تعديل: جدول خدمة USIM: تفعيل الخدمات رقم 47 ورقم 48
    1. EF_UST (6F38)
      • المحتوى: 9EFFBF1DFFFE0083410310010400406E01
  4. التعديل: ملفات DF-5GS وDF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • المحتوى: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • المحتوى: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • المحتوى: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • المحتوى: A0020000FF…FF
  5. التعديل: استخدِم سلسلة اسم مشغّل شبكة الجوّال Android CTS في ملفّات EF ذات الصلة التي تحتوي على هذا التصنيف:
    1. EF_SPN (USIM/6F46)
      • المحتوى: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • المحتوى: Rec1 430B83413759FE4E934143EA14FF..FF

مطابقة بنية ملف التعريف التجريبي

نزِّل أحدث إصدار من بنية الملفات الشخصية الاختبارية العامة التالية ومطابقتها. لن يتم تخصيص قاعدة امتيازات مشغّل شبكة الجوّال في CTS أو إجراء أي تعديلات أخرى مُدرَجة أعلاه في هذه الملفات الشخصية.

إجراء الاختبارات

ولتسهيل الأمر، تدعم CTS رمزًا مميّزًا للجهاز يحدّ من إجراء اختبارات ليتم إجراؤها فقط على الأجهزة التي تم إعدادها باستخدام الرمز المميز نفسه. مجموعة أدوات اختبار البيانات (CTS) من واجهة برمجة تطبيقات مشغّل شبكة الجوّال اختبار إمكانية استخدام الرمز المميّز للجهاز sim-card-with-certs. على سبيل المثال: يمنع الرمز المميز التالي الخاص بالجهاز إجراء اختبارات واجهة برمجة تطبيقات مشغِّل شبكة الجوّال على الجهاز فقط abcd1234:

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

عند إجراء اختبار بدون استخدام رمز أمان الجهاز، يتم تنفيذ الاختبار على جميع الأجهزة.

الأسئلة الشائعة

كيف يمكن تعديل الشهادات على شريحة UICC؟

أ: استخدام آلية تحديث البطاقة الحالية عبر الهواء

هل يمكن أن تتعايش قاعدة UICC مع قواعد أخرى؟

ج: لا بأس بوجود قواعد أمان أخرى على شريحة UICC ضمن رقم تعريف الجهاز نفسه، فتصفّحها المنصة تلقائيًا.

ماذا يحدث عند إزالة UICC لتطبيق يعتمد على أو الشهادات عليها؟

أ: يفقد التطبيق امتيازاته لأنّ القواعد المرتبطة بكرت UICC يتم إزالتها عند إزالة هذا الكرت.

هل هناك حدّ أقصى لعدد الشهادات في واجهة UICC؟

ج: لا تفرض المنصة قيودًا على عدد الشهادات، ولكن بما أنّ عملية التحقق خطية، قد يؤدي تزايد عدد القواعد إلى تأخير عملية الفحص.

هل هناك حدّ أقصى لعدد واجهات برمجة التطبيقات التي يمكننا استخدامها في تنفيذ هذه العملية؟ الطريقة؟

الجواب: لا، ولكن نحصر النطاق بواجهات برمجة التطبيقات المتعلقة بمشغّل شبكة الجوّال.

هل هناك بعض واجهات برمجة التطبيقات ممنوعة من استخدام هذه الطريقة؟ إذا كان الأمر كذلك، كيف تتم تنفيذها؟ (أي، هل لديك اختبارات للتحقق من واجهات برمجة التطبيقات مع هذه الطريقة)

ج: اطّلِع على قسم "التوافق مع سلوك واجهة برمجة التطبيقات" ضِمن نظام التوافق مع Android مستند تعريف (CDD) لدينا بعض اختبارات CTS للتأكّد من عدم تغيير نموذج الأذونات لواجهات برمجة التطبيقات.

كيف تعمل هذه الميزة مع ميزة "شريحة SIM متعددة"؟

أ: يتم استخدام شريحة SIM التلقائية التي حدّدها المستخدم.

هل تتفاعل هذه التكنولوجيا بأي شكل من الأشكال مع تكنولوجيات غيرها متعلّقة بالوصول إلى محتوى الوسائط التفاعلية، مثل SEEK؟

الجواب: على سبيل المثال، يستخدم SeeK معرّف AID نفسه الوارد في واجهة UICC. وبالتالي، تتعايش القواعد ويتمّت فلترتها إما باستخدام SEEK أو UiccCarrierPrivileges.

ما هو الوقت المناسب للتحقّق من امتيازات مشغّل شبكة الجوّال؟

أ: بعد بث حالة شريحة SIM.

هل يمكن للمصنّعين الأصليين للأجهزة إيقاف جزء من واجهات برمجة تطبيقات مشغّل شبكة الجوّال؟

ج: لا، نعتقد أنّ واجهات برمجة التطبيقات الحالية هي الحد الأدنى من المجموعات، ونحن نخطّط لاستخدام قناع الوحدات بتقسيم أدق في المستقبل.

هل تلغي setOperatorBrandOverride جميع أشكال سلاسل أسماء عوامل التشغيل الأخرى؟ على سبيل المثال، SE13 أو SPN في شريحة UICC أو NITZ المستند إلى الشبكة؟

نعم، إنّ إلغاء العلامة التجارية للمشغّل له الأولوية القصوى. وعند ضبطه، يتم إلغاء جميع الأشكال الأخرى لسلاسل أسماء عوامل التشغيل.

ما هو وظيفة استدعاء طريقة injectSmsPdu؟

ج: تسهّل هذه الطريقة الاحتفاظ بنسخة احتياطية من الرسائل القصيرة أو استعادتها في السحابة الإلكترونية. يؤدي طلب injectSmsPdu إلى تفعيل وظيفة الاستعادة.

بالنسبة إلى فلترة الرسائل القصيرة، هل تستند المكالمة onFilterSms إلى فلترة منفذ UDH للرسائل القصيرة؟ أو هل يمكن لتطبيقات مشغّل شبكة الجوّال الوصول إلى جميع رسائل SMS الواردة؟

الإجابة: يمكن لمشغّلي شبكات الجوّال الوصول إلى جميع بيانات الرسائل القصيرة.

يبدو أنّ إضافة DeviceAppID-REF-DO للسماح بمعالجة ملف ‎32 بايت لا تتوافق مع مواصفات GP الحالية (التي تسمح بمعالجة ملف 0 أو 20 بايت فقط)، فما هو سبب إجراء هذا التغيير؟ هل SHA-1 غير كافٍ لتجنُّب حدوث تصادمات؟ هل سبق لك اقتراح هذا التغيير على فريق GP، لأنّه قد يكون غير متوافق مع الإصدارات القديمة من ARA-M/ARF؟

ج: تقدّم هذه الإضافة خوارزمية SHA-256 لتوفير أمان مستدام في المستقبل. لـ DeviceAppID-REF-DO بالإضافة إلى خوارزمية SHA-1، التي يتم استخدامها حاليًا هو الخيار الوحيد في معيار GP SEAC. ننصح بشدة باستخدام خوارزمية SHA-256.

إذا كانت قيمة DeviceAppID هي 0 (فارغة)، هل يتم تطبيق القاعدة على جميع تطبيقات الأجهزة التي لا تشملها قاعدة محدّدة؟

أ: تتطلّب واجهات برمجة تطبيقات مشغّلي شبكات الجوّال تعبئة DeviceAppID-REF-DO. يُستخدَم النموذج الفارغ لأغراض الاختبار، ولا يُنصح باستخدامه في عمليات النشر التشغيلية.

وفقًا للمواصفات التي وضعتها، تم استخدام PKG-REF-DO من قِبل نفسها، بدون DeviceAppID-REF-DO، يجب قبولها. لَكِنْ فإنه لا يزال موصوفًا في الجدول 6-4 من المواصفات على أنه تمديد تعريف REF-DO. هل هذا عن قصد؟ كيف يتصرف الرمز عند استخدام PKG-REF-DO فقط في REF-DO؟

أ: خيار استخدام PKG-REF-DO كقيمة واحدة تمت إزالة عنصر في REF-DO في أحدث إصدار. يجب أن تحدث السمة PKG-REF-DO فقط مع DeviceAppID-REF-DO

نفترض أنّه يمكننا منح إذن الوصول إلى جميع الأذونات المستندة إلى مشغّل شبكة الجوّال أو أنّه يمكننا التحكّم بشكل أدق. إذا كان الأمر كذلك، فما الذي يحدد التعيين بين البت القناع والأذونات الفعلية؟ هل هناك إذن واحد لكل صف؟ إذن واحد لكل الطريقة؟ هل 64 إذنًا منفصلاً كافٍ على المدى الطويل؟

الجواب: هذا الخيار مخصّص للمستقبل، ونرحب بالاقتراحات.

هل يمكنك تحديد DeviceAppID بشكلٍ أدق لنظام Android على وجه التحديد؟ هذه هي قيمة تجزئة SHA-1 (20 بايت) للناشر الشهادة المستخدمة لتوقيع التطبيق المعين، لذا يجب ألا يعكس الاسم الغرض؟ (قد يكون الاسم مربكًا للعديد من القرّاء لأنّ القاعدة تنطبق بعد ذلك على جميع التطبيقات الموقَّعة باستخدام شهادة الناشر نفسها).

ج: تتوافق شهادات التخزين DeviceAppID مع المواصفات الحالية. وقد حاولنا تقليل تغييرات المواصفات لتقليل حاجز الاعتماد. لمعرفة التفاصيل، يُرجى الاطّلاع على القواعد في UICC.