BRPI0208735B1 - método e equipamento para transmissão fora-de-banda de opção de serviço de broadcast em um sistema de comunicação sem fio - Google Patents

Abstract

"método e equipamento para transmissão fora-de-banda de opção de serviço de broadcast em um sistema de comunicação sem fio". método e equipamento para prover informações de overhead para um serviço de broadcast em um sistema de comunicação sem fio através de uma transmissão fora de banda. a estação móvel é capaz de contatar o servidor de conteúdo diretamente usando a sinalização fora de banda através de uma opção de serviço de dados em pacotes. a comunicação fora de banda permite que o servidor de conteúdo atualize as informações sem transmissão através de um elemento de infra-estrutura intermediário. em uma modalidade, as informações de overhead incluem um número de opção de serviço que corresponde a um conjunto de parâmetros de broadcast, tais como aqueles que identificam uma pilha de protocolo para processar conteúdo de broadcast.

Description

"MÉTODO E EQUIPAMENTO PARA TRANSMISSÃO FORA-DE-BANDA DE OPÇÃO DE SERVIÇO BROADCAST EM UM SISTEMA DE COMUNICAÇÃO SEM FIO" FUNDAMENTOS

Reivindicação de Prioridade sob o 35 U.S.C. §120 O presente depósito de patente reivindica prioridade do depósito provisório americano No. 60/279.970, depositado em 28 de março de 2001, de propriedade do Requerente da presente invenção e aqui expressamente incorporado por referência.

Referência a Depósitos de Patente Co-pendentes A presente invenção refere-se aos seguintes depósitos de patente no escritório americano de marcas e patentes: "Method and Apparatus for Security in a Data Processing System" por Philip Hawkes et al·., possuindo Registro Legal N° 010497, depositado concomitantemente a este e de propriedade da Requerente da presente invenção e aqui expressamente incorporado por referência; "Method and Apparatus for Overhead Messaging in a Wireless Communication System" por Nikolai Leung, possuindo Registro Legal N° 010439, depositado concomitantemente a este e de propriedade da Requerente da presente invenção e aqui expressamente incorporado por referência; "Method and Apparatus for Broadcast Signaling in a Wireless Communication System" por Nikolai Leung, possuindo Registro Legal N° 010438, depositado concomitantemente a este e de propriedade da Requerente da presente invenção e aqui expressamente incorporado por referência; "Method and Apparatus for Transmission Framing in a Wireless Communication System" por Raymond Hsu, possuindo Registro Legal No. 010498, depositado concomitantemente a este e de propriedade da Requerente da presente invenção e aqui expressamente incorporado por referência; "Method and Apparatus for Data Transport in a Wireless Communication System" por Raymond Hsu, possuindo Registro Legal No. 010499, depositado concomitantemente a este e de propriedade da Requerente da presente invenção e aqui expressamente incorporado por referência; "Method and Apparatus for Cabeçalho Compression in a Wireless Communication System" por Raymond Hsu, possuindo Registro Legal No. 010500, depositado concomitantemente a este e de propriedade da Requerente da presente invenção e aqui expressamente incorporado por referência;

CAMPO A presente invenção refere-se de modo geral a sistemas de comunicação sem fio e especificamente, a métodos e equipamentos para compressão de mensagens na preparação para transmissão em um sistema de comunicação sem fio.

FUNDAMENTO Há uma demanda crescente por serviços de dados em pacotes em sistemas de comunicação sem fio. Como sistemas de comunicação sem fio tradicionais são projetados para comunicações de voz, a extensão para suportar serviços de dados introduz muitos desafios. Especificamente, a provisão de serviços unidirecionais, tal como o serviço broadcast onde informações de video e áudio são emitidas em fluxos a um assinante, possui um único conjunto de exigências e metas. Tais serviços podem ter grandes exigências de largura da banda, em que os projetistas de sistemas buscam minimizar a transmissão de informações de overhead. Adicionalmente, o assinante requer informações especificas para acessar as transmissões de broadcast, tal como processamento de parâmetros e protocolos. üm problema existente na transmissão de informações específicas de broadcast enquanto otimiza a utilização de largura da banda disponível.

Então, há uma demanda por um método eficiente e preciso de transmissão de dados em um sistema de comunicação sem fio. Adicionalmente, há uma demanda por um método eficiente e preciso de prover informações específicas de serviço a um usuário.

SUMÁRIO

As modalidades aqui descritas atendem à demanda acima mencionada ao prover um método para segurança em um sistema de processamento de dados.

Em um aspecto, em um sistema de comunicação sem fio suportando um serviço broadcast, um método inclui transmitir uma seção de broadcast em um canal de transmissão de broadcast e transmitir informações de overhead de broadcast correspondendo à seção de broadcast em um canal de transmissão de overhead. O serviço broadcast é transmitido por um servidor de conteúdo. O serviço broadcast possui uma pilha de protocolos correspondente possuindo uma camada de aplicação e uma camada de transporte, em que o servidor de conteúdo controla independentemente os protocolos da camada de aplicação e da camada de transporte.

Em outro aspecto, em um sistema de comunicação sem fio suportando um serviço broadcast, um método inclui receber informações de overhead de broadcast que correspondem à seção de broadcast em um canal de transmissão de overhead, acessar a seção de broadcast em um canal de transmissão de broadcast e utilizar as informações de overhead de broadcast para processar conteúdo de broadcast da seção de broadcast.

DESCRIÇÃO BREVE DOS DESENHOS A Figura 1 é um diagrama de um sistema de comunicação com espalhamento espectral que suporta diversos usuários. A Figura 2 é um diagrama de blocos do sistema de comunicação suportando transmissões de broadcast. A Figura 3 é um modelo da pilha de protocolos que corresponde a uma opção de serviço broadcast em um sistema de comunicação sem fio. A Figura 4 é uma tabela de protocolos aplicada a camadas de uma pilha de protocolos que suporta uma opção de serviço broadcast em um sistema de comunicação sem fio. A Figura 5 é um fluxograma para acessar um serviço broadcast em uma topologia de sistema de comunicação sem fio. A Figura 6 é um fluxo de broadcast em um sistema de comunicação sem fio. A Figura 7 é um mapeamento de compressão de cabeçalho (header) em um sistema de comunicação sem fio. A Figura 8 é um broadcast periódico de informações de compressão de cabeçalho. A Figura 9 é um protocolo de compressão de cabeçalho. A Figura 10 é um protocolo de compressão de cabeçalho para serviço broadcast em um sistema de comunicação sem fio. A Figura 11 é um fluxograma de compressão de cabeçalho para serviço broadcast em um sistema de comunicação sem fio. A Figura 12 é um fluxograma de descompressão de cabeçalho para serviço broadcast em um sistema de comunicação sem fio.

As Figuras 13 e 14 ilustram transporte de dados em um sistema de comunicação sem fio. A Figura 15 é um diagrama de temporização de um fluxo de mensagem em um sistema de comunicação sem fio. A Figura 16 é uma configuração de mensagem de parâmetro de overhead do sistema. A Figura 17 é uma configuração de mensagem de parâmetro de overhead do sistema de bloco de bits (BLOB). A Figura 18 é um fluxograma para provisão de protocolos de broadcast e parâmetros em um sistema de comunicação sem fio. A Figura 19 é um mapeamento de números de opção de serviço a conjuntos de parâmetros. A Figura 20 ilustra definição de parâmetro em um sistema de comunicação sem fio. A Figura 21 é um diagrama de blocos de canais utilizados para um sistema de comunicação sem fio suportando serviços de broadcast. A Figura 22 é um fluxo de broadcast com informações de overhead intercaladas com conteúdo de broadcast. A Figura 23 é um método para acessar um serviço broadcast em um sistema de comunicação sem fio. A Figura 24 é um elemento de memória para armazenar informações de overhead de broadcast.

DESCRIÇÃO DE TALHADA A palavra "exemplar" é utilizada aqui exclusivamente para significar "servindo como um exemplo, caso, ou ilustração". Qualquer modalidade descrita aqui como "exemplar" não necessariamente deve ser construída como preferida ou vantajosa em relação a outras modalidades. Enquanto são apresentados os diversos aspectos da presente invenção nos desenhos, os desenhos não necessariamente são representados em escala a menos que indicado especificamente.

Uma modalidade exemplar de um sistema de comunicação sem fio emprega um método de compressão de cabeçalho que reduz o tamanho de cada cabeçalho enquanto satisfaz exigências de precisão e transmissão do sistema. A modalidade exemplar suporta um serviço broadcast unidirecional. O serviço broadcast provê fluxos de video e/ou áudio para múltiplos usuários. Os assinantes do serviço broadcast "sintonizam" a um canal designado para acessar a transmissão de broadcast. Como a exigência de largura da banda para transmissão de alta velocidade de difusões de video é grande, é desejável reduzir o tamanho de qualquer overhead associado com tal transmissão de broadcast. A discussão seguinte desenvolve a modalidade exemplar geralmente apresentando primeiro um sistema de comunicação sem fio com espalhamento espectral. A seguir, o serviço broadcast é introduzido, em que o serviço refere-se ao serviço broadcast de alta velocidade (HSBS - High Speed Broadcast Service), e a discussão inclui designações de canal da modalidade exemplar. Um modelo de assinatura é mostrado a seguir incluindo opções para planos de assinaturas pagas, assinaturas gratuitas e assinaturas híbridas, semelhantemente àqueles disponíveis atualmente para transmissões de televisão. As especificidades no acesso ao serviço broadcast são a seguir detalhadas, apresentando a utilização de uma opção de serviço para definir as especificidades de uma determinada transmissão. O fluxo de mensagem no sistema de broadcast é discutido com relação à topologia do sistema, isto é, elementos de infra-estrutura. Finalmente, é discutida a compressão de cabeçalho utilizada na modalidade exemplar.

Observa-se que a modalidade exemplar é fornecida como um exemplo ao longo desta discussão; porém, modalidades alternativas podem incorporar vários aspectos sem afastamento do escopo da presente invenção.

Especificamente, a presente invenção é aplicável a um sistema de processamento de dados, um sistema de comunicação sem fio, um sistema de broadcast unidirecional e qualquer outro sistema que deseja transmissão eficiente de informações.

SISTEMA DE COMUNICAÇÃO SEM FIO A modalidade exemplar emprega um sistema de comunicação sem fio com espalhamento espectral, suportando um serviço broadcast. Os sistemas de comunicação sem fio são desenvolvidos amplamente para prover vários tipos de comunicação tal como voz, dados e assim por diante. Estes sistemas podem estar baseados no acesso múltiplo por divisão de código (CDMA), acesso múltiplo por divisão de tempo (TDMA) ou alguma outra técnica de modulação. Um sistema CDMA provê certas vantagens em relação a outros tipos de sistemas, incluindo capacidade de sistema aumentada.

