Sans fil : Contrôleurs sans fil de la gamme Cisco 5500

Solution de réseau sans fil unifié Cisco : Guide de déploiement de VideoStream

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Le Réseau sans fil unifié Cisco (CUWN) présente une nouvelle fonction, VideoStream, pour des déploiements à l'échelle de l'entreprise. Cette caractéristique permet à l'architecture Sans fil de déployer le flux vidéo de Multidiffusion à travers l'entreprise vers des clients sans fil. Récompenses de cette caractéristique les inconvénients qui dégradent la livraison visuelle comme les flots et l'échelle de clients dans un réseau d'entreprise. VideoStream fait la Multidiffusion visuelle aux clients sans fil plus fiable et utilisante la bande passante/spectre plus efficacement. Dans un réseau d'entreprise multi-coulant, la caractéristique assigne la priorité au flot et fournit plus d'âge de poids aux flots préférés. Cette caractéristique également garantit la livraison du vidéo aux clients sans fil et refuse le vidéo au nouvel abonnement de client sous l'utilisation lourde de canal.

Conditions requises

La connaissance de la solution LAN de Cisco Unified Wireless.

Composants utilisés

La caractéristique de VideoStream est disponible dans des améliorations de la version de logiciel 7.0with de réseau sans fil unifié Cisco dans la version de logiciel 7.2 de réseau sans fil unifié Cisco. Cette caractéristique est prise en charge sur tous les contrôleurs LAN Sans fil (WLAN) et Points d'accès d'intérieur de plus nouvelle génération (aps). Cette caractéristique n'est pas disponible sur des points d'accès autonome et des Points d'accès extérieurs.

Produits connexes

Matériel et logiciel Sans fil pris en charge

VideoStream est pris en charge sur tous les contrôleurs LAN Sans fil. Ceci inclut le contrôleur de Cisco 5500, le contrôleur de Cisco 4400, le contrôleur de Cisco 2100 et le WiSMs. VideoStream est également pris en charge sur Cisco 2504 autonome et contrôleur de Cisco WiSM-2. IGMPv2 est la version prise en charge sur tous les contrôleurs.

VideoStream est pris en charge sur tous les Points d'accès. Ceci inclut tous les modèles 802.11n des Points d'accès se composant de la gamme 3600 Point d'accès de Cisco Aironet, du Gamme Cisco Aironet 3500 Point d'accès, du Gamme Cisco Aironet 1260 Point d'accès, des point d'accès de la gamme Cisco Aironet 1250, des Points d'accès de Gamme Cisco Aironet 1140 de Cisco Aironet et des Points d'accès de Gamme Cisco Aironet 1040. VideoStream est également pris en charge sur des Points d'accès de Points d'accès de gamme de Cisco Aironet 1240AG* et de séries de Cisco Aironet 1130AG*.

La caractéristique de VideoStream a été introduite dans la version CUWN 7.0 du code de contrôleur et prise en charge sur des versions ultérieures de logiciel contrôleur avec des améliorations.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Théorie d'exécution

Avant d'aller dans des détails au sujet de la caractéristique de VideoStream, certains des déficits du besoin de Multidiffusion de WiFi d'être compris. 802.11n est une technologie du sans fil en évidence discutée pour des déploiements Sans fil d'intérieur. La condition requise également proéminente est vue en service le service multimédia sur un réseau Sans fil d'entreprise, en particulier, vidéo. Le flux vidéo de Multidiffusion sera une solution rentable dans un réseau d'entreprise énorme car l'unicast des services vidéos ne mesurera pas dans couler au niveau de l'entreprise. La Multidiffusion ne fournit aucune reprise de couche de MAC sur des trames de Multidiffusion/émission. Les paquets de Multidiffusion et d'émission n'ont pas un accusé de réception (ACK), et toute la livraison de paquet est meilleur effort. La Multidiffusion au-dessus de la radio avec 802.11a/b/g/n ne fournit aucun mécanisme pour la transmission fiable.

Les déploiements Sans fil d'entreprise sont à interférence encline, utilisation élevée de canal, client incompatible, le bas SNR à la périphérie de la cellule. La livraison visuelle aux clients sans fil est les plus élevés à débits de données obligatoires sur le canal respectif. Il y a également beaucoup de clients partageant le même canal mais a des états de différent canal, des limites d'alimentation et des capacités de traitement de client. Par conséquent, la Multidiffusion ne sera pas un protocole fiable de transmission à tous les clients dans le même canal que chaque client a des états de différent canal comme vu ci-dessous dans le diagramme.

La Multidiffusion Sans fil ne donne pas la priorité au trafic visuel quoique ce soit Point de code de services différenciés (DSCP) marqué par le serveur vidéo. L'application verra une perte de paquets sans l'ACK, et les relances à la livraison seront mauvaises. Afin de fournir les transmissions fiables du paquet de multidiffusion, il est nécessaire que le réseau classifie des files d'attente et des dispositions au moyen de Qualité de service (QoS). Ceci retirera pratiquement la question du manque de fiabilité en éliminant des paquets de baisse et le retard des paquets sur l'hôte en marquant les paquets et en les triant sur la file d'attente appropriée.

Quoique l'adaptation 802.11n se soit accélérée avec le réseau et les clients, la Multidiffusion Sans fil n'a pas pu utiliser les débits de données 802.11n. C'a également été l'un des facteurs pour un mécanisme alternatif pour la propagation Sans fil de Multidiffusion.

Multidiffusion existante

L'implémentation de la Multidiffusion a évolué au-dessus des releases sur CUWN. Avant que le code CUWN 7.0 la représentation de Multidiffusion ait été optimisé et une façon efficace de livrer le trafic de multidiffusion du contrôleur au Point d'accès a été introduit.

Dans ce processus par groupe de multidiffusion est configuré sur le contrôleur pour enregistrer les Points d'accès et pour livrer le paquet de multidiffusion. Cette implémentation a relâché le processus du contrôleur employant l'unicast pour livrer des paquets de multidiffusion à chaque Point d'accès au-dessus d'un tunnel de Protocol de point d'accès léger (LWAPP). Dans cette configuration les parties du réseau sous-jacentes sont utilisées par le contrôleur pour répliquer et livrer le paquet de multidiffusion au Point d'accès. Le contrôleur devient la source multicast pour le groupe configuré LWAPP/CAPWAP et les Points d'accès sont les récepteurs multicasts. Le Point d'accès reçoit des requêtes de Protocole IGMP (Internet Group Management Protocol) du routeur et des paquets de multidiffusion en amont avec une adresse IP source du contrôleur associé. Ceci améliore la représentation de Multidiffusion considérablement. La requête IGMP est envoyée à ses membres et clients, continue ainsi à mettre à jour la base de données.

La configuration de surveillance IGMP a également introduit une meilleure livraison de Multidiffusion des paquets. Les requêtes d'un voisin en amont de routeur de Multidiffusion sont répondues avec un rapport IGMP basé sur la configuration de groupe sur le contrôleur. Une seule identification groupe de Multidiffusion (MGIDs) est créée par le contrôleur des rapports IGMP après avoir vérifié les adresses de multidiffusion L3 et le nombre VLAN, et met à jour un rapport IGMP au commutateur ou au voisin de l'en amont L3. Le contrôleur envoie les états avec l'adresse source car l'adresse d'interface sur laquelle les états sont reçus des clients. Une table MGID est créée ou mise à jour sur le Point d'accès avec les adresses MAC de client.

Quand le contrôleur reçoit une Multidiffusion joignez la réponse pour un groupe particulier il en avant à tous les Points d'accès dans le groupe. Cependant, seulement ces Points d'accès qui ont les clients actifs abonnés à ce groupe de multidiffusion pour envoyer le trafic de multidiffusion. Le trafic de multidiffusion circule au client le plus élevé à débit de données obligatoire comme vu dans la capture. Le client a associé au Point d'accès au débit 802.11n sur une radio 5GHz.

cuwns-vidstrm-guide-01.gif

VideoStream

VideoStream fournit l'utilisation de bande passante efficace en enlevant la nécessité d'annoncer des paquets de multidiffusion à tous les WLAN sur AP sans se soucier s'il y a un client joint à un groupe de multidiffusion. Afin de venir à bout cette limite, AP doit pouvoir envoyer le trafic de multidiffusion à l'hôte par l'intermédiaire de l'expédition d'Unicast, seulement sur le WLAN que le client est joint et faites ainsi au débit de données que le client est joint à. Avant que VideoStream soit configuré, vous devez comprendre à un haut niveau comment il diffère du déploiement normal de Multidiffusion (Multidiffusion/émission).

