BRPI0418412B1 - Method and arrangement for control of access in a multi-diffusion system - Google Patents

Description

“MÉTODO E ARRANJO PARA CONTROLE DE ACESSO EM UM SISTEMA DE MULTIDIFUSÃO” CAMPO TÉCNICO DA INVENÇÃO A presente invenção relaciona-se a métodos e arranjos para controle de acesso em um sistema de multidifusão quando dados são distribuídos de uma fonte para pelo menos dois usuários.

DESCRIÇÃO DA TÉCNICA RELACIONADA É possível enviar vídeo através de redes de pacote tais como redes de IP e Ethernet. Como o fluxo de pacote precisado para produzir as imagens em movimento na tela de TV tem largura de banda considerável, muitas redes não têm largura de banda total suficiente para prover fluxos de dados de vídeo únicos para cada usuário. Para programas de TV vistos por vários usuários (os recebedores), é suficiente enviar um fluxo de pacote da fonte, e duplicar este fluxo só em pontos na rede onde há mais de uma porta de saída, que conduz a um espectador. De acordo com este esquema, qualquer ligação entre um recebedor e a fonte leva exatamente uma cópia do fluxo de pacote. Uma ligação que não está entre a fonte e um recebedor não leva o fluxo de pacote. Esta técnica é chamada multidifusão. Multidifusão é um modo valioso de economizar largura de banda quando dados são para serem enviados para vários recebedores ao mesmo tempo.

Em alguns sistemas de multidifusão, controle de quais ligações o pacote de fluxo é copiado fica com os recebedores. Fluxos de dados são endereçados para endereços de destino bastante abstratos. Estes endereços não representam conjuntos estáticos de destinos. Eles são etiquetas de identificação, que os usuários e a rede usam ao negociar sobre onde os fluxos são para serem copiados. Estes endereços são chamados endereços de multidifusão. De acordo com alguns protocolos para negociar sobre fluxos de multidifusão, fontes enviam pacotes endereçados com endereços de multidifusão na rede. Outros nós se tomam recebedores do fluxo de multidifusão pedindo para ser assim. IGMP é um protocolo para hospedeiros em redes de IP para negociar com chaves de Ethernet através de quais fluxos de multidifusão eles estão para receber. Em algumas redes, há regiões que não têm recursos suficientes para transferir todos os fluxos de multidifusão, que os nós poderiam pedir. Isto é razoável desde que multidifusão está prestes a operar grandes fluxos de dados. Ou, posto de outro modo, se houvesse largura de banda suficiente para todos os fluxos de dados em todos os lugares, não haveria uma necessidade por multidifusão. A esperança dos construtores de tais redes é que pedidos serão congruentes suficientemente (nós perto de outro pedem os mesmos fluxos de multidifusão a alguma extensão) para os usuários serem satisfeitos suficientemente. Os recursos que podem ser limitados incluem largura de banda total e o número total de fluxos.

Para o caso quando a rede não é capaz de cumprir todos os pedidos para fluxos de multidifusão, há necessidade por um árbitro ou dispensador de recursos. Um aparelho de transmissão de pacote é exposto na Patente US 2003/0043840. Um árbitro de pacote seleciona pacotes por um algoritmo prescrito e pede transmissão do pacote. A patente US descreve um sistema bastante estático onde necessidade atual não é levada em consideração e onde imparcialidade é posta de lado. Como a carga em uma rede é dependente de congruência de pedidos, as técnicas usadas para alocação de recurso no caso de unidifusão não podem ser aplicadas diretamente. No caso de unidifusão, a carga na rede pode ser calculada adicionando as cargas causadas por usuários individuais. No caso de multidifusão, pedir um novo fluxo adiciona o novo fluxo à carga, enquanto pedir um fluxo já sendo transmitido para outro usuário conectado ao mesmo nó de rede adiciona pouca ou nada à carga neste nó. Portanto, os métodos para limitar a utilização de recurso para usuários de unidifusão não podem ser aplicados a usuários de multidifusão com eficiência razoável. Limites de largura de banda suficientemente baixos para assegurar que o sistema não seja sobrecarregado resultariam em sub-utilização severa dos recursos de rede. SUMÁRIO DA INVENÇÃO A presente invenção resolve os problemas relacionados a conflitos de recurso em um sistema de multidifusão. Os problemas são resolvidos pela invenção limitando a acessibilidade de largura de banda para usuários antes que conflitos de recurso ocorram.

