تمارين جودة الخدمة (QoS) بالفيديو

المقدمة

يراجع هذا المستند موضوع جودة مكالمة الفيديو ويوفر تمرينا على الأشياء التي يجب وضعها في الاعتبار أثناء تكوين جودة الخدمة (QoS) على عبارة Cisco Unified Border Element(CUBE) أو عبارة تجميع (TDM) بتقسيم الوقت.

تمت المساهمة من قبل باكثا موراليدهاران، مهندس TAC من Cisco، تحرير أنوب كومار.

المتطلبات الأساسية

المتطلبات

يعد هذا المستند مفيدا للغاية للمهندسين المطلعين على نقل الصوت عبر بروتوكول الإنترنت (VoIP)، رغم أن الآخرين قد يرونه مفيدا.

المكونات المستخدمة

لا توجد أجهزة أو برامج معينة تستخدم لكتابة هذا المستند.

معلومات أساسية

تمثل مجموعة من عينات الصوت بأبسط صورة لها، حيث تصف كل عينة ضغط الصوت خلال تلك الفترة.  يمكن التقاط الصوت التحدثي وإعادة إنتاجه بدرجة عالية من الدقة، مع 8000 عينة فقط في الثانية[1].  وهذا يعني أنه طالما كانت الشبكة قادرة على نقل العينات دون تأخير مفرط وتشوه البيانات وفقد الحزم، فيمكن إعادة إنتاج الصوت بأمانة في الطرف الآخر.

على النقيض من ذلك، معالجة ونقل الفيديو أكثر تعقيدا. السطوع، التباين، تشبع اللون، الاستجابة (للحركة) ومزامنة الشفاه هي بعض الخصائص التي تحدد جودة الفيديو. تتطلب عينات الفيديو بشكل عام مساحة أكبر بكثير. وليس من المستغرب، أن يضع الفيديو طلبا أكبر بكثير على عرض النطاق الترددي للشبكة، على شبكة النقل. يتم تحديد جودة الصوت بواسطة: مكبر صوت الميكروفون في برنامج فك تشفير سماعة الرأس - تتأثر جودة مكالمات فيديو شبكة النقل للضغط ب: توافق/قابلية التشغيل البيني لشبكة نقل فيديو جهاز عرض الكاميرا

ملاحظة: من المهم أن نفهم أنه على عكس الصوت، يحدث شيء ما في نقاط نهاية الفيديو، عندما يتعلق الأمر بضبط الجودة.

الهدف

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

• ضبط نقطة النهاية- تحسين تكوين نقاط النهاية (على سبيل المثال، الدقة، الإطار في الثانية)
• تحسين النقل- تحسين الشبكة لنقل حركة مرور الفيديو لكل شبكة SLA.
• اعتبارات قابلية التشغيل البيني - تتضمن مكالمات الفيديو في كثير من الأحيان نقاط النهاية لقدرات متنوعة. إن تصميم وتهيئة الأنظمة لتحقيق الحد الأقصى من قابلية التشغيل البيني يمكن أن يؤثر على جودة الفيديو.

سيكون التركيز المحدد في هذا المستند على اعتبارات جودة الخدمة على بوابة IOS أو CUBE عند معالجة مكالمات الفيديو.

الضبط عند نقاط النهاية سينطوي على ضبط مجموعة من المعاملات على نقاط نهاية الفيديو. هذا طبعا يعتمد على المنتج ولكن هنا بعض "العقد" العامة :

• دقة الوضوح (أي حجم الصورة)
• معدل الإطارات (مثل حساسية/حقيقة الحركة)
• وضع علامات التمييز (أي وضع علامات على ToS)

يتضمن ضبط شبكة الفيديو بشكل عام الأمور التالية :

• فهم تكوين حركة المرور المتدفقة عبر المكعب - على سبيل المثال حجم [المكالمة] القصوى وما إلى ذلك.
• مراجعة سعة إرتباط/أنبوب الشبكة
• تصميم سياسات جودة الخدمة المناسبة، لضمان تلبية إتفاقية مستوى الخدمة (SLA) لكل فئة من فئات حركة المرور

