Sem fio : Controladores sem fio Cisco 5500 Series

Solução de rede do Cisco Unified Wireless: Guia de distribuição de VideoStream

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

A Cisco Unified Wireless Network (CUWN) introduziu uma nova característica, o VideoStream, para grandes implementações empresariais. Esta característica permite a arquitetura wireless de distribuir o fluxo de vídeo do Multicast através da empresa aos clientes Wireless. Esta característica recompensa os inconvenientes que degradam a entrega video enquanto os córregos e a escala dos clientes em uma rede de empreendimento. VideoStream faz o Multicast video aos clientes Wireless mais seguro e usando a largura de banda/espectro mais eficientemente. Em uma rede de empreendimento defluência, a característica atribui a prioridade ao córrego e fornece mais idade do peso aos córregos preferidos. Esta característica igualmente garante a entrega do vídeo aos clientes Wireless e nega o vídeo à assinatura nova do cliente sob a utilização de canal pesada.

Requisitos

Conhecimento da solução de LAN do Cisco Unified Wireless.

Componentes Utilizados

A característica de VideoStream está disponível em realces da versão 7.0with do software de rede do Cisco Unified Wireless na versão 7.2 do software de rede do Cisco Unified Wireless. Esta característica é apoiada em todos os controladores do Wireless LAN (WLAN) e nos Access point internos de uma geração mais nova (AP). Esta característica não está disponível em Access point autônomos e em Access point exteriores.

Produtos Relacionados

Hardware e software wireless apoiado

VideoStream é apoiado em todos os controladores do Wireless LAN. Isto inclui o controlador de Cisco 5500, o controlador de Cisco 4400, o controlador de Cisco 2100 e o WiSMs. VideoStream é apoiado igualmente no Cisco 2504 autônomo e no controlador de Cisco WiSM-2. O IGMPv2 é a versão suportada em todos os controladores.

VideoStream é apoiado em todos os Access point. Isto inclui todos os modelos 802.11n dos Access point que consistem no 3600 Series Access point do Cisco Aironet, nos Access point do Cisco Aironet série 3500 Access point, do Cisco Aironet série 1260 Access point, do Cisco Aironet série 1250, nos Access point do Cisco Aironet série 1140 do Cisco Aironet e no 1040 Series do Cisco Aironet Access point. VideoStream é apoiado igualmente em Access point dos Access point da série do Cisco Aironet 1240AG* e da série do Cisco Aironet 1130AG*.

A característica de VideoStream foi introduzida na versão CUWN 7.0 do código do controlador e apoiada em umas versões mais atrasadas do software do controlador com realces.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Teoria operacional

Antes de entrar em detalhes sobre a característica de VideoStream, alguns dos défices na necessidade do Multicast do Wi-fi de ser compreendido. 802.11n é uma tecnologia Wireless proeminentemente discutida para disposições wireless internas. A exigência ingualmente proeminente é considerada no serviço multimídia em uma rede Wireless da empresa, em particular, vídeo. O fluxo de vídeo do Multicast será uma solução econômica em uma rede de empreendimento enorme porque o unicast dos serviços de vídeo não escalará em uma fluência larga da empresa. O Multicast não fornece nenhuma recuperação da camada de MAC no Multicast/frames de transmissão. O Multicast e os pacotes de transmissão não têm um reconhecimento (ACK), e toda a entrega de pacotes é o melhor esforço. O Multicast sobre o Sem fio com 802.11a/b/g/n não fornece nenhum mecanismo para a transmissão segura.

As disposições wireless da empresa são interferência inclinada, utilização de canal alta, cliente incompatível, baixo SNR na borda da pilha. A entrega video aos clientes Wireless está nas taxas de dados imperativas as mais altas no canal respectivo. Há igualmente muitos clientes que compartilham do mesmo canal mas tem condições do canal, limitações da potência e capacidades de processamento diferentes do cliente. Consequentemente, o Multicast não será um protocolo de transmissão seguro a todos os clientes no mesmo canal que cada cliente tem condições diferentes do canal como visto abaixo no diagrama.

O Multicast wireless não dá a prioridade ao tráfego de vídeo mesmo que seja Differentiated Service Code Point (DSCP) marcado pelo servidor de vídeo. O aplicativo considerará uma perda de pacotes sem o ACK, e as novas tentativas à entrega serão ruins. A fim fornecer o pacote seguro das transmissões de transmissão múltiplas, é necessário que a rede classifica filas e disposições por meio do Qualidade de Serviço (QoS). Isto removerá virtualmente a introdução da insegurança eliminando pacotes da gota e atraso dos pacotes ao host marcando os pacotes e classificando os à fila apropriada.

Mesmo que a adaptação 802.11n ganhasse o impulso com a rede e os clientes, o Multicast wireless não pôde usar as taxas de dados 802.11n. Este igualmente foi um dos fatores para um mecanismo alternado para a propagação wireless do Multicast.

Multicast do legado

A aplicação do Multicast evoluiu sobre liberações em CUWN. Antes que o código CUWN 7.0 o desempenho do Multicast esteve aperfeiçoado e uma maneira eficiente entregar o tráfego multicast do controlador ao Access point foi introduzido.

Neste processo um o grupo de transmissão múltipla é configurado no controlador para registrar os Access point e para entregar o pacote de transmissão múltipla. Esta aplicação deixou cair o processo do controlador que usa o unicast para entregar pacotes de transmissão múltipla a cada Access point sobre um túnel de pouco peso do protocolo do Access point (LWAPP). Nesta configuração os componentes da rede subjacente são usados pelo controlador para replicate e entregar o pacote de transmissão múltipla ao Access point. O controlador transforma-se o origem de transmissão múltipla para o grupo configurado LWAPP/CAPWAP e os Access point são os receptores de transmissão múltipla. O Access point aceita perguntas do Internet Group Management Protocol (IGMP) do roteador fluxo acima e dos pacotes de transmissão múltipla com um endereço IP de origem do controlador associado. Isto aumenta o desempenho do Multicast consideravelmente. A pergunta IGMP é enviada a seus membros e clientes, mantém-se assim atualizar o banco de dados.

A configuração do IGMP Snooping igualmente introduziu uma entrega de pacotes melhor do Multicast. As perguntas de um vizinho ascendente do router/do Multicast são respondidas com um relatório IGMP baseado na configuração de grupo no controlador. Um grupo de transmissão múltipla ID original (MGIDs) é criado pelo controlador dos relatórios IGMP após ter verificado os endereços de multicast L3 e o número de VLAN, e atualiza um relatório IGMP ao interruptor L3 ou ao vizinho ascendente. O controlador envia os relatórios com o endereço de origem como o endereço da relação em que os relatórios são recebidos dos clientes. Uma tabela MGID é criada ou atualizada no Access point com os endereços MAC de cliente.

