BRPI0315207B1 - Method and system for transmitting the media flow from a flux server to the mobile client, flow server, mobile client. - Google Patents

Method and system for transmitting the media flow from a flux server to the mobile client, flow server, mobile client. Download PDF

Info

Publication number
BRPI0315207B1
BRPI0315207B1 BRPI0315207-3A BRPI0315207A BRPI0315207B1 BR PI0315207 B1 BRPI0315207 B1 BR PI0315207B1 BR PI0315207 A BRPI0315207 A BR PI0315207A BR PI0315207 B1 BRPI0315207 B1 BR PI0315207B1
Authority
BR
Brazil
Prior art keywords
client device
media stream
mobile client
server
streaming
Prior art date
Application number
BRPI0315207-3A
Other languages
English (en)
Inventor
Danilo Diego Curcio Igor
Lundan Miikka
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of BRPI0315207B1 publication Critical patent/BRPI0315207B1/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1083In-session procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/02Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • H04W36/023Buffering or recovering information during reselection

Abstract

"método e sistema para transmitir o fluxo de mídia de um servidor de fluxo para o cliente móvel, servidor de fluxo, cliente móvel, e, programa de computador". a invenção relaciona a um método para transmitir o fluxo de mídia do servidor de fluxo (111) para o dispositivo cliente móvel (101) em uma interface aérea, onde, após a re-seleção da célula, o método compreende solicitar ao servidor de fluxo (111) para re-enviar o fluxo de mídia que o dispositivo cliente móvel (101) não foi capaz de receber devido à re-seleção da célula.

Description