تلعب قابلية التشغيل البيني دورا عندما تشارك الأنظمة غير المتجانسة (مثل الهواتف المرئية بالإضافة إلى نظام التواجد عن بعد (TP)) في مؤتمر عبر الهاتف. تختلف التجربة التي يوفرها بروتوكول TP ونظام هاتف الفيديو إختلافا جوهريا. ويتحقق التوافق بينها بشكل عام من خلال تقسيمها باستخدام عملية تعرف باسم التتالي.

ما الذي لا يغطيه هذا

هذه الوثيقة ليست وثيقة تصميم وليست وثيقة جودة خدمة فيديو شاملة. على وجه التحديد، لا يغطي هذا المستند هذه الموضوعات:

• إرسال إشارات [بروتوكولات] لمكالمات الفيديو، بالإضافة إلى ما هو مطلوب لتوضيح الجوانب المتعلقة بجودة الخدمة.
• إعداد/تكوين نقطة نهاية الفيديو
• مراجعة شاملة لآليات جودة الخدمة، بما في ذلك وضع السياسات ووضع قوائم الانتظار والتشكيل والانطلاق
• مراجعة تكوين جودة الخدمة على محولات الطبقة 2 أو اعتبارات حدود الثقة.

خصائص حركة مرور بيانات الشبكة للفيديو

الفيديو، مثل الصوت هو الوقت الحقيقي.  الإرسال الصوتي هو معدل البت الثابت (CBR). في المقابل، تميل حركة مرور الفيديو إلى أن تكون مزدحمة ويشار إليها باسم "معدل البت المتغير" (VBR) وبالتالي فإن معدل البت لنقل الفيديو لن يكون بالضرورة ثابتا، إذا كنا بحاجة إلى الحفاظ على جودة معينة[2].

الصورة 1

كما أن تحديد عرض النطاق الترددي والضغط الهائل اللازم لتشغيل مقاطع الفيديو يعد أمرا أكثر أهمية. ستتم مناقشة ذلك لاحقا في هذا المستند.

• حركة مرور الفيديو مزدحمة.
• يمكن أن تكون حزم الفيديو كبيرة جدا.
• الصوت هو دائما CBR. الفيديو هو في العادة VBR. 

لماذا الفيديو مشتعل؟

الجواب يكمن في طريقة ضغط الفيديو. تذكر أن الفيديو هو سلسلة من الصور (إطارات) التي يتم تشغيلها لتوفير تأثير الحركة البصرية. تستخدم تقنيات الضغط المستخدمة من قبل برامج ترميز الفيديو أسلوب يسمى ترميز دلتا[3]، والذي يعمل عن طريق تخزين قيم البايت كفروق (دلتاوات) بين القيم المتسلسلة (العينات) بدلا من القيم نفسها. وبناء على ذلك، يتم تشفير الفيديو (وإرساله) كإطارات متتالية تحمل فقط "الأجزاء المتحركة" بدلا من الإطارات الكاملة.

ربما تتساءلون لماذا ، تغيرات الصوت أيضا تصاعديا ؟ حسنا، صحيح بما فيه الكفاية، ولكن "الحركة" (أو الديناميكيات) لا تؤثر على الصوت بقدر ما تؤثر على الفيديو. لا تضغط عينات الصوت 8-بت بشكل أفضل عندما ترمز دلتا، فإن عينات الفيديو (الإطارات) تفعل ذلك. التغيير النسبي من نموذج (إطار إلى إطار) إلى نموذج فيديو أصغر بكثير من الصوت. طبقا لطبيعة ودرجة الحركة، فإن عينات الفيديو يمكن أن تختلف في الحجم بشكل كبير. الصورة 2 توضح ضغط الفيديو-

الصورة 2

الإطار I هو صورة مشفرة داخليا، في الواقع صورة محددة بالكامل، مثل ملف صورة ثابت تقليدي.

إطار P (الصورة المتوقعة) يحمل التغييرات في الصورة من الإطار السابق فقط. لا يحتاج المرمز إلى تخزين بيكسلات الخلفية غير المتغيرة في إطار P، وبالتالي توفير المساحة. تعرف إطارات P أيضا باسم إطارات دلتا.

الإطار B (صورة ثنائية التنبؤ) يوفر مساحة أكثر باستخدام الفروق بين الإطار الحالي والإطارات السابقة واللاحقة لتحديد محتواه.

قياس جودة الفيديو