Mais em detalhes, os problemas são resolvidos pela invenção por um método para controle de acesso no sistema de multidifusão quando dados são distribuídos de uma fonte para usuários em uma ligação comum por um nó. O nó inclui um árbitro de pedido arranjado para selecionar dados da fonte aos usuários. O método inclui as etapas seguintes: Designar um peso a cada usuário associado com o nó, quais pesos determinam a largura de banda permitida de cada usuário isto é, a largura de banda permitida usar fora de largura de banda disponível na ligação comum.

Receber um pedido para se unir a uma sessão de multidifusão, de um usuário ao nó.

Comparar no nó, uso de largura de banda real pelo usuário calculado como a soma da parte de largura de banda do usuário de cada sessão usada na ligação comum incluindo o novo pedido, com a largura de banda permitida do usuário.

Uma vantagem da invenção é que negação de acesso afeta usuários fortemente como uma limitação de quanta informação de multidifusão eles obtém acesso a mais que afetando usuários que estão tentando ir de nenhuma informação para alguma informação. Isto significa uma probabilidade mais alta de sucesso para usuários que estão tentando obter seu primeiro canal ao custo de usuários obtendo uma probabilidade mais baixa de ver muitos canais.

Outra vantagem é que um número mais alto de canais é feito disponível para aqueles que vêem canais, que também são vistos por outros. Assim, a habilidade para carregar a rede de distribuição é igualada. Usuários obtêm oportunidades mais iguais. Ou melhor, o operador obtém controle através das oportunidades que os espectadores obtêm para carregar a rede. A invenção será descrita agora em mais detalhes com a ajuda de concretizações preferidas com relação aos desenhos inclusos.

BREVE DESCRIÇÃO DOS DESENHOS

Figura 1 mostra uma ilustração esquemática de bloco de um sistema de comunicação de multidifusão usado para transferir dados de uma fonte de vídeo por um árbitro de pedido para usuários em um destino.

Figura 2 expõe uma tabela na qual usuários subscrevendo a sessões diferentes são mostrados.

Figura 3 expõe um fluxograma ilustrando um método para prevenir conflitos de recurso em um sistema de multidifusão.

Figura 4 mostra uma ilustração esquemática de bloco de um sistema de comunicação de multidifusão usado para transferir dados de uma fonte de vídeo por árbitros de pedido para usuários em um destino.

Figura 5 expõe uma ilustração esquemática de bloco de um nó de ramal.

DESCRIÇÃO DETALHADA DE CONCRETIZAÇÕES

Na Figura 1, um sistema de transmissão de multidifusão para transferência de vídeo é exposto em uma primeira concretização. O sistema de transmissão transmite e distribui seqüências de vídeo de uma fonte de vídeo VS para vários usuários U1-U96. Os usuários, que são receptores ou distribuidores locais de seqüências de vídeo, são simbolizados com caixas na Figura 1, mas por causa de clareza da Figura 1, só os usuários Ul, U2, UI2, U85 e U96 são mostrados na figura. O sistema de multidifusão inclui uma parte de rede de fonte S, uma parte de rede de acesso AN, e uma parte de rede de destino DEST. A rede de acesso AN é uma rede de transmissão de pacote que pode ser do tipo orientada para conexão ou sem conexão. A fonte é neste exemplo uma fonte de vídeo VS e o destino consiste em usuários diferentes U1-U96 localizados por exemplo em escritórios ou casas. Neste exemplo, noventa e seis usuários divididos em grupos de doze estão conectados a nós de ramal diferentes BN21-BN28 na rede de acesso, isto é, doze usuários estão conectados a cada nó de ramal. A rede de acesso AN inclui chaves de Ethernet ESI e ES2 que distribuem dados entre a fonte VS e os nós de ramal BN21-BN28. Uma primeira ligação LI conecta a fonte de vídeo VS à chave de Ethernet ESI, uma segunda ligação L2 conecta a chave de Ethernet ESI à chave de Ethernet ES2 e uma terceira ligação L3 conecta a chave de Ethernet ES2 a um nó de ramal BN21. Duzentas sessões de vídeo estão disponíveis do servidor de vídeo VS. A terceira ligação L3, que também é chamada uma ligação de nó de ramal comum L3, é uma ligação de 100 Mbit/s. O nó de ramal BN21 é uma unidade de MUX que distribui dados chegando no nó para os usuários U1-U12, por ligações de ADSL de 8 Mbit/s. O usuário UI é um distribuidor em uma casa à qual uma TV e um PC estão conectados. O nó de ramal BN21 inclui um árbitro de pedido ARB. O árbitro considera todos os pedidos de largura de banda realmente concedidos, as condições contratadas para todos os usuários U1-U12 e recursos disponíveis. Destes fatos, o árbitro determina para cada pedido se deveria ser concedido ou não. Isto será explicado ademais abaixo.