Um sistema pode ser projetado para suportar um ou mais padrões tal como o "TIA/EIA/IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" designado aqui como o padrão IS-95, o padrão oferecido por um consórcio nomeado "3rd Generation Partnership Project" designado aqui como 3GPP, e incorporado em um conjunto de documentos incluindo os Documento Nos. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, 3G TS 25.214 e 3G TS 25.302, designado aqui como o padrão W-CDMA, o padrão oferecido por um consórcio nomeado "3rd Generation Partnership Project 2" designado aqui como 3GPP2, e TR-45.5 designado aqui como o padrão cdma2000, antigamente designado de IS-2000 MC. Os padrões citados acima são incorporados expressamente aqui por referência.

Cada padrão define especificamente o processamento de dados para transmissão a partir da estação base para o móvel, e vice-versa. Como uma modalidade exemplar a seguinte discussão considera um sistema de comunicação de espalhamento espectral consistente com o padrão cdma2000 de protocolos. As modalidades alternativas podem incorporar outros padrões. Ainda outras modalidades podem aplicar os métodos de compressão descritos aqui para outros tipos de sistemas de processamento de dados. A Figura 1 serve como um exemplo de um sistema de comunicação 100 que suporta diversos usuários e é capaz de implementar pelo menos alguns aspectos e modalidades da invenção. Qualquer das variedades de algoritmos e métodos podem ser utilizados para programar transmissões no sistema 100. O sistema 100 provê comunicação para várias células de 102A a 102G, cada uma das quais é atendida por uma estação base correspondente de 104A a 104G, respectivamente. Considera-se que o termo "estação base 104" empregado por todo o relatório, se refere às "estações base 104A, 104B, 104C, 104D, 104E, 104F e 104G". O termo "estação base 104" é empregado somente com o objetivo de concisão. Na modalidade exemplar, algumas das estações base 104 possuem múltiplas antenas receptoras e outras possuem uma única antena receptora. De modo semelhante, algumas das estações base 104 possuem múltiplas antenas transmissoras e outras possuem uma única antena receptora. Não existem restrições nas combinações de antenas transmissoras e antenas receptoras. Consequentemente, é possível que uma estação base 104 possua múltiplas antenas receptoras e uma única antena receptora, ou possua múltiplas antenas receptoras e uma única antena transmissora, ou possua tanto uma única como múltiplas antenas transmissoras e receptoras .

Os terminais 106 na área de cobertura podem ser fixos (isto é, estacionários) ou móveis. Como mostrado na Figura 1, vários terminais 106 estão espalhados ao longo do sistema. Considera-se que o termo "terminal 106", empregado por todo o relatório, se refere aos "terminais 106A, 106B, 106C, 106D, 106E, 106F e 106G". O termo "terminal 106" é empregado somente com o objetivo de concisão. Cada terminal 106 comunica-se com pelo menos uma e possivelmente mais estações base 104 no downlink e uplink em algum determinado momento dependendo de se, por exemplo, o soft handoff for empregado ou se o terminal for projetado e operado para receber (concomitantemente ou seqüencialmente) múltiplas transmissões a partir das estações base. O soft handoff em sistemas de comunicações CDMA é bem-conhecido na técnica e é descrito em detalhes na Patente U.S. N° 5.101.501, intitulada "Method and System for providing a Soft Handoff in a CDMA Cellular Telephone System", que é de propriedade da Requerente da presente invenção. O downlink, ou FL, refere-se à transmissão a partir da estação base para o terminal; e o uplink, ou RL, refere-se à transmissão a partir do terminal para a estação base. Na modalidade exemplar, alguns dos terminais 106 possuem múltiplas antenas receptoras e outras possuem apenas uma única antena receptora. Na Figura 1, a estação base 104A transmite dados para os terminais 106A e 106J no downlink, a estação base 104B transmite dados para os terminais 106B e 106J, a estação base 104C transmite dados para o terminal 106C, e assim por diante. A crescente demanda para transmissão de dados sem fio e a expansão de serviços disponíveis através da tecnologia de comunicação sem fio conduziu ao desenvolvimento de serviços de dados específicos. Um tal serviço é designado como de Alta Taxa de Dados (HDR - High Data Rate). Um serviço HDR exemplar é proposto no "EIA/TIA-IS856 cdma2000 High Rate Packet Data Air Interface Specification" designado como ''a especificação HDR". O serviço HDR geralmente é uma sobreposição a um sistema de comunicação de voz que provê um método eficiente de transmitir pacotes de dados em um sistema de comunicação sem fio. Como a quantidade de dados transmitidos e o número de transmissões aumentam, a limitada largura de banda disponível para transmissões via rádio torna-se um recurso critico. Conseqüentemente, existe uma demanda por um método eficiente e bom de programar transmissões em um sistema de comunicação que otimize a utilização da largura de banda disponível. Na modalidade exemplar, o sistema 100 ilustrado na Figura 1 está de acordo com um sistema tipo CDMA que possui serviço HDR. SISTEMA DE BRQADCAST DE ALTA VELOCIDADE (HSBS) Um sistema de comunicação sem fio 200 é ilustrado na Figura 2, em que informações de video e de áudio são providas a uma rede de serviços de dados em pacotes (PDSN) 202. As informações de video e áudio podem ser de programação de televisão ou de uma transmissão via rádio. As informações são providas como dados em pacotes, tal como pacotes IP. A PDSN 202 processa os pacotes IP para distribuição dentro de uma rede de acesso (AN). Como ilustrado a AN é definida como porções do sistema incluindo uma BS 204 em comunicação com múltiplas MS 206. A PDSN 202 é acoplada à BS 204. Para o serviço HSBS, a BS 204 recebe o fluxo de informações a partir da PDSN 202 e provê as informações no canal designado para assinantes dentro do sistema 200.

Em um determinado setor, existem diversas formas nas quais o serviço broadcast HSBS pode ser desenvolvido. Os fatores envolvidos no projeto de um sistema incluem, mas não estão limitadas ao, número de sessões HSBS suportadas, número de designações de freqüências, e número de canais físicos de broadcast suportados. O HSBS é um fluxo de informações provido através de uma interface área em um sistema de comunicação sem fio. O "canal HSBS" refere-se a uma única sessão de broadcast HSBS lógica como definido pelo conteúdo de broadcast. Observa-se que o conteúdo de um determinado canal HSBS pode mudar com tempo, por exemplo, Noticias às 7h da manhã, o Tempo às 8h da manhã, Filmes às 9h da manhã, etc. A programação baseada no tempo é análoga a um único canal de TV. 0 "canal de broadcast" refere-se a um único canal fisico de link direto, por exemplo, um dado código Walsh, que porta tráfego de broadcast. O canal de broadcast, BCH, corresponde a um único canal CDM.

Um único canal de broadcast pode portar um ou mais canais HSBS; neste caso, os canais HSBS serão multiplexados em uma forma multiplexada por divisão de tempo (TDM) dentro do único canal de broadcast. Em uma modalidade, um único canal HSBS é provido em mais que um canal de broadcast dentro de um setor. Em outra modalidade, um único canal HSBS é provido em freqüências diferentes para atender assinantes em tais freqüências.

De acordo com a modalidade exemplar, o sistema 100 ilustrado na Figura 1 suporta um serviço broadcast de multimidia de alta velocidade designado como serviço broadcast de alta velocidade (HSBS - High-Speed Broadcast Service). As capacidades de broadcast do serviço pretendem prover programação em uma taxa de dados suficiente para suportar comunicações de video e áudio. Como exemplo, aplicações do HSBS podem incluir transmissão de fluxo continuo de videos de filmes, de eventos esportivos, etc. O serviço HSBS é um serviço de dados em pacotes baseado no Protocolo Internet (IP).

De acordo com a modalidade exemplar, um provedor de serviços é designado como um servidor de conteúdo (CS -Content Server), em que o CS alerta quanto à disponibilidade de tal serviço broadcast de alta velocidade aos usuários do sistema. Qualquer usuário que deseje receber o serviço HSBS, pode assinar o CS. O assinante é a seguir capaz de varrer a programação do serviço broadcast em uma diversidade de formas que pode ser provida pelo CS. Como exemplo, o conteúdo de broadcast pode ser comunicado através de propagandas, mensagens de sistema de gerenciamento curto (SMS - Short Management System), protocolo de aplicação sem fio (WAP - Wireless Application Protocol), e/ou qualquer outro meio geralmente de acordo com, e conveniente para, comunicações sem fio móveis. Os usuários móveis são designados como estações móveis (MSs -Mobile Stations). As estações base (BSs - Base Stations) transmitem parâmetros relacionados com HSBS em mensagens de overhead, tal como aqueles transmitidos em canais e/ou freqüências designadas para controle e informações, isto é, mensagens não de carga-útil (payload).A carga-útil refere-se ao conteúdo de informações da transmissão, em que para uma sessão de broadcast, a carga-útil é o conteúdo de broadcast, isto é, o programa de video, etc. Quando um assinante do serviço broadcast deseja receber uma sessão de broadcast, isto é, um programa programado de broadcast especifico, a MS lê as mensagens de overhead e aprende as configurações apropriadas. A MS a seguir sintoniza para a freqüência que contém o canal HSBS e recebe o conteúdo de serviço broadcast. A estrutura de canal da modalidade exemplar está de acordo com o padrão cdma2000, em que o canal suplementar direto (F-SCH - Forward Supplemental Channel) suporta transmissões de dados. Uma modalidade empacota um número grande dos canais fundamentais diretos (F-FCHs) ou o Canal de Controle Exclusivo Direto (F-DCCHs - Forward Dedicated Control Channels) para atingir exigências de taxa de dados mais elevada de serviços de dados. A modalidade exemplar utiliza um F-SCH como a base para o F-BSCH suportando uma carga-útil de 64 kbps (excluindo overhead RTP} . O F-BSCH também pode ser modificado para suportar outras taxas de carga-útil, por exemplo, através da subdivisão da taxa de carga-útil de 64 kbps em subfluxos de taxas mais baixas.

Uma modalidade também suporta chamadas em grupo em diversas formas diferentes. Como exemplo, ao utilizar canais unicast existentes, isto é, um canal de link direto por MS sem compartilhamento, de F-FCH (ou de F-DCCH) em ambos os links direto e reverso. Em outro exemplo, são aplicados o F-SCH (compartilhado pelos membros do grupo no mesmo setor) e o F-DCCH (sem quadros (frames) mas o subcanal de controle de potência direto na maior parte do tempo) no link direto e o R-DCCH no link reverso. Ainda em outro exemplo, são utilizados o F-BSCH de alta taxa no link direto e o canal de acesso (ou a combinação canal de acesso aumentado/canal de controle comum reverso) no link reverso.