لا تقوم أجهزة الفيديو من Cisco بقياس أو الإبلاغ عن جودة الفيديو على هذا النحو، لذلك يتم إدراك جودة الفيديو بدلا من قياسها. وهناك خوارزميات معيارية تقيس الجودة عن طريق درجات MOS (درجة الرأي المتوسط). ومع ذلك، إذا كانت المشاكل التي تم الإبلاغ عنها حول جودة الصوت هي أي مؤشرات، فمن المرجح أن يتم فتح حالات جودة الفيديو (TAC) لأن المستخدم يرى مشاكل في الجودة بدلا من التقارير باستخدام أداة.

عناصر التحكم عند نقاط النهاية

العوامل التي تؤثر على جودة الفيديو تشمل:

• برنامج ترميز الفيديو (MPEG4 و H261 و H263 و H264 و H265)
• الحجم (الشاشة 1/8، الشاشة 1/4، الشاشة الكاملة)
• معدل الإطارات (من 1 إلى 30 إطار في الثانية و 6 إطارات افتراضية)
• إعداد جودة الضغط (منخفض، متوسط، مرتفع)

وبشكل عام، يمكن تحديد كل مما سبق أو التحكم به عند نقاط النهاية.

النتائج المرئية

الطي والتمشيط والخطوط تعتاد على هذه المصطلحات، جزء من تصنيف إعاقات الفيديو. ارجع إلى هذا المستند للحصول على تفاصيل حول اضمحلال الفيديو الشائعة:

المرجع: 

http://www.estadistica.cl/public_disk/Programas/DeTodo/Manejo y pegado de subtitulos/virtualDub-1.6.14/help/p-artifacts.html

  

SLAs لشبكة النقل لجودة الفيديو

إتفاقية مستوى الخدمة (SLA) للشبكة الموصى بها للفيديو[4] هي كالتالي:

• زمن الوصول ≤ من 150 إلى 300 مللي ثانية
• رجفان ≤ 10 ميللي ثانية - 50 ميللي ثانية
• الخسارة ≤ 0.5٪

وبالمناسبة فإن إتفاقية مستوى الخدمة (SLA) الخاصة بالشبكة الموصى بها لنقل الصوت هي:

• زمن الوصول ≤ من 150 إلى 300 مللي ثانية
• رجفان ≤ 20 ميللي ثانية - 50 ميللي ثانية
• خسارة ≤ 1٪

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

عناصر التحكم في شبكة النقل

بشكل عام، يمكن تسليم إتفاقية مستوى الخدمة (SLA) لنقل الفيديو باستخدام سياسات جودة الخدمة (QoS) التي تشبه إلى حد كبير تلك المستخدمة لنقل الصوت. غير أن هناك بعض الاختلافات بسبب طبيعة حركة الفيديو.

  

ملاحظة: على الرغم من أن نطاق هذا المستند مقصور على مكون CUBE، تذكر أن جودة الخدمة هي من نهاية إلى نهاية.

أصناف الفيديو

هل جميع مقاطع الفيديو متشابهة؟ حسنا، ليس تماما. تتضمن تنويعات الفيديو كوسيط ما يلي:

• خدمة الاتصال الهاتفي/مؤتمرات الفيديو
• تفاعلية في الوقت الفعلي
• عرض نطاق ترددي أقل نسبيا. ما يصل إلى 1 ميجابت في الثانية تقريبا
• التواجد عن بُعد
• تفاعلي في الوقت الحقيقي
• تجربة تتعايش معها بكامل حواسك
• تتطلب نطاقا تردديا عريضا مرتفعا جدا
• الدفق
• في الوقت الحقيقي، أحادي الإتجاه
• يمكن أن يكون أحادي البث أو متعدد البث
• عرض نطاق ترددي عال
• غير حساس للتأخير (قد يستغرق الفيديو عدة ثواني للصفوف)
• غير حساس إلى حد كبير للرجفان (بسبب التخزين المؤقت للتطبيق)
• ويجب ألا تكون الخسارة أكثر من 5 في المئة.
• يجب ألا يزيد زمن الوصول عن 4 إلى 5 ثوان (وفقا لإمكانيات التخزين المؤقت لتطبيق الفيديو)
• يمكن أخذ بعض مقاطع الفيديو (مثل الترفيه) في الاعتبار عند تقديم خدمة جمع القمامة.