Quando o controlador recebe um Multicast junte-se à resposta para um grupo particular ele para a frente a todos os Access point no grupo. Contudo, somente aqueles Access point que têm os clientes ativo subscritos a esse grupo de transmissão múltipla para enviar o tráfego multicast. Os fluxos de tráfego multicast ao cliente na taxa de dados imperativa a mais alta como visto na captação. O cliente associou ao Access point na taxa 802.11n em um rádio 5GHz.

cuwns-vidstrm-guide-01.gif

VideoStream

VideoStream fornece a utilização da largura de banda eficiente removendo a necessidade de transmitir de qualquer maneira pacotes de transmissão múltipla a todos os WLAN no AP se há um cliente juntado a um grupo de transmissão múltipla. A fim obter em torno desta limitação, o AP precisa de poder enviar o tráfego multicast ao host através do encaminhamento de unicast, simplesmente no WLAN que o cliente está juntado e faça assim na taxa de dados que o cliente é juntado em. Antes que VideoStream esteja configurado, você deve compreender em um nível alto como difere do desenvolvimento normal do Multicast (Multicast/transmissão).

VideoStream, pela primeira vez em um sistema Wireless, fornece uma aproximação sem emenda para que os coordenadores projetem e executem uma solução do Multicast sem destruir a largura de banda entre o controlador e o interruptor ou o roteador ascendente.

A tecnologia de Cisco VideoStream é um conjunto de recurso largo do sistema novo da rede de Cisco Unified Wireless que incorpora alguns dos realces chaves para entregar a qualidade de vídeo superior. Cisco VideoStream apresenta o RF e a experiência video de Cisco para entregar uma plataforma segura, consistente para todos os tipos diferentes de vídeo. Isto toma o exame, o MAC, e as camadas de aplicativo do Wireless LAN na consideração. As próximas seções destacam algumas das características de VideoStream e como as características aumentam excepcionalmente a entrega do vídeo sobre o Wi-fi e a qualidade da experiência de usuário final. Um diagrama simples de rede para VideoStream é mostrado aqui para explicar os conceitos que são introduzidos.

cuwns-vidstrm-guide-02.gif

A introdução ao fluxo de processo para VideoStream fará fácil compreender as próximas seções da descrição de recurso. O fluxo de processo igualmente introduzirá os módulos tais como a admissão do córrego, a prioridade do córrego, o controle de rádio da reserva, o Multicast-à-unicast, e o AutoQoS.

cuwns-vidstrm-guide-03.gif

VideoStream pode ser permitido globalmente no controlador. A característica pode ser permitida a nível de rádio (2.4 gigahertz gigahertz e 5) e a nível WLAN ou SSID, e fornece mais controle ao administrador para identificar fluxos de vídeo específicos para o tratamento preferencial de Qualidade de Serviço.

Admissão e prioridade do córrego

Como mais adiantado mencionado quando o vídeo for uns meios de uma comunicação eficientes, de alto impacto, é igualmente muito largura de banda intensiva, e como é visto, não todo o índice video é dado a prioridade o mesmos. De uma discussão mais adiantada é claro que as organizações que investem no vídeo não podem ter recursos para ter a largura de banda de rede consumida sem nenhuma prioridade de media críticos para negócio.

A admissão do córrego autorizará o administrador de rede para ter o controle sobre todo o fluxo de vídeo do Multicast na rede. A admissão do córrego facilitará o administrador de rede para usar moldes predefinidos para fluxos de transmissão múltipla de entrada. Há poucos moldes predefinidos para larguras de banda do córrego de 300Kbps, de 500Kbps, de 1Mbps, de 3Mbps e de 5 Mbps. Os administradores de rede com menos experiência do vídeo podem usar os moldes predefinidos.

cuwns-vidstrm-guide-04.gif

cuwns-vidstrm-guide-05.gif

É necessário ter uma compreensão básica da vídeo fluente característica antes de configurar. Por exemplo, considere as duas configurações acima. Se a taxa de bits video é em torno de 4Mbps você precisa de adicionar manualmente as configurações em vez de usar alguns dos dois moldes acima. Se Stream-Less3Mbps é usado, a qualidade do vídeo será quadros video faltantes devidos do mau. Observa-se que há pixelation do gelo video e constante do vídeo em um cliente Wireless. Se Stream-Less5Mbps é usado, o número dos clientes video será menos como cada cliente Wireless está garantido de 5Mbps quando a taxa de bit video for bit somente 4 M. Se você teve o Sem fio dez mim clientes a largura de banda agregada do cliente deve ser em torno de 40Mbps. Usando o Stream-Less5Mbps o controlador estará usando 50Mbps, daqui privando 3 clientes Wireless do vídeo.

A prioridade do córrego pode configurar o fluxo de mídia com a prioridade diferente baseada na importância dentro da rede de empreendimento. A prioridade RRC vem jogar somente quando há uma congestão ou uma disputa no ponto de acesso Wireless.

cuwns-vidstrm-guide-06.gif

Quando há uma congestão e há fluxos de transmissão múltipla video e clientes demais, o córrego 4 toma a precedência sobre o resto dos córregos configurados. O fluxo de vídeo configurado terá a baixa prioridade do que a Voz, e a prioridade mais alta do que o tráfego de melhor esforço. Todo o tráfego multicast restante será admitido como o tráfego de melhor esforço mesmo que sejam marcados para QoS para a prioridade video.

Controle da reserva de recurso

Porque cada vez mais os usuários começam a utilizar o vídeo no local de trabalho em valores-limite do Wi-fi, a capacidade para controlar e escalar graciosamente a um momento determinado uma experiência contínua, e de alta qualidade para grupos da flutuação de usuários ou o lugar é crítico. O controlador e os Access point têm um algoritmo crucial da tomada de decisão, aquele é o controle da reserva de recurso (RRC) fornece recursos avançados controlar a admissão e os controles de política. A admissão e as decisões de política são feitas baseado nas medidas do recurso de rádio, na medida das estatísticas do tráfego, e nas configurações de sistema. O controlador inicia pedidos RRC aos Access point para o IGMP junta-se. O Access point processará o pedido para todos os parâmetros alistados neste diagrama:

cuwns-vidstrm-guide-07.gif

Na resposta acima todos os parâmetros passaram a configuração das normas no controlador. O IGMP junta-se ao pedido do cliente nesse Access point será admitido. Se o pedido RRC teve uma resposta como mostrado abaixo, o pedido da junta será investigado e o algoritmo RRC será verificado para ver se há a configuração das normas outra vez. O cliente será admitido mas como um melhor cliente do esforço. Contudo, em diversas tentativas da verificação RRC admitir-se-á com uma prioridade de QoS melhor.

cuwns-vidstrm-guide-08.gif

RRC é iniciado em um cliente no IGMP junta-se a um córrego e pode-se ser configurado para a verificação periódica. Devido a alguns muda na característica wireless se a resposta métrica RRC varia o cliente será negada consideravelmente ao córrego.

cuwns-vidstrm-guide-09.gif