Possuindo uma alta taxa de dados, o F-BSCH da modalidade exemplar pode utilizar uma parte muito grande de uma potência de link direto da estação base para prover cobertura adequada. O projeto de camada fisica do HSBC é portanto, focado em melhorias de eficiência em um ambiente de broadcast.

Para prover suporte adequado aos serviços de vídeo, o projeto do sistema considera a potência da estação base requerida para as várias formas para transmitir o canal, bem como, a qualidade de video correspondente. Um aspecto do projeto é um intercâmbio subjetivo entre a qualidade de video percebida no limite de cobertura e a proximidade da estação rádio-base (cell site). Como a taxa de carga-útil é reduzida, a taxa de código de correção de erros efetiva é aumentada, um dado nível de potência de transmissão de estação base proveria melhor cobertura no limite da célula. Para estações móveis localizadas mais perto das estações base, a recepção do canal mantém-se livre de erros e a qualidade do vídeo ficará mais baixa devido à taxa fonte mais baixa. Este mesmo intercâmbio também se aplica a outras aplicações que não de vídeo que o F-BSCH pode suportar. Abaixando a taxa de carga-útil suportada pelo canal aumenta-se a cobertura pelo custo da redução da velocidade do download para tais aplicações. O balanceamento da importância relativa entre qualidade de vídeo e a vazão de dados versus a área de cobertura é objetivo. A configuração escolhida busca uma configuração otimizada especifica para aplicação e um bom compromisso entre todas as possibilidades. A taxa de carga-útil para o F-BSCH é um importante parâmetro de projeto. As seguintes suposições podem ser utilizadas no projeto de um sistema que suporte transmissões de broadcast de acordo com a modalidade exemplar: (1) a taxa de carga-útil meta é 64 kbps; (2) para a transmissão de fluxo continuo de serviço de video, a taxa de carga-útil é presumida para incluir bytes de 128 bits por overhead de pacote dos pacotes RTP; (3} o overhead médio para todas as camadas entre RTP e a camada fisica é aproximadamente 64, bytes de 8 bits por pacote mais 8 bits por overhead de quadro F-SCH é utilizado pelo cabeçalho MUXPDU.

Na modalidade exemplar, para serviços de broadcast não de video, a taxa máxima suportada é 64 kbps. Porém, muitas outras taxas de carga-útil possíveis abaixo de 64 kbps também são alcançáveis.

MODELO DE ASSINATURA

Existem diversos modelos possíveis de assinatura/receita para serviço HSBS, incluindo acesso gratuito, acesso controlado e acesso parcialmente controlado. Para o acesso gratuito, nenhuma assinatura é necessária pelo usuário para receber o serviço. A BS difunde o conteúdo sem criptografia e dirige a móveis que podem receber o conteúdo. A receita para o provedor de serviços pode ser gerada através de propagandas que podem também ser transmitidas no canal de broadcast. Por exemplo, os clipes de filme que chegam podem ser transmitidos para os estúdios que vão pagar ao provedor de serviços.

Para o acesso controlado, os usuários da MS assinam o serviço e pagam a taxa correspondente para receber o serviço broadcast. Os usuários não assinantes, não são habilitados a receber o serviço HSBS. O acesso controlado pode ser atingido por criptografia da transmissão/conteúdo HSBS de forma que apenas os usuários assinantes possam decriptografar o conteúdo. Isto pode utilizar procedimentos de troca de chave de criptografia através do ar. Este esquema provê forte segurança e impede acesso de serviço não autorizado.

Um esquema de acesso híbrido, designado como acesso parcialmente controlado, provê o serviço HSBS como um serviço baseado na assinatura que é criptografado com transmissões de propaganda não criptografada intermitentes. Tais propagandas podem ser dirigidas para encorajar assinantes ao serviço HSBS criptografado. A programação de tais segmentos não criptografados pode ser conhecida da MS através de dispositivos externos.

OPÇÃO DE SERVIÇO HSBS A opção de serviço HSBS é definida por: (1) uma pilha de protocolos; (2) opções na pilha de protocolos; e (3) procedimentos para ajustar e sincronizar o serviço. A pilha de protocolos de acordo com a modalidade exemplar é ilustrada nas Figuras 3 e 4. Como ilustrado na Figura 3, a pilha de protocolos é específica ao elemento de infra-estrutura, isto é, MS, BS, PDSN e CS na modalidade exemplar.

Continuando com a Figura 3, para a camada de aplicação da MS, o protocolo especifica o codec de áudio, o codec de vídeo, bem como qualquer perfil de vídeo. Adicionalmente, o protocolo especifica tipos de carga-útil do protocolo de transporte via rádio (RTP) quando o RTP é utilizado. Para a camada de transporte da MS, o protocolo especifica uma porta de protocolo de datagrama de usuário (UDP - User Datagram Protocol) a ser utilizada para portar os pacotes RTP. A camada de segurança da MS é especificada pelo protocolo {Ip sec), em que são providos parâmetros de segurança através de canais fora de banda quando a associação de segurança for inicialmente estabelecida com o CS. A camada de enlace especifica os parâmetros de compressão de cabeçalho IP. Conforme ilustrado, informações de processamento utilizadas para transmissão pelo CS e solicitadas pela MS, não têm necessariamente necessidade de ser conhecidas pela BS/PCF ou PDSN. Tais informações podem incluir informações IPsec, informações MPEG, etc.

Para que as estações móveis descubram e escutem os canais de broadcast com sucesso, diversos parâmetros de serviço broadcast relacionados são transmitidos através da interface aérea. O serviço broadcast é projetado para suportar opções de protocolo diferentes na pilha de protocolos. Isto requer que os receptores do serviço broadcast sejam informados das opções de protocolo selecionadas para facilitar decodificação e processamento adequados do broadcast. Em uma modalidade o CS provê estas informações ao receptor como uma mensagem de parâmetro de sistema de overhead, consistente com padrão CDMA2000. A vantagem para o receptor é a capacidade de receber informações imediatamente a partir da mensagem de overhead. Desta forma, o receptor pode determinar imediatamente se o receptor possui recursos suficientes para receber a sessão de broadcast. O receptor monitora as mensagens de parâmetro de sistema de overhead. O sistema pode implementar um número de opções de serviço que corresponde a um conjunto de parâmetros e protocolos, em que o número de opções de serviço é provido na mensagem de overhead. Alternativamente, o sistema pode prover um conjunto de bits ou flags para indicar as opções de protocolo diferentes selecionadas. O receptor a seguir determina as opções de protocolo para decodificar a sessão de broadcast corretamente. O canal de broadcast é um canal físico definido para portar tráfego de broadcast. Há diversos formatos possíveis de camada física que podem ser usados para um determinado canal de broadcast, e portanto, os receptores de estação móvel requerem informações sobre estes parâmetros para decodificar a transmissão física do canal de broadcast com sucesso. Especificamente, cada canal de broadcast, canal HSBS, possui um único identificador no sistema. Adicionalmente, para cada canal HSBS, a BS designa um identificador de referência de serviço broadcast, em que a estação base ajusta o campo que corresponde à sessão de serviço broadcast atual. O serviço broadcast transmitirá a seguir, informações para cada canal HSBS incluindo: o identificador de canal de broadcast e o identificador de referência de serviço broadcast.

Adicionalmente, o canal de broadcast pode incorporar várias combinações de protocolos de camada superior, com base no tipo de conteúdo que é entregue. O receptor móvel também requer informações com relação a estes protocolos de camada superior para interpretação das transmissões de broadcast. De acordo com uma modalidade, a pilha de protocolos é comunicada por métodos fora de banda, em que o método fora de banda indica a transmissão de informações através de um canal separado distinto do canal de broadcast. Com esta abordagem, a descrição da pilha de protocolos de camada superior não é transmitida através do canal de broadcast ou através do canal de parâmetros de sistema de overhead.

Como discutido acima, a opção de serviço define a pilha de protocolos e os procedimentos utilizados para operar o serviço broadcast. Consistente com um serviço unidirecional, o serviço broadcast é caracterizado pelas opções de protocolo comuns entre múltiplos receptores de broadcast. Na modalidade exemplar, opções de protocolo para o serviço broadcast não são negociadas entre a estação móvel e a rede. As opções são predeterminadas pela rede e são providas à estação móvel. Como o serviço broadcast é um serviço unidirecional, o serviço broadcast não suporta solicitações provenientes da estação móvel. Preferivelmente o conceito do serviço broadcast é semelhante a uma transmissão de televisão, em que os receptores sintonizam no canal de broadcast e acessam a transmissão de broadcast utilizando os parâmetros especificados pelo CS.

Para evitar a requisição de coordenação entre a rede sem fio e o CS, o serviço pode utilizar canais fora de banda para transmitir informações à estação móvel com relação às opções de protocolo acima da camada de rede IP. A Figura 15 ilustra um fluxo de broadcast de acordo com uma modalidade. 0 eixo horizontal representa a topologia do sistema, isto é, elementos de infra-estrutura. O eixo vertical representa a linha do tempo. No momento tl a MS acessa o canal fora de banda através da BS. Observa-se que a MS pode acessar a rede ao selecionar uma opção de serviço de dados em pacotes, tal como ao usar um canal de opção de serviço de dados em pacotes exclusivo designado como SO 33. Efetivamente, a MS seleciona uma opção de serviço de dados em pacotes para estabelecer uma sessão de protocolo de fluxo continuo em tempo real (RTSP - Real Time Streaming Protocol) com o CS. Neste exemplo, a instrução RTSP é utilizada, especificamente, "RTSP: Descrever".A MS solicita uma descrição da aplicação e protocolos de transporte utilizados para o fluxo de broadcast do CS no momento t3. Observa-se que adicionalmente à utilização do RTSP, o protocolo de iniciação de sessão (SIP - Session Initiation Protocol) também pode ser utilizado para solicitar a descrição da aplicação e protocolos de transporte. A descrição é portada através do protocolo de descrição de sessão (SDP - Session Description Protocol) no momento t4. A transmissão do protocolo pode ser efetuada enquanto o usuário estiver acessando o serviço broadcast. Observa-se que o RTSP. e o SDP são abordagens padronizadas para estabelecer um serviço de fluxo continuo unidirecional no IETF e no 3GPP2. A estação móvel também utilizará um serviço de dados em pacotes para solicitar à PDSN para identificar o protocolo de compressão de cabeçalho do serviço broadcast. A PDSN então retransmite quaisquer informações de inicialização de compressão à estação móvel no momento t2. Em uma modalidade, o protocolo de controle do Protocolo Internet (IPCP) é utilizado para trocar informações de compressão de cabeçalho com a estação móvel. De modo similar, este mesmo mecanismo pode ser estendido para prover informações para o fluxo de broadcast.