Relatório Descritivo da Patente de Invenção para: “MÉTODO E SISTEMA PARA TRANSMITIR O FLUXO DE MÍDIA DE UM SERVIDOR DE FLUXO PARA O CLIENTE MÓVEL, SERVIDOR DE FLUXO, E, CLIENTE MÓVEL”.
Campo da Invenção A invenção se refere à transmissão do fluxo de mídia de um servidor de fluxo para um dispositivo cliente móvel em uma interface de rádio.
Descrição do Estado da Técnica O serviço de fluxo comutado por pacote PSS (Packet Swtich Streamtng) está sendo atualmente padronizado para o modelo móvel pelo 3GPP (3rd Gcncration Partncrship Project). Um exemplo de um sistema de comunicação capaz de transmitir o fluxo de mídia (fluxo de vídeo e/ou de áudio) é apresentado na Figura I). O sistema compreende um servidor de fluxo 111, que c acoplado a uma rcdc-IP (Internet Protocol/ Protocolo Internet) 104, A rede-ÍP 104 pode ser, por exemplo, a Internet ou a Intranet do operador do provedor de serviço (uma rede intranet que pertence ao domínio do operador), A rede-TP 104 é acoplada à rede núcleo 103 da rede de comunicação móvel através da interface Gi. A rede de comunicação móvel também tem uma rede de acesso de rádio (RAN, Radio Access NetWork) 102 acoplada à rede núcleo 103, A rede de acesso de rádio 102 provê os dispositivos de comunicação móveis 101 com acesso à rede de comunicação móvel em uma interface aérea. Tal acesso pode ser por um dispositivo comutado por circuito (circuito comutado por voz ou chamada de dados) ou por um dispositivo comutado por pacote ou ambos. A seguir, o GPRS (General Packet Radio Service/Serviço Geral de Rádio por Pacote) é usado, como exemplo, de um dispositivo comutado por pacote para comunicar na interface aérea. Referindo ao GPRS, o termo genérico “rede de acesso de rádio (RAN)” c considerado para compreender as estações base transccptoras (BS, Base Station) e os controladores da estação base (BSC, Base Station Çontroller), No fluxo dc mídia, uma sequência de “imagens em movimento” (isto é, vídeo) ou som (isto c, áudio) ou uma sequência dc “imagens cm movimento” junto com som (isto é, multimídia) é enviada em uma forma compactada do senador de fluxo 111 para o dispositivo de comunicação móvel 101 (a seguir referenciado como dispositivo cliente 101). Em contraste à técnica na qual todo o arquivo dc mídia tem que ter chagado no cliente antes que este possa ser reproduzido, a técnica de fluxo habilita o envio de mídia (video e/ou áudio) do servidor de fluxo 111 para o dispositivo cliente 101 de uma maneira contínua e, reproduz a mídia quando esta chega no cliente.
Quando a mídia é transmitida no sistema de comunicação móvel celular, tal como o sistema apresentado na Figura 1, novos problemas específicos do modelo móvel surgem. Estes problemas são na maioria devido às diferentes restrições dos sistemas móveis. Um destes problemas surge na situação de re-seleção da célula (i.e., transferência) apresentada na Figura 2.
Na Figura 2, a primeira estação base BS1 da rede de acesso de rádio 102 serve a área da primeira célula 202, considerando que a segunda estação base BS2 da rede de acesso de rádio 102 serve a área da segunda célula 202. Antes da re-seleção da célula, o dispositivo cliente 101 é servido pela primeira estação base BS1, i.e., o dispositivo cliente 101 tem um enlace de rádio ativo com a primeira estação base BS1. Esta situação é apresentada na lateral esquerda da Figura 2. Após a re-seleção da célula, o dispositivo cliente 101 é servido pela segunda estação base BS2. O enlace de rádio com a primeira estação base BS1, apresentado pela linha pontilhada, é rompido. Esta situação é apresentada na lateral direita da Figura 2. A re-seleção da célula (CR, Çell Reselection) pode ser dividida em três períodos no tempo: a) período pré-CR
b) período CR c) período pós-CR.
Durante o período pré-CR, a qualidade do sinal recebido na primeira célula enfraquece e o dispositivo cliente 101 inicia a sinalização de re-seleção da célula. O dispositivo cliente 101 é capaz de receber o fluxo de mídia através da primeira estação base BS1 durante este período. Durante o período CR, a re-seleção da célula é executada. O dispositivo cliente 101 não pode receber o fluxo de mídia durante este período. Durante o período pós-CR, o dispositivo cliente 101 é capaz de receber o fluxo de mídia através da segunda estação base BS2. A re-seleção da célula pode causar uma parada longa no serviço. Por exemplo, a re-seleção da célula (período CR) no caso, onde o GPRS é usado como portadora de rádio pode levar de 30 - 40 segundos. Isto afetará a sessão de fluxo entrante. Por exemplo, parte dos pacotes que carregam o fluxo de mídia pode estar perdida e/ou congelada da mídia reproduzida, que pode ocorrer no dispositivo cliente 101. Se o fluxo de mídia compreende um fluxo de vídeo, o congelamento significa que a imagem imóvel aparecerá e ficará por um período de tempo no visor do dispositivo cliente antes do fluxo de mídia ser recebido novamente e poder ser reproduzido novamente. Se o fluxo de mídia compreende um fluxo de áudio, o congelamento significa que nenhum som é reproduzido de volta (i.e., silêncio) até o período CR terminar.
Adequadamente, há uma necessidade para encontrar um meio apropriado para reduzir os efeitos da re-seleção da célula em uma sessão de fluxo entrante.
Resumo da Invenção De acordo com o primeiro aspecto da invenção, é fornecido um método para transmitir o fluxo de mídia de um servidor de fluxo para o dispositivo cliente móvel em uma interface aérea, onde o método compreende a etapa de: - solicitar ao servidor de fluxo para enviar o fluxo de mídia que o dispositivo cliente móvel não é capaz de receber devido à re-seleção da célula.
Um pedido para solicitar ao servidor de fluxo para enviar o fluxo de mídia que pode ser enviado do dispositivo cliente móvel para o servidor de fluxo antes ou após a re-seleção da célula mencionada. O pedido mencionado não é limitado à solicitação para enviar apenas a mídia que o dispositivo móvel não é (ou foi) capaz de receber devido à re-seleção da célula (durante o período de re-seleção da célula). Em uma incorporação, o pedido pode ser construído, tal que seja atualmente solicitado: re-enviar a parte do conteúdo de mídia não recebida como também enviar qualquer parte restante do conteúdo de mídia. O termo mídia é considerado para significar vídeo ou áudio ou outra mídia, tal como uma imagem imóvel, ou qualquer combinação desta, i.e., multimídia.
Preferivelmente, um pedido de re-envio é enviado em resposta à re-seleção da célula. O pedido de re-envio é preferivelmente um pedido da camada de aplicação enviado entre a aplicação do dispositivo cliente móvel e a aplicação do servidor de fluxo.
Em uma incorporação preferida, o servidor de fluxo é solicitado para enviar em uma velocidade aumentada por um período de tempo predeterminado, de forma a aumentar no dispositivo cliente a proporção de capacidade de armazenagem temporária, tal como uma memória, na qual o fluxo de mídia é temporariamente armazenado antes da reprodução. Preferivelmente, isto é feito ao solicitar ao servidor de fluxo para comutar o envio do fluxo de mídia de taxa de bit elevada para o envio do fluxo de mídia de taxa de bit mais baixa em uma velocidade aumentada. Os fluxos de taxa de bit superior e inferior são preferivelmente fornecidos pelo codec de múltiplas-taxas.
De acordo com o segundo aspecto da invenção, é fornecido um dispositivo cliente móvel para receber o fluxo de mídia de um servidor de fluxo em uma interface aérea, o dispositivo cliente móvel compreendendo: - um dispositivo para solicitar ao servidor de fluxo para enviar o fluxo de mídia, que o dispositivo cliente móvel não foi capaz de receber devido à re-seleção da célula.
Preferivelmente, a interface aérea acopla o dispositivo cliente móvel àrede de comunicação móvel. O dispositivo cliente móvel preferivelmente compreende um telefone móvel celular.
De acordo com o terceiro aspecto da invenção, é fornecido um servidor de fluxo para enviar o fluxo de mídia para o dispositivo cliente móvel em uma interface aérea, o servidor de fluxo compreendendo: - um dispositivo para receber um pedido solicitando ao servidor de fluxo para enviar o fluxo de mídia que o dispositivo cliente móvel não foi capaz de receber devido à re-seleção da célula; e - os dispositivos para atuar no pedido recebido.
De acordo com o quarto aspecto da invenção, é fornecido um sistema compreendendo um servidor de fluxo e um dispositivo cliente móvel, para transmitir o fluxo de mídia do servidor de fluxo para o dispositivo cliente móvel na interface aérea, o sistema compreendendo: no dispositivo cliente móvel: - os dispositivos para solicitar ao servidor de fluxo para enviar o fluxo de mídia que o dispositivo cliente móvel não foi capaz de receber devido à re-seleção da célula; o sistema também compreende, no servidor de fluxo: - o dispositivo para receber o pedido; e - os dispositivos para atuar no pedido recebido.
De acordo com o quinto aspecto da invenção, é fornecido um programa de computador executável no dispositivo cliente móvel, o programa de computador compreendendo: - um código de programa para ocasionar ao dispositivo cliente móvel para solicitar ao servidor de fluxo para enviar o fluxo de mídia que o dispositivo cliente móvel não foi capaz de receber devido à re-seleção da célula.
De acordo com o sexto aspecto da invenção, é fornecido um programa de computador executável no servidor de fluxo, o programa de computador compreendendo: - um código de programa para ocasionar ao servidor de fluxo para receber um pedido solicitando ao servidor de fluxo para enviar o fluxo de mídia que o dispositivo cliente móvel não foi capaz de receber devido à re-seleção da célula; e - um código de programa para atuar no pedido recebido.
As reivindicações dependentes contêm as incorporações preferíveis da invenção. O assunto contido nas reivindicações dependentes relaciona a um aspecto particular da invenção e é também aplicável a outros aspectos da invenção.
Breve Descrição das Figuras As incorporações da invenção serão descritas por meio de exemplos com referência aos desenhos apensos, nos quais: Figura 1 - apresenta um sistema de comunicação capaz de transmitir o fluxo de mídia;
Figura 2 - apresenta uma situação de re-seleção da célula na qual a memória do dispositivo cliente é maior do que o tempo que a re-seleção da célula leva;
Figura 4 - apresenta a memória do dispositivo cliente em uma situação na qual a memória do dispositivo cliente é maior do que o tempo que a re-seleção da célula leva;
Figura 5 - apresenta outra ilustração da situação que é oposta a da Figura 4;
Figura 6 - apresenta a ação preferida em uma incorporação preferida da invenção;
Figura 7 - ilustra uma incorporação preferida da invenção;
Figura 8 - ilustra uma incorporação preferida da invenção;
Figura 9 - apresenta o dispositivo cliente de acordo com a incorporação preferida da invenção;
Figura 10 - apresenta o servidor de fluxo de acordo com a incorporação preferida da invenção; e Figura 11 - ilustra três formas de enviar mensagens de acordo com as incorporações preferidas da invenção.
Descrição Detalhada da Invenção O sistema apresentado na Figura 1 pode também ser usado nas incorporações preferidas da invenção (o mesmo se aplica para a Figura 2). Adequadamente, o sistema compreende um servidor de fluxo 111 que é acoplado à rede-IP. A rede-IP 104 pode ser, por exemplo, a Internet ou a intranet do operador do provedor de serviço. A rede-IP 104 é acoplada à rede núcleo 103 da rede de comunicação móvel através da interface Gj. A rede de comunicação móvel também tem uma rede de acesso de rádio (RAN) 102 acoplada à rede núcleo 103. A rede de acesso de rádiol02 provê os dispositivos de comunicação móveis 101 com acesso à rede de comunicação móvel sobre a interface aérea. Tal acesso pode ser provido ou por um dispositivo comutado por circuito (voz comutada por circuito ou chamada de dados) ou por um dispositivo comutado por pacote ou por ambos. A seguir, o GPRS (General Packet Radio Service/Serviço de Rádio Pacote Geral) é usado como um exemplo do dispositivo comutado por pacote para comunicar sobre a interface aérea.
Para melhor entender as incorporações preferidas da invenção, consideraremos os exemplos a seguir.
Neste exemplo, o dispositivo de comunicação móvel 101 (novamente referenciado como dispositivo cliente 101) tem estabelecido uma sessão de fluxo com o servidor de fluxo 111 ao ser servido pela primeira estação base BS1. Neste exemplo e na descrição a seguir, uma sessão de fluxo é considerada. Contudo, uma consideração correspondente aplica a uma sessão de fluxo de áudio como também a uma sessão de fluxo de multimídia (ex., vídeo com áudio). O protocolo RTSP (Real Time Streaming Protocol/Protocolo de Fluxo em Tempo Real) é usado no estabelecimento da sessão de fluxo. Uma vez que a sessão tem sido estabelecida, o próprio fluxo pode ser executado (i.e., o fluxo de mídia pode ser enviado) de acordo com o protocolo RTP (Real time Transport Protocol/Protocolo de Transporte em Tempo Real) ou outro protocolo. Contudo, se for desejado realizar uma troca na sessão estabelecida, isto será novamente feito usando RTSP.
No início da sessão de fluxo estabelecida, o fluxo de mídia recebido (fluxo de mídia), transmitido nos pacotes (ou quadros), é armazenado (i.e., armazenado temporariamente) na memória do dispositivo cliente (a seguir referenciado como a memória do dispositivo cliente). Quando a memória do dispositivo cliente está cheia, a reprodução (playback) do fluxo de mídia é iniciada em uma extremidade da memória, enquanto a memória é continuamente preenchida na outra extremidade com o fluxo de mídia recebido. Além disso, a memória deve permanecer quase cheia durante a operação normal do sistema. O dispositivo cliente agora passa pela re-seleção da célula da primeira célula 201 para a segunda célula 202 (Figura 2). E para ser observado que, embora a rede de acesso de rádio (RAN) 102 seja ilustrada na Figura 2 por apenas uma única nuvem, esta pode compreender diferentes redes de acesso de rádio. Esta pode compreender uma RAN GPRS (GPRS apenas), uma RAN 3G (terceira geração) ou uma combinação destas. A primeira célula 201 (servida pela estação base BS1) e a segunda célula 202 (servida pela estação base BS2) podem então ser, por exemplo, as células da RAN GPRS ou RAN 3G. Adequadamente, a re-seleção da célula (transferência) pode ocorrer, por exemplo, entre as estações base que pertencem a RAN GPRS, entre as estações base que pertencem a RAN 3G ou entre a estação base que pertence a RAN GPRS e a estação base que pertence a RAN 3G. O dispositivo cliente 101 não pode receber o fluxo de mídia durante o período CR. Além disso, quando o período CR inicia a memória do dispositivo cliente inicia vazia, porque o conteúdo da memória é também reproduzido enquanto o preenchimento contínuo é parado. Dependendo do tamanho da memória do dispositivo cliente, dois diferentes casos podem ser identificados: i) A memória do dispositivo cliente (no tempo) é menor do que o tempo que a re-seleção da célula leva, i.e., o tempo para esvaziar a memória total do dispositivo cliente é menor do que o período CR; ii) A memória do dispositivo cliente (no tempo) é maior do que a re-seleção da célula leva, i.e., o tempo para esvaziar a memória total do dispositivo cliente é maior do que o período CR.
No primeiro caso (Figura 3), a memória ficará totalmente vazia durante o período CR. Uma vez que a memória fica vazia, o dispositivo cliente 101 não tem nenhuma mídia para reproduzir. Conseqüentemente, o dispositivo cliente 101 inicia a re-armazenagem. A re-armazenagem pode ser iniciada durante o período pós-CR. De forma a ter a re-armazenagem iniciada, o dispositivo cliente 101 pode usar o método PAUSA/REPRODUZER. RTSP. Neste método, o dispositivo cliente 101 primeiro envia uma mensagem PAUSA RTSP para o servidor de fluxo 111. A mensagem PAUSA fará com que o servidor 11 pause o envio do fluxo de mídia. Subseqüentemente, o dispositivo cliente 101 envia uma mensagem REPRODUZIR RTSP, a qual solicita ao servidor de fluxo 111 para iniciar o fluxo de mídia do último quadro recebido. A re-armazenagem inicia quando o cliente novamente inicia a recepção do fluxo de mídia. Quando a memória do dispositivo cliente está cheia, a reprodução do fluxo de mídia é reiniciada do último quadro recebido. No meio-tempo, o último quadro recebido é apresentado como uma imagem imóvel no visor do dispositivo cliente. Contudo, a respeito da desvantagem de apresentar a imagem imóvel, nenhum pacote é efetivamente perdido, visto que o fluxo de mídia que não foi recebido no dispositivo cliente durante o período CR é re-enviado do servidor 111 para o dispositivo cliente 101 após o período CR.
No segundo caso (Figura 4), o conteúdo total da memória não foi reproduzido durante o período CR. Conseqüentemente, a memória apenas fica parcialmente vazia durante o período CR, i.e., existe ainda fluxo de mídia (DADOS) na memória quando o período CR termina. Durante o período pós-CR (após o período CR), a reprodução do fluxo de mídia armazenado na memória antes do período CR (i.e., DADOS*) é também continuada para uma extremidade da memória, enquanto a outra extremidade é preenchida com o fluxo de mídia recebido após o período CR (i.e., DADOS**). Se nada for feito, DADOS* eventualmente terminará e a reprodução é continuada com o primeiro quadro de dados DADOS**. Nenhuma imagem imóvel é apresentada. Contudo, o primeiro quadro de DADOS** não é o quadro que deveria ser reproduzido a direita após o último quadro de DADOS*. Uma vez que, o dispositivo cliente 101 não podería receber o fluxo de mídia durante o período CR, este não tem mesmo recebido o quadro que deveria ser apresentado após o último quadro de DADOS*. Existe um intervalo temporal na mídia armazenada. Como resultado, o dispositivo cliente 101 saltará apresentando a seqüência do fluxo de mídia (vídeo), a qual não podería ser recebida, devido a concemência de re-seleção da célula no fluxo de áudio, o mesmo efeito ocorre, i. e., o dispositivo cliente 101 saltará ao reproduzir o som que não podería ser recebido. O segundo caso é também ilustrado com a ajuda da Figura 5. É para ser observado que a Figura 5 apenas apresenta um caso muito simplificado. O tempo é considerado para fluir da esquerda para a direita na Figura 5. A seqüência do fluxo de mídia que o servidor envia compreende os quadros de vídeo A-S. Os quadros são recebidos no dispositivo cliente e armazenados antes da reprodução. A reprodução da mídia inicia do quadro A que inicia quando a memória está cheia (i.e., quando os quadros A-G têm sido armazenados na memória), os quadros (imagem de vídeo em movimento) são subseqüentemente apresentados no visor do dispositivo cliente. A armazenagem dos quadros seguintes ao quadro G não é apresentada na Figura 5 por motivo de clareza. O fluxo de mídia do servidor para o dispositivo cliente não é possível durante o período CR. Além disso, o dispositivo cliente não recebe os quadros L-O. Caso contrário, o fluxo de mídia é perfeitamente recebido no dispositivo cliente. Agora que o período CR é menor do que o tamanho da memória, a apresentação do último quadro (quadro K) recebido antes do período CR será seguida pela apresentação do primeiro quadro (quadro P) recebido após o período CR. Os quadros de vídeo L-0 não são todos apresentados. Concernindo um fluxo de áudio, o mesmo efeito ocorre, i.e., o usuário ouve uma pausa e um intervalo temporal no som.
Existem dois tipos de quadros: os quadros intra e os quadros inter. Os quadros intra contêm toda a informação necessária de uma imagem, considerando que os quadros-inter apenas contêm as alterações ou as alterações preditas comparadas à imagem prévia. A imagem prévia pode ser um quadro intra ou um quadro inter. Além disso, se o quadro P for um quadro intra, a imagem apresentada apenas distorce no tempo do quadro K para o quadro P. Neste caso, os quadros L-0 não são simplesmente apresentados para o usuário. Mas se o quadro P for uma distorção severa do quadro inter, na imagem apresentada (em movimento), é provável de ocorrer antes que o próximo quadro intra seja recebido e reproduzido.
Uma incorporação preferida da invenção como apresentado na Figura 6 concentra no problema acima mencionado relatando o segundo caso. Nesta incorporação, a memória é maior do que a duração do período CR. Além disso, a memória não fica totalmente vazia durante o período CR, mas apenas parcialmente vazia. É para ser observado que a Figura 6 apenas apresenta um caso muito simplificado. O tempo é considerado para fluir da esquerda para a direita na Figura 6. A seqüência do fluxo de mídia que o servidor envia compreende os quadros A-S. Os quadros são recebidos no dispositivo cliente e armazenados antes da reprodução. A reprodução da mídia inicia do quadro A que inicia quando a memória está cheia, os quadros (imagem de vídeo em movimento) são apresentados subseqüentemente no visor do dispositivo cliente. A armazenagem dos quadros seguintes ao quadro G não é apresentada na Figura 6 por motivo de clareza. O fluxo de mídia do servidor para o dispositivo cliente não é possível durante o período CR. Além disso, o dispositivo cliente não recebe os quadros L-O. Caso contrário, o fluxo de mídia é perfeitamente recebido no dispositivo cliente.
Quando o período CR termina, o dispositivo cliente sabe exatamente qual é o último quadro que tem sido recebido antes do período CR (i.e., durante o período pré-CR). Nesta incorporação, este é o quadro K. O dispositivo cliente então solicita, o direito após o período CR ter sido terminado, o servidor de fluxo inicia o re-envio do fluxo de mídia do último quadro recebido para o começo. Após receber o pedido, o servidor de fluxo inicia o re-envio do fluxo de mídia. O primeiro quadro a ser enviado está na incorporação do quadro L. Quaisquer quadros enviados e recebidos após o período CR, mas antes do re-envio ter começado (possivelmente alguns quadros iniciando do quadro P) são ignorados pelo dispositivo cliente. Quando o fluxo de mídia (dos quadros A-K) armazenado na memória antes do período CR terminar, então a reprodução é continuada com o primeiro quadro (quadro L) do fluxo de mídia re-enviado recebido após o período CR. Além disso, nenhuma descontinuidade na imagem de vídeo apresentada deveria aparecer para o usuário. Na Figura 6, os quadros L-0 de vídeo re-enviados, os quais teriam por outro lado falhado, recebidos no dispositivo cliente são apresentados com fonte em negrito. Correspondentemente, referindo ao fluxo de áudio, o servidor de fluxo é solicitado para iniciar o re-envio do fluxo de áudio em um ponto no qual a recepção tem sido parada no dispositivo cliente. Nenhuma descontinuidade na reprodução deveria aparecer.
Na prática, o pedido de re-envio pode ser executado pelo método de PAUSA/REPRODUZIR RTSP. Neste método, o dispositivo cliente primeiro envia, após o período CR ter sido terminado, uma mensagem de PAUSA RTSP para o servidor de fluxo. A mensagem PAUSA ocasionará ao servidor para pausar o envio do fluxo de mídia. Contudo, a reprodução do fluxo de mídia recebido no dispositivo cliente não é pausada, a menos que a memória fique vazia (que não deveria ser o caso). Subseqüentemente, o dispositivo cliente envia uma mensagem PLAY RTSP para o servidor de fluxo 111. A mensagem PLAY contém a informação no ponto de partida de re-envio. Na extremidade do período CR, o dispositivo cliente sabe o tempo do último quadro recebido. Baseado neste, o dispositivo cliente determina o ponto de partida antes de enviar a mensagem PLAY. A mensagem PLAY ocasiona ao servidor o inicio do re-envio.
Um exemplo da mensagem PAUSA é como a seguir: PAUSA rtsp://exemplo.com/foo RTSP/1.0 CSeq: 6 Sessão: 354832 A mensagem PAUSA informa ao servidor que a troca está indo. Um exemplo da mensagem REPRODUZIR enviada subseqüentemente é como a seguir: REPRODUZIR rtsp://exemplo.com/foo RTSP/1.0 CSeq: 7 Sessão: 354832 Ordem: npt=28.00- 0 campo da mensagem Ordem’ indica o ponto de partida do re-envio. Neste exemplo, o ponto de partida é 28 segundos do início da seqüência do fluxo de mídia. Em relação à incorporação apresentada na Figura 6, este ponto seria exatamente o tempo do quadro L na seqiiência do fluxo de mídia.
Na incorporação descrita, os quadros (pacotes) que foram perdidos durante o período CR serão re-enviado do servidor para o dispositivo cliente. Também, uma vez que o tamanho da memória é maior do que a duração do período CR, nenhuma interrupção na imagem de vídeo apresentada deveria aparecer e a experiência do usuário é maximizada.
Contudo, como no caso em que durante o fluxo normal a proporção da capacidade da memória não muda, uma vez que a memória está vazia (reproduzida) na mesma taxa que esta é preenchida, isto pode causar um problema adicional. Em uma incorporação descrita, após a re-seleção da célula, a memória do dispositivo cliente fica mais vazia do que antes, pelas razões descritas antes. Além disso, por exemplo, se uma nova re-seleção da célula é para ser executada em um futuro próximo, a memória mais vazia ocasiona a mesma desvantagem como discutido em conexão com o primeiro caso acima (i.e., o caso no qual a memória do dispositivo cliente foi menor do que o tempo que a re-seleção da célula leva). A incorporação preferida da invenção concentra no problema identificado acima. Nesta incorporação, para assegurar o procedimento mais leve da imagem de vídeo apresentada (correspondentemente: o som reproduzido), a memória do dispositivo cliente é preenchida após o período CR, por um período de tempo, em uma taxa mais alta que é esvaziada (reproduzido). Este período pode ser denominado de período de preenchimento, Quando o período de preenchimento termina, a memória é preenchida novamente e, o fluxo normal no qual a memória é preenchida com a mesma taxa da esvaziada é retomado. É para ser observado que normalmente o aumento da proporção da capacidade da memória requerería que a reprodução fosse pausada. Na presente incorporação, a reprodução não é pausada, mas a proporção da capacidade da memória pode ainda ser aumentada devido ao gerenciamento da memória inteligente, na qual a memória é preenchida, durante a reprodução, a uma taxa maior do que a taxa de reprodução.
Para aumentar a proporção da capacidade da memória sem pausar a reprodução, o dispositivo cliente, nesta incorporação, solicita ao servidor para comutar o envio de uma seqiiência de fluxo de mídia de taxa de bit mais baixa, mas para uso no envio atual com a mesma taxa de transmissão de bit (a seguir referenciada como uma taxa de bit de transmissão original) de antes. Para alcançar a taxa de bit de transmissão original, o dispositivo cliente solicita ao servidor para acelerar a transmissão da sequência da taxa de bit mais baixa pelo fator de velocidade. Acelerar a taxa de bit de transmissão ocasiona que mais dados sejam escritos na memória do que lidos da memória. Além disso, a proporção da capacidade da memória aumenta quando desejado.
Em outras palavras, ao servidor é pedido para comutar do envio da seqüência original codificada na primeira taxa de bit para enviar uma nova sequência correspondente codificada na segunda taxa de bit inferior à primeira taxa de bit e para aumentar a taxa de bit de transmissão da nova seqüência, de forma a alcançar a taxa de bit de transmissão original (largura de banda). É para ser observado que a taxa de bit, na qual o fluxo de mídia é codificado (e será decodificado) é um conceito diferente do que a taxa de bit de transmissão. A taxa de bit na qual o fluxo de mídia tem sido codificado tem efeito na qualidade da imagem. Se o fluxo de mídia tem sido codificado a uma taxa de bit mais alta, isto significa que mais bits têm sido usados na codificação comparado à codificação a uma taxa de bit mais baixa. Isto tipicamente resulta em uma melhor qualidade da imagem. A taxa de bit de transmissão, por outro lado, é a taxa de bit na qual o fluxo de mídia é enviado atualmente e este depende da largura de banda disponível. O pedido para comutar o envio de uma seqüência de taxa de bit inferior e para acelerar a taxa de bit de transmissão pode ser entregue ao usar o método PAUS A/REPRODUZIR RTSP. Quando o dispositivo cliente deseja preencher a memória do dispositivo cliente durante o período pós-CR, este primeiro envia uma mensagem PAUSA, correspondendo a uma já apresentada na descrição precedente, para o servidor indicar que uma troca está indo. Subseqüentemente, este gera a mensagem REPRODUZIR e envia esta para o servidor.
Um exemplo de tal mensagem REPRODUZIR é como a seguir: REPRODUZIR rtsp://exemplo.com/foo RTSP/1.0 CSeq: 7 Sessão: 354832 Ordem: npt=28.00-40.00 Largura de Banda: 20000 Velocidade: 1.5 Esta mensagem contém dois campos de mensagem opcionais, denominados de ‘Largura de Banda’ e ‘Velocidade’ a serem informados no dispositivo cliente e no servidor de fluxo. Estes campos já foram especificados como campos opcionais pelo IETF (Internet Engineering Task Force/Força Tarefa de Engenharia Internet) no padrão RFC 2326 (Real Time Streaming Protocol/Protocolo de Fluxo em Tempo Real). O campo da mensagem ‘Largura de Banda’ indica ao servidor para trocar no envio a seqüência da taxa de bit mais baixa (aqui: uma seqüência cuja taxa de bit é 20 kbps) e o campo da mensagem ‘Velocidade’ indica ao servidor para acelerar o envio pelo fator de velocidade (aqui: 1.5). O campo da mensagem Ordem’ indica o ponto de partida e o ponto de parada na seqüência do fluxo de mídia em unidades de tempo (calculadas do início da seqüência(s) do fluxo de mídia). A mensagem REPRODUZIR apresentada seria adequada, por exemplo, para o servidor que inicialmente envia uma seqüência de taxa de bit de 30kbps em uma taxa de bit de transmissão original de 30 kbps e em qual servidor, de forma a preencher a memória, é desejado para comutar o envio da seqüência cuja taxa de bit é de 20 kbps e para acelerar o envio no fator de velocidade de 1.5 para alcançar a taxa de bit de transmissão original de 30 kbps durante um período de preenchimento de 12 segundos (i.e., entre os instantes de tempo de 28 e 40 segundos da seqüência de mídia).
Se o cliente conhece as opções possíveis da taxa de bit (elas são tipicamente comunicadas do servidor para o cliente durante o estabelecimento da sessão, por exemplo, com a ajuda da resposta OK 200 para uma mensagem DESCREVER RTSP), este pode calcular o fator de velocidade necessário para alcançar a taxa de bit original usando a fórmula a seguir: Quando a memória está cheia, o dispositivo cliente envia outra mensagem par PAUSA RTSP e REPRODUZIR para o servidor. Um exemplo da mensagem REPRODUZIR é como a seguir: REPRODUZIR rtsp://exemplo.com/foo RTSP/1.0 CSeq: 67 Sessão: 354832 Ordem: npt = 40.00- Largura de Banda: 30000 Velocidade: 1.0 Esta mensagem exemplar solicita ao servidor para iniciar o envio da seqüência do fluxo de mídia (original) de 30 kbps (Largura de banda: 30000) na taxa de bit de transmissão original de 30kbps (Velocidade: 1.0) iniciando do instante de tempo de 40 segundos da seqüência de mídia (Ordem: npt = 40.00-). O dispositivo cliente pode calcular o comprimento do período de preenchimento da memória usando as fórmulas a seguir: onde Nestas fórmulas, TempoSeqlnferior indica a duração da seqüência da taxa de bit inferior reproduzindo o tempo no dispositivo cliente, TamanhoMem indica o tamanho da memória em segundos e DadosMem indica os dados deixados na memória em segundos. O preenchimento da memória é ilustrado na Figura 7. É para ser observado que a Figura 7 apenas apresenta um caso muito simplificado. Todos os retardos, por exemplo, têm sido ignorados. O tempo é considerado para fluir da esquerda para a direita na Figura 7. Pode ser visto que a memória inicia vazia quando o período CR inicia. Após receber, a primeira mensagem REPRODUZIR, o servidor comuta ao enviar uma seqüência de mídia tendo uma taxa de bit inferior (aqui: 20kpbs) e acelera o envio pelo fator de velocidade (aqui novamente: 1.5), Uma vez que o fator de velocidade é de 1.5, o preenchimento da memória leva duas vezes o tempo que o último período vazio. Por exemplo, se o último período vazio for de 25 segundos, o período de preenchimento deveria ser de 50 segundos com este fator de velocidade. Quando a memória é preenchida a segunda mensagem REPRODUZIR é enviada e o servidor comuta ao enviar a sequência de mídia original possuindo uma taxa de bit superior (aqui: 30 kbps) e continua enviando na taxa de bit de transmissão original.
Anteriormente, tem sido descrito que, por exemplo, o fluxo de vídeo tipicamente compreende ambos, os quadros intra e inter, onde os quadros intra são ‘quadros independentes’ contendo toda a informação necessária de uma imagem, considerando que os quadros-inter apenas contêm alterações ou alterações preditas comparadas à imagem prévia. Na incorporação preferida da invenção a seguir, a temporização de comutação da seqüência de taxa de bit inferior para a seqüência de taxa de bit original é mais precisamente descrita a este respeito.
Nesta incorporação o propósito é o tempo, quando possível, para comutar da seqüência de taxa de bit inferior para a seqüência de taxa de bit original, para ocorrer no ponto do quadro intra da seqüência da taxa de bit original (ou, mais geralmente, no ponto do quadro intra da seqüência, no qual o envio é comutado). Desta forma, os erros de predição e/ou pulos no fluxo de mídia (quadro) podem ser evitados. A Figura 8 ilustra esta incorporação. É para ser observado que a Figura 8 apenas apresenta um caso simplificado. O tempo é considerado para fluir da esquerda para a direita na Figura 8. Nesta incorporação, a primeira comutação da seqüência de taxa de bit original para a seqüência de taxa de bit inferior é realizada no pondo de 28 segundos, com a ajuda da primeira mensagem par PAUSA/REPRODUZIR.
Como ilustrado na Figura 8, a posição dos quadros intra na seqüência de taxa de bit original pode diferenciar da seqüência de taxa de bit inferior. Contudo, baseado nos itens abaixo: • o tempo requerido para preencher totalmente a memória, i.e. ‘período de preenchimento’, • a distância em tempo dos dois quadros intra adjacentes na seqüência original, i.e. uma taxa de quadro intra, ‘TempoQuadroIoriginai’. e • o tempo no qual a primeira comutação da seqüência de taxa de bit original para a seqüência de taxa de bit inferior é realizada, i.e., ‘TempoComutação’, pode ser calculado um ponto adequado no tempo para comutar de volta a seqüência de taxa de bit original. O parâmetro ‘TempoQuadroIoriginai’ pode ser calculado no dispositivo cliente da seqüência de taxa de bit original antes de comutar para a seqüência de taxa de bit inferior. O cálculo do ponto adequado no tempo para comutar de volta para a seqüência de taxa de bit original pode ser executado usando a fórmula a seguir: Nesta fórmula, TempoTrocaSeq’ indica o ponto no tempo para comutar de volta para a seqüência de taxa de bit original e os colchetes indicam uma fimção-mínima (ou uma função de truncagem) que tranca a parte ffacional do valor computado nos colchetes. Por exemplo, se o tempo requerido para preencher totalmente a memória, i.e., ‘período de preenchimento’ é de 16 segundos, o tempo no qual a primeira comutação é realizada, i.e., ‘TempoComutação’ é de 28 segundos e a diferença de tempo entre os dois quadros intra adjacentes na seqüência original, i.e., ‘TempoQuadroIorigina]’ é de 5 segundos, então o ponto no tempo para comutar de volta para a seqüência de taxa de bit original é de 40 segundos (TempoTrocaSeq = 5*floor((28+16)/5) = 40s). Adequadamente, a segunda mensagem par PAUSA/REPRODUZIR é enviada no ponto 40 segundos, como indicado na Figura 8. Nesta incorporação, o ponto de partida e o ponto de parada a ser colocado no campo da mensagem Ordem’ da mensagem REPRODUZIR são de 28 segundos e de 40 segundos, respectivamente. E para ser observado que, devido a taxa do quadro intra, não podería em todos os casos ser possível preencher totalmente a memória. Por exemplo, no exemplo descrito, teria levado 4 segundos mais para preencher totalmente a memória. Contudo, a fórmula fornece o quadro intra mais adequado para o período de preenchimento da memória.
Em outra incorporação pode ser que, no ponto do último quadro recebido antes do período CR, não exista um quadro intra na sequência de mídia de taxa de bit inferior. Nesta incorporação, o ponto de partida do pedido de re-envio é ajustado por uma quantia necessária de quadros (ou tempo) retroativos, tal que haverá um quadro intra na seqüência de taxa de bit inferior no ponto de partida. Neste caso, o grupo dos últimos quadros recebidos antes do período CR, que pertence a um período de tempo subsequente no ponto de partida, são ignorados no dispositivo cliente para garantir uma reprodução contínua.
Em outra incorporação da invenção, as comutações entre duas diferentes seqüências de taxa de bit são executadas sem o método(s) de temporização descrito. Nesta incorporação, o primeiro ponto de comutação (da seqüência de taxa de bit superior para a inferior) é determinado diretamente através do último quadro recebido e o segundo ponto de comutação (da seqüência de taxa de bit inferior para a superior) é determinado diretamente pelo tempo requerido para preencher totalmente a memória (‘período de preenchimento’). Os pontos de comutação podem então finalizar sendo o ponto do quadro intra ou inter. Deveria ao estabelecimento do ponto de comutação sendo no ponto do quadro inter (por exemplo, um quadro-P), um erro de predição menor pode ocorrer na mídia reproduzida, contudo, nesta incorporação, a memória pode ser totalmente preenchida.
Outra forma de executar a comutação é usar o denominado “quadros de comutação”. Existem quadros que contêm a informação “diferença” entre os quadros correspondentes em diferentes seqüências de taxa de bit. Nesta incorporação, uma ponte e um comutador entre as duas seqüências são executados com a ajuda destes quadros usando a informação de diferença. A Figura 9 apresenta o dispositivo cliente 101 de acordo com a incorporação preferida da invenção. O dispositivo cliente pode ser uma estação móvel da rede de telefonia de rádio celular. O dispositivo cliente 101 compreende uma unidade de processamento MCU, uma parte de ffeqüência de rádio RF, e uma interface do usuário UI. A parte de freqüência de rádio RF e a interface do usuário UI são acopladas à unidade de processamento MCU. A interface do usuário UI tipicamente compreende um visor, um ou mais alto-falantes e um teclado (não apresentado) com ajuda do qual o usuário pode usar o dispositivo 101. A unidade de processamento MCU compreende um processador (não apresentado), uma memória 210 e um programa de computador. O programa tem sido armazenado na memória 210. A memória do dispositivo cliente 240 é também compreendida na memória 210. O processador controla, de acordo com o programa, a operação do dispositivo cliente 101, tal como receber o fluxo de mídia enviado do servidor 111 e o envio dos pedidos para o servidor 111 através da parte de freqüência de rádio RF, ao ler e escrever o fluxo de mídia recebido (vídeo e/ou áudio) na memória 240, e apresentar o fluxo de vídeo recebido no visor e o áudio em um ou mais alto-falantes da interface do usuário UI. O tamanho adequado da memória (no tempo) pode ser, por exemplo, 1.5 ou 2 vezes o período de tempo CR máximo (ou médio). O programa compreende a aplicação de programa do cliente de fluxo 220 (aqui referenciado como programa do cliente 220), a pilha de protocolo 230 para implementar as camadas de protocolo necessárias, tal como a camada RTP, a camada RTSP, a camada SDP (Session Description Protocol/Camada de Descrição de Sessão), a camada TCP (Transmission Control Protocol/Protocolo de Controle de Transmissão), uma camada IP e, abaixo da camada-IP, as camadas de protocolo mais baixas. Em adição, o programa compreende como uma parte do programa do cliente 220, um aparelho de mídia para reproduzir a mídia recebida. O processador gera, baseado no programa do cliente 220, as mensagens PAUSA e REPRODUZIR acima mencionadas e as envia para o servidor 111 através da parte de freqüência de rádio RF. O processador também executa, baseado no programa do cliente 220, os cálculos necessários que relacionam ao fator de velocidade, que relaciona ao período de preenchimento da memória e que relaciona ao ponto adequado no tempo para comutar da seqüência de taxa de bit inferior de volta para a seqüência de taxa de bit original. A geração e o envio do pedido de re-envio (mensagem REPRODUZIR) e outra ação apropriada é ativada pelo evento de re-seleção da célula ocorrido no dispositivo cliente móvel 101. O evento pode ser detectado pelo programa do cliente 220 através de uma mensagem assíncrona de um API (Application Programming Interface/Interface do Programa de Aplicação) fornecido pelas camadas mais baixas da pilha de protocolo 230. Altemativamente ou em adição, o evento pode ser detectado ao monitorar o nível de memória, i.e, a proporção de capacidade da memória do dispositivo cliente 240. Neste caso, se a memória 240 não recebe os dados para uma certa quantia X de tempo (dependendo da implementação, o parâmetro X pode ser definido como um valor constante, e é um limiar para o programa cliente 220 para entender que o evento de re-seleção da célula tem ocorrido), e se o dispositivo cliente 101 após começa a receber os dados após uma certa quantia variável Y de tempo (onde Y>X, e Y é a duração real do período CR), então o cliente pode ativar a ação descrita nesta descrição. A Figura 10 apresenta o servidor de fluxo 111 de acordo com a incorporação preferida da invenção. O servidor de fluxo 111 compreende uma unidade de processamento CPU, a primeira memória 310, uma interface de rede IP 350, e uma segunda memória 360. A primeira memória 310, a interface de rede IP 350, e a segunda memória 360 são acopladas à unidade de processamento CPU. A unidade de processamento CPU controla, de acordo com o programa de computador armazenado na primeira memória 310, a operação do servidor de fluxo 111, tal como o processamento dos pedidos recebidos do dispositivo cliente 101 e o envio dos fluxos de mídia pré-armazenados, armazenados na segunda memória (disco) 360, para o dispositivo cliente 101 através da interface de rede IP 350. O programa compreende uma aplicação de programa do servidor de fluxo 320 (aqui referenciado como um programa do servidor 320), uma pilha de protocolos 330 para implementar as camadas de protocolo necessárias, tal como a camada RTP, a camada RTSP, a camada SDP, a camada TCP, a camada IP e as camadas de protocolo mais baixas.
As mensagens PAUSA e REPRODUZIR enviadas do dispositivo cliente 101 são recebidas através da interface de rede IP 350. O processador (não apresentado) da unidade de processamento CPU processa as mensagens de acordo com o programa do servidor 320 e a pilha de protocolo 330 e toma a ação apropriada. A presente invenção provê um meio para reduzir os efeitos da re-seleção da célula na sessão de fluxo entrante. E para ser observado que, de acordo com as incorporações preferidas da invenção, um pedido para re-enviar (ex., a mensagem REPRODUZIR) é enviado na camada de aplicação, i.e., entre a aplicação do programa cliente 220 e a aplicação do programa do servidor 320. Preferivelmente, o RTSP sobre TCP (Transmission Çontrol Protocol/Protocolo de Controle de Transmissão) ou RTSP sobre outro protocolo confiável é usado na transferência dos pedidos da camada de aplicação do dispositivo cliente para o servidor de fluxo. A recepção das mensagens no servidor de fluxo pode então basicamente ser garantida.
Embora tenha sido descrito que a re-seleção da célula seria executada entre duas estações base, deveria ser observado que a re-seleção da célula pode ser executada também entre dois setores de uma e a mesma estação base. Também, deveria ser observado que dependendo da implementação, pode ser que mensagens separadas (mensagens PAUSA) que pausam o envio do fluxo de mídia não sejam necessárias. Em uma incorporação alternativa, ambos parar o envio do fluxo de mídia e iniciar o re-envio do fluxo de mídia é ocasionado por uma única mensagem apropriada.
Em adição, em relação à incorporação de preenchimento da memória, tem sido descrito anteriormente que quando o servidor comuta o envio de uma seqüência de taxa de bit inferior, a taxa de bit de transmissão original seria mantida. Contudo, em uma incorporação alternativa da invenção, uma maior taxa de bit de transmissão do que a taxa de bit de transmissão original é usada durante o período de preenchimento, de forma a preencher a memória mais rapidamente. Nesta incorporação, é assumido que uma maior largura de banda pode ser solicitada pelo dispositivo cliente móvel e que a maior largura de banda é atualmente disponível na rede de acesso de rádio.
Em adição, em relação à incorporação de preenchimento da memória, a informação de largura de banda da seqüência pode ser enviada para o servidor de fluxo 111, também por outros meios do que o campo RTSP ‘Largura de Banda’ (por exemplo, ao solicitar uma seqüência específica codificada como uma taxa de bit conhecida para o dispositivo cliente 101). Neste caso, o campo ‘Largura de Banda’ não é usado, os campos ‘Velocidade’ e Ordem’ são re-calculados de acordo com a taxa de bit da seqüência conhecida amai. E possível que a largura de banda da rede (interface aérea) troque durante o período de preenchimento da memória. Se o dispositivo cliente 101 suporta a adaptação da largura de banda que envolve a comutação do fluxo de bit, o dispositivo cliente 101 deveria pausar o preenchimento da memória (com uma mensagem PAUSA RTSP) antes de enviar a mensagem de adaptação da largura de banda para o servidor de fluxo 111. Após as operações de adaptação da largura de banda terminarem, o dispositivo cliente pode iniciar o preenchimento da memória novamente e recalcular os valores da ‘Largura de Banda’, da ‘Velocidade’ e da Ordem’ de acordo com a taxa de bit e a informação de temporização do novo fluxo de mídia.
Também, em relação à incorporação de preenchimento da memória, deveria ser observado que, em uma incorporação alternativa, as segundas mensagens PAUSA/REPRODUZIR não são enviadas, mas a comutação de volta para enviar a seqüência de mídia original na taxa de bit de transmissão original será executada automaticamente pelo servidor baseado na informação do ponto de parada contida na primeira mensagem REPRODUZIR. O pedido de re-envio mencionado nas várias incorporações da invenção pode, em certos casos, atualmente serem um pedido de envio. Um dos casos é considerado como uma incorporação alternativa da invenção. Nesta incorporação, o dispositivo cliente 101 sabendo de antemão que a re-seleção da célula está para ocorrer em um futuro muito próximo envia uma mensagem PAUSA para o servidor de fluxo 111 antes de iniciar o período de re-seleção da célula (i.e., durante o período pré-CR). Ao enviar a mensagem PAUSA está é ativada pelo evento de início de re-seleção da célula notificado para o programa cliente 220, por meio da camada mais baixa API. A mensagem PAUSA ocasiona ao servidor de fluxo 111 para parar o envio do fluxo de mídia. Quando o período CR terminar, o dispositivo cliente 101 então envia a mensagem PAUSA ocasionando ao servidor de fluxo para iniciar o envio no ponto no qual o envio foi parado antes do período-CR. Ao reproduzir o fluxo de mídia, este não é parado no dispositivo cliente 101 entre, e se a memória do dispositivo cliente 240 tiver sido selecionada para ser maior no tempo do que o tempo que a re-seleção da célula leva, a memória 240 não fica totalmente vazia durante a re-seleção da célula e o usuário não experimenta quaisquer pulos ou interrupção na reprodução. A mensagem REPRODUZIR pode conter um pedido para enviar em uma velocidade aumentada, de forma a aumentar a proporção da capacidade da memória 240.
Em ainda outra incorporação, o dispositivo cliente móvel 101 envia, antes do período CR, para o servidor de fluxo 111 uma mensagem apropriada solicitando ao servidor de fluxo 111 para parar o envio do fluxo de mídia e para iniciar o envio novamente em um ponto adequado no tempo após o período CR. Ao enviar a mensagem está é ativada, durante o período pré-CR, através do evento de início de re-seleção da célula notificado para o programa cliente 220, por meio da camada mais baixa API. O dispositivo cliente móvel 101, sabendo aproximadamente do tempo que a re-seleção da célula está levando, estima um ponto adequado no tempo no qual este é novamente capaz de receber os dados. Este insere esta informação para a mensagem assim como para prevenir o servidor de fluxo 111 de iniciar o envio novamente tão cedo.
Um exemplo da mensagem mencionada acima é como a seguir: REPRODUZIR rtsp://exemplo.com/foo RTSP/1.0 CSeq: 7 Sessão: 354832 Ordem: npt = 28.00-40.00; tempo = 19970123T153600Z
Largura de Banda: 20000 Velocidade: 1.5 Esta é uma mensagem REPRODUZIR RTSP possuindo o campo do cabeçalho ‘Tempo’. O valor deste campo programa o início do envio “futuro” do fluxo de mídia. A Figura 11 ilustra (especialmente em relação às incorporações de preenchimento da memória) a seguir as três formas nas quais as mensagens podem ser enviadas: Caso 1: A primeira mensagem PAUSA e REPRODUZIR é enviada após o período CR. A segunda mensagem PAUSA e REPRODUZIR é enviada quando a memória 240 está cheia.
Caso 2: A primeira mensagem PAUSA é enviada antes do período CR. A mensagem REPRODUZIR associada é enviada após o período CR. A segunda mensagem PAUSA e REPRODUZIR é enviada quando a memória 240 está cheia.
Caso 3: A primeira mensagem PAUSA é enviada antes do período CR. A mensagem REPRODUZIR associada é enviada após a mensagem PAUSA, mas antes do período CR. A segunda mensagem PAUSA e REPRODUZIR é enviada quando a memória 240 está cheia. O envio da segunda mensagem PAUSA não é necessário, se a primeira mensagem REPRODUZIR contém o campo Ordem’ fechado.
As implementações e as incorporações particulares da invenção têm sido descritas. É claro para o técnico no assunto que a invenção não está restrita aos detalhes das incorporações apresentados acima (ex., os nomes das mensagens e os nomes dos campos da mensagem), mas estes podem ser implementados em outras incorporações usando meios equivalentes sem desviar das características da invenção. O escopo da invenção é apenas restrito às reivindicações apensas.
REIVINDICAÇÕES