ملاحظة: توخيا للإيجاز، لا تقدم إيضاحات كثيرة عن كل نوع من أنواع الفيديو المذكورة أعلاه.

برامج تشفير حركة مرور الفيديو

• • تم تصميم H.261-Codec في الأصل للإرسال عبر خطوط ISDN. باستخدام ربط الفيديو، تكون معدلات البت للفيديو مضاعفات 64 كيلوبت/ثانية.
  • H.263 - يتم إستخدام برنامج الترميز في مؤتمرات الفيديو المستندة إلى IP وكذلك في شبكات ISDN. يتطلب H.263 نصف النطاق الترددي لتحقيق نفس جودة الفيديو كما في H.261. ونتيجة لذلك، حل H.263 محل H.261 إلى حد كبير. تم تحسين H.263 لمجموعة كبيرة من معدلات البت وليس مجرد 64 كيلو بت/ثانية مثل H.261.
  • H.264/MPEG-4 - تستخدم cs حاليا أحد أكثر التنسيقات إستخداما وتستخدم معدل البت MPEG-2 أو H.263 أو MPEG-4 الجزء 2.
  • H265 - واحد من عدة خلفيات محتملة ل H.264 المستخدم على نطاق واسع واستنادا إلى توسيع المفاهيم نفسها. وهي تدعم الحلول التي تصل إلى 8192 × 4320 بكسل، بما في ذلك محركات أقراص ثابتة فائقة الدقة بسرعة 8 آلاف لفة في الدقيقة.

ملاحظة: يتم نقل الفيديو، مثل الصوت، في بروتوكول الوقت الفعلي (RTP)

آليات جودة الخدمة للفيديو

ومن حيث المبدأ، فإن آليات جودة الخدمة المستخدمة لتقديم إتفاقات مستوى الخدمة لشبكة نقل الفيديو هي في الغالب نفس الآليات المستخدمة لنقل الصوت. ومع ذلك، هناك بعض الاختلافات التي ترجع في الغالب إلى الطبيعة المتقطعة للفيديو ونقل VBR.

هناك نهجان لجودة الخدمة، وهما الخدمات المترابطة (الخدمات المتكاملة) والخدمات المتباينة (الخدمات المتنوعة).

اعتبر أن Intserv يعمل على مستوى إرسال الإشارات و DiffServ على مستوى الوسائط. بعبارة أخرى، يضمن الطراز InterServ الجودة من خلال العمل على مستوى التحكم، ويهدف DiffServ إلى ضمان الجودة من خلال الاشتراك على مستوى مستوى مستوى التاريخ.

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

هناك أيضا نموذج IntServ/DiffServ، وهو نوع من الخليط. يفصل هذا النموذج عمليات مستوى التحكم عن عمليات مستوى البيانات. تقتصر عملية RSVP على التحكم في الدخول فقط، مع قيام آليات DiffServ بمعالجة عمليات التصنيف ووضع العلامات ووضع السياسات والجدولة. وعلى هذا النحو، يتسم نموذج IntServ/DiffServ بقابلية تطوير عالية ومرونة عالية.

ملاحظة: يركز هذا المستند فقط على أسلوب DiffServ (مخطط تحديد الأولويات من حيث القيمة إلى حيث القيمة).

ضمان عرض النطاق الترددي

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

• برنامج الترميز المستخدم
• معدل الإطارات
• حجم الصورة
• حجم المكالمة (الذروة والمتوسط)

الخدعة القديمة المتمثلة في رمي عرض النطاق على المشكلة ليست دائما الحل. ويصدق هذا بشكل خاص على جودة الفيديو. على سبيل المثال، مع CUVA (ميزة الفيديو الموحد من Cisco) لا توجد آلية مزامنة بين الجهازين (الهاتف والكمبيوتر الشخصي) المعنيين. وبالتالي، يجب تكوين جودة الخدمة للحد من الرجفان وزمن الوصول والحزم المجزأة والحزم الخارجة عن الترتيب.