RRC fornece a proteção da largura de banda para o cliente video negando os pedidos que causariam a assinatura em excesso. A utilização de canal é usada como uma métrica para determinar a capacidade e para executar o controle de admissão. Figura 4 ilustra como RRC trabalha. A integração com Voz CAC garante a qualidade de vídeo e a prioridade de voz.

Multicast ao unicast

Permitindo as taxas de dados 802.11n e fornecendo a correção de erros do pacote, as capacidades do Multicast-à-unicast de Cisco VideoStream aumentam a confiança de entregar a vídeo fluente sobre o Wi-fi além das características do melhor esforço de redes Wireless tradicionais.

Um aplicativo de cliente Wireless subscreve a um córrego do Protocolo IP multicast enviando um juntar mensagem IGMP. Com Multicast seguro, este pedido snooped pela infraestrutura, que recolhe dados dos mensagens IGMP. As verificações de sistema a assinatura e a configuração do córrego, recolhem então o medidor e as políticas de tráfego para o córrego pedido. Se o córrego pedido é permitido pelas políticas, uma resposta está enviada ao cliente Wireless anexado ao Access point a fim iniciar o Multicast seguro uma vez que o córrego chega. O sistema igualmente procura a largura de banda disponível e o medidor configurado do córrego para determinar se há bastante tempo de antena para apoiar a assinatura nova. Além, o sistema considera a carga de prevalência no rádio e a saúde dos media antes de fazer a decisão da admissão. Os critérios acima são encontrados afinal, uma resposta da junta são enviados ao Access point. Isto é quando o Access point replicates o frame de transmissão múltipla e o converte aos frames de unicast do 802.11. Finalmente, um serviço de transmissão múltipla seguro entrega o fluxo de vídeo como o unicast diretamente ao cliente.

Escamação video mais alta em clientes

Aumentos no número de clientes que alcançam o vídeo sobre a pressão aumentada lugar do Wi-fi e a procura na rede. Isto impacta o desempenho e a qualidade. Uma escamação video mais alta é uma medida do número de clientes apoiados pelo controlador ao aperfeiçoar o fluxo de tráfego do prendido à rede Wireless. Com tecnologia de Cisco VideoStream, toda a replicação é feita na borda (no Access point), assim utilizando a rede total eficientemente.

Em qualquer momento a tempo, há somente o fluxo de mídia configurado que atravessa a rede, porque o fluxo de vídeo é convertido ao unicast nos Access point baseados nos pedidos IGMP iniciados pelos clientes. Algumas aplicações do outro fornecedor fazem uma conversão similar do Multicast ao unicast, mas fazem-na incapazmente como evidenciada pela carga posta sobre a rede ligada com fio para apoiar o córrego.

Teoricamente em uma rede non-802.11n com os clientes 2.4GHz e o 5GHz associados, lá podem ser tantos como como 3 ou 4 clientes que olham um fluxo de vídeo do bit de 5M. Com todos os clientes video adicionais, a utilização de canal será capacidade esgotada para fora e a possibilidade dos clientes que deixam cair ou que perdem a Conectividade é mais alta.

Com rede 802.11n a escalabilidade dos aumentos dos clientes significativamente devido à Disponibilidade da largura de banda. A escalabilidade do cliente dos clientes com ou sem o canal que liga-se igualmente varia na rede 802.11n. Isto é inexistente em um legado/não em uma rede 802.11n.

Conceitos

Agora você deve ter uma compreensão na funcionalidade da infraestrutura quando VideoStream é configurado. É igualmente importante compreender como os aplicativos de vídeo, os dispositivos do cliente, etc. contribuem para uma sinergia melhor para que o sistema trabalhe. Observou-se em todos os aplicativos da instalação sem fio e os clientes têm um papel igual a jogar para uma entrega fim-a-fim.

Aplicativos

Há hoje disponível dos vários aplicativos de vídeo para a vídeo fluente sobre a rede IP. A fonte do fluxo de vídeo é comum através do prendido e redes Wireless. O controlador está no núcleo ou na distribuição da rede ligada com fio no trajeto como o último repórter para a rede de transmissão múltipla. Alguns dos aplicativos de vídeo que foram testados com VideoStream são discutidos nas próximas seções.

  • Motor da experiência do Cisco media

  • Aplicações de distribuição de conteúdo da Cisco

  • Server/serviços do Windows Media

  • VBrick – Dispositivo H.264

  • Fornalha video

  • Jogador VLC

Motor da experiência do Cisco media

O motor da experiência do Cisco media (MXE) 3500 é um dispositivo facilmente distribuído que integre transparentemente na rede para entregar um conjunto rico de capacidades deprocessamento. Projetado como um componente central da rede Media-pronta de Cisco, Cisco MXE 3500 fornece:

  • Detalhado vive e o Video on Demand (VoD) - os serviços transcoding baseados que permitem que você compartilhe do índice video através de sua rede a virtualmente qualquer tipo de valor-limite

  • Características inovativas do postproduction que transformam o índice video ordinário na saída impressionante da estúdio-qualidade

  • Serviços pioneiros da transcrição do discurso-à-texto

  • Colaboração inovativa com outros aplicativos entregados pelo Cisco suite do Produtos dos media

O resultado é uma plataforma deprocessamento poderosa que permita que os administradores TI aerodinamizem significativamente os custos operacionais associados com a fluência de mídia, a produção dos media, e a distribuição vivas.

Aplicativo da entrega do índice de Cisco

As Aplicações de distribuição de conteúdo da Cisco são os elementos de software dos CD e executam processos satisfeitos sobre os motores da entrega do índice de Cisco, que fornece funções tais como ingerem, armazenamento, pôr em esconderijo, personalização, e fluir. O TV que flui aplicativos da entrega inclui:

  • Aplicação Cisco Vault

  • Cisco TV Streamer Application

  • Aplicação Cisco TV Playout

  • Aplicação Cisco Integrated Streamer-Vault

  • Cisco Content Delivery System Manager

O Internet que flui aplicativos satisfeitos da entrega inclui:

  • Aplicação Cisco Internet Streamer

  • Aplicação de aquisição de conteúdo da Cisco

  • Aplicação do roteador de serviço da Cisco

  • Cisco Content Delivery System Manager

O sistema de entrega do índice de Cisco compreende uns ou vários motores conectados da entrega do índice de Cisco, cada um aperfeiçoado para umas ou várias tarefas tais como o índice ingere, armazenamento, pondo em esconderijo, ou fluindo.

Server do Windows Media

O server do Windows Media flui o índice do áudio digital e do vídeo aos clientes sobre o Internet ou um intranet. Estes clientes podem ser outros computadores ou dispositivos que jogam para trás o índice usando um jogador, tal como Windows Media Player. Ou, podem ser outros computadores que estão dirigindo os serviços do Windows Media (chamados server do Windows Media) esse proxy, põem em esconderijo, ou redistribuem o índice.