Caso as opções de protocolo de serviço broadcast mudem, a estação móvel requererá notificação. Uma modalidade aplica um índice de parâmetros de segurança (SPI - Security Parameters Index) para indicar quando opções de protocolo podem ter sido mudadas. Caso as opções de protocolo mudem, como resultado da utilização de um CS diferente para o sistema, ou a estação móvel que realiza o handoff para um sistema diferente, o SPI mudará automaticamente devido à fonte de endereço IP das mudanças do CS. Além disso, caso o CS não mude e o mesmo seja utilizado com opções de protocolo diferentes, o CS será requerido para mudar o SPI para indicar que os parâmetros mudaram. Quando a estação móvel detecta este SPI novo, obterá a nova descrição de protocolo ao configurar uma chamada de serviço de dados em pacotes e contactar a PDSN e o CS cujo endereço IP é incluído no SPI.

Em uma modalidade, a abordagem SPI aplica diversos critérios. Em primeiro lugar, um único CS usa as mesmas opções de protocolo para sessões de fluxo contínuo consecutivas, caso contrário o CS modifica o SPI quando as opções de protocolo mudam. Em segundo lugar, a PDSN não muda o algoritmo de compressão de cabeçalho ou os parâmetros entre sessões de fluxo contínuo com o mesmo SPI. A mudança das opções de protocolo em um determinado sistema dispara múltiplas estações móveis para configurar uma chamada de serviço de dados em pacotes para recuperar as descrições de protocolo atualizadas. Os retardos de configuração de chamada aleatórios devem ser introduzidos para impedir que o sistema seja sobrecarregado por estas originações de chamada. Os servidores de conteúdo podem introduzir algum retardo entre o momento em que o SPI é mudado e o momento em que o fluxo de conteúdo começa a permitir que todos os usuários recuperem as opções de protocolo.

Por outro lado os protocolos e parâmetros do canal de broadcast podem ser transmitidos à estação móvel. Em uma modalidade alternativa, um número de opção de serviço (SO) é designado a cada conjunto de protocolos e parâmetros de broadcast, em que o número SO é transmitido aos múltiplos receptores. Em uma derivação do mesmo, as informações de parâmetro são transmitidas diretamente aos múltiplos receptores como uma pluralidade de campos codificados. O método anterior de identificar protocolos de broadcast e parâmetros pelo número SO, incorpora uma mensagem de parâmetros de serviço broadcast (BSPM Broadcast Service Parameters Message). Esta BSPM é uma mensagem de overhead especifica para o serviço broadcast. Aquelas estações móveis que desejam receber o serviço HSBS monitorariam a BSPM. A BSPM é periódica e continuamente transmitida por cada setor que configurou um ou mais canais de broadcast. O formato da BSPM da modalidade exemplar é ilustrado na Figura 16. Os diversos parâmetros indicados na mensagem são listados com o número de bits alocado na mensagem para cada um. 0 índice de deslocamento (offset) da seqüência PN piloto é identificado como PILOT_PN. A BS ajusta o campo PILOT_PN para o deslocamento de seqüência PN piloto para a estação base correspondente em unidades de 64 chips PN. O BSPM_MSG_SEQ refere-se a um número de seqüência de mensagem de parâmetros de serviço broadcast. Quando algum dos parâmetros identificados em uma BSPM atual muda desde a transmissão anterior da BSPM, a BS incrementa o BSPM_MSG_SEQ. O HSBS_REG_USED é um indicador utilizado para o registro do serviço broadcast. Este campo indica as freqüências utilizadas para alertar (paging) um assinante de MS para o serviço broadcast. O HSBS_REG_TIMER (High-Speed Broadcast Service Registration Timer - -temporizador de registro de serviço de broadcast de alta velocidade) é um valor de temporizador de registro do serviço broadcast. Caso o campo HSBS_REG_USED seja ajustado em '0', a estação base omitirá este campo. Caso contrário, a estação base inclui este campo HSBS_REG_TIMER com significação dada como: a BS ajusta este campo HSBS_REG_TIMER ao comprimento da duração do registro para os canais de serviço broadcast; ou a estação base ajusta este campo HSBS_REG_TIMER para '00000' caso a MS seja requerida para registrar o canal HSBS a cada momento que ela começa a monitorar um canal HSBS .

Continuando com a Figura 16, o NUM_FBSCH é o número de canais suplementares de broadcast diretos. A BS ajusta este campo com o número de canais suplementares de broadcast diretos transmitidos pela BS correspondente. O NUM_HSBS_SESSION é o número de sessões de serviço broadcast. A BS ajusta este campo ao número de sessões de serviço broadcast que são transmitidas pela BS correspondente. O NUM_LPM_ENTRIES é o número de entradas de mapeamento de lógica para fisica. A BS ajusta este campo ao número de lógica, isto é, sessões de serviço broadcast, para fisica, isto é canal suplementar de broadcast direto, mapeando entradas portadas nesta mensagem. A BS ajusta um identificador de canal suplementar de broadcast direto, FBSCH_ID, correspondendo ao canal suplementar de broadcast direto. Caso o campo FBSCH__CDMA_FREQ seja incluído neste registro, a estação base ajusta o bit indicador de Frequência incluída, FREQ_INCL, para '1'; caso contrário, a estação base ajustará o bit para '0' .