Claims (23)

1. Método para transmitir o fluxo de mídia de um servidor de fluxo (111) para o dispositivo cliente móvel (101) em uma interface aérea, onde o método é CARACTERIZADO pelo fato de que compreende a etapa de: - receber fluxo de mídia enviado do servidor de fluxo (111); - detectar um evento de re-seleção de célula no dispositivo cliente móvel; e - em resposta ao evento de re-seleção da célula detectado, solicitar ao servidor de fluxo (111) com um pedido de protocolo de transmissão em tempo real para enviar o fluxo de mídia, que o dispositivo cliente móvel (101) deixou de receber devido à re-seleção da célula em uma sessão contínua de transmissão.
2. Método de acordo com a reivindicação 1, é CARACTERIZADO pelo fato de que o servidor de fluxo é fornecido com um ponto de partida no qual inicia a transmissão.
3. Método de acordo com a reivindicação 1, é CARACTERIZADO pelo fato de que o servidor de fluxo (111) envia o fluxo de mídia que o dispositivo cliente móvel (101) deixou de receber devido à re-seleção da célula como também a parte restante do fluxo de mídia em resposta ao pedido.
4. Método de acordo com a reivindicação 1, é CARACTERIZADO pelo fato de que a re-seleção da célula compreende o período de re-seleção da célula durante o qual o dispositivo cliente móvel (101) deixou de receber o fluxo de mídia, o método compreende: - enviar do dispositivo cliente móvel (101) para o servidor de fluxo (111), após o período de re-seleção da célula, um pedido de re-envio solicitando ao servidor de fluxo (111) para re-enviar o fluxo de mídia que o dispositivo cliente móvel (101) não foi capaz de receber durante o período de re-seleção da célula.
5. Método de acordo com a reivindicação 4, é CARACTERIZADO pelo fato de que o pedido de re-envio é gerado de acordo com o protocolo RTSP (Real Time Streaming Protocolo/Protocolo de Fluxo em Tempo Real).
6. Método de acordo com a reivindicação 4, é CARACTERIZADO pelo fato de que o pedido de re-envio é implementado por um par de mensagens PAUSE/PLAY RTSP.
7. Método de acordo com a reivindicação 1, é CARACTERIZADO pelo fato de que o fluxo de mídia é armazenado temporariamente em um meio de armazenagem temporária (240), tal como uma memória, no dispositivo cliente (101) antes de reproduzir.
8. Método de acordo com a reivindicação 7, é CARACTERIZADO pelo fato de que o meio de armazenagem temporária (240) tem um tamanho maior no tempo do que o período de re-seleção da célula.
9. Método de acordo com a reivindicação 7, é CARACTERIZADO pelo fato de que o servidor de fluxo é solicitado para enviar o fluxo de mídia a uma taxa mais alta do que a taxa de reprodução desta mídia, de forma a aumentar o grau máximo do dispositivo de armazenagem temporária (240).
10. Método de acordo com a reivindicação 9, é CARACTERIZADO pelo fato de que a largura de banda ou a taxa de bit de transmissão desejada com o fator de velocidade é comunicada para o servidor de fluxo (111) em um pedido.
11. Método de acordo com a reivindicação 9, é CARACTERIZADO pelo fato de que o fluxo de mídia é armazenado no dispositivo cliente móvel (101) em uma taxa mais elevada do que a taxa de reprodução.
12. Método de acordo com a reivindicação 9, é CARACTERIZADO pelo fato de que o servidor de fluxo (111) é subsequentemente solicitado para resumir uma configuração original.
13. Método de acordo com a reivindicação 7, é CARACTERIZADO pelo fato de que o grau máximo de armazenagem temporária (240) diminui durante a re-seleção da célula, e o servidor de fluxo é solicitado para enviar o fluxo de mídia não recebido embora a armazenagem temporária (240) não tenha sido totalmente esvaziada, e a solicitação é executada sem a reprodução de pausa no dispositivo cliente móvel (101).
14. Método de acordo com a reivindicação 1, é CARACTERIZADO pelo fato de que o servidor de fluxo tem um grupo de fluxos de mídia disponíveis para transmissão, no qual o mesmo conteúdo de mídia tem sido codificado em diferentes taxas de bits.
15. Método de acordo com a reivindicação 14, é CARACTERIZADO pelo fato de que a informação no grupo de fluxos de mídia disponível é anteriormente comunicada ao dispositivo cliente móvel (101) no estabelecimento da sessão de fluxo.
16. Método de acordo com a reivindicação 15, é CARACTERIZADO pelo fato de que o servidor de fluxo (111) é solicitado para comutar o envio de um fluxo de mídia de taxa de bit mais elevada para o envio de um fluxo de mídia de taxa de bit baixa em uma velocidade aumentada.
17. Método de acordo com as reivindicações 1 a 16, é CARACTERIZADO pelo fato de que o fluxo de mídia compreende um dos a seguir: um fluxo de vídeo, um fluxo de áudio, um outro fluxo de mídia simples, um fluxo de multimídia.
18. Método de acordo com as reivindicações 1 a 17, é CARACTERIZADO pelo fato de que o servidor de fluxo (111) envia o fluxo de mídia para o cliente dispositivo móvel (101) através da rede de comunicação móvel.
19. Método de acordo com as reivindicações 1 a 18, é CARACTERIZADO pelo fato de que a rede de comunicação móvel compreende uma rede de rádio pacote móvel, tal como a rede GPRS (General Packet Radio Service/Serviço Geral de Rádio Pacote).
20. Método de acordo com as reivindicações 1 a 19, é C ARACTE RIZ ADO pelo fato de que a re-seleção da célula é executada entre duas estações base (BS1, BS2), que são selecionadas de um grupo compreendendo: as estações base que pertencem ao sistema GPRS, e as estações base que pertencem ao sistema de comunicação móvel de terceira geração.
21. Dispositivo cliente móvel (101) para receber o fluxo de mídia do servidor de fluxo (111) em uma interface aérea é CARACTERIZADO pelo fato de que compreende: - meios para receber fluxo de mídia enviado do servidor de fluxo (111); - meios para detectar um evento de re-seleção da célula no dispositivo cliente móvel; e - meios para solicitar em resposta ao evento de re-seleção de célula detectado, com um pedido de protocolo de transmissão em tempo real ao servidor de fluxo (111) para enviar o fluxo de mídia que o dispositivo cliente móvel (101) deixou de receber devido à re-seleção da célula em uma sessão contínua de transmissão.
22. Servidor de fluxo (111) para enviar o fluxo de mídia para o dispositivo cliente móvel (101) em uma interface aérea é CARACTERIZADO pelo fato de que compreende: - meios para enviar fluxo de mídia para o dispositivo cliente móvel; - meios para receber um pedido de protocolo de transmissão em tempo real solicitando ao servidor de fluxo (111) para enviar o fluxo de mídia que o dispositivo cliente móvel (101) deixou de receber devido à re-seleção da célula em uma sessão contínua de transmissão, sendo o pedido enviado em resposta à detecção de um evento de re-seleção da célula no dispositivo cliente móvel; e - meios para atuar no pedido recebido.
23. Sistema compreendendo um servidor de fluxo (111) e um dispositivo cliente móvel (101), para transmitir o fluxo de mídia do servidor de fluxo (111) para o dispositivo cliente móvel (101) na interface aérea, o sistema é CARACTERIZADO pelo fato de que o dispositivo cliente móvel (101) compreende: - meios para receber fluxo de mídia enviado do servidor de fluxo (111); - meios para detectar um evento de re-seleção da célula no dispositivo cliente móvel; e - meios para solicitar em reposta ao evento de re-seleção da célula detectado, com um pedido de protocolo de transmissão em tempo real ao servidor de fluxo (111) para enviar o fluxo de mídia que o dispositivo cliente móvel (101) deixou de receber devido à re-seleção da célula em uma sessão contínua de transmissão; O sistema também compreende, no servidor de fluxo (111): - meios para enviar fluxo de mídia para o dispositivo cliente móvel; - meios para receber referido pedido de protocolo de transmissão em tempo real; e- meios para atuar no pedido recebido.
BRPI0315207-3A 2002-10-14 2003-10-10 Method and system for transmitting the media flow from a flux server to the mobile client, flow server, mobile client. BRPI0315207B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI20021820 2002-10-14
FI20021820A FI116816B (fi) 2002-10-14 2002-10-14 Median suoratoisto
PCT/FI2003/000752 WO2004036824A1 (en) 2002-10-14 2003-10-10 Streaming media