VideoStream, pour la première fois dans un système sans fil, fournit une approche sans couture pour que les ingénieurs conçoivent et pour implémentent une solution de Multidiffusion sans détruire la bande passante entre le contrôleur et le commutateur ou le routeur en amont.

La technologie de Cisco VideoStream est un ensemble de fonctionnalités large de nouveau système du réseau sans fil unifié Cisco qui incorpore certaines des améliorations-clé pour fournir la qualité vidéo supérieure. Cisco VideoStream présente le rf et l'expertise visuelle de Cisco pour fournir une plate-forme fiable et cohérente pour tous les différents types de vidéo. Ceci prend en compte l'examen médical, le MAC, et les couches application du RÉSEAU LOCAL Sans fil. Les sections suivantes mettent en valeur certaines des caractéristiques de VideoStream et comment les caractéristiques améliorent seulement la livraison du vidéo au-dessus du WiFi et la qualité de l'expérience utilisateur. Un schéma de réseau simple pour VideoStream est affiché ici pour expliquer les concepts qui sont introduits.

cuwns-vidstrm-guide-02.gif

L'introduction à l'écoulement de processus pour VideoStream le rendra facile de comprendre les sections à venir de la description de la fonction. L'écoulement de processus introduira également les modules tels que l'admission de flot, la hiérarchisation de flot, le contrôle par radio de réservation, Multidiffusion-à-unicast, et l'AutoQoS.

cuwns-vidstrm-guide-03.gif

VideoStream peut être activé globalement sur le contrôleur. La caractéristique peut être activée au niveau par radio (2.4 gigahertz et 5 gigahertz) et au niveau WLAN ou SSID, et fournit plus de contrôle à l'administrateur pour identifier les flux vidéos spécifiques pour le traitement préférentiel de qualité de service.

Admission et hiérarchisation de flot

Comme plus tôt mentionné tandis que le vidéo est des moyens de communication efficaces et à haute impression, c'est également très bande passante intensive, et comme est vu, non tout le contenu vidéo est donné la priorité les mêmes. D'une discussion plus tôt il est clair que les organismes investissant dans le vidéo ne puissent pas se permettre d'avoir la bande passante de réseau non consommée sans aucune hiérarchisation des medias critiques.

L'admission de flot autorisera l'administrateur réseau pour avoir le contrôle de tout le flux vidéo de Multidiffusion dans le réseau. L'admission de flot facilitera l'administrateur réseau pour utiliser les modèles prédéfinis pour des flots de Multidiffusion d'entrée. Il y a peu de modèles prédéfinis pour des bandes passantes de flot de 300Kbps, de 500Kbps, de 1Mbps, de 3Mbps et de 5 Mbits/s. Les administrateurs réseau avec moins d'expérience de vidéo peuvent utiliser les modèles prédéfinis.

cuwns-vidstrm-guide-04.gif

cuwns-vidstrm-guide-05.gif

Il est nécessaire pour avoir une compréhension de base de streaming vidéo caractéristique avant de configurer. Par exemple, considérez les deux configurations ci-dessus. Si le débit binaire visuel est autour de 4Mbps vous devez ajouter manuellement les configurations au lieu de l'utilisation l'une des au-dessus de deux modèles. Si Stream-Less3Mbps est utilisé, la qualité du vidéo sera les images vidéo manquantes dues du mauvais. On l'observe qu'il y a de pixelation du gel visuel et constant du vidéo sur un client sans fil. Si Stream-Less5Mbps est utilisé, le nombre de clients visuels sera moins comme chaque client sans fil est garanti de 5Mbps tandis que le débit binaire visuel est des bits seulement 4 M. Si vous aviez dix clients de la radio I la bande passante d'agrégat de client devrait être autour de 40Mbps. Utilisant le Stream-Less5Mbps le contrôleur utilisera 50Mbps, par conséquent privant 3 clients sans fil du vidéo.

La priorité de flot peut configurer le flux multimédia avec la priorité différente basée sur l'importance dans le réseau d'entreprise. La priorité RRC est livré de la lire seulement quand il y a un encombrement ou un conflit au point d'accès sans fil.

cuwns-vidstrm-guide-06.gif

Quand il y a un encombrement et il y a trop de Multidiffusion de vidéo coule et des clients, le flot 4 a la priorité au-dessus du reste des flots configurés. Le flux vidéo configuré aura une priorité plus basse que la Voix, et une haute priorité que le trafic de meilleur effort. Tout l'autre trafic de multidiffusion sera admis comme trafic de meilleur effort quoiqu'ils soient marqués pour QoS pour la priorité visuelle.

Contrôle de RSVP

Car de plus en plus les utilisateurs commencent à utiliser le vidéo dans le lieu de travail sur des points finaux de WiFi, la capacité avec élégance de gérer et mesurer une expérience continue et et de haute qualité pour des groupes de fluctuation d'utilisateurs à un moment donné ou l'emplacement est essentiel. Le contrôleur et les Points d'accès ont un algorithme crucial de prise de décision, c'est le contrôle de RSVP (RRC) fournit des capacités améliorées pour gérer des contrôles d'admission et de stratégie. L'admission et les décisions politiques sont prises basé sur les mesures de ressource par radio, la mesure de statistiques du trafic, et les configurations de système. Le contrôleur initie des demandes RRC aux Points d'accès pour l'IGMP se joignent. Le Point d'accès traitera la demande de tous les paramètres répertoriés dans ce diagramme :

cuwns-vidstrm-guide-07.gif

Dans la réponse ci-dessus tous les paramètres ont passé la configuration de politique sur le contrôleur. La demande de jonction IGMP du client sur ce Point d'accès sera admise. Si la demande RRC avait une réponse comme affiché ci-dessous, la demande de jonction sera étudiée et l'algorithme RRC sera vérifié la configuration de politique de nouveau. Le client sera admis mais en tant que client de meilleur effort. Cependant, sur plusieurs tentatives de contrôle RRC on l'admettra avec une meilleure priorité de QoS.

cuwns-vidstrm-guide-08.gif

RRC est initié sur un client à IGMP se joint à un flot et peut être configuré pour le contrôle périodique. En raison de en change dans la caractéristique Sans fil si la réponse métrique RRC varie considérablement le client sera refusée au flot.

cuwns-vidstrm-guide-09.gif

RRC assure la protection de bande passante pour le client visuel en refusant les demandes qui entraîneraient la sursouscription. L'utilisation de la Manche est utilisée comme mesure pour déterminer la capacité et pour exécuter le contrôle d'admission. La figure 4 montre comment RRC fonctionne. L'intégration avec la Voix CAC garantit la priorité de qualité vidéo et de Voix.

Multidiffusion à Unicast

En activant les débits de données 802.11n et en fournissant la correction d'erreurs de paquet, Multidiffusion--unicast aux capacités de Cisco VideoStream améliorez la fiabilité de fournir le streaming vidéo au-dessus de Wi-Fi au delà des caractéristiques de meilleur effort des réseaux Sans fil traditionnels.

Une application de client sans fil s'abonne au Protocole IP Multicast un flot en envoyant un IGMP joignent le message. Avec la Multidiffusion fiable, cette demande est pillée par l'infrastructure, qui collecte des données des messages IGMP. Les contrôles du système l'abonnement et la configuration de flot, collecte alors des mesures et des stratégies de trafic pour le flot demandé. Si on permet le flot demandé par les stratégies, une réponse est envoyée au client sans fil relié au Point d'accès afin d'initier la Multidiffusion fiable une fois que le flot arrive. Le système recherche également la bande passante disponible et les mesures configurées de flot pour déterminer s'il y a assez de diffusion pour prendre en charge le nouvel abonnement. En outre, le système considère le chargement actuel sur la radio et les santés des medias avant de prendre la décision d'admission. Après tout les critères ci-dessus sont remplis, une réponse de jonction est envoyés au Point d'accès. C'est quand le Point d'accès réplique la trame de Multidiffusion et la convertit en trames de monodiffusion de 802.11. En conclusion, un service fiable de Multidiffusion livre le flux vidéo comme unicast directement au client.

Une évolution visuelle plus élevée sur des clients