O índice que seus córregos do server do Windows Media aos clientes podem ser um córrego vivo ou um arquivo de media digital PRE-gravado. As empresas wireless que entregam serviços de entretenimento de faixa larga wireless usando server escaláveis e seguros do Windows Media usam servidores de mídia.

  • Radiodifusores do Internet que entregam o índice para o rádio, a televisão, o cabo, ou o satélite.

  • Distribuidores do filme e da música que distribuem o índice audio e video em uma maneira segura sem buffer excessivo ou congestionamento de rede.

  • Profissionais IPTV que entregam uma experiência de alta qualidade IPTV nas redes de área local (LAN).

VideoFurnace

A fornalha de Haivision fornece um seguro, fácil de usar, simples distribuir o sistema fim-a-fim para a vídeo ao vivo de codificação e de distribuição aos computadores e às caixas superiores ajustadas, porque criar os canais programados do playback para a empresa TV e o signage, e para gravar o Video on Demand satisfeito e entregando.

A fornalha fornece uma solução de vídeo completa IP. A experiência da visão para alcançar os canais vivos e gravados assim como o índice por encomenda é fornecida para o desktop através “do jogador InStream da pegada zero” e aos monitores e aos indicadores fixos com o Set Top Box de Stingray™. Com controle da grão fina de todos os visores e indicadores, a fornalha é o sistema ideal para controlar e distribuir o vídeo da empresa firmemente, para estabelecer o signage HD durante todo uma facilidade, para fornecer o material por encomenda, e para capturar, organizar, e rever eventos.

H.264 fim-a-fim, a fornalha fornece capacidades fim-a-fim sem emenda. O server portal da fornalha controla a distribuição direta e segura do vídeo SD e HD H.264 e do MPEG-1, MPEG-2, vídeo MPEG-4 SD ao jogador InStream e ao Set Top Box da arraia-lixa. O gerente do playback da fornalha apoia os canais programados para vive e broadcasts de vídeo prerecorded IP e signage digital. O servidor de mídia da fornalha permite o video-on-demand. Leveraging as eficiências da compressão H.264 video, o media alto da definição está disponível a todos os usuários. Além disso, a fornalha incorpora o suporte direto para os codificadores revolucionários do Barracuda™ e do Makito™ H.264 de Haivision que entregam o índice vivo SD e HD em taxas de bits de 150 kbps ao 15 Mbps.

Planeamento da pilha

O planeamento da pilha é um aspecto principal que precise de ser considerado para um vídeo ou um desenvolvimento da Voz. O planeamento da pilha não é tão simples quanto montando um Access point em um lugar apropriado e fornecendo a conectividade Wireless. Isto mudou ao longo dos últimos anos enquanto a cobertura sem fio patente se transformou uma exigência. Há hoje disponível de diversas ferramentas para executar um planeamento da célula adequada. O Sistema de controle sem fio da Cisco tem uma ferramenta do planejador que seja muito eficaz.

Além dos critérios wireless normais do planeamento há alguns mais parâmetros que precisam considerado no planeamento da pilha para o vídeo. Estas são a latência, o tremor e a perda de pacotes. Destacando o mesmos na tabela abaixo e igualmente categorizando o mesmos com valores realísticos do campo, você pode ver que o planeamento da pilha é muito eficaz.

  Latência Tremulação Transferência Perda de pacote
Teleconferência de vídeo Alto Alto Baixa Médio
Teleconferência de vídeo HD Alto Alto Alto Alto
Video on Demand Baixa Baixa Médio Baixa
Vídeo fluente viva Médio Médio Médio Alto

A fim determinar o aplicativo de vídeo em termos dos valores, esta tabela foi reconhece extensamente para aplicativos de vídeo:

Métrico Colaboração video Signage de Digitas TelePresence Vigilância por vídeo
Latência (segundos) 150 200 150 300
Tremulação 30 10 10 10
Perda de pacotes (%) 1% .05% .05% .05%

Considere um Access point de Cisco CAPWAP instalado com a versão de código a mais atrasada em um ambiente de teste limpo sem a interferência em um ambiente de escritório. Quando a taxa, a intensidade de sinal e o ruído da associação de cliente são medidos em vários pontos os dados olham como segue. As medidas abaixo são capturadas com ligação do canal e sem ligação do canal. Observe a intensidade de sinal e o ruído em todos os cenários de teste. Isto dar-lhe-á uma compreensão básica da variação do sinal e propalá-la-á. As diretrizes do planeamento não são baseadas nos dois valores considerados, mas igualmente tomam na consideração a interferência do co-canal, taxas de dados do cliente, potência de transmissão do cliente, capacidade de canal total. Estes estarão planeando considerações quando a densidade do Access point e a contagem do cliente aumentam.

5Ghz com ligação do canal

Distância do Access point (ft) Taxa da associação de cliente (Mbps) Intensidade de sinal (- dBm) Ruído (- dBm)
5 276 42 72
20 250 44 75
40 243 47 77
80 216 59 89
100 198 64 90

5Ghz sem ligação do canal

Distância do Access point Taxa da associação de cliente Intensidade de sinal Ruído
5 144 41 71
20 144 51 79
40 130 55 81
80 108 60 90
100 87 77 93

rádio 2.4Ghz sem ligação do canal

Distância do Access point Taxa da associação de cliente Intensidade de sinal Ruído
5 144 30 61
20 144 32 62
40 121 49 77
80 108 53 80
100 84 56 88

A configuração do controle de admissão da chamada (CAC) para a sobreassinatura do canal e garante a largura de banda configurada dos media. A configuração CAC igualmente parará usuários novos dos media, daqui protege os usuários atuais de ser afetada quando oversubscribed.

As configurações CAC para VideoStream são um ponto de ajustamento da chave que equilibre os usuários da Voz, do vídeo e dos dados em um media wireless usando a rede de Cisco Unified Wireless 7.0. Esta configuração é específica de rádio e pode ser permitida em rádios ambos os 2.4 gigahertz gigahertz e 5. A configuração CAC pode ser permitida clicando o SEM FIO > o 802.11a/n ou o 802.11b/g/n > os media.

cuwns-vidstrm-guide-10.gif

À revelia a Voz e os ajustes video CAC são desabilitados. Todas as configurações que forem feitas aqui aplicar-se-ão diretamente às configurações da Voz e do vídeo. Em curto, media =Voice+Video. Isto à revelia é configurado a um máximo de 85% da largura de banda de rádio total. A 15% permanecendo da largura de banda de rádio é tráfego de melhor esforço (dados). Segundo o uso dos dados, da Voz e do vídeo recomenda-se mudar estes valores. Os ajustes dos media podem ser mudados clicando a aba dos media. Recomenda-se manter valores padrão até que haja uma necessidade absoluta para mudar estes valores.

Os ajustes da Voz e do vídeo podem ser ajustados basearam nos serviços do tipo de rede proporcionados. Se a Voz é o aplicativo principal na rede os valores CAC podem variar de 5 - 85%. Há igualmente uma largura de banda vagueando Reserved que seja incluída na configuração de voz acima. Com um ajuste máximo CAC de 85% em um rádio 5Ghz, o sistema Wireless pode acomodar aproximadamente 21 chamadas de voz. Similarmente em um rádio 2.4Ghz com um ajuste máximo CAC de 85%, o sistema pode acomodar aproximadamente 13 chamadas de voz.