O FBSCH_CDMA_FREQ é a designação de freqüência do canal suplementar de broadcast direto. Caso o bit FREQ_INCL seja ajustado para '0', a estação base omitirá este campo; caso contrário, as estações base ajustam este campo como a seguir: a estação base ajustará este campo ao número de canal CDMA que corresponde à designação de freqüência CDMA para o canal CDMA que contém o canal suplementar de broadcast direto. 0 FBSCH_CODE_CHAN é um índice de canal de código do canal suplementar de broadcast direto, em que a estação base ajusta este campo para o índice de canal de código que a estação móvel deve utilizar no canal suplementar de broadcast direto. O FBSCH_RC é uma configuração via rádio do canal suplementar de broadcast direto, em que a BS ajusta este campo à configuração via rádio a ser usada pela estação móvel no canal suplementar de broadcast direto. O FBSCH_RATE é a taxa de dados do canal suplementar de broadcast direto, em que a estação base ajusta este campo para a taxa de dados utilizada no canal suplementar de broadcast direto. O FBSCH_FRAME_SIZE é o tamanho de quadro do canal suplementar de broadcast direto, em que a estação base ajusta este campo para o tamanho de quadro no canal suplementar de broadcast direto. O FBSCH_FRAME_REPEAT_IND é o indicador de repetição de quadro do canal suplementar de broadcast direto, em que caso a repetição de quadro seja utilizada no canal suplementar de broadcast direto, a estação base ajusta este campo para '1'; caso contrário, a estação base ajusta este campo para '0' . O FBSCH_SHO_SUPPORTED é o indicador de suporte a soft handoff no canal suplementar de broadcast direto, em que caso a estação base suporte soft handoff no canal suplementar de broadcast direto com um ou mais de seus vizinhos, a estação base ajusta este campo para '1' ; caso contrário, a estação base ajusta este campo para '0'. O NUM_NGHBR é o número de vizinhos que suportam soft handoff no canal suplementar de broadcast direto. Caso o campo FBSCH_SHO_S(JPPORTED seja ajustado para '1', a estação base ajustará o campo NUM_NGHBR ao número de vizinhos que suportam soft handoff neste canal suplementar de broadcast direto. O NGHBR_PN é o indice de deslocamento da seqüência PN piloto de vizinho. A estação base ajusta este campo para o deslocamento de seqüência PN piloto para este vizinho, em unidades de 64 chips PN. O NGHBR_FBSCH_CODE_CHAN_INCL é o indicador de inclusão de indice de canal de código de canal suplementar de broadcast direto de piloto vizinho. Caso o indice de canal de código de canal suplementar de broadcast direto de piloto vizinho seja incluído nesta mensagem, a estação base ajusta este campo para '1'; caso contrário, a estação base ajusta este campo para '0'. O NGHBR_FBSCH_CODE_CHAN é o índice de canal de código de canal suplementar de broadcast direto de piloto vizinho. Caso o campo NGHBR_FBSCH_CODE_CHAN_INCL seja ajustado para '0' , a estação base omite o campo NGHBR_FBSCH_CODE_CHAN_INCL; caso contrário, a estação base inclui o campo NGHBR_FBSCH_CODE_CHAN_INCL e a BS ajusta o campo NGHBR_FBSCH_CODE_CHAN_INCL ao índice de canal de código que a estação móvel utilizará neste canal suplementar de broadcast direto neste vizinho. O HSBS_ID é um identificador de sessão de serviço broadcast, em que a estação base ajustará este campo ao identificador que corresponde a esta sessão de serviço broadcast. O BSR_ID é um identificador de referência de serviço broadcast, em que a estação base ajustará este campo ao identificador de referência do serviço broadcast que corresponde a esta sessão de serviço broadcast. O HSBS_ID é o identificador de sessão de serviço broadcast, em que o BS ajustará este campo ao identificador que corresponde à sessão de serviço broadcast. O FBSCH_ID é o identificador de canal suplementar de broadcast direto, em que a estação base ajustará este campo ao identificador que corresponde ao canal suplementar de broadcast direto no qual a sessão de serviço broadcast acima está sendo portada.

As opções de protocolo que requereríam negociação entre o transmissor e o receptor são selecionadas e definidas na descrição de opção de serviço. A MS utiliza o número SO enviado na BSPM para descobrir as opções de protocolo do serviço broadcast. Em contraste a um serviço de dados em pacotes unidirecionais em que a SO especifica os protocolos até a camada de rede IP, o serviço broadcast especifica protocolos até a camada de aplicação. A camada de segurança utiliza algoritmos de criptografia e autenticação comunicados durante o estabelecimento de uma associação de segurança, por exemplo, através de meios fora de banda.

Na modalidade exemplar, a camada de transporte é especificada na SO como o protocolo de transporte aplicado, tal como RTP, pode não ser identificado prontamente como a carga-útil dos pacotes UDP. A SO também especificará um número de porta UDP para a carga-útil RTP, para distinguir este dos outros tipos de tráfego UDP que podem ser enviados através do canal de broadcast. A camada de aplicação também é especificada na SO como muitos codecs de áudio e vídeo (por exemplo, MPEG-4 e EVRC) não possuem tipos de carga-útil RTP estáticos que são prontamente identificados pela estação móvel. Em uma aplicação de broadcast unidirecional, os tipos de carga-útil RTP para estes codecs devem ser designados dinamicamente através de negociação de configuração de chamada (por exemplo, utilizando SIP, RTSP, etc.). Uma vez que o serviço broadcast deseje evitar tal negociação, os decodificadores de mídia são pré-selecionados pela SO. Além disso, uma vez que os dados de áudio e vídeo podem ser portados em pacotes RTP separados, é desejado especificar os tipos de carga-útil RTP a serem utilizados por cada fluxo de mídia.

Na modalidade exemplar, o mapeamento lógico para fisico especifica o canal HSBS (HSBS_ID/BSR_ID) portado em um F-BSCH (FBSCH_ID) correspondente. 0 conjunto {HSBS_ID, BSR_ID, FBSCH_ID} especifica completamente (para a MS) onde encontrar e escutar um determinado serviço broadcast. Como tal, as informações de mapeamento lógico para fisico são transmitidas através do ar para as MSs de modo que uma MS que deseja acesso a um determinado canal HSBS pode determinar o canal F-BSCH para monitorar. Portanto, as seguintes informações são transmitidas à estação móvel através da interface aérea: parâmetros de canal fisico de broadcast; parâmetros de canal lógico de broadcast; mapeamento lógico para fisico. Uma opção para sinalizar estes parâmetros de serviço broadcast é definir uma nova mensagem de overhead no cdma2000 que é especifico para o serviço broadcast.

Uma modalidade alternativa aplica a BSPM, em que os parâmetros individuais são transmitidos em um bloco de bits, designado como BLOB, que contém opções de programa selecionáveis. Ao contrário da utilização de um número SO para identificar um conjunto de parâmetros, em que as opções de protocolo na camada de aplicação mudam requerendo assim freqüentemente redefinição, a utilização do BLOB permite mudanças na camada de aplicação sem redefinição do conjunto inteiro de parâmetros. Especificamente, o BLOB permite redefinição de um único parâmetro sem mudar o conjunto inteiro de parâmetros. Caso o serviço broadcast deva suportar muitas opções de protocolo diferentes, o problema de definir múltiplas opções de serviço na seção anterior pode ser aliviado através da definição de um BLOB de serviço broadcast. Este BLOB é enviado como parte da BSPM e identifica as opções de protocolo utilizadas para o serviço broadcast. A Figura 17 ilustra a pilha de protocolos e aplicação do BLOB. O fornecimento do BLOB provê a vantagem de que a estação móvel utiliza a BSPM para identificar a pilha de protocolos, e portanto, não são requeridos outros canais fora de banda para transmissão destas informações. Adicionalmente, a estação móvel pode determinar imediatamente a capacidade de acessar e decodificar o fluxo de broadcast sem ter que registrar-se para o serviço.

Uma desvantagem de utilizar a SO e/ou a descrição de BLOB é a utilização da infra-estrutura sem fio para coordenar os protocolos utilizados acima da camada de rede IP. Os protocolos utilizados pelo CS e pela PDSN devem coincidir àqueles definidos no BLOB enviados pela estação base.

Uma forma de prover coordenação é ter um cliente na infra-estrutura sem fio (por exemplo, BSC) solicitando informações de opção de protocolo a partir do CS e da PDSN. O BSC a seguir traduz estas informações no BLOB de serviço broadcast correspondente enviado na BSPM. Os protocolos utilizados entre o cliente BSC e o servidor de conteúdo e PDSN estarão baseados em protocolos padrão, tal como aqueles especificados no cdma2000. O cliente no BSC utiliza RTSP para solicitar uma descrição das camadas de aplicação e de transporte a partir do CS utilizando SDP. O cliente também utiliza IPCP para solicitar informações de compressão de cabeçalho a partir da PDSN. Para limitar o número de protocolos que a estação móvel deve suportar, deveríam ser definidas opções de protocolo obrigatórias e opcionais para o serviço broadcast.

REDE DE ACESSO

Uma topologia de rede de acesso geral para um sistema 1000 está ilustrada na Figura 13 possuindo um CS 1002, uma PDSN 1004 e duas PCFs: PCF1 1006 e PCF2 1008. A Figura 13 inclui datagramas que especificam as transmissões a partir de cada um dentre os elementos de infra-estrutura ilustrados no sistema 1000. Conforme ilustrado, o CS 1002 prepara um pacote IP de informações e transmite o pacote em pelo menos um quadro, possuindo uma carga útil e cabeçalho interno, H1. O cabeçalho interno possui informações de origem e destino, em que a origem identifica o CS 1002 e o destino identifica um grupo de assinantes. O CS 1002 transmite o quadro à PDSN 1004, que mapeia o grupo de assinantes de destino para assinantes individuais em um conjunto de usuários ativos. A PDSN 1004 determina o número de usuários individuais no conjunto ativo que estão no grupo de assinantes de destino e duplica o quadro recebido a partir do CS 1002 para cada um dentre tais usuários. A PDSN 1004 determina a(s) PCF(s) correspondente {s) a cada um dos usuários no grupo de assinantes. A PDSN 1004 então anexa um cabeçalho externo, H2, a cada um dos quadros preparados, em que H2 identifica uma PFC. A PDSN 1004 então transmite os quadros para a(s) PCF(s). A transmissão a partir da PDSN 1004 inclui a carga útil original, o cabeçalho Hl e o cabeçalho H2. Conforme ilustrado, a PDSN 1004 envia N quadros de transmissão à PCF1 1006 e envia H quadros de transmissão à PCF2 1008. Os N quadros de transmissão correspondem a N usuários no grupo de assinantes servidos via PCF1 1006 e os M quadros de transmissão correspondentes aos M usuários no grupo de assinantes servidos via PCF2 1008 . Neste cenário, a PDSN 1004 duplica quadros recebidos qualquer número de vezes para transmissão aos assinantes correspondentes. A figura 14 ilustra uma modalidade exemplar de um sistema 1020 que possui um CS 1022 que se comunica com PCF1 1026 e PCF2 1028 via PDSN 1024. Conforme ilustrado, o CS 1022 prepara um pacote IP de informações e transmite o pacote em pelo menos um quadro, possuindo uma carga útil e cabeçalho interno, Hl. O cabeçalho interno possui informações de origem e destino, em que a origem identifica o CS 1022 e o destino identifica um grupo de assinantes. O CS 1022 transmite o quadro à PDSN 1024, em que a PDSN 1024 anexa um cabeçalho externo, H2, em que H2 roteia o quadro para pelo menos uma PCF. A PDSN 1024 então transmite os quadros à(s) PCF(s) . Δ transmissão a partir da PDSN 1024 inclui a carga útil original, o cabeçalho H1 e o cabeçalho H2. Conforme ilustrado, a PDSN 1024 envia um quadro de transmissão à PCFl 1026 e envia um quadro de transmissão ao PCF2 1028. A PCFl 1026 envia um quadro de transmissão aos N usuários no grupo de assinantes. A PCF2 1028 envia um quadro de transmissão aos M usuários no grupo de assinantes.

De acordo com uma modalidade exemplar, o CS de broadcast envia pacotes IP contendo conteúdo de broadcast criptografado a um grupo multicast identificado por um endereço IP multicast classe-D. Este endereço é utilizado no campo de endereço de destino dos pacotes IP. Oma dada PDSN 1024 participa no roteamento multicast destes pacotes. Após compressão de cabeçalho, a PDSN 1024 coloca cada pacote em um quadro HDLC para transmissão. O quadro HDLC é encapsulado por um pacote de Encapsulamento de Roteamento Genérico (GRE). 0 campo chave do cabeçalho de pacote GRE utiliza um valor especial para indicar uma conexão portadora por broadcast. O pacote GRE é anexado o cabeçalho de pacote IP de 20 bytes possuindo um campo de endereço de origem identificando o endereço IP da PDSN 1024, e campo de endereço de destino utiliza um endereço IP multicast classe-D. É recomendado que este endereço IP multicast seja diferente do utilizado pelo CS broadcast. O sistema 1020 configura pelo menos uma tabela de roteamento multicast das respectivas PCFs e PDSNs. Os pacotes entregues na conexão broadcast são providos em seqüência; na modalidade exemplar a característica de seqüenciamento de GRE está habilitada. A duplicação dos pacotes IP multicast é feita em roteadores capazes de multicast. A Figura 18 ilustra um método 2000 para prover informações de parâmetro e de protocolo do serviço broadcast utilizando uma BSPM. Na etapa 2002 a MS recebe a BSPM a partir do CS. A BSPM é como acima descrita. A MS extrai o número SO a partir da BSPM na etapa 2004. O número SO é mapeado a um conjunto suficiente de parâmetros e protocolos para a MS para receber o broadcast desejado. A MS a seguir inicia a pilha de protocolos que corresponde ao número SO selecionado na etapa 2008. Uma vez que a pilha de protocolos é iniciada, a MS é capaz de receber e decodificar informações recebidas no canal de broadcast na etapa 2010. Observa-se que a BSPM é transmitida em um Canal Walsh separado conhecido dos assinantes. A Figura 19 ilustra uma mapeamento 2020 de cada um dos números SO para um conjunto de parâmetros e protocolos. Quando o CS programar inicialmente um broadcast, tal como uma partida de futebol em um determinado dia, o CS determina os parâmetros e protocolos a serem utilizados para transmissão do broadcast a partir de um conjunto de opções previamente padronizadas.

Em uma modalidade, o número SO corresponde a um conjunto fixo de protocolos e parâmetros, em que o mapeamento é conhecido do CS e da MS. O conhecimento a priori do mapeamento evita a necessidade de transmitir as informações e assim reduz o overhead de transmissão, isto é, conserva a largura de banda. Os mapeamentos são armazenados na MS e portanto, não são mudados prontamente ou atualizados. Caso o CS utilize uma combinação de parâmetros que não foram previamente padronizados como um número SO, a Organização Padrão deve definir um novo perfil de parâmetros antes que esta combinação de parâmetros possa ser utilizada para o broadcast.

A utilização de um BLOB de informações é ilustrado na Figura 20, em que uma sessão de broadcast é designada a um conjunto de parâmetros. Cada parâmetro pode ser uma de múltiplas opções. A transmissão dos parâmetros provê mais flexibilidade em comparação à utilização de conjuntos fixos de parâmetros associados a um número SO. O CS pode selecionar quaisquer das opções disponíveis e transmitir as informações para a MS. Como ilustrado, o CAMPO 2 do BLOB pode ser especificado como qualquer das opções: OPÇÃO 1 a OPÇÃO K, em que cada campo do BLOB pode ter um número diferente de opções disponíveis.

Uma modalidade alternativa provê os protocolos de broadcast e parâmetros através de sinalização fora de banda no fluxo de broadcast. Na discussão atual, fora de banda indica um canal separado utilizado para comunicação das informações de overhead. O canal separado pode ser uma freqüência diferente ou pode ser um canal de espalhamento espectral, tal como um canal definido por um código Walsh diferente. O sistema provê as informações de parâmetro e de protocolo de broadcast ao assinante quando o assinante inicia uma chamada de dados em pacotes. O assinante ou MS, primeiro solicita informações de compressão de cabeçalho a partir da PDSN. Utilizando as informações recebidas a partir da PDSN, a MS é capaz de receber as informações de overhead de broadcast. A MS contacta o CS através de protocolos tipo IP, por exemplo, RTSP ou SIP, para receber uma descrição das camadas de transporte e de aplicação. A MS utiliza estas informações para receber, decodificar e processar uma sessão de broadcast. A Figura 21 ilustra os diversos canais utilizados para transmissão de várias informações em um sistema de broadcast. Como ilustrado o sistema 3000 inclui um CS 3002 e uma MS 3004, comunicando-se através de um canal de broadcast 3010, um canal de overhead 3012 e um canal de tráfego 3014. O conteúdo de broadcast de uma determinada sessão de broadcast é transmitido no canal de broadcast 3010, que pode ser uma freqüência designada exclusivamente ou pode ser um canal Walsh designado exclusivamente. A transmissão de uma mensagem BSPM é provida no canal de overhead 3012. O canal de tráfego 3014 é usado para transmissão de sinalização fora de banda, tal como comunicação entre CS e MS, e comunicações entre PDSN (não mostrado) e MS. A MS pode contactar o CS e a PDSN diretamente, utilizando sinalização fora de banda através de uma opção de serviço de dados em pacotes. Ά comunicação fora de banda permite que o CS atualize as informações sem transmissão através da BS, como a comunicação fora de banda é direta entre a MS e a PDSN ou entre a MS e o CS. Observa-se que quando utiliza-se o serviço de dados em pacotes como meio fora de banda, a comunicação entre a MS e o CS ainda passa pela BS. Porém, a BS não requer conhecimento da carga-útil, portanto, fazendo-o desnecessário para coordenar · os protocolos CS e BS.

Para evitar as desvantagens dos métodos fora de banda de transmissão dos protocolos e parâmetros aos receptores, a descrição SDP a partir do CS pode ser multiplexada no fluxo de broadcast. Isto permite que a estação móvel determine as opções de protocolo utilizadas pelo CS sem configurar uma chamada de dados em pacotes. A descrição SDP é enviada tão freqüentemente quanto uma chave de criptografia de curta duração (SK -short-term encryption key) no fluxo de broadcast. A taxa de envio destas atualizações será limitada pela quantidade de largura de banda disponível para tais atualizações. Como exemplo, caso a descrição SDP seja de 300 bytes em tamanho e enviada a cada 3 segundos, a largura de banda exigida é de 800 bps. Observa-se que uma vez que a descrição SDP é originada a partir do servidor de conteúdo, o servidor de conteúdo pode melhorar a qualidade de mídia através da multiplexação da mensagem SDP no fluxo de broadcast quando a largura da banda de mídia for muito estreita para acomodá-la. Efetivamente as informações SDP podem ser baseadas adaptativamente em condições de largura de banda. Portanto, como a condição de canal e ou tensões na largura de banda da mudança de sistema, a freqüência da transmissão SDP também pode mudar. De modo semelhante, pode ser possível mudar o tamanho do SDP mediante ajuste das informações contidas nele, específicas a um determinado sistema. A descrição SDP é transportada tipicamente nas mensagens RTSP, SAP ou SIP. Para evitar o overhead de tais protocolos, é recomendado que a descrição SDP seja transportada diretamente através do UDP mediante identificação de um número de porta UDP bem-conhecido para portar a mensagem SDP. Este número de porta não deve ser utilizado para portar RTP ou outros tipos de tráfego UDP enviados através do canal de broadcast. A soma de verificação (checksum) UDP proverá detecção de erros para a carga-útil SDP.

De acordo com uma modalidade ilustrada na Figura 22, o sistema provê os protocolos e parâmetros de broadcast através de sinalização em banda no fluxo de broadcast. 0 fluxo de broadcast 4000 possui o conteúdo de broadcast e é transmitido no canal de broadcast, tal como o canal de broadcast 3010 da Figura 21. O SDP 4002 é intercalado ao longo do fluxo de broadcast 4000. Ά Figura 23 ilustra um método 5000 para prover informações de parâmetro e protocolo de serviço broadcast utilizando um método em banda, em que as informações tipo overhead são providas com o conteúdo de broadcast no canal de broadcast. O termo em banda pretende indicar que informações tipo overhead são providas no mesmo canal como conteúdo de broadcast e assim não solicitam um mecanismo de transmissão separado, isto é, canal. O método 5000 primeiro acessa a BSPM na etapa 5002. A MS extrai as informações de canal de broadcast, as informações da camada física e as informações da camada MAC a partir da BSPM. As informações de compressão de cabeçalho são recebidas diretamente a partir da PDSN na etapa 5004. Isto pode ser feito tanto tendo a MS contato diretamente com a PDSN através de uma opção de serviço de dados em pacote (fora de banda) ou mediante a inserção PDSN das informações de configuração de compressão de cabeçalho no fluxo de broadcast para a MS. Na etapa 5006 a MS acessa o conteúdo de broadcast (BC -Broadcast Content). Em resposta à recepção das informações de compressão de cabeçalho, a MS pode receber o SDP transmitido no canal de broadcast com o conteúdo de broadcast na etapa 5008. O SDP contém parâmetros e protocolos para recepção da sessão de broadcast associada. A MS aplica as informações contidas no SDP para receber, decodificar e processar conteúdo de broadcast recebido no canal de broadcast na etapa 5010.

Quando um assinante do serviço broadcast deseja mudar para outra sessão de broadcast, a configuração e/ou iniciação da nova sessão de broadcast podem introduzir retardos inaceitáveis para o assinante. Uma modalidade provê uma unidade de memória armazenadora no receptor, em que pelo menos uma parte das informações é armazenada no receptor e pode ser utilizada para mudar rapidamente de uma sessão de broadcast, isto é, de um programa para outro, ou alternativamente, pode ser utilizado para recordar de uma sessão de broadcast previamente acessada. A Figura 24 ilustra uma memória armazenadora 6000 que armazena o SPI e o SDP que correspondem a cada sessão de broadcast acessada. As informações de overhead que correspondem à sessão de broadcast atual é armazenada na memória 6000, em que as informações armazenadas são as últimas informações recebidas. Em uma modalidade, a memória armazenadora 6000 é uma unidade de memória armazenadora primeiro a entrar, primeiro a sair (FIFO - First In First Out) . Em uma modalidade alternativa, é utilizada uma memória cache. Em ainda outra modalidade, uma tabela de consulta (LUT - Look Up Table) armazena informações relativas às sessões de broadcast acessadas.

Em modalidades que utilizam mecanismos tal como memória cache e/ou LUT, a MS utiliza um algoritmo simples de marca de tempo (time-stamp algorithm) para manter apenas uma cópia das configurações mais recentes de SPI-SDP na memória. Para cada par SPI-SDP, a MS mantém uma marca de tempo de quando a MS recebeu a última descrição. Caso a MS detecte um SPI que já existe em sua memória, ela utiliza a configuração armazenada e atualiza a marca de tempo para o tempo atual. Caso o SPI detectado não esteja na memória das MSs, a MS substitui a entrada SPI-SDP mais antiga em sua memória com o par SPI-SDP recentemente detectado. A MS utiliza agora esta configuração nova para decodificar o fluxo de broadcast.

FLUXO DE MENSAGEM A Figura 5 ilustra o fluxo de chamada para acesso a uma sessão de broadcast na modalidade exemplar para uma determinada topologia de sistema. O sistema inclui uma MS, BS, PDSN e CS, como listado no eixo horizontal. O eixo vertical representa o tempo. O usuário ou a MS é um assinante do serviço HSBS. No momento tl a MS e o CS negociam a segurança da assinatura pelo serviço broadcast. A negociação envolve troca e manutenção de chaves de criptografia, etc., utilizadas para receber o conteúdo de broadcast no canal de broadcast. O usuário estabelece uma associação de segurança com o CS na recepção das informações criptografadas. As informações criptografadas podem incluir uma chave de acesso ao broadcast (BAK -Broadcast Access Key) ou uma combinação de chaves, etc., a partir do CS. De acordo com a modalidade exemplar, o CS provê as informações criptografadas através de um canal exclusivo durante uma sessão de dados em pacotes, tal como por PPP, WAP, ou outros métodos fora de banda.

No momento t2 a MS sintoniza no canal de broadcast e começa a receber pacotes. Neste momento, a MS está habilitada para processar os pacotes recebidos porque o cabeçalho IP/ESP é comprimido através da ROHC, e o descompressor da MS não foi inicializado. A PDSN provê informações de compressão de cabeçalho (detalhadas abaixo) no momento t3. A partir do cabeçalho do pacote ROHC, a MS detecta e obtém um pacote de Inicialização e Refresh (IR) ROHC enviado periodicamente a partir da PDSN ao canal de broadcast. O pacote IR ROHC é utilizado para inicializar o estado do descompressor na MS, permitindo-a descomprimir o cabeçalho IP/ESP dos pacotes recebidos. A MS pode a seguir processar o cabeçalho IP/ESP dos pacotes recebidos, porém, a MS requer'informações adicionais para processar a carga-útil ESP, uma vez que a carga-útil é criptografada com uma chave de curta duração (SK - Short-term Key) no CS. A SK atua na coordenação com a BAK, em que a SK é decriptografada no receptor utilizando a BAK. O CS provê informações adicionais de criptografia, tal como informações de chave atualizadas ou uma SK atual no momento t4 . Observa-se que o CS provê estas informações periodicamente à MS para assegurar a segurança continua do broadcast. No momento t5 a MS recebe o conteúdo de broadcast a partir do CS. Observa-se que modalidades alternativas podem incorporar métodos de compressão e de descompressão alternativos que provêem transmissão eficiente das informações de cabeçalho. Adicionalmente, modalidades alternativas podem implementar uma variedade de esquemas de segurança para proteger o conteúdo de broadcast. As modalidades alternativas ainda podem prover um serviço broadcast não seguro. A MS utiliza as informações criptografadas, tal como a SK, para decriptografar e exibir conteúdo de broadcast.

COMPRESSÃO

De acordo com a modalidade exemplar, o conteúdo de broadcast é transmitido em um canal de broadcast exclusivo. A camada de transporte provê overhead de criptografia para portar conteúdo de broadcast em pacotes IP. O sistema suporta compressão de dados e especificamente compressão de cabeçalho. A decisão para comprimir dados depende da vazão média solicitada (incluindo overhead de transporte / criptografia, overhead da camada de enlace de dados e overhead da camada fisica) e percepção do usuário da qualidade de broadcast. O overhead é reduzido ao portar mais conteúdo de broadcast em cada pacote IP e assim a largura da banda do canal de broadcast é reduzida. Em contraste, a compressão aumenta a taxa de erros de pacotes (PER - Packet Error Rate) que afeta a percepção do usuário. Isto ocorre devido à transmissão de cada pacote IP longo que atravessa quadros de múltiplas camadas fisicas e portanto é associado a aumentos na taxa de erros de quadros (FER - Frarae Error Rate). Caso um portador decida utilizar pacotes IP pequenos para melhorar a qualidade de broadcast, a portadora pode escolher compressão de cabeçalho para reduzir o overhead de transporte e criptografia do pacote IP.

Os protocolos RTP/UDP/IP são utilizados para transportar conteúdo de broadcast a partir do CS para a MS e o conteúdo é protegido pelo ESP no modo de transporte. O overhead de transporte é o cabeçalho RTP/UDP/IP e possui 40 bytes por dados de pacote IP. O overhead de criptografia está na forma de cabeçalho ESP, vetor de inicialização (IV - Initialization Vector) e trailer ESP. O cabeçalho ESP e o IV são inseridos entre o cabeçalho IP e o cabeçalho UDP. O cabeçalho ESP consiste no SPI (4 bytes) e do número de seqüência (4 bytes) . O comprimento do IV é especifico para qual algoritmo de criptografia for utilizado. Para o algoritmo de cifra AES, o comprimento do IV é de 16 bytes. O trailer ESP é anexado ao fim do datagrama UDP e consiste no enchimento, próximo cabeçalho (1 byte) e comprimento do enchimento (1 byte) . Uma vez que o tamanho do bloco de cifra do algoritmo AES é de 16 bytes, o tamanho do enchimento varia de 0 a 15 bytes. Aplicando-se a função conformadora do tamanho de enchimento médio obtém-se 8 bytes. Para um pacote IP o overhead total devido ao transporte e à criptografia varia de 66 a 81 bytes com a média de 7 4 bytes não incluindo o overhead da camada de enlace de dados a partir da PDSN para a MS. A figura 6 ilustra um formato IP 400, em que um datagrama pode ser fragmentado em múltiplas cargas úteis. Cada fragmento é transmitido possuindo uma parte de cabeçalho e de carga útil. Os cabeçalhos 404 e 410 identificam o comprimento de cada fragmento, COMPRIMENTO 404, 410, respectivamente. üm enchimento 414 pode ser acrescentado ao último fragmento. Os campos CONT 402 e 408 são utilizados para conectar fragmentos. A compressão de cabeçalho tal como a compressão de cabeçalho robusta (ROHC - Robust Cabeçalho Compression) pode ser utilizada para reduzir o cabeçalho IP e o campo SPI do cabeçalho ESP de 24 bytes para 2 bytes. O número de seqüência do cabeçalho ESP não está comprimido, porque é utilizado para colocar em seqüência os pacotes comprimidos. Ο IV não é comprimido, porque ele varia aleatoriamente para cada pacote. O cabeçalho UDP/RTP e o trailer ESP não podem ser comprimidos porque eles são criptografados. Conseqüentemente, caso a ROHC seja utilizada para comprimir o cabeçalho IP/ESP, o overhead médio devido ao transporte e criptografia é reduzido de 74 bytes para 52 bytes por pacote IP.

De acordo com a modalidade exemplar, a compressão de cabeçalho, tal como a compressão de cabeçalho robusta (ROHC), é aplicada para evitar a propagação de erros de descompressão. Como ilustrado na Figura 7, as informações de cabeçalho são comprimidas de 24 bytes até 2 bytes. O cabeçalho 500 inclui um cabeçalho IP 502 e uma parte SPI 504. O algoritmo de compressão obtém um resultado de 2 bytes após a compressão. Diferentemente da compressão de cabeçalho convencional, em que algum tipo de negociação é solicitada entre a MS e a PDSN ou outro elemento de infra-estrutura, a modalidade exemplar provê uma transmissão unidirecional de informações de compressão. A MS não precisa solicitar as informações de compressão, isto é, parâmetros de compressão de cabeçalho suficientes para descompressão das informações recebidas na MS.

Preferencialmente, a PDSN provê as informações de compressão periodicamente como ilustrado na Figura 8. A PDSN provê as informações de compressão no canal de broadcast intercalado com o conteúdo de broadcast. A provisão de informações de controle dentro de um fluxo de dados é designada como "em banda", uma vez que um canal separado não é solicitado. Como ilustrado, o fluxo de broadcast 600 inclui porções de conteúdo de broadcast 604 e informações de descompressão, isto é, informações de compressão, 602. As informações de descompressão são providas possuindo um período TDEScompressão* Modalidades alternativas podem prover informações de descompressão na ocorrência de um evento predeterminado em lugar de periodicamente. Como a MS não solicita as informações de descompressão, a PDSN fornece as informações com uma freqüência que impede retardos no acesso do conteúdo de broadcast. Em outras palavras, a PDSN deveria prover as informações freqüentemente, de forma que uma MS possa acessar o broadcast em qualquer momento sem ter que esperar pelas informações de descompressão.

Observa-se que a ROHC pode ser operada em um modo unidirecional, em que, pacotes são enviados em apenas uma direção: a partir do compressor para o descompressor. Este modo, portanto, faz a ROHC utilizável através de links em que um percurso de retorno a partir do descompressor para o compressor é indisponível ou indesejável. Antes que a MS possa descomprimir pacotes recebidos a partir do canal de broadcast, o estado do descompressor é inicializado. O pacote Inicialização e Refresh (IR) é utilizado para este propósito. Há duas alternativas para a inicialização da ROHC. O assinante "sintoniza" no canal de broadcast e aguarda pelos pacotes IR ROHC enviados periodicamente pelo compressor ROHC na PDSN. Pacotes IR ROHC freqüentes podem ser necessários para que a MS inicie a descompressão de pacotes recebidos rapidamente. Pacotes IR ROHC freqüentes podem usar muita largura da banda no canal de broadcast. Um pacote IR possui aproximadamente 30 bytes para o perfil de compressão IP/ESP. Caso um pacote IR seja enviado uma vez a cada 250 ms, o processo consome aproximadamente 1 kbps no canal de broadcast. A perda de pacotes IR através do ar retardariam adicionalmente a MS para adquirir inicialização ROHC .

Caso a descompressão ocorra fora de sincronia, devido à perda de pacote, ou erro residual no cabeçalho comprimido recebido, ou falha, etc., o erro de descompressão resultante pode propagar-se até que a descompressão seja ressincronizada ou reinicializada. Um cabeçalho comprimido ROHC contém uma verificação por redundância ciclica (CRC - Cyclic Redundant Check), que é calculada através do cabeçalho inteiro antes da compressão. Esta CRC permite descompressão para efetuar um reparo de contexto local que traz o contexto em sincronia (nos casos de perda de pacote e erro residual). Quando a descompressão recupera-se de uma falha, os pacotes IR periódicos reinicializam efetivamente o processo de descompressão. CAMADA DE TRANSPORTE

Um protocolo de enquadramento de camada de enlace de dados ou protocolo de camada de transporte é aplicado entre a PDSN e a MS para delinear pacotes recebidos a partir do canal de broadcast. Fazendo referência à Figura 3, as informações na camada de transporte, identificadas como CAMADA DE ENLACE, são providas entre a PDSN e a MS. As informações de enquadramento são geradas na PDSN e são providas à MS através da BS . A PDSN recebe fluxos IP a partir do CS e enquadra os fluxos IP de acordo com um protocolo de enquadramento predeterminado. Como ilustrado na modalidade exemplar, a PDSN aplica uma versão de protocolo de enquadramento do controle de link de dados de alto nivel (HDLC - High-Level Data Link Control). O HDLC especificado no padrão ISO corresponde à Camada 2 da arquitetura de 7 camadas da organização de padrões internacionais (ISO), em que a Camada 2 é designada como a camada de enlace de dados. O protocolo HDLC busca prover movimento de dados livre de erros entre nodos de rede. Para este fim, a camada HDLC é projetada para assegurar a integridade dos dados passados a uma próxima camada. Em outras palavras, o protocolo de enquadramento busca reproduzir os dados recebidos exatamente como os dados foram transmitidos originalmente, sem erros, sem perda de informações, e na ordem correta. A modalidade exemplar aplica uma versão do enquadramento HDLC que por sua vez, aplica um subconjunto dos parâmetros definidos do HDLC. A Figura 9 ilustra uma modalidade do enquadramento HDLC, em que o quadro 700 inclui uma pluralidade de campos como definido pelo protocolo HDLC esboçado no RFC 1662. O campo 702 define um FLAG ou indicação de um inicio de quadro. O FLAG possui um comprimento de bits designado e é definido por um padrão de bits predeterminado. É conveniente aplicar o HDLC, uma vez que o HDLC é um protocolo padronizado normalmente disponível. Uma desvantagem do protocolo de enquadramento HDLC completo é o tempo de processamento solicitado para gerar os quadros no transmissor e para recuperar os quadros no receptor.

Em particular, o protocolo HDLC é considerado intensivo em processamento uma vez que processamento adicional é utilizado para assegurar que a carga-útil não inclua a mesma seqüência de bits que o FLAG. No transmissor, caso uma seqüência de FLAG de bits seja detectada na carga-útil, um caractere de escape é inserido na carga-útil para identificar o FLAG como parte da carga-útil e não indicando um inicio de quadro. O processo de somar um caractere de escape é designado como "escapando" dos padrões hexadecimais de 0x7E e 0x7D na carga-útil de quadro. Um método alternativo designado como protocolo de enquadramento eficiente (Efficient Framing Protocol) que é menos intensivo em processamento que o enquadramento tipo HDLC é descrito abaixo. A Figura 9 ilustra as opções de usar enquadramento HDLC para transportar quadro PPP. Para a operação HSBS, o overhead de enquadramento tipo HDLC pode ser reduzido ao eliminar o campo que não é solicitado, ou tem pouco significado e/ou provê poucas informações, para um broadcast unidirecional. Como descrito acima, o FLAG é uma seqüência predeterminada de bits que indicam o inicio de um quadro HDLC. A modalidade exemplar incorpora um FLAG ou outro inicio de indicador de quadro 802, como ilustrado dentro do formato 800 da Figura 10. Diferentemente do formato da Figura 9, o final de um quadro não é indicado com informações de overhead na modalidade exemplar. Como o campo endereço 704 e o campo controle 7 06 do formato 700 possuem valores estáticos, estes não são incluidos no formato 800.

Continuando com a Figura 10, como o propósito do campo Protocolo 708 (Figura 9) é identificar o tipo de carga-útil, tal como pacote de controle LCP, pacote ROHC, pacote IP, etc., este discriminador não é solicitado para operação de broadcast uma vez que todos os pacotes no canal de broadcast pertencem ao mesmo tipo. Como exemplo, caso a compressão ROHC for utilizada para transmissão de pacotes, todos os pacotes no canal de broadcast são processados como pacotes ROHC. Os tipos de pacotes ROHC, tal como pacote IR, pacote comprimido, etc., são distinguidos pelo campo Tipo de Pacote no cabeçalho de pacote ROHC. Portanto, o campo Protocolo não é incluido no formato 800. Adicionalmente, o formato 800 inclui um campo de verificação de erros 806 após a carga-útil 804. O campo de verificação de erros 806 provê informações ao receptor para permitir ao receptor verificar erros na carga-útil recebida. A modalidade exemplar incorpora uma soma de verificação de quadro (FCS -Frame Check Sum) 712 que pode ser especificada como nulo, 16 bits ou 32 bits. Uma vez que um quadro HDLC pode atravessar múltiplos quadros de camada fisica no canal de broadcast, é recomendado utilizar um FCS de 16 bits. O procedimento de enchimento de octeto definido no RFC 1662 é também aplicado na modalidade exemplar, em que após a computação FCS, o transmissor HDLC no PDSN examina cada byte no quadro HDLC (excluindo o FLAG) para os padrões de 0x7E e 0x7D. O padrão 0x7E será codificado como 0x7D e 0x5E, e o padrão 0x7D será codificado como 0x7D e 0x5D. 0 transmissor HDLC não codificará nenhum outro padrão. Isto significa que o mapa de caractere de controle assincrono (ACCM - Async-Control-Character-Map) como definido no RFC 1662 é todo ajustado para zero. O overhead de enquadramento HDLC é de 3 bytes mais o overhead de enchimento de octeto. Assumindo que o padrão de byte seja distribuído uniformemente, o overhead de enchimento de octeto médio é de um byte por 128 bytes de quadro HDLC. Como exemplo, caso a carga-útil seja de 256 bytes, o overhead de enquadramento HDLC é, na média, de 5 bytes. A Figura 11 é um fluxograma de um método de enquadramento 900 executado no transmissor. O transmissor forma o quadro de broadcast na etapa 902 ao determinar uma parte de carga-útil dos dados empacotados e gerar um início de flag (SOF - Start Of Flag) . O transmissor a seguir verifica o quadro por qualquer seqüência SOF contida na carga-útil 904 . Caso uma seqüência SOF seja encontrada na carga-útil, o transmissor soma um caractere de escape na etapa 912. Caso contrário, o transmissor anexa o SOF à carga-útil na etapa 906 e provê um mecanismo de verificação de erros na etapa 908. O quadro é transmitido na etapa 910. 0 quadro transmitido possui o formato 800 da Figura 10. Modalidades alternativas podem implementar outros campos dentro do formato de enquadramento e podem incorporar qualquer forma de classificador para localizar uma seqüência SOF na carga-útil. A Figura 12 é um fluxograma de um método de desenquadramento 920 executado no receptor. O processo é iniciado após a recepção de um quadro de broadcast na etapa 922. O receptor identifica um SOF na etapa 924 e verifica caracteres de escape na carga-útil no losango de decisão 926. Caso um caractere de escape, ou outro identificador de seqüência SOF, seja encontrado na carga-útil, o receptor remove o caractere de escape na etapa 932 . Caso contrário, o receptor executa uma verificação de erros na etapa 928 e processa o quadro na etapa 930.

Os versados na técnica notarão que as informações e sinais podem ser representados utilizando-se quaisquer dentre uma diversidade de diferentes tecnologias e técnicas. Como exemplo, os dados, instruções, comandos, informações, sinais, bits, símbolos e chips que possam ter sido mencionados por toda a descrição acima podem ser representados por tensões, correntes, ondas eletromagnéticas, campos ou partículas magnéticas, campos ou partículas ópticas, ou quaisquer combinações de tais.

Os versados na técnica notarão adicionalmente que os vários exemplos de blocos lógicos, módulos, circuitos e etapas de algoritmos descritos em conexão com as modalidades aqui descritas podem ser implementados na forma de hardware eletrônico, software de computador, ou combinações de tais. Para ilustrar claramente tal intercambialidade de hardware e software, vários exemplos de componentes, blocos, módulos, circuitos e etapas foram acima descritos de um modo geral em termos de sua funcionalidade. Se tal funcionalidade é implementada na forma de um hardware ou software depende da aplicação especifica e restrições de projeto impostas ao sistema como um todo. Os versados na técnica podem implementar a funcionalidade descrita de diversas formas para cada aplicação especifica, porém tais decisões de implementação não devem ser interpretadas como um afastamento do escopo da presente invenção.

Os vários exemplos de blocos lógicos, módulos e circuitos aqui descritos em conexão com as modalidades aqui apresentadas podem ser implementados ou efetivados por meio de um processador de utilização geral, um processador de sinais digitais (DSP), um circuito integrado de aplicação especifica (ASIC), um arranjo de portas programável em campo (FPGA) ou outros dispositivos lógicos programáveis, portas discretas ou lógica de transistores, componentes de hardware discretos, ou quaisquer combinações de tais projetadas para efetuar as funções aqui descritas. Um processador de utilização geral pode ser um microprocessador, porém como alternativa, o processador pode ser qualquer processador, controlador, microcontrolador, ou máquina de estados convencionais. Um processador também pode ser implementado na forma de uma combinação de dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo DSP, ou qualquer outra tal configuração.

As etapas de um método ou algoritmo descritos em conexão com as modalidades aqui apresentadas podem ser efetivadas diretamente em hardware, em um módulo de software executado por um processador, ou em uma combinação de ambos. Um módulo de software pode residir em uma memória RAM, memória flash, memória ROM, memória EPROM, memória EEPROM, registradores, disco rigido, um disco removível, um CD-ROM, ou qualquer outra forma de meio de armazenamento conhecido pelos versados na técnica. Um meio de armazenamento exemplar é acoplado ao processador de tal forma que o processador possa ler informações provenientes do, e gravar informações no, meio de armazenamento. Como alternativa, o meio de armazenamento pode estar integrado ao processador. O processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um terminal de usuário. Como alternativa, o processador e o meio de armazenamento podem residir na forma de componentes discretos em um terminal de usuário. A descrição acima das modalidades preferidas é provida para permitir que os versados na técnica efetivem ou utilizem a presente invenção. As diversas modificações dessas modalidades ficarão prontamente claras para os versados na técnica e os princípios genéricos aqui definidos podem ser aplicados a outras modalidades sem o afastamento do espirito ou escopo da invenção. Dessa forma, a presente invenção não deve ser limitada às modalidades aqui apresentadas, devendo estar de acordo com o escopo mais amplo, consistente com os princípios e características de novidade aqui descritos.

Claims (14)

1. Método, em um sistema de comunicação sem fio (100) suportando um serviço de broadcast (204), o sistema adicionalmente compreendendo uma rede de serviço de dados empacotados (202, 204, 1024), o método caracterizado pelo fato de que compreende as etapas de: transmitir uma sessão de broadcast em um canal de transmissão de broadcast (3010); transmitir informações de overhead de broadcast correspondentes à sessão de broadcast em um canal de transmissão de overhead (3012); atualizar informações de compressão de cabeçalho com a rede de serviço de dados empacotados (202, 1004, 1024); e atualizar uma parte das informações de overhead de broadcast durante uma transmissão de broadcast.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que: o serviço de broadcast (204) é transmitido por um servidor de conteúdo (3002); o serviço de broadcast (204) possui uma pilha de protocolos correspondente possuindo uma camada de aplicação e uma camada de transporte; e o servidor de conteúdo (3002) controla independentemente os protocolos da camada de aplicação e da camada de transporte.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o serviço de broadcast (204) é transmitido como pacotes de dados de Protocolo Internet.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: transmitir as informações de overhead de broadcast com a parte atualizada.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: transmitir, pela rede de serviços de dados empacotados {202, 1004, 1024), as informações de compressão de cabeçalho atualizadas em um canal de transmissão de overhead (3012).

6. Método, em um sistema de comunicação sem fio suportando um serviço de broadcast (204), o sistema adicionalmente compreendendo uma rede de serviços de dados empacotados (202, 1004, 1024), o método caracterizado pelo fato de que compreende as etapas de: receber informações de overhead de broadcast correspondentes a uma seção de broadcast em um canal de transmissão de overhead (3012); receber informações de compressão de cabeçalho atualizadas da rede de serviço de dados empacotados (202, 1004, 1024) em um canal de transmissão de overhead (3012); receber, durante uma transmissão de broadcast, informações de overhead de broadcast atualizadas em um canal de transmissão de overhead (3012); acessar a seção de broadcast em um canal de transmissão de broadcast (3010); e utilizar as informações de overhead de broadcast para processar conteúdo de broadcast da seção de broadcast.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que: o serviço de broadcast (204) é transmitido por um servidor de conteúdo (3002); o serviço de broadcast (204) possui uma pilha de protocolos correspondente possuindo uma camada de aplicação e uma camada de transporte; e o servidor de conteúdo (3002) controla independentemente os protocolos da camada de aplicação e da camada de transporte.

8. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que o serviço de broadcast (204) é transmitido como pacotes de dados de Protocolo Internet.

9. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende adicionalmente: processar conteúdo de broadcast recebido no canal de transmissão de broadcast (3010) utilizando as informações de overhead de broadcast atualizadas.

10. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende adicionalmente: utilizar as informações de compressão de cabeçalho atualizadas para receber o conteúdo de broadcast.

11. Equipamento sem fio, caracterizado pelo fato de que compreende: uma rede de serviço de dados empacotados (202, 1004, 1024); dispositivos para receber informações de overhead de broadcast correspondentes a uma seção de broadcast em um canal de transmissão de overhead (3012); dispositivos para receber informações de compressão de cabeçalho atualizadas a partir da rede de serviço de dados empacotados (202, 1004, 1024) em um canal de transmissão de overhead (3012); dispositivos para receber, durante uma transmissão de broadcast, informações de overhead de broadcast atualizadas em um canal de transmissão de overhead (3012); dispositivos para acessar a seção de broadcast em um canal de transmissão de broadcast (3010); e dispositivos para utilizar as informações de overhead de broadcast para processar conteúdo de broadcast da seção de broadcast.

12. Equipamento, de acordo com a reivindicação 11, caracterizado pelo fato de que: um serviço de broadcast (204) é transmitido por um servidor de conteúdo (3002); o serviço de broadcast (204) possui uma pilha de protocolos correspondente possuindo uma camada de aplicação e uma camada de transporte; e o servidor de conteúdo (3002) controla independentemente os protocolos da camada de aplicação e da camada de transporte.

13. Equipamento, de acordo com a reivindicação 12, caracterizado pelo fato de que o serviço de broadcast é transmitido como pacotes de dados de Protocolo Internet.

14. Equipamento, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende adicionalmente: dispositivos para utilizar as informações de compressão de cabeçalho atualizadas para receber o conteúdo de broadcast.