Augmentations dans le nombre de clients accédant au vidéo au-dessus de la pression accrue par endroit de WiFi et la demande sur le réseau. Ceci affecte la représentation et la qualité. Une évolution visuelle plus élevée est une mesure du nombre de clients pris en charge par contrôleur tout en optimisant la circulation du de câble au réseau Sans fil. Avec la technologie de Cisco VideoStream, toute les réplication est faite à la périphérie (sur le Point d'accès), de ce fait utilisant le réseau global efficacement.

À tout moment, il y a seulement le flux multimédia configuré traversant le réseau, parce que le flux vidéo est converti en unicast aux Points d'accès basés sur les demandes IGMP initiées par les clients. Quelques autres réalisations de constructeur font une conversion semblable de Multidiffusion à l'unicast, mais la font inefficacement comme démontré par le chargement mis sur le réseau câblé pour prendre en charge le flot.

Théoriquement dans un réseau non-802.11n avec les clients 2.4GHz et 5GHz associés, là peuvent être autant d'en tant que 3 ou 4 clients observant un flux vidéo de 5M. Avec tous les clients visuels supplémentaires, l'utilisation de canal maxed et la possibilité des clients relâchant ou perdant la Connectivité est plus élevée.

Avec le réseau 802.11n l'évolutivité des augmentations de clients sensiblement dues à la Disponibilité de la bande passante. L'évolutivité de client des clients avec ou sans le canal collant également varie dans le réseau 802.11n. C'est inexistant dans un existant/non un réseau 802.11n.

Concepts

Maintenant vous devriez avoir une compréhension sur la fonctionnalité d'infrastructure quand VideoStream est configuré. Il est également important de comprendre comment les applications vidéo, les périphériques de client, etc. contribuent pour une meilleure synergie pour que le système fonctionne. On l'a observé dans toutes les applications Sans fil d'installation et les clients ont un rôle égal à jouer pour une livraison de bout en bout.

Applications

Il y a d'aujourd'hui disponible de diverses applications vidéo pour le streaming vidéo au-dessus du réseau IP. La source de flux vidéo est commune à travers les réseaux de câble et Sans fil. Le contrôleur est au centre ou la distribution du réseau câblé dans le chemin en tant que dernier journaliste pour le réseau multicast. Certaines des applications vidéo qui ont été testées avec VideoStream sont discutées dans les sections suivantes.

  • Engine d'expérience multimédia de Cisco

  • Applications de distribution de contenu Cisco

  • Serveur/services de Windows Media

  • VBrick ? Appliance H.264

  • Four visuel

  • Lecteur VLC

Engine d'expérience multimédia de Cisco

L'engine d'expérience multimédia de Cisco (MXE) 3500 est une appliance facilement déployée qui intègre d'une manière transparente dans le réseau pour fournir un riche collection de capacités de traitement multimédia. Conçu comme principal composant du réseau Support-prêt de Cisco, Cisco MXE 3500 fournit :

  • Complet vivent et les services basés sur de transcodage de vidéo sur demande (VoD) qui te permettent pour partager le contenu vidéo à travers votre réseau à pratiquement n'importe quel type de point final

  • Caractéristiques innovatrices de postproduction qui transforment le contenu vidéo ordinaire en sortie renversante de studio-qualité

  • Services tranchants de transcription de discours-à-texte

  • Collaboration innovatrice avec d'autres applications fournies par la suite de Cisco des Produits de medias

Le résultat est une plate-forme puissante de traitement multimédia qui permet aux administrateurs informatiques pour rationaliser de manière significative des coûts d'exploitation associés avec la diffusion multimédia, la production de medias, et la distribution vivantes.

Application de la livraison de contenu de Cisco

Les Applications de distribution de contenu Cisco sont les éléments de logiciel des CD et implémentent des processus satisfaits sur des engines de la livraison de contenu de Cisco, telles que lequel fournit des fonctions ingèrent, mémoire, mise en cache, personalization, et couler. La TV coulant des applications de la livraison incluent :

  • Application Cisco Vault

  • Cisco TV Streamer Application

  • Application Cisco TV Playout

  • Application Cisco Integrated Streamer-Vault

  • Gestionnaire de système de livraison de contenu Cisco

L'Internet coulant des applications de la livraison de contenu incluent :

  • Application Cisco Internet Streamer

  • Application d'acquisition de contenu Cisco

  • Application de routeur de service Cisco

  • Gestionnaire de système de livraison de contenu Cisco

Le système de la livraison de contenu de Cisco comporte un ou plusieurs engines en réseau de la livraison de contenu de Cisco, chacun optimisé pour un ou plusieurs tâches telles que le contenu ingèrent, mémoire, mise en cache, ou couler.

Serveur de Windows Media

Le serveur de Windows Media coule l'audio numérique et le contenu vidéo aux clients au-dessus de l'Internet ou d'un intranet. Ces clients peuvent être d'autres ordinateurs ou périphériques qui lisent de retour le contenu utilisant un lecteur, tel que des Windows Media Player. Ou, ils peuvent être d'autres ordinateurs qui sont des services de Windows Media courants (appelés les serveurs de Windows Media) ce proxy, cachent, ou redistribuent le contenu.

Le contenu que vos flots de serveur de Windows Media aux clients peuvent être un flot vivant ou un fichier de supports numériques pré-enregistré. Les sociétés Sans fil qui fournissent des services de loisirs de haut débit sans fil à l'aide des serveurs extensibles et dignes de confiance de Windows Media utilisent des serveurs multimédias.

  • Diffuseurs d'Internet qui fournissent le contenu pour la radio, la télévision, le câble, ou le satellite.

  • Distributeurs de film et de musique qui distribuent le contenu audio et vidéo d'une manière sécurisée sans mise en mémoire tampon ou encombrement de réseau excessive.

  • Professionnels IPTV qui fournissent une expérience de la haute qualité IPTV sur des réseaux locaux (réseaux locaux).

VideoFurnace

Le four de Haivision fournit un sécurisé, facile à utiliser, simple pour déployer le système de bout en bout pour la vidéo en direct encodante et de distribution dans des ordinateurs et des boîtiers décodeur, parce que créer les canaux programmés de lecture pour l'entreprise TV et la signalisation, et pour enregistrer la vidéo sur demande satisfaite et livrante.

Le four fournit une solution vidéo complète IP. L'expérience de visionnement pour accéder aux canaux vivants et enregistrés aussi bien que le contenu sur demande est donnée pour l'appareil de bureau par le lecteur incorporé « d'empreinte de pas zéro » et aux moniteurs et aux affichages fixes par le boîtier décodeur de Stingray?. Avec le contrôle de grain correct de tous les visualiseurs et affichages, le four est le système idéal pour le vidéo gérant et de distribution d'entreprise sécurisé, pour établir la signalisation HD dans toute une installation, pour fournir le contenu sur demande, et pour capturer, organiser, et passer en revue des événements.

H.264 de bout en bout, le four fournit des capacités de bout en bout sans couture. Le serveur portail de four contrôle la distribution directe et sécurisée du vidéo écart-type et HD H.264 et du MPEG-1, MPEG-2, vidéo écart-type MPEG-4 dans le lecteur incorporé et le boîtier décodeur de pastenague. Les supports de gestionnaire de lecture de four ont programmé des canaux pour vivent et le vidéo pré-enregistré IP annonce et signalisation numérique. Le serveur multimédia de four active la vidéo sur demande. Accroissant les efficacités de la compression vidéo H.264, le support de haute définition est à la disposition de tous les utilisateurs. En outre, le four incorpore le soutien direct des encodeurs révolutionnaires de Barracuda? et de Makito? H.264 de Haivision fournissant le contenu vivant écart-type et HD aux débits binaires de 150 Kbps à 15 Mbits/s.

Planification de cellules

La planification de cellules est un aspect clé qui doit être considéré pour un vidéo ou un déploiement vocal. La planification de cellules n'est pas aussi simple que montant un Point d'accès dans une localisation adaptée et fournissant la connexion sans fil. Ceci a changé au cours des dernières années pendant que la couverture Sans fil dominante est devenue une condition requise. Il y a d'aujourd'hui disponible de plusieurs outils pour exécuter une planification appropriée de cellules. Le Système de contrôle sans fil Cisco a un outil de planificateur qui est très efficace.

Sans compter que des critères Sans fil normaux de planification il y a quelques plus de paramètres qui ont besoin considéré dans la planification de cellules pour le vidéo. Ce sont la latence, le jitter et la perte de paquets. Mettant en valeur la même chose dans la table ci-dessous et également classant la même chose par catégorie avec des valeurs réalistes de champ, vous pouvez voir que la planification de cellules est très efficace.

  Latence Jitter Débit Perte de paquets
Téléconférence vidéo Haute Haute Bas Support
Téléconférence vidéo HD Haute Haute Haute Haute
Vidéo sur demande Bas Bas Support Bas
Streaming vidéo vivant Support Support Support Haute

Afin de mesurer l'application vidéo en termes de valeurs, cette table a été reconnaissent largement pour des applications vidéo :

Mesure Collaboration visuelle Signalisation numérique TelePresence Surveillance vidéo
Latence (sec) 150 200 150 300
Jitter 30 10 10 10
Perte de paquets (%) 1% .05% .05% .05%

Considérez un Point d'accès de Cisco CAPWAP installé avec la dernière version du code dans un environnement de test propre sans l'interférence dans un environnement de bureau. Quand le débit, la force du signal et le bruit d'association de client sont mesurés à de divers points les données regardent comme suit. Les mesures ci-dessous sont capturées avec la liaison de canal et sans liaison de canal. Observez la force du signal et le bruit dans tous les scénarios de test. Ceci te donnera une compréhension de base de la variation du signal et du bruit. Les instructions de planification ne sont pas basées sur les deux valeurs considérées, mais prennent en compte également l'interférence de co-canal, des débits de données de client, puissance de transmission de client, capacité de canal totale. Ceux-ci prévoiront des considérations quand la densité de Point d'accès et le compte de client augmentent.

5Ghz avec la liaison de la Manche

Distance du Point d'accès (pi) Débit d'association de client (Mbits/s) Force du signal (- dbm) Bruit (- dbm)
5 276 42 72
20 250 44 75
40 243 47 77
80 216 59 89
100 198 64 90

5Ghz sans liaison de canal

Distance de Point d'accès Débit d'association de client Force du signal Bruit
5 144 41 71
20 144 51 79
40 130 55 81
80 108 60 90
100 87 77 93

radio 2.4Ghz sans liaison de canal

Distance de Point d'accès Débit d'association de client Force du signal Bruit
5 144 30 61
20 144 32 62
40 121 49 77
80 108 53 80
100 84 56 88

La configuration du contrôle d'admission d'appel (CAC) arrête le surabonnement du canal et garantit la bande passante configurée de medias. La configuration CAC arrêtera également de nouveaux utilisateurs de medias, par conséquent sauvegarde les utilisateurs courants d'être affectée quand oversubscribed.

Les configurations CAC pour VideoStream est un point de accord de clé qui équilibre les utilisateurs de Voix, de vidéo et de données sur un support Sans fil utilisant le réseau sans fil unifié Cisco 7.0. Cette configuration est la particularité par radio et peut être activée sur des radios 2.4 gigahertz et 5 gigahertz. La configuration CAC peut être activée en cliquant sur la RADIO > le 802.11a/n ou le 802.11b/g/n > les medias.

cuwns-vidstrm-guide-10.gif

Par défaut la Voix et des configurations visuelles CAC sont désactivées. Toutes les configurations qui sont faites ici s'appliqueront directement aux configurations de Voix et de vidéo. En bref, medias =Voice+Video. C'est par défaut configuré à un maximum de 85% de toute la bande passante par radio. L'autre 15% de la bande passante par radio est le trafic de meilleur effort (données). Selon l'utilisation des données, de la Voix et du vidéo il est recommandé pour changer ces valeurs. Les configurations de medias peuvent être changées en cliquant sur l'onglet de medias. Il est recommandé pour mettre à jour des valeurs par défaut jusqu'à ce qu'il y ait une nécessité absolue pour changer ces valeurs.

Les configurations de Voix et de vidéo peuvent être accordées ont basé sur le type de services réseau fournis. Si la Voix est l'application principale dans le réseau les valeurs CAC peuvent s'étendre de 5 - 85%. Il y a également une bande passante réservée d'itinérance qui est incluse dans la configuration ci-dessus de Voix. Avec une configuration maximum CAC de 85% sur une radio 5Ghz, le système sans fil peut faciliter environ 21 communications voix. De même sur une radio 2.4Ghz avec une configuration maximum CAC de 85%, le système peut faciliter environ 13 communications voix.

Sur une note semblable si vous commutez à un vidéo CAC, avec un maximum de 85% le système sans fil peut rendre service à environ 22 clients sur une radio 5Ghz. Avec une configuration maximum CAC de 85% sur une radio 2.4 gigahertz, le système sans fil peut rendre service à 10 clients. La table ci-dessous donnera une idée de le comment les systèmes peuvent agir sous différentes configurations. Ces valeurs sont avec la liaison de canal sur la radio 5Ghz et une configuration visuelle de débit binaire des bits de 3M.

Valeur visuelle CAC Clients visuels Appel vocal Valeur de la Voix CAC
85 22 0 0
65 15 6 20
45 10 11 40
25 5 16 60
5 2 20 80

Remarque: Ces résultats de test sont documentés pour CUWN 7.2 après l'amélioration de l'agrégation, de la mise en mémoire tampon et de l'établissement du programme intelligent des paquets visuels au client.

Valeur visuelle CAC Valeur de la Voix CAC Débit binaire visuel Clients
85 0 1.5 ~2 M 51
85 0 5M 30
85 0 10m 20

Remarque: Tous les clients dans le test sont semblables dans la configuration avec un adaptateur de radio 3X3 802.11a/b/g/n. L'environnement de test est clair de tous les interférences et également interferers Sans fil de non-WiFi.

Les radios sont capables de manipuler 255 associations. Puisque le support Sans fil est support bidirectionnel-alterné partagé il y aura conflit par les clients. Pendant que les clients se déplacent plus loin de la radio, le débit diminue. Promouvez en bas de la périphérie de la cellule que les débits de données de client chute au plus bas, et avez par conséquent introduit trop de relances. Quoique la radio puisse permettre un nombre supérieur d'associations, elle est recommandée de limiter les clients à moins de 60 par Point d'accès pour des applications de données normales. Cependant, quand vous avez la Voix et les services vidéos sur le Point d'accès il est recommandé pour prévoir l'affichage de Point d'accès tels que la force du signal d'adaptateur de client ne tombe pas ci-dessous -60db ou débit équivalent d'association de client. En outre, envisagez de fournir une cellule de 15~20% superposant pour s'assurer qu'il y a transfert sans heurt de l'application vidéo d'un Point d'accès à l'autre quand les clients errent.

Qualité de service

Normalement, tout le vidéo accueillant des sources s'assurent que le repérage de DSCP est convenablement marqué du côté de câble. Si le serveur vidéo se trouve localement et ne doit traverser aucune périphéries du routeur, des paquets marqués par DSCP sont garantis pour être identiques. Parfois quand les paquets visuels traversent des bornes conduites, les marquages de DSCP tendent à être remis à l'état initial. CUWN s'assure que les paquets visuels ont le DSCP correct marquant du côté Sans fil. Ceci peut être observé sur le Point d'accès car les compteurs visuels de file d'attente incrémenteront. S'il n'y a aucun trafic visuel et seulement du trafic de meilleur effort, les compteurs respectifs incrémenteront. Toute les exécution discutée sera efficace seulement si le profil visuel sur le contrôleur est tracé au protocole 802.1p avec une valeur étiquetée de 5.

cuwns-vidstrm-guide-11.gif

Configuration

VideoStream peut être déployé sur un réseau de câble et Sans fil au niveau de l'entreprise existant. L'implémentation et les coûts de maintenance globaux d'un vidéo au-dessus de réseau Sans fil sont considérablement réduits. La supposition est que le réseau câblé est multidiffusé activé. Afin de vérifier qu'une distribution ou un commutateur d'accès fait partie du réseau de la couche 3, connectez une machine cliente au switchport et la vérifiez si la machine cliente peut joindre un flux de Multidiffusion.

Affichez le passage | incluez la Multidiffusion affichera si la Multidiffusion est activée sur le commutateur de la couche 3. Sinon activé pour la Multidiffusion vous pouvez activer la Multidiffusion en ajoutant la commande suivante sur le commutateur.

cuwns-vidstrm-guide-conf0.gif

cuwns-vidstrm-guide-conf1.gif

Selon le type de configuration indépendante du routage de Protocol (PIM) sur le réseau câblé, le commutateur de la couche 3 est configuré pour le mode intermédiaire PIM ou le mode dense PIM. Il y a également un mode hybride, le mode clairsemé-dense PIM qui est très utilisé.

cuwns-vidstrm-guide-conf2.gif

Les interfaces d'igmp de show ip afficheront les interfaces SVI qui participent à l'adhésion IGMP. Cette commande affichera également la version d'IGMP configuré sur le commutateur ou le routeur. L'activité IGMP sur l'interface peut également être vérifiée sous forme de se joint et des feuilles par les clients.

cuwns-vidstrm-guide-conf3.gif

La configuration ci-dessus peut être vérifiée en exécutant la commande de show ip mroute sur le commutateur de la couche 3.

cuwns-vidstrm-guide-conf4.gif

La capture ci-dessus a certaines entrées lesquelles devez être examiné. La notation spéciale de (source, groupe), a prononcé « S, G » où la source « S » est l'adresse IP source du serveur multicast et « G » est l'adresse de groupe de multidiffusion qu'un client a invitée pour se joindre. Si le réseau a beaucoup de sources vous verrez dans des vos Routeurs (S, G) pour chacune de l'adresse IP source et des adresses de groupe de multidiffusion. Cette capture a également les informations du sortant et des interfaces entrantes.

Matériel et logiciel Sans fil pris en charge

VideoStream est pris en charge sur tous les contrôleurs LAN Sans fil. Ceci inclut le contrôleur de Cisco 5500, le contrôleur de Cisco 4400, le contrôleur de Cisco 2100 et le WiSMs. VideoStream est également pris en charge sur Cisco 2504 autonome et contrôleur de Cisco WiSM-2. IGMPv2 est la version prise en charge sur tous les contrôleurs.

VideoStream est pris en charge sur tous les plus nouveaux Points d'accès. Ceci inclut des modèles des Points d'accès de Gamme Cisco Aironet 3500 Point d'accès, de Gamme Cisco Aironet 1260 Point d'accès, de point d'accès de la gamme Cisco Aironet 1250, de Cisco Aironet 1240AG de gamme, des Points d'accès de Gamme Cisco Aironet 1140, des Points d'accès des séries de Cisco Aironet 1130AG et des Points d'accès de Gamme Cisco Aironet 1040.

La caractéristique de VideoStream est introduite dans la version CUWN 7.0 du code de contrôleur et prise en charge sur des versions ultérieures de logiciel contrôleur.

Configuration de contrôleur

La caractéristique de VideoStream exige la Multidiffusion activée sur le contrôleur. La Multidiffusion sur le contrôleur peut être activée en deux modes : Multidiffusion-unicast et Multidiffusion-Multidiffusion. Quand le Protocole IP Multicast est activé, le contrôleur a livré des paquets de multidiffusion aux clients Sans fil de RÉSEAU LOCAL en tirant des copies des paquets de multidiffusion, alors en expédiant les paquets par un tunnel de Protocol de point d'accès léger d'unicast à chaque Point d'accès connecté au contrôleur. La livraison d'Unicast place une charge lourde sur AP, aussi bien que l'unité de traitement réseau du contrôleur, due au déluge des paquets qui doivent être répliqués vers le bas vers les Points d'accès.

La méthode de la livraison de Multidiffusion-Unicast de Cisco est utilisée généralement par les clients que « seulement » voulez pour fournir la Multidiffusion au-dessus de leur réseau Sans fil, ou le réseau ne prend en charge pas la Multidiffusion. Il est recommandé pour que des clients évitent d'utiliser la méthode de Multidiffusion-Unicast de livraison. Cette méthode est processeur intensif selon le nombre de flots de Multidiffusion à prendre en charge. En ce mode chaque paquet de multidiffusion doit être répliqué vers tous les Points d'accès qui ont joint le contrôleur sans se soucier s'il y a un client demandant l'adresse de groupe de multidiffusion.

La représentation de Multidiffusion a été optimisée avec l'introduction du mode de Multidiffusion-Multidiffusion. Au lieu d'employer l'unicast pour livrer chaque paquet de multidiffusion au-dessus du tunnel CAPWAP à chaque Point d'accès, un groupe de multidiffusion CAPWAP est configuré pour livrer le paquet de multidiffusion. Ceci permet aux Routeurs dans le réseau pour employer des techniques standard de Multidiffusion pour répliquer et livrer des paquets de multidiffusion aux Points d'accès. Pour le groupe de multidiffusion CAPWAP, le contrôleur devient la source multicast et les Points d'accès vont bien aux récepteurs multicasts. La représentation de Multidiffusion est améliorée pendant que les Points d'accès reçoivent des requêtes IGMP seulement du routeur et des paquets de multidiffusion avec une adresse IP source du contrôleur avec lequel ils sont actuellement associés.

cuwns-vidstrm-guide-12.gif

Remarque: Le Protocole IP Multicast utilise la chaîne de la classe D des adresses IP 224.0.0.0 par 239.255.255.255. Les plages d'adresse réservées, l'adresse de multidiffusion locale de lien (224.0.0.0 par 224.0.0.255) sont à l'usage des protocoles et ne peuvent pas être utilisées. Le reste de l'adresse de classe D, administrativement l'adresse de multidiffusion de Scoped (239.0.0.0 par 239.255.255.255) peut être utilisé pour configurer les réseaux IP pour la Multidiffusion.

La configuration ci-dessus peut également être configurée utilisant des lignes de commande dans quelques étapes.

cuwns-vidstrm-guide-conf5.gif

Remarque: Il est recommandé pour utiliser un seuls adresse de multidiffusion/contrôleur.

Une configuration plus importante sur le contrôleur est d'activer la surveillance IGMP. L'activation de la surveillance IGMP sur le contrôleur aide à collecter des rapports IGMP des hôtes et envoie à chaque AP une liste d'hôtes qui écoutent n'importe quel groupe de multidiffusion. Les paquets de multidiffusion AP puis en avant seulement à ces hôtes.

Le délai d'attente IGMP et l'intervalle de requête IGMP aident la surveillance IGMP pour être plus efficace. Quand le délai d'attente IGMP expire, le contrôleur envoie une requête sur tout le SSID entraînant les clients qui écoutent le groupe de multidiffusion pour envoyer un paquet de nouveau au contrôleur. L'intervalle de requête IGMP est combien de fois le contrôleur envoie une requête à tout le SSID. Si le délai d'attente IGMP est placé à 60 secondes et l'intervalle de requête IGMP est configuré à 20, il y aura trois requêtes.

cuwns-vidstrm-guide-13.gif

cuwns-vidstrm-guide-conf6.gif

Activant VideoStream ? Global

La caractéristique de VideoStream peut être activée dans trois endroits différents selon l'implémentation de la caractéristique. Ceci aide des administrateurs réseau à contrôler activer la caractéristique de VideoStream sur le contrôleur.

La caractéristique doit être activée globalement sur le contrôleur en vérifiant l'onglet sous la radio > le flux multimédia > le général. Activant la caractéristique ici remplira certains des paramètres de configuration sur le contrôleur pour VideoStream.

La caractéristique de VideoStream peut également être activée sous le type PHY. Le client a la flexibilité d'activer VideoStream seulement sur la radio 5Ghz ou la radio 2.4Ghz ou chacun des deux.

Le bouton direct de Multidiffusion sous WLAN > QoS apparaît en fonction si la caractéristique est activée globalement. Ceci donne la flexibilité d'activer la caractéristique de VideoStream par SSID.

cuwns-vidstrm-guide-14.gif

cuwns-vidstrm-guide-conf7.gif

Ajoutez la configuration de flot de Multidiffusion

Les flux de Multidiffusion peuvent être activés participer à RRC seulement si le flux de Multidiffusion est configuré sur le contrôleur. Afin d'ajouter un flot de Multidiffusion au contrôleur, le clic coule sous MediaStream.

Car mentionné lui est nécessaire que l'administrateur se rende compte de couler caractéristique visuel par un contrôleur. Un équilibre vrai doit être dessiné quand la configuration de flots sont ajoutées. Par exemple, si le débit binaire de flot varie entre 1200 Kbps et 1500 Kbps le flot doit être configuré pour une bande passante de 1500kbps. Si le flot est configuré pour 3000 Kbps puis vous ferez entretenir peu de client visuel par le Point d'accès. De même, configurer pour 1000 Kbps entraînera le pixelization, le mauvais audio et l'expérience utilisateur du mauvais.

Il y a quelques modèles préconfigurés sur la configuration de flot qui peut être utilisée. Il est nécessaire d'appliquer le jugement semblable en les sélectionnant. Certaines des configurations sont déjà capturées dans la partie précédente du document (admission et hiérarchisation de flot). Sinon utilisant les modèles, il y a quelques plus de configurations qui peuvent être utilisées pour améliorer l'expérience utilisateur. La taille moyenne des paquets peut être changée pour apparier le streaming vidéo. Le contrôle de réservation de ressource peut activé pour la mise à jour régulière de sorte que les systèmes puissent vérifier des santés très souvent. Ceci peut également être désactivé pour permettre à RRC de fonctionner seulement à l'admission. La priorité du flot peut être également fixée à une valeur élevée pour la hiérarchisation du flot. Une valeur configurée de 8 permettra le flot à donner la priorité et ne pas envoyer vers le bas au meilleur effort.

Sur n'importe quelle violation des stratégies précédentes, le flot peut être déclassifié au meilleur effort ou peut être lâché. Il est recommandé pour déclassifier au meilleur effort.

cuwns-vidstrm-guide-15.gif

cuwns-vidstrm-guide-conf8.gif

L'adresse IP de début de destination de Multidiffusion et l'adresse IP d'extrémité peuvent être la même adresse qu'affichées ci-dessus. On peut également configurer une plage de l'adresse de multidiffusion sur le contrôleur. Il n'y a aucune limite sur le nombre d'entrées d'adresses de multidiffusion ou le nombre d'entrées de flot. L'adresse IP de début peut être 239.4.5.1 et l'adresse IP d'extrémité peut être 239.4.5.254.

Des configs de VideoStream peuvent être activés sur les les deux les radios sur les Points d'accès. Les configs sur la radio peuvent être configurés ou modifiés seulement avec les radios désactivées. Quelques configurations exigeront également des WLAN /SSID d'être désactivés.

Remarque: Il est recommandé pour faire la toute la configuration exigée sur les radios une fois désactivé.

Activant VideoStream ? radio du 802.11 a/n

cuwns-vidstrm-guide-16.gif

Cliquez sur la RADIO > le 802.11 a/n > medias > medias pour activer le VideoStream et pour ajouter des configurations CAC/QOS. Des configurations semblables pourraient être exigées sur la radio du 802.11 b/g/n, selon le type de service fourni sur la radio.

Par VideoStream par défaut est désactivé sur les radios. La caractéristique peut être activée en vérifiant l'enable direct de Multidiffusion. La radio peut également également être configurée pour le nombre de clients qui peuvent joindre un flot de Multidiffusion par la traction en bas du nombre maximum direct de Multidiffusion de flots. Ceci peut être l'un ou l'autre a placé à l'automatique pour permettre à tous les clients pour joindre le flot de Multidiffusion. Le compte de client sur la radio peut également être contrôlé en configurant une valeur de 1-20.

cuwns-vidstrm-guide-17.gif

cuwns-vidstrm-guide-18.gif

L'Unicast Redirect visuelle est activé par défaut. Ceci permettra à unicast la circulation visuelle aux clients sans fil.

RRC admettra des clients pour joindre un flot après que des critères de passage (expliqués plus tôt) soit réalisés. Les clients admis auront une priorité de QoS de 4. Les clients qui ne passent pas les critères RRC seront lâchés et pas permis pour joindre le flot. Cependant, ceci peut être outrepassé en activant l'admission de QoS de meilleur effort. Maintenant tous les clients sans fil priés de joindre un flot seront admis au flot de Multidiffusion, mais certains d'entre eux auront une priorité de QoS de 0. La bande passante de medias est actuellement placée à 85% par défaut.

La bande passante de medias est la somme du trafic de Voix et de vidéo sur une interface par radio. Le plus bas qu'un client peut relâcher sur la radio est de 6000 Kbps pour joindre un streaming vidéo. S'il y a des clients qui doivent être limités de joindre un flot au-dessous d'un certain débit PHY cette valeur peuvent être changés. La valeur est 6000 par défaut. Le pour cent maximum de relance est, par défaut, positionnement à 80%. Le système maintient les relances sur la radio. Si les relances sont plus grandes qu'on ne permettra pas à la la valeur configurée le client pour joindre le flot.

Remarque: Il est recommandé pour garder les valeurs par défaut.

Cliquez sur la RADIO > le 802.11 a/n > medias > vidéo pour activer le contrôle CAC/Admission. Contrôle d'admission d'enable pour le vidéo.

Selon le type de service qui doit être activé sur la radio configurez une valeur pour la bande passante maximum rf. Cet à valeur ajoutée ici décidera le nombre de clients visuels à laisser joindre un flot configuré de Multidiffusion sur la radio (référez-vous à la Voix de Tableau/à valeur visuelle CAC). Par exemple, une valeur maximale de 80% permettra à vingt clients sans fil le flot avec un débit binaire de bits de 5M.

cuwns-vidstrm-guide-19.gif

RADIO > 802.11 de clic a/n > medias > Voix pour activer le contrôle de la Voix CAC/Admission. Contrôle d'admission d'enable pour la Voix. Cet à valeur ajoutée ici décidera le nombre de communications voix qui seront permises sur la radio (référez-vous à la Voix de Tableau/à valeur visuelle CAC).

cuwns-vidstrm-guide-20.gif

La radio a été désactivée pour ajouter les configurations de VideoStream. Activez la radio 802.11a.

Activant VideoStream ? radio 802.11b/g/n

La configuration ci-dessus peut être répétée sur la radio 802.11b/g/n. Désactivez la radio 802.11b/g/n d'abord avant que toutes les modifications soient apportées.

cuwns-vidstrm-guide-21.gif

L'activation de la caractéristique de VideoStream sur 802.11b/g/n a besoin d'attention plus particulière car il y aura une densité plus élevée de client. Il est nécessaire d'allouer une quantité de bande passante suffisante pour que les clients sans fil joignent le flot de Multidiffusion. Équilibrant les données, des clients de Voix et de vidéo sur la radio 802.11b/g/n devraient être bien à l'avance prévus ainsi les configurations, une fois qu'appliqués, n'entraîneront pas des problèmes cruciaux.

Remarque: BandSelect et ClientLink sont les deux caractéristiques qui entretiendront les clients sans fil et réduisent certains des clients sur la radio 2.4 gigahertz.

Répétez les étapes affichées dans les trois captures d'écran ci-dessus sur la radio 802.11b/g/n. Les captures d'écran sont affichées ci-dessous.

cuwns-vidstrm-guide-22.gif

Par défaut la caractéristique de VideoStream est désactivée sur les radios. Cliquez sur la RADIO > le 802.11 b/g/n > medias > medias. Vérifiez la caractéristique directe d'enable de Multidiffusion. Abaissez le nombre maximum direct de Multidiffusion du flot pour configurer une valeur 1 à 20, ou laissez-le au par défaut.

L'Unicast Redirect visuelle est activé par défaut. Ceci permettra à unicast la circulation visuelle aux clients sans fil.

RRC admettra des clients pour joindre un flot après que des critères de passage (expliqués plus tôt) soit réalisés. Les clients admis auront une priorité de QoS de 4. Les clients qui ne passent pas les critères RRC seront lâchés et pas permis pour joindre le flot. Cependant, ceci peut être outrepassé en activant l'admission de QoS de meilleur effort. Maintenant tous les clients sans fil priés de joindre un flot seront admis au flot de Multidiffusion, mais certains d'entre eux auront une priorité de QoS de 0.

La bande passante de medias est actuellement placée à 85% par défaut. La bande passante de medias est la somme du trafic de Voix et de vidéo sur une interface par radio. Le plus bas qu'un client peut relâcher sur la radio est de 6000 Kbps pour joindre un streaming vidéo. S'il y a des clients qui doivent être limités de joindre un flot au-dessous d'un certain débit PHY cette valeur peuvent être changés. La valeur est 6000 par défaut. Le pour cent maximum de relance est par l'ensemble par défaut à 80%. Le système maintient les relances sur la radio et si les relances est plus grande que la valeur configurée on ne permettra pas qu'au le client pour joindre le flot.

Cliquez sur la RADIO > le 802.11 b/g/n > medias > vidéo pour activer le contrôle CAC/Admission. Contrôle d'admission d'enable pour le vidéo.

Selon le type de service qui doit être activé sur la radio, configurez une valeur pour la bande passante maximum rf. L'à valeur ajoutée ici décidera le nombre de client visuel qui sera laissé pour joindre un flot configuré de Multidiffusion sur la radio (référez-vous à la Voix de Tableau/à valeur visuelle CAC).

cuwns-vidstrm-guide-23.gif

RADIO > 802.11 de clic b/g/n > medias > Voix pour activer le contrôle de la Voix CAC/Admission. Contrôle d'admission d'enable pour la Voix. L'à valeur ajoutée ici décidera le nombre de communications voix à autoriser sur la radio (référez-vous à la Voix de Tableau/à valeur visuelle CAC).

cuwns-vidstrm-guide-24.gif

Permettez aux radios de permettre à des clients pour s'associer.

Activant VideoStream - WLAN

Un ou tous WLAN/SSID configuré peuvent être activés pour le streaming vidéo avec VideoStream. C'est une autre étape de configuration qui peut contrôler l'activation de la caractéristique de VideoStream. L'activation ou désactivation de la caractéristique de VideoStream est non perturbatrice. Clic WLAN > <WLAN ID> > QoS.

cuwns-vidstrm-guide-25.gif

Configurez la qualité de service à Gold(video) pour couler le vidéo au client sans fil à une valeur de QoS de l'or (4). Ceci activera seulement la qualité vidéo du service aux clients sans fil joints à un flot configuré sur le contrôleur. Le reste des clients sera activé pour QoS approprié. Multidiffusion d'enable directe sur le WLAN en vérifiant la caractéristique comme affiché ci-dessus. Ceci permettra au WLAN d'entretenir des clients sans fil avec la configuration de VideoStream.

Tous les clients sans fil demandant de joindre un flot seront assignés la priorité visuelle de QoS sur l'admission. Le streaming vidéo de client sans fil avant d'activer la caractéristique sur le WLAN coulera utilisant la Multidiffusion normale. L'activation de la caractéristique commutera les clients Multidiffusion-directs automatiquement sur le prochain intervalle de surveillance IGMP.

La Multidiffusion existante peut être activée sur le WLAN en ne vérifiant pas la caractéristique directe de Multidiffusion. Ceci prouvera que le streaming vidéo de clients sans fil sont en mode normal de Multidiffusion.

Vérifier la fonctionnalité de VideoStream

Assurez-vous que les clients sans fil sont associés au Point d'accès, et sont configurés pour une interface appropriée. Comme vu dans la capture ci-dessous il y a trois clients associés à un Point d'accès. Chacun des trois clients a une adresse IP de VLAN124 (testclients).

cuwns-vidstrm-guide-26.gif

Les clients associés ont une adresse IP et une bonne Connectivité de liaison ascendante au Point d'accès.

cuwns-vidstrm-guide-27.gif

Il n'y a aucun client qui ont joint le flot de Multidiffusion. Il y a seulement l'entrée de contrôleur avec l'adresse configurée de groupe de multidiffusion enregistrée sur le commutateur.

Switch14-1>en
Password:
Switch14-1#sh ip mroute

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, 
L - Local, P - Pruned, R - RP-bit set, F - Register flag, 
T - SPT-bit set, J - Join SPT, M - MSDP created entry, 
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, 
U - URD, I - Received Source Specific Host Report, 
Z - Multicast Tunnel, z - MDT-data group sender, 
Y - Joined MDT-data group, y - Sending to MDT-data group 
V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.1.2), 01:23:52/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan122, Forward/Sparse-Dense, 01:22:31/00:00:00