Publications (1)

Publication Number Publication Date
BRPI0315207B1 true BRPI0315207B1 (pt) 2017-12-26

Family

ID=8564746

Family Applications (2)

Application Number Title Priority Date Filing Date
BR0315207-3A BR0315207A (pt) 2002-10-14 2003-10-10 Método e sistema para transmitir o fluxo de mìdia de um servidor de fluxo para o cliente móvel, servidor de fluxo, cliente móvel, e, programa de computador
BRPI0315207-3A BRPI0315207B1 (pt) 2002-10-14 2003-10-10 Method and system for transmitting the media flow from a flux server to the mobile client, flow server, mobile client.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
BR0315207-3A BR0315207A (pt) 2002-10-14 2003-10-10 Método e sistema para transmitir o fluxo de mìdia de um servidor de fluxo para o cliente móvel, servidor de fluxo, cliente móvel, e, programa de computador

Country Status (12)

Country Link
US (1) US7733830B2 (pt)
EP (1) EP1552644B1 (pt)
JP (1) JP4287376B2 (pt)
KR (1) KR100705432B1 (pt)
CN (1) CN1706146B (pt)
AU (1) AU2003278207A1 (pt)
BR (2) BR0315207A (pt)
CA (1) CA2500781A1 (pt)
FI (1) FI116816B (pt)
MY (1) MY143014A (pt)
TW (1) TWI248740B (pt)
WO (1) WO2004036824A1 (pt)