Em uma nota similar se você comuta a um vídeo CAC, com um máximo de 85% o sistema Wireless pode acomodar aproximadamente 22 clientes em um rádio 5Ghz. Com um ajuste máximo CAC de 85% em um rádio 2.4 gigahertz, o sistema Wireless pode acomodar os clientes 10. A tabela abaixo dará uma ideia do como os sistemas podem atuar sob configurações diferentes. Estes valores são com ligação do canal no rádio 5Ghz e uma configuração video da taxa de bits de bit de 3M.

Valor do vídeo CAC Clientes video Chamada de Voz Valor da Voz CAC
85 22 0 0
65 15 6 20
45 10 11 40
25 5 16 60
5 2 20 80

Nota: Estes resultados de teste são documentados para CUWN 7.2 após a melhoria da agregação, da proteção e da programação esperta dos pacotes de vídeo ao cliente.

Valor do vídeo CAC Valor da Voz CAC Taxa de bits video Clientes
85 0 1.5 ~2 M 51
85 0 5M 30
85 0 10M 20

Nota: Todos os clientes no teste são similares na configuração com um adaptador Wireless 3X3 802.11a/b/g/n. O ambiente de teste é claro de todas as interferências e igualmente interferências wireless de NON-WiFi.

Os rádios são capazes de segurar 255 associações. Porque o media wireless é mídias semi-duplex compartilhadas haverá uma disputa pelos clientes. Enquanto os clientes se movem mais longe do rádio, a taxa de transferência diminui. Promova abaixo da borda da pilha que as taxas de dados do cliente deixam cair ao mais baixo, e daqui introduziu novas tentativas demais. Mesmo que o rádio possa permitir um número mais alto de associações, recomenda-se limitar os clientes a menos de 60 pelo Access point para aplicativos de dados normais. Contudo, quando você tem a Voz e os serviços de vídeo no Access point recomenda-se planear a disposição do Access point tais que a intensidade de sinal do adaptador cliente não cai abaixo -60db ou taxa equivalente da associação de cliente. Também, considere fornecer uma pilha de 15~20% que sobrepõe para assegurar-se de que haja uma entrega lisa do aplicativo de vídeo de um Access point a outro quando os clientes estão vagueando.

Qualidade de Serviço

Normalmente, todo o vídeo que hospeda fontes assegura-se de que a marcação DSCP esteja marcada apropriadamente na face da tela. Se o servidor de vídeo é encontrado localmente e não tem que atravessar nenhuns limites de roteador, os pacotes marcados DSCP estão garantidos para ser os mesmos. Às vezes quando os pacotes de vídeo estão atravessando limites roteados, as marcações DSCP tendem a ser restauradas. CUWN assegura-se de que os pacotes de vídeo tenham a marcação correta DSCP no lado wireless. Isto pode ser observado no Access point porque os contadores de fila video estarão incrementando. Se não há nenhuns tráfego de vídeo e somente tráfego de melhor esforço, os contadores respectivos incrementarão. Toda a operação discutida será eficaz somente se o perfil video no controlador é traçado ao protocolo 802.1p com um valor etiquetado do 5.

cuwns-vidstrm-guide-11.gif

Configuração

VideoStream pode ser distribuído em uma empresa existente prendida largamente e na rede Wireless. A aplicação e os custos de manutenção totais de um vídeo sobre a rede Wireless são reduzidos extremamente. A suposição é que a rede ligada com fio é Multicast permitido. A fim verificar que uma distribuição ou um switch de acesso são parte da rede da camada 3, conecte uma máquina cliente ao switchport e verifique se a máquina cliente pode se juntar a uma alimentação multicast.

Show run | inclua o Multicast indicará se o Multicast é permitido no switch de camada 3. Se não permitido para o Multicast você pode permitir o Multicast adicionando o comando seguinte no interruptor.

cuwns-vidstrm-guide-conf0.gif

cuwns-vidstrm-guide-conf1.gif

Segundo o tipo de configuração do roteamento do independente de protocolo (PIM) na rede ligada com fio, o switch de camada 3 é configurado para o modo escasso de PIM ou o modo denso de PIM. Há igualmente um modo híbrido, o modo escasso-denso PIM que é amplamente utilizado.

cuwns-vidstrm-guide-conf2.gif

As relações do igmp da mostra IP indicarão as relações SVI que estão participando na sociedade IGMP. Este comando igualmente mostrará a versão do IGMP configurada no interruptor ou no roteador. A atividade IGMP na relação pode igualmente ser verificada sob a forma de junta-se e sae-se pelos clientes.

cuwns-vidstrm-guide-conf3.gif

A configuração acima pode ser verificada executando o comando show ip mroute no switch de camada 3.

cuwns-vidstrm-guide-conf4.gif

A captação acima tem determinadas entradas a que precise de ser olhado dentro. A notação especial de (fonte, grupo), pronunciou “S, G” onde a fonte “S” é o endereço IP de origem do servidor de transmissão múltipla e “G” é o endereço de grupo de transmissão múltipla que um cliente pediu se juntar. Se a rede tem muitas fontes você verá em seu Roteadores (S, G) para cada um do endereço IP de origem e dos endereços de grupo de transmissão múltipla. Esta captação igualmente tem a informação do que parte e das interfaces de entrada.

Hardware e software wireless apoiado

VideoStream é apoiado em todos os controladores do Wireless LAN. Isto inclui o controlador de Cisco 5500, o controlador de Cisco 4400, o controlador de Cisco 2100 e o WiSMs. VideoStream é apoiado igualmente no Cisco 2504 autônomo e no controlador de Cisco WiSM-2. O IGMPv2 é a versão suportada em todos os controladores.

VideoStream é apoiado em todos os Access point mais novos. Isto inclui modelos de Access point do Cisco Aironet série 3500 Access point, do Cisco Aironet série 1260 Access point, do Cisco Aironet série 1250, de séries do Cisco Aironet 1240AG Access point, Access point do Cisco Aironet série 1140, de série do Cisco Aironet 1130AG Access point e de 1040 Series do Cisco Aironet Access point.

A característica de VideoStream é introduzida na versão CUWN 7.0 do código do controlador e apoiada em umas versões mais atrasadas do software do controlador.

Configuração de controle

A característica de VideoStream exige o Multicast permitido no controlador. O Multicast no controlador pode ser permitido em dois modos: Multicast-unicast e Multicast-Multicast. Quando o Protocolo IP multicast é permitido, o controlador entregou pacotes de transmissão múltipla aos clientes do Wireless LAN fazendo cópias dos pacotes de transmissão múltipla, a seguir enviando os pacotes através de um túnel de protocolo de pouco peso do Access point do unicast a cada Access point conectado ao controlador. A entrega do unicast coloca uma carga pesada no AP, assim como a unidade de processamento da rede de controlador, devido ao dilúvio dos pacotes que precisam de ser replicated para baixo aos Access point.

