BRPI0721638A2

BRPI0721638A2 - aparelho e mÉtodo para realizar gerenciamento de energia em um receptor

Info

Publication number: BRPI0721638A2
Application number: BRPI0721638-6A
Authority: BR
Inventors: Avinash Sridhar; David Anthony Campana; Jill Macdonald Boyce
Original assignee: Thomson Licensing
Priority date: 2007-06-01
Filing date: 2007-06-01
Publication date: 2013-02-13
Also published as: JP5148697B2; KR101397565B1; CN101682435B; KR20100017462A; US20100130122A1; EP2171891A1; WO2008147367A1; CN101682435A; JP2010529734A

Abstract

APARELHO E MÉTODO PARA REALIZAR GERENCIAMENTO DE ENERGIA EM UM RECEPTOR. Um sistema de Radiodifusão Vídeo Digital - Portátil (DVB-H) dispõe de um terminal de distribuição e pelo menos um receptor. O terminal de distribuição utiliza o protocolo de Transferência de Arquivo via Transporte Unidirecional (FLUTE) para a transmissão de um guia de serviços eletrônicos (ESG) e conteúdo para o receptor. o receptor determina o tempo de atraso para receber conteúdo em função de um valor de um parâmetro Horalnício Publicada do ESG e o tempo real em que o receptor recebe o conteúdo. Usando este tempo de atraso, o receptor faz uma estimativa de tempo para receber o conteúdo selecionado em função de um valor de um parâmetro Horalnício Publicada do ESG para o conteúdo seleciondo e do tempo de atraso determinado. O receptor realiza então gerenciamento de energia, de forma que, durante os intervalos de tempo em que o receptor não tenha expectativa de receber o conteúdo selecionado, o receptor possa reduzir energia.

Description

"APARELHO E MÉTODO PARA REALIZAR GERENCIAMENTO DE ENERGIA EM UM RECEPTOR"

Fundamento da Invenção

A presente invenção geralmente refere-se a sistemas de comunicação e, mais par- ticularmente, a gerenciamento de energia em um dispositivo de comunicação, tal como, mas não limitado a, um dispositivo móvel, um dispositivo movido a bateria etc.

Hoje, os dispositivos móveis estão em toda parte - desde leitores de MP3 e assis- tentes pessoais digitais a telefones celulares e televisores móveis (TVs). Infelizmente, um dispositivo móvel normalmente tem limitações de recursos computacionais e / ou potência. Neste sentido, um sistema de Protocolo Internet (IP) Datacast via Radiodifusão Vídeo Digital - Portátil (DVB-H) é um sistema de radiodifuão extremo a extremo para a transferência de qualquer tipo de arquivo e serviços utilizando mecanismos baseados em IP que é otimizado para tais dispositivos. Por exemplo, ver ETSI EN 302 304 VI. 1.1 (2004-11) "Digital Video Broadcasting (DVB); Sistema de Transmissão para Terminais Portáteis (DVB-H)", ETSI EN 300 468 Vl .7.1 (2006-05) "Digital Video Broadcasting (DVB); Especificação de Serviço de Informação (SI) em sistemas DVB"; ETSI TS 102 472 Vl .1.1 (2006-06) "Digital Video Broad- casting (DVB); IP Datacast via DVB-H: Protocolos de Transmissão de Conteúdo"; e ETSI TS 102 471 Vl .1.1 (2006-04) "Digital Video Broadcasting (DVB); IP Datacast via DVB-H: Guia de Serviço Eletrônico (ESG)". Um exemplo de IP Datacast via DVB-H, como conhecido na técnica, é mostrado na FIG. 1. Na FIG. 1, um terminal de distribuição 10 (também referido como um "emissor") transmite, via antena 35, um sinal DVB-H 36 para um, ou mais, disposi- tivos de recepção (também referido como "clientes" ou "receptores"), como representado pelo receptor 90. O sinal DVB-H 36 transfere o IP Datacast para os clientes. O receptor 90 recebe o sinal DVB-H 36, através de uma antena (não mostrada), para daí recuperar o IP Datacasts. O sistema da FIG. 1 é representativo de uma rede unidirecional.

Os acima descritos IP Datacasts são usados para fornecer serviços baseados em conteúdo através de distribuição de arquivos, tal como um guia de serviços eletrônicos (ESG) e arquivos de conteúdo. No contexto da FIG. 1, um serviço baseado em conteúdo pode ser de conteúdo em tempo real, por exemplo, um programa de televisão (TV), ou de conteúdo baseado em arquivo, por exemplo, conteúdo simplificado, que é menor do que um programa de televisão típico. O ESG fornece ao usuário a capacidade de selecionar os ser- viços baseados em conteúdo e ativar o receptor para recuperar o conteúdo selecionado. A este respeito, um ESG geralmente inclui dados descritivos, ou metadados, sobre o conteúdo (também referido como um evento), tais como o nome do programa de TV, uma sinopse, atores, diretor etc., bem como agenda de data, hora, duração e canal de transmissão. Um usuário associado ao receptor 90 pode receber o conteúdo que é referido pelo ESG sintoni- zando o receptor ao canal adequado identificado pelo ESG. Deve-se notar que, no caso de conteúdo em tempo real, por exemplo, um programa de televisão, o ESG inclui um arquivo de Protocolo de Descrição de Sessão (SDP) (por exemplo, ver M. Handley, V. Jacobson, "Abril de 1998 - "RFC 2327 - SDP: Session Description Protocol). O arquivo de SDP inclui informações adicionais que permitem que receptor 90 para sintonize o conteúdo de trans- missão selecionado.

Com relação ao conteúdo baseado em arquivo, o terminal de distribuição 10 da FIG. 1 distribui arquivos usando o protocolo de Transferência de Arquivo via Transporte Uni- direcional (FLUTE) (por exemplo, ver T. Paila, M. Luby, V. Roca, R. Walsh, "RFC 3926 - FLUTE - File Delivery sobre Unidirectional Transport", Outubro de 2004). O protocolo de FLUTE é usado para transferir arquivos, ou dados, através de redes unidirecionais e prevê a transmissão de arquivos multicast. Neste exemplo, pressupõe-se também o terminal de transmissão 10 utiliza o protocolo de Codificação com Disposição Assíncrona (ALC) (por exemplo, ver Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. e J. Crowcroft , "Asynchronous Layered Coding (ALC) Protocol lnstantiation", RFC 3450, Dezembro de 2002) como o trans- porte básico para FLUTE. O protocolo de ALC é projetado para a transmissão de objetos binários arbitrários. É especialmente indicado para distribuição multicast massivamente es- calável, unidirecional.