De acordo com a invenção, a cada usuário é designado um peso para determinar quanta largura de banda de multidifusão cada usuário é para ser permitido receber. O peso é designado quando o sistema é configurado. Disponibilidade de largura de banda é por este meio proporcional ao peso designado. O peso designado é traduzido na largura de banda disponível para o usuário, isto é, a largura de banda permitida, usando um fator de conversão que diminui com carga real na terceira ligação L3. A largura de banda real de um usuário em uma ligação é calculada como a soma da parte do usuário em todas as sessões subscritas. Se o usuário estiver subscrevendo às sessões Si, S2, ..., Sm, o número de assinantes para estas sessões é ni, n2, ..., nm e as larguras de banda são bi, b2,bm respectivamente. A largura de banda real do usuário é a soma de bj/nj para todas essas sessões.

Figura 2 expõe uma tabela de usuários UI-UI2 em relação às sessões subscritas na terceira ligação L3 fora das duzentas sessões S1-S200· Como já dito, a terceira ligação é uma ligação de 100 Mbit/s. Neste exemplo, uma largura de banda de 50 Mbit/s é reservada para as sessões subscritas. Na Figura 2, pode ser visto que UI subscreveu às sessões Si, S2, S51 e que U6 subscreve às sessões S2, S41. Neste exemplo, cada sessão subscrita requer 1,5 Mbit/s fora da largura de banda de 50 Mbit/s reservada na ligação L3. Na Figura 2 pode ser visto que dezessete sessões diferentes ocupam a terceira ligação L3 e consequentemente 50-17 x 1,5 = 24,5 Mbit/s permanece disponível na terceira ligação. Esta é a denominada largura de banda disponível.

Um método de acordo com a invenção será explicado agora. O método inclui as etapas seguintes: Quando 0 sistema é configurado, a cada usuário é designado um peso. O peso fixa a importância do usuário. Neste exemplo, aos usuários U2-U6 foram designados o peso "1", U7-U12 são designados o peso "2", U13-U18 são designados o peso "3" e U19-U24 foram designados o peso "4". Ao usuário UI foi designado 0 peso "3". O peso "1" significa neste exemplo que o usuário está permitido usar 20% da largura de banda restante de L3 da terceira ligação, "2" significa 15%, "3" significa 10% e "4" significa 5%.