O método de entrega do Multicast-unicast de Cisco é de uso geral pelos clientes que “somente” queira fornecer o Multicast sobre sua rede Wireless, ou a rede não apoia o Multicast. Recomenda-se para que os clientes evitem usar o método do Multicast-unicast da entrega. Este método é utilização de processador segundo o número de fluxos de transmissão múltipla a ser apoiados. Neste modo cada pacote de transmissão múltipla deve ser replicated a todos os Access point que se juntaram ao controlador de qualquer maneira se há um cliente que pede o endereço de grupo de transmissão múltipla.

O desempenho do Multicast foi aperfeiçoado com a introdução de modo do Multicast-Multicast. Em vez de usar o unicast para entregar cada pacote de transmissão múltipla sobre o túnel CAPWAP a cada Access point, um grupo de transmissão múltipla CAPWAP é configurado para entregar o pacote de transmissão múltipla. Isto permite que o Roteadores na rede use técnicas padrão do Multicast para replicate e entregar pacotes de transmissão múltipla aos Access point. Para o grupo de transmissão múltipla CAPWAP, o controlador transforma-se o origem de transmissão múltipla e os Access point assentam bem nos receptores de transmissão múltipla. O desempenho do Multicast é aumentado enquanto os Access point aceitam perguntas IGMP somente do roteador e dos pacotes de transmissão múltipla com um endereço IP de origem do controlador com que estão associados atualmente.

cuwns-vidstrm-guide-12.gif

Nota: O Protocolo IP multicast usa a escala da classe D dos endereços IP 224.0.0.0 com 239.255.255.255. Os intervalos de endereço reservados, ligam o endereço de multicast local (224.0.0.0 com 224.0.0.255) são para o uso dos protocolos e não podem ser usados. O resto do endereço da classe D, o endereço de multicast administrativamente no escopo (239.0.0.0 com 239.255.255.255) pode ser usado configurando as redes IP para o Multicast.

A configuração acima pode igualmente ser configurada usando linhas de comando em um par etapas.

cuwns-vidstrm-guide-conf5.gif

Nota: Recomenda-se usar uns endereço de multicast/controlador originais.

Uma configuração mais importante no controlador é permitir o IGMP Snooping. A possibilidade do IGMP Snooping no controlador ajuda a recolher relatórios IGMP dos anfitriões e envia a cada AP uma lista de anfitriões que estão escutando qualquer grupo de transmissão múltipla. Os pacotes de transmissão múltipla AP então para a frente somente 2 aqueles anfitriões.

O intervalo IGMP e o intervalo da pergunta IGMP ajudam o IGMP Snooping a ser mais eficaz. Quando o intervalo IGMP expira, o controlador envia uma pergunta em todos os SSID que causam os clientes que estão escutando o grupo de transmissão múltipla para enviar um pacote de volta ao controlador. O intervalo da pergunta IGMP é como frequentemente o controlador envia uma pergunta a todos os SSID. Se o intervalo IGMP está ajustado a 60 segundos e o intervalo da pergunta IGMP está configurado a 20, haverá três perguntas.

cuwns-vidstrm-guide-13.gif

cuwns-vidstrm-guide-conf6.gif

Permitindo VideoStream – Global

A característica de VideoStream pode ser permitida em três lugares diferentes segundo a aplicação da característica. Isto ajuda administradores de rede a controlar a possibilidade da característica de VideoStream no controlador.

A característica deve ser permitida globalmente no controlador verificando a aba sob o Sem fio > o fluxo de mídia > o general. Permitindo a característica aqui povoará alguns dos parâmetros de configuração no controlador para VideoStream.

A característica de VideoStream pode igualmente ser permitida sob o tipo PHY. O cliente tem a flexibilidade permitir VideoStream somente no rádio 5Ghz ou no rádio 2.4Ghz ou em ambos.

O botão direto do Multicast sob WLAN > QoS aparece sobre se a característica é permitida globalmente. Isto dá a flexibilidade permitir a característica de VideoStream pelo SSID.

cuwns-vidstrm-guide-14.gif

cuwns-vidstrm-guide-conf7.gif

Adicionar a configuração do fluxo de transmissão múltipla

As alimentações multicast podem ser permitidas de participar em RRC somente se a alimentação multicast é configurada no controlador. A fim adicionar um fluxo de transmissão múltipla ao controlador, o clique flui sob MediaStream.

Porque mencionado lhe é necessário que o administrador está ciente da fluência característica video através de um controlador. Um equilíbrio verdadeiro deve ser desenhado quando a configuração dos córregos é adicionada. Por exemplo, se a taxa de bits do córrego varia entre 1200 kbps e 1500 kbps o córrego deve ser configurado para uma largura de banda de 1500kbps. Se o córrego é configurado para 3000 kbps então você terá pouco cliente video prestado serviços de manutenção pelo Access point. Similarmente, configurar para 1000 kbps causará o pixelization, a experiência audio e ruim ruim do usuário.

Há alguns moldes preconfigured na configuração do córrego que pode ser usada. É necessário aplicar o julgamento similar ao selecioná-los. Algumas das configurações são capturadas já no mais adiantado parte do documento (admissão e prioridade do córrego). Se não usando os moldes, há algumas mais configurações que podem ser usadas para aumentar a experiência do usuário. O tamanho médio do pacote pode ser mudado para combinar a vídeo fluente. O controle da reserva de recurso pode permitido para a atualização periódica de modo que os sistemas possam verificar para ver se há a saúde muito frequentemente. Isto pode igualmente ser desabilitado para permitir RRC de ser executado somente na admissão. A prioridade do córrego pode igualmente ser ajustada a um alto valor para a prioridade do córrego. Um valor configurado de 8 permitirá que o córrego seja dado a prioridade e não colidindo para baixo ao melhor esforço.

Em toda a violação das políticas precedentes, o córrego pode ser degradado ao melhor esforço ou pode ser deixado cair. Recomenda-se degradar ao melhor esforço.

cuwns-vidstrm-guide-15.gif

cuwns-vidstrm-guide-conf8.gif

O endereço IP de Um ou Mais Servidores Cisco ICM NT do começo do destino multicast e o endereço IP de Um ou Mais Servidores Cisco ICM NT da extremidade podem ser o mesmo endereço como mostrado acima. Se pode igualmente configurar uma escala do endereço de multicast no controlador. Não há nenhuma limitação no número de entradas dos endereços de multicast ou no número de entradas do córrego. O endereço IP de Um ou Mais Servidores Cisco ICM NT do começo pode ser 239.4.5.1 e o endereço IP de Um ou Mais Servidores Cisco ICM NT da extremidade pode ser 239.4.5.254.

As configurações de VideoStream podem ser permitidas em ambos os rádios nos Access point. As configurações no rádio podem ser configuradas ou alterado somente com os rádios desabilitados. Algumas configurações igualmente exigirão os WLAN /SSID ser desabilitadas.

