يناقش هذا المستند تكوين وضع مجدول البث العكسي لسلسلة موجه النطاق الترددي العريض العالمي (uBR) من أنظمة توصيل مودم الكبل (CMTS) من Cisco.
يركز هذا المستند على الموظفين الذين يعملون على تصميم وصيانة شبكات البيانات المنقولة عبر الكبلات فائقة السرعة التي تستفيد من خدمات البث التي يمثل زمن الوصول فيها أمرا حيويا بالنسبة للرجفان، مثل الصوت أو الفيديو عبر بروتوكول الإنترنت (IP).
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
البيانات عبر أنظمة مواصفات واجهة خدمة الكبلات (DOCSIS)
سلسلة Cisco uBR من CMTS
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
Cisco uBR CMTS
برنامج IOS® الإصدار trains 12.3(13a)BC و 12.3(17a)BC من Cisco
ملاحظة: للحصول على معلومات حول التغييرات الطارئة على الإصدارات الأحدث من برنامج Cisco IOS Software، ارجع إلى ملاحظات الإصدار المناسبة المتوفرة في موقع Cisco.com على الويب.
راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.
في شبكة مواصفات واجهة خدمة البيانات المنقولة عبر الكبلات (DOCSIS)، يتحكم CMTS في توقيت ومعدل جميع عمليات الإرسال إلى الخادم التي تقوم بها أجهزة مودم الكبلات. تعمل أنواع عديدة مختلفة من الخدمات التي تتطلب زمن وصول واهتزاز وسعة معالجة مختلفة في آن واحد على أحد عمليات تحميل شبكة DOCSIS الحديثة. لذلك، يجب عليك فهم كيفية تقرير CMTS متى يمكن لمودم الكبل إجراء عمليات الإرسال إلى الخادم نيابة عن هذه الأنواع المختلفة من الخدمات.
يتضمن هذا التقرير الأبيض ما يلي:
نظرة عامة على أوضاع الجدولة عند البث في DOCSIS، بما في ذلك أفضل الجهود، وخدمة المنح غير المرغوب فيها (UGS) وخدمة الاقتراع في الوقت الفعلي (RTPS)
عملية تكوين المجدول المتوافق مع DOCSIS ل Cisco uBR CMTS وتكوينه
عملية تكوين مجدول قوائم انتظار المهلة المنخفضة الجديد ل Cisco uBR CMTS
يمكن أن توفر CMTS المتوافقة مع DOCSIS أوضاع جدولة بداية مختلفة لتدفقات الحزم أو التطبيقات المختلفة من خلال مفهوم تدفق الخدمة. يمثل تدفق الخدمة إما تدفق بيانات من الخادم أو من الخادم، والذي يقوم معرف تدفق الخدمة (SFID) بتعريفه بشكل فريد. يمكن أن يكون لكل تدفق خدمة معلمات جودة الخدمة (QoS) الخاصة به، على سبيل المثال، الحد الأقصى للإنتاجية والحد الأدنى للإنتاجية المضمونة والأولوية. في حالة تدفقات خدمة البث، يمكنك أيضا تحديد وضع جدولة.
يمكنك الحصول على أكثر من تدفق خدمة للتحميل لكل مودم كبل لاستيعاب أنواع مختلفة من التطبيقات. على سبيل المثال، يمكن أن يستخدم الويب والبريد الإلكتروني تدفق خدمة واحد، ونقل الصوت عبر بروتوكول الإنترنت (VoIP) إستخدام آخر، كما يمكن للألعاب على الإنترنت إستخدام تدفق خدمة آخر. لكي تتمكن من توفير نوع خدمة مناسب لكل تطبيق من هذه التطبيقات، يجب أن تكون خصائص تدفقات الخدمة هذه مختلفة.
يمكن لمودم الكبل و CMTS توجيه الأنواع الصحيحة من حركة المرور إلى تدفقات الخدمة المناسبة باستخدام التصنيفات. التصنيفات هي عوامل تصفية خاصة، مثل قوائم الوصول، تطابق خصائص الحزمة مثل أرقام منافذ UDP و TCP لتحديد تدفق الخدمة المناسب للحزم التي تنتقل عبرها.
في الشكل 1 يحتوي مودم الكبل على ثلاثة تدفقات خدمة للتدفق من الخادم. تم حجز تدفق الخدمة الأول لحركة المرور الصوتية. يتميز تدفق الخدمة هذا بانخفاض الحد الأقصى للإنتاجية، إلا أنه تمت تهيئته أيضا ليوفر ضمانا بتدني زمن الوصول. يعد تدفق الخدمة التالي لحركة مرور الويب والبريد الإلكتروني العامة. يتسم تدفق الخدمة هذا بسعة معالجة فائقة. تم حجز تدفق الخدمة النهائي لحركة مرور نظير إلى نظير (P2P). يحتوي تدفق الخدمة هذا على سعة معالجة قصوى أكثر تقييدا لتقليل سرعة هذا التطبيق.
شكل 1 - مودم كبل مع ثلاث تدفقات خدمة للتحميل
يتم إنشاء تدفقات الخدمة وتنشيطها عند اتصال مودم الكبل أولا. توفير تفاصيل تدفقات الخدمة في ملف تكوين DOCSIS الذي تستخدمه لتكوين مودم الكبل. قم بتوفير تدفق خدمة واحد على الأقل لحركة مرور البيانات من الخادم، وتدفق خدمة آخر لحركة مرور البيانات من الخادم في ملف تكوين DOCSIS. تسمى تدفقات خدمة تدفق البيانات إلى الخادم أو إلى الخادم التي تحددها في ملف تكوين DOCSIS تدفقات الخدمة الأساسية.
كما يمكن إنشاء تدفقات الخدمة وتنشيطها بشكل ديناميكي بعد اتصال مودم الكبل بالإنترنت. ينطبق هذا السيناريو بشكل عام على تدفق الخدمة، والذي يتوافق مع البيانات التي تنتمي إلى مكالمة هاتفية عبر بروتوكول VoIP. يتم إنشاء تدفق خدمة كهذا وتنشيطه عند بدء محادثة هاتفية. يتم بعد ذلك إلغاء تنشيط تدفق الخدمة وحذفه عند انتهاء المكالمة. إذا كان تدفق الخدمة موجودا فقط عند الضرورة، فيمكنك حفظ موارد عرض النطاق الترددي للتدفق وحمولة وحدة المعالجة المركزية (CPU) للنظام والذاكرة.
لا يمكن لأجهزة مودم الكبلات إجراء عمليات الإرسال إلى الخادم في أي وقت. بدلا من ذلك، يجب أن تنتظر أجهزة المودم التعليمات من CMTS قبل أن تتمكن من إرسال البيانات، لأن مودم كبل واحد فقط يمكنه إرسال البيانات على قناة تدفق في كل مرة. وإلا فإن عمليات الإرسال قد تجتاح وتفسد بعضها البعض. إرشادات حول متى يمكن لمودم الكبل جعل الإرسال يأتي من CMTS في شكل رسالة خريطة تخصيص عرض النطاق الترددي. يرسل Cisco CMTS رسالة خريطة كل 2 مللي ثانية لإخبار أجهزة مودم الكبل عندما يمكن أن تقوم بعمل بث من أي نوع. تحتوي كل رسالة من رسائل الخريطة على معلومات ترشد أجهزة المودم متى تقوم بعمل الإرسال على وجه التحديد، وكم من الوقت يمكن أن يستمر الإرسال، وما نوع البيانات التي يمكنها إرسالها. وبالتالي، فإن عمليات إرسال بيانات المودم الكابلي لا تتداخل مع بعضها البعض، وتتجنب تلف البيانات. يناقش هذا القسم بعض الطرق التي يمكن بها ل CMTS تحديد متى يمنح مودم الكبل إذنا لإجراء إرسال في المنبع.
تعد أفضل جدولة للجهد مناسبة لتطبيقات الإنترنت الكلاسيكية التي لا تتطلب متطلبات صارمة فيما يتعلق بزمن الوصول أو التشوه. وتتضمن الأمثلة على هذه الأنواع من التطبيقات البريد الإلكتروني أو إستعراض الويب أو نقل الملفات من نظير إلى نظير. لا تناسب أفضل جدولة للجهد التطبيقات التي تتطلب زمن وصول مضمون أو تشويش، على سبيل المثال، الصوت أو الفيديو عبر IP. وذلك لأنه في الظروف المزدحمة لا يمكن تقديم مثل هذه الضمانات في أفضل أوضاع الجهود. تسمح أنظمة DOCSIS 1.0 بهذا النوع من الجدولة فقط.
عادة ما يتم توفير تدفقات خدمة أفضل الجهود في ملف تكوين DOCSIS المرتبط بمودم كبل. لذلك، تكون تدفقات خدمة أفضل الجهود نشطة بشكل عام بمجرد اتصال مودم الكبل بالإنترنت. يجب أن يكون تدفق خدمة الخادم الأولي، وهو أول تدفق خدمة من الخادم الخادم يتم توفيره في ملف تكوين DOCSIS، تدفق خدمة من نوع أفضل الجهود.
فيما يلي المعلمات الأكثر إستخداما التي تحدد تدفق خدمة أفضل الجهود في وضع DOCSIS 1.1/2.0:
الحد الأقصى لمعدل نقل البيانات المستمر (R)
يقصد ب Maximum Sustained Traffic Rate أقصى معدل يمكن لحركة المرور من خلاله العمل عبر تدفق الخدمة هذا. يتم التعبير عن هذه القيمة بوحدة بت في الثانية.
الحد الأقصى لانفجار حركة المرور (ب)
يشير الحد الأقصى لانفجار حركة المرور إلى حجم الاندفاع بالبايت الذي ينطبق على أدوات تحديد معدل دلو الرمز المميز التي تفرض حدود الخرج للتدفق. إذا لم يتم تحديد قيمة، يتم تطبيق القيمة الافتراضية ل 3044، والتي هي حجم إطاري إيثرنت كاملين. من أجل المعدلات القصوى الكبيرة لحركة المرور المستمرة، قم بتعيين هذه القيمة على الأقل لتكون الحد الأقصى لحركة المرور المستدامة مقسوما على 64.
أولوية حركة المرور
تشير هذه المعلمة إلى أولوية حركة المرور في تدفق خدمة يتراوح من 0 (الأدنى) إلى 7 (الأعلى). في الجزء العلوي، تتم جدولة جميع حركات المرور المعلقة لتدفقات الخدمة ذات الأولوية العليا للإرسال قبل حركة المرور لتدفقات الخدمة ذات الأولوية المنخفضة.
الحد الأدنى للمعدل المحجوز
يشير هذا المعامل إلى الحد الأدنى للإنتاجية المضمونة في وحدات بت في الثانية لتدفق الخدمة، مماثل لمعدل المعلومات الملتزم به (CIR). يجب ألا يتجاوز الحد الأدنى للمعدلات المحجوزة المجمعة لجميع تدفقات الخدمة على قناة النطاق الترددي المتاح على تلك القناة. وإلا فمن المستحيل ضمان الحد الأدنى من الأسعار المحجوزة الموعودة.
اندفاع إرتجالي أقصى
Maximum Concatenated Burst هو الحجم بالبايت لأكبر عملية إرسال للإطارات المهتزة التي يمكن للمودم القيام بها بالنيابة عن تدفق الخدمة. وكما تشير هذه المعلمة، يمكن للمودم إرسال إطارات متعددة في دفعة واحدة من الإرسال. إذا لم يتم تحديد هذه القيمة، فإن أجهزة مودم كبل DOCSIS 1.0 وأجهزة مودم DOCSIS 1.1 القديمة يفترض عدم وجود حد صريح معين على حجم الاندفاع المضغوط. تستخدم أجهزة المودم المتوافقة مع المراجعات الأحدث لمواصفات DOCSIS 1.1 أو الأحدث قيمة مقدارها 1522 بايت.
عندما يحتوي مودم الكبل على بيانات لنقلها بالنيابة عن تدفق خدمة أفضل جهد للتحميل، لا يمكن للمودم إعادة توجيه البيانات ببساطة إلى شبكة DOCSIS دون تأخير. يجب أن يمر المودم بعملية يطلب فيها المودم وقت إرسال حصري من CMTS. تضمن عملية الطلب هذه عدم تعارض البيانات مع عمليات إرسال مودم كبل آخر متصل بنفس قناة الخادم.
في بعض الأحيان، تقوم CMTS بجدولة فترات معينة يسمح فيها CMTS لأجهزة مودم الكبلات بإرسال رسائل خاصة تسمى طلبات النطاق الترددي. يعد طلب النطاق الترددي إطارا صغيرا للغاية يحتوي على تفاصيل مقدار البيانات التي يريد المودم إرسالها، بالإضافة إلى معرف الخدمة (SID) الذي يتوافق مع تدفق خدمة البث الذي يحتاج إلى إرسال البيانات. يحتفظ CMTS بجدول داخلي مطابق لأرقام SID لتدفقات خدمة تدفق البيانات.
يقوم CMTS بجدولة فرص طلب النطاق الترددي عندما لا تتم جدولة أي أحداث أخرى في الخادم. بمعنى آخر، يوفر المجدول فرص طلب النطاق الترددي عندما لا تخطط أداة جدولة البث الأولي لمنح أفضل الجهود، أو منحة UGS أو نوع آخر من المنح لوضعها في نقطة معينة. لذلك، عند إستخدام قناة تدفق بيانات إلى الخادم بشكل كبير، تكون الفرص المتاحة لأجهزة مودم الكبلات لنقل طلبات النطاق الترددي أقل.
يضمن نظام إدارة الهيكل (CMTS) دائما جدولة عدد قليل من فرص طلب عرض النطاق الترددي بانتظام، بغض النظر عن مدى الازدحام الذي تصبح عليه قناة الخادم. يمكن أن تنقل أجهزة مودم الكبلات المتعددة طلبات النطاق الترددي في نفس الوقت، كما يمكن أن تفسد عمليات إرسال بعضها البعض. لتقليل أحتمالية التصادمات التي يمكن أن تؤدي إلى تلف طلبات النطاق الترددي، تم وضع خوارزمية "التراجع وإعادة المحاولة". تناقش الأقسام التالية من هذا المستند هذه الخوارزمية.
عندما يستقبل CMTS طلب نطاق ترددي من مودم كبل، يقوم CMTS بتنفيذ هذه الإجراءات:
يستخدم CMTS رقم معرف الأمان (SID) الذي تم إستقباله في طلب النطاق الترددي لفحص تدفق الخدمة الذي يقترن به طلب النطاق الترددي.
وبعد ذلك يستخدم CMTS خوارزمية دلو الرمز المميز. تساعد هذه الخوارزمية CMTS في التحقق مما إذا كان تدفق الخدمة سوف يتجاوز الحد الأقصى المحدد للمعدل المستدام إذا كان CMTS يمنح النطاق الترددي المطلوب. فيما يلي حساب خوارزمية دلو الرمز المميز:
الحد الأقصى(t) = t * (r / 8) + b
حيث:
يشير Max(T) إلى الحد الأقصى لعدد وحدات البايت التي يمكن إرسالها على تدفق الخدمة عبر الوقت T.
T يمثل الوقت بالثواني.
يشير R إلى الحد الأقصى لمعدل حركة المرور المستمرة لتدفق الخدمة في وحدات بت في الثانية
B هو الحد الأقصى لانفجار حركة مرور البيانات لتدفق الخدمة بالبايت.
عندما يتحقق CMTS من أن طلب النطاق الترددي يقع ضمن حدود الإنتاجية، يقوم CMTS بوضع تفاصيل طلب النطاق الترددي في قائمة انتظار إلى مجدول البث. تحدد أداة جدولة تدفق البيانات من الخادم متى يتم منح طلب عرض النطاق الترددي.
تقوم Cisco uBR CMTS بتنفيذ لوغاريتمي مجدول للتحميل، ويطلقان على مجدول متوافق مع DOCSIS وأداة الجدولة الزمنية لقوائم انتظار المهلة المنخفضة. راجع قسم المجدول المتوافق مع DOCSIS وجدول قوائم انتظار المهلة المنخفضة في هذا المستند للحصول على مزيد من المعلومات.
يقوم CMTS بعد ذلك بتضمين هذه التفاصيل في رسالة خريطة تخصيص عرض النطاق الترددي الدورية التالية:
عند قدرة مودم الكبل على الإرسال.
طوال المدة التي يتمكن فيها مودم الكبل من الإرسال.
تستخدم آلية طلب عرض النطاق الترددي خوارزمية "رد الفعل وإعادة المحاولة" البسيطة لتقليل أحتمالية التصادم بين أجهزة مودم الكبلات المتعددة التي تنقل طلبات عرض النطاق الترددي في نفس الوقت، ولكن ليس القضاء عليها تماما.
يجب أن ينتظر مودم الكبل الذي يقرر إرسال طلب النطاق الترددي أولا عدد عشوائي من فرص طلب النطاق الترددي قبل أن يقوم المودم بإجراء الإرسال. يساعد وقت الانتظار هذا على تقليل إمكانية حدوث التصادمات بسبب الإرسال المتزامن لطلبات النطاق الترددي.
تم إستدعاء بدء تشغيل البيانات المعززة وتحديد نهاية البيانات لفترة الانتظار العشوائية. تتعرف أجهزة مودم الكبلات على هذه المعلمات كجزء من محتويات رسالة واصف قناة المنبع الدورية (UCD). يرسل CMTS رسالة UCD نيابة عن كل قناة نشطة للتدفق كل ثانيتين.
ويعبر عن هذه البارامترات الاحتياطية على أنها "قوة قيمتين". تستخدم أجهزة المودم هذه المعلمات كقوى من إثنين لحساب المدة التي يجب انتظارها قبل إرسال طلبات النطاق الترددي. كلتا القيمتين لها نطاق من 0 إلى 15 ويجب أن تكون نهاية التراجع للبيانات أكبر من أو تساوي بداية التراجع عن البيانات.
في المرة الأولى التي يريد فيها مودم الكبل إرسال طلب نطاق ترددي معين، يجب على مودم الكبل انتقاء رقم عشوائي بين 0 و 2 أولا إلى طاقة بداية التراجع عن البيانات - 1. على سبيل المثال، إذا تم تعيين بداية التراجع عن البيانات على 3، فيجب على المودم إختيار رقم عشوائي بين 0 و (23 - 1) = (8 - 1) = 7.
ويجب بعد ذلك أن ينتظر مودم الكبل مرور العدد العشوائي المحدد من فرص إرسال طلب النطاق الترددي قبل أن يرسل المودم طلب النطاق الترددي. وبالتالي، في حين لا يستطيع المودم إرسال طلب عرض نطاق عند الفرصة التالية المتاحة بسبب هذا التأخير القسري، فإن إمكانية التصادم مع بث مودم آخر تقل.
وبشكل طبيعي كلما زادت قيمة بدء تشغيل تشغيل إيقاف البيانات، أقل هو إمكانية التصادم بين طلب النطاق الترددي. تعني قيم بدء تشغيل النسخ الاحتياطية للبيانات الأكبر أيضا أنه من المحتمل أن تحتاج أجهزة المودم إلى الانتظار لفترة أطول لنقل طلبات النطاق الترددي، وبالتالي زيادة زمن الوصول إلى الخادم.
يتضمن CMTS إقرارا في رسالة خريطة تخصيص عرض النطاق الترددي المرسلة التالية. يقوم هذا الإقرار بإعلام مودم الكبل بأن طلب النطاق الترددي تم تلقيه بنجاح. يمكن لهذا الإقرار:
إما أن تشير إلى الوقت الذي يمكن فيه للمودم إجراء الإرسال
أو
قم بالإشارة فقط إلى أنه تم تلقي طلب عرض النطاق الترددي وأنه سيتم تحديد وقت الإرسال في رسالة خريطة مستقبلية.
إذا لم يتضمن CMTS إقرارا بطلب النطاق الترددي في رسالة الخريطة التالية، فيمكن للمودم أن يستنتج أن طلب النطاق الترددي لم يتم إستلامه. قد يحدث هذا الموقف بسبب تصادم، أو ضوضاء في الخادم، أو لأن تدفق الخدمة يتجاوز الحد الأقصى لمعدل الإنتاجية المحدد في حالة الموافقة على الطلب.
في كلتا الحالتين، تتمثل الخطوة التالية لمودم الكبل في التراجع، ثم حاول إرسال طلب النطاق الترددي مرة أخرى. يزيد المودم من النطاق الذي يتم فيه إختيار قيمة عشوائية. وللقيام بذلك، يضيف المودم واحدا إلى قيمة بدء تشغيل النسخ الاحتياطي للبيانات. على سبيل المثال، إذا كانت قيمة بداية إيقاف البيانات هي 3، وفشل CMTS في تلقي إرسال طلب عرض نطاق ترددي واحد، فإن المودم ينتظر قيمة عشوائية بين 0 و 15 فرصة لطلب عرض النطاق الترددي قبل إعادة الإرسال. هنا الحساب: 23+1 - 1 = 24 - 1 = 16 - 1 = 15
النطاق الأكبر للقيم يقلل من فرصة حدوث تصادم آخر. إذا فقد المودم المزيد من طلبات النطاق الترددي، يستمر المودم في زيادة القيمة المستخدمة كطاقة لعنصرين لكل عملية إعادة إرسال حتى تصبح القيمة مساوية لنهاية النسخ الاحتياطي للبيانات. يجب ألا تنمو قوة الطرازين لتصبح أكبر من قيمة نهاية ظهر البيانات.
يرسل المودم طلب نطاق ترددي حتى 16 مرة، وبعد ذلك يتجاهل المودم طلب النطاق الترددي. يحدث هذا الموقف فقط في ظروف شديدة الازدحام.
أنت يستطيع شكلت المعطيات boucle بداية و معطيات نهاية خلفي قيمة لكل كبل up على cisco uBR CMTS مع هذا كبل قارن أمر:
نهاية لمصدر بيانات تدفق الكبل-نسخ إحتياطي للبيانات-بيانات-إيقاف تشغيل لمصدر بيانات
توصي Cisco بالاحتفاظ بالقيم الافتراضية لمعلمات بدء إيقاف تشغيل البيانات وإيقاف تشغيل البيانات، والتي تكون 3 و 5. وتعني طبيعة نظام جدولة أفضل الجهود القائمة على التنازع أنه بالنسبة لتدفقات خدمة أفضل الجهود، من المستحيل توفير مستوى محدد أو مضمون من زمن الوصول أو التشوه عند أعلى المجهود. وبالإضافة إلى ذلك، فإن الظروف المزدحمة قد تجعل من المستحيل ضمان مستوى معين من الإنتاجية من أجل تدفق خدمة أفضل الجهود. ومع ذلك، يمكنك إستخدام خصائص تدفق الخدمة مثل الأولوية والحد الأدنى للمعدل المحجوز. ومع هذه الخصائص، يمكن لتدفق الخدمة أن يحقق المستوى المرغوب من الخرج في الظروف المزدحمة.
يتضمن هذا المثال أربعة أجهزة مودم لكبلات باسم A و B و C و D، متصلة بنفس قناة المنبع. في نفس الوقت الذي يسمى T0، تقرر أجهزة المودم A و B و C إرسال بعض البيانات في الخادم.
هنا، تم تعيين بداية التراجع للبيانات على 2 وتم تعيين نهاية التراجع للبيانات على 4. يتراوح نطاق الفواصل التي تختار منها أجهزة المودم فترة قبل أن تحاول أولا إرسال طلب النطاق الترددي بين 0 و 3. هنا الحساب:
(22 - 1) = (4 - 1) = 3 فترات.
فيما يلي عدد فرص طلب النطاق الترددي التي تختارها أجهزة المودم الثلاثة للانتظار من الوقت t0.
المودم A: 3
المودم B: 2
المودم C: 3
لاحظ أن المودم A والمودم C يختاران نفس عدد الفرص للانتظار.
ينتظر المودم B فرصتين لطلب النطاق الترددي تظهر بعد T0. يرسل المودم B بعد ذلك طلب النطاق الترددي، والذي يتلقاه CMTS. ينتظر المودم A والمودم C كلاهما تمرير 3 فرص لطلب النطاق الترددي بعد T0. ثم يقوم المودم A و C بإرسال طلبات النطاق الترددي في نفس الوقت. هذان الطلبان للنطاق الترددي يصطدمان ويصبحان فاسدين. ونتيجة لذلك، لم يصل أي من الطلبين إلى CMTS بنجاح. الشكل 2 يوضح تسلسل الأحداث هذا.
الشكل 2 - مثال طلب النطاق الترددي العريض الجزء 1
يمثل الشريط الرمادي في أعلى المخطط سلسلة من فرص طلب النطاق الترددي المتاحة لأجهزة مودم الكبلات بعد الوقت t0. تمثل الأسهم الملونة طلبات النطاق الترددي التي تقوم أجهزة مودم الكبل بنقلها. يمثل المربع الملون داخل الشريط الرمادي طلب عرض نطاق يصل إلى CMTS بنجاح.
تحتوي رسالة الخريطة التالية التي يتم بثها من CMTS على منحة للمودم B ولكن ليس هناك تعليمات للمودم A و C. وهذا يشير إلى المودم A و C أنهم يحتاجون إلى إعادة إرسال طلبات عرض النطاق الترددي.
وفي المحاولة الثانية، يحتاج المودم A والمودم C إلى زيادة طاقة مودم A ومودم C لاستخدامه عند حساب نطاق الفواصل الزمنية التي يتم الانتقاء منها. الآن، يقوم المودم A والمودم C باختيار عدد عشوائي من الفواصل الزمنية بين 0 و 7. هنا الحساب:
(22+1 -1) = (23-1) = (8-1) = 7 فترات.
بافتراض أن الوقت الذي يدرك فيه المودم A والمودم C الحاجة إلى إعادة الإرسال هو t1. افترض أيضا أن مودم آخر يسمى مودم D يقرر أن يبث بعض بيانات المنبع في نفس اللحظة، t1. المودم D على وشك إجراء إرسال طلب عرض النطاق الترددي لأول مرة. وبالتالي، يستخدم المودم D القيمة الأصلية لبدء تشغيل البيانات المعززة ونهاية فصل البيانات، أي بين 0 و 3 [(22 - 1) = (4 - 1) = 3 فواصل].
تختار أجهزة المودم الثلاثة هذا العدد العشوائي من فرص طلب عرض النطاق الترددي للانتظار من الوقت t1.
المودم A: 5
المودم C: 2
المودم D: 2
ينتظر كل من أجهزة المودم C و D فرصتي طلب عرض النطاق الترددي التي تظهر بعد الوقت T1. ثم يقوم المودم C و D بإرسال طلبات النطاق الترددي في نفس الوقت. وتتصادم طلبات عرض النطاق الترددي هذه وبالتالي لا تصل إلى CMTS. يتيح المودم A خمس فرص لتمرير طلب عرض النطاق الترددي. بعد ذلك، يرسل المودم A طلب النطاق الترددي، والذي يتلقاه CMTS. الشكل 3 يوضح التضارب بين إرسال المودم C و D، والاستلام الناجح لإرسال المودم A. مرجع وقت البدء لهذا الشكل هو t1.
الشكل 3 - مثال طلب النطاق الترددي العريض الجزء 2
يحتوي بث رسالة الخريطة التالي من CMTS على منحة للمودم A ولكن لا توجد تعليمات للمودم C والمودم D. يدرك المودم C و D الحاجة إلى إعادة إرسال طلبات النطاق الترددي. المودم D الآن على وشك إرسال طلب النطاق الترددي للمرة الثانية. لذلك، يستخدم المودم D بداية التراجع للبيانات + 1 كقوة الرقم 2 لاستخدامه في حساب نطاق الفواصل الزمنية للانتظار. يختار المودم D الفاصل الزمني بين 0 و 7. هنا الحساب:
(22+1 - 1) = (23 - 1) = (8 - 1) = 7 فترات.
المودم C على وشك إرسال طلب النطاق الترددي للمرة الثالثة. وبالتالي، يستخدم المودم C بداية إيقاف تشغيل البيانات + 2 كطاقة مقدارها 2 إلى حساب نطاق الفواصل الزمنية للانتظار. يختار المودم C الفاصل الزمني بين 0 و 15. هنا الحساب:
(22+2 - 1) = (24 - 1) = (16 - 1) = 15 فاصل زمني.
لاحظ أن طاقة إثنين هنا هي نفسها قيمة نهاية نهاية نهاية المعطيات، والتي هي أربعة. وهذا هو أعلى مستوى يمكن أن تكون فيه قوة القيمتين لمودم على قناة المنبع هذه. في دورة الإرسال التالية لطلب عرض النطاق الترددي، تختار أجهزة المودم إثنان هذا العدد من فرص طلب عرض النطاق الترددي للانتظار:
المودم C: 9
المودم D: 4
يمكن للمودم D إرسال طلب النطاق الترددي لأن المودم D ينتظر أربع فرص لتمرير طلب النطاق الترددي. بالإضافة إلى ذلك، يمكن للمودم C أيضا إرسال طلب النطاق الترددي، لأن المودم C يؤجل الإرسال الآن لتسع فرص لطلب النطاق الترددي.
ولسوء الحظ، عندما ينتقل المودم C، تتداخل موجة كبيرة من ضجيج الدخول مع الإرسال، ويفشل CMTS في تلقي طلب النطاق الترددي (انظر الشكل 4). ونتيجة لذلك، مرة أخرى، يفشل المودم C في رؤية منحة في رسالة الخريطة التالية التي يرسلها CMTS. وهذا يجعل المودم C يحاول نقل طلب النطاق الترددي للمرة الرابعة.
الشكل 4 - المثال 3 لطلب النطاق الترددي العريض
لقد وصل المودم C بالفعل إلى قيمة نهاية خروج البيانات التي تبلغ 4. يتعذر على المودم C زيادة النطاق المستخدم لاختيار عدد عشوائي من الفواصل الزمنية للانتظار. لذلك، يستخدم المودم C مرة أخرى 4 كطاقة مقدارها إثنان لحساب النطاق العشوائي. لا يزال المودم C يستخدم الفواصل الزمنية بين 0 و 15 لكل عملية حسابية هذه:
(24 - 1) = (16 - 1) = 15 فاصل زمني.
وفي المحاولة الرابعة، يكون المودم C قادرا على إرسال طلب عرض النطاق الترددي بنجاح في غياب النزاع أو الضوضاء.
توضح عمليات إعادة إرسال طلب عرض النطاق الترددي المتعددة للمودم C في هذا المثال ما يمكن أن يحدث على قناة تدفق البيانات في الجزء العلوي المزدحمة. يوضح هذا المثال أيضا المشكلات المحتملة التي ينطوي عليها وضع جدولة أفضل الجهود والسبب في أن جدولة أفضل الجهود غير مناسبة للخدمات التي تتطلب مستويات تخضع لقيود صارمة من زمن وصول الحزم وترددها.
عندما يحتوي CMTS على العديد من طلبات النطاق الترددي المعلقة من تدفقات الخدمة، ينظر CMTS في أولوية حركة المرور لكل تدفق خدمة لتحديد أي من التدفقات تمنح النطاق الترددي أولا.
يمنح CMTS وقت الإرسال لجميع الطلبات المعلقة من تدفقات الخدمة ذات الأولوية الأعلى قبل طلبات النطاق الترددي من تدفقات الخدمة ذات الأولوية الأقل. وفي حالات الازدحام عند أعلى المجاري، يؤدي ذلك بشكل عام إلى معدل أعلى لإنتاجية تدفقات الخدمات ذات الأولوية العالية مقارنة بتدفقات الخدمات ذات الأولوية المنخفضة.
من الحقائق الهامة التي تجدر ملاحظتها أنه في حين أن تدفق خدمة أفضل الجهود ذات الأولوية العالية من المرجح أن يستقبل النطاق الترددي بسرعة أكبر، فإن تدفق الخدمة لا يزال خاضعا لاحتمال تصادمات طلب النطاق الترددي العريض. ولهذا السبب، فبينما يمكن لأولوية حركة المرور تحسين خصائص الإنتاجية وزمن الوصول لتدفق الخدمة، لا تزال أولوية حركة المرور ليست الطريقة المناسبة لتوفير ضمان خدمة للتطبيقات التي تتطلب ذلك.
يمكن أن تتلقى تدفقات خدمة أفضل الجهود الحد الأدنى للمعدل المحجوز الذي يجب الامتثال له. يضمن CMTS أن سير الخدمة مع الحد الأدنى المحدد للمعدل المحجوز يستلم النطاق الترددي بالتفضيل على جميع تدفقات خدمة أفضل الجهود الأخرى، بغض النظر عن الأولوية.
هذه الطريقة هي محاولة لتوفير نوع من خدمة نمط معدل المعلومات الملتزم به (CIR) مماثل لشبكة ترحيل الإطارات. يحتوي CMTS على آليات التحكم في الدخول لضمان أنه في تدفق بيانات مرتفع معين، لا يمكن أن يتجاوز الحد الأدنى المحجوز المجمع لجميع تدفقات الخدمة المتصلة النطاق الترددي المتاح لقناة الخادم، أو نسبة مئوية منه. أنت يستطيع نشط هذا آلية مع هذا لكل up port أمر:
[no] التحكم في الدخول إلى الخادم العلوي لكابل-port-id الحد الأقصى للحجز-الحد
تتراوح المعلمة Max-Reservation-Limit من 10 إلى 1000 بالمائة للإشارة إلى مستوى الاشتراك بالمقارنة مع سعة المعالجة المتوفرة للقناة الأولية التي يمكن أن تستهلكها خدمات نمط CIR. إذا قمت بتكوين حد أقصى للحجز أكبر من 100، يمكن أن يقوم الخادم بإفراط في الاشتراك في خدمات نمط CIR عن طريق حد النسبة المئوية المحدد.
لا يسمح CMTS بإنشاء تدفقات خدمة الحد الأدنى الجديد للسعر المحجوز إذا كانت ستتسبب في تجاوز منفذ التحميل النسبة المئوية للحد الأقصى للحجز الذي تم تكوينه للنطاق الترددي لقناة تدفق الخادم المتوفرة. لا يزال الحد الأدنى لتدفقات خدمة المعدل المحجوز خاضعا لتصادمات محتملة لطلبات النطاق الترددي. وعلى هذا النحو، لا يمكن أن يوفر الحد الأدنى من تدفقات خدمة السعر المحجوز ضمانا حقيقيا لمعدل نقل معين، لا سيما في ظروف شديدة الازدحام. بمعنى آخر، يمكن ل CMTS فقط ضمان أن الحد الأدنى لتدفق الخدمة بمعدل محجوز يمكن أن يحقق معدل إنتاجية معين مضمون إذا كان CMTS قادرا على تلقي جميع طلبات النطاق الترددي المطلوبة من مودم الكبل. يمكن تحقيق هذا المتطلب إذا قمت بجعل تدفق الخدمة تدفق خدمة اقتراع في الوقت الفعلي (RTPS) بدلا من تدفق خدمة أفضل جهد. راجع قسم خدمة الاقتراع في الوقت الفعلي (RTPS) للحصول على مزيد من المعلومات.
عندما يقوم تدفق خدمة أفضل المجهودات من الخادم بإرسال إطارات بمعدل مرتفع، من الممكن إرسال طلبات عرض النطاق الترددي إلى إطارات بيانات المنبع بدلا من إجراء إرسال منفصل لطلبات عرض النطاق الترددي. تتم ببساطة إضافة تفاصيل الطلب التالي للنطاق الترددي إلى رأس حزمة البيانات التي يتم إرسالها في الخادم إلى CMTS.
وهذا يعني أن طلب النطاق الترددي غير خاضع للجدل وبالتالي لديه فرصة أكبر بكثير للوصول إلى CMTS. يقلل مفهوم طلبات عرض النطاق الترددي Piggyback الوقت الذي يستغرقه إطار إيثرنت للوصول إلى أجهزة العميل الأصلية (CPE) الخاصة بالمستخدم النهائي، نظرا لأن الوقت الذي يستغرقه هذا الإطار في نقل البيانات من الخادم يقلل من الوقت. وذلك نظرا لأن المودم لا يحتاج إلى إجراء عملية النقل الاحتياطي وإعادة محاولة إرسال طلب النطاق الترددي، والتي يمكن أن تكون عرضة للتأخير.
يقع تتبع طلبات النطاق الترددي عادة في هذا السيناريو:
بينما ينتظر مودم الكبل أن يبث إطار، لنقل X، في المنبع، يستلم المودم إطارا آخر، لنقل Y، من CPE أن يبث في المنبع. يتعذر على مودم الكبل إضافة وحدات البايت من الإطار الجديد Y إلى الإرسال، لأن ذلك يتضمن إستخدام وقت أعلى من منح المودم. بدلا من ذلك، يعبئ المودم في حقل في رأس DOCSIS للإطار X ليشير إلى مقدار وقت الإرسال المطلوب للإطار Y.
يتلقى CMTS الإطار X وكذلك تفاصيل طلب عرض النطاق نيابة عن Y. على أساس التوفر، يمنح CMTS المودم وقت إرسال إضافي نيابة عن Y.
وبمصطلحات محافظة جدا، تنقضي فترة قصيرة تصل إلى 5 مللي ثانية بين إرسال طلب عرض النطاق الترددي واستلام تخصيص عرض النطاق الترددي، بالإضافة إلى إقرار MAP الذي يحدد وقتا لنقل البيانات. هذا يعني أنه للحصول على وضع "الخوض"، يحتاج مودم الكبل إلى تلقي إطارات من CPE ضمن أقل من 5 مللي ثانية من بعضهم البعض.
وهذا جدير بالملاحظة لأن برنامج ترميز VoIP نموذجي مثل G.711 يستخدم بشكل عام فترة بين الإطارات مقدارها 10 أو 20 مللي ثانية. لا يمكن أن يستفيد الدفق النموذجي لنقل الصوت عبر بروتوكول الإنترنت (VoIP) الذي يعمل على تدفق خدمة أفضل الجهود من ميزة دعم الحمام.
عندما يقوم تدفق خدمة أفضل جهد تدفق تدفق تدفق تدفق تدفق تدفق أعلى الإطارات بسرعة عالية، يمكن أن يتلاقى مودم الكبل مع بعض الإطارات معا ويطلب الإذن لنقل الإطارات في نفس الوقت. هذا يسمى ترقيق. يحتاج مودم الكبل إلى إرسال طلب نطاق ترددي واحد فقط بالنيابة عن كل الإطارات في مجموعة من الإطارات المحددة، مما يحسن الكفاءة.
يحدث غالبا Concatenation في ظروف مماثلة ل Piggyback باستثناء أن Concation يتطلب إطارات متعددة ليتم وضعها في قائمة الانتظار داخل مودم الكبل عندما يقرر المودم أن يرسل طلب عرض نطاق. وهذا يعني أن الهضم يميل إلى الحدوث بمعدلات إطارات أعلى من تلك التي تحدث عند ظهور الخصر. كما أن كلا الآليتين تعملان معا بشكل عام لتحسين كفاءة حركة مرور الجهود المثلى.
يحد حقل الاندفاع التفصيلي الأقصى الذي يمكنك تكوينه لتدفق الخدمة الحد الأقصى لحجم الإطار المضغوط الذي يمكن أن ينقله تدفق الخدمة. يمكنك أيضا إستخدام أمر cable default-phy-burst للحد من حجم الإطار المضغوط والحد الأقصى لحجم الاندفاع في ملف تعريف تعديل قناة المنبع.
مكنت تشكيل افتراضيا على ال up ميناء من ال cisco uBR sery من CMTS. ومع ذلك، يمكنك التحكم في التكوين على أساس كل تدفق-port باستخدام أمر واجهة الكبل [no] cable upstream upstream-port-id [docsis10].
إذا قمت بتكوين معلمة DOCSIS10، فإن الأمر يطبق فقط على أجهزة مودم الكبلات التي تعمل في وضع DOCSIS 1.0.
إذا قمت بإجراء تغييرات على هذا الأمر، فيجب إعادة تسجيل أجهزة مودم الكبلات على CMTS لكي تصبح التغييرات نافذة المفعول. يجب إعادة تعيين أجهزة المودم الموجودة على الخادم المتأثر. يتعرف مودم الكبل على ما إذا كان مسموحا إجراء العملية الصغيرة عند النقطة التي يقوم فيها المودم بإجراء التسجيل كجزء من عملية الوصول إلى الإنترنت.
تستغرق الإطارات الكبيرة وقتا طويلا للإرسال في المنبع. يعرف وقت الإرسال هذا باسم تأخير التسلسل. خاصة أن إطارات المنبع الكبيرة يمكن أن تستغرق وقتا طويلا للإرسال حتى أنها يمكن أن تؤخر الحزم التي تنتمي إلى الخدمات الحساسة للوقت، على سبيل المثال، VoIP. هذا صحيح خاصة للإطارات المسقطة الكبيرة. لهذا السبب، تم تقديم التجزئة في DOCSIS 1.1 حتى يمكن تقسيم الإطارات الكبيرة إلى إطارات أصغر للإرسال في دفعات منفصلة يستغرق كل منها وقتا أقل للإرسال.
يتيح التفتت أن يتم تداخل الإطارات الصغيرة الحساسة للوقت بين أجزاء الإطارات الكبيرة بدلا من انتظار إرسال الإطار الكبير بأكمله. نقل إطار كأجزاء متعددة أقل فعالية بقليل من نقل إطار في دفعة واحدة بسبب المجموعة الإضافية من رؤوس DOCSIS التي يجب أن ترافق كل جزء. ومع ذلك، فإن المرونة التي تضيفها التجزئة إلى قناة المنبع تبرر النفقات الإضافية.
لا يمكن لأجهزة مودم الكبلات التي تعمل في وضع DOCSIS 1.0 إجراء التجزئة.
يتم تمكين التجزئة بشكل افتراضي على منافذ الخادم لسلسلة Cisco uBR من CMTS. ومع ذلك، يمكنك تمكين التجزئة أو تعطيلها على أساس كل تدفق-port باستخدام أمر واجهة كبل [no] cable upstream upstream-port-id.
لا تحتاج إلى إعادة ضبط أجهزة مودم الكبل لكي يدخل الأمر حيز التنفيذ. توصي Cisco بتمكين التجزئة دائما. يحدث التجزئة عادة عندما يعتقد CMTS أن إطار البيانات الكبير يمكن أن يتداخل مع إرسال الإطارات الصغيرة الحساسة للوقت أو أحداث إدارة DOCSIS دورية معينة.
يمكنك فرض أجهزة مودم كبل DOCSIS 1.1/2.0 لتجزئة جميع الإطارات الكبيرة باستخدام أمر واجهة الكبل [no] up stream-port-id fragment-force [threshold number-of-parts].
افتراضيا، أعجزت هذا سمة. إذا لم تقم بتحديد قيم للحد وعدد الأجزاء في التكوين، فإنه يتم تعيين الحد على 2000 بايت ويتم تعيين عدد الأجزاء على 3. يقوم الأمر fragment-force بمقارنة عدد وحدات البايت التي يطلبها تدفق الخدمة للإرسال مع معلمة الحد المحددة. إذا كان حجم الطلب أكبر من الحد، فإن نظام إدارة الهيكل (CMTS) يمنح النطاق الترددي لتدفق الخدمة في "عدد الأجزاء" ذات الحجم المتساوي.
على سبيل المثال، افترض أنه تم تمكين قوة جزء المنبع الخاصة بقيمة 2000 بايت للعتبة و 3 لعدد الأجزاء. ثم افترض أن طلبا لنقل انفجار 3000 بايت قد وصل. بما أن 3000 بايت أكبر من الحد البالغ 2000 بايت، يجب تجزئة المنحة. ونظرا لتعيين عدد الأجزاء على 3، فإن وقت الإرسال هو ثلاث منح متساوية الحجم لكل منها بواقع 1000 بايت.
أحرص على التأكد من أن أحجام الأجزاء الفردية لا تتجاوز قدرة نوع بطاقة خط الكبل قيد الاستخدام. بالنسبة لبطاقات الخط MC5x20S، يجب ألا يتجاوز حجم الجزء الفردي الأكبر 2000 بايت، وبالنسبة لبطاقات الخط الأخرى، بما في ذلك MC28U و MC5x20U و MC5x20H، يجب ألا يتجاوز حجم الجزء الفردي الأكبر 4000 بايت.
توفر "خدمة المنح غير المرغوب فيها" (UGS) منح دورية لتدفق خدمة تدفق بيانات الخادم دون الحاجة إلى مودم كبل لنقل طلبات النطاق الترددي. هذا النوع من الخدمة مناسب للتطبيقات التي تقوم بإنشاء إطارات ثابتة الحجم على فترات زمنية منتظمة وغير مسموح بها لفقدان الحزمة. نقل الصوت عبر بروتوكول الإنترنت (IP) هو المثال التقليدي.
قارن نظام جدولة UGS بفتحة زمنية في نظام تجميع تقسيم الوقت (TDM) مثل الدائرة T1 أو E1. توفر UGS سعة معالجة ووقت وصول مضمونين، مما يوفر بدوره دفقا مستمرا من الفواصل الزمنية الدورية الثابتة للإرسال دون الحاجة إلى أن يقوم العميل بشكل دوري بطلب النطاق الترددي أو المطالبة به بشكل متكرر. يعد هذا النظام مثاليا لنقل الصوت عبر بروتوكول VoIP لأن حركة المرور الصوتية يتم إرسالها بشكل عام كتدفق مستمر من البيانات الدورية ذات الحجم الثابت.
تم تصميم UGS بسبب عدم وجود ضمانات لزمن الوصول والتشوه وسعة المعالجة في وضع جدولة أفضل الجهود. أفضل طريقة لجدولة الجهد لا توفر الضمان بأن إطارا معينا يمكن أن يرسل في وقت معين، وفي نظام محتقن لا يوجد ضمان أن إطارا معينا يمكن أن يرسل على الإطلاق.
لاحظ أنه على الرغم من أن تدفقات خدمة نمط UGS هي النوع الأنسب لتدفق الخدمة لنقل حركة مرور حامل VoIP، إلا أنها لا تعتبر مناسبة لتطبيقات الإنترنت الكلاسيكية مثل الويب أو البريد الإلكتروني أو P2P. وذلك لأن تطبيقات الإنترنت الكلاسيكية لا تولد بيانات على فترات دورية ثابتة، بل يمكنها في الواقع أن تقضي فترات زمنية طويلة دون نقل البيانات على الإطلاق. إذا تم إستخدام تدفق خدمة UGS لنقل حركة مرور الإنترنت التقليدية، يمكن أن يتم إستخدام تدفق الخدمة لفترات كبيرة عندما يتوقف التطبيق عن عمليات الإرسال لفترة وجيزة. وهذا يؤدي إلى منح UGS غير المستخدمة التي تمثل هدرا لموارد عرض النطاق الترددي للمنبع وهو أمر غير مرغوب فيه.
عادة ما يتم إنشاء تدفقات خدمة UGS بشكل ديناميكي عند طلبها بدلا من إمدادها في ملف تكوين DOCSIS. عادة ما يمكن لمودم الكبل المزود بمنافذ VoIP المدمجة أن يطلب من CMTS إنشاء تدفق خدمة UGS مناسب عندما يكتشف المودم أن مكالمة هاتف VoIP قيد التقدم.
توصيك Cisco بعدم تكوين تدفق خدمة UGS في ملف تكوين DOCSIS لأن هذا التكوين يبقي تدفق خدمة UGS نشطا طوال مدة وجود مودم الكبل عبر الإنترنت سواء أكانت أي خدمات تستخدمه أم لا. يؤدي هذا التكوين إلى إهدار النطاق الترددي للتدفق من الخادم لأن تدفق خدمة UGS يقوم باستمرار باحتياطي وقت الإرسال من الخادم نيابة عن مودم الكبل. ومن الأفضل بكثير السماح بإنشاء تدفق خدمة UGS وحذفه بشكل ديناميكي بحيث يكون UGS نشطا عند الحاجة.
فيما يلي المعلمات الأكثر إستخداما التي تحدد تدفق خدمة UGS:
حجم المنحة غير المطلوب (G)—حجم كل منحة دورية بالبايت.
الفاصل الزمني للمنحة الاسمية (I) - الفاصل الزمني في الميكرو ثانية بين المنح.
رجفان الهبة المسموح به (J) — الاختلاف المسموح به في الميكرو ثانية من الهبات الدورية تماما. وبعبارة أخرى، هذا هو المجال الذي تتيحه CMTS عندما يحاول CMTS جدولة منحة UGS في الوقت المحدد.
عندما يكون تدفق خدمة UGS نشطا، كل (i) مللي ثانية، توفر CMTS فرصة لتدفق الخدمة للإرسال بالبايت "حجم المنحة (G) غير المرغوب فيه." على الرغم من أن CMTS يقدم المنحة بشكل نموذجي كل (I) مللي ثانية، إلا أنه قد يتأخر لمدة تصل إلى (J) مللي ثانية.
الشكل 5 يوضح جدولا زمنيا يوضح كيف يمكن تخصيص منح UGS مع حجم منحة معين، وفترة منح، ودرجة توتر مسموح بها.
الشكل 5 - الجدول الزمني الذي يوضح المنح الدورية من UGS
تمثل الوحدات المنقوشة باللون الأخضر الوقت الذي يقوم CMTS فيه بتخصيص وقت الإرسال إلى الخادم لتدفق خدمة UGS.
توفر خدمة Real Time Polling Service (RTPS) فرص دورية غير قائمة على النزاع لطلب عرض النطاق الترددي بحيث يحتوي تدفق الخدمة على وقت مخصص لنقل طلبات عرض النطاق الترددي. يسمح فقط لتدفق خدمة RTPS باستخدام فرصة طلب عرض النطاق الترددي للبث الأحادي هذه. لا يمكن أن تتسبب أجهزة مودم الكبل الأخرى في حدوث تعارض في طلب النطاق الترددي.
يعد RTPS مناسبا للتطبيقات التي تولد أطولا متغيرة على أساس نصف دوري وتتطلب سعة معالجة دنيا مضمونة للعمل بفعالية. ومن الأمثلة النموذجية على ذلك مهاتفة الفيديو عبر IP أو الألعاب عبر الإنترنت متعددة اللاعبين.
يتم إستخدام RTPS أيضا لحركة مرور إرسال إشارات VoIP. على الرغم من أنه لا يلزم إرسال حركة مرور إرسال إشارات VoIP بزمن وصول أو تشويش منخفض للغاية، إلا أن VoIP تحتاج إلى أحتمالية عالية للتمكن من الوصول إلى CMTS في فترة زمنية معقولة. إذا كنت تستخدم بروتوكول RTPS بدلا من جدولة أفضل الجهود، فيمكنك التأكد من أن إرسال الإشارات الصوتية لا يتم تأجيله أو إسقاطه بشكل كبير بسبب تصادمات طلب النطاق الترددي المتكررة.
يحتوي تدفق خدمة RTPS بشكل خاص على السمات التالية:
الفاصل الزمني للاستقصاء الاسمي— الفاصل الزمني بالميكروثانية بين فرص طلب عرض النطاق الترددي للبث الأحادي.
تشوه الأصوات المسموح به — الاختلاف المسموح به في جزء من الثانية قبل إستطلاعات الرأي الدورية بالضبط. وضع طريقة أخرى، هذه هي الطريقة التي تتبعها CMTS عند محاولة جدولة فرصة طلب عرض النطاق الترددي للبث الأحادي ل RTPS في الوقت المحدد.
يوضح الشكل 6 جدولا زمنيا يوضح كيفية تخصيص عمليات اقتراع RTPS مع فترة اقتراع إسمية محددة، مع تسامح تشوه الأصوات.
الشكل 6 - الخط الزمني الذي يوضح إستطلاع RTPS الدوري
تمثل الوحدات الصغيرة ذات النمط الأخضر الوقت الذي يوفر فيه CMTS تدفق خدمة RTPS فرصة لطلب عرض النطاق الترددي للبث الأحادي.
عندما يستقبل CMTS طلب نطاق ترددي نيابة عن تدفق خدمة RTPS، يعالج CMTS طلب النطاق الترددي بنفس الطريقة التي يتم بها معالجة طلب من تدفق خدمة "أفضل جهد". وهذا يعني أنه بالإضافة إلى المعلمات الواردة أعلاه، يجب تضمين الخصائص مثل الحد الأقصى لمعدل حركة المرور المستدام وأولوية حركة المرور في تعريف تدفق خدمة RTPS. كما يحتوي تدفق خدمة RTPS بشكل عام على الحد الأدنى لمعدل حركة المرور المحجوزة لضمان قدرة حركة المرور المرتبطة بتدفق الخدمة على تلقي ضمان النطاق الترددي الملتزم به.
تقوم خدمة المنح غير المرغوب فيها مع اكتشاف النشاط (UGS-AS) بتعيين وقت إرسال نمط UGS إلى تدفق الخدمة فقط عندما يحتاج UGS-AS بالفعل إلى إرسال الحزم. عندما يكتشف CMTS أن مودم الكبل لم يرسل إطارات لفترة معينة، فإن CMTS يوفر فرص طلب عرض النطاق الترددي لنمط RTPS بدلا من منح نمط UGS. إذا اكتشف CMTS بعد ذلك أن تدفق الخدمة يقوم بطلبات عرض النطاق الترددي، فإن CMTS يرجع تدفق الخدمة إلى تقديم منح نمط UGS ويتوقف عن توفير فرص طلب عرض النطاق الترددي على نمط RTPS.
وعادة ما يتم إستخدام UGS-AD في الحالة التي يتم فيها نقل حركة مرور VoIP التي تستخدم اكتشاف النشاط الصوتي (VAD). يتسبب اكتشاف نشاط الصوت في توقف نقطة نهاية بروتوكول VoIP عن إرسال إطارات VoIP إذا اكتشفت UGS-AD إيقاف مؤقت في خطاب المستخدم. على الرغم من أن هذا السلوك يمكن أن يوفر عرض النطاق، إلا أنه يمكن أن يسبب مشاكل في جودة الصوت، خاصة إذا كان VAD أو UGS-AD آلية كشف النشاط تنشط بشكل طفيف بعد أن يبدأ الطرف النهائي في إستئناف الحديث. قد يؤدي ذلك إلى ظهور صوت قرقعة أو النقر فوقه عندما يستأنف المستخدم التحدث بعد الصمت. ولهذا السبب لم يتم نشر UGS-AD على نطاق واسع.
قم بإصدار أمر تكوين CMTS العام حد عدم النشاط لخدمة الكبل في ثوان لتعيين الفترة التي يقوم CMTS بعدها بتبديل تدفق خدمة UGS-AD غير النشط من وضع UGS إلى وضع RTPS.
القيمة الافتراضية للمعلمة threshold-in-seconds هي 10 ثوان. تحمل تدفقات خدمة UGS-AD بشكل عام سمات تدفق خدمة UGS وفترة الاستقصاء الاسمية وسمة رجفان الاستطلاع المسموح بها المرتبطة بتدفقات خدمة RTPS.
وضع جدولة خدمة الاستقصاء في الوقت غير الحقيقي (nRTPS) هو أساسا نفس وضع RTPS باستثناء أن nRTPS مرتبط بشكل عام بالخدمات غير التفاعلية مثل عمليات نقل الملفات. يمكن أن يشير مكون الوقت غير الحقيقي إلى أن فترة الاستقصاء الاسمي لفرص طلب عرض النطاق الترددي للبث الأحادي ليست منتظمة تماما أو يمكن أن تحدث بمعدل أقل من واحد في الثانية.
يمكن أن تختار بعض مشغلي شبكة الكبلات إستخدام nRTPS بدلا من تدفقات خدمة RTPS لنقل حركة مرور إرسال الإشارات الصوتية.
قبل إجراء مناقشة حول تفاصيل أداة الجدولة المتوافقة مع DOCSIS وجدول قوائم انتظار المهلة المنخفضة، يجب عليك فهم المقايضات التي تحتاج إلى إجراؤها لتحديد خصائص أداة الجدولة الزمنية للتحميل. وعلى الرغم من أن مناقشة خوارزميات المجدول تتركز أساسا على وضع جدولة UGS، إلا أن المناقشة تنطبق أيضا على خدمات نمط RTPS.
عندما تقرر كيفية جدولة تدفقات خدمة UGS، فلن يكون هناك العديد من الخيارات المرنة. لا يمكنك جعل المجدول يغير حجم المنحة أو الفاصل الزمني للمنح الخاص بتدفقات خدمة UGS، لأن هذا التغيير يتسبب في فشل إستدعاءات VoIP بالكامل. ومع ذلك، إذا قمت بتغيير التشوه، فالمكالمات تعمل، وإن كان من المحتمل أن يكون ذلك مع زيادة زمن الوصول للمكالمة. بالإضافة إلى ذلك، لا يؤثر تعديل الحد الأقصى لعدد المكالمات المسموح بها على الخادم على جودة المكالمات الفردية. لذلك تأملوا في هذين العاملين الرئيسيين عندما تجدولة اعدادا كبيرة من تدفقات خدمة UGS:
رجفان
سعة تدفق خدمة UGS لكل عملية تحميل
يتم تحديد رجفان منح مسموح به كإحدى سمات تدفق خدمة UGS أو RTPS. ومع ذلك، يمكن أن يكون الدعم المتزامن لبعض تدفقات الخدمات التي تتسم بضعف درجة التذبذب الشديد وغيرها من الخدمات التي تتسم بكمية كبيرة جدا من الاهتزاز غير فعال. بشكل عام، يجب عليك إتخاذ خيار موحد فيما يتعلق بنوع الرجفان الذي تتدفق إستخدامه الخدمة على أعلى الخادم.
وإذا كان الأمر يتطلب مستويات منخفضة من الاهتزاز، فلابد أن تكون أداة الجدولة غير مرنة وصلبة عند جدولتها للمنح. ونتيجة لذلك، يحتاج المجدول إلى وضع قيود على عدد تدفقات خدمة UGS المدعومة على الخادم.
لا يلزم دائما أن تكون مستويات الرجفان منخفضة للغاية بالنسبة لمستهلك الصوت عبر بروتوكول الإنترنت (VoIP) العادي لأن تقنية التخزين المؤقت للرجفان قادرة على التعويض عن المستويات المرتفعة من الرجفان. يمكن لمخازن الصوت عبر بروتوكول الإنترنت (VoIP) المعدلة التعويض عن أكثر من 150 مللي ثانية من التشوه. ومع ذلك، تضيف شبكة VoIP مقدار التخزين المؤقت الذي يحدث إلى زمن انتقال الحزم. يمكن أن تساهم المستويات المرتفعة من زمن الوصول في التمتع بتجربة بروتوكول الصوت فوق الإنترنت (VoIP) الأكثر فقرا.
تحدد سمات الطبقة المادية مثل عرض القناة ومخطط التعديل وقوة تصحيح الخطأ السعة الفعلية للتدفق. ومع ذلك، يعتمد أيضا عدد تدفقات خدمة UGS المتزامنة التي يمكن أن يدعمها البث على خوارزمية المجدول.
إذا لم تكن مستويات الرجفان المنخفضة للغاية ضرورية، فيمكنك تخفيف صلابة المجدول ومواجهة عدد أكبر من تدفقات خدمة UGS التي يمكن أن يدعمها البث في نفس الوقت. يمكنك تحقيق كفاءة أعلى لحركة المرور غير الصوتية في أعلى الخادم إذا قمت بتخفيف متطلبات الرجفان.
ملاحظة: يمكن أن تسمح الخوارزميات المختلفة للجدولة بقناة معينة للتحميل بدعم أعداد مختلفة من تدفقات خدمات UGS و RTPS. ومع ذلك، لا يمكن أن تستخدم هذه الخدمات 100٪ من سعة الخادم في نظام DOCSIS. وذلك نظرا لأنه يجب على قناة الخادم تخصيص جزء لحركة مرور إدارة DOCSIS مثل رسائل الصيانة الأولية التي تستخدمها أجهزة مودم الكبلات لإجراء اتصال أولي مع CMTS، وحركة مرور keepalive لصيانة المحطة المستخدمة لضمان أن أجهزة مودم الكبلات يمكنها الحفاظ على الاتصال ب CMTS.
أداة الجدولة المتوافقة مع DOCSIS هي النظام الافتراضي لجدولة خدمات تدفق البيانات على Cisco uBR CMTS. تم تصميم أداة الجدولة هذه لتقليل الرجفان الذي يحدث في عمليات تدفق خدمة UGS و RTPS. ومع ذلك، لا تزال أداة الجدولة هذه تسمح لك بالحفاظ على درجة ما من المرونة من أجل تحسين عدد إستدعاءات UGS المتزامنة لكل تدفق.
تقوم أداة الجدولة المتوافقة مع DOCSIS بتخصيص وقت التشغيل مسبقا لتدفقات خدمة UGS. وقبل جدولة أي عمليات تخصيص أخرى للنطاق الترددي العريض، يخصص نظام إدارة الهيكل (CMTS) وقتا في المستقبل للمنح التي تنتمي إلى تدفقات خدمة UGS النشطة لضمان عدم قيام أي من الأنواع الأخرى من تدفقات الخدمة أو حركة المرور بتغيير منح UGS والتسبب في حدوث إرتباك كبير.
إذا كان CMTS يتلقى طلبات عرض النطاق الترددي نيابة عن تدفقات خدمة أسلوب أفضل جهد، فيجب على CMTS جدولة وقت الإرسال لتدفقات خدمة أفضل جهد حول منح UGS المخصصة مسبقا بحيث لا تؤثر على جدولة كل منحة UGS في الوقت المناسب.
أداة الجدولة المتوافقة مع DOCSIS هي خوارزمية المجدول الأولي الوحيدة المتوفرة للإصدارات 12.3(9a)BCx من برنامج Cisco IOS Software والإصدارات الأقدم. وبالتالي، لا يتطلب هذا المجدول أي أوامر تكوين للتنشيط.
بالنسبة للإصدارات 12.3(13a)BC من برنامج Cisco IOS Software والإصدارات الأحدث، يكون برنامج المجدول المتوافق مع DOCSIS هو أحد لوغاريتمي مجدول بديلين، ولكنه يتم تعيينه كمجدول افتراضي. يمكنك تمكين المجدول المتوافق مع DOCSIS لواحد أو كل أو بعض أنواع الجدولة التالية:
UGS
RTPS
NRTPS
يمكنك تمكين أداة الجدولة المتوافقة مع DOCSIS بشكل صريح لكل من أنواع الجدولة هذه باستخدام نوع جدولة تدفق الكبل لأعلى المنفذ [NRTPS | RTPS | ugs] mode docsis cable interface أمر.
يعد إستخدام أداة الجدولة المتوافقة مع DOCSIS جزءا من التكوين الافتراضي. لذلك، لا تحتاج إلى تنفيذ هذا الأمر إلا إذا قمت بالتغيير مرة أخرى من خوارزمية مجدول قوائم الانتظار غير الافتراضي بزمن وصول منخفض. راجع قسم مجدول قوائم انتظار المهلة المنخفضة للحصول على مزيد من المعلومات.
ومن المزايا الرائعة التي تتمتع بها أداة الجدولة المتوافقة مع DOCSIS أن أداة الجدولة هذه تضمن عدم زيادة تدفقات خدمة UGS عن اشتراكها في الخادم. إذا كان يجب إنشاء تدفق خدمة UGS جديد، واكتشف المجدول أن الجدولة المسبقة للمنح غير ممكنة بسبب عدم ترك مساحة، فإن CMTS يرفض تدفق خدمة UGS الجديد. إذا تم السماح بتدفق خدمة UGS التي تنقل حركة مرور VoIP بالإفراط في الاشتراك في قناة الخادم، فإن جودة جميع إستدعاءات VoIP تصبح متدنية للغاية.
لتوضيح كيف يضمن مجدول التوافق مع DOCSIS عدم تجاوز تدفقات خدمة UGS للاشتراك في الخادم مطلقا، ارجع إلى الأرقام الواردة في هذا القسم. تظهر الأشكال 7 و 8 و 9 بنود الوقت لتخصيص عرض النطاق الترددي.
في جميع هذه الأشكال، تظهر الأقسام المنقوشة بالألوان الوقت الذي تتلقى فيه أجهزة مودم الكبلات منح بالنيابة عن تدفقات خدمة UGS الخاصة بها. لا يمكن إجراء عمليات إرسال أخرى إلى الخادم من أجهزة مودم الكبلات الأخرى أثناء ذلك الوقت. الجزء الرمادي من الخط الزمني هو عرض نطاق ترددي غير مخصص حتى الآن. تستخدم أجهزة مودم الكبلات هذه المرة لنقل طلبات النطاق الترددي. يمكن ل CMTS إستخدام هذا الوقت لاحقا لجدولة أنواع أخرى من الخدمات.
الشكل 7 - جدولة خدمات DOCSIS المتوافقة مع ثلاثة تدفقات
قم بإضافة دفعي خدمة UGS إضافيين من نفس حجم المنحة وفترات المنحة. ومع ذلك، لا توجد مشكلة في جدولة المجدول مسبقا.
الشكل 8 - جدولة متوافقة مع DOCSIS تقوم بالتدفق المسبق لخمسة تدفقات لخدمة UGS
إذا قمت بإضافة تدفقات خدمة UGS إضافية، فعليك ملء كل عرض النطاق الترددي المتاح للتدفق.
الشكل 9 - تستهلك تدفقات خدمة UGS جميع عرض النطاق الترددي المتاح للتدفق
من الواضح أن المجدول لا يمكنه قبول أي تدفقات أخرى لخدمة UGS هنا. لذلك إذا حاول تدفق خدمة UGS آخر أن يصبح نشطا، فإن المجدول المتوافق مع DOCSIS يدرك أنه لا يوجد مجال لمزيد من المنح، ويمنع إنشاء تدفق الخدمة هذا.
ملاحظة: من المستحيل ملء أي تدفق من خدمات UGS بشكل كامل عند أعلى الخادم كما هو موضح في هذه السلسلة من الأرقام. يحتاج المجدول إلى إستيعاب الأنواع المهمة الأخرى لحركة المرور، على سبيل المثال، رسائل تنشيط صيانة المحطة وحركة مرور بيانات أفضل الجهود. كما أن الضمان لتجنب الاكتتاب الزائد مع المجدول المتوافق مع DOCSIS يطبق فقط إذا كانت جميع أوضاع جدولة تدفق الخدمة، أي UGS و RTPS و nRTPS، تستخدم المجدول المتوافق مع DOCSIS.
على الرغم من أن تكوين التحكم في الإدخال الصريح غير ضروري عند إستخدام المجدول المتوافق مع DOCSIS، إلا أن Cisco توصيك بضمان عدم إرتفاع إستخدام قناة الخادم إلى مستويات يمكن أن تؤثر سلبا على حركة مرور أفضل جهد. توصي Cisco أيضا بألا يتجاوز إجمالي إستخدام قناة الخادم 75٪ لفترات زمنية كبيرة. هذا هو مستوى إستخدام الخادم حيث تبدأ خدمات أفضل المجهودات في تجربة زمن وصول أعلى بكثير ومعدل إخراج أبطأ. لا تزال خدمات UGS تعمل، بغض النظر عن إستخدام الخادم.
إذا كنت ترغب في الحد من كمية حركة المرور التي تم إدخالها على تدفق تدفق تدفق البيانات إلى الخادم معين، فقم بتكوين التحكم في الدخول لكل من UGS أو RTPS أو NRTPS أو UGS-AD أو أفضل الجهود التي يتم إجراؤها باستخدام الأمر global، لكل واجهة كبل أو لكل أمر من أوامر تدفق البيانات. المعلمة الأكثر أهمية هي حقل الحد الحصري للنسبة المئوية.
cable [upstream upstream-number] admission-control us-bandwidth scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent major major-threshold-percent exclusive exclusive-threshold-percent [non-exclusive non-excl-threshold-percent]
هنا المعاملات:
[upstream <number>]: حدد هذه المعلمة إذا كنت تريد تطبيق الأمر على تدفق معين بدلا من واجهة كبل أو بشكل عام.
<UGS|AD-UGS|RTPS|NRTPS|BE>: تحدد هذه المعلمة وضع جدولة تدفقات الخدمة التي تريد تطبيق التحكم في الدخول عليها.
<minor-threshold-percent>: تشير هذه المعلمة إلى النسبة المئوية لاستخدام الخادم حسب نوع الجدولة الذي تم تكوينه والذي يتم عنده إرسال تنبيه ثانوي إلى محطة إدارة الشبكة.
<major-threshold-percent>: تحدد هذه المعلمة النسبة المئوية لاستخدام الخادم حسب نوع الجدولة التي تم تكوينها والتي يتم فيها إرسال تنبيه رئيسي إلى محطة إدارة الشبكة. يجب أن تكون هذه القيمة أعلى من القيمة التي قمت بتعيينها للمعلمة <minor-threshold-percent>.
<exclusive-threshold-percent>: تمثل هذه المعلمة النسبة المئوية لاستخدام الخادم محجوزة بشكل حصري لنوع الجدولة المحدد. إذا لم تحدد قيمة <non-excl-threshold-percent>، تمثل هذه القيمة الحد الأقصى للاستخدام لهذا النوع من تدفق الخدمة. يجب أن تكون هذه القيمة أكبر من قيمة <main-threshold-percent>.
<non-excl-threshold-percent>: تمثل هذه المعلمة النسبة المئوية لاستخدام الخادم أعلى من <exclusive-threshold-percent> الذي يمكن أن يستخدمه نوع الجدولة هذا، طالما أن نوع جدولة آخر لا يستخدمه بالفعل.
على سبيل المثال، افترض أنك تريد الحد من تدفقات خدمة UGS إلى 60٪ من إجمالي عرض النطاق الترددي المتاح عند أعلى الخادم. أيضا، افترض أن لديك محطات إدارة الشبكة قد أخطرت أنه إذا إرتفعت نسبة إستخدام الخادم بسبب تدفقات خدمة UGS أكثر من 40٪، فيجب إرسال تنبيه صغير وأكثر من 50٪، فيجب إرسال تنبيه رئيسي. قم بإصدار هذا الأمر:
التحكم بإذن الدخول إلى الكبل Us-Bandwidth نوع جدولة UGS Minor 40 Major 50 Exclusive 60
تقوم أداة الجدولة المتوافقة مع DOCSIS ببساطة بجدولة حركة مرور أفضل الجهود حول منح UGS أو RTPS المخصصة مسبقا. وتبرهن الأرقام الواردة في هذا القسم على هذا السلوك.
الشكل 10 - منح أفضل الجهود في انتظار الجدولة
يوضح الشكل 10 أن الخادم به ثلاث تدفقات خدمة UGS بنفس حجم المنحة وفترة المنحة المجدولة مسبقا. يستقبل تدفق الخدمة A طلبات عرض النطاق الترددي نيابة عن ثلاث تدفقات خدمة منفصلة. يتطلب تدفق الخدمة A وقتا متوسطا للإرسال، كما يتطلب تدفق الخدمة B قدرا صغيرا من وقت الإرسال ويتطلب تدفق الخدمة C مقدارا كبيرا من وقت الإرسال.
منح أولوية متساوية لكل من تدفقات خدمة أفضل الجهود. كما افترض أن CMTS تتلقى طلبات عرض النطاق لكل من هذه المنح بالترتيب A ثم B، ثم C. تقوم CMTS أولا بتخصيص وقت الإرسال للمنح بنفس الترتيب. الشكل 11 يوضح كيفية تخصيص أداة الجدولة المتوافقة مع DOCSIS لهذه المنح.
الشكل 11 - منح أفضل الجهود المجدولة حول منح تدفق خدمات UGS الثابتة
وبوسع المجدول أن يقلص المنح المقدمة لكل من ألف وباء معا في الفجوة بين القسمين الأولين من منح UGS. بيد أن المنحة بالنسبة للفئة جيم أكبر من أي فجوة متاحة. وبالتالي، يقوم المجدول المتوافق مع DOCSIS بتقسيم المنحة الخاصة ب C حول الكتلة الثالثة من منح UGS إلى منحتين صغيرتين تسمى C1 و C2. يمنع التجزئة التأخيرات في منح UGS، ويضمن أن هذه المنح لا تخضع للتشويش الذي تتسبب فيه حركة مرور أفضل الجهود.
يزيد التجزئة قليلا من حمل بروتوكول DOCSIS المرتبط بإرسال البيانات. لكل جزء إضافي تم إرساله، يجب أيضا إرسال مجموعة إضافية من رؤوس DOCSIS. ومع ذلك، فبدون تجزئة، لا يمكن أن تقوم أداة الجدولة بربط منح أفضل الجهود بكفاءة بين منح UGS الثابتة. لا يمكن حدوث التجزئة لأجهزة مودم الكبلات التي تعمل في وضع DOCSIS 1.0.
يضع المجدول المتوافق مع DOCSIS المنح التي تنتظر التخصيص في قوائم انتظار استنادا إلى أولوية تدفق الخدمة التي تنتمي إليها المنحة. هناك ثماني أولويات DOCSIS تكون أقل كل منها بصفر وأعلى سبع أولويات. تحتوي كل واحدة من هذه الأولويات على قائمة انتظار مقترنة.
تستخدم أداة الجدولة المتوافقة مع DOCSIS آلية صارمة لتحديد أولوية قوائم الانتظار لتحديد متى يتم تخصيص وقت إرسال منح الأولوية المختلفة. بعبارة أخرى، يجب تقديم كافة المنح المخزنة في قوائم الانتظار ذات الأولوية العالية قبل المنح في قوائم الانتظار ذات الأولوية المنخفضة.
على سبيل المثال، لنفترض أن المجدول المتوافق مع DOCSIS يتلقى خمس منح في فترة قصيرة في الترتيب A و B و C و D و E و F. يقوم المجدول بوضع كل منح لأعلى في قائمة الانتظار تتوافق مع أولوية تدفق الخدمة للمنحة.
الشكل 12 - المنح ذات الأولويات المختلفة
تقوم أداة الجدولة المتوافقة مع DOCSIS بجدولة منح أفضل الجهود حول منح UGS المجدولة مسبقا والتي تظهر ككتل منمطة في الشكل 12. يتمثل الإجراء الأول الذي تقوم به أداة الجدولة المتوافقة مع DOCSIS في التحقق من قائمة الانتظار ذات الأولوية العليا. في هذه الحالة، تحتوي قائمة انتظار الأولوية 7 على منح جاهزة للجدولة. يمضي المجدول قدما ويخصص وقت الإرسال للمنحتين باء وهاء. إخطار بأن المنحة E تحتاج إلى تجزئة حتى لا تتعارض المنحة مع توقيت منح UGS المخصصة مسبقا.
الشكل 13 - جدولة منح الأولوية 7
يتأكد المجدول من تلقي كافة منح الأولوية 7 وقت الإرسال. ثم يتحقق المجدول من قائمة الانتظار ذات الأولوية 6. في هذه الحالة، تكون قائمة الانتظار ذات الأولوية 6 فارغة، وبالتالي ينتقل المجدول إلى قائمة الانتظار ذات الأولوية 5 التي تحتوي على المنحة C.
الشكل 14 - جدولة المنح ذات الأولوية 5
ثم يستمر المجدول بطريقة مماثلة من خلال قوائم الانتظار ذات الأولوية الأدنى حتى تصبح جميع قوائم الانتظار فارغة. إذا كان هناك عدد كبير من المنح المطلوب جدولتها، يمكن لطلبات النطاق الترددي الجديدة الوصول إلى CMTS قبل أن ينهي برنامج الجدولة المتوافقة مع DOCSIS تخصيص وقت الإرسال لجميع المنح المعلقة. بافتراض أن CMTS يستلم طلب نطاق ترددي g من الأولوية 6 عند هذه النقطة في المثال.
الشكل 15 - قائمة الانتظار لمنح الأولوية 6
على الرغم من أنه يمنح A و F و D انتظار أطول من المنحة G الموضوعة في قائمة الانتظار مؤخرا، إلا أن المجدول المتوافق مع DOCSIS يجب أن يقوم بعد ذلك بتخصيص وقت الإرسال إلى G لأن G لديه الأولوية الأعلى. هذا يعني أن عمليات تخصيص النطاق الترددي التالية للجدول المتوافق مع DOCSIS ستكون G، A ثم D (راجع الشكل 16).
الشكل 16 - جدولة منح الأولوية 6 والأولوية 2
المنحة التالية التي سيتم جدولتها هي F، إذا افترضت أنه لا توجد منح أولوية أعلى تدخل نظام قوائم الانتظار في الوقت المتوسط.
تحتوي أداة الجدولة المتوافقة مع DOCSIS على قائمتين إضافيتين لم يتم ذكرهما في الأمثلة. قائمة الانتظار الأولى هي قائمة الانتظار المستخدمة لجدولة حركة مرور رسائل تنشيط الصيانة الدورية للمحطة لإبقاء أجهزة مودم الكبلات عبر الإنترنت. يتم إستخدام قائمة الانتظار هذه لجدولة فرص أجهزة مودم الكبلات لإرسال حركة مرور رسائل تنشيط CMTS الدورية. عندما يكون المجدول المتوافق مع DOCSIS نشطا، تتم خدمة قائمة الانتظار هذه أولا قبل جميع قوائم الانتظار الأخرى. الثانية هي قائمة انتظار للمنح المخصصة لتدفقات الخدمات مع تحديد الحد الأدنى للمعدل المحجوز (CIR). يتعامل المجدول مع قائمة انتظار CIR هذه كقائمة انتظار ذات أولوية 8 لضمان أن تدفقات الخدمة بمعدل محدد تتلقى الحد الأدنى من الإنتاج المطلوب.
ومن الأمثلة الواردة في الفرع السابق، يلزم في بعض الأحيان تقسيم المنح إلى أجزاء متعددة لضمان عدم استحثاث الرجفان في منح UGS المخصصة مسبقا. يمكن أن تكون هذه مشكلة لأجهزة مودم الكبلات التي تعمل في وضع DOCSIS 1.0 على مقاطع الخادم التي تحتوي على مقدار كبير من حركة مرور UGS، نظرا لأنه يمكن لمودم كبل DOCSIS 1.0 أن يطلب إرسال إطار أكبر من أن يمكن احتواؤه في فرصة الإرسال التالية المتاحة.
هنا مثال آخر، يفترض أن المجدول يتلقى المنح الجديدة A و B بهذا الترتيب. كما يمكنك افتراض أن كلا المنح لها نفس الأولوية ولكن المنحة B هي لمودم كبل يعمل في وضع DOCSIS 1.0.
الشكل 17 - منح DOCSIS 1.1 و DOCSIS 1.0 المعلقة
يحاول المجدول تخصيص الوقت للمنح A أولا. ثم يحاول المجدول تخصيص فرصة الإرسال التالية المتاحة لمنح B. ومع ذلك، لا يوجد مجال لأن تظل المنحة B غير مجزأة بين المجموعة A والجزء التالي من منح UGS (انظر الشكل 18).
الشكل 18 - منحة DOCSIS 1.0 B مؤجلة
ولهذا السبب، يتأخر تقديم المنحة باء إلى ما بعد الجزء الثاني من منح UGS حيث يكون هناك مجال للمنحة باء. لاحظ أنه توجد الآن مساحة غير مستخدمة قبل الكتلة الثانية من منح UGS. تستخدم أجهزة مودم الكبلات هذه المرة لنقل طلبات النطاق الترددي إلى CMTS، ولكن هذا يمثل إستخداما غير فعال للنطاق الترددي.
قم بإعادة زيارة هذا المثال وإضافة تدفقات خدمة UGS إضافية إلى المجدول. في حين يمكن تجزئة المنحة A، لا توجد فرصة لجدولة المنحة B غير القابلة للتجزئة لأن المنحة B كبيرة جدا بحيث لا يمكن احتواؤها بين كتل منح UGS. يترك هذا الحالة مودم الكبل المرتبط بالمنحة ب غير قادر على إرسال إطارات كبيرة في المنبع.
الشكل 19 - لا يمكن جدولة منحة DOCSIS 1.0 B
يمكنك السماح للمصمم المجدول ببساطة بإلغاء مجموعة منح UGS أو تأخيرها قليلا لإفساح المجال للمنحة B ولكن هذا الإجراء يؤدي إلى حدوث إرتباك في تدفق خدمة UGS. أما الآن، فإذا افترضت أنك تريد أن تقلل من حدة التوتر إلى أدنى حد ممكن، فهذا حل غير مقبول.
من أجل التغلب على هذه المشكلة باستخدام منح DOCSIS 1.0 كبيرة غير قابلة للتجزئة، يقوم برنامج الجدولة الزمنية المتوافق مع DOCSIS بالجدولة الدورية لقطع وقت البث بحجم أكبر إطار يمكن لمودم كبل DOCSIS 1.0 أن ينقله. يقوم المجدول بذلك قبل جدولة أي تدفقات لخدمة UGS. وهذا الوقت يعادل عادة نحو 2000 بايت من الإرسال عند الخادم، ويطلق عليه "الكتلة غير القابلة للتجزئة" أو "الكتلة الحرة UGS".
لا تقوم أداة الجدولة المتوافقة مع DOCSIS بوضع أي منح لنمط UGS أو RTPS في الأوقات المخصصة لحركة المرور غير القابلة للتجزئة لضمان وجود فرصة دائما لبرمجة منح DOCSIS 1.0 الكبيرة. في هذا النظام، يؤدي حجز الوقت لحركة مرور DOCSIS 1.0 غير القابلة للتجزئة إلى تقليل عدد تدفقات خدمة UGS التي يمكن أن يدعمها الخادم في نفس الوقت.
يوضح الشكل 20 الكتلة غير القابلة للتجزئة في اللون الأزرق وتدفق خدمة UGS الأربعة بنفس حجم المنحة وفترة المنحة. لا يمكنك إضافة تدفق خدمة UGS آخر من نفس حجم المنحة وفترات المنحة إلى هذا الخادم لأنه غير مسموح بجدولة منح UGS في منطقة الكتلة الزرقاء غير القابلة للتجزئة.
الشكل 20 - الكتلة القابلة للتجزئة: لا يمكن قبول منح إضافية من UGS
وعلى الرغم من أن الكتلة غير القابلة للتجزئة تتم جدولتها في كثير من الأحيان أقل من الفترة التي تمنح فيها UGS، إلا أن هذه الكتلة تميل إلى التسبب في وجود مساحة عرض نطاق ترددي غير مخصص أكبر من حجمها بين جميع كتل منح UGS. وهذا يوفر فرصة وفيرة لجدولة منح كبيرة غير قابلة للتجزئة.
ارجع إلى مثال المنحة A و DOCSIS 1.0 المنحة B، ويمكنك أن ترى أنه مع وجود الكتلة التي لا يمكن تجزئتها، يستطيع المجدول المتوافق مع DOCSIS الآن جدولة المنحة B بنجاح بعد الكتلة الأولى من منح UGS.
الشكل 21 - منح الجدولة باستخدام الكتلة غير القابلة للتجزئة
على الرغم من جدولة المنحة B ل DOCSIS 1.0 بنجاح، لا تزال هناك فجوة صغيرة في المساحة غير المستخدمة بين المنحة A والكتلة الأولى من منح UGS. تمثل هذه الفجوة إستخداما أقل من الأمثل للنطاق الترددي، كما توضح لماذا يجب عليك إستخدام أجهزة مودم كبل وضع DOCSIS 1.1 عند نشر خدمات UGS.
بشكل افتراضي على Cisco uBR CMTS، يكون أكبر انفجار يمكن لمودم الكبل إرساله هو 2000 بايت. يتم إستخدام هذه القيمة لأكبر حجم تدفق من الخادم لحساب حجم الكتلة غير القابلة للتجزئة كما هو الحال مع إستخدام المجدول المتوافق مع DOCSIS.
يمكنك تغيير أكبر حجم تدفق باستخدام أمر واجهة الكبل default-phy-burst max-bytes-allowed-in-burst .
تحتوي المعلمة <max-bytes-allowed-in-burst> على نطاق يتراوح من 0 إلى 4096 بايت وقيمة افتراضية تبلغ 2000 بايت. هناك بعض القيود المهمة على كيفية تعيين هذه القيمة إذا كنت تريد تغيير القيمة من القيمة الافتراضية.
بالنسبة لواجهات الكبلات على بطاقة الخط MC5x20S، لا تقم بتعيين هذه المعلمة فوق الإعداد الافتراضي البالغ 2000 بايت. بالنسبة لكافة أنواع بطاقات الخط الأخرى، بما في ذلك بطاقات الخط MC28U و MC5x20U و MC5x20H، يمكنك تعيين هذه المعلمة على أنها ذات 4000 بايت.
لا تقم بتعيين المعلمة <max-bytes-allowed-in-burst> أقل من حجم أكبر إطار إيثرنت مفرد يمكن أن يحتاج مودم الكبل إلى نقله، بما في ذلك DOCSIS أو المصروفات العامة ل 802.1q. وهذا يعني أن هذه القيمة يجب ألا تقل عن 1540 بايت تقريبا.
إذا قمت بضبط <max-bytes-allowed-in-burst> على القيمة الخاصة 0، فإن CMTS لا يستخدم هذه المعلمة لتقييد حجم تدفق تدفق تدفق الخادم. تحتاج إلى تكوين متغيرات أخرى لتقييد حجم اندفاع الخادم إلى حد معقول، مثل إعداد الاندفاع التفصيلي الأقصى في ملف تكوين DOCSIS، أو الأمر cable upstream fragment-force.
عند تعديل اندفاع الكبل الافتراضي لتغيير الحد الأقصى لحجم اندفاع الخادم، يتم أيضا تعديل حجم الكتلة الحرة UGS وفقا لذلك. يوضح الشكل 22 أنه إذا قمت بتقليل إعداد اندفاع الكبل الافتراضي، فإن حجم كتلة UGS الحرة يقلل، وبالتالي يمكن أن يسمح المجدول المتوافق مع DOCSIS بالمزيد من مكالمات UGS على الخادم. في هذا المثال، قم بتقليل الاندفاع الافتراضي للكابل من الإعداد الافتراضي لعام 2000 إلى إعداد أقل من 1600 للسماح بمساحة لتدفق خدمة UGS واحد إضافي ليصبح نشطا.
الشكل 22 - يؤدي انخفاض اندفاع القيمة الافتراضية إلى تقليل حجم الكتلة القابلة للتجزئة
يمكن أن يؤدي تقليل الحد الأقصى لحجم الاندفاع المسموح به باستخدام الأمر cable default-phy-burst إلى تقليل كفاءة تدفق بيانات أعلى أفضل الجهود بشكل طفيف، لأن هذا الأمر يقلل عدد الإطارات التي يمكن ترسيمها ضمن اندفاع واحد. ويمكن أن يؤدي هذا الانخفاض أيضا إلى زيادة مستويات التجزئة عندما يكون للتدفق الأولي عدد أكبر من تدفقات خدمة UGS النشطة.
يمكن أن تؤثر أحجام الاندفاع الصغيرة المضغوطة على سرعة تحميل البيانات في تدفق خدمة أفضل الجهود. وذلك لأن إرسال إطارات متعددة في وقت واحد يكون أسرع من إرسال طلب عرض نطاق لكل إطار. كما يمكن أن تؤثر مستويات التوافق المنخفضة على سرعة التنزيلات بسبب القدرة المتضائلة لمودم الكبل على تجميع أعداد كبيرة من حزم TCP ACK التي تنتقل في إتجاه البث.
وفي بعض الأحيان، يمكن للحد الأقصى لحجم الاندفاع كما تم تكوينه في وحدة التحكم في الوصول للبنية الأساسية (IUC) "الطويلة" الخاصة بملف تعريف تعديل الكبل الذي يتم تطبيقه على أحد عمليات الخادم، تحديد أكبر حجم اندفاع عند الخادم. يمكن أن يحدث ذلك إذا كان الحد الأقصى لحجم الاندفاع في ملف تعريف التعديل أقل من قيمة كبل default-phy-burst بالبايت. هذا سيناريو نادر. ومع ذلك، إذا قمت بزيادة المعلمة default-phy-burst للكابل من الإعداد الافتراضي البالغ 2000 بايت، فتحقق من الحد الأقصى لحجم الاندفاع في تكوين IUC "long" لضمان عدم الحد من الاندفاع.
القيد الآخر على حجم اندفاع المنبع هو أن 255 قطعة صغيرة كحد أقصى يمكن إرسالها في دفعة واحدة. يمكن أن يصبح هذا عاملا إذا تم تعيين حجم قطعة الصغر على الحد الأدنى 8 بايت. وحدة صغيرة هي أصغر وحدة إرسال من الخادم في شبكة DOCSIS وعادة ما تكون مساوية ل 8 أو 16 بايت.
هناك طريقة أخرى لضبط المجدول المتوافق مع DOCSIS من أجل السماح بعدد أكبر من تدفقات UGS المتزامنة على الخادم هي السماح للجدول بالسماح للدفعات الكبيرة من حركة مرور أفضل الجهود غير القابلة للتجزئة بتقديم كميات صغيرة من الرجفان إلى تدفقات خدمة UGS. يمكنك القيام بذلك باستخدام أمر واجهة الكبل cable upstream upstream-number unfrag-slot-jitter limit val.
في هذا الأمر، يتم تحديد <val> في الميكروثوان ولديه قيمة افتراضية مقدارها صفر، مما يعني أن السلوك الافتراضي لمخطط الجدولة المتوافق مع DOCSIS هو عدم السماح للمنح غير القابلة للتجزئة بإحداث رجفان لتدفقات خدمة UGS و RTPS. عند تحديد رجفان فتحة غير مجزأ موجب، يمكن أن يقوم المجدول المتوافق مع DOCSIS بتأخير منح UGS بما يصل إلى <val> ميكروثانية من الوقت الذي يجب فيه جدولة منحة UGS بشكل مثالي، وبالتالي التسبب في الرجفان.
وهذا له نفس تأثير تقليل حجم الكتلة غير القابل للتجزئة بمقدار مكافئ لعدد المايكروثانية المحددة. على سبيل المثال، إذا قمت بالاحتفاظ بالقيمة الافتراضية لبروتوكول PHY-Burst (2000 بايت) وإذا قمت بتحديد قيمة مقدارها 1000 ميكروثانية لرجفان الفتحات غير القابل للتجزئة، فإن الكتلة غير القابلة للتجزئة تقلل (راجع الشكل 23).
الشكل 23 - يقوم رجفان الفتحات غير القابلة للتجزئة غير صفري بخفض حجم الكتلة القابلة للتجزئة
ملاحظة: يعتمد عدد وحدات البايت التي يتوافق معها الوقت 1000-MicroSecond على مدى سرعة تكوين قناة الخادم لتعمل من خلال إعدادات مخطط التعديل وعرض القناة.
ملاحظة: باستخدام رجفان الفتحات غير الصفري القابل للتجزئة، يمكن أن تزيد أداة الجدولة المتوافقة مع DOCSIS عدد منح UGS التي يدعمها الخادم بطريقة مشابهة لامتلاك اندفاع افتراضي منخفض في الطبقة العليا.
ملاحظة: ارجع إلى المثال باستخدام منحة DOCSIS 1.1 كبيرة (أ) متبوعة بمنحة DOCSIS 1.0 كبيرة غير قابلة للتجزئة (ب) للجدولة على أحد عمليات الخادم. تقوم بضبط رجفان الفتحات غير القابل للتجزئة إلى 1000 ميكرو ثانية. يتصرف المجدول المتوافق مع DOCSIS كما هو موضح في الأشكال الموجودة في هذا القسم.
ملاحظة: أولا، يخصص المجدول وقت الإرسال للمنحة ألف. وللقيام بذلك، يقوم المجدول بتقسيم المنحة إلى المنح ألف1 وألف2 بحيث تلائم المنح قبل وبعد المجموعة الأولى من منح UGS. من أجل جدولة المنحة B، يجب أن يقرر المجدول ما إذا كان باستطاعة المجدول إحتواء الكتلة غير القابلة للتجزئة في المساحة الحرة بعد منح A2 بدون تأخير إلى الكتلة التالية من منح UGS بأكثر من رجفان الفتحات غير القابل للتجزئة المكون من 1000 ميكرو ثانية. وتبين هذه الأرقام أنه إذا قام المجدول بوضع المنحة (ب) بعد منح A2، فإن الكتلة التالية من حركة مرور UGS تتأخر، أو تتراجع، بأكثر من 1500 ميكرو ثانية. وبالتالي لا يمكن للمجدول وضع المنحة B مباشرة بعد المنحة A2.
الشكل 24 - يتعذر جدولة المنحة باء بعد المنح A2.
تتمثل الخطوة التالية لجدول التوافق مع DOCSIS في معرفة ما إذا كانت الفجوة التالية المتاحة يمكن أن تتسع للمنحة B. يوضح الشكل 25 أنه إذا قام المجدول بوضع المنحة B بعد الكتلة الثانية من منح UGS، فلن يتم تأخير الكتلة الثالثة بأكثر من رجفان الفتحات غير القابلة للتجزئة المكونين وقدره 1000 ميكروثانية.
الشكل 25 - المنحة باء المجدولة بعد الجزء الثاني من منح UGS
مع العلم بأن إدراج المنحة B في هذه المرحلة لا يسبب تشويشا غير مقبول لمنحة UGS، يدرج المجدول المتوافق مع DOCSIS المنحة B ويتأخر قليلا المجموعة التالية من منح UGS.
الشكل 26 - جدولة المنحة غير القابلة للتجزئة باء وتأخر منح UGS
يمكنك إستخدام الأمر show interface-number mac-scheduler upStream-number لقياس الحالة الحالية للمصفوفة المتوافقة مع DOCSIS. هنا مثال من الإنتاج من هذا أمر كما يرى على cisco uBR7200VXR مع بطاقة خط MC28U.
uBR7200VXR# show interface cable 3/0 mac-scheduler 0 DOCSIS 1.1 MAC scheduler for Cable3/0/U0 Queue[Rng Polls] 0/128, 0 drops, max 1 Queue[CIR Grants] 0/64, 0 drops, max 0 Queue[BE(7) Grants] 1/64, 0 drops, max 2 Queue[BE(6) Grants] 0/64, 0 drops, max 0 Queue[BE(5) Grants] 0/64, 0 drops, max 0 Queue[BE(4) Grants] 0/64, 0 drops, max 0 Queue[BE(3) Grants] 0/64, 0 drops, max 0 Queue[BE(2) Grants] 0/64, 0 drops, max 0 Queue[BE(1) Grants] 0/64, 0 drops, max 0 Queue[BE(0) Grants] 1/64, 0 drops, max 1 Req Slots 36356057, Req/Data Slots 185165 Init Mtn Slots 514263, Stn Mtn Slots 314793 Short Grant Slots 12256, Long Grant Slots 4691 ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0 ATDMA UGS Grant Slots 0 Awacs Slots 277629 Fragmentation count 41 Fragmentation test disabled Avg upstream channel utilization : 26% Avg percent contention slots : 73% Avg percent initial ranging slots : 2% Avg percent minislots lost on late MAPs : 0% Sched Table Rsv-state: Grants 0, Reqpolls 0 Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27% UGS : 6 SIDs, Reservation-level in bps 556800 UGS-AD : 0 SIDs, Reservation-level in bps 0 RTPS : 0 SIDs, Reservation-level in bps 0 NRTPS : 0 SIDs, Reservation-level in bps 0 BE : 35 SIDs, Reservation-level in bps 0 RTPS : 0 SIDs, Reservation-level in bps 0 NRTPS : 0 SIDs, Reservation-level in bps 0 BE : 0 SIDs, Reservation-level in bps 0
يشرح هذا القسم كل سطر من مخرجات هذا الأمر. لاحظ أن هذا القسم من المستند يفترض أنك على دراية تامة بمفاهيم جدولة DOCSIS العامة للتدفق.
مجدول DOCSIS 1.1 MAC للكابل 3/0/U0
يشير السطر الأول من إخراج الأمر إلى منفذ الخادم الذي تتعلق به البيانات.
قائمة الانتظار [إستطلاعات RNG] 0/128، 0 إنخفاضات، 1 كحد أقصى
يوضح هذا السطر حالة قائمة الانتظار التي تقدم رسائل keepalive لصيانة المحطة أو فرص النطاق في المجدول المتوافق مع DOCSIS. يشير 0/128 إلى وجود صفر حاليا من 128 فرصة نطاق معلقة كحد أقصى في قائمة الانتظار.
يشير عداد عمليات الإسقاط إلى عدد المرات التي تعذر فيها وضع فرصة تحديد المدى في قائمة الانتظار لأن قائمة الانتظار هذه ممتلئة بالفعل (أي 128 فرصة تحديد نطاق معلقة). من المحتمل أن تحدث عمليات السقوط هنا فقط على الخادم مع وجود عدد كبير للغاية من أجهزة مودم الكبلات عبر الإنترنت وإذا كان هناك عدد كبير من عمليات تدفق خدمات UGS أو RTPS نشطة. تتم خدمة قائمة الانتظار هذه بأعلى أولوية عند تشغيل مجدول شكاوى DOCSIS. لذلك، فإن حالات السقوط في قائمة الانتظار هذه غير مرجحة إلى حد كبير، ولكن من المرجح أن تشير إلى تجاوز خطير في الاشتراك في قناة المنبع.
يشير العداد الأقصى إلى الحد الأقصى لعدد العناصر الموجودة وفي قائمة الانتظار هذه منذ آخر تشغيل للأمر show interface cable mac-scheduler. ومن الناحية المثالية، ينبغي أن يظل ذلك قريبا من الصفر قدر الإمكان.
قائمة الانتظار [منح CIR] 0/64، 0 عمليات إسقاط، الحد الأقصى 0
يظهر هذا البند حالة قائمة الانتظار التي تدير منح تدفقات الخدمة مع تحديد الحد الأدنى لمعدل حركة المرور المحجوزة. بمعنى آخر، تمنح خدمات قائمة الانتظار هذه تدفقات خدمة معدل المعلومات الملتزم بها (CIR). يشير 0/64 إلى وجود صفر حاليا من أصل 64 منحة معلقة كحد أقصى في قائمة الانتظار.
يشير عداد عمليات الإسقاط إلى عدد المرات التي تعذر فيها وضع منحة CIR في قائمة الانتظار بسبب امتلاء قائمة الانتظار هذه بالفعل (أي 64 منحة في قائمة الانتظار). يمكن أن تتراكم حالات السقوط هنا إذا تجاوزت تدفقات خدمة UGS و RTPS و CIR النمط الاشتراك في عملية التشغيل، كما يمكن أن تشير إلى الحاجة إلى تحكم أكثر صرامة في الدخول.
يشير العداد الأقصى إلى الحد الأقصى لعدد المنح في قائمة الانتظار هذه منذ آخر تشغيل للأمر show interface cable mac-scheduler. تحتوي قائمة الانتظار هذه على ثاني أعلى أولوية، لذا فإن أداة الجدولة المتوافقة مع DOCSIS تقوم بتخصيص الوقت لعناصر قائمة الانتظار هذه قبل أن يقوم المجدول بخدمة أفضل قوائم انتظار الجهد.
قائمة الانتظار [BE(w) منح] x/64، حالات السقوط y، الحد الأقصى ل z
تظهر الإدخالات الثمانية التالية حالة قوائم الانتظار التي تدير منح الأولوية من 7 إلى 0 تدفقات خدمة. الحقول الموجودة في تلك المدخلات لها نفس المعنى مثل الحقول الموجودة في إدخال قائمة انتظار CIR. تكون قائمة الانتظار الأولى التي سيتم تقديمها في هذه المجموعة هي قائمة الانتظار BE (7)، بينما تكون قائمة الانتظار BE (0) هي آخر قائمة يتم تقديمها.
يمكن أن تحدث عمليات الإسقاط في قوائم الانتظار هذه إذا استهلك مستوى أولوية أعلى لحركة المرور كل عرض النطاق الترددي للتدفق من الخادم أو إذا حدث تجاوز مستوى الاشتراك في عمليات تدفق خدمة نمط UGS و RTPS و CIR. قد يشير ذلك إلى الحاجة إلى إعادة تقييم أولويات DOCSIS لتدفقات الخدمات كبيرة الحجم أو الحاجة إلى تحكم أكثر صرامة في الدخول إلى الخادم.
فتحات Req 36356057
يشير هذا البند إلى عدد فرص طلب النطاق الترددي التي تم الإعلان عنها منذ تنشيط البث. يجب أن يكون هذا الرقم في زيادة باستمرار.
Req/فتحات البيانات 185165
على الرغم من أن الاسم يقترح أن هذا الحقل يوضح عدد فرص البيانات أو الطلب المعلن عنها على الخادم، فإن هذا الحقل يوضح بالفعل عدد الفترات التي أعلن عنها CMTS لتسهيل وظيفة إدارة الطيف المتقدمة. من المتوقع أن يتزايد هذا العداد للتحديثات على بطاقات الخط ذات النمط MC28U و MC520.
تكون فرص الطلب/البيانات هي نفسها فرص طلب النطاق الترددي باستثناء أن أجهزة مودم الكبلات قادرة أيضا على إرسال دفعات صغيرة من البيانات في هذه الفترات. لا تقوم وحدات التحكم في الوصول للوسائط (CMTS) من السلسلة uBR من Cisco حاليا بجدولة فرص البيانات/الطلبات الحقيقية.
فتحات MTN الداخلية طراز 514263
يمثل هذا البند عدد فرص الصيانة الأولية التي تم الإعلان عنها منذ تنشيط الخادم. يجب أن يكون هذا الرقم في أزدياد باستمرار. تستخدم أجهزة مودم الكبلات التي تقوم بمحاولات أولية لإنشاء اتصال ب CMTS فرص الصيانة الأولية.
فتحات STN MTN 314793
يشير هذا السطر إلى عدد فرص صيانة المحطة أو نطاق الفرص المتاحة على الخادم. إذا كانت هناك أجهزة مودم كبلات على الإنترنت على الخادم، فيجب أن يكون هذا الرقم في إرتفاع باستمرار.
فتحات المنح القصيرة 12256، فتحات المنح الطويلة 4691
يشير هذا السطر إلى عدد منح البيانات المقدمة على الخادم. إن هناك كبل مودم أن يبث معطيات تدفق، هذا رقم ينبغي كنت باستمرار على إرتفاع.
فتحات المنح القصيرة ATDMA 0 وفتحات المنح الطويلة ATDMA 0 وفتحات المنح ATDMA UGS 0
يمثل هذا البند عدد منح البيانات المقدمة في وضع الوصول المتعدد لتقسيم الوقت المتقدم (ATDMA) على الخادم. إذا كانت هناك أجهزة مودم كبلات تعمل في وضع DOCSIS 2.0، وتنقل بيانات تدفق البيانات، فيجب أن تكون هذه الأرقام قيد الارتفاع باستمرار. لاحظ أن ATDMA يقوم بحساب حركة مرور UGS بشكل منفصل.
فتحات طائرات الأواكس طراز 277629
يوضح هذا البند عدد الفترات المخصصة للإدارة المتقدمة للطيف. لكي تحدث إدارة الطيف المتقدمة، يحتاج CMTS إلى جدولة الوقت دوريا حيث يجب أن يقوم كل مودم كبل بإرسال موجز حتى تتمكن وظيفة تحليل النطاق الداخلي من تقييم جودة الإشارة من كل مودم.
عدد التجزئة 41
يعرض هذا السطر العدد الإجمالي للأجزاء التي تمت جدولة منفذ الخادم لاستقبالها. على سبيل المثال، الإطار الذي تم تجزئته إلى ثلاثة أجزاء سيؤدي إلى زيادة هذا العداد بمقدار ثلاثة.
تم تعطيل إختبار التجزئة
يشير هذا السطر إلى أنه لم يتم إستدعاء أمر إختبار تجزئة كبل. لا تستخدم هذا الأمر في شبكة إنتاج.
متوسط إستخدام قناة الخادم: 26٪
يوضح هذا السطر إستخدام قناة الخادم الحالية عن طريق عمليات إرسال بيانات الخادم. ويشمل ذلك عمليات الإرسال التي تتم من خلال منح ATDMA القصيرة والطويلة والقصيرة وطويلة الأجل ATDMA و ATDMA UGS. يتم حساب القيمة كل ثانية كمتوسط متداول. توصي Cisco بألا تتجاوز هذه القيمة 75٪ على أساس موسع أثناء أوقات ذروة الاستخدام. وإلا فيمكن للمستخدمين النهائيين البدء في ملاحظة مشكلات الأداء مع حركة مرور أفضل الجهود.
متوسط نسبة فتحات الاتصال: 73٪
يوضح هذا السطر النسبة المئوية لوقت تدفق البيانات المخصص لطلبات عرض النطاق الترددي. ويعادل ذلك مقدار الوقت الحر في الخادم، وبالتالي يقلل مع زيادة النسبة المئوية لاستخدام قناة AVG للتدفق.
متوسط النسبة المئوية لفتحات النطاق الأولية: 2٪
يشير هذا السطر إلى النسبة المئوية لوقت تدفق البيانات إلى الخادم المخصص لفرص النطاق الأولي التي تستخدمها أجهزة مودم الكبلات عند إجراء محاولات لإنشاء اتصال أولي مع CMTS. يجب أن تظل هذه القيمة دائما نسبة مئوية منخفضة من إجمالي الاستخدام.
متوسط النسبة المئوية لأراضي المهملات المفقودة على الخرائط المتأخرة: 0٪
يشير هذا السطر إلى النسبة المئوية لوقت البث الذي لم تتم جدولته لأن CMTS لم يتمكن من إرسال رسالة خريطة تخصيص عرض النطاق الترددي إلى أجهزة مودم الكبلات في الوقت المناسب. يجب أن تكون هذه المعلمة دائما قريبة من الصفر ولكن يمكن أن تبدأ في إظهار قيم أكبر على الأنظمة التي تحتوي على حمل مرتفع للغاية لوحدة المعالجة المركزية.
SCHED Table RSV-STATE: Grants 0، reqpolls 0
يوضح هذا البند عدد تدفقات خدمة نمط UGS (المنح) أو تدفقات خدمة نمط RTPS (ReqPoll) التي تم تخصيص منح لها مسبقا في المجدول المتوافق مع DOCSIS، ولكن لم يتم تنشيطها بعد. وهذا يحدث عند نقل مودم كبل باستخدام UGS أو RTPS الحالي الذي تتدفق الخدمة من واحد أعلى إلى آخر من خلال موازنة الأحمال. لاحظ أن هذا الشكل ينطبق فقط على المنح التي تستخدم "مجدول DOCSIS" المتوافق، وليس "مجدول LLQ".
SCHED Table ADM-State: المنح 6، ريكتس 0، 27 في المائة
يشير هذا السطر إلى عدد تدفقات خدمة نمط UGS (المنح) أو تدفقات خدمة نمط RTPS (ReqPoll) التي تم تخصيص منح لها مسبقا في المجدول المتوافق مع DOCSIS لهذا الخادم. يقصد ب Util الاستخدام المقدر لإجمالي عرض النطاق الترددي المتاح للتدفق من الخادم بواسطة تدفقات الخدمة هذه. لاحظ أن هذا الشكل ينطبق فقط على المنح التي تستخدم "مجدول DOCSIS" المتوافق، وليس "مجدول LLQ".
<نوع الجدولة>: x SIDs، مستوى الحجز في BPS y
يشير هذا البند إلى عدد تدفقات الخدمة أو SIDs <ScheduleType> الموجودة على الخادم، ومقدار النطاق الترددي في وحدات بت في الثانية الذي تم حجزه من تدفقات الخدمة هذه. بالنسبة إلى أفضل الجهود وتدفقات خدمة نمط RTPS، يتم حجز النطاق الترددي فقط إذا كان تدفق الخدمة يحتوي على الحد الأدنى للمعدل المحجوز الذي تم تكوينه.
يتمثل الهدف من أداة الجدولة المتوافقة مع DOCSIS في تقليل رجفان تدفقات خدمة نمط UGS و RTPS إلى الحد الأدنى، وكذلك إستيعاب دفقات DOCSIS 1.0 غير القابلة للتجزئة. تتمثل المقايضة التي تقوم بها أداة الجدولة المتوافقة مع DOCSIS من أجل تحقيق هذه الأهداف في أن الحد الأقصى لعدد تدفقات خدمة UGS المدعومة لكل دفق أقل من الحد الأقصى النظري الذي يمكن أن يدعمه تدفق DOCSIS ماديا، وأن حركة مرور أفضل الجهود يمكن أن تخضع إلى درجة من التجزئة.
بينما تدعم أداة الجدولة المتوافقة مع DOCSIS أقل بقليل من الحد الأقصى النظري لتدفق خدمة UGS المتزامنة على الخادم، وفي حين أن بعض عمليات تنفيذ الجدولة الأخرى يمكن أن تدعم المزيد من تدفقات خدمة UGS لكل تدفق، يجب عليك التركيز على المقايضة.
على سبيل المثال، لا يمكن لأي مجدول دعم تدفقات خدمة UGS التي لا تحتوي على علامات مرور والتي تستهلك ما يقرب من 100٪ من عرض النطاق الترددي لقناة تدفق بيانات أعلى وتدعم في الوقت نفسه الإطارات المجمعة الكبيرة غير القابلة للتجزئة من أجهزة مودم DOCSIS 1.0. فيما يتعلق بتصميم المجدول المتوافق مع DOCSIS، هناك نقطتان مهمتان يجب فهمهما.
75٪ هو الحد الأقصى المطلوب لاستخدام الخادم.
وجدت Cisco أنه عندما تعمل عملية تدفق البيانات بشكل متناسق بنسبة إستخدام تزيد عن 75٪، بما في ذلك الاستخدام بسبب تدفقات خدمة UGS، فإن أفضل أداء لحركة مرور الجهود يبدأ في التأثر بشكل ملحوظ. وهذا يعني أنه إذا استهلك إرسال إشارات UGS و VoIP أكثر من 75٪ من الخادم، فإن أي حركة مرور عادية لبروتوكول IP يتم نقلها بواسطة تدفقات خدمة أفضل الجهود تبدأ في المعاناة من زمن وصول إضافي يتسبب في انخفاض الإنتاجية وأوقات الاستجابة بشكل ملحوظ. ويعد انخفاض الأداء هذا عند مستويات إستخدام أعلى خاصية تشترك فيها معظم أنظمة الشبكات متعددة الوصول الحديثة، على سبيل المثال، شبكات إيثرنت أو الشبكات المحلية اللاسلكية.
عند إستخدام عرض قناة الخادم الذي يتم نشره بشكل نموذجي بسرعة 3.2 ميجاهرتز، يسمح المجدول المتوافق مع DOCSIS بتدفقات خدمة UGS باستخدام ما يصل إلى 75٪ من قناة الخادم. تنقل تدفقات الخدمة هذه مكالمات G.711 VoIP.
توفر هاتان النقطتان بعض المعلومات عن اعتبارات التصميم التي تم أخذها في الاعتبار عند إنشاء المجدول المتوافق مع DOCSIS. تم تصميم المجدول المتوافق مع DOCSIS بحيث بالنسبة لتدفقات خدمة UGS النموذجية (G.711) وبعرض القناة الأكثر انتشارا الذي يبلغ 3.2 ميجاهرتز، يبدأ تطبيق حدود الاستدعاء لكل تدفق حوالي علامة الاستخدام 75٪. وهذا يعني أن المجدول يعمل على تقليل الاهتزاز إلى الحد الأدنى بنجاح ويسمح أيضا بعدد معقول من تدفقات خدمة UGS في الخادم.
بمعنى آخر، تم تصميم المجدول المتوافق مع DOCSIS للعمل بشكل صحيح في شبكات DOCSIS للإنتاج، وعدم السماح لتدفقات خدمة UGS باستخدام نسبة عالية غير واقعية من عرض النطاق الترددي للتدفق. ويمكن أن يحدث هذا السيناريو في سيناريو مختبري مكتمل للاختبار.
يمكنك تعديل المجدول المتوافق مع DOCSIS لاستيعاب عدد متزايد من إستدعاءات UGS لكل تدفق، وإن كان ذلك على حساب رجفان UGS وكفاءة حركة مرور أفضل الجهود. لهذا، يجب عليك تقليل المعلمة default-phy-burst للكابل إلى الحد الأدنى للإعداد الموصى به وهو 1540 بايت. إذا كنت بحاجة إلى مزيد من كثافة الاستدعاء، فقم بتعيين رجفان Unfrag-slot-jitter للكابل أعلى الخادم إلى قيمة مثل 2000 ميكروثانية. ومع ذلك، لا توصي Cisco بهذه الإعدادات بشكل عام لشبكة إنتاج.
هناك ميزة أخرى في المجدول المتوافق مع DOCSIS وهي عدم وجود متطلب إلزامي يقوم مشغلو CMTS بتكوين التحكم في الدخول بشكل صريح ل UGS و RTPS تدفقات خدمة نمط. وذلك نظرا لأن طريقة جدولة التخصيص المسبق تزيل إمكانية الإفراط في الاشتراك العرضي. على الرغم من أن هذه هي الحالة التي لا تزال Cisco تقترح أن يضمن المشغلون ألا يتجاوز إجمالي إستخدام الخادم 75٪ لفترات ممتدة خلال ساعة الذروة. لذلك، توصي Cisco بتكوين التحكم في الدخول كأفضل ممارسة.
يتمثل أحد عيوب المجدول المتوافق مع DOCSIS في أن الوضع الثابت لمنح UGS يمكن أن يتطلب تجزئة منح أفضل الجهود عندما يكون إستخدام UGS مرتفعا. بشكل عام، لا تتسبب التجزئة في حدوث مشاكل ملحوظة في الأداء، ولكنها تؤدي إلى زيادة طفيفة في زمن الوصول لأفضل حركة مرور جهد وزيادة في مصروفات البروتوكول الموجودة على قناة المنبع.
تتمثل إحدى العيوب الأخرى في أنه عندما ترغب أجهزة مودم كبلات DOCSIS 1.0 في إجراء عمليات إرسال كبيرة غير قابلة للتجزئة إلى الخادم يمكن أن يكون هناك تأخير قبل ظهور فجوة مناسبة بين كتل منح UGS المجدولة مسبقا. كما يمكن أن يؤدي ذلك إلى زيادة زمن الوصول لحركة مرور بيانات تدفق بيانات DOCSIS 1.0 للتدفق والاستخدام الأقل من الأمثل لوقت الإرسال المتوفر للتدفق.
وأخيرا، تم تصميم مجدول DOCSIS المتوافق مع DOCSIS بحيث يعمل بشكل أفضل في البيئات التي تشترك فيها جميع تدفقات خدمة UGS في نفس حجم المنحة وفترات المنحة. وهذا هو المكان الذي تشترك فيه جميع مكالمات VoIP في نفس المشفر، مثل تعيين الحزمة G.711 بسرعة 10 مللي ثانية أو 20 مللي ثانية كما يحدث في نظام نموذجي يستند إلى PacketCable 1.0. عند وجود فواصل وأحجام منح متباينة، فإن سعة مجدول DOCSIS المتوافق مع دعم عدد كبير من تدفقات خدمة UGS تقل على أحد عمليات التشغيل. بالإضافة إلى ذلك، يمكن أن يحدث مقدار صغير جدا من الاهتزاز (أقل من 2 مللي ثانية) لبعض المنح حيث يحاول المجدول ربط تدفقات خدمة UGS بفترات وأحجام مختلفة.
نظرا لأن شبكات PacketCable MultiMedia (PCMM) أصبحت أكثر شيوعا، فقد تصبح أكثر شيوعا لمجموعة متنوعة من برامج تشفير VoIP مع فترات مختلفة لتخصيص الحزم ليتم تشغيلها في نفس الوقت. يمكن لهذا النوع من البيئات دعم أداة الجدولة "لقوائم انتظار" ذات زمن الانتقال المنخفض.
تم إدخال مجدول قوائم انتظار المهلة المنخفضة (LLQ) في برنامج Cisco IOS الإصدار 12.3(13a)BC. LLQ هو الطريقة البديلة لجدولة خدمات البث على Cisco uBR CMTS. وقد تم تصميم أداة الجدولة هذه لزيادة عدد تدفقات خدمة نمط UGS و RTPS إلى أقصى حد، ويمكن أن يدعمها الخادم في آن واحد، كما يمكن أن تحسن كفاءة حركة مرور أفضل الجهود في وجود تدفقات خدمة UGS. وتتمثل النتيجة في أن مجدول LLQ لا يقدم أي ضمانات فيما يتعلق بالرغبة في تدفق خدمات UGS و RTPS.
كما يناقش قسم المجدول المتوافق مع DOCSIS، فإن المجدول المتوافق مع DOCSIS يقوم مسبقا بتخصيص وقت الإرسال مسبقا لتدفقات خدمة نمط UGS و RTPS. وهذا مشابه للطريقة التي يقوم بها نظام تجميع انقسام الوقت القديم (TDM) بتخصيص النطاق الترددي لخدمة ما لضمان مستويات معينة من زمن الوصول والتشوه.
في الشبكات الحديثة المستندة إلى الحزم، تكون قوائم انتظار المهلة المنخفضة هي الطريقة التي تستخدمها الموجهات لضمان إمكانية تسليم الحزم المرتبطة بالخدمات ذات الأولوية العليا، على سبيل المثال الصوت والفيديو، في شبكة قبل الحزم الأخرى ذات الأولوية المنخفضة. هذه أيضا هي الطريقة التي تستخدمها الموجهات الحديثة لضمان تقليل زمن الوصول والتشوه لحركة المرور الهامة.
إستخدام كلمة "ضمان" للنظام القائم على إدارة قاعدة بيانات المعاملات و"الحد الأدنى" للنظام القائم على LLQ فيما يتعلق بالتوتر وزمن الوصول. وفي حين أن ضمان عدم وجود زمن وصول وترنح صفري هو أمر مرغوب فيه، فإن المبادلة هي أن هذا النظام يكون عادة غير مرن ويصعب إعادة تشكيله وعموما غير قادر على التكيف بسهولة مع التغييرات في ظروف الشبكة.
ويمكن للنظام الذي يقلل زمن الوصول والتردد إلى الحد الأدنى، بدلا من توفير ضمان صارم، توفير المرونة اللازمة لتحسين نفسه باستمرار في مواجهة التغييرات في ظروف الشبكة. يتصرف مجدول قوائم انتظار المهلة المنخفضة بطريقة مماثلة لنظام LLQ المستند إلى موجه الحزم. وبدلا من وضع نظم مقررة مسبقا لتخصيص منح UGS، فإن هذا النظام يقوم بجدولة المنح "في أقرب وقت ممكن" عند النقطة التي يلزم جدولتها فيها.
ويجب تخصيص النهج الذي يمنح لتدفقات خدمات UGS في أقرب وقت ممكن ولكن ليس بالضرورة بتواتر تام، ويعبر هذا النظام عن ضمانات رجعية صارمة لزيادة قدرة UGS وتجزئة البيانات المتعلقة بأفضل الجهود.
بالنسبة للإصدارات 12.3(13a)BC من البرنامج Cisco IOS Software والإصدارات الأحدث، يكون برنامج LLQ Scheduler واحدا من خوارزميات المجدول البديلة. يمكنك تمكين LLQ لواحد أو كل أو بعض أوضاع الجدولة التالية:
UGS
RTPS
NRTPS
لم يتم تمكين مجدول LLQ بشكل افتراضي. يجب تشغيل مجدول LLQ بشكل صريح لأنواع جدولة تدفق البيانات إلى الخادم المطلوبة. إستخدام نوع جدولة تدفق الكبل أعلى تدفق منفذ [NRTPS | RTPS | ugs] mode llq cable interface أمر.
بصفة عامة، يمكنك تمكين مجدول LLQ لجميع أوضاع الجدولة المدرجة إذا كان هذا هو وضع الجدولة المطلوب. فيما يلي مثال لحالة تريد فيها تمكين جدولة LLQ لنوع واحد فقط من وضع الجدولة ولكن مع الاحتفاظ بالمجدول المتوافق مع DOCSIS للآخرين:
لا تتضمن تدفقات خدمة RTPS أي متطلبات صارمة للرجفان ولكن تدفقات خدمة UGS لها. في هذه الحالة، يمكنك تمكين مجدول LLQ لتدفق خدمة RTPS، والاحتفاظ بمجدول DOCSIS المتوافق مع UGS.
يعمل مجدول LLQ بنفس الطريقة التي تعمل بها وظيفة قوائم الانتظار ذات الأولوية الخاصة بمجدول DOCSIS المتوافق مع إضافة قائمة انتظار خاصة ذات زمن وصول أقل (LLQ)، مما يعطي الأولوية على جميع قوائم الانتظار الأخرى.
يقوم مجدول LLQ بتشغيل مؤقت بالنيابة عن جميع تدفقات خدمة نمط UGS (و RTPS) النشطة. تم تعيين المؤقت على إيقاف التشغيل مرة واحدة في كل "فترة منح". عند انتهاء صلاحية المؤقت، يتم وضع منحة UGS في قائمة انتظار LLQ. ونظرا لوضع هذه المنحة في قائمة انتظار LLQ التي لها أولوية قصوى، فإنه يتم جدولة المنحة في اللحظة التالية الممكنة حيث توجد مساحة حرة.
تعرض المخططات في هذا القسم مثالا لنظام به ثلاث عمليات تدفق خدمة UGS نشطة بنفس فترة المنحة. الشكل 27 يوضح زمن تدفق خدمة UGS على اليسار، ويطلق عليه UGS-1 من خلال UGS-3. يتحرك السهم الأصفر باتجاه عقارب الساعة. عندما يشير السهم الأصفر لأعلى نحو النقطة الحمراء، تتم إضافة منحة UGS إلى قائمة انتظار LLQ. كما يمكنك أيضا مشاهدة ثماني قوائم انتظار ذات أولوية مألوفة تتراوح من صفر إلى 7 وقائمة انتظار LLQ جديدة تعطي الأولوية لها جميعا. أخيرا، إلى اليمين، هو الخط الزمني لتخصيص عرض النطاق الترددي الذي يصف كيفية جدولة المنح على المنبع. للحصول على وضوح إضافي، يتضمن سطر وقت تخصيص عرض النطاق الترددي مؤشر "الوقت الحالي". يتحرك هذا المؤشر للأمام على الخط الزمني أثناء انتقال المثال.
الشكل 27 - نظام قوائم انتظار المهلة المنخفضة
الحدث الأول الذي يحدث هو انتهاء صلاحية مؤقت UGS-1 في أعلى اليسار. تم وضع المنحة المطابقة في قائمة انتظار LLQ. وفي الوقت نفسه، يتم وضع منحة أفضل جهد تسمى A ذات الأولوية 2 في قائمة الانتظار.
الشكل 28 - وضع المنحة المقدمة للمنحة UGS-1 والمنحة ذات الأولوية 2 A في قائمة الانتظار
ويخصص برنامج LLQ Scheduler الآن وقت الإرسال إلى المنح المعلقة حسب ترتيب الأولوية. أول منحة لتلقي وقت الإرسال هي منحة UGS-1 التي تنتظر في قائمة انتظار LLQ. المنحة A كما يلي.
الشكل 29 - منح UGS-1 والمنحة (أ) وقتا مخصصا لانتقال المرض
الحدث التالي الذي سيحدث هو انتهاء صلاحية مؤقت UGS-2 ويتسبب في وضع منحة لتدفق خدمة UGS-2 في قائمة انتظار LLQ. وفي الوقت نفسه، يتم وضع المنحة B ذات الأولوية 0 في قائمة الانتظار، بينما يتم وضع الأولوية 6 للمنحة C في قائمة الانتظار.
الشكل 30 - انتهت صلاحية المؤقت UGS-2. تم وضع المنح B و C في قائمة الانتظار
ويخصص برنامج جدولة LLQ مرة أخرى وقت الإرسال حسب ترتيب أولوية المنح، مما يعني أن المجدول يخصص أولا وقتا للمنحة من UGS-2، ثم للمنحة C، وأخيرا للمنحة B.
الشكل 31 - منح UGS-2 و C و B وقت انتقال مخصص
افترض أنه لا يتم منح أية محاولة لإدخال المجدول لفترة من الوقت. تنتهي صلاحية وحدات توقيت UGS عدة مرات. يمكنك الآن رؤية نوع الفترة التي تقوم بها أداة الجدولة بتخصيص المنح ل UGS. يبدو أنها موزعة بالتساوي. وإذا افترضنا أن المنح عندما تظهر على هذا النحو في علاقتها ببعضها البعض على الجدول الزمني لتخصيص النطاق الترددي العريض، فإنها لا تواجه أي تشويش كبير.
الشكل 32 - يتلقى UGS-1 و UGS-2 و UGS-3 عددا من المنح. تم وضع المنحة D في قائمة الانتظار
يشير الشكل 32 إلى الوضع المثالي لمنحة UGS-2 التالية. وإذا كان بإمكان UGS-2 الحصول على المنحة في هذا الموقع، فإن UGS-2 لن يواجه أي تشويش على المنحة. لاحظ أنه لا يزال هناك وقت لانتظار منحة UGS-2 التالية في قائمة انتظار LLQ.
يشير الشكل 32 أيضا إلى أن منحة 0 ذات أولوية كبيرة جدا قد دخلت لتوها قائمة انتظار الأولوية 0. الإجراء التالي الذي يتخذه مجدول LLQ هو جدولة وقت الإرسال للمنحة D.
الشكل 33 يعرض هذا السيناريو. أرجعوا الساعة إلى الامام قليلا إلى النقطة حيث تكون المنحة التالية ل UGS-2 في قائمة الانتظار.
الشكل 33 - المنحة D تتلقى وقت الإرسال. تم وضع المنحة ل UGS-2 في قائمة الانتظار
ويبدو أن المنحة دال كانت مقررة في الوقت الذي يجب فيه جدولة منحة UGS-2 المقبلة على أن تكون بلا تشويش. والسؤال الآن هو لماذا يسمح مجدول LLQ بجدولة المنحة D عند تلك النقطة ولا يؤجل المنحة D حتى بعد المنحة ل UGS-2 أو لماذا لم يتم تجزؤ D. الإجابة هي أن مجدول LLQ لا يقوم بتخصيص وقت الإرسال مسبقا لتدفقات خدمة UGS. وبالتالي، لا تعلم أداة جدولة LLQ مسبقا بمكان منح UGS على سطر وقت تخصيص عرض النطاق الترددي. لا تعرف خدمة جدولة LLQ منح UGS حتى يتم وضعها في قائمة انتظار LLQ. في هذا المثال، بحلول الوقت الذي تدخل فيه منحة UGS-2 في قائمة الانتظار، تكون المنحة D قد تمت جدولتها بالفعل.
وجدول LLQ للمنحة للفئة UGS-2 في الفرصة المتاحة التالية، ولكن هذه المنحة متأخرة قليلا عن الوضع المثالي، مما يعني بحكم التعريف أن هذه المنحة الخاصة تواجه بعض الارتباك.
الشكل 34 - تأخر تقديم منحة للفئة الثانية من الخدمات العامة (UGS-2) وتذبذب التجارب
وفي حين أنه كان بإمكان المجدول المتوافق مع DOCSIS تجنب هذا الارتباك، فإن مجدول LLQ يتجنب تأخير أو تجزئة المنحة D على حساب مقدار صغير فقط من الرجفان. يمكن لمخزن مؤقت للتشويش في نقطة نهاية VoIP التعويض بسهولة عن هذا التشوه.
الحالة الأخرى التي يمكن أن يحدث فيها الاهتزاز هي عندما تنتهي صلاحية مؤقت LLQ الخاص بتدفقات خدمات متعددة في نفس الوقت وتمنح UGS الانتظار خلف منح UGS الأخرى التي يتم وضعها في قائمة انتظار LLQ. تم تصميم مجدول LLQ لتقليل إمكانية حدوث هذا الحدث إلى الحد الأدنى. يقوم المجدول تلقائيا بنشر أوقات انتهاء الصلاحية لأوقات تدفق الخدمة.
وفقا لمجدول DOCSIS المتوافق، تحتوي خدمة LLQ Scheduler على قائمتي انتظار إضافيتين لا تذكرهما الأمثلة. هنا الطوابير:
يتم إستخدام قائمة الانتظار الأولى لجدولة حركة مرور رسائل تنشيط الصيانة الدورية للمحطة لإبقاء أجهزة مودم الكبلات عبر الإنترنت. تتم خدمة قائمة الانتظار هذه بعد قائمة انتظار LLQ مباشرة.
والثاني هو قائمة انتظار للمنح المخصصة لتدفقات الخدمات ذات الحد الأدنى من المعدل المحجوز (تدفقات خدمة CIR). يتم التعامل مع قائمة انتظار CIR هذه كقائمة انتظار "أولوية 8" لضمان أن تدفقات الخدمة بمعدل محدد تتلقى الحد الأدنى من سعة المعالجة المطلوبة.
على عكس "مجدول DOCSIS" المتوافق، لا تستخدم أداة جدولة LLQ نظام جدولة مسبقة يقوم بوقف تجاوز الاشتراك العرضي في أحد عمليات التحميل باستخدام UGS و RTPS. ولهذا السبب يجب تكوين التحكم في الدخول إلى الخادم بشكل صريح على أي تدفق يستخدم مجدول LLQ. يضمن هذا التكوين ألا يتجاوز النطاق الترددي الإجمالي لتدفقات خدمة UGS للتحميل الحدود المعقولة.
تقترح Cisco بشكل عام عدم السماح باستخدام قناة الخادم بأكثر من 75٪ لفترات ممتدة أثناء فترات الاستخدام القصوى. على سبيل المثال، إذا استهلكت حركة مرور UGS أكثر من 75٪ من النطاق الترددي العريض للتدفق، فإن بيانات أفضل الجهود تبدأ في المعاناة من زمن الوصول الزائد ومشكلات أداء الخرج.
بطبيعة الحال إذا كان مشغل CMTS قادرا على قبول العواقب السلبية لحركة مرور أفضل الجهود، فيمكنك ترك خدمة UGS تستهلك أكثر من 75٪ من عرض النطاق الترددي المتاح للتدفق من الخادم. مهما، أنت ينبغي أيضا أخذت في الاعتبار التأثير على الطبقة 2 إدارة حركة مرور على المنبع قناة. يجب أن تسمح بالوقت للمراسلة الأولية ومراسلة صيانة المحطة (رسائل keepalive لمودم الكبل). إذا لم تضع هذا في الاعتبار، وتستهلك حركة مرور UGS ما يقرب من 100٪ من النطاق الترددي، فلن تتمكن أجهزة مودم الكبلات من الاتصال أو قد تقع دون اتصال.
هنا مثال لتكوين التحكم في الدخول. يقوم هذا المثال بتقييد تدفقات خدمة UGS على تدفق تدفق خاص إلى 50٪ من النطاق الترددي المتاح من الخادم. يرسل هذا النموذج من الأمر أيضا ملائمات SNMP إلى أي محطات إدارة شبكة مكونة عندما يتم الوصول إلى الحدين الثانوي والأساسي 30٪ و 40٪ إستخدام. والأمر هو:
دخول رقم التحكم في دخول تدفق الكبل إلى الخادم الولايات المتحدة-نوع جدولة عرض النطاق الترددي UGS Minor 30 Major 40 Exclusive 50
راجع قسم التحكم في الدخول ضمن قسم "المجدول" المتوافق مع DOCSIS في هذا المستند لمعرفة كيفية تكوين التحكم في الدخول.
قم بإصدار الأمر show interface cable interface-number mac-scheduler upStream-number لقياس الحالة الحالية ل LLQ Scheduler.
هنا مثال من الإنتاج من هذا أمر. تكون أجزاء مخرجات الأمر التي تختلف عن وقت تشغيل المجدول المتوافق مع DOCSIS في نص غامق:
uBR7200VXR# show interface cable 5/0 mac-scheduler 0 DOCSIS 1.1 MAC scheduler for Cable5/0/U0 Queue[Rng Polls] 0/128, 0 drops, max 1 Queue[CIR Grants] 0/64, 0 drops, max 2 Queue[BE(7) Grants] 0/64, 0 drops, max 0 Queue[BE(6) Grants] 0/64, 0 drops, max 0 Queue[BE(5) Grants] 0/64, 0 drops, max 0 Queue[BE(4) Grants] 0/64, 0 drops, max 0 Queue[BE(3) Grants] 0/64, 0 drops, max 2 Queue[BE(2) Grants] 0/64, 0 drops, max 0 Queue[BE(1) Grants] 0/64, 0 drops, max 0 Queue[BE(0) Grants] 0/64, 0 drops, max 5 Queue[LLQ Grants] 0/64, 0 drops, max 3 Req Slots 165488850, Req/Data Slots 871206 Init Mtn Slots 1727283, Stn Mtn Slots 1478295 Short Grant Slots 105668683, Long Grant Slots 52721 ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0 ATDMA UGS Grant Slots 0 Awacs Slots 1303668 Fragmentation count 11215 Fragmentation test disabled Avg upstream channel utilization : 6% Avg percent contention slots : 91% Avg percent initial ranging slots : 3% Avg percent minislots lost on late MAPs : 0% Sched Table Rsv-state: Grants 0, Reqpolls 0 Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1% UGS : 3 SIDs, Reservation-level in bps 278400 UGS-AD : 0 SIDs, Reservation-level in bps 0 RTPS : 0 SIDs, Reservation-level in bps 0 NRTPS : 0 SIDs, Reservation-level in bps 0 BE : 14 SIDs, Reservation-level in bps 0 r4k ticks in 1ms 600000 Total scheduling events 5009 No search was needed 5009 Previous entry free 0 Next entry free 0 Could not schedule 0 Recovery failed 0 Curr time 1341 entry 61 Entry 188, Bin 13 SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20 type 8, perfect time ref 188, skew from ref 0, priority 10 position 188, bin 13 Entry 188, Bin 14 SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20 type 8, perfect time ref 188, skew from ref 0, priority 10 position 188, bin 14 Entry 192, Bin 12 SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20 type 8, perfect time ref 192, skew from ref 0, priority 10 position 192, bin 12
للحصول على شرح لخطوط النص العادية في هذا الإخراج، راجع قسم عرض الأمر output لمجدول متوافق مع DOCSIS.
هنا أوصاف الخطوط الغامقة من العرض أمر إنتاج:
قائمة الانتظار [منح LLQ] 0/64، 0 عمليات إسقاط، الحد الأقصى 3
يوضح هذا البند حالة قائمة انتظار LLQ، التي تدير منح أنواع تدفق الخدمة المحددة في نوع جدولة تدفق تدفق الكبل [nrtps | RTPS | ugs] mode llq command. يشير 0/64 إلى وجود صفر حاليا من أصل 64 منحة معلقة كحد أقصى في قائمة الانتظار.
يشير عداد عمليات الإسقاط إلى عدد المرات التي تعذر فيها على المجدول انتظار منح UGS أو إستقصاء RTPS لأن قائمة الانتظار هذه ممتلئة بالفعل (بمعنى آخر، عند وجود 64 منحة في قائمة الانتظار). إذا حدثت عمليات إسقاط في قائمة الانتظار هذه، فإن التفسير الأكثر ترجيحا هو أنه تم زيادة الاشتراك في تدفق خدمة UGS أو RTPS ويجب عليك تطبيق تحكم أكثر صرامة في الدخول.
يشير العداد الأقصى إلى الحد الأقصى لعدد المنح الموجودة في قائمة الانتظار هذه منذ آخر تشغيل للأمر show interface cable mac-scheduler. عند وجوده، تكون لقائمة الانتظار هذه أعلى أولوية لكافة قوائم الانتظار المدرجة.
r4k من الإشارات في 1ms 60000
يمثل هذا الحقل متغير توقيت داخلي تستخدمه خدمة LLQ Scheduler لضمان وضع المنح في قائمة انتظار LLQ بدقة عالية.
إجمالي أحداث الجدولة 5009
يشير هذا السطر إلى عدد المرات التي يحاول فيها مجدول LLQ وضع منحة في قائمة الانتظار منذ آخر مرة تم فيها تشغيل الأمر show interface cable mac-scheduler لهذا الخادم. تتم إعادة تعيين هذا العداد في كل مرة يتم فيها تشغيل الأمر show.
لم تكن هناك حاجة للبحث 5009
بعد أن يقوم مجدول LLQ بوضع منحة في قائمة الانتظار، يحاول مجدول LLQ إعادة تعيين مؤقت تدفق الخدمة للإعداد للمرة التالية التي يتم فيها وضع المنحة في قائمة الانتظار. في حالة عدم وجود مشاكل في إعادة تعيين المؤقت، يتزايد هذا العداد. يجب أن يحتوي هذا العداد بشكل مثالي على نفس قيمة عداد إجمالي أحداث الجدولة.
الإدخال السابق مجاني 0، الإدخال التالي مجاني 0
لا تزيد أي من هذه العدادات في الإصدارات الحالية من برنامج Cisco IOS Software. تبقى هذه العدادات دائما عند الصفر.
تعذر جدولة 0، فشل الاسترداد 0
يشير هذا السطر إلى عدد المرات التي تعذر فيها على مجدول LLQ الترتيب لتعيين مؤقت منح تدفق الخدمة بشكل صحيح. يجب أن يحدث ذلك فقط إذا كان مجدول LLQ يتعامل مع عدد كبير للغاية من المنح بفترات منح منخفضة جدا. من غير المرجح جدا أن تزيد هذه العدادات على شبكة إنتاج. يمكن أن تشير زيادة هذه العدادات إلى أن تدفقات خدمة UGS و RTPS تستهلك عرض نطاق أكبر من المتوفر فعليا على الخادم. في هذا السيناريو، يلزمك تنفيذ أوامر التحكم في الدخول المناسبة.
الإدخال في الوقت الحالي 1341 61
يعرض هذا السطر وحدات التوقيت الداخلية لمخطط LLQ الذي يتم قياسه بالمللي ثانية. عندما يساوي حقل "الإدخال" المدرج هنا الحقل "الإدخال" المدرج في إحصائيات تدفق الخدمة لكل خدمة، يتم وضع المنحة في قائمة انتظار LLQ.
ويتم تكرار هذه الإحصائيات لكل تدفق خدمة يعالجه مجدول LLQ. في هذا المثال، توجد ثلاث تدفقات من هذه الخدمات.
Entry 188، Bin 13
عندما تكون قيمة "الإدخال" مساوية لحقل "الإدخال" في العنصر السابق، تنتهي صلاحية وحدة التوقيت لتدفق الخدمة هذا وتذهب المنحة إلى قائمة انتظار LLQ. يقوم هذا الحقل بإعادة الضبط في كل مرة يتم فيها وضع المنحة في قائمة الانتظار الخاصة بتدفق الخدمة.
سيد: 416
معرف الخدمة (SID) لتدفق الخدمة الذي يمنح جداول مجدول LLQ.
IUC: 5
رمز إستخدام الفاصل الزمني المعلن عنه في رسالة MAP للمنح التي تنتمي إلى تدفق الخدمة هذا. ويكاد يكون هذا الرقم 5 في حالة "البيانات القصيرة"، و 6 بالنسبة "البيانات الطويلة" أو 11 بالنسبة إلى "PHY UGS المتقدمة" عندما يكون تدفق خدمة نمط UGS قيد الاستخدام. بالنسبة لتدفق خدمة نمط RTPS، تكون هذه القيمة دائما 1 ل "الطلب".
size_ms: 17 size_byte: 232
حجم المنحة في مساحات صغيرة، متبوعا بحجم المنحة بالبايت. وحدة صغيرة هي أصغر وحدة إرسال من الخادم في شبكة DOCSIS وعادة ما تكون مساوية ل 8 أو 16 بايت.
FRAG: N
الإشارة إلى ما إذا كانت المنحة قابلة للتجزئة. في الوقت الحالي، يتم تعيين هذه القيمة دائما على N.
إنفال: 20
فترة المنحة أو الاستقصاء بالمللي ثانية.
نوع 8
8 يشير إلى أن تدفق الخدمة هذا هو UGS، و 10 يشير إلى RTPS و 11 يشير إلى NRTPS.
أفضل وقت ref 188
الوقت المثالي الذي يجب جدولة هذه المنحة فيه. وهذا هو عادة ما يسمى "Entry" في الأعلى. وإذا لم يكن الأمر كذلك، فهناك مؤشر على وجود اكتظاظ شديد في المنبع يحتاج إلى تحكم أكثر صرامة في الدخول.
منحرف من المرجع 0
الفرق بين وقت جدولة هذه المنحة ووقت جدولة المنحة بشكل مثالي. وهذا هو الفرق بين "الدخول" و "الوقت الكامل ref". لذلك، يجب أن تكون هذه القيمة عادة صفر.
الأولوية 10
في الإصدارات الحالية من برنامج Cisco IOS، يتم تعيين هذه القيمة دائما على 10، ولكن يمكن أن تختلف في المستقبل.
الموضع 188، بن 13
يجب أن تكون هذه الحقول هي نفسها "Entry، Bin" في أعلى هذه القائمة.
يتمثل الهدف من أداة جدولة LLQ في زيادة سعة UGS و RTPS لقنوات البث وزيادة كفاءة حركة مرور أفضل الجهود. تتمثل الطريقة التي يقوم بها مجدول LLQ لتحقيق هذه الأهداف في أن مجدول البيانات هذا لا يوفر ضمانات بشكل صريح ل UGS و RTPS Service Flow Itter. وبدلا من ذلك، فإن برنامج جدولة LLQ يجدولة منح UGS واستطلاعات RTPS أقرب ما يكون إلى الوقت المثالي قدر الإمكان بغية تقليل التشوه إلى الحد الأدنى.
كما أن مجدول LLQ قادر على معالجة تدفقات خدمات UGS متعددة بشكل أفضل باستخدام فواصل منح مختلفة وأحجام منح مختلفة عن مجدول DOCSIS المتوافق. يمكن أن تكون هذه الميزة مفيدة في بيئة PCMM حيث يتم تقديم أنواع مختلفة من مكالمات VoIP وربما تطبيقات أخرى في نفس الوقت على قناة الخادم الواحدة.
تقوم أداة جدولة LLQ بجدولة حركة مرور أفضل الجهود بكفاءة أكبر لأن أداة جدولة LLQ تقلل من أحتمالية تجزئة المنح. عند جدولة عمليات تشغيل DOCSIS 1.0 غير القابلة للتجزئة، لا تقوم أداة جدولة LLQ بإنشاء فجوات في النطاق الترددي غير المستخدم أمام منح UGS أو استعلامات RTPS كما هو الحال في بعض الأحيان في أداة الجدولة المتوافقة مع DOCSIS. يؤدي ذلك إلى إستخدام أفضل للوقت المتاح للمنبع.
على الرغم من أن رجفان UGS يكون بشكل عام أعلى عند إستخدام مجدول LLQ من عند إستخدام مجدول DOCSIS المتوافق، في الشبكات النموذجية المستندة إلى DOCSIS أو PacketCable، تكون مستويات رجفان LLQ SCHEDULER في حدود سعة تقنية المخزن المؤقت لرجفان نقطة نهاية VoIP. وهذا يعني أنه لا يوجد تأثير ملحوظ على جودة مكالمات VoIP عند إستخدام مجدول LLQ في شبكة VoIP مصممة بشكل صحيح.
يمكنك الحد من الهيجان الذي ينشأ من اندفاعات كبيرة في المنبع. لهذا، تأكد من الاحتفاظ بمعلمة Cable default-phy-burst بالقيمة الافتراضية التي تبلغ 2000 بايت أو أقل. إذا كان النظام يستخدم قناة تدفق بطيئة، مثلا مع 800 كيلوهرتز أو عرض قناة أصغر، يمكنك تحقيق المزيد من التخفيضات في التشنج إذا قمت بإجبار تشوهات كبيرة على أن يتم تجزئتها إلى أخرى أصغر باستخدام أمر قوة جزء تدفق الكبل المنبع.
عندما يكون مجدول LLQ قيد الاستخدام، يجب تكوين التحكم في الدخول إلى الكبل لمنع احتمال الاكتتاب الزائد في قناة الخادم. تتدفق خدمة UGS أكثر نشاطا مما يمكن للتدفق الأولي معالجته بشكل فعلي، مما يؤدي إلى ضعف جودة الصوت عبر جميع تدفقات خدمة UGS على الخادم. في الحالات القصوى، يعني ذلك أيضا أن أجهزة مودم الكبلات غير متصلة وأن أجهزة مودم الكبلات الجديدة غير قادرة على الاتصال بالإنترنت. توصي Cisco بأن يقوم مشغلو CMTS بتكوين التحكم في الدخول بحيث لا يتجاوز إجمالي إستخدام الخادم على أي منفذ للتحميل 75٪ لفترات زمنية ممتدة.
توفر سلسلة Cisco uBR من منتجات DOCSIS CMTS خوارزميين بديلين لجدولة البث، وبالتالي فإنها قادرة على تلبية مجموعة متنوعة من شروط الشبكة.
إن المجدول المتوافق مع DOCSIS، والذي تم تحسينه للرجفان المنخفض، هو الأكثر ملاءمة لأنظمة PacketCable 1.x الصوتية النموذجية مع وجود برنامج ترميز موحد VoIP وحيثما تكون المستويات القياسية لاستخدام قناة الخادم بواسطة تدفقات خدمة UGS مطلوبة.
تم تصميم مجدول قوائم انتظار تقليل التأخير لدعم مستويات إستخدام أعلى من الطبيعي للتدفق بواسطة خدمة UGS، وزيادة كفاءة حركة مرور أفضل الجهود، والأنظمة التي تستخدم UGS و RTPS من تدفقات الخدمة مع مجموعة متنوعة من الفواصل الزمنية للمنح وأحجام المنح.
وحدة صغيرة هي أصغر وحدة إرسال في تدفق DOCSIS. عندما يقوم مودم الكبل بإرسال طلب عرض نطاق ترددي إلى CMTS لطلب وقت الإرسال إلى الخادم، يطلب المودم وحدات قطع صغيرة بدلا من وحدات البايت أو المللي ثانية. بالإضافة إلى ذلك، عندما تقوم رسالة خريطة تخصيص عرض النطاق الترددي بإعلام أجهزة المودم بموعد إرسالها ومدة إرسالها، تحتوي الرسالة على المعلومات بوحدات قطع الصغيرة.
الحد الأقصى لعدد قطع الصغيرة التي يمكن للمودم أن يطلب إرسالها في دفعة واحدة هو 255. يتم تحديد حجم الضآلة في الوحدات التي تسمى حزم DOCSIS. تعتبر خطوة DOCSIS ما يعادل 6.25 ميكروثانية في الوقت.
لتعيين حجم صغير في علامات لمنفذ تدفق، قم بإصدار حجم صغير للتدفق الكبل <upstream-number> [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128] أمر واجهة الكبل.
يسمح فقط بأحجام صغيرة معينة من خلال عروض قنوات معينة عند أعلى المجرى. يظهر هذا الجدول أحجام مساحة ضئيلة صالحة مقابل عروض قناة DOCSIS للتدفق، كما يعرض الطول في رموز مخطط التعديل الخاصة بقطعة صغيرة ذات إعدادات صالحة.
ملاحظة: تشير علامة X إلى تركيب غير صحيح.
عرض القناة | 200 كيلو هرتز | 400 كيلو هرتز | 800 كيلو هرتز | 1٫6 ميغا هرتز | 3٫2 ميغا هرتز | 6٫4 ميغا هرتز | |
---|---|---|---|---|---|---|---|
حجم صغير في قطع صغيرة | |||||||
1 | X | X | X | X | X | 32 | |
2 | X | X | X | X | 32 | 64 | |
4 | X | X | X | 32 | 64 | 128 | |
8 | X | X | 32 | 64 | 128 | 256 | |
16 | X | 32 | 64 | 128 | 256 | X | |
32 | 32 | 64 | 128 | 256 | X | X | |
64 | 64 | 128 | 256 | X | X | X | |
128 | 128 | 256 | X | X | X | X |
لحساب عدد وحدات البايت المرسلة لكل قطعة صغيرة، اضرب الرموز لكل قطعة صغيرة بعدد وحدات بت لكل رمز لمخطط التعديل الذي تم تكوينه. تنقل أنظمة التعديل المختلفة أعداد مختلفة من وحدات بت لكل رمز كما هو موضح في هذا الجدول:
خطط تعديل DOCSIS 1.1 TDMA | وحدات بت لكل رمز |
---|---|
QPSK | 2 |
16-QAM | 4 |
مخططات تعديل DOCSIS 2.0 ATDMA | وحدات بت لكل رمز |
---|---|
8-QAM | 3 |
32-QAM | 5 |
64-QAM | 6 |
على سبيل المثال، بعرض قناة 1.6 ميجاهيرتز وحجم قطعة صغيرة 4 ميجاهيرتز، يمكنك إستخدام الجدول الأول للوصول إلى شكل 32 رمزا لكل قطعة صغيرة. أستخدم الجدول الثاني لتحويل هذا الشكل إلى بايت، لأن رمز QPSK يحتوي على 2 بت. قطعة صغيرة واحدة في هذا المثال تساوي 32 رمزا لكل قطعة صغيرة * 2 بت لكل رمز = 64 بت لكل قطعة صغيرة = 8 بايت لكل قطعة صغيرة.
تذكر أن الحد الأقصى لعدد رسائل التجزئة الصغيرة التي يمكن لمودم الكبل طلب إرسالها هو 255. لذلك، في هذا المثال، يكون أكبر تدفق بالبايت للتدفق في الخادم هو 255 قطعة صغيرة * 8 بايت لكل قطعة صغيرة = 2040 بايت.
لاحظ أن هذا الشكل بالبايت هو تصحيح أخطاء إعادة التوجيه ورقم ترحيل صورة عامة للطبقة الفعلية. يضيف تصحيح الأخطاء ونفقات طبقة DOCSIS PHY الأخرى حوالي 10 إلى 20 بالمائة إلى طول إطار الإيثرنت أثناء مروره عبر قناة الخادم. لاستخلاص الشكل الدقيق، أستخدم ملف تعريف التعديل المطبق على منفذ المنبع.
هذه المناقشة مهمة لأن أحد المقاطع السابقة من هذا المستند ينص على أن أحد الحدود على الحد الأقصى لحجم الاندفاع لمودم الكبل هي القيمة التي تم تكوينها في الأمر cable default-phy-burst. إذا تم تعيين الأمر cable default-phy-burst على 4000 بايت في سياق هذا المثال، فإن العامل المقيد أو حجم الاندفاع هو الحد الصغير 255 (2040 بايت ناقص المصروفات العامة) بدلا من قيمة كبل default-phy-burst.
يمكنك ملاحظة تعبيرات مختلفة من حجم الضئيل لتدفق ما باستخدام الأمر show controller cable interface-number upstream upstream-number. فيما يلي مثال:
uBR7200VXR# show controller cable 5/0 upstream 0 Cable5/0 Upstream 0 is up Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps This upstream is mapped to physical port 0 Spectrum Group 1, Last Frequency Hop Data Error: NO(0) MC28U CNR measurement : better than 40 dB US phy MER(SNR)_estimate for good packets - 36.1280 dB Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100 Ranging Backoff Start 3, Ranging Backoff End 6 Ranging Insertion Interval automatic (60 ms) US throttling off Tx Backoff Start 3, Tx Backoff End 5 Modulation Profile Group 41 Concatenation is enabled Fragmentation is enabled part_id=0x3138, rev_id=0x03, rev2_id=0x00 nb_agc_thr=0x0000, nb_agc_nom=0x0000 Range Load Reg Size=0x58 Request Load Reg Size=0x0E Minislot Size in number of Timebase Ticks is = 8 Minislot Size in Symbols = 64 Bandwidth Requests = 0x338C Piggyback Requests = 0x66D Invalid BW Requests= 0xD9 Minislots Requested= 0x756C2 Minislots Granted = 0x4E09 Minislot Size in Bytes = 16 Map Advance (Dynamic) : 2482 usecs UCD Count = 8353
cisco يوصي أن يثبت أنت الحجم صغير أن a miniLotLot مكافئ إلى 16 بايت أو أقرب قيمة مسموح بها. يعطي حجم قطعة صغيرة يبلغ 16 بايت أجهزة مودم الكبلات القدرة على إنشاء اندفاع ما بعد FEC يصل إلى 255 * 16 = 4096 بايت.
تقوم CMTS بإنشاء رسالة خاصة بشكل دوري تسمى خريطة تخصيص النطاق الترددي التي تقوم بإعلام أجهزة مودم الكبلات بوقت دقيق عندما يمكن لأجهزة المودم إجراء عمليات الإرسال على قناة الخادم. تأخذ الإشارات الكهربائية التي تنقل رسالة الخريطة مقدار محدود من الوقت للانتشار فيزيائيا من خلال شبكة كبلات الهيكل المختلطة (HFC) من CMTS إلى جميع أجهزة مودم الكبلات المتصلة. ونتيجة لذلك، يلزم إرسال رسالة الخريطة في وقت مبكر بما فيه الكفاية لكي تتلقى أجهزة المودم الرسالة وتكون قادرة على إجراء عمليات الإرسال الخاصة بها من المنبع بحيث تصل إلى CMTS في الوقت المحدد.
يمثل زمن تقدم الخريطة أو زمن نظرة الخريطة إلى الأمام الفرق بين الوقت الذي يقوم فيه CMTS بتوليد رسالة الخريطة والوقت الذي يلزم فيه تلقي أول عملية إرسال تطلبت بواسطة MAP من قبل CMTS. يمثل هذا الوقت مجموعة من حالات التأخير الموجودة في نظام DOCSIS:
الوقت الذي يستغرقه CMTS لإنشاء رسالة الخريطة في البرنامج ولوضع الرسالة في قائمة الانتظار ومعالجتها بواسطة دوائر الإرسال لتدفق البيانات. تكون قيمة هذا المكون خاصة بالأنظمة الأساسية والبنى المختلفة، كما أنها بشكل عام قيمة ثابتة.
زمن الانتقال الذي تضيفه دالة الدفق البيني لتدفق البيانات، والذي يتم إستخدامه لأغراض تصحيح أخطاء إعادة التوجيه للحماية من تشويش النبضات. لتغيير هذه القيمة، قم بتغيير معلمات المتتالي لتدفق البيانات.
الوقت الذي تستغرقه الإشارات الكهربائية للانتقال عبر شبكة HFC من CMTS إلى مودم الكبل ثم مرة أخرى. يحدد DOCSIS الحد الأقصى لوقت الذهاب أحادي الإتجاه بين CMTS ومودم الكبل من 800 ميكروثانية. تختلف هذه القيمة حسب الطول الفعلي لمحطة الكبلات. كما يؤثر مخطط التعديل لتدفق البيانات ومخطط عرض قناة البث وتنقيحها على هذه القيمة.
وقت معالجة مودم الكبل لرسالة خريطة مستلمة والقدرة على التحضير لبث الخادم. يجب أن لا يزيد هذا عن 200 ميكرو ثانية بالإضافة إلى أي تأخير تدفق أمامي حسب الإرشادات في مواصفات DOCSIS. في الواقع، يمكن أن يصل إرتفاع هذا الوقت إلى 300 ميكرو ثانية أو قد يصل إلى 100 ميكرو ثانية حسب إعداد مودم الكبل وطرازه ومراجعته.
يمكن أن يؤثر زمن تقدم الخريطة بشكل ملحوظ على زمن انتقال عمليات الإرسال من الخادم لأن هذه القيمة تمثل الحد الأدنى للتأخير بين الوقت الذي يعرف فيه CMTS أن مودم الكبل يريد إجراء إرسال والوقت الذي يسمح فيه للمودم بإجراء ذلك الإرسال. لهذا السبب، قم بتقليل الوقت المتقدم للخريطة لتقليل زمن الوصول إلى الخادم.
لاحظ أن هناك عوامل أخرى تؤثر أيضا على زمن الوصول عند المنبع في حالة الازدحام. على سبيل المثال، تتسبب عمليات التأخير التي تتسبب فيها خوارزمية طلب عرض النطاق الترددي للرد الاحتياطي وإعادة المحاولة، ووضع المنح المعلقة في قائمة الانتظار وراء بعضها البعض.
يوضح الشكل 36 العلاقة بين خريطة ينتجها CMTS وإيصال البيانات المتوافق في الخادم.
الشكل 36 - العلاقة بين إنشاء الخريطة واستلام بيانات المنبع
العامل الأول في تقدم الخريطة الذي يمكن أن يختلف هو الشطب السفلي كما هو مستخدم للحماية من ضجيج النبضات. يوضح هذا الجدول زمن الوصول الذي تمت إضافته إلى عمليات الإرسال من الخادم لإعدادات ضغطات التفريغ المتتالي والزيادات المتتالي المختلفة:
ملاحظة: كلما كان حجم اللمس أكبر، كان تصحيح الخطأ أقوى، ولكن الأكبر أيضا هو زمن الوصول المستحث.
I (عدد TAPS) | ياء (الزيادة) | زمن الانتقال 64-QAM | زمن الانتقال 256-QAM |
---|---|---|---|
8 | 16 | 220 µ ثانية | 150 µ ثانية |
16 | 8 | 480 µ ثانية | 330 µ ثانية |
32 | 4 | 980 µ ثانية | 680 µ ثانية |
64 | 2 | 2000 µ الثانية | 1400 µ الثانية |
128 | 1 | 4000 µ ثانية | 2800 µ ثانية |
12 (EuroDOCSIS) | 17 (EuroDOCSIS) | 430 µ ثانية | 320 µ ثانية |
يمكنك تعيين معلمات الدفق مع عمق تداخل الكبل مع تدفق البيانات [8 | 16 | 32 | 64 | 128] أمر تكوين واجهة الكبل
ملاحظة: يتم تحديد قيمة I (عدد الأشرطة) وتنطبق تلقائيا قيمة ثابتة مناظرة للزيادة J (Increment) كما هو موضح في الجدول. كما أن البارامترات المتتلية ثابتة بالنسبة لوضع EuroDOCSIS (المرفق ألف) عند I = 12 و J = 17. القيمة الافتراضية ل i هي 32، أي يعطي قيمة افتراضية ل J من 4.
والعامل الثاني الذي يساهم في تعيين الوقت المتقدم الذي يمكن تغييره هو وقت الذهاب والعودة الكهربي بين CMTS ومودم الكبلات. تؤثر المسافة المادية بين CMTS ومودم الكبل وتأخير المعالجة الملازم في أجهزة مودم الكبل على هذه القيمة.
تفوض مواصفات DOCSIS ألا يزيد الحد الأقصى لوقت النشر المسموح به بطريقة واحدة بين CMTS وأبعد مودم كبل في النظام عن 800 ميكروثانية. وهذا يعني ضمنا زمن جولة، باستثناء تأخير معالجة مودم الكبل، يبلغ 1600 ميكرو ثانية تقريبا.
وتبلغ سرعة الضوء في الفراغ حوالي 186 000 ميل في الثانية (300 000 كيلومتر في الثانية)، ونسب سرعة انتشار الألياف عادة إلى 0.67. لذلك، فإن الحد الأقصى المسموح به للمسافة باتجاه واحد بين CMTS ومودم الكبل هو تقريبا:
Distance = Velocity * Time = (186,000 miles/sec * 0.67) * 800 microseconds = 100 miles or 161 kilometers.
وفقا لمواصفات DOCSIS، يجب ألا يتجاوز تأخير معالجة مودم الكبل 200 ميكروثانية بالإضافة إلى أي تأخير متداخل للتحميل. ومع ذلك، في حالات نادرة، قد تستغرق بعض العلامات التجارية القديمة لمودم الكبل حتى 300 ميكرو ثانية لمعالجة رسالة MAP. يمكن للأنواع الأحدث من أجهزة مودم الكبلات المزودة بوحدات معالجة مركزية (CPU) أكثر فعالية أن تستغرق ما يصل إلى 100 ميكروثانية لمعالجة رسالة MAP.
بافتراض أن أجهزة مودم الكبلات متوافقة، في المتوسط، مع مواصفات DOCSIS. لذلك، يجب أن يكون الحد الأقصى لوقت الذهاب والعودة 1600 + 200 = 1800 ميكرو ثانية.
غالبية أنظمة الكابلات أقصر بكثير من 100 ميل. لذلك لا يكون من الأفضل ل CMTS أن يفترض دائما أن وقت الذهاب والعودة الكهربي بين CMTS وأبعد مودم كبل هو القيمة القصوى 1800 ميكرو ثانية.
للحصول على تقدير تقريبي لأكبر وقت متوقع لرحلة كهربائية دائرية، أضف مسافة الألياف بين نظام إدارة الكابلات (CMTS) ومودم الكبل وتضرب ب 16 ميكرو ثانية لكل ميل (10 ميكروثانية لكل كيلومتر). ثم أضف مسافة أي كابلات وضرب تلك القيمة بمقدار 12.4 ميكروثانية لكل ميل (7.6 ميكروثانية لكل كيلومتر). ثم أضف تأخر المعالجة 200 ميكروثانية.
على سبيل المثال، قطاع HFC يبلغ طول الألياف فيه 20 ميلا ويحتوي على 1 ميل من التضاريس بين CMTS وأبعد مودم كبل يمكن أن يتوقع تأخير الرحلة الكهربائية ذهابا وإيابا:
20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds = 320 microseconds + 12.4 microseconds + 200 microseconds = 532.4 microseconds
لا يأخذ هذا الرقم في الاعتبار التأخيرات الإضافية الناجمة عن خصائص قناة تدفق البيانات إلى الخادم الخادم وخط البث، والتغيرات في أوقات معالجة المودم. لذلك هذه القيمة غير مناسبة للاستخدام عند حساب وقت تقدم MAP.
هناك طريقة أكثر دقة لتحديد وقت الذهاب والإياب في النظام وهي مراقبة "موازنة التوقيت" لأجهزة مودم الكبلات كما هو موضح في إخراج أمر show cable modem. وكجزء من عملية النطاق التي تستخدمها أجهزة مودم الكبل للحفاظ على الاتصال ب CMTS، يقوم CMTS بحساب وقت الذهاب والإياب لكل مودم كبل. يظهر وقت الذهاب والإياب هذا ك "إزاحة التوقيت" في خرج أمر مودم show cable بوحدات 1/10.24 ميجاهيرتز = 97.7 نانو ثانية تسمى إزاحة التوقيت أو وحدات إزاحة النطاق. لتحويل إزاحة التوقيت لمودم إلى ميكروثانية، قم بضرب القيمة ب 25/256، أو بقسم القيمة تقريبا ب 10.
هنا مثال حيث يتم تحويل عمليات إزاحة التوقيت للعديد من أجهزة المودم في إخراج أمر show cable modem إلى قيمة microSecond:
ملاحظة: تظهر قيمة الميكروثانية بالخط المائل.
uBR7200VXR# show cable modem MAC Address IP Address I/F MAC Prim RxPwr Timing Num BPI State Sid (dB) Offset CPE Enb 00aa.bb99.0859 4.24.64.28 C5/1/U0 online(pt) 16 0.00 2027 0 Y (198μs) 00aa.bb99.7459 4.24.64.11 C5/1/U0 online(pt) 17 1.00 3528 0 Y (345μs) 00aa.bbf3.7258 4.24.64.31 C5/1/U0 online(pt) 18 0.00 2531 0 Y (247μs) 00aa.bbf3.5658 4.24.64.39 C5/1/U0 online(pt) 19 0.00 6030 0 Y (589μs)
وفي هذه الحالة، فإن المودم الأبعد بعيدا كهربائيا هو آخر مودم بإزاحة توقيت مقدارها 6030. وهذا يعادل زمن رحلة الذهاب والإياب 6030 * 25/256 = 589 ميكروثانية.
في نظام تعرف أن طول شبكة HFC أقل بكثير من 100 ميل، يمكنك تكوين CMTS لاستخدام الحد الأقصى من وقت الذهاب والعودة أقل من 1800 ميكرو ثانية القياسي عندما تقوم بحساب زمن تقدم الخريطة.
لإجبار CMTS على إستخدام قيمة مخصصة لوقت الذهاب والعودة في حساب تقدم الخريطة، قم بإصدار أمر واجهة كبل ثابت max-round-trip-time الخاص بخريطة الكبل.
والمدى الأقصى لزمن الذهاب والعودة هو 100 إلى 2000 ميكرو ثانية. إذا لم يتم تحديد قيمة للحد الأقصى لوقت الذهاب والعودة، يتم تطبيق الإعداد الافتراضي من 1800 ميكروثانية.
ملاحظة: يمكنك إستبدال الكلمة الأساسية الثابتة بالكلمة الأساسية الديناميكية. راجع القسم التالي.
تأكد من أن وقت الذهاب والعودة المحدد أكبر بالفعل من أعظم CMTS إلى وقت الذهاب والعودة إلى المودم الكابلي على قناة تدفق البيانات من الخادم. إذا كان لدى مودم الكبل وقت أكبر لرحلة ذهاب وإياب من الوقت المحدد في الحد الأقصى للرحلة، فيمكن للمودم أن يجد صعوبة في البقاء على الإنترنت. وذلك لأن هذا المودم ليس لديه الوقت الكافي للاستجابة لرسالة MAP وبالتالي لا يمكنه الاتصال ب CMTS.
إذا تجاوزت الإزاحة الزمنية لمودم الكبل، المحولة إلى ميكروثانية، الحد الأقصى لوقت الذهاب والعودة المحدد، يتم وضع علامة على المودم بعلامة إزاحة التوقيت غير المناسبة. تظهر علامة الإزاحة هذه كعلامة تعجب (!) بجوار إزاحة التوقيت لمودم الكبل في إخراج أمر show cable modem. يمكن أن يحدث هذا الموقف إذا تم تعيين المعلمة max-round-time time إلى قيمة منخفضة جدا أو إذا كان مودم الكبل يعاني من مشكلة حيث تكون إزاحة التوقيت غير مستقرة وتزداد باستمرار مع مرور الوقت.
فيما يلي مثال:
uBR7200VXR# show cable modem MAC Address IP Address I/F MAC Prim RxPwr Timing Num BPI State Sid (dB) Offset CPE Enb 00aa.bb99.0859 4.24.64.28 C5/1/U0 online(pt) 16 0.00 2027 0 Y (198μs) 00aa.bb99.7459 4.24.64.11 C5/1/U0 online(pt) 17 1.00 3528 0 Y (345μs) 00aa.bbf3.7258 4.24.64.31 C5/1/U0 online(pt) 18 0.00 2531 0 Y (247μs) 00aa.bbf3.5658 4.24.64.39 C5/1/U0 online(pt) 19 0.00 !5120 0 Y (500μs)
في هذا المثال، يتم تحديد الأمر cable map-advance static 500. ومع ذلك، فإن أحد أجهزة مودم الكبلات المتصلة بواجهة الكبل لديه إزاحة توقيت أكبر من 500 ميكروثانية (أي ما يعادل 500 * 256/25 = 5120 وحدة إزاحة توقيت).
لاحظ أن إزاحة التوقيت لآخر مودم كبل مميزة بعلامة إزاحة توقيت غير صحيحة، "!". كما أنها ثابتة على أقصى قيمة مسموح بها وهي 5120 وحدة على الرغم من أن إزاحة التوقيت الحقيقية يمكن أن تكون أعلى بكثير. يمكن أن يصبح مودم الكبل هذا غير متصل ويعاني من ضعف الأداء.
تظل علامة إزاحة التوقيت غير الصحيح مضبوطة لمودم الكبل حتى إذا كانت إزاحة التوقيت أقل من الحد الأقصى لطول الرحلة. الطريقة الوحيدة لمسح الإشارة هي إزالة المودم مؤقتا من قائمة مودم show cable. لهذا، يمكنك إستخدام أمر حذف مسح مودم الكبل mac-address. بدلا من ذلك، يمكنك إعادة ضبط واجهة الكبل أو منفذ الخادم.
لمراقبة تشغيل خوارزمية تقدم الخريطة الثابتة على أساس كل تدفق، قم بإصدار الأمر show controller cable interface-number upstream-number. فيما يلي مثال:
uBR7200VXR# show controller cable 5/0 upstream 0 Cable5/0 Upstream 0 is up Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps This upstream is mapped to physical port 0 Spectrum Group is overridden US phy MER(SNR)_estimate for good packets - 36.1280 dB Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037 Ranging Backoff automatic (Start 0, End 3) Ranging Insertion Interval automatic (60 ms) US throttling off Tx Backoff automatic (Start 0, End 3) Modulation Profile Group 43 Concatenation is enabled Fragmentation is enabled part_id=0x3138, rev_id=0x03, rev2_id=0x00 nb_agc_thr=0x0000, nb_agc_nom=0x0000 Range Load Reg Size=0x58 Request Load Reg Size=0x0E Minislot Size in number of Timebase Ticks is = 16 Minislot Size in Symbols = 128 Bandwidth Requests = 0x6ECEA Piggyback Requests = 0xDE79 Invalid BW Requests= 0x63D Minislots Requested= 0x8DEE0E Minislots Granted = 0x7CE03 Minislot Size in Bytes = 32 Map Advance (Static) : 3480 usecs UCD Count = 289392
يظهر حقل خريطة متقدم (ساكن إستاتيكي) زمن تقدم الخريطة 3480 ميكرو ثانية. إذا قمت بتغيير خصائص تدفق البيانات من الخادم أو المعلمة Max-Round-Trip-time، فإن التغيير ينعكس في قيمة تقدم الخريطة الثابتة.
يتطلب إستخدام حساب MAP المتقدم الثابت لتحسين أوقات تقدم المخطط أن يقوم مشغل CMTS بتحديد أكبر وقت لرحلة ذهاب وإياب يدويا على مقطع الكبل. إذا تغير أي من خصائص قناة تدفق البيانات أو الخادم، أو تغيرت أي من ظروف المحطة، يمكن أن يتغير الحد الأقصى لوقت الذهاب والعودة بشكل كبير. قد يكون من الصعب تحديث التكوين باستمرار لاستيعاب التغيير في شروط النظام.
تحل خوارزمية الخريطة الديناميكية المتقدمة هذه المشكلة. تقوم خوارزمية الخريطة الديناميكية المتقدمة بمسح دوري لقائمة مودم show cable للبحث عن المودم مع أكبر إزاحة توقيت مبدئية لتحديد النطاق، ثم تستخدم تلك القيمة تلقائيا لحساب وقت تقدم الخريطة. وهكذا، يستخدم نظام إدارة الاتصالات دائما أدنى وقت ممكن للخريطة.
إزاحة توقيت النطاق الأولي لمودم الكبل هي إزاحة التوقيت التي يبلغ عنها المودم عند النقطة التي يصل فيها المودم إلى الإنترنت. في معظم الحالات، يكون هذا قريبا من إزاحة التوقيت الجاري كما هو موضح في إخراج أمر show cable modem. ومع ذلك، هناك بعض أنواع أجهزة مودم الكبلات التي تواجه مشكلة عندما تنزلق إزاحة التوقيت لأعلى بمرور الوقت إلى قيم كبيرة جدا. يمكن أن يؤدي هذا إلى تشويه حساب زمن تقدم الخريطة. لذلك يتم إستخدام إزاحة توقيت النطاق الأولي فقط، والتي يتم تحديثها فقط في حالة اتصال المودم بالإنترنت. لعرض إزاحة توقيت النطاق الأولي وإزاحة التوقيت المستمر لمودم الكبل، قم بإصدار الأمر show cable modem verbose. فيما يلي مثال:
uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose MAC Address : 00aa.bbf3.7858 IP Address : 4.24.64.18 Prim Sid : 48 Interface : C5/1/U0 Upstream Power : 39.06 dBmV (SNR = 36.12 dB) Downstream Power : 14.01 dBmV (SNR = 35.04 dB) Timing Offset : 2566 Initial Timing Offset : 2560 Received Power : 0.00 dBmV MAC Version : DOC1.1 QoS Provisioned Mode : DOC1.1 Enable DOCSIS2.0 Mode : Y Phy Operating Mode : tdma Capabilities : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+} Sid/Said Limit : {Max US Sids=16, Max DS Saids=15} Optional Filtering Support : {802.1P=N, 802.1Q=N} Transmit Equalizer Support : {Taps/Symbol= 1, Num of Taps= 8} Number of CPE IPs : 0(Max CPE IPs = 16) CFG Max-CPE : 32 Flaps : 4(Mar 13 21:13:50) Errors : 0 CRCs, 0 HCSes Stn Mtn Failures : 0 aborts, 1 exhausted Total US Flows : 1(1 active) Total DS Flows : 1(1 active) Total US Data : 321 packets, 40199 bytes Total US Throughput : 129 bits/sec, 0 packets/sec Total DS Data : 28 packets, 2516 bytes Total DS Throughput : 0 bits/sec, 0 packets/sec Active Classifiers : 0 (Max = NO LIMIT) DSA/DSX messages : permit all Total Time Online : 1h00m
وفي هذا المثال، فإن موازنة الوقت الجارية (2566) أعلى قليلا من إزاحة توقيت المدى الأولي (2560). يمكن أن تختلف هذه القيم بشكل طفيف. ومع ذلك، إذا كانت القيم تختلف بأكثر من بضع مئات من الوحدات، فقد تكون هناك مشكلة في التحكم في إزاحة التوقيت لمودم الكبل.
لتنشيط حساب تقدم الخريطة الديناميكية، قم بإصدار أمر واجهة كبل خريطة الكبل والتقدم الديناميكي لعامل الأمان max-round-trip-time.
تتراوح معلمة عامل الأمان من 100 إلى 2000 ميكروثانية. ويضاف هذا المعامل إلى الوقت المتقدم في الخريطة لتوفير حماية صغيرة لمراعاة أي تأخيرات غير متوقعة إضافية في نشر الإشارات. القيمة الافتراضية هي 1000 ميكرو ثانية. ومع ذلك، بالنسبة لأنظمة الكبلات المستقرة التي لا تخضع لتغييرات كبيرة في محطة الكبلات أو في خصائص قناة تدفق البيانات إلى الخادم أو إلى الخادم، أستخدم قيمة أقل مثل 500 ميكروثانية.
تتراوح المعلمة Max-round-journey-time من 100 إلى 2000 ميكروثانية. يتم إستخدام هذه المعلمة كحد أعلى للإزاحة الزمنية لأجهزة مودم الكبلات المتصلة بمقطع الكبل. القيمة الافتراضية هي 1800 ميكروثانية. إذا كانت الإزاحة الزمنية لمودم الكبل، المحولة إلى ميكروثانية، تتجاوز الحد الأقصى لوقت الذهاب والعودة المحدد، فإنها تظهر علامة إزاحة توقيت غير صحيح.
قم بتعيين المعلمة max-round-time time time parameter إلى قيمة غير افتراضية عندما تعرف أن طول نظام الكبلات أقل بكثير من 100 ميل، وإذا كنت تعرف ما يجب أن يكون الحد الأقصى للإزاحة العادية لأدوات مودم الكبلات المتصلة بالقسم.
لاحظ تشغيل خوارزمية تقدم الخريطة الديناميكية على أساس كل تدفق باستخدام الأمر show controller cable interface-number upstream upstream-number. فيما يلي مثال:
uBR7200VXR# show controller cable 5/0 upstream 0 Cable5/0 Upstream 0 is up Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps This upstream is mapped to physical port 0 Spectrum Group 1, Last Frequency Hop Data Error: NO(0) MC28U CNR measurement : better than 40 dB US phy MER(SNR)_estimate for good packets - 36.1280 dB Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100 Ranging Backoff Start 3, Ranging Backoff End 6 Ranging Insertion Interval automatic (60 ms) US throttling off Tx Backoff Start 3, Tx Backoff End 5 Modulation Profile Group 41 Concatenation is enabled Fragmentation is enabled part_id=0x3138, rev_id=0x03, rev2_id=0x00 nb_agc_thr=0x0000, nb_agc_nom=0x0000 Range Load Reg Size=0x58 Request Load Reg Size=0x0E Minislot Size in number of Timebase Ticks is = 8 Minislot Size in Symbols = 64 Bandwidth Requests = 0x338C Piggyback Requests = 0x66D Invalid BW Requests= 0xD9 Minislots Requested= 0x756C2 Minislots Granted = 0x4E09 Minislot Size in Bytes = 16 Map Advance (Dynamic) : 2482 usecs UCD Count = 8353
تعرض قيمة إزاحة توقيت Tx أكبر إزاحة توقيت لجميع أجهزة مودم الكبلات المتصلة بالجزء العلوي من وحدات إزاحة التوقيت. أستخدم هذه القيمة لحساب وقت تقدم الخريطة. يظهر حقل خريطة التقدم (الديناميكي) وقت تقدم الخريطة الناتج. يمكن أن تختلف هذه القيمة إذا تغير إزاحة توقيت Tx، أو إذا تم تعديل قيمة السلامة، أو إذا تم تغيير خصائص تدرجية تدفق البيانات.
تعتمد خوارزمية الخريطة الديناميكية المتقدمة على ما إذا كانت أجهزة مودم الكبلات تقوم بالإبلاغ عن إزاحة توقيت النطاق الأولي إلى CMTS بشكل صحيح. لسوء الحظ، يقوم بعض أجهزة مودم الكبلات بكتابة تقارير عن عمليات إزاحة توقيت النطاق الأولي كقيم أقل بشكل ملحوظ من القيمة الحقيقية. يمكنك ملاحظة ذلك عندما تظهر أجهزة المودم إزاحات التوقيت القريبة من الصفر أو حتى القيم السالبة.
رسائل الخطأ المماثلة ٪UBR7200-4-BADTXOFFSET: إزاحة التوقيت غير صحيحة -2 التي تم الكشف عنها لمودم الكبل 00ff.0bad.caf3 يمكن أن تظهر على أجهزة مودم الكبل هذه. لا تقوم هذه الأنواع من أجهزة مودم الكبلات بالإبلاغ عن عمليات إزاحة التوقيت الخاصة بها بطريقة متوافقة مع DOCSIS، ولا يمكن لخوارزمية تقدم الخريطة الديناميكية حساب وقت تقدم الخريطة بشكل صحيح والذي يتم ضمانه لمنح كل مودم كبل الوقت اللازم لتلقي رسائل MAP والاستجابة لها.
إذا كانت أجهزة مودم الكبلات هذه موجودة على مقطع كبل، فقم بتعطيل خوارزمية تقدم الخريطة الديناميكية وارتد إلى خوارزمية تقدم الخريطة الثابتة. راجع لماذا تعرض بعض أجهزة مودم الكبلات إزاحة وقت سالبة؟ للحصول على مزيد من المعلومات.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
03-Apr-2006 |
الإصدار الأولي |