(10.10.10.10, 239.100.1.2), 00:01:45/00:01:15, flags: PT
Incoming interface: Vlan122, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 239.192.1.150), 01:23:55/00:02:13, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan122, Forward/Sparse-Dense, 01:23:55/00:00:00

Il n'y a aucun flux vidéo sur le réseau câblé, par conséquent aucune entrées pour (S, G) source, des adresses de groupe. Activez couler du côté de câble en connectant un serveur vidéo à une adresse de multidiffusion configurée 239.4.5.6. La capture sur le commutateur sera plus que ce qui a été observé plus tôt.

Switch14-1#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, 
L - Local, P - Pruned, R - RP-bit set, F - Register flag, 
T - SPT-bit set, J - Join SPT, M - MSDP created entry, 
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, 
U - URD, I - Received Source Specific Host Report, 
Z - Multicast Tunnel, z - MDT-data group sender, 
Y - Joined MDT-data group, y - Sending to MDT-data group 
V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.1.2), 01:23:52/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan122, Forward/Sparse-Dense, 01:22:31/00:00:00

(10.10.10.10, 239.100.1.2), 00:01:45/00:01:15, flags: PT
Incoming interface: Vlan122, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 239.4.5.6), 01:23:34/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.10.10.101, 239.4.5.6), 00:08:26/00:02:58, flags: PT
Incoming interface: Vlan122, RPF nbr 0.0.0.0
Outgoing interface list: Null
Switch14-1#