Nota: Recomenda-se fazer toda a configuração exigida nos rádios quando desabilitado.

Permitindo VideoStream – rádio do 802.11 a/n

cuwns-vidstrm-guide-16.gif

Clique o SEM FIO > o 802.11 a/n > media > media para permitir o VideoStream e para adicionar configurações CAC/QOS. As configurações similares puderam ser exigidas no rádio do 802.11 b/g/n, segundo o tipo de serviço proporcionado no rádio.

VideoStream é desabilitado à revelia nos rádios. A característica pode ser permitida verificando o Multicast direto permite. O rádio igualmente pode igualmente ser configurado para o número de clientes que podem se juntar a um fluxo de transmissão múltipla puxando abaixo do número máximo direto do Multicast de córregos. Este pode ser qualquer um ajustou-se ao automóvel para permitir que todos os clientes juntem-se ao fluxo de transmissão múltipla. A contagem do cliente no rádio pode igualmente ser controlada configurando um valor de 1-20.

cuwns-vidstrm-guide-17.gif

cuwns-vidstrm-guide-18.gif

O unicast Redirect video é permitido à revelia. Isto permitirá o fluxo de tráfego de vídeo do unicast aos clientes Wireless.

RRC admitirá clientes para juntar-se a um córrego depois que os critérios da passagem (explicados mais cedo) são conseguidos. Os clientes admitidos terão uma prioridade de QoS de 4. Não permitidos aos clientes que não passam os critérios RRC serão deixados cair e juntar-se ao córrego. Contudo, isto pode ser rejeitado permitindo a melhor admissão de QoS do esforço. Agora todos os clientes Wireless pedidos juntar-se a um córrego serão admitidos ao fluxo de transmissão múltipla, mas alguns deles terão uma prioridade de QoS de 0. A largura de banda dos media é ajustada atualmente a 85% à revelia.

A largura de banda dos media é a soma da Voz e do tráfego de vídeo em uma interface de rádio. O mais baixo que um cliente pode deixar cair no rádio é 6000 kbps para juntar-se a uma vídeo fluente. Se há os clientes que precisam de ser restringidos de se juntar um córrego abaixo de uma determinada taxa PHY este valor podem ser mudados. O valor é 6000 à revelia. O por cento da nova tentativa máxima é, à revelia, grupo a 80%. O sistema mantém-se a par das novas tentativas no rádio. Se as novas tentativas são maiores do que o valor configurado o cliente não estará permitido juntar-se ao córrego.

Nota: Recomenda-se manter os valores padrão.

Clique o SEM FIO > o 802.11 a/n > media > vídeo para permitir o controle CAC/Admission. Permita o controle de admissão para o vídeo.

Segundo o tipo de serviço que precisa de ser permitido no rádio configurar um valor para a largura de banda máxima RF. Este de valor acrescentado aqui decidirá o número dos clientes video a ser reservados juntar-se a um fluxo de transmissão múltipla configurado no rádio (refira o valor da Voz/vídeo CAC da tabela). Por exemplo, um valor máximo de 80% permitirá a vinte clientes Wireless o córrego com uma taxa de bits de bit de 5M.

cuwns-vidstrm-guide-19.gif

SEM FIO > 802.11 do clique a/n > media > Voz para permitir o controle da Voz CAC/Admission. Permita o controle de admissão para a Voz. Este de valor acrescentado aqui decidirá o número de chamadas de voz que serão permitidas no rádio (refira o valor da Voz/vídeo CAC da tabela).

cuwns-vidstrm-guide-20.gif

O rádio foi desabilitado para adicionar as configurações de VideoStream. Permita o rádio 802.11a.

Permitindo VideoStream – rádio 802.11b/g/n

A configuração acima pode ser repetida no rádio 802.11b/g/n. Desabilite o rádio 802.11b/g/n primeiramente antes que todas as mudanças estejam feitas.

cuwns-vidstrm-guide-21.gif

Permitir a característica de VideoStream em 802.11b/g/n precisa uma atenção mais próxima porque haverá uma densidade mais alta do cliente. É necessário atribuir uma suficiente quantidade de largura de banda para que os clientes Wireless juntem-se ao fluxo de transmissão múltipla. Equilibrando os dados, os clientes da Voz e do vídeo no rádio 802.11b/g/n devem ser planeados bem adiantado assim as configurações, uma vez que aplicados, não causarão questões principal.

Nota: BandSelect e ClientLink são as duas características que prestarão serviços de manutenção aos clientes Wireless e reduzem alguns dos clientes no rádio 2.4 gigahertz.

Repita as etapas mostradas nos três screenshots acima no rádio 802.11b/g/n. Os screenshots são mostrados abaixo.

cuwns-vidstrm-guide-22.gif

A característica de VideoStream é desabilitada à revelia nos rádios. Clique o SEM FIO > o 802.11 b/g/n > media > media. Verifique o Multicast direto permitem a característica. Puxe para baixo o número máximo direto do Multicast de córrego para configurar um valor 1 20, ou deixe-o no padrão.

O unicast Redirect video é permitido à revelia. Isto permitirá o fluxo de tráfego de vídeo do unicast aos clientes Wireless.

RRC admitirá clientes para juntar-se a um córrego depois que os critérios da passagem (explicados mais cedo) são conseguidos. Os clientes admitidos terão uma prioridade de QoS de 4. Não permitidos aos clientes que não passam os critérios RRC serão deixados cair e juntar-se ao córrego. Contudo, isto pode ser rejeitado permitindo a melhor admissão de QoS do esforço. Agora todos os clientes Wireless pedidos juntar-se a um córrego serão admitidos ao fluxo de transmissão múltipla, mas alguns deles terão uma prioridade de QoS de 0.

A largura de banda dos media é ajustada atualmente a 85% à revelia. A largura de banda dos media é a soma da Voz e do tráfego de vídeo em uma interface de rádio. O mais baixo que um cliente pode deixar cair no rádio é 6000 kbps para juntar-se a uma vídeo fluente. Se há os clientes que precisam de ser restringidos de se juntar um córrego abaixo de uma determinada taxa PHY este valor podem ser mudados. O valor é 6000 à revelia. O por cento da nova tentativa máxima à revelia é ajustado a 80%. O sistema mantém-se a par das novas tentativas no rádio e se as novas tentativas são maiores do que no valor configurado que não será permitido ao cliente se juntar ao córrego.

Clique o SEM FIO > o 802.11 b/g/n > media > vídeo para permitir o controle CAC/Admission. Permita o controle de admissão para o vídeo.

Segundo o tipo de serviço que precisa de ser permitido no rádio, configurar um valor para a largura de banda máxima RF. O de valor acrescentado aqui decidirá o número do cliente video que será permitido se juntar a um fluxo de transmissão múltipla configurado no rádio (refira o valor da Voz/vídeo CAC da tabela).

cuwns-vidstrm-guide-23.gif