Families Citing this family (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
EP1552617A2 (en) 2002-10-05 2005-07-13 Digital Fountain, Inc. Systematic encoding and decoding of chain reaction codes
CN1954501B (zh) 2003-10-06 2010-06-16 数字方敦股份有限公司 通过通信信道接收从源发射的数据的方法
US7440430B1 (en) * 2004-03-30 2008-10-21 Cisco Technology, Inc. Jitter buffer management for mobile communication handoffs
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
JP4971144B2 (ja) 2004-05-07 2012-07-11 デジタル ファウンテン, インコーポレイテッド ファイルダウンロードおよびストリーミングのシステム
JP4428161B2 (ja) * 2004-07-16 2010-03-10 ブラザー工業株式会社 接続状態制御装置、接続状態制御方法及び接続状態制御用プログラム
JP4389216B2 (ja) * 2004-11-15 2009-12-24 株式会社カシオ日立モバイルコミュニケーションズ 移動通信端末およびコンテンツ再生方法
US8218439B2 (en) * 2004-11-24 2012-07-10 Sharp Laboratories Of America, Inc. Method and apparatus for adaptive buffering
US8089941B2 (en) * 2004-12-10 2012-01-03 Broadcom Corporation Mobile communication device and system supporting personal media recorder functionality
US8683066B2 (en) 2007-08-06 2014-03-25 DISH Digital L.L.C. Apparatus, system, and method for multi-bitrate content streaming
US8370514B2 (en) 2005-04-28 2013-02-05 DISH Digital L.L.C. System and method of minimizing network bandwidth retrieved from an external network
EP1911278A2 (en) * 2005-08-04 2008-04-16 Nds Limited Advanced digital tv system
US8908577B2 (en) * 2005-12-02 2014-12-09 Qualcomm Incorporated Solving IP buffering delays in mobile multimedia applications with translayer optimization
KR101292851B1 (ko) 2006-02-13 2013-08-02 디지털 파운튼, 인크. 가변적 fec 오버헤드 및 보호 구간을 이용하는 스트리밍및 버퍼링
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US7971129B2 (en) 2006-05-10 2011-06-28 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient users of the communications systems
US8355720B2 (en) * 2006-05-12 2013-01-15 Motorola Mobility Llc Application and transport adaptation for a wireless communication prior to a reselection
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
JP4722028B2 (ja) 2006-12-26 2011-07-13 富士通株式会社 データ転送システム、接近通知システム、およびデータ転送方法
US9979931B2 (en) * 2007-05-30 2018-05-22 Adobe Systems Incorporated Transmitting a digital media stream that is already being transmitted to a first device to a second device and inhibiting presenting transmission of frames included within a sequence of frames until after an initial frame and frames between the initial frame and a requested subsequent frame have been received by the second device
US8180029B2 (en) * 2007-06-28 2012-05-15 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
JP4919890B2 (ja) * 2007-07-11 2012-04-18 株式会社日立製作所 無線システム、基地局および移動局
US8813141B2 (en) 2007-08-08 2014-08-19 At&T Intellectual Properties I, L.P. System and method of providing video content
JP5027305B2 (ja) 2007-09-12 2012-09-19 デジタル ファウンテン, インコーポレイテッド 信頼できる通信を可能にするためのソース識別情報の生成および伝達
US8090867B2 (en) * 2007-10-19 2012-01-03 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8682336B2 (en) * 2007-10-19 2014-03-25 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8145780B2 (en) * 2007-10-19 2012-03-27 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8706907B2 (en) * 2007-10-19 2014-04-22 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8380874B2 (en) * 2007-10-19 2013-02-19 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8699678B2 (en) * 2007-10-19 2014-04-15 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8391312B2 (en) * 2007-10-19 2013-03-05 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8111713B2 (en) 2007-10-19 2012-02-07 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8321581B2 (en) * 2007-10-19 2012-11-27 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
WO2009084082A1 (ja) * 2007-12-27 2009-07-09 Fujitsu Limited 通信方法、通信システムおよび基地局
JP2009194688A (ja) * 2008-02-15 2009-08-27 Seiko Epson Corp 画像転送装置、画像表示装置、画像表示システム、画像データの転送方法、画像表示方法、およびコンピュータプログラム
CN101540881B (zh) * 2008-03-19 2011-04-13 华为技术有限公司 实现流媒体定位播放的方法、装置及系统
US8565740B2 (en) * 2008-05-08 2013-10-22 Blackberry Limited System and method for providing streaming data to a mobile device
US9462029B2 (en) * 2008-08-29 2016-10-04 Red Hat, Inc. Invoking serialized data streams
KR20100073168A (ko) * 2008-12-22 2010-07-01 한국전자통신연구원 합성데이터 송/수신 장치 및 방법
TWI396443B (zh) * 2008-12-22 2013-05-11 Ind Tech Res Inst 應用於網路串流之影音控制回應及頻寬調適方法與使用該方法之伺服器
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US9137026B1 (en) * 2009-04-23 2015-09-15 Sprint Communications Company L.P. Seamless service transitions for dual-network mobile devices
JP2011041018A (ja) * 2009-08-11 2011-02-24 Sony Corp 情報処理装置、情報処理方法、プログラムおよび通信端末
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
CN101729858A (zh) * 2009-12-14 2010-06-09 中兴通讯股份有限公司 一种蓝牙媒体的播放控制方法及系统
US9819840B2 (en) 2010-01-11 2017-11-14 Bryan Nunes Audio device that extracts the audio of a multimedia stream and serves the audio on a network while the video is displayed
US9438360B2 (en) * 2010-01-11 2016-09-06 Signet Media, Inc. System and method for providing an audio component of a multimedia content displayed on an electronic display device to one or more wireless computing devices
CN102148806A (zh) * 2010-02-09 2011-08-10 华为技术有限公司 网络电视的时移处理方法和系统以及网络设备、终端
US9510029B2 (en) 2010-02-11 2016-11-29 Echostar Advanced Technologies L.L.C. Systems and methods to provide trick play during streaming playback
US8516063B2 (en) 2010-02-12 2013-08-20 Mary Anne Fletcher Mobile device streaming media application
US9049497B2 (en) 2010-06-29 2015-06-02 Qualcomm Incorporated Signaling random access points for streaming video data
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9319448B2 (en) 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
TWI469606B (zh) 2012-12-10 2015-01-11 Hon Hai Prec Ind Co Ltd 流媒體分享請求系統、流媒體提供系統及其方法
EP2750447A1 (en) * 2012-12-28 2014-07-02 Alcatel Lucent Neighboring cell selection for an user equipment using a content delivery service in a mobile network
US9883546B2 (en) 2015-09-04 2018-01-30 Apple Inc. Postponing a resending of a data service request
JP6772218B2 (ja) * 2018-06-29 2020-10-21 Line株式会社 プログラム、情報処理方法、端末
JP6906126B2 (ja) * 2018-06-29 2021-07-21 Line株式会社 プログラム、情報処理方法、端末
WO2020026242A1 (en) * 2018-08-01 2020-02-06 Ichannel.Io Ltd. A system for management of a plurality of rendering machines to avoid transmission failures
US11588876B2 (en) * 2020-06-16 2023-02-21 T-Mobile Usa, Inc. Device-side playback restrictions on high throughput networks
US20230101262A1 (en) * 2021-09-29 2023-03-30 At&T Intellectual Property I, L.P. Application-level network slicing for high quality of experience

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5864578A (en) * 1996-04-29 1999-01-26 Golden Bridge Technology, Inc. Matched filter-based handoff method and apparatus
FI109503B (fi) 1997-04-15 2002-08-15 Nokia Corp Pakettien menetyksen estäminen pakettipohjaisen tietoliikenneverkon handoverissa sekä handovermenetelmä
JP3337062B2 (ja) * 1997-11-21 2002-10-21 日本電気株式会社 無線データ転送方法及びそのシステム
JPH11187367A (ja) 1997-12-19 1999-07-09 Nec Corp 映像送信装置,映像受信装置及びこれらを用いた映像伝送システム
US8341662B1 (en) * 1999-09-30 2012-12-25 International Business Machine Corporation User-controlled selective overlay in a streaming media
AU1065601A (en) 1999-10-18 2001-04-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for the wireless transmission of loss sensitive data
US6665726B1 (en) * 2000-01-06 2003-12-16 Akamai Technologies, Inc. Method and system for fault tolerant media streaming over the internet
US6360099B1 (en) * 2000-06-09 2002-03-19 Motorola, Inc. Reducing audio gaps during a communication network handoff
EP1182875A3 (en) 2000-07-06 2003-11-26 Matsushita Electric Industrial Co., Ltd. Streaming method and corresponding system
FI113323B (fi) * 2000-08-21 2004-03-31 Nokia Corp Datapakettinumeroiden synkronointi pakettivälitteisessä tiedonsiirrossa
CA2428325C (en) 2000-11-29 2011-08-30 Matthew David Walker Transmitting and receiving real-time data
EP1261204A2 (en) 2001-03-29 2002-11-27 Matsushita Electric Industrial Co., Ltd. Method and apparatus for data reproduction
US7058035B2 (en) * 2001-06-29 2006-06-06 Qualcomm, Indorporated Communication system employing multiple handoff criteria
US7200402B2 (en) * 2001-07-03 2007-04-03 Hewlett-Packard Development Company, L.P. Method for handing off streaming media sessions between wireless base stations in a mobile streaming media system
US6954456B2 (en) * 2001-12-14 2005-10-11 At & T Corp. Method for content-aware redirection and content renaming
US20030114158A1 (en) * 2001-12-18 2003-06-19 Lauri Soderbacka Intersystem handover of a mobile terminal
US20040008688A1 (en) * 2002-07-11 2004-01-15 Hitachi, Ltd. Business method and apparatus for path configuration in networks

Also Published As

Publication number Publication date
MY143014A (en) 2011-02-14
TWI248740B (en) 2006-02-01
KR20050065592A (ko) 2005-06-29
CA2500781A1 (en) 2004-04-29
CN1706146A (zh) 2005-12-07
EP1552644A1 (en) 2005-07-13
EP1552644B1 (en) 2016-12-28
US7733830B2 (en) 2010-06-08
WO2004036824A1 (en) 2004-04-29
TW200406108A (en) 2004-04-16
FI20021820A (fi) 2004-04-15
BR0315207A (pt) 2005-08-16
FI116816B (fi) 2006-02-28
CN1706146B (zh) 2010-10-13
FI20021820A0 (fi) 2002-10-14
AU2003278207A1 (en) 2004-05-04
KR100705432B1 (ko) 2007-04-09
JP4287376B2 (ja) 2009-07-01
JP2006503463A (ja) 2006-01-26
US20040071088A1 (en) 2004-04-15

Similar Documents

Publication Publication Date Title
BRPI0315207B1 (pt) Method and system for transmitting the media flow from a flux server to the mobile client, flow server, mobile client.
JP4927333B2 (ja) 帯域幅適応
JP3631439B2 (ja) 非信頼ネットワークにおけるデータ伝送方法及び装置
BRPI0407059B1 (pt) Aparelho de controle de comunicação, aparelho de terminal de comunicação, aparelho de servidor, e método de controle de comunicação
JP2010154547A (ja) パケット化データのビットレートの適合化とデータパケットの再送信との間の連携
US9525874B2 (en) Transmitting apparatus and transmission method
WO2004028095A1 (en) Bandwidth adaptation
BR112017001040B1 (pt) Redução do atraso na telefonia por vídeo
US8532062B2 (en) Wireless communication apparatus
US20110019580A1 (en) Wireless communication apparatus
WO2006086691A2 (en) A network for providing a streaming service
JP2002290974A (ja) 伝送レート制御方法
Waltermann et al. A technique for seamless VoIP-codec switching in next generation networks
BRPI0904441A2 (pt) método e aparelho para a recepção de conteúdo
KR101055169B1 (ko) 스트리밍 시스템의 트래픽 제어 방법 및 그 장치
JP2004186793A (ja) ストリーミング配信装置、ストリーミング端末装置、ストリーミング配信システム、及びストリーミング配信方法
JP2003006087A (ja) 情報処理装置および方法、プログラム、並びに記録媒体
WO2022002003A1 (zh) 信息确定方法及设备
JPH11205390A (ja) 伝送システム、端末装置、サーバ装置及び記録媒体