Debug - Commutateur

Joignez un client sans fil au streaming vidéo de Multidiffusion. En outre, debug bcast de capture tout l'enable du contrôleur. La capture de débogage a les informations sur la demande de client, l'adresse de groupe, le statut de la demande et la mise à jour.

*bcastReceiveTask: Sep 29 13:31:56.913: bcastProcessNPUMsg: received packet  
  (rxTunType 1, dataLen 155)  
*bcastReceiveTask: Sep 29 13:31:56.913: bcastLwappRx: received lwapp packet  
  from STA 0021.5dac.d898 
*bcastReceiveTask: Sep 29 13:31:56.913: IGMP packet received over vlanid = 0  
  from client 00:21:5d:ac:d8:98 
*bcastReceiveTask: Sep 29 13:31:56.913: Recieved Igmp v2 report packet from  
  client 00:21:5d:ac:d8:98 
*bcastReceiveTask: Sep 29 13:31:56.913: report packet recevied for group  
  addr 239.4.5.6 
*bcastReceiveTask: Sep 29 13:31:56.913: join group 239.4.5.6 and vlan = 0  
  is not there adding... 
*bcastReceiveTask: Sep 29 13:31:56.913: 00:21:5D:AC:D8:98 client joining the group:  
  239.4.5.6, with status = 1, qos=0 and valid = 1... 
