UMTS - GPRS Tunneling Protocol برتوكول النفق
كان إنشاء بروتوكول نفق GPRS (GTP) مستحيلًا فعليًا ، ولكن ليس من المرغوب أيضًا إعطائه للنظام الجديد ، ولكن من ناحية أخرى ، من المفهوم تمامًا أن التحسينات مطلوبة أيضًا من أجل التمكن من التفاعل مع عالم PS القديم بسلاسة ودعم الوظائف اللازمة لأحدث نظام.
بروتوكول نفق GPRS (GTP)
تم تصميم بروتوكول GTP للنفق وتغليف وحدات البيانات ورسائل التحكم في GPRS. منذ تصميمه في أواخر التسعينيات ، تم وضعه للنشر على نطاق واسع ، وتم جمع خبرة قوية.
يتوفر GTP لنظام Evolved 3GPP في نوعين مختلفين ، مستوى تحكم ومستوى مستخدم. يدير GTP-C تشوير مستوي التحكم ، وهو ضروري بالإضافة إلى بروتوكول نقل البيانات حول نقاء المستخدم ، GTP-U ؛ يطلق عليه طائرة المستخدم. الإصدارات الحالية المناسبة لنظام EPS هي GTPv1 US و GTPv2-C.
تكمن خصوصية GTP في أنه يدعم فصل حركة المرور داخل حامل نفق GTP الأساسي ، أو بعبارة أخرى ، القدرة على تجميعها معًا ومعالجة شركات النقل. يتم تحديد نهايات أنفاق GTP بواسطة TEID (معرفات نقطة نهاية النفق) ؛ يتم تعيينها على المستوى المحلي للوصلة الصاعدة والهابطة من قبل الكيانات النظيرة ويتم الإبلاغ عنها بشكل عرضي بينها. يتم استخدام TEIDs على مستويات مختلفة من خلال مثال محدد لاتصال PDN على S5 و S8 و EU على واجهات S3 / S4 / S10 / S11.
مستوى التحكم في بروتوكول نفق GPRS
يتم استخدام بروتوكول GTPv2-C في واجهات إشارات EPC (بما في ذلك شبكات SGSN ذات النسبة 8 على الأقل). على سبيل المثال -
- S3 (بين SGSN و MME) ،
- S4 (بين SGSN وخدمة GW) ،
- S5 و S8 (بين تقديم GW و PDN GW) ،
- S10 (بين اثنين من MMEs) و
- S11 (بين MME و GW في الخدمة).
بالتوافق مع هذا ، وحدة بيانات بروتوكول GTPv2-C نموذجية كما هو موضح في الشكل أعلاه ، الجزء المحدد GTP مسبوق برؤوس IP و UDP ، ويتكون من رأس GTPv2-C وجزء يحتوي على معلومات GTPv2-C متغير في العدد ، الطول والشكل ، حسب نوع الرسالة. نظرًا لعدم دعم الصدى والإخطار بإصدار البروتوكول ، فإن معلومات TEID غير موجودة. من الواضح أن الإصدار مضبوط على 2 في هذا الإصدار من البروتوكول.
كان لدى GTP آلية رأس تمديد قديمة معقدة ؛ لا يتم استخدامه في معظم GTPv2-C. يتم تحديد نوع الرسالة بالبايت الثاني (لذا يمكن تحديد 256 رسالة كحد أقصى للإضافات المستقبلية). يقدم الجدول أدناه نظرة عامة على الرسائل المحددة حاليًا GTPv2-C. يتم ترميز طول الرسالة في البايتين 3 و 4 (مقاسة بالبايت ولا تحتوي على البايتات الأربعة الأولى نفسها).
TEID هو معرف نقطة نهاية النفق ، قيمة واحدة على الجانب المقابل / المستقبِل ؛ يسمح بتعدد الإرسال وإلغاء الإرسال المتعدد في أحد الأطراف في الحالات المتكررة جدًا التي يجب تمييزها عبر نفق GTP.
| نوع الرسالة | رسالة | شرح إضافي |
|---|---|---|
| 0 | محجوز | لا يجوز استخدامه أبدًا (مستبعد عن قصد من البروتوكول ، لفرض إعداد صريح) |
| 1/2 | طلب / استجابة صدى | يُستخدم للتحقق مما إذا كان إصدار GTP يدعمه عقدة الإرسال. |
| 3 | الإصدار غير مدعوم إشارة | يحتوي على أحدث إصدار GTP يدعم عقدة الإرسال. |
| 4/5 | طلب / استجابة التحويل المباشر | تُستخدم لإرسال رسائل إشارات الأنفاق على واجهة S101 من أجل التسليم الأمثل ، بين وصول HRPD لا و MME |
| 6/7 | طلب / استجابة الإخطار | يستخدم لإخطار الأنفاق على S101 بين عقدة الوصول HRPD و MME |
| 25/26 | طلب SRVCC PS إلى CS | يُستخدم لتشغيل وتأكيد بدء SRVCC بين خادم SGSN / MME وخادم MSC |
| 27/28 | SRVCC PS to CS إخطار كامل | تستخدم للإشارة والتأكيد على اكتمال SRVCC بين خادم MSC و SGSN / MME |
| 32/33 | إنشاء طلب الجلسة | يستخدم لإنشاء اتصال بين عقدتين |
| 34/35 | تعديل طلب الحامل | يستخدم لتعديل خصائص حامل واحد أو متعدد ، بما في ذلك معلومات سياق الحامل |
| 36/37 | حذف طلب الجلسة | تمزق جلسة التحكم في GTP |
| 38/39 | تغيير طلب الإعلام | تستخدم للإبلاغ عن معلومات الموقع |
| 66/67 | حذف إشارة أمر / فشل الحامل | قم بإرشاد العقد إلى حذف الحامل وإعادة التأكيد |
| 68/69 | إشارة فشل / أمر مورد الحامل | تستخدم لتخصيص أو تعديل الموارد |
| 73 | وقف إشارة الترحيل | مُرسَل من SGW إلى MME أو SGSN |
| 95/96 | إنشاء طلب / استجابة لحاملها | قم بتوجيه العقد لتركيب الحوامل وإعادة التأكيد |
| 97/98 | طلب تحديث الحامل | يستخدم لإبلاغ عقد مستوى التحكم من مستوى المستخدم بتغييرات الحامل |
GTPv1-U المحسن
تم تطبيق تحسين صغير ولكن فعال على GTP-U ، ولهذا لم يكن من الضروري تعزيز عدد إصدارات البروتوكول. وبالتالي ، ما زلنا نتوقع GTPv1-U ، لكنه على الأقل أحدث إصدار من Rel. 8.
مكدس البروتوكول هو نفسه بشكل أساسي لـ GTPv2-C مع اسم الطبقات فقط واستبدال البروتوكولات وفقًا لذلك. يتم الاحتفاظ بآلية رأس التمديد في مكانها ؛ يسمح بإدخال عنصرين إذا لزم الأمر.
منفذ مصدر UDP لرسالة التشغيل (ثماني بتات) ؛
رقم PDCP PDU - يتعلق بنقل الخاصية دون خسارة ؛ في هذه الحالة ، يجب ترقيم حزم البيانات في EPC (ثماني بتات).
التحسين هو القدرة على نقل "السوق النهائي" في مستوى المستخدم. يتم استخدامه في إجراء تسليم inter-eNodeB ويعطي إشارة إلى أن المسار قد تم تنشيطه فورًا بعد حزمة البيانات ، على سبيل المثال ، الميزة ليست ضرورية لـ pre-Rel.8 لأن GTP-U لم تنته في الوصول اللاسلكي العقدة (أي ليس في BS أو NodeB) يوجد فقط عدد قليل من الرسائل. GTPv1-U ، وهي مدرجة في الجدول أعلاه.
من الواضح ، في الواقع ، أن نوعًا محدودًا جدًا من الإشارات ممكن عبر GTPv1-U (آليات الصدى ووسم النهاية). الرسالة الوحيدة التي مفادها أن نقل بيانات المستخدم الحقيقي هو من النوع 255 ، ما يسمى برسالة G-PDU ؛ الجزء الوحيد من المعلومات الذي يحمله ، بعد الرأس هو حزمة البيانات الأصلية من مستخدم أو جهاز PDN خارجي.
لم يتم سرد جميع حالات أنفاق GTP-U في البنية المرجعية (التي تهدف إلى التقاط الجمعيات التي لم تعد تعيش بين عقد الشبكة) ؛ الأنفاق المؤقتة ممكنة -
بين غيغاواط للخدمة ، تنطبق على النقل على أساس S1 ، في حالة نقل الخدمة GW ؛
بين اثنين من SGSNs ، يتوافق مع الحالة السابقة ، ولكن في شبكة PS القديمة ؛
بين اثنين من RNCs ، قابلة للتطبيق على نقل RNC في شبكة 3G PS (لا علاقة لها بـ EPC ، مذكورة هنا فقط للاكتمال).