Um pedido para se unir a uma sessão é recebido ao nó de ramal BN do usuário Ul. UI pede para se unir à sessão Ssi- O árbitro ARB21 começa a determinar a largura de banda real de Ul. Como pode ser visto na Figura 2, Ul já faz parte das sessões Sls S2 e S5[. Ul sozinho usa a sessão Si, enquanto UI compartilha S2 com oito outros usuário e S51 com dois outros usuários. A sessão Ssi está antes de pedido de UI já compartilhada por dois outros usuários U8 e UI2. Como dito, cada sessão requer largura de banda de 1,5 Mbit/s e a largura de banda real de UI é por este meio calculada como a soma da parte de largura de banda de UI de cada sessão usada, incluindo o novo pedido, isto é, b{/ni + b2/n2 + b5i/n5i = 1,5/1 + 1,5/9 + 1,5/3 = 2,167 Mbit/s mais a parte de largura de banda da nova sessão pedida S8i, que é bgi/ngi = 1,5/3 = 0,5 Mbit/s. A largura de banda real de UI é por este meio 2,167 + 0,5 = 2,667 Mbit/s. O árbitro determina a largura de banda disponível. Na figura 2, pode ser visto que dezessete sessões estão reservadas na terceira ligação L3. Isto significa que uma largura de banda de 50-17 x 1,5 Mbit/s está disponível na terceira ligação L3, isto é, 24,5 Mbit/s está disponível. O árbitro determina a largura de banda disponível para Ul, isto é, a largura de banda permitida. A largura de banda permitida é calculada como a largura de banda disponível na ligação L3 em relação ao peso de Ul. O peso determina a qual parte relativa da largura de banda reservada para este tipo de sessão 0 usuário está autorizado. A largura de banda feita disponível para o usuário é por este meio proporcional ao peso designado ao usuário. Neste exemplo, 0 peso de Ul é "3" isto é, Ul está permitido usar 10% da largura de banda disponível. A largura de banda permitida de Ul é por este meio 0,1 x 24,5 = 2,45 Mbit/s. O árbitro compara a largura de banda real de Ul de 2,667 Mbit/s com a largura de banda permitida de Ul de 2,45 Mbit/s e acha que a largura de banda permitida é mais baixa do que a largura de banda real. O árbitro nega 0 pedido de Ul.

Cenários diferentes serão concebidos agora para realçar as vantagens da invenção. Por exemplo: Assumindo que largura de banda disponível na terceira ligação L3 é mais do que os 24,5 Mbit/s, isto é que menos usuários se subscleveram às sessões. Deixe assumir que a largura de banda disponível é 30 Mbit/s. O peso de UI é "3" isto é, UI está permitido usar 10%. Isto por sua vez conduzirá a uma situação onde o árbitro compara a largura de banda real de UI de 2,667 Mbit/s com a largura de banda permitida de UI de 3,0 Mbit/s e acha que a largura de banda permitida está mais alta do que a largura de banda real. Conseqüentemente, o árbitro permitirá o pedido de Ul.

Novamente voltando ao exemplo original e assumindo que Ul foi ponderado como um usuário mais importante e em vez de peso "3" obteve peso "2" isto é, Ul está permitido usar 15%. Isto conduzirá a uma situação onde a largura de banda permitida de Ul é 0,15 x 24 = 3,6 Mbit/s. Isto por sua vez conduzirá a uma situação onde o árbitro compara a largura de banda real de Ul de 2,667 Mbit/s com a largura de banda permitida de Ul de 3,6 Mbit/s e acha que a largura de banda permitida está mais alta do que a largura de banda real. Conseqüentemente o árbitro permitirá o pedido de Ul.

Novamente voltando ao exemplo original e assumindo que Ul pela primeira vez pede para se unir a uma sessão. Neste caso, a largura de banda real de Ul será 1,5/3 = 0,5 Mbit/s em vez dos 2,167 + 0,5 = 2,667 Mbit/s anterior. Isto por sua vez conduzirá a uma situação onde o árbitro compara a largura de banda real de Ul de 0,5 Mbit/s com a largura de banda permitida de Ul de 2,45 Mbit/s e acha que a largura de banda real está mais baixa do que a largura de banda permitida. Conseqüentemente, o árbitro permitirá o pedido de U1.

Novamente voltando ao exemplo original e assumindo que Ul é o primeiro assinante pedindo para se unir à sessão Ssi. Neste caso, a largura de banda real de Ul será 2,167 + 1,5/1 = 3, 667 Mbit/s. Compare se Ul ao invés fosse o décimo usuário a se unir à sessão Sgi- Neste caso, a largura de banda real de Ul seria 2,167 + 1,5/10 = 2,317 Mbit/s. Ao comparar os dois cenários, pode ser visto que o árbitro permitirá o pedido quando Ul é número dez, mas negará o pedido se UI for número um Deixe assumir que a sessão pedida SSi já era usada por alguém, Isto é realmente o caso com a sessão pedida S8Í na primeira concretização acima. Neste caso, o novo pedido não implicará qualquer carga adicional e o usuário UI pode ser permitido usar a sessão até mesmo se não justificado realmente. O método de acordo com esta variação da primeira concretização habilitará isto, e inclui as etapas adicionais seguintes depois que o árbitro comparou a largura de banda real de UI de 2,667 Mbit/s com a largura de banda permitida de UI de 2,45 Mbit/s (compare o método na primeira concretização): O árbitro ARB21 verifica que a sessão pedida Sgi já é usada por pelo menos um outro usuário U8, UI2. Esta informação é armazenada em uma memória no árbitro ARB21. O árbitro permite o pedido de Ul.

Agora novamente voltando à primeira concretização. Assumamos, como ainda outra variação da primeira concretização que o usuário quer retomar à sessão Sgi depois de por exemplo um intervalo de TV comercial curto. O usuário é por este meio visto como subscrevendo à sessão também por algum tempo depois que a assinatura real terminou. Durante um período de tempo depois que a assinatura real terminou, o usuário é garantido poder "retomar". O operador fixa um denominado tempo de qualificação que define "curto". Se o usuário não fosse permitido retomar depois de um intervalo de comercial curto, causaria descontentamento. O método de acordo com esta variação da primeira concretização inclui as etapas adicionais seguintes depois que o árbitro comparou a largura de banda real de Ul de 2,667 Mbit/s com a largura de banda permitida de Ul de 2,45 Mbit/s (veja o método na primeira concretização): O árbitro ARB21 acha que o usuário Ul usou a sessão Ssi um tempo atrás que é menos do que o tempo de qualificação predefinido. Esta informação é armazenada em uma memória no árbitro ARB21 O peso do usuário é mudado temporariamente de "3"para "2", isto é, o usuário se tomou um usuário mais importante, O árbitro permite o pedido de U1.

Quando o usuário mais tarde deixa a sessão, o peso do usuário será mudado novamente de volta para "3". A fim de prevenir que navegação rápida por sessões acumule assinaturas extras que fazem o árbitro negar assinaturas, há uma necessidade para filtrar fora assinaturas atuais muito curtas. O operador por este meio define um denominado tempo de garantia que define o tempo que um usuário deve ficar em uma sessão a fim de mais tarde ser permitido retomar à sessão. Isto significa uma variação do método acima por meio de que o árbitro também verifica o tempo de garantia depois de ter verificado o tempo de qualificação. O peso será mudado por este meio de "3" para "2" só se o usuário realmente usou a sessão um tempo atrás que é menos do que o tempo de qualificação predefinido e se o usuário nesse momento usou a sessão durante um período de tempo que excede o tempo de garantia predefinido.

Na Figura 3, as etapas mais essenciais do método podem ser vistas. O fluxograma é para ser lido junto com as figuras mostradas anteriormente. O método de acordo com a invenção inclui as etapas seguintes: Quando o sistema é configurado, a cada usuário é designado um peso. Ao usuário UI foi designado o peso "3". Esta etapa pode ser vista no fluxograma por um bloco 101.

Um pedido para unir a uma sessão é recebido ao nó de ramal BN do usuário UI. UI pede para se unir à sessão S8i. Esta etapa pode ser vista no fluxograma por um bloco 102. O árbitro ARB21 determina a largura de banda real de Ul. A largura de banda real de Ul é por este meio 2,167 + 0, 5 = 2,667 Mbit/s. Esta etapa pode ser vista no fluxograma por um bloco 103. O árbitro determina a largura de banda disponível na terceira ligação L3. Uma largura de banda de 50-17 x 1,5 Mbit/s está disponível, isto é, 24,5 Mbit/s está disponível. Esta etapa pode ser visto no fluxograma por um bloco 104. O árbitro determina a largura de banda permitida de Ul. A largura de banda permitida de Ul é 0,1 x 24,5 = 2,45 Mbit/s. Esta etapa pode ser vista no fluxograma por um bloco 105. O árbitro compara a largura de banda real de Ul de 2,667 Mbit/s com a largura de banda permitida de Ul de 2,45 Mbit/s e acha que a largura de banda permitida é mais baixa do que a largura de banda real. Esta etapa pode ser vista no fluxograma por um bloco 106. O árbitro nega o pedido de Ul. Esta etapa pode ser vista no fluxograma por um bloco 107.

Uma segunda concretização é exposta na Figura 4. A figura mostra o mesmo sistema de multidifusão como foi exposto anteriormente na Figura 1. Neste exemplo, não só a terceira ligação L3é considerada ser uma ligação crítica relativa a conflitos. Também há um risco potencial por conflitos na segunda ligação L2. A segunda ligação é uma ligação de 100 Mbit/s e é chamada uma ligação de Ethernet comum L2. Também a Chave de Ethernet ES2 inclui nesta concretização um árbitro de pedido ARB2. Esta segunda concretização é uma continuação da primeira concretização, mas é assumido que o árbitro ARB21 não negou o pedido prévio de Ul devido a por exemplo que o usuário Ul estava ponderado "2" de acordo com o cenário discutido anteriormente. Quando o sistema foi configurado, a cada usuário associado com a Chave de Ethernet foi designado um peso. A Ul era, como mencionado, designado o peso "2", U2-U12 eram designados os pesos como dito na primeira concretização, enquanto os usuários U13-U96 todos eram designados o peso "1". O método de acordo com a invenção na segunda concretização inclui as etapas adicionais seguintes: Depois que ARB21 permitiu o pedido de Ul, o pedido de UI para se unir à sessão S81 é remetido do nó de ramal BN21 à Chave de Ethernet ES2. O árbitro ARB2 na Chave de Ethernet ES 2 determina a largura de banda real de Ul na segunda ligação L2. Ul já faz parte das sessões Si, S2 e S51- Estas sessões são compartilhadas na segunda ligação também por alguns dos usuários U13-U96. A largura de banda real de Ul é por este meio neste exemplo assumida ser 1,5 Mbit/s. O árbitro de pedido ARB2 agora determina a largura de banda disponível na segunda ligação L2. Neste exemplo, é assumido que uma largura de banda de 3 Mbit/s está disponível em L2. O árbitro determina a largura de banda permitida de Ul. O peso de Ul é "2" (15%) e a largura de banda permitida de Ul é conseqüentemente 0,15 x 3 = 0,45 Mbit/s. O árbitro compara a largura de banda real de Ul de 1,5 Mbit/s com a largura de banda permitida de Ul de 0,45 Mbit/s e acha que a largura de banda permitida é mais baixa do que a largura de banda real. O árbitro ARB2 nega 0 pedido de Ul. A Chave de Ethernet ES2 envia uma mensagem de negação ao nó de ramal BN21. O árbitro de pedido ARB21 no nó de ramal BN21 também nega 0 pedido de Ul e por este meio libera a capacidade na terceira ligação L3.

Na Figura 5, o nó de ramal BN21 é exposto esquematicamente. O nó inclui uma unidade de MUX MU que distribui dados da terceira ligação L3 para as ligações de ADSL diferentes ADSL-1. O nó também inclui 0 árbitro de pedido ARB21 que inclui uma unidade central CU e dois espaços de memória MEM1 e MEM2. MEM1 inclui a tabela exposta na Figura 2. MEM2 inclui informação sobre quais usuários deixaram recentemente uma sessão pedida. A unidade central CU busca informação da terceira ligação, das ligações de ADSL e dos espaços de memória. CU processa a informação, calcula larguras de banda e tempos, controla a unidade de MUX e distribui sessões selecionadas da terceira ligação L3 para as ligações de ADSL.

Variações diferentes são certamente possíveis dentro da extensão da invenção. O arranjo na Figura 5 pode por exemplo ser estruturado diferentemente contanto que as funções de acordo com a invenção permaneçam. Um peso do usuário pode ser re-designado a qualquer momento. Largura de banda ocupada por uma sessão pode ser fixa ou pode variar. A invenção em outras palavras não está limitada ao descrito acima e nos desenhos mostrados em concretizações, mas pode ser modificada dentro da extensão das reivindicações inclusas.

REIVINDICAÇÕES

Claims (14)

1. Método para controle de acesso em um sistema de multidifusão ao distribuir dados de uma fonte (VS) em uma ligação comum (L3) para pelo menos dois usuários (U1-U12) por um nó (BN21), caracterizado pelo fato de compreender as etapas seguintes: - designar um peso a cada usuário (UI-UI2) associado com o nó (BN21), quais pesos determinam a largura de banda permitida de cada usuário isto é, a largura de banda permitida para uso fora de largura de banda disponível na ligação comum (L3); - receber ao nó (BN21), um pedido para unir uma sessão de multidifusão (Sei), de um usuário (Ul); - comparar no nó (BN21), uso de largura de banda real pelo usuário (Ul) calculado como a soma da parte de largura de banda do usuário de cada sessão usada na ligação comum (L3) incluindo o novo pedido, com a largura de banda permitida do usuário (Ul).

2. Método para controle de acesso em um sistema de multidifusão de acordo com reivindicação 1, caracterizado pelo fato de compreender a etapa adicional seguinte: - negar o pedido se a largura de banda permitida for mais baixa do que a largura de banda real.

3. Método para controle de acesso em um sistema de multidifusão de acordo com reivindicação 1, caracterizado pelo fato de compreender as etapas adicionais seguintes: - verificar que a sessão pedida (Sgi) é usada por pelo menos um outro usuário (U8, U12); - permitir o pedido de Ul.

4. Método para controle de acesso em um sistema de multidifusão de acordo com reivindicação 1, caracterizado pelo fato de compreender as etapas adicionais seguintes: - perceber que o usuário (Ul) usou a sessão (S8i) menos do que um tempo de qualificação predefinido atrás; me - mudar temporariamente o peso do usuário; - permitir o pedido se a largura de banda permitida for mais alta do que a largura de banda real.

5. Método para controle de acesso em um sistema de multidifusão de acordo com reivindicação 4, caracterizado pelo fato de compreender antes de mudar o peso do usuário, a etapa adicional seguinte: - perceber que o usuário usou a sessão (S8i) durante um período de tempo que excede um tempo de garantia predeterminado.

6. Método para controle de acesso em um sistema de multidifusão de acordo com reivindicação 4 ou 5, caracterizado pelo fato de compreender as etapas adicionais seguintes: - o usuário (Ul) deixa a sessão pedida S8i; - mudar de volta o peso do usuário para seu valor original.

7. Arranjo para controle de acesso em um sistema de multidifusão ao distribuir dados de uma fonte (VS) em uma ligação comum (L3) para pelo menos dois usuários (U1-U12) por um nó (BN21), caracterizado pelo fato de compreender: - meio para designar um peso a cada usuário (U1-U12) associado com o nó (BN21), quais pesos determinam a largura de banda permitida de cada usuário isto é, a largura de banda permitida para uso fora de largura de banda disponível na ligação comum (L3); - meio no nó (BN21) para receber um pedido para unir uma sessão de multidifusão (S8i) de um usuário (Ul); - meio para comparar no nó (BN21), uso de largura de banda real pelo usuário (Ul) calculado como a soma da parte de largura de banda do usuário de cada sessão usada na ligação comum (L3) incluindo o novo pedido, com a largura de banda permitida do usuário (Ul).

8. Arranjo para controle de acesso em um sistema de multidifiisão de acordo com reivindicação 7, caracterizado pelo fato de compreender meio para negar o pedido se a largura de banda permitida for mais baixa do que a largura de banda real.

9. Arranjo para controle de acesso em um sistema de multidifusão de acordo com reivindicação 7, caracterizado pelo fato de compreender: - meio para verificar que a sessão pedida (S8l) é usada por pelo menos um outro usuário (U8, UI2); - meio para permitir o pedido de UI.

10. Arranjo para controle de acesso em um sistema de multidifusão de acordo com reivindicação 7, caracterizado pelo fato de compreender: - meio para perceber que o usuário (Ul) usou a sessão (S8i) menos que um tempo de qualificação predefmido atrás; - meio para mudar temporariamente o peso do usuário; - meio para permitir o pedido se a largura de banda permitida for mais alta do que a largura de banda real.

11. Arranjo para controle de acesso em um sistema de multidifusão de acordo com reivindicação 10, caracterizado pelo fato de compreender: - meio para perceber que o usuário usou a sessão (S8i) durante um período de tempo que excede um tempo de garantia predeterminado.

12. Arranjo para controle de acesso em um sistema de multidifusão de acordo com reivindicação 10 ou 11, caracterizado pelo fato de compreender meio para mudar de volta o peso do usuário para seu valor original.

13. Arranjo para controle de acesso em um sistema de multidifusão de acordo com quaisquer das reivindicações 7-12, caracterizado pelo fato de incluir meio para calcular a largura de banda real do usuário (Ul).

14. Arranjo para controle de acesso em um sistema de multidifiisão de acordo com quaisquer das reivindicações 7-13, caracterizado pelo fato de incluir meio para calcular a largura de banda permitida do usuário (Ul).