*bcastReceiveTask: Sep 29 13:31:56.929: Received status Update for  
  client: 00:21:5D:AC:D8:98 , status = 2, qos = 4  
*bcastReceiveTask: Sep 29 13:31:56.929: 00:21:5D:AC:D8:98 client status is updated  
  from 1 to ALLOWED state.  
*bcastReceiveTask: Sep 29 13:31:56.930: IGMP message send succeeded src 10.10.10.10  
  and dst 239.4.5.6, hdr len 32,message type 16 
*bcastReceiveTask: Sep 29 13:31:56.930: update ap for status = 2

Le client sans fil avec l'adresse MAC 00:21:5d:ac:d8:98 envoyée un IGMP v2 se joignent sous forme d'état à une adresse de flot de 239.4.5.6. Le client a joint le groupe avec un qos=4 et a été changé à un état PERMIS (référez-vous à l'organigramme).

To cliquer sur Monitor > Multidiffusion > et le MGID pour l'adresse coulante 239.4.5.6. On l'observe que l'adresse MAC du client sans fil est dans un état permis Multidiffusion-direct. La priorité utilisateur de QoS est 4. Ceci affiche le client traitant les paquets visuels dans la file d'attente visuelle.

cuwns-vidstrm-guide-28.gif

cuwns-vidstrm-guide-conf9.gif

Debug - Contrôleur

Le traitement de la demande d'un client sans fil sur un contrôleur peut être clairement compris par l'activation met au point sur le contrôleur. Activé met au point est également capturé sur le contrôleur. Il y a une demande 3646 créée pour le client avec l'adresse MAC 0021.5dac.d898. Tout les flux de données est WRT au client avec l'adresse MAC 0021.5dac.d898 est affiché dans le débogage ci-dessous. Le RRC donne un coup de pied dedans pour valider les ressources pour la radio associée. La validation est réussie et le client est admis a basé sur les valeurs validées. Le flot est toujours dans un état bloqué jusqu'à ce que le flot soit admis et le client ne recevra aucun vidéo. Le client mettra en marche le streaming vidéo une fois qu'il reçoit une réponse de jonction.

Promouvez les demandes du même client sera validé. Puisque le client coule déjà l'engine RRC répondra avec un message « déjà admis « . Ceci ne gênera pas les performances du client sans fil.

(Cisco Controller) >show debug

MAC debugging .............................. disabled

Debug Flags Enabled:
Media-Stream Admission debug enabled.
Media-Stream Config debug enabled.
Media-Stream Errors debug enabled.
Media-Stream Event debug enabled.
Media-Stream Rrc debug enabled.

(Cisco Controller) >
*rrcEngineTask: Sep 29 15:37:13.181: rrcEngineProcessPurgeTimer: table expired
*bcastReceiveTask: Sep 29 15:37:18.599: msPolicyPlatform test AP 1100 type
*bcastReceiveTask: Sep 29 15:37:18.599: msPolicyPlatform not AP 1100
*bcastReceiveTask: Sep 29 15:37:18.599: mStreamWlanMc2ucAllowed allow
*bcastReceiveTask: Sep 29 15:37:18.599: mStreamBand 1 allow mc2uc
*bcastReceiveTask: Sep 29 15:37:18.599: stream policy allow mc2uc
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc update client 0021.5dac.d898
  radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124
*bcastReceiveTask: Sep 29 15:37:18.605: msPolicyGetRrcQosSupport 1 4 1
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc begin check policy
*bcastReceiveTask: Sep 29 15:37:18.605: msPolicyPlatform test AP 1100 type
*bcastReceiveTask: Sep 29 15:37:18.605: msPolicyPlatform not AP 1100
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc qos admit 1 qos 4 pri 1
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc submit client client 0021.5dac.d898  
  radio c47d.4f53.14f0 destIp ef040506 mgid 569 vapId 1 vlan 124
*bcastReceiveTask: Sep 29 15:37:18.605: start FindRequestByClient
*bcastReceiveTask: Sep 29 15:37:18.605: FindRequestByClient not found  
  dest ef040506 client 0021.5dac.d898 radio c47d.4f53.14f0
*bcastReceiveTask: Sep 29 15:37:18.605: Creating request 3646
*bcastReceiveTask: Sep 29 15:37:18.605: for radio c47d.4f53.14f0
*bcastReceiveTask: Sep 29 15:37:18.605: for client 0021.5dac.d898
*bcastReceiveTask: Sep 29 15:37:18.605: rrcEngineInsertAdmitRequest dest ef040506  
  mgid 569 request 3646
*bcastReceiveTask: Sep 29 15:37:18.606: rrcEngineSendMeasureMetricsRequest  
  sent request 3646 to radio c47d.4f53.14f0, minRate = 6000, maxRetryPercent = 80
*rrcEngineTask: Sep 29 15:37:18.607: rrcEngineProcessRadioMetrics  
  start radio c47d.4f53.14f0 request 3646
*rrcEngineTask: Sep 29 15:37:18.607: rrcEngineFindRequest look for request 3646
*rrcEngineTask: Sep 29 15:37:18.607: rrcEngineFindRequest found request 3646
*rrcEngineTask: Sep 29 15:37:18.607: done rrcEngineProcessRadioMetrics  
  radio c47d.4f53.14f0 request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineProcessClientMetrics  
  radio c47d.4f53.14f0 request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineFindRequest look for request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineFindRequest found request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineRemoveAdmitRequest request 3646
*rrcEngineTask: Sep 29 15:37:18.613: p_video = 0, p_voice = 0, pb = 198, 
  video_qo = 0, video_l_r_ratio = 0, video_no = 0, video_delay_hist_severe = 0,  
  video_pkt_loss_discard = 0, video_pkt_loss_fail = 0,
*rrcEngineTask: Sep 29 15:37:18.613: radio_tx_q_max_size = 1,  
  radio_tx_q_limit = 672, vi_tx_q_max_size = 0, current_rate = 234
*rrcEngineTask: Sep 29 15:37:18.613: msPolicyGetStreamParameters 1500 1200
*rrcEngineTask: Sep 29 15:37:18.613: Admit video: client number 0 request 3646  
  radio c47d.4f53.14f0, decision 1
*rrcEngineTask: Sep 29 15:37:18.613: Admit video: client number 0 request 3646  
  radio c47d.4f53.14f0, decision 1
*rrcEngineTask: Sep 29 15:37:18.613: mStreamBandMc2ucAdmit besteffort 0
*rrcEngineTask: Sep 29 15:37:18.613: Approve Admission on radio c47d.4f53.14f0  
  request 3646 vlan 124 destIp ef040506 decision 1 qos 4 admitBest 0
*rrcEngineTask: Sep 29 15:37:18.614: Recording request 3646 destIp ef040506 qos 4  
  vlan 124 violation-drop 0 priority 1
*rrcEngineTask: Sep 29 15:37:18.614: done rrcEngineProcessClientMetrics  
  client 0021.5dac.d898 radio c47d.4f53.14f0 request 3646
*bcastReceiveTask: Sep 29 15:37:19.553: mc2uc update client 0021.5dac.d898  
  radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124
*bcastReceiveTask: Sep 29 15:37:19.553: Already admitted, mc2uc  
  Update the last IGMP timestamp
*bcastReceiveTask: Sep 29 15:37:20.553: mc2uc update client 0021.5dac.d898  
  radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124

(Cisco Controller) >

Commandes show ? Contrôleur

Certaines des commandes show ont été capturées plus tôt dans ce document. Cette section de la capture est seulement pour la référence. Pour plus de détails sur les commandes, référez-vous au guide de référence de commandes de version 7.0 CUWN.

(Cisco Controller) >show ap summary

Number of APs.................................... 1

Global AP User Name.............................. Not Configured
Global AP Dot1x User Name.................... Not Configured

AP Name  Slots AP Model Ethernet MAC Location Port Country Priority
------------- ----- -------------------- ----------------- ----------------
CAP3502E 2 AIR-CAP3502E-A-K9 c4:7d:4f:3a:06:86 default location LAG US 1

(Cisco Controller) >

(Cisco Controller) >show client summary

Number of Clients................................ 2

MAC Address AP Name Status WLAN Auth Protocol Port Wired
----------------- - ---------------- ------------- ---------- ---- 
00:1d:e0:00:ab:c7 CAP3502E Associated 1 Yes 802.11n(2.4 GHz) 13 No
00:21:5d:ac:d8:98 CAP3502E Associated 1 Yes 802.11n(2.4 GHz) 13 No

(Cisco Controller) >

(Cisco Controller) >show media-stream multicast-direct state
Multicast-direct State........................... enable
Allowed WLANs.................................... 1

(Cisco Controller) >

(Cisco Controller) >show media-stream group summary
Stream Name Start IP End IP Operation Status
------------- -------------- -------------- ----------------
test1.5K 239.4.5.6 239.4.5.6 Multicast-direct

(Cisco Controller) >

(Cisco Controller) >show media-stream group detail test1.5K
Media Stream Name................................ test1.5K
Start IP Address....................................... 239.4.5.6
End IP Address........................................ 239.4.5.6
RRC Parmmeters
Avg Packet Size(Bytes)............................... 1200
Expected Bandwidth(Kbps)........................ 1500
Policy......................................................... Admit
RRC re-evaluation....................................... periodic
QoS............................................. Video
Status................................... ...... Multicast-direct
Usage Priority.............................. 1
Violation...................................... fallback

(Cisco Controller) >

(Cisco Controller) >show network multicast mgid summary
Layer2 MGID Mapping:
-------------------
InterfaceName vlanId MGID
------------------------ ------ ----
data 123 11
management 0 0
testclients 124 12
Layer3 MGID Mapping:
-------------------
Number of Layer3 MGIDs........................... 7
Group address Vlan MGID
--------------- --- ----
224.0.0.251 0 550
224.0.0.255 0 555
224.2.127.254 0 552
239.4.5.6 0 556
239.195.255.255 0 553
239.255.255.250 0 551
239.255.255.255 0 554

(Cisco Controller) >show 802.11b media-stream rrc
Multicast-direct................................. Enabled
Best Effort.......................................... Disabled
Video Re-Direct................................. Enabled
Max Allowed Streams........................ Auto
Max Video Bandwidth....................... 30
Max Voice Bandwidth........................ 55
Max Media Bandwidth....................... 85
Min PHY Rate..................................... 6000
Max Retry Percentage........................ 80

(Cisco Controller) >

Conclusion

Caractéristique de VideoStream de supports logiciels CUWN 7.2 sur le matériel plus nouveau de contrôleur. Ceci inclut :

  • Contrôleurs de gamme Cisco 5500

  • Module de service sans fil - 2

  • Contrôleurs de gamme Cisco 2500 *

  • ISR G2 de Cisco avec le module SRE *

Remarque: * — Les nombres de représentation diffèrent sur les Points d'accès non-802.11n.

Caractéristique de VideoStream de supports logiciels CUWN 7.0 sur le matériel plus nouveau de contrôleur. Ceci inclut :

  • Contrôleurs de gamme Cisco 5500

  • Contrôleurs de gamme Cisco 4400

  • Contrôleurs de gamme Cisco 2100

  • Module de service sans fil

VideoStream est également pris en charge sur Cisco 2504 autonome et contrôleur de Cisco WiSM-2.

Caractéristique de VideoStream de supports logiciels CUWN 7.2 sur tous les plus nouveaux Points d'accès 802.11n et quelques Points d'accès existants. Ceci inclut :

  • Points d'accès de gamme 3600 de Cisco Aironet

  • Points d'accès de Gamme Cisco Aironet 3500

  • Points d'accès de Gamme Cisco Aironet 1260

  • Point d'accès de la gamme Cisco Aironet 1250

  • Points d'accès de gamme de Cisco Aironet 1240AG**

  • Points d'accès de Gamme Cisco Aironet 1140

  • Points d'accès de gamme de Cisco Aironet 1130AG**

  • Points d'accès de Gamme Cisco Aironet 1040

Remarque: ** — La capacité de client varie sur les contrôleurs bas de gamme.

La caractéristique de VideoStream peut couler le vidéo au-dessus du matériel de Cisco Unified Wireless et fournir une qualité supérieure. La configuration statique CAC fournira le contrôle de client sans fil sur les radios. La caractéristique active la Multidiffusion coulant au-dessus de la radio dans la retransmission avec la Multidiffusion coulant sur des clients câblés. La Multidiffusion coulant aux clients sans fil avec la demande de jonction IGMP seulement et la réplication est faite seulement aux Points d'accès économisant de ce fait la bande passante sur les ports uplinks de la distribution et des commutateurs d'accès.


Informations connexes


Document ID: 112889