ملاحظة: يتطلب Interactive Video نفس متطلبات مستوى الخدمة التي يتطلبها VoIP لأن المكالمات الصوتية يتم تضمينها في تدفق الفيديو.يتطلب Streaming Video متطلبات أكثر بساطة بسبب كمية التخزين المؤقت الكبيرة التي تم تضمينها في التطبيقات.

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

تشكيل قائمة الانتظار

قوائم انتظار تقليل التأخير (LLQ) هي سياسة قوائم الانتظار المفضلة لصوت VoIP. ونظرا للمتطلبات الصارمة المتعلقة بالتأخير/الارتجاج الحساسة ل TP والحاجة إلى مزامنة الصوت والفيديو ل CUVA، فإن قائمة انتظار الأولوية (LLQ) هي الموصى بها لجميع حركة مرور الفيديو أيضا. لاحظ أنه بالنسبة للفيديو، فإن أولوية النطاق الترددي يتم تحريكها بشكل عام بنسبة 20٪ لتمثل التكاليف الإضافية.

ضغط الرأس

غير مستحسن للفيديو.

تجزئة ودمج الارتباط

LFI هي آلية شائعة لضمان عدم خروج التردد عن السيطرة على الارتباطات البطيئة، حيث يمكن أن تكون تأخيرات تسلسل مرتفعة.

ولكن مرة أخرى لا ينصح بالفيديو التفاعلي للروابط البطيئة. وذلك لأن LLQ الذي يتم تعيين حركة مرور الفيديو إليه، لا يخضع للتجزئة. وهذا يعني أن حزم الفيديو التفاعلية الكبيرة (مثل إطارات I-Frame كاملة الحركة سعة 1500 بايت) يمكن أن تتسبب في حدوث تأخيرات في تسلسل حزم الفيديو التفاعلية الأصغر حجما.

تجنب الازدحام

تجاهل انتقائي استنادا إلى RTCP

اندفاع

تعتبر آلية جودة الخدمة هذه مهمة لحركة مرور الفيديو التي، كما تمت الإشارة إليه سابقا، مزدحمة.

يمكن تكوين معلمة الاندفاع الاختيارية كجزء من الأمر priority[6].

مع H.264، أسوأ انفجار سيكون الشاشة الكاملة من الفيديو (مضغوط مكانيا). استنادا إلى إختبارات موسعة على أنظمة TP، تبين أن هذه السعة تبلغ 64 كيلوبايت. لذلك ينبغي تكوين معلمة انفجار LLQ للسماح بمعدل اندفاع يصل إلى 64 كيلوبايت لكل إطار لكل شاشة. وهكذا سيتم تكوين نظام CTS-1000 الذي يعمل على معيار 1080p-Best (مع الدعم الاختياري لتدفق فيديو إضافي[7]) باستخدام LLQ بمعيار اندفاع مثالي يبلغ 128 (2x64) كيلوبايت.

كم عرض النطاق؟

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

قرار

هذا يشير أساسا إلى حجم الصورة.  المصطلحات الأخرى شائعة الاستخدام في هذا الصدد تتضمن تنسيق الفيديو وحجم الشاشة.  تظهر تنسيقات الفيديو الأكثر إستخداما أدناه.

تنسيق	دقة وضوح الفيديو (بالبكسل)
SQCIF	128 × 96 بكسل
QCIF	176×144
SCF	256×192
سيف	352×240
CIF	352 × 288 بكسل
DCIF	528x384
4CIF	704×576
16CIF	1408x1152

تعمل الغالبية العظمى من أجهزة مؤتمرات الفيديو بتنسيقات CIF أو 4CIF.

المرجع: http://en.wikipedia.org/wiki/Common_Intermediate_Format

ملاحظة: لا يوجد تكافؤ للتحليل (المرئي) في عالم الصوت

معدل الإطارات

يشير ذلك إلى معدل إنتاج جهاز التصوير لصور متتابعة فريدة تسمى إطارات. يتم التعبير عن معدل الإطارات كإطارات في الثانية (FPS).

ملاحظة: القياس المكافئ في عالم الصوت هو وقت أخذ العينات. على سبيل المثال، 8000 ل g.711ulaw.

حساب النطاق الترددي

تميل عمليات حساب النطاق الترددي لأنظمة الاتصال الهاتفي بالفيديو وأنظمة مؤتمرات الفيديو التقليدية الأخرى إلى أن تكون أكثر بساطة.