Passando brevemente à FIG. 2, a transmissão de conteúdo baseado em arquivo usando FLUTE é ilustrada no contexto do terminal de distribuição 10 transmitindo um ESG. A transmissão de outro conteúdo baseado em arquivo é semelhante e não aqui descrito. O terminal de distribuição 10 compreende um gerador de ESG 15, emissor de FLUTE 20, en- capsulador de IP 25 e modulador de DVB-H 30. O gerador de ESG 15 fornece um ESG ao emissor de FLUTE 20, que formata o ESG, de acordo com o FLUTE via ALC e fornece os pacotes de ALC resultantes transferindo os arquivos FLUTE para encapsulador de IP 25 para encapsulamento em pacotes de IP, como é conhecido na técnica. Os pacotes de IP resultantes são fornecidos ao modulador de DVB-H 30 para a transmissão de um, ou mais, dispositivos de recepção, conforme ilustrado na FIG. 1. Um receptor sintoniza um canal FLUTE particular (por exemplo, o endereço IP e o número da porta) para recuperar o ESG para uso no receptor.

Como mencionado acima, um receptor pode ter limitações de energia, por exemplo,

a vida da bateria. Além disso, um receptor em uma rede de transmissão só pode estar rece- bendo conteúdo baseado em arquivo particular ou selecionado em horários específicos. Em outras vezes, o receptor - enquanto está totalmente ligado - não está processando qualquer outro conteúdo transmitido pela rede de transmissão. Desta forma, seria vantajoso se o e- missor FLUTE (por exemplo, o emissor FLUTE 20 do terminal de distribuição 10 da FIG. 2) e o receptor FLUTE (por exemplo, a parte do receptor FLUTE (não mostrado), do receptor 90 da FIG. 1) fossem sincronizados no tempo, de modo que o receptor pudesse reduzir a ener- gia durante os intervalos de tempo em que a informação selecionada não estiver sendo re- cebida, de forma a aumentar a vida útil da bateria do receptor. Uma abordagem para realizar a sincronização de tempo é mostrada na FIG. 3. Em particular, na FIG. 3, a sincronização de tempo é realizada entre o terminal de distribuição 10 e o receptor 90 através de um servidor Protocolo Tempo de Rede (NTP) 45. Neste caso, o emissor FLUTE 20 (do terminal de distri- buição 10) provê uma Tabela de Hora e Data (TDT) (por exemplo, ver o supra-referenciado ETSI EN 300 468 Vl .7.1) que inclui um timestamp NTP do servidor NTP 45. O terminal de distribuição 10 transmite a TDT em sinal DVB-H 36. O receptor 90 então usa apenas times- tamp NTP recebido para procurar conteúdo selecionado em horários específicos. Alternati- vãmente, o terminal de distribuição 10 pode fornecer o timestamp NTP para o receptor de 90 em Relatórios Emissores de Protocolo de Controle Transporte em Tempo Real (RTCP) que estão incluídos em uma transmissão ao vivo. (Por exemplo, ver Audio-Video Transport Wor- king Group, H. Schulzrinne , GMD Fokus S. Casner, Preceito Software, Inc., R. Frederick, Xerox Palo Alto Research Center, V. Jacobson., Janeiro de 1996 - "RFC 1889 RTP: A Transport Protocol for Real-Time Applications).

Sumário da Invenção

Observou-se que a execução da sincronização de tempo usando um timestamp NTP, conforme descrito acima, nem sempre é adequada para realizar o gerenciamento de energia em um receptor. Em particular, a abordagem acima descrita não leva em conta os tempos de atraso adicionais. Em outras palavras, o uso de um timestamp NTP não fornece ao receptor a hora real em que as informações selecionadas serão recebidas no receptor. Este problema de sincronização pode ser agravado se o receptor estiver recebendo o times- tamp NTP de um relatório emissor RTCP, uma vez que o relatório emissor RTCP não fica disponível caso o receptor não esteja sintonizado para um serviço de transmissão ao vivo. No entanto, percebeu-se que é possível um receptor determinar uma estimativa de

quaisquer tempos de atraso entre o emissor e o receptor que levam em conta parâmetros como distância, interferência etc. para aquele receptor. Em particular, e de acordo com os princípios da invenção, um receptor determina um tempo de atraso em função de um tempo de transmissão e um tempo de recepção quando da recepção de um evento, e determina uma estimativa de tempo para receber um evento selecionado em função do tempo de atra- so.

Em uma modalidade ilustrativa da invenção, um sistema de Radiodifusão Vídeo Di- gital - Portátil (DVB-H) dispõe de um terminal de distribuição e pelo menos um receptor. O terminal de distribuição utiliza o protocolo de Transferência de Arquivo via Transporte Unidi- recional (FLUTE) para a transmissão de um guia de serviços eletrônicos (ESG) e conteúdo para o receptor. O receptor determina o tempo de atraso para receber conteúdo em função de um valor de um parâmetro HoralnicioPubIicada do ESG e do tempo real em que o recep- tor recebe o conteúdo. Usando este tempo de atraso, o receptor faz uma estimativa de tem- po para recepção do conteúdo selecionado em função de um valor de um parâmetro Horal- nícioPublicada do ESG para o conteúdo selecionado e do tempo de atraso determinado.

Em outra modalidade do conceito da invenção, o receptor então executa gerencia- mento de energia, tal que, durante os intervalos de tempo em que o receptor não tenha ex- pectativa de receber o conteúdo selecionado, o receptor possa reduzir o energia.

Face ao exposto, e como será aparente a partir da leitura da descrição detalhada, outras modalidades e características também são possíveis e estão dentro dos princípios da invenção.

Breve Descrição dos Desenhos

As FIGs. 1-3 mostram um sistema de Protocolo Internet (IP) Datacast via Radiodi- fusão Vídeo Digital - Portátil (DVB-H) da técnica anterior;

A FIG. 4 mostra transmissão de conteúdo baseado em arquivo e um fragmento as- sociado de um ESD para o sistema das FIGs. 1-3;

A FIG. 5 ilustra tempos de atraso de acordo com os princípios da invenção;

A FIG. 6 mostra uma modalidade ilustrativa de um sistema de acordo com os prin- cípios da invenção;

As FIGs. 7 e 8 mostram fluxogramas ilustrativos para utilização em um receptor de acordo com os princípios da invenção;

A FIG. 9 ilustra a utilização de um fragmento de ESG e um FDT de acordo com os

princípios da invenção;

A FIG. 10 mostra outro fluxograma ilustrativo de acordo com os princípios da inven- ção;

A FIG. 11 mostra uma tabela ilustrativa de hora de início real para conteúdo sele-

cionado de acordo com os princípios da invenção;

A FIG. 12 mostra um exemplo de gerenciamento de energia de acordo com os prin- cípios da invenção;

A FIG. 13 mostra outro fluxograma ilustrativo de acordo com os princípios da inven- ção; e

As FIGs. 14 e 15 mostram modalidades ilustrativas de um receptor de acordo com

os princípios da invenção.

Descrição Detalhada

Diferentemente do conceito da invenção, os elementos mostrados nas figuras são bem conhecidos e não serão descritos em detalhe. Por exemplo, diferente do conceito da

invenção, a familiaridade com de Transmissão de Multitom Discreto (DMT) (também conhe- cido como Multiplexação por Divisão Ortogonal de Freqüência (OFDM) ou Multiplexação por Divisão Ortogonal de Freqüência Codificada (COFDM)) é assumida e não aqui descrita. A- 10

15

lém disso, a familiaridade com transmissão de televisão, receptores e codificação de vídeo é assumida e não é descrita em detalhes aqui. Por exemplo, diferente do conceito da inven- ção, a familiaridade com as recomendações atuais e propostas para padrões de TV como NTSC (Comitê de Sistemas de Televisão Nacional), PAL (Linhas de Alternância de Fase), SECAM (Cor Seqüencial com Memória) e ATSC (Comitê de Sistemas de Televisão Avança- do) (ATSC)1 o Sistema de Televisão Digital Chinês (GB) 20600-2006 e DVB-H é assumida. Da mesma forma, diferente do conceito da invenção, outros conceitos de transmissão, tais como banda lateral residual de nível 8 (8 -VSB), Modulação de Amplitude em Quadratura (QAM), e componentes receptores, tais como uma unidade inicial de rádio-frequência (RF) (como um bloco de baixo ruído, sintonizadores, conversor descendente etc.), desmodulado- res, correladores, integrador de fuga e squarers são assumidos. Adicionalmente, além do conceito da invenção, a familiaridade com protocolos como Transferência de Arquivo via Transporte Unidirecional (FLUTE), protocolo de Codificação com Disposição Assíncrona (ALC), protocolo de Internet (IP) e Encapsulador de Protocolo de Internet (IPE), é assumida e não descrita aqui. Da mesma forma, diferente do conceito da invenção, métodos de forma- tação e codificação (tais como Padrão de Sistema de Moving Picture Expert Group (MPEG)- 2 (ISO / IEC 13818-1)) para gerar correntes de bits de transporte são bem conhecidos e não aqui descritos. Deve-se também notar que o conceito da invenção pode ser implementado usando técnicas de programação convencionais, que, como tal, não serão aqui descritas. Finalmente, números iguais nas figuras representam elementos semelhantes.

Conforme descrito anteriormente, observou-se que executar a sincronização de tempo usando um timestamp NTP, conforme descrito acima, nem sempre é adequado para realizar o gerenciamento de energia em um receptor. Em particular, a abordagem de times- tamp NTP acima descrita não leva em conta os tempos de atraso adicionais. Isto é adicio- nalmente ilustrado nas FIGs. 4 e 5, no contexto de transmissão de conteúdo baseado em arquivo em DVB-H. Na FIG. 4, a transmissão de conteúdo baseado em arquivo em DVB-H compreende vários eventos (também referidos como clipes), como representados pelos cli- pes 50, 51, 52 e 53. Cada clipe pode incluir vários pacotes, mas isso não é relevante para o conceito da invenção. Os ESG associa cada clipe com uma hora de início, uma hora final e identifica o arquivo de conteúdo associado na sessão FLUTE correspondente. Isto é ilustra- do na FIG. 4 para um fragmento de um fragmento 60 de um ESG (fragmento de ESG 60) associado ao clipe 51. Por simplicidade, outros dados de ESG não são mostrados. Confor- me mostrado na FIG. 4, o fragmento de ESG 60 inclui um parâmetro LocalizaçãoConteúdo 65, um parâmetro HoralnicioPubIicada 61, bem como um parâmetro HoraFinaIPubIicada 62 associados ao clipe 51. Neste exemplo, o arquivo de conteúdo associado na sessão FLUTE correspondente é "Clipe.mp4". Os valores reais para HoralnicioPubIicada e HoraFinaIPubIi- cada, 63 e 64, respectivamente, estão em unidades de Tempo Universal Coordenado

30 10

15

20

25

30

35

(UTC). O valor para HoralnicioPubIicada é a hora em que o emissor FLUTE vai realmente começar a transmitir os arquivos, ou seja, a hora em que o clipe sai do emissor FLUTE para o próximo bloco na cadeia do sistema. Isto é adicionalmente ilustrado na FIG. 5 para um sistema DVB-H1 ou seja, o valor para HoralnicioPubIicada é a hora em que o emissor FLUTE 20 envia o clipe para o encapsulador de IP 25. No entanto, convém notar que há um tempo de atraso adicional a partir de quando os pacotes de dados deixam o emissor FLUTE até que cheguem ao cliente através de qualquer rede intermediária, que inclui redes com ou sem fio, unidirecionais ou bidirecionais. Isto também é ilustrado na FIG. 5, no contexto do sistema DVB-H pelo tempo de atraso 61. Sem informações sobre este tempo de atraso, o receptor pode ser incapaz de estimar com precisão a hora de recepção de difusão de conte- údos e, portanto, não será capaz de prever corretamente o tempo correto para realizar o gerenciamento de energia. A abordagem de timestamp NTP descrita anteriormente para realizar a sincronização de tempo não leva em conta esse tempo de atraso. Assim, o uso de apenas o timestamp NTP não fornece ao receptor 90 a hora real em que o conteúdo atinge o receptor 90 em todas as situações. De fato, como mencionado acima, o problema de sin- cronização pode ser agravado se o receptor estiver recebendo o timestamp NTP de um rela- tório de emissor RTCP, uma vez que um relatório de emissor RTCP nem sempre está dis- ponível (por exemplo, se o receptor não for sintonizado para um serviço de transmissão ao vivo).

No entanto, percebeu-se que é possível um receptor determinar uma estimativa de quaisquer tempos de atraso entre o emissor e o receptor que levam em conta parâmetros como distância, interferência etc. para tal receptor. Em particular, e em conformidade com os princípios da invenção, um receptor determina um tempo de atraso em função de um tempo de transmissão e um tempo de recepção quando do recebimento de um evento; e determina uma estimativa de tempo para recepção de um evento selecionado em função do tempo de atraso. Conforme descrito aqui, um tempo de transmissão se refere, por exemplo, a uma hora de início, uma hora final etc.; e um tempo de recepção se refere, por exemplo, a uma hora de chegada, hora de conclusão etc.

Passando agora à FIG. 6, um sistema ilustrativo, em conformidade com os princí- pios da invenção, é mostrado. Para os fins deste exemplo, e outros que não o conceito da invenção, assume-se que o sistema mostrado na FIG. 6 é um sistema de Datacast IP via DVB-H, semelhante ao descrito na FIG. 1. Neste contexto, um terminal de distribuição 10 transmite, através de antena de 35, um sinal DVB-H 36 de radiodifusão de Datacasts IP pa- ra um, ou mais, dispositivos de recepção (também referidos como "clientes" ou "recepto- res"), representados por qualquer um de computador portátil 20-1, assistente digital pessoal (PDA) 20-2 e 20-3 e telefone celular, cada um dos quais se presume ser configurado para receber um sinal DVB-H para daí recuperar o Datacasts IP de difusão para conteúdo em tempo real e conteúdo baseado em arquivo. O sistema da FIG. 6 é representativo de uma rede unidirecional. No entanto, o conceito da invenção não é tão limitado. Como descrito abaixo, cada cliente determina uma estimativa de tempo para a recepção de informações selecionadas; e realiza o gerenciamento de energia em função da estimativa de tempo de- terminado.

Referindo-se agora à FIG. 7, um fluxograma ilustrativo para o uso em um dispositi- vo de recepção (por exemplo, 20-1, 20-2 e 20-3), em conformidade com os princípios da invenção, é mostrado. Para simplificar, o conceito da invenção é descrito no contexto de transmissão de conteúdo baseado em arquivo, mas o conceito da invenção não é tão limita- do. Na etapa 205, o dispositivo de recepção recebe um ESG. O ESG inclui uma lista de e- ventos de conteúdo baseado em arquivo (clipes). Na etapa 210, o receptor determina se algum dos clipes listados no ESG recebido foi selecionado para ser recebido. A seleção dos clipes pode ser realizada de várias maneiras. Por exemplo, o usuário pode visualizar o ESG em um display do receptor e selecionar manualmente clipes para recepção. Alternativamen- te, o receptor pode armazenar um perfil em uma memória (não mostrada), que represente os hábitos de visualização do usuário, no qual o receptor seleciona automaticamente os cli- pes atualmente listados no ESG, que são marcados com as mesmas palavras-chave que se encontram no perfil. O perfil pode ser criado pelo usuário e / ou criado pelo receptor com base em clipes recebidos anteriormente. Após um ou mais clipes terem sido selecionados, o receptor calcula um tempo de atraso na etapa 215. Em seguida, na etapa 220, o receptor realiza gerenciamento de energia em função da estimativa determinada do tempo de atraso. Deve -se notar, para simplificação, que as condições de erro não são mostradas nos fluxo- gramas descritos neste documento. Por exemplo, se nenhum clipe for selecionado na etapa 210 durante um determinado período de tempo, o receptor pode cortar energia devido à falta de atividade.

Um fluxograma ilustrativo para estimativa do tempo de atraso na etapa de 215 da FIG. 7 é mostrado na FIG. 8. Este exemplo para estimativa do tempo de atraso faz uso de propriedades do FLUTE e de protocolos ALC. Contudo, o conceito da invenção não é tão limitado e outros métodos de estimativa de um tempo de atraso podem ser usados. Os Da- tacasts IP baseados em FLUTE incluem uma Tabela de Descrição de Arquivo (FDT) para descrever os atributos dos arquivos a serem transmitidos. Neste exemplo, supõe-se que o destinatário recebe uma FDT, na etapa 305, antes da transmissão do conteúdo baseado em arquivo associado. De particular observação são os campos da FDT a seguir: "Localização de Conteúdo", que transfere o nome do arquivo e "Identificador de Objeto de Transporte (TOI)", que transfere um número exclusivo que está associado com o arquivo para o âmbito da sessão FLUTE . Na etapa 310, o receptor analisa a FDT recebida por valores de TOI para o conteúdo selecionado do ESG. Em particular, para cada conteúdo selecionado, o 15

receptor identifica o nome do arquivo a partir do parâmetro LocalizaçãoConteúdo corres- pondente do fragmento de ESG para o conteúdo selecionado (por exemplo, parâmetro Lo- calizaçãoConteúdo 65 da FIG. 4), e identifica o valor de TOI associado para o nome de ar- quivo correspondente na FDT recebida. Isto é ilustrado na FIG. 9. Na FIG. 9, um fragmento de ESG 70 é associado com o conteúdo selecionado, onde o nome do conteúdo seleciona- do "Clipe2.mp4" é mostrado como o valor para o parâmetro LocalizaçãoConteúdo 72 do fragmento de ESG 70. Uma parte 75 de uma FDT recebida também é mostrada. Como pode ser observado na FIG. 9, o receptor localiza o arquivo correspondente na FDT recebida pela análise de valores de parâmetro Localização-Conteúdo 76 da FDT para localizar o arquivo selecionado e, em seguida, determina o valor de TOI associado ao parâmetro de TOI 77 da FDT. Neste exemplo, o receptor poderia determinar que o arquivo selecionado "Clipe2.mp4" tem um valor de TOI de NN2, que é um valor inteiro.

Voltando à FIG. 8, após de analisar a FDT, o receptor espera receber um pacote de ALC transferindo qualquer conteúdo baseado em arquivo selecionado. Cada pacote de ALC consiste em pacotes de arquivos e seus a TOI associados. Ilustrativamente, o receptor utili- za os valores de TOI para o conteúdo selecionado da etapa 310 para detectar o início da efetiva recepção do conteúdo baseado em arquivo correspondente. Isso é mostrado nas etapas 315 e 320 da FIG. 8. Em especial, ao receber um pacote de ALC na etapa 315, o receptor verifica, na etapa 320, se o valor de TOI do pacote de ALC recebido corresponde a 3 um valor de TOI para o conteúdo selecionado. Se o valor de TOI do pacote de ALC recebido não corresponde ao conteúdo selecionado, então, o receptor novamente executa as etapas 315 e 320 para o próximo pacote de ALC recebido. No entanto, uma vez que o receptor de- tecta um valor de TOI no pacote de ALC recebido correspondente a um valor de TOI para o conteúdo selecionado (por exemplo, NN2 associado Mclipe2.mp4"), o receptor determina que a recepção efetiva de conteúdo selecionado foi iniciada e realiza a etapa 325 para determi- nar um tempo de atraso para o conteúdo selecionado.

Referindo-se agora à FIG. 10, um fluxograma ilustrativo para a determinação do tempo de atraso na etapa 325 é mostrado. Na etapa 350, o receptor determina a hora atual, por exemplo, de um relógio local do receptor. Este valor de tempo atual é aqui referido como a receptorJimestamp (ou tempo de recepção). O valor para o receptorjimestamp represen- ta a hora de início real de recepção do conteúdo selecionado. Na etapa 355, o receptor de- termina o tempo de atraso de:

Td = receptorjimestamp - HoralnícioPublicada; (1) onde o parâmetro TD represen- ta o tempo de atraso estimado, e o valor para HoralnícioPublicada é retirada do fragmento de ESG correspondente para o conteúdo recebido selecionado (por exemplo, parâmetro 71 do fragmento de ESG 70 para "clipe2. mp4"). Uma vez que o receptor estima o tempo na etapa 355, o receptor já pode estimar a hora de início real para a entrega de todos os conte- 10

15

20

25

30

35

údos selecionados. Em particular, na etapa 360, para cada conteúdo selecionado, o receptor determina:

HoraJnício_Real = HoralnicioPubIicada + TD; (2) onde o valor para HoraInicioPu- blicada é retirado do fragmento de ESG associado para cada conteúdo selecionado. Como i resultado, o receptor constrói uma tabela de tempo de início real, como ilustrado no FIG. 11 para todos os conteúdos selecionados, indicando os horários de início real. Neste exemplo, supõe-se que um ESG recebido indica cinco clipes que estão disponíveis: clipel, clipe2, clipe3, clipe4 e clipeõ, e que o clipe2, clipe4 e clipeõ foram selecionados para serem recebi- dos pelo receptor (por exemplo, a etapa 210 da FIG. 7). Para cada clipe selecionado, os valores associados para HoralnicioPubIicada são extraídos dos fragmentos de ESG corres- pondentes, por exemplo, tempos T2, T4 e T5, para clipe2, clipe4 e clipeõ, respectivamente. Da mesma forma, os valores de TOI correspondentes são extraídos da FDT (por exemplo, etapa 310 da FIG. 8), por exemplo, NN2, NN4 e NN5. Finalmente, os horários de início real para recebimento dos conteúdos selecionados são computados a partir da equação (2). Vol- tando à FIG. 8, o receptor continua a receber pacotes de ALC para o conteúdo selecionado atualmente a ser recebido nas etapas de 330 e 335 até o fim do arquivo (EOF) ser detecta- do na etapa 330. Quando da detecção de um EOF, o receptor processa o conteúdo recebido na etapa 340. Deve-se notar que o clipe2 está incluído na tabela da FIG. 1.1 para a integra- lidade. Conforme descrito no parágrafo seguinte, para este exemplo, o clipe2 é usado para determinar o tempo de atraso, Tp-. Como tal, este não é necessário para determinar a hora de início real do clipeZ No entanto, e em conformidade com os princípios da invenção, outro

conteúdo, mesmo que conteúdo não-selecionado, tal como clipel, pode ser usado para de- terminar o tempo de atraso T0 -.

Como resultado do processo acima descrito, um valor de hora de início real é de- terminado para cada conteúdo selecionado, o qual leva em conta os atrasos de rede entre o emissor e o receptor. Voltando à FIG. 7, o receptor realiza o gerenciamento de energia na etapa 220, em função da estimativa de tempo determinado. Portanto, e em conformidade com os princípios da invenção, todos os canais FLUTE associados com o conteúdo selecio- nado podem agora ser ligados apenas quando necessário para receber o conteúdo selecio- nado. Isto é ilustrado na FIG. 12 para os clipes selecionados na tabela da FIG. 1.1. Por e- xemplo, no intervalo de tempo 81, o receptor é "ligado" para receber a FDT 80 e determinar o tempo de atraso, To-. Em especial, em tempo >7, o receptor recebe e analisa uma FDT recebida 80 (etapas 305 e 310 da FIG. 8). O receptor então processa pacotes de ALC rece- bidos à procura de conteúdos selecionados para determinar um tempo de atraso. O primeiro clipe, cHP1, é ignorado pelo receptor, uma vez que o clipel não é um conteúdo selecionado conforme indicado pelo valor de TOI recebido do clipel. No entanto, após a detecção, no início do clipe2, que o clipe2 é conteúdo selecionado pelo valor de TOI recebido de clip2 o 10

15

3

receptor calcula um valor de Tp1 determina os horários de início real de todos os conteúdos selecionados, como descrito acima, e processa os pacotes de ALC recebidos para clipe2. Como resultado, depois de receber o clipe2, aquela parte do receptor associado com o pro- cessamento dos canais de FLUTE para conteúdo baseado em arquivo agora pode ser "des- ligado" ou "deixado em repouso", no intervalo de tempo 82 até que seja hora de começar a receber o próximo conteúdo selecionado, o clipe4 etc. Assim, e como pode ser observado na FIG. 12, partes do receptor podem ficar em repouso até a hora de realmente receber o conteúdo selecionado. Isso isenta o receptor de desperdiçar energia por ter que manter to- dos os canais de FLUTE abertos todo o tempo.

Um fluxograma ilustrativo para realizar o gerenciamento de energia na etapa 220 da FIG. 7, em conformidade com os princípios da invenção, é mostrado na FIG. 13. Depois de ter determinado as horas de início reais de conteúdos selecionados - e, no processo, ter recebido o primeiro conteúdo selecionado - o receptor fica em repouso até a hora de início real do conteúdo selecionado seguinte na etapa 405. Quando for a hora de receber o conte- údo selecionado, o receptor ativa e recebe um pacote de ALC na etapa 410. Na etapa 415, o receptor verifica o valor de TOI para determinar se este é o conteúdo selecionado. Se este não for o conteúdo selecionado, o receptor volta para a etapa 405 e fica em repouso até a hora de início real do próximo conteúdo selecionado. No entanto, se este for o conteúdo selecionado, o receptor continua a receber os pacote de ALC procurando um EOF, como mostrado nas etapas 420 e 425. Após a detecção de um EOF, o receptor processa o conte- údo recebido na etapa 430. O receptor, então, retorna para a etapa 405 e fica em repouso até a hora de início real do próximo conteúdo selecionado.

Como mencionado acima, uma forma do receptor reduzir energia é o de ligar e des- ligar a recepção de canais FLUTE. Neste caso, o receptor dessintoniza todos os pacotes de IP associados com o canal FLUTE e, então, elimina qualquer processamento extra para o conteúdo não-selecionado. No entanto, o receptor pode reduzir o consumo de energia de outras formas, de acordo com os princípios da invenção. Por exemplo, o receptor de rádio DVB-H em si pode ser alternado entre ligado e desligado. Isto isentaria o receptor da utiliza- ção de energia para executar o receptor de rádio durante aqueles momentos em que o con- teúdo não selecionado estivesse sendo recebido.

Referindo-se agora à FIG. 14, uma modalidade ilustrativa de um receptor 100, em conformidade com os princípios da invenção, é mostrada. Apenas aquela parte do receptor 100 pertinentes ao conceito da invenção é mostrada. O receptor 100 é representativo de uma plataforma baseada em processador, por exemplo, um PC, um assistente pessoal digi- tal (PDA), um telefone celular, uma televisão móvel digital (DTV) etc. Neste sentido, o recep- tor 100 inclui um ou mais processadores e memória associada, como representado pelo processador 190 e memória 195, mostrados na forma de caixas tracejadas na FIG. 14. Nes- te contexto, programas de computador, ou software, como representado pelos fluxogramas anteriormente descritos das FIGs. 7, 8, 10 e 13, são armazenados na memória de 195 para execução pelo processador 190. O último é representativo de um ou mais processadores de controle de programa armazenado e estes não têm que ser dedicados à função de receptor, por exemplo, o processador de 190 pode também controlar outras funções do receptor 100. A memória 195 é representativa de qualquer dispositivo de armazenamento, por exemplo, memória de acesso aleatório (RAM), memória somente leitura (ROM) etc.; pode ser interna e / ou externa ao receptor 15; e é volátil e / ou não-volátil conforme necessário. O receptor 100 dispõe de receptor DVB-H 110, desencapsulator de IP 115 e receptor FLUTE 120. Qualquer um ou todos estes componentes podem ser implementados em software, como representado pelo processador 190 e memória 195. O receptor DVB-H 110 recebe sinal DVB-H 36 (da FIG. 6) através de antena 105 e fornece um sinal desmodulado para o desen- capsulator de IP 115. Esta última oferece pacotes de ALC para o receptor FLUTE 120, que recupera o conteúdo, como representado pelo sinal 121. Este conteúdo pode ser processa- do pelo receptor 100, como conhecido na técnica (como representado pelas elipses 130). Como descrito acima, e em conformidade com os princípios da invenção, o processador 190 estima um tempo de atraso e realiza o gerenciamento de energia. Neste exemplo, o receptor FLUTE 120 e o receptor DVB-H 110 são ligados, e desligados, pelo processador 190, repre- sentado pelos sinais de controle 109 e 119, de tal forma que, pelo menos por algum tempo, 3 o receptor de conteúdo não-selecionado 100 opera em potência reduzida.

Outra modalidade ilustrativa de um receptor 500, em conformidade com os princí- pios da invenção, é mostrada na FIG. 15. Somente aquela parte do receptor 500 pertinente ao conceito da invenção é mostrada. O receptor 500 inclui receptor DVB-H 510, desmodula- dor / decodificador 515, processador de transporte 520, controlador 550 e memória 560. j Deve-se notar que outros componentes de um receptor, tais como um conversor analógico- para-digital, filtro de unidade inicial etc., não são mostrados para simplificação. Ambos o processador de transporte 520 e o controlador 550 são, cada um, representativos de um ou mais microprocessadores e / ou processadores de sinal digital (DSPs) e podem incluir me- mória para executar programas e armazenar dados. Neste sentido, a memória 560 é repre- sentativa de memória no receptor 500 e inclui, por exemplo, qualquer memória do processa- dor de transporte 520 e / ou controlador 550. Um barramento de dados e controle bidirecio- nal 501 acopla vários dos elementos do receptor 500, conforme mostrado. O barramento 501 é meramente representativo, por exemplo, sinais individuais (em paralelo e / ou forma de série) podem ser utilizados etc., para a transmissão de dados e controle de sinalização entre os elementos do receptor 500. O receptor DVB-H 510 recebe um sinal DVB-H 509 e provê um sinal DVB-H convertido 511 para o desmodulador / decodificador 515. Este último realiza desmodulação e decodificação de sinal 511 e fornece um sinal decodificado 516 para o processador de transporte 520. O processador de transporte 520 é um processador de pacotes e implementa tanto um protocolo em tempo real e um protocolo FLUTE / ALC para recuperar tanto conteúdo em tempo real como conteúdo baseado em arquivo, de acordo com o DVB-H. O processador de transporte 520 fornece conteúdo, como representado pelo sinal de conteúdo 521 para circuitos subseqüentes apropriados (como representado pelas elipses 591). O controlador 550 controla o processador de transporte 520, via barramento 501, em conformidade com os fluxogramas acima descritos, para recuperar informações de ESG e FTD; e para determinar o receptorjimestamp acima descrito para uso na estimativa de um tempo de atraso, TD, e para a construção de uma tabela de hora de início real, con- forme ilustrado na FIG. 1.1 para o armazenamento na memória 560. O controlador 560 rea- liza o gerenciamento de energia do processador de transporte 520, receptor DVB-H 510 e desmodulador / decodificador 515, em conformidade com os princípios da invenção, através de sinais de controles 551, 552 e 553 (via barramento 501).

Como descrito acima, o conceito da invenção permite que um receptor estime tem- pos de atraso específicos de receptor que levam em conta parâmetros como distância, inter- ferência etc. para tal receptor. Além disso, e em conformidade com os princípios da inven- ção, a estimativa do tempo de atraso representada pela equação (1) pode ser ainda mais refinada. Por exemplo, toda vez que o receptor arranque para receber o conteúdo selecio- nado, o receptor pode atualizar o valor de Tp baseado no timestamp do conteúdo seleciona- D do atualmente recebido. Neste sentido, o tempo de atraso pode ser estimado por um perío- do de tempo em função de uma operação estatística sobre a diferença entre a hora de início publicada e a hora da recepção. As funções estatísticas podem incluir desvio padrão da mé- dia dos valores de tempo de atraso coletados, medindo os valores de tempo de atraso, cor- relações lineares e não-lineares dos valores de tempo de atraso. Os pontos de amostra de > tempo de atraso também fornecem a capacidade do receptor utilizar técnicas de modelagem para fazer a estimativa mais eficiente. Estas técnicas de modelagem podem incluir curvas de Gauss modificadas ou não-modificadas, curvas Laplacianas, e modelos de qui-quadrado. Além disso, uma vez que um fragmento de ESG também inclui um campo HoraFinaIPubIi- cada, o receptor também pode estimar o tempo de atraso pela gravação do tempo de con- clusão, ou seja, o momento em que o último pacote de ALC para o conteúdo recebido é re- cebido, como a hora final real, e comparar a hora final real com a HoraFinaIPubIicada no fragmento de ESG associado.

Deve-se notar que outras variações para determinar um tempo de atraso são tam- bém possíveis. Em especial, na descrição da FIG. 8, presumiu-se que o receptor recebe uma FDT antes da transmissão do conteúdo real. No entanto, deve-se notar que um sistema DVB-H não exige que uma FDT seja enviada antes da transmissão do conteúdo real. Por exemplo, uma FDT poderia ser enviada no final da transmissão de conteúdo ou de forma 10

15

assíncrona em um período de tempo completamente diferente. Em tais casos, o receptor receberá o conteúdo selecionado sem o conhecimento dos atributos do arquivo. No entanto, o receptor pode ainda determinar uma estimativa de tempo, de acordo com os princípios da invenção. Por exemplo, o receptor pode se referir ao ESG recebido para determinar o con- teúdo seguinte, agendado para a transmissão, e usar o primeiro pacote de ALC recebido deste conteúdo para estimar o tempo de atraso, conforme descrito acima, mesmo se este conteúdo não tiver sido selecionado.

Face ao exposto, e em conformidade com os princípios da invenção, um receptor realiza gerenciamento de energia, reduzindo energia durante esses tempos em que o con- teúdo selecionado não esteja sendo recebido. Deve-se notar que, embora o conceito da invenção tenha sido ilustrado no contexto de um sistema DVB-H unicast com dispositivos móveis, o conceito da invenção não é tão limitado e é aplicável a outros tipos de sistemas, receptores, ou dispositivos. Por exemplo, o conceito da invenção também se aplica aos sis- temas multicast. Da mesma forma, o conceito da invenção se aplica a qualquer receptor, ou dispositivo, para realizar gerenciamento de energia, com ou sem uma bateria. Como tal, o conceito da invenção aplica-se a um dispositivo mesmo não sendo móvel. Além disso, em- bora o conceito da invenção tenha sido descrito no contexto de um dispositivo com vários elementos, deve-se entender que o conceito da invenção também se aplica a um dispositivo no qual um ou mais dos seguintes elementos estão dispostos de forma distribuída, por e- D xemplo, através de uma rede, como uma rede de área local, rede bluetooth etc. Além disso, embora a gerenciamento de energia tenha sido descrito no contexto de ligar e desligar o receptor de canais de FLUTE e / ou rádio DVB-H, outras abordagens também podem ser utilizadas. Por exemplo, um ou mais circuitos integrados no receptor podem suportar módulo de economia de energia que pode ser habilitado em conformidade com os princípios da in- > venção. Ou, algumas ou todas as partes do receptor podem sofrer redução de energia ou ser desligadas, por exemplo, o circuito transceptor do receptor (ou seja, tanto o transmissor e o receptor). Além disso, o conceito da invenção pode ser usado com outras técnicas de economia de energia. Por exemplo, o gerenciamento de energia, em conformidade com os princípios da invenção, funciona em conjunto com o módulo de tempo de corte, desde que via DVB-H, que tem como objetivo reduzir o consumo de energia do receptor (por exemplo, ver o antes mencionado ETSI EN 302 304 V 1.1.1). Além disso, embora descrito no contexto de transmissão de conteúdo baseado em arquivo, no conceito da invenção também é apli- cável à transmissões de conteúdo em tempo real.

Face ao exposto, o que precede apenas ilustra os princípios da invenção e, portan- to, será apreciado que os que aqueles versados na técnica serão capazes de conceber vá- rias soluções alternativas que, embora não explicitamente aqui descritas, incorporam os princípios da invenção e estão dentro de seu espírito e escopo. Por exemplo, embora ilus- trada no contexto de elementos funcionais distintos, estes elementos funcionais podem ser incorporados em um, ou mais, circuitos integrados (ICs). Da mesma forma, embora apresen- tados como elementos distintos, alguns ou todos os elementos podem ser implementados em um processador controlado por programa armazenado, por exemplo, um processador de sinal digital, que executa software associado, por exemplo, correspondente a uma, ou mais, das etapas mostradas, por exemplo, nas FIGs 7-8, 10, 13, etc. Além disso, os princípios da invenção são aplicáveis a outros tipos de sistemas de comunicações, por exemplo, via saté- lite, Wireless-Fidelity (Wi-Fi)1 celulares etc. Na realidade, o conceito da invenção é também aplicável aos receptores fixos ou móveis. É, portanto, para ser entendido que numerosas modificações podem ser feitas às modalidades ilustrativas e outras disposições podem ser concebidas sem se afastar do espírito e escopo da presente invenção, tal como definido pelas reivindicações anexas.

Claims

1. Método para utilização em um receptor, o método sendo CARACTERIZADO pelo fato de que compreende: determinar um tempo de atraso em função de um tempo de trans- missão e um tempo de recepção quando recebendo um evento; e determinar um tempo es- timado para recebimento de um evento selecionado em função do tempo de atraso.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora de início para o evento.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora final para o evento.

4. Método, de acordo com a reivindicação 1, adicionalmente compreendendo a eta- pa de: realizar gerenciamento de energia em função da estimativa de tempo determinada.

5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que a etapa de realização de gerenciamento de energia inclui a etapa de: reduzir energia a um tempo diferente do tempo estimado de recepção do evento selecionado.

6. Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que a etapa de redução de energia inclui a etapa de controlar pelo menos um de um receptor de rádio e um processador de pacote durante o pelo menos um intervalo de tempo, tal que pelo menos um do receptor de rádio e processador de pacote opere em energia reduzida.

7. Método, de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que o processador de pacote suporta sessões de Transmissão de Arquivo via Transporte Unidire- cional (FLUTE) e a etapa de controle inclui as etapas de: desligar os canais de FLUTE as- sociados aos eventos não-selecionados quando o processador de pacote operar em energia reduzida.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o evento selecionado é representativo de um conteúdo baseado em arquivo compreendendo pelo menos um clipe.

9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o evento selecionado é representativo de um conteúdo em tempo real compreendendo pelo menos um programa.

10. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o evento é também um evento selecionado.

11. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a determinação de um tempo de transmissão inclui as etapas de: identificar a partir de um guia de programa uma hora de início do evento como o tempo de transmissão.

12. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que a hora de início é uma hora de início publicada.

13. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a determinação de um tempo de recepção inclui as etapas de: detectar que a informação recebida corresponde ao evento; e registrar um tempo de chegada da informação recebida como o tempo de recepção.

14. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que a etapa de detecção inclui a etapa de: receber uma Tabela de Descrição de Arquivo (FDT) tendo um valor Identificador de Objeto de Transporte (TOI) que seja associado ao evento; e detectar o valor TOI na informação recebida para determinar que a informação recebida cor- responde ao evento.

15. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora de início e a etapa de determinar um tempo de atraso determina o tempo de atraso pela subtração da hora de início do tempo de recepção.

16. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora de início e a etapa de determinar o tempo de atraso determina o tempo de atraso a partir de uma função estatística operando sobre a diferença entre a hora de início e o tempo de recepção sobre um período de tempo para uma plurali- dade de eventos.

17. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a etapa de determinação do tempo estimado inclui a etapa de: determinar um tempo de transmissão para o evento selecionado; e adicionar o tempo de transmissão para o evento selecionado ao tempo de atraso a fim de determinar o tempo estimado para recepção do evento selecionado.

18. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a determinação de um tempo de transmissão inclui a etapa de: identificar a partir de um guia de programa uma hora final do evento como o tempo de transmissão.

19. Método, de acordo com a reivindicação 18, CARACTERIZADO pelo fato de que a hora final é uma hora final publicada.

20. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a etapa de determinação de um tempo de recepção inclui as etapas de: detectar que a in- formação recebida corresponde ao evento; e registrar uma hora final real ao final da recep- ção do evento.

21. Método, de acordo com a reivindicação 20, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora final e a etapa de determinação do tempo de atraso determina o tempo de atraso pela subtração da hora final da hora final real.

22. Método, de acordo com a reivindicação 20, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora final e a etapa de determinar o tempo de atraso deter- mina o tempo de atraso a partir de uma função estatística operando sobre a diferença entre a hora final e a hora final real sobre um período de tempo para uma pluralidade de eventos.

23. Aparelho, CARACTERIZADO pelo fato de que compreende: um desmodulador para fornecer um sinal recebido representando uma informação transferida em uma seqüên- cia de pacotes; um processador de pacote para operar sobre o sinal recebido para utilização na recuperação da informação; e um processador para determinar um tempo estimado para recepção da informação selecionada, em que o processador determina o tempo estimado em função de um tempo de atraso, o qual é determinado em função de um tempo de trans- missão para a informação recebida e um tempo de recepção para a informação recebida.

24. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora de início para a informação recebida.

25. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora final para a informação recebida.

26. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que a informação recebida é também a informação selecionada.

27. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que o processador controla pelo menos um do processador de pacote e desmodulador, tal que a energia seja reduzida em um tempo diferente do tempo estimado para recepção da informação selecionada.

28. Aparelho, de acordo com a reivindicação 27, CARACTERIZADO pelo fato de que o processador de pacote suporta sessões de Transmissão de Arquivo via Transporte Unidirecional (FLUTE) e o processador desliga os canais de FLUTE associados aos eventos não-selecionados quando o processador de pacote operar em energia reduzida.

29. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que a informação selecionada é um conteúdo baseado em arquivo compreendendo pelo menos um clipe.

30. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que a informação selecionada é um conteúdo em tempo real compreendendo pelo menos um programa.

31. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora de início e o processador determina o tempo de atraso em função de uma hora de início da informação recebida e uma hora real de chegada da informação recebida.

32. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que a hora de início da informação recebida é determinada a partir do guia de programa.

33. Aparelho, de acordo com a reivindicação 32, CARACTERIZADO pelo fato de 35 que a hora de início é uma hora de início publicada.

34. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que o tempo de atraso é determinado pela subtração da hora de início da hora real de che- gada.

35. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que o tempo de atraso é determinado a partir de uma função estatística operando sobre a diferença entre a hora de início e a hora real de chegada sobre um período de tempo para a informação recebida.

36. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que o tempo estimado é determinado pela adição de um tempo de transmissão para o even- to selecionado ao tempo de atraso.

37. Aparelho, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que o tempo de transmissão é uma hora final e o processador determina o tempo de atraso em função de uma hora final para a informação recebida e uma hora real de conclusão da informação recebida.

38. Aparelho, de acordo com a reivindicação 37, CARACTERIZADO pelo fato de que a hora final da informação recebida é determinada a partir de um guia de programa.

39. Aparelho, de acordo com a reivindicação 38, CARACTERIZADO pelo fato de que a hora final é uma hora final publicada.

40. . Aparelho, de acordo com a reivindicação 37, CARACTERIZADO pelo fato de que o tempo de atraso é determinado pela subtração da hora final da hora real de conclu- são.

41. . Aparelho, de acordo com a reivindicação 37, CARACTERIZADO pelo fato de que o tempo de atraso é determinado a partir de uma função estatística operando sobre a diferença entre a hora final e a hora real de conclusão sobre um período de tempo para a informação recebida.