Clique o SEM FIO > o 802.11 b/g/n > media > Voz para permitir o controle da Voz CAC/Admission. Permita o controle de admissão para a Voz. O de valor acrescentado aqui decidirá o número de chamadas de voz a ser permitidas no rádio (refira o valor da Voz/vídeo CAC da tabela).

cuwns-vidstrm-guide-24.gif

Permita os rádios de permitir que os clientes associem.

Permitindo VideoStream - WLAN

Uns ou todos os WLAN/SSID configurado pode ser permitido para a vídeo fluente com VideoStream. Esta é uma outra etapa de configuração que possa controlar a possibilidade da característica de VideoStream. A possibilidade ou a desabilitação da característica de VideoStream são sem interrupções. Clique WLAN > <WLAN ID> > QoS.

cuwns-vidstrm-guide-25.gif

Configurar Qualidade de Serviço a Gold(video) para fluir o vídeo ao cliente Wireless em um valor do QoS do ouro (4). Isto permitirá somente a qualidade de vídeo do serviço aos clientes Wireless juntados a um córrego configurado no controlador. O resto dos clientes será permitido para QoS apropriado. Permita o Multicast direto no WLAN verificando a característica como mostrado acima. Isto permitirá o WLAN de prestar serviços de manutenção a clientes Wireless com a característica de VideoStream.

Todos os clientes Wireless que pedem para se juntar a um córrego serão atribuídos a prioridade de QoS video na admissão. A vídeo fluente do cliente Wireless antes de permitir a característica no WLAN estará fluindo usando o Multicast normal. A possibilidade da característica comutará os clientes Multicast-diretos automaticamente no intervalo seguinte do IGMP Snooping.

O Multicast do legado pode ser permitido no WLAN não verificando a característica direta do Multicast. Isto mostrará que a vídeo fluente dos clientes Wireless reage do Modo multicast normal.

Verificando a funcionalidade de VideoStream

Certifique-se que os clientes Wireless estão associados ao Access point, e configurados para uma relação correta. Como visto na captação abaixo há três clientes associados a um Access point. Todos os três clientes têm um endereço IP de Um ou Mais Servidores Cisco ICM NT de VLAN124 (testclients).

cuwns-vidstrm-guide-26.gif

Os clientes associados têm um endereço IP de Um ou Mais Servidores Cisco ICM NT e uma boa Conectividade do uplink ao Access point.

cuwns-vidstrm-guide-27.gif

Não há nenhum cliente que se juntou ao fluxo de transmissão múltipla. Há somente a entrada do controlador com o endereço de grupo de transmissão múltipla configurado registrado no interruptor.

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

Não há nenhum fluxo de vídeo na rede ligada com fio, daqui em nenhumas entradas para (S, G) fonte, endereços de grupo. Enable que flui na face da tela conectando um servidor de vídeo com um endereço de multicast configurado 239.4.5.6. A captação no interruptor será mais do que o que foi observado mais cedo.

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#

Debugar - Comute

Junte-se a um cliente Wireless à vídeo fluente do Multicast. Também, a captação debuga o bcast que todos permitem do controlador. A captação debugar tem a informação no pedido do cliente, no endereço de grupo, no estado do pedido e na atualização.

*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

O cliente Wireless com o MAC address 00:21:5d:ac:d8:98 enviado um IGMP v2 junta-se sob a forma de um relatório a um endereço do córrego de 239.4.5.6. O cliente juntou-se ao grupo com um qos=4 e foi mudado a um estado PERMITIDO (refira o diagrama de fluxo).

Clique o MONITOR > o Multicast > e o MGID para o endereço de fluência 239.4.5.6. Observa-se que o MAC address do cliente Wireless está em um estado permitido Multicast-direto. A prioridade de usuário de QoS é 4. Isto mostra o cliente que processa os pacotes de vídeo na fila video.

cuwns-vidstrm-guide-28.gif

cuwns-vidstrm-guide-conf9.gif

Debugar - Controlador

O processamento do pedido de um cliente Wireless em um controlador pode claramente ser compreendido permitindo debuga no controlador. Permitido debuga é capturado igualmente no controlador. Há um pedido 3646 criado para o cliente com o MAC address 0021.5dac.d898. Todo o fluxo de dados é WRT ao cliente com o MAC address 0021.5dac.d898 é mostrado debugar abaixo. O RRC retrocede dentro para validar os recursos para o rádio associado. A validação é bem sucedida e o cliente é admitido baseou nos valores validados. O córrego está ainda em um estado obstruído até que o córrego esteja admitido e o cliente não receber nenhum vídeo. O cliente ligará a vídeo fluente uma vez que recebe uma resposta da junta.

Promova pedidos do mesmo cliente será validado. Porque o cliente já está fluindo o motor RRC responderá com uma mensagem “já admitida “. Isto não impedirá o desempenho do cliente Wireless.

(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) >

Comandos show – Controlador

Alguns dos comandos show foram capturados mais cedo neste documento. Esta seção da captação é somente para a referência. Para mais detalhes nos comandos, refira o guia de referência dos comandos da liberação 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) >

Conclusão

Característica de VideoStream dos suportes de software CUWN 7.2 no hardware de controle mais novo. Isso inclui:

  • Controladores do Cisco 5500 Series

  • Módulo de serviço Wireless - 2

  • Controladores do Cisco 2500 Series *

  • Cisco ISR-G2 com módulo SRE *

Nota: * — Os números de desempenho diferem nos Access point non-802.11n.

Característica de VideoStream dos suportes de software CUWN 7.0 no hardware de controle mais novo. Isso inclui:

  • Controladores do Cisco 5500 Series

  • Controladores do Cisco 4400 Series

  • Controladores do Cisco 2100 Series

  • Módulo de serviço Wireless

VideoStream é apoiado igualmente no Cisco 2504 autônomo e controlador de Cisco WiSM-2.

Característica de VideoStream dos suportes de software CUWN 7.2 em todos os Access point 802.11n mais novos e em alguns Access point do legado. Isso inclui:

  • Access point do 3600 Series do Cisco Aironet

  • Access point do Cisco Aironet série 3500

  • Access point do Cisco Aironet série 1260

  • Access point do Cisco Aironet série 1250

  • Access point da série do Cisco Aironet 1240AG**

  • Access point do Cisco Aironet série 1140

  • Access point da série do Cisco Aironet 1130AG**

  • Access point do 1040 Series do Cisco Aironet

Nota: ** — A capacidade do cliente varia nos controladores baixo da gama.

A característica de VideoStream pode fluir o vídeo sobre o hardware do Cisco Unified Wireless e fornecer uma qualidade superior. A configuração estática CAC fornecerá o controle do cliente Wireless nos rádios. A característica permite o Multicast que flui sobre o Sem fio na paridade com o Multicast que flui em clientes prendidos. O Multicast que flui aos clientes Wireless com IGMP junta-se ao pedido somente e a replicação é feita somente nos Access point que conservam assim a largura de banda nas portas de uplink da distribuição e dos switch de acesso.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 112889