على سبيل المثال، تأمل في مكالمة TP ذات دقة تبلغ 1080 × 1920.  يتم حساب النطاق الترددي المطلوب على النحو التالي-

     2،073،600 بكسل لكل إطار

        عدد ألوان x3 لكل بيكسل

        x1 بايت (8 بت) لكل لون

        x 30 إطار في الثانية

        = 1. 5 جيجابت في الثانية لكل شاشة. غير مضغوط!

مع الضغط، فإن نطاق ترددي عريض بمعدل 4 ميجابت في الثانية لكل شاشة ( > 99٪ مضغوط) يكون كافيا لنقل الإطار أعلاه!

يحتوي الجدول التالي على بعض التركيبات-

صورة فورمات	إضاءة بيكسل	إضاءة بنود	غير مضغوط معدل البت (بت/ثانية)
			10 إطارات/ثانية		30 إطار/ثانية
			أشيبي	لون	أشيبي	لون
SQCIF	128	96	1.0	1.5	3.0	4.4
QCIF	176	144	2.0	3.0	6.1	9.1
CIF	352	288	8.1	12.2	24.3	36.5
4CIF	704	576	32.4	48.7	97.3	146.0
16CIF	1408	1152	129.8	194.6	389.3	583.9

لاحظ أن العمليات الحسابية أعلاه خاصة بشاشة واحدة. قد يتطلب إستدعاء TP شاشات متعددة، وبذلك يكون إجمالي النطاق الترددي للمكالمة مضاعفا للنطاق الترددي لكل شاشة.

ارجع إلى https://supportforums.cisco.com/thread/311604 للحصول على حاسبة عرض النطاق الترددي جيدة لأنظمة Cisco TP.

تصنيف/تمييز حركة مرور الفيديو

كيف يتم التعرف على حركة مرور الفيديو/تمييزها؟ تستخدم إحدى طرق تصنيف الحزم على المكعب علامات DSCP.

يوضح الجدول التالي علامات DSCP لكل خط أساس جودة خدمة Cisco بالإضافة إلى RFC 4594.

حركة المرور	طبقة 3 PHB	بروتوكول DSCP للطبقة 3
إرسال إشارات المكالمات	CS3	24
الصوت	EF	46
مؤتمر فيديو	أف 41	34
التواجد عن بُعد	سي إس 4	32
دفق الوسائط المتعددة	أف 31	26
بث الفيديو	سي إس 5	40

PHB - سلوك كل خطوة. يشير إلى ما يقوم به الموجه بالنسبة لوظائف تصنيف الحزمة وتكييف حركة المرور، مثل القياس، ووضع العلامات، والتشكيل، ووضع السياسات.

بشكل افتراضي، وقبل الإصدار 9.0 CUCM (Cisco Unified Call Manager)، تم وضع علامة على أي حركة مرور فيديو وكافة حركات المرور (بما في ذلك التواجد عن بعد) إلى AF41. بدءا من الإصدار 9.0، يقوم CUCM بتكوين قيم DSCP التالية بشكل مسبق:

• مكالمات TelePresence (مقاطع فيديو تتعايش معها بكامل حواسك) في CS4 و
• مكالمات الفيديو (IP Video Telephony) في AF41

التكوين

تتطلب عملية التهيئة لضبط جودة الصوت حساب عرض النطاق الترددي ذي الأولوية وتنفيذ سياسة LLQ على إرتباط شبكة WAN. ويستند ذلك بشكل عام إلى مستوى صوت المكالمة المتوقعة وبرنامج الترميز الصوتي المستخدم.

بالرغم من أن المبادئ متطابقة، إلا أن عرض نطاق الفيديو من خلال مكعب لا يسهل حسابه. ويعود ذلك إلى عدد من العوامل، منها:

• كيف يمكن للمرء حساب عرض النطاق الترددي الإجمالي المطلوب نظرا لأن إستدعاءات TP المختلفة (المتدفقة عبر CUBE) قد تتضمن عددا مختلفا من الشاشات وعلامات دقة مختلفة؟
• الطبيعة المتقطعة و VBR
• هناك بعد آخر للتعقيد [في حساب النطاق الترددي] يتعلق ب "مكالمات قابلية التشغيل البيني"؟  تستخدم إستدعاءات قابلية التشغيل البيني TIP. TIP يمثل بروتوكول قابلية التشغيل البيني لنظام TelePresence. يتم إستخدام TIP لمضاعفة شاشات متعددة ودفقات صوت متعددة، وكذلك شاشة بيانات مساعدة في دفعتين RTP، واحدة للفيديو والصوت. فهو يتيح جلسات عمل من نقطة إلى نقطة ومن نقاط متعددة، فضلا عن مزيج من نقاط النهاية للشاشات المتعددة والشاشات الأحادية. TIP هو بروتوكول Cisco خاص. يستند TIP إلى RTCP.

وبالتالي، يتم أحيانا توفير عرض النطاق الترددي لأنظمة الفيديو بالترتيب العكسي - أي مقدار النطاق الترددي الذي يمكن أن تقدمه شبكة النقل، باستخدام سياسة LLQ، ويتم تحديده أولا واستنادا إلى ذلك، ويتم تكوين نقطة النهاية. أنظمة فيديو النقطة الطرفية ذكية بما يكفي لضبط مختلف معلمات الفيديو لحجم ممر البيانات! وبناء على ذلك، تشير نقاط النهاية إلى الدعوة.

معالجة عرض النطاق الترددي للمكعب

كيف يعالج CUBE النطاق الترددي العريض في عرضه (SIP)/أجوبته عند إرسال إشارات مكالمات الفيديو؟ يقوم المكعب بملء حقول النطاق الترددي للفيديو في SDP كما يلي-

  1. من سمة النطاق الترددي في SDP الوارد. في SDP، هناك سمة النطاق الترددي، والتي تحتوي على معدل يستخدم لتحديد نوع معدل البت الذي تشير إليه القيمة.  تحتوي السمة على النموذج التالي: b=<modifier>:<value>

  2. من عرض النطاق الترددي للفيديو الذي تم تكوينه على المكعب. على سبيل المثال، يتم حساب الحد الأقصى المقدر للنطاق الترددي استنادا إلى الميزات التي يستخدمها مستخدم CTS ويتم تكوين النطاق الترددي المقدر مسبقا على CUBE، باستخدام CLI-

• <معدل طبقات فيديو النطاق الترددي> أو
• <فيديو النطاق الترددي كمعدل>

  3. النطاق الترددي الافتراضي للفيديو (384 كيلوبت/ثانية)

يوضح تدفق المكالمات الموضح أدناه كيفية قيام CUBE بملء النطاق الترددي في رسائل إرسال إشارات المكالمات-

يستخدم المكعب على وجه التحديد المنطق التالي:

• في العروض (لإجراء المكالمات)، يستخدم CUBE النطاق الترددي الذي تم تكوينه.
• قيد التشغيل (إجابات ل EOs)، يرسل CUBE النطاق الترددي الذي تكون قيمته هي الحد الأدنى من العرض والتكوين المحلي.

على مستوى جلسة SDP، تمثل قيمة TIAS الحد الأقصى لحجم النطاق الترددي المطلوب عند إستخدام جميع تدفقات الوسائط المعلنة[8].

أنواع حمولة برنامج ترميز الفيديو

هذا مجال آخر يختلف فيه الفيديو عن الصوت.  تستخدم برامج تشفير الصوت أنواع حمولة ثابتة. على العكس، تستخدم برامج تشفير الفيديو أنواع حمولة RTP الديناميكية، والتي تستخدم النطاق من 96 إلى 127.

يرتبط سبب إستخدام نوع الحمولة الديناميكية بالتطبيق الواسع لمشفرات الفيديو. تحتوي برامج ترميز الفيديو على معلمات توفر جهاز إستقبال بخصائص الدفق الذي سيتم إرساله. يتم تحديد أنواع حمولة الفيديو في SDP، باستخدام المعلمة a=rtpmap. بالإضافة إلى ذلك، يمكن إستخدام السمة "a=fmtp:" لتحديد معلمات التنسيق. سلسلة FMTP معتمة ويتم تمريرها فقط إلى الجانب الآخر.

فيما يلي مثال-

m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

لاحظ أن نقطتي النهاية المشمولتين بمكالمة قد تستخدمان نوع حمولة مختلف للترميز نفسه. يستجيب المكعب لكل جانب مع وجود سطر=rtpmap مستلم على الطرف الآخر. هذا يعني أن التكوين "الحمولة غير المتماثلة full" مطلوب لمكالمات الفيديو للعمل.

النطاق الترددي العريض من المستوى الثاني

على عكس الصوت، تعد حركة مرور فيديو IP في الوقت الفعلي بشكل عام دفق معدل البت المتغير المتقطع إلى حد ما. لذلك فإن الفيديو، على عكس الصوت، لا يحتوي على صيغ واضحة لحساب مصروفات الشبكة لأن أحجام حزم الفيديو وسرعاتها تختلف بالتناسب مع درجة الحركة ضمن صورة الفيديو نفسها. من وجهة نظر مسؤول الشبكة، يتم توفير النطاق الترددي دائما في الطبقة 2، ولكن التنوع في أحجام الحزمة وتنوع وسائط الطبقة 2 التي قد تجتازها الحزم من نهاية إلى نهاية يجعل من الصعب حساب النطاق الترددي الحقيقي الذي يجب توفيره في الطبقة 2. إلا أن القاعدة المحافظة التي تم إختبارها بشكل كامل واستخدامها على نطاق واسع هي توفير عرض نطاق للفيديو بشكل زائد بنسبة 20 في المائة. يغطي هذا الأمر معدل الاندفاع البالغ 10٪ ونفقات الشبكة من الطبقة 2 إلى الطبقة 4.

الرصد/القياس

وكما ذكر سابقا فإن نقاط نهاية الفيديو لا تشير إلى وجود ظاهرة مماثلة. ومع ذلك، يمكن إستخدام الأدوات التالية لقياس/مراقبة أداء شبكة النقل ولمراقبة جودة الفيديو.

فيديو IP SLAs

تقوم الميزة المضمنة في IOS و IP SLAs (إتفاقيات مستوى الخدمة) بإجراء المراقبة النشطة لأداء الشبكة. تختلف عملية فيديو IP SLAs عن عمليات IP SLA الأخرى من حيث أن جميع حركة المرور هي طريقة واحدة فقط، مع مطالبة المستجيب بمعالجة أرقام التسلسل والأختام الزمنية محليا وانتظار طلب من المصدر قبل إرسال البيانات المحسوبة مرة أخرى.

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

تستخدم CiscoWorks IPM (مراقبة أداء IOS) أداة IP SLA Probe و MediaTrace[9] لقياس أداء حركة مرور المستخدم والتقارير.

Cube VQM

تعد ميزة "مراقبة جودة الفيديو" (VQM)، المتوفرة على المكعب، أداة رائعة لمراقبة جودة الفيديو بين نقطتي اهتمام. يتم عرض النتائج على هيئة MOS.

وهذا متوفر من IOS 15.2(1)T والإصدارات الأحدث. لاحظ أن VQM يستخدم موارد DSP.

المرجع

• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a00807ca099.shtml
• http://www.cisco.com/en/US/partner/docs/video/milticomm/h320Bonding.html
• http://www.cisco.com/en/US/docs/solutions/TelePresence_Network_Systems_1.1_DG.pdf
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/qos.html
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/basics.html
• اتصال IP Video-Telephony SRND -
• http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TP_InterOp_v2.html
• http://www.encoding.com/do_you_have_any_information_on_h.264_levels
• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.watchpointvideo.com/pdf/Measuring%20Video%20Quality%20in%20Videoconferencing%20Systems.pdf
• http://www.broadcastpapers.com/whitepapers/Why_IPTV_is_different_from_IP_data_and_VoIP.pdf?CFID=25762102&CFTOKEN=60dc627518f1a19b-3F4F563D-FC97-8A61-6169D8F641750255
• http://en.wikipedia.org/wiki/Video_compression_picture_types
• http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/coding_standards.pdf
• http://www.cs.jhu.edu/~yairamir/cs667/Multimedia/compress.gif
• http://www.wireshark.org/lists/wireshark-users/201003/msg00125.html
• http://www.networkworld.com/news/tech/2002/0923tech.html
• http://www.javvin.com/protocolH263.html
• http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html#GUID-29B155B6-AFC3-4F8B-AC1D-C127C9D797F0

 StartSelection:00000199 EndSelection:00000538