BR112014017357B1 - Método e entidade móvel para comunicação sem fio, e memória legível por computador - Google Patents

Abstract

MÉTODO E SISTEMA PARA TRANSIÇÕES DE RECEPÇÕES DE SERVIÇO DE DASH DE BROADCAST ENTRE UNICAST E BROADCAST. Técnicas são providas para receber uma ou mais representações de conteúdo sem fio. O método pode envolver receber uma descrição de apresentação de mídia (MPD), que inclui parâmetros para a recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast (2312). O método pode envolver determinar se a transmissão de broadcast ou a transmissão de unicast é apropriada para a recepção dos segmentos de dados (2314), e selecionar uma determinada representação dentre as múltiplas representações do conteúdo com base em um critério da entidade móvel (2316). O método pode envolver a recepção dos segmentos de dados para a dada representação com base, pelo menos em parte nos parâmetros para a determinada transmissão da transmissão de broadcast e transmissão de unicast (2318).

Description

Referência Cruzada a Pedidos Relacionados

[0001] O presente pedido de patente reivindica prioridade aos seguintes Pedidos Provisórios: No. 61/587,103, depositado em 16 de janeiro de 2012, intitulado "METHOD AND SYSTEM FOR TRANSMISSIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST E BROADCAST"; NO. 61/623,965, depositado em 13 de abril de 2012, intitulado "METHOD AND SYSTEM FOR TRANSMISSIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST E BROADCAST"; No. 61/646,873, depositado em 14 de maio de 2012, intitulado "METHOD AND SYSTEM FOR TRANSMISSIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST E BROADCAST"; e No. 61/719,936, depositado em 29 de outubro de 2012, intitulado "METHOD AND SYSTEM FOR TRANSMISSIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST E BROADCAST"; os quais são atribuídos à cessionária e aqui expressamente incorporados na sua totalidade para referência.

ANTECEDENTES Campo

[0002] Aspectos da presente divulgação referem-se geralmente a sistemas de comunicação sem fio, e, mais particularmente, a gerenciamento de Streaming Adaptativo Dinâmico sobre serviço HTTP (DASH).

Antecedentes

[0003] Redes de comunicação sem fio são amplamente utilizadas para prover vários serviços de comunicação, tais como voz, vídeo, dados em pacotes, troca de mensagens, broadcast, etc. Estas redes sem fio podem ser redes de acesso múltiplo capazes de suportar vários usuários compartilhando os recursos de rede disponíveis. Exemplos de tais redes de acesso múltiplo incluem redes de Acesso Múltiplo por Divisão de Código (CDMA), redes de Acesso Múltiplo por Divisão de Tempo (TDMA), redes de Acesso Múltiplo por Divisão de Frequência (FDMA), redes FDMA Ortogonal (OFDMA), e redes FDMA de Portadora Única (SC-FDMA).

[0004] Uma rede de comunicação sem fio pode incluir várias estações base, que podem suportar comunicação de vários equipamentos de usuário (UEs), também referidos como entidades móveis. Um UE pode se comunicar com uma estação base através de um downlink e de um uplink. O downlink (ou link direto) refere-se ao link de comunicação da estação base para o UE, e o uplink (ou link reverso) refere-se ao link de comunicação do UE para a estação base. Tal como aqui utilizado, uma "estação base" significa uma eNó B (eNB), um Nó B, um nó B nativo, ou componente de rede semelhante de um sistema de comunicações sem fio.

[0005] Evolução de Longo Prazo (LTE) do Projeto de Parceria de 3a Geração (3GPP), representa um grande avanço na tecnologia celular tal como uma evolução do Sistema Global para Comunicações Móveis (GSM) e Sistema de Telecomunicações Móveis Universal (UMTS). A camada física LTE (PHY) provê uma maneira altamente eficiente para transmitir ambas informação de controle e dados entre as estações base, como por exemplo um Nó B evoluído (eNBs), e as entidades móveis, tais como UEs. Nos pedidos anteriores, um método para facilitar a comunicação de largura de banda elevada para multimídia tem sido a operação de rede de frequência única (SFN). SFNs utilizam rádio transmissores, tais como, por exemplo, eNBs, para se comunicar com UEs assinantes. Em operação unicast, cada eNB é controlado de modo a transmitir sinais portando informação dirigida para um ou mais UEs assinantes particulares. A especificidade da sinalização unicast permite serviços de pessoa-para-pessoa, tais como, por exemplo, chamadas de voz, mensagens de texto ou vídeo chamada.

[0006] Streaming Adaptativo Dinâmico sobre HTTP (DASH) permite serviços que entregam conteúdo de mídia contínuo (streaming) sobre Protocolo de Transferência de Hipertexto (HTTP), que é um protocolo de transporte unicast. A entrega unicast e broadcast simultânea de conteúdo DASH e a manipulação de transições entre entrega de unicast e broadcast, e vice-versa não está totalmente definido. Latências associadas com a entrega de broadcast também oferecem novos desafios para essas transições. Informações sobre o ajuste de disponibilidade de broadcast (por exemplo, retardo ou adiantamento em disponibilidade) é dependente da implementação da rede e deve ser disponibilizado para a entidade móvel para conseguir transições ininterruptas entre entrega unicast e broadcast. Informações relativas à entrega de segmentos DASH via broadcast pode ter de ser entregue a clientes DASH, onde tais informações podem incluir: restrições geográficas na recepção de versões unicast do conteúdo; informação na qual a representação do conteúdo está disponível via broadcast em uma área determinada, informações para permitir a descoberta de sessões de transporte de broadcast apropriadas portando diferentes representações do mesmo conteúdo; e informação para suportar em serviços DASH sob demanda para tráfego DASH unicast off-load. Assim, também são necessárias técnicas para transportar parâmetros que suportam entrega de broadcast sem afetar as características unicast básicas de DASH.

SUMÁRIO

[0007] Modalidades ilustrativas da presente invenção que são mostradas nos desenhos encontram-se resumidas abaixo. Estas e outras modalidades são descritas mais detalhadamente na seção de descrição detalhada. Deve ser entendido, contudo, que não há intenção de limitar a invenção às formas descritas neste Sumário da Invenção ou na descrição detalhada.

[0008] Deve ser notado que broadcast e multicast são sinônimos, tal como aqui utilizado. Note-se ainda que, em algumas redes broadcast, conteúdo de fluxo de broadcast também pode ser disponibilizado e acessado via unicast. Tal entrega alternativa de conteúdo provê uma técnica de fallback unicast para acessar o conteúdo para um serviço de streaming de broadcast quando não estiver em cobertura broadcast. Uma questão é que um serviço DASH de broadcast pode entregar diferentes versões do conteúdo (por exemplo, diferentes representações) em locais diferentes. Também é possível que diferentes representações só possam estar disponíveis via broadcast, ou apenas disponível via unicast, ou disponível tanto via unicast e broadcast.

[0009] De acordo com um ou mais aspectos das modalidades aqui descritas, é proporcionado um método operável por uma entidade móvel no sistema de comunicação sem fio. O método pode envolver receber uma descrição de apresentação de mídia (MPD), que inclui parâmetros para a recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O método pode envolver a determinação de se a transmissão de broadcast ou a transmissão de unicast é apropriada para a recepção dos segmentos de dados. O método pode envolver a seleção de uma dada representação dentre as múltiplas representações do conteúdo com base no critério da entidade móvel. O método pode envolver a recepção dos segmentos de dados para a dada representação com base pelo menos em parte nos parâmetros para a transmissão determinada da transmissão de broadcast e transmissão de unicast. Em aspectos conexos, um dispositivo eletrônico (por exemplo, uma entidade móvel ou componente (s) do mesmo) pode ser configurado para executar a metodologia acima descrita.

[0010] De acordo com um ou mais aspectos das modalidades aqui descritas, é proporcionado um outro método operável por uma entidade móvel. O método pode envolver receber informação de sistema, que inclui: (a) uma MPD DASH; e (b) parâmetros para recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O método pode envolver a seleção de uma dada representação dentre as múltiplas representações do conteúdo com base nos parâmetros para a transmissão de broadcast e um critério da entidade móvel. O método pode envolver receber segmentos de dados para a dada representação em uma sessão de entrega de arquivo de broadcast. Em aspectos conexos, um dispositivo eletrônico (por exemplo, uma entidade móvel ou componente (s) do mesmo) pode ser configurada para executar a metodologia acima descrita.

[0011] De acordo com um ou mais aspectos das modalidades aqui descritas, é proporcionado um método operável por uma entidade de rede. O método pode envolver o envio de uma MPD que inclui parâmetros para a recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O método pode envolver receber uma solicitação de uma determinada representação do conteúdo. O método envolve o envio dos segmentos de dados para a dada representação em uma sessão de entrega de arquivo através de transmissão de broadcast ou transmissão de unicast com base pelo menos em parte nos parâmetros. Em aspectos conexos, um dispositivo eletrônico (por exemplo, uma entidade de rede ou componente (s) do mesmo) pode ser configurado para executar a metodologia acima descrita.

[0012] Para a realização do que foi exposto e fins relacionados, as uma ou mais modalidades incluem os recursos doravante integralmente descritos e particularmente apontados nas reivindicações. A descrição que se segue e dos desenhos em anexo estabelecem em detalhes certos aspectos ilustrativos de uma ou mais modalidades. Estes aspectos são indicativos, contudo, de apenas algumas das várias maneiras em que os princípios de diversas modalidades podem ser utilizados e as modalidades descritas destinam-se a incluir todos esses aspectos e os seus equivalentes.

BREVE DESCRIÇÃO DOS DESENHOS

[0013] A figura 1 é um diagrama de blocos conceitual que ilustra um exemplo de um sistema de telecomunicações.

[0014] A figura 2 é um diagrama de blocos conceitual que ilustra um exemplo de uma estrutura de quadro de downlink em um sistema de telecomunicações.

[0015] A figura 3 é um diagrama de blocos conceitual que ilustra um desenho de uma estação base / eNB e um UE configurado de acordo com um aspecto da presente divulgação.

[0016] A figura 4 é um diagrama de um quadro de sinalização ilustrando um exemplo de alocação de símbolo para sinais unicast e multicast.

[0017] A figura 5 é um diagrama que ilustra MBMS sobre áreas de Rede de Única Frequência (MBSFN) dentro de uma área de serviço MBSFN.

[0018] A figura 6 é um diagrama de blocos que ilustra componentes de um sistema de comunicação sem fio para prover ou suportar serviço MBSFN.

[0019] A figura 7 ilustra uma modalidade de uma MPD DASH.

[0020] A figura 8 ilustra uma modalidade de um BaseURL em uma MPD DASH.

[0021] A figura 9 ilustra uma modalidade de uma descrição de bundle em USD eMBMS.

[0022] A figura 10A ilustra uma modalidade de uma USD para eMBMS.

[0023] A figura 10B ilustra uma outra modalidade de uma USD para eMBMS.

[0024] A figura 11 ilustra uma modalidade de uma descrição deliveryMethod no USD eMBMS

[0025] A figura 12 ilustra uma modalidade de múltiplas BaseURLs ao nível MPD.

[0026] A figura 13 ilustra uma modalidade de um cronograma de disponibilidade de segmento DASH.

[0027] A figura 14 mostra um exemplo de consideração implícita em um período de proteção.

[0028] A figura 15 mostra um exemplo de cronograma para uma transição UC-BC.

[0029] A figura 16 mostra exemplos de diferentes retardos de reprodução para segmentos buscados de unicast.

[0030] A figura 17 mostra exemplos de diferentes retardos de reprodução para segmentos buscados de broadcast.

[0031] A figura 18 mostra um exemplo de cronograma para uma transição BC-UC.

[0032] A figura 19 ilustra a reprodução de segmento com base nos segmentos buscados de broadcast versus unicast.

[0033] A figura 20 ilustra várias transmissões de broadcast para um único serviço.

[0034] A figura 21 ilustra transporte de parâmetros através de sequências de XML para múltiplas transmissões de broadcast para um único serviço.

[0035] A figura 22A ilustra um exemplo de metodologia executável por uma entidade móvel.

[0036] As figuras 22B-D mostram outros aspectos da metodologia da figura 22A.

[0037] A figura 23 mostra uma modalidade de um aparelho, de acordo com a metodologia das figuras 22A-D.

[0038] A figura 24 ilustra um exemplo de metodologia executável por uma entidade móvel em um sistema sem fio.

[0039] A figura 25 mostra uma modalidade de um aparelho, de acordo com a metodologia da figura 24.

[0040] A figura 26 ilustra um exemplo de metodologia executável por uma entidade de rede de um sistema sem fio.

[0041] A figura 27 mostra uma modalidade de um aparelho, de acordo com a metodologia da figura 26.

DESCRIÇÃO DETALHADA

[0042] A descrição detalhada apresentada a seguir, em ligação com os desenhos anexos, é projetada como uma descrição de várias configurações e não se destina a representar as únicas configurações em que os conceitos aqui descritos podem ser praticados. A descrição detalhada inclui detalhes específicos para a finalidade de prover uma compreensão completa dos vários conceitos. No entanto, será evidente para os versados na técnica que estes conceitos podem ser praticados sem estes detalhes específicos. Em alguns casos, estruturas e componentes bem conhecidos são mostrados em forma de diagrama de bloco, a fim de evitar obscurecer tais conceitos.

[0043] As técnicas aqui descritas podem ser utilizadas para diferentes redes de comunicações sem fio, tais como CDMA, TDMA, FDMA, OFDMA, e SC-FDMA outras redes. Os termos "rede" e "sistema" são muitas vezes usados como sinônimos. A rede CDMA pode implementar uma tecnologia de rádio, tal como Acesso Rádio Terrestre Universal (UTRA), CDMA2000, etc. UTRA inclui CDMA de banda Larga (WCDMA) e outras variantes de CDMA. CDMA2000 cobre padrões IS-2000, IS-95 e IS-856. A rede TDMA pode implementar uma tecnologia de rádio, tal como Sistema Global para Comunicações Móveis (GSM). Uma rede OFDMA pode implementar uma tecnologia de rádio, como UTRA Evoluída (E-UTRA), Banda larga Ultra Móvel (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, etc. UTRA e E-UTRA fazem parte do Sistema Universal de Telecomunicações Móveis (UMTS). 3GPP Evolução (LTE) e LTE-Avançado (LTE-A) são novos lançamentos de UMTS que usam E-UTRA. UTRA, E-UTRA, UMTS, LTE, LTE-A e GSM são descritos em documentos de uma organização chamada "3rd Generation Partnership Project" (3GPP). CDMA2000 e UMB são descritos em documentos de uma organização chamada "3rd Generation Partnership Project 2 "(3GPP2). As técnicas aqui descritas podem ser utilizadas para as redes sem fio e tecnologias de rádio mencionadas acima, bem como outras tecnologias de redes sem fio e rádio. Para maior clareza, alguns aspectos das técnicas são descritos a seguir para LTE, e terminologia LTE é usada em grande parte da descrição que se segue.

[0044] A figura 1 mostra uma rede de comunicação sem fio 100, que pode ser uma rede de LTE. A rede sem fio 100 pode incluir vários eNBs 110 e outras entidades de rede. Um eNB pode ser uma estação que se comunica com os UEs e pode também ser referido como uma estação base, um nó B, um ponto de acesso, ou qualquer outro termo. Cada eNB 110a, 110b, 110c pode prover cobertura de comunicação para uma determinada área geográfica. Em 3GPP, o termo "célula" pode referir-se a uma área de cobertura de um eNB e/ou um subsistema eNB servindo essa área de cobertura, dependendo do contexto em que o termo é utilizado.

[0045] Um eNB pode prover cobertura para uma comunicação macrocélula, uma célula do pico, uma célula de femto, e/ou outros tipos de células. Uma célula macro pode abranger uma área geográfica relativamente grande (por exemplo, vários quilômetros de raio) e pode permitir o acesso irrestrito por UEs com assinatura de serviço. Uma célula pico pode abranger uma área geográfica relativamente pequena e pode permitir o acesso irrestrito por UEs com assinatura de serviço. Uma célula femto pode abranger uma área geográfica relativamente pequena (por exemplo, uma casa) e pode permitir o acesso restrito por UEs tendo associação com a célula femto (por exemplo, UEs em um Assinante de Grupo Fechado (CSG), UEs para usuários em casa, etc.). Um eNB para uma célula macro pode ser referido como um eNB macro. Um eNB para uma célula pico pode ser referido como um eNB pico. Um eNB para uma célula femto pode ser referido como um eNB femto ou um eNB nativo (RNT). No exemplo mostrado na figura 1, os eNBs 110a, 110b e 110c podem ser eNBs macro para as células macro 102a, 102b e 102C, respectivamente. O eNB 110x pode ser um eNB pico para uma célula pico 102X, servindo um EU 120x. Os eNBs 110y e 110z podem ser eNBs femto para as células femto 102y e 102z, respectivamente. Um eNB pode suportar uma ou múltiplas (por exemplo, três) células.

[0046] A rede sem fio 100 também pode incluir estações retransmissoras 110r. A estação retransmissora é uma estação que recebe uma transmissão de dados e/ou outras informações de uma estação a montante (por exemplo, um eNB ou um UE) e envia uma transmissão de dados e/ou outra informação para uma estação a jusante (por exemplo, um UE ou um eNB). A estação retransmissora pode também ser um UE que passa as transmissões para outros UEs. No exemplo mostrado na figura 1, uma estação retransmissora 110r pode se comunicar com o eNB 110a e um UE 120r, a fim de facilitar a comunicação entre o eNB 110a e o UE 120r. Uma estação retransmissora pode também ser referida como um eNB retransmissor, um retransmissor, etc.

[0047] A rede sem fio 100 pode ser uma rede heterogênea que inclui eNBs de diferentes tipos, por exemplo, eNBs macro, eNBs pico, eNBs femto, retransmissores, etc. Estes diferentes tipos de eNBs podem ter diferentes níveis de potência de transmissão, áreas de cobertura diferentes, e impacto diferente sobre a interferência na rede sem fio 100. Por exemplo, eNBs macro podem ter um alto nível de potência de transmissão (por exemplo, 20 Watts), enquanto eNBs pico, eNBs femto e retransmissores podem ter um nível mais baixo de potência de transmissão (por exemplo, 1 Watt).

[0048] A rede sem fio 100 pode suportar operação síncrona ou assíncrona. Para a operação síncrona, os eNBs podem ter temporização de quadro semelhante e transmissões de diferentes eNBs podem ser aproximadamente alinhadas no tempo. Para o funcionamento assíncrono, os eNBs podem ter temporização de quadro diferente, e transmissões de diferentes eNBs não podem ser alinhadas no tempo. As técnicas aqui descritas podem ser utilizadas para ambas as operações síncrona e assíncrona.

[0049] Um controlador de rede 130 pode se acoplar a um conjunto de eNBs e prover coordenação e controle para esses eNBs. O controlador de rede 130 pode se comunicar com os eNBs 110 através de um canal de transporte de retorno (backhaul). Os eNBs 110 também podem se comunicar uns com os outros, por exemplo, direta ou indiretamente, através de canal de transporte de retorno sem fio ou fixo.

[0050] Os UEs 120 podem estar dispersos por toda a rede sem fio 100, e cada UE pode ser fixo ou móvel. Um UE pode também ser referido como um terminal, uma estação móvel, uma unidade de assinante, uma estação, etc. Um UE pode ser um telefone celular, um assistente pessoal digital (PDA), um modem sem fio, um dispositivo de comunicação sem fio, um dispositivo portátil, um computador portátil, um telefone sem fio, uma estação de loop local sem fio (WLL), ou outras entidades móveis. O UE pode ser capaz de se comunicar com eNBs macro, eNBs pico, eNBs femto, retransmissores, ou outras entidades de rede. Na figura 1, uma linha cheia com setas duplas indica transmissões desejadas entre um UE e um eNB de serviço, que é um eNB designado para servir o UE no downlink e/ou uplink. Uma linha tracejada com setas duplas indica que transmissões interferentes entre um UE e um eNB.

[0051] LTE utiliza a multiplexação por divisão de frequência ortogonal (OFDM) no downlink e multiplexação por divisão de frequência de única portadora (SC-FDM) no uplink. OFDM e SC-FDM dividem a largura de banda de sistema em várias (K) subportadoras ortogonais, que também são comumente referidas como tons, faixas, etc. Cada subportadora pode ser modulada com dados. Em geral, os símbolos de modulação são enviados no domínio da frequência com OFDM e no domínio do tempo com SC-FDM. O espaçamento entre subportadoras adjacentes pode ser fixo, e o número total de subportadoras (K) pode ser dependente da largura de banda de sistema. Por exemplo, K pode ser igual a 128, 256, 512, 1024 ou 2048 para a largura de banda de sistema de 1,25, 2,5, 5, 10 ou 20 megahertz (MHz), respectivamente. A largura de banda de sistema pode também ser dividida em sub-bandas. Por exemplo, uma sub-banda pode abranger 1,08 MHz, e pode haver 1, 2, 4, 8 ou 16 sub-bandas para a largura de banda de sistema de 1,25, 2,5, 5, 10 ou 20 MHz, respectivamente.

[0052] A figura 2 mostra uma estrutura de quadro de downlink usado em LTE. O cronograma de transmissão para o downlink pode ser subdividido em unidades de quadros de rádio. Cada quadro de rádio pode ter uma duração predeterminada (por exemplo, 10 milissegundos (ms)) e pode ser dividido em 10 subquadros com índices de 0 a 9. Cada subquadro pode incluir duas partições. Cada quadro de rádio pode, assim, incluir 20 partições com índices de 0 a 19. Cada partição pode incluir L períodos de símbolo, por exemplo, 7 períodos de símbolo para um prefixo cíclico normal (CP), como mostrado na figura 2, ou 6 períodos de símbolo para um prefixo cíclico prolongado. O CP normal e o CP prolongado podem ser aqui referidos como diferentes tipos de CP. Aos 2L períodos de símbolo, em cada subquadro podem ser atribuídos índices de 0 a 2L-1. Os recursos de frequência de tempo disponíveis podem ser divididos em blocos de recursos. Cada bloco de recursos pode cobrir subportadoras N (por exemplo, 12 subportadoras) em uma partição.

[0053] Em LTE, um eNB pode enviar um sinal de sincronização primário (PSS) e um sinal de sincronização secundário (SSS) para cada célula no eNB. Os sinais de sincronização primário e secundário podem ser enviados em períodos de símbolo de 6 e 5, respectivamente, em cada um dos subquadros 0 e 5 de cada quadro de rádio com o prefixo clico normal, como mostrado na figura 2. Os sinais de sincronização podem ser usados por UEs para a detecção de células e aquisição. O eNB pode enviar um Canal de Broadcast Físico (PBCH) em períodos de símbolo 0 a 3 na partição 1 de subquadro 0. O PBCH pode portar algumas informações do sistema.

[0054] O eNB pode enviar um Canal Indicador de Formato de Controle Físico (PCFICH) em apenas uma porção do primeiro período de símbolo de cada subquadro, embora descrita em todo o primeiro período de símbolo na figura 2. O PCFICH pode transmitir o número de períodos de símbolo (M) utilizados para canais de controle, em que M pode ser igual a 1, 2 ou 3 e pode mudar de subquadro para subquadro. M pode também ser igual a 4, para uma largura de banda de sistema pequena, por exemplo, com menos do que 10 blocos de recursos. No exemplo mostrado na figura 2, M = 3. O eNB pode enviar um Canal Físico Indicador de HARQ (PHICH) e um Canal Físico de Controle de Downlink (PDCCH) nos primeiros M períodos de símbolo de cada subquadro (M = 3 na figura 2). O PHICH pode transportar informações para suportar a retransmissão automática híbrida (HARQ). O PDCCH pode portar informações sobre a alocação de recursos para UEs e informação de controle para os canais de downlink. Embora não seja mostrado no primeiro período de símbolo na figura 2, compreende-se que o PDCCH e PHICH também estão incluídos no primeiro período de símbolo. Da mesma forma, o PHICH e PDCCH também estão ambos nos segundo e terceiro períodos de símbolo, embora não seja mostrado desta forma na figura 2. O eNB pode enviar um Canal Físico Compartilhado de Downlink (PDSCH) nos períodos de símbolos remanescentes de cada subquadro. O PDSCH pode portar dados para UEs programados para a transmissão de dados no downlink. Os vários sinais e canais em LTE são descritos em 3GPP TS 36,211, intitulado "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation", que está disponível publicamente.

[0055] O eNB pode enviar o PSS, SSS e PBCH no centro de 1,08 MHz de largura de banda de sistema utilizado pelo eNB. O eNB pode enviar o PCFICH e PHICH ao longo de toda a largura de banda de sistema em cada período de símbolos, em que estes canais são enviados. O eNB pode enviar PDCCH para grupos de UEs em certas porções da largura de banda de sistema. O eNB pode enviar o PDSCH para UEs específicos em porções específicas da largura de banda de sistema. O eNB pode enviar o PSS, SSS, PBCH, PCFICH e PHICH de uma forma de broadcast para todos os UEs, pode enviar o PDCCH de forma unicast para UEs específicos, e pode também enviar o PDSCH de forma unicast para UEs específicos.

[0056] Uma série de elementos de recursos pode estar disponível em cada período de símbolo. Cada elemento de recurso pode cobrir uma subportadora de um período de símbolo e pode ser usado para enviar um símbolo de modulação, que pode ser um valor real ou complexo. Elementos de recursos não utilizados para um sinal de referência em cada período de símbolo podem ser dispostos em grupos de elementos de recurso (REGs). Cada REG pode incluir quatro elementos de recursos em um período de símbolo. O PCFICH pode ocupar quatro REGs, que podem ser espaçados aproximadamente na mesma proporção em frequência, em período de símbolo 0. The PHICH pode ocupar três REGs, que podem ser distribuídos em frequência, em um ou mais períodos de símbolo configuráveis. Por exemplo, os três REGs para o PHICH podem todos pertencer a período de símbolo 0 ou podem ser espalhados em períodos de símbolo 0, 1 e 2. PDCCH pode ocupar 9, 18, 32 ou 64 REGs, que podem ser selecionados dentre os REGs disponíveis, nos primeiros períodos de símbolo M. Somente certas combinações de REGs podem ser permitidas para o PDCCH.

[0057] O UE pode conhecer os REGs específicos utilizados para o PHICH e o PCFICH. O UE pode buscar diferentes combinações de REGs para o PDCCH. O número de combinações a buscar é tipicamente menor do que o número de combinações permitidas para PDCCH. Um eNB pode enviar PDCCH ao UE em qualquer uma das combinações que o UE buscar.

[0058] O UE pode estar dentro da cobertura de múltiplos eNBs. Um desses eNBs pode ser selecionado para servir o UE. O eNB de serviço pode ser selecionado com base em vários critérios, como a energia recebida, perda de percurso, a relação sinal/ruído (SNR), etc.

[0059] A figura 3 mostra um diagrama de bloco de um projeto de uma estação base / eNB 110 e um UE 120, que pode ser uma das estações base / eNBs e um dos UEs na figura 1. Para um cenário de associação restrita, a estação base 110 pode ser o eNB macro 110c na figura 1, e o UE 120 pode ser o UE 120y. A estação base 110 pode também ser uma estação base de um outro tipo. A estação base 110 pode ser equipada com antenas 334a a 334t, e o UE 120 pode ser equipado com antenas 352a a 352r.

[0060] Na estação base 110, um processador de transmissão 320 pode receber dados de uma fonte de dados 312 e informação de controle de um controlador / processador 340. As informações de controle podem ser para o PBCH, PCFICH, PHICH, PDCCH, etc. Os dados podem ser para o PDSCH, etc. O processador 320 pode processar (por exemplo, codificar e mapear em símbolo) os dados e informações de controle para obter símbolos de dados e símbolos de controle, respectivamente. O processador 320 pode também gerar símbolos de referência, por exemplo, para o PSS, SSS, e o sinal de referência específico da célula. O processador de múltipla entrada e múltipla saída (MINO) de transmissão (TX) 330 pode executar o processamento espacial (por exemplo, pré-codificação) em símbolos de dados, os símbolos de controle, e/ou os símbolos de referência, se for o caso, e pode prover fluxos de símbolos de saída aos moduladores (SDMO) 332 a 332t. Cada modulador 332 pode processar um respectivo fluxo de símbolos de saída (por exemplo, para OFDM, etc.), para obter um fluxo de saída de amostra. Cada modulador 332 pode adicionalmente processar (por exemplo, converter para analógico, amplificar, filtrar, e realizar a conversão ascendente) o fluxo da amostra de saída para obter um sinal de downlink. Sinais de downlink de moduladores 332a a 332t podem ser transmitidos através das antenas 334a a 334t, respectivamente.

[0061] No UE 120, as antenas 352a a 352r podem receber os sinais de downlink a partir da estação base 110 e pode prover sinais recebidos dos demoduladores (DEMODs) 354a a 354r, respectivamente. Cada demodulador 354 pode condicionar (por exemplo, filtrar, amplificar, converter descendentemente e digitalizar) um respectivo sinal recebido para obter amostras de entrada. Cada demodulador 354 pode adicionalmente processar as amostras de entrada (por exemplo, para OFDM, etc.) para obter símbolos recebidos. Um detector MIMO 356 pode obter símbolos recebidos de todos os demoduladores 354a a 354r, realizar a detecção MIMO sobre os símbolos recebidos, se aplicável, e prover símbolos detectados. Um processador de recepção 358 pode processar (por exemplo, demodular, desintercalar e decodificar) os símbolos detectados, prover dados decodificados para o UE 120 a um depósito de dados 360, e prover informações de controle decodificadas a um controlador / processador 380.

[0062] No uplink, no UE 120, um processador de transmissão 364 pode receber e processar dados (por exemplo, para o PUSCH) a partir de uma fonte de dados 362 e informação de controle (por exemplo, para o PUCCH) a partir do controlador / processador 380. O processador 364 pode também gerar símbolos de referência para um sinal de referência. Os símbolos a partir do processador de transmissão 364 podem ser pré-codificados por um processador MIMO TX 366 se for o caso, adicionalmente processado pelos moduladores 354a a 354r (por exemplo, para SC-FDM, etc.), e transmitidos para a estação base 110. Na estação base 110, os sinais de uplink a partir do UE 120 podem ser recebidos pelas antenas 334, transformados pelos demoduladores 332, detectados por um detector MIMO 336 se for o caso, e adicionalmente processados por um processador de recepção 338 para obter dados decodificados e informação de controle enviada pelo UE 120. O processador 338 pode prover os dados decodificados para um depósito de dados 339 e as informações de controle decodificadas para o controlador / processador 340.

[0063] Os controladores / processadores 340 e 380 podem direcionar a operação na estação base 110 e EU 120, respectivamente. O processador 340 e/ou outros processadores e módulos na estação base 110 podem executar ou direcionar a execução de vários processos para as técnicas aqui descritas (por exemplo, ver figura 26). O processador 380 e/ou outros processadores e módulos no UE 120 podem executar ou direcionar a execução de vários processos para as técnicas aqui descritas (por exemplo, ver Figuras 22A-D e figura 24). As memórias 342 e 382 podem armazenar dados e códigos de programa na estação base 110 e no UE 120, respectivamente. Um programador pode programar UEs 344 para transmissão de dados no downlink e/ou uplink.

[0064] SINALIZAÇÃO EMBMS E UNICAST EM REDES DE FREQUÊNCIA ÚNICA: Uma técnica para facilitar a comunicação de largura de banda elevada para multimídia tem sido operação de rede de frequência única (SFN). Particularmente, Serviço Multicast Broadcast Multimídia (MBMS) e MBMS para LTE, também conhecido como MBMS evoluído (eMBMS) (incluindo, por exemplo, aquele que veio recentemente a ser conhecido como rede de frequência única de broadcast multimídia (MBSFN) no contexto LTE), pode utilizar essa operação SFN. SFN utiliza transmissores de rádio, tais como, por exemplo, eNBs, para se comunicar com UEs assinantes. Grupos de eNBs podem transmitir informação de uma maneira sincronizada, de modo que os sinais reforçam um ao outro em vez de interferir uns com os outros. No contexto da eMBMS, o conteúdo compartilhado é transmitido a partir de vários eNBs de uma rede LTE para vários UEs. Portanto, dentro de uma determinada área eMBMS, o UE pode receber sinais eMBMS de qualquer eNB (s) dentro do alcance de rádio, como parte da área de serviço do eMBMS ou área MBSFN. No entanto, para decodificar os eMBMS sinalizam cada UE que recebe informação de Canal de Controle Multicast (MCCH) proveniente de um eNB de serviço sobre um canal não eMBMS. Informação MCCH muda de tempos em tempos e notificação de alterações é fornecida através de um outro canal não eMBMS, o PDCCH. Portanto, para decodificar sinais eMBMS dentro de uma área eMBMS particular, cada UE é sinais MCCH servido e siais PDCCH por um dos eNBs na área.

[0065] De acordo com os aspectos do objeto da presente divulgação, é proporcionada uma rede sem fio (por exemplo, uma rede 3GPP), que tem características relacionadas com a otimização de portadora única para eMBMS. eMBMS provê uma maneira eficiente para transmitir conteúdo compartilhado a partir de uma rede LTE para várias entidades móveis, tais como, por exemplo, UEs.

[0066] No que diz respeito a camada física (PHY) de eMBMS para Duplexação por Divisão de Frequência LTE (FDD), a estrutura de canal pode compreender tempo particionamento de recurso de multiplexação por divisão de tempo (TDM) entre eMBMS e transmissões unicast em portadoras mistas, permitindo assim utilização de espectro flexível e dinâmico. Atualmente, um subconjunto de subquadros (até 60%), conhecido como subquadros de rede de frequência única de Broadcast multimídia (MBSFN), pode ser reservado para a transmissão de eMBMS. Como tal projeto de eMBMS atual permite, no máximo, seis vezes subquadros para eMBMS.

[0067] Um exemplo de alocação de subquadro para eMBMS é mostrado na figura 4, que mostra uma alocação existente de sinais de referência MBSFN sobre subquadro MBSFN, para um caso de única portadora. Componentes representados na figura 4 correspondem aos mostrados na figura 2, com a figura 4 mostrando as subportadoras individuais dentro de cada partição e bloco de recurso (RB). Em 3GPP LTE, um RB abrange 12 subportadoras sobre uma duração de portadora de 0,5 ms, com cada subportadora tendo uma largura de banda de 15 kHz juntamente abrangendo 180 kHz por RB. Subquadros podem ser alocados para unicast ou eMBMS; por exemplo, em uma sequência de subquadro rotulado 0, 1, 2, 3, 4, 5, 6, 7, 8 e 9, subquadros 0, 4, 5, e 9 podem ser excluídos de eMBMS em FDD. Além disso, subquadros 0, 1, 5 e 6 podem ser excluídos de eMBMS em Duplexação por Divisão de Tempo (TDD). Mais especificamente, subquadros 0, 4, 5, e 9 podem ser usados para PSS / SSS / PBCH / paging / Blocos de Informações de Sistema (SIBs) e serviço unicast. Subquadros restantes na sequência, por exemplo, subquadros 1, 2, 3, 6, 7, e 8 podem ser configurados como subquadro eMBMS.

[0068] Com referência continuada à figura 4, no interior de cada subquadro eMBMS, os primeiros um ou dois símbolos podem ser utilizados para os símbolos de referência unicast (RSs) e sinalização de controle. Um comprimento CP dos primeiros 1 ou 2 símbolos pode seguir aquele do subquadro 0. Um intervalo de transmissão pode ocorrer entre os primeiros 1 ou 2 símbolos e os símbolos eMBMS se os comprimentos CP forem diferentes. Em aspectos relacionados, a utilização de largura de banda de eMBMS geral pode ser 42,5% considerando overhead RS (por exemplo, 6 subquadros eMBMS e 2 símbolos de controle dentro de cada subquadro eMBMS). Técnicas conhecidas por prover MBSFN RSs e RSs unicast normalmente envolvem a alocação de MBSFN RSs em subquadros MBSFN (como mostrado na figura 4), e alocação de RSs unicast separadamente em subquadros não MBSFN. Mais especificamente, a figura 4 mostra, o CP estendido do subquadro MBSFN que inclui MBSFN RSs mas RSs não unicast. A tecnologia atual não se limita ao esquema de alocação particular ilustrado nas Figuras 2 e 4, que são apresentados a título de exemplo, e não como forma de limitação. Uma sessão multicast ou broadcast multicast como aqui utilizado pode utilizar qualquer plano de alocação de quadro adequado.

[0069] ÁREAS DE SERVIÇO eMBMS: A figura 5 ilustra um sistema 500 que inclui uma área de serviço de MBMS 502 englobando várias áreas MBSFN 504, 506, 508, as quais se incluem várias células ou estações base 510. Tal como aqui utilizado, uma "área de serviço MBMS " refere-se a um grupo de células de broadcast sem fio, onde um determinado serviço MBMS está disponível. Por exemplo, um determinado esporte ou outro programa pode ser transmitido por estações base na área de serviço MBMS em um determinado momento. A área onde o programa especial é transmitido define a área de serviço MBMS. A área de serviço de MBMS pode ser constituída por uma ou mais "áreas MBSFN", como mostrado em 504, 506 e 508. Tal como aqui utilizado, uma área MBSFN refere-se a um grupo de células (por exemplo, células 510) atualmente transmitindo um programa particular de forma sincronizada usando um protocolo MBSFN. Uma "zona de sincronização MBSFN" refere-se a um grupo de células que se encontram interligadas e configuradas de uma maneira tal que elas são capazes de operar em uma maneira sincronizada para transmitir um programa particular, utilizando um protocolo MBSFN, independentemente se elas estão ou não atualmente fazendo assim. Cada eNB pode pertencer a apenas uma área de sincronização MBSFN, em uma determinada camada de frequência. Vale a pena notar que uma área de serviço MBMS 502 pode incluir uma ou mais áreas de sincronização MBSFN (não mostradas). Por outro lado, uma área de sincronização MBSFN pode incluir uma ou mais áreas MBSFN ou áreas de serviço MBMS. Geralmente, uma área MBSFN é constituída por todas, ou uma porção de uma única área de sincronização MBSFN e está localizada dentro de uma única área de cobertura MBMS. Sobreposição entre diversas áreas MBSFN é suportada, e um único eNB pode pertencer a várias áreas MBSFN diferentes. Por exemplo, até 8 MCCHs independentes podem ser configurados em SIB-13 para suportar a adesão em diferentes áreas MBSFN. Uma célula reservada de área MBSFN ou Estação Base é uma célula /estação base dentro de uma área MBSFN que não contribui para a transmissão MBSFN, por exemplo, uma célula perto de um limite de área de sincronização de MBSFN, ou uma célula que não é necessária para a transmissão MBSFN por causa da sua localização.

[0070] COMPONENTES DE SISTEMA eMBMS E FUNÇÕES: A figura 6 ilustra entidades funcionais de um sistema de comunicação sem fio 600 para prover ou suportar serviço MBSFN. Em relação à qualidade de serviço (QoS), o sistema 600 usa uma Taxa de Bit Garantida (GBR) tipo portador MBMS, onde a taxa de bits máxima (MBR) é igual a GBR. Estes componentes são mostrados e descritos a título de exemplo, e não limitam os conceitos inventivos aqui descritos, que podem ser adoptados para outras arquiteturas e distribuições funcionais para administrar e controlar as transmissões multicast.

[0071] O sistema 600 pode incluir um GateWay MBMS (MBMS GW) 616. O MBMS GW 616 controla de distribuição multicast de Protocolo Internet (IP) de dados de plano de usuário MBMS para eNóBs 604 através de uma interface M1; um eNB 604 de muitos possíveis eNBs é mostrado. Além disso, o MBMS GW controla a distribuição IP multicast de dados de plano de usuário MBMS para controladores de Rede Rádio UTRAN (RNC) 620 através de uma interface M1; um UTRAN RNC 620 de muitos RNC possíveis é mostrado. A interface M1 está associada aos dados MBMS (plano de usuário) e faz uso de IP para a entrega dos pacotes de dados. O eNB 604 pode prover conteúdo MBMS a um equipamento de usuário (UE) / entidade móvel 602 através de uma interface E-UTRAN Uu. O RNC 620 pode prover conteúdo MBMS para uma entidade móvel de UE 622 através de uma interface Uu. O MBMS GW 616 pode executar adicionalmente Sinalização de Controle de Sessão de MBMS, por exemplo início da sessão MBMS e parada de sessão, através da Entidade de Gerenciamento de Mobilidade (MME) e interface de Sm 608. O MBMS GW 616 pode adicionalmente prover uma interface para entidades usando portadores MBMS pelo ponto de referência SG-mb (plano do usuário), e prover uma interface para entidades usando portadores MBMS pelo ponto de referência SGI-mb (plano de controle). A Interface SG-mb porta sinalização específica do serviço de portador MBMS. A interface SGI-mb é uma interface de plano de usuário para entrega de dados MBMS. Entrega de dados MBMS pode ser realizada por transmissão de unicast IP, que pode ser um modo padrão, ou por multicast IP. O MBMS GW 616 pode prover uma função de plano de controle para MBMS sobre UTRAN através de um Nó de Suporte de Serviço de Rádio por Pacote Geral de Serviço (SGSN) 618 e as interfaces de Sn/Iu.

[0072] O sistema 600 pode adicionalmente incluir uma entidade coordenadora Multicast (MCE) 606. A MCE 606 pode executar uma função de controle de admissão de conteúdo MBMS, e alocar recursos de rádio frequência e tempo utilizados por todos os eNBs na área de MBSFN para transmissões multicelulares MBMS usando operação MBSFN. A MCE 606 pode determinar uma configuração de rádio para uma Área MBSFN, como, por exemplo, o esquema de codificação e modulação. A MCE 606 pode programar e controlar transmissão de plano de usuário de conteúdo MBMS e gerenciar multiplexação de serviço eMBMS, determinar quais serviços devem ser multiplexados no Canal Multicast (MCH). A MCE 606 pode participar em Sinalização de Controle de Sessão MBMS com a MME 608 através de uma interface M3, e pode prover uma interface de plano de controle M2 com o eNB 604.

[0073] O sistema 600 pode adicionalmente incluir um Centro de Serviço Broadcast-Multicast (BM-SC) 612 em comunicação com um servidor de provedor de conteúdo 614. O BM-SC 616 pode lidar com o consumo de conteúdo multicast de uma ou mais fontes, tais como o provedor de conteúdo 614, e prover outras funções de gerenciamento de nível superior, conforme descrito abaixo. Essas funções podem incluir, por exemplo, uma função da sociedade, incluindo a autorização e o início de serviços MBMS para um UE identificado. O BM-SC 616 pode realizar mais uma sessão MBMS e funções de transmissão, programação de broadcast ao vivo, e entrega, incluindo MBMS e funções de distribuição associadas. O BM- SC 612 pode adicionalmente prover propaganda e descrição de serviços, tal como o conteúdo da propaganda disponível para multicast. Um contexto separado de Protocolo de Dados em Pacote (PDP) pode ser usado para portar mensagens de controle entre UE e BM-SC. O BM-SC pode adicionalmente prover funções de segurança, tais como gerenciamento chave, gerenciar o carregamento de provedores de conteúdo de acordo com parâmetros como o volume de dados e QoS, prover a sincronização de conteúdo para MBMS em UTRAN e em E-UTRAN para o modo de broadcast, e proporcionar a compressão do cabeçalho para dados MBSFN em UTRAN. O BM-SC 612 pode indicar início de sessão, atualização e parada para o MBMS- GW 616, incluindo atributos de sessão, como a área de serviço QoS e MBMS.

[0074] O sistema 600 pode adicionalmente incluir uma Entidade de Gerenciamento Multicast (MME) 608 em comunicação com o MCE 606 e MBMS-GW 616. A MME 608 pode prover uma função de plano de controle para MBMS sobre E- UTRAN. Além disso, a MME pode prover o eNB 604, 620, com a informação relacionada a multicast definida pelo MBMS-GW 616. Uma interface Sm entre o MME 608 e o MBMS GW-616 pode ser utilizada para transportar a sinalização de controle MBMS, por exemplo, início de sessão e sinais de parada.

[0075] O sistema 600 pode adicionalmente incluir um Gateway de Rede de Dados em Pacote (PDN) (GW) 610, por vezes abreviado como P-GW. O P-GW 610 pode prover uma portadora de Sistema de Pacote Evoluído (EPS) entre o UE 602 e BM-SC 612 para sinalização e/ou dados do usuário. Como tal, o P-GW pode receber solicitações baseadas em Localizador de Recurso Uniforme (URL) provenientes de UEs em associação com endereços IP designados aos UEs. O BM-SC 612 pode também ser ligado a um ou mais provedores de conteúdo por meio do P-GW 610, o qual pode se comunicar com o BM-SC 612 através de uma interface de IP.

[0076] De acordo com um ou mais aspectos das modalidades aqui descritas, é provida uma técnica para sinalizar o uso de certas URLs no suporte de direcionar acessos a Streaming Adaptativo Dinâmico Unicast sobre HTTP (DASH) para uma versão de broadcast sob demanda que o conteúdo através do atributo ServiceLocation na descrição de apresentação de mídia (MPD) para aquele conteúdo DASH. DASH permite serviços que entregam conteúdo de mídia contínua (streaming) sobre Protocolo de Transferência de Hipertexto (HTTP). As especificações para DASH definem principalmente dois formatos: a MPD e os formatos de Segmento.

[0077] A figura 7 ilustra uma modalidade 700 de uma estrutura de esquema de linguagem de marcação extensível de alto nível (XML) de uma MPD. A figura 8 ilustra um esquema 800 para ilustrar a estrutura de um BaseURL que associa um atributo ServiceLocation e ByteRange (s) com URLs base. As listas de elementos BaseURLs podem ser descritas na MPD, no período, no Conjunto de Adaptação, e nos níveis de Representação de uma MPD.

[0078] Em aspectos relacionados, BaseURLs pode desempenhar a função de identificadores de recursos uniforme de Base (URIs). URLs em cada nível de MPD podem ser resolvidas de acordo com a RFC3986 com respeito ao elemento BaseURL especificado nesse nível do documento (por exemplo, a DMP) ou a nível superior. Resolução URL aplica- se a todas as URLs encontradas em documentos da MPD, em URLs específicas para inicialização e Segmentos mídia que são ou interessam para a divulgação descrita aqui. Pode ser fornecido vários elementos BaseURL para especificar um ou mais locais comuns onde segmentos idênticos podem ser acessados. Na ausência de outros critérios, o cliente DASH pode usar o primeiro elemento BaseURL como a URL base.

[0079] Com referência à figura 8, o atributo ServiceLocation para um elemento BaseURL, especifica uma relação entre BaseURLs tal que elementos BaseURL com o mesmo valor ServiceLocation são suscetíveis de ter suas URLs resolvidas para serviços em um local de rede comum, como, por exemplo, uma Rede de Entrega de Conteúdo comum. Por exemplo, se o cliente DASH busca segmentos para uma representação (por exemplo, diferentes versões de um determinado conteúdo, como a resolução, linguagem, etc.), mas decide buscar segmentos a partir de uma representação diferente (por exemplo, porque a rede de acesso sem fio não pode continuar a suportar as exigências de representação atuais sobre a largura de banda), ele pode selecionar o BaseURL para a nova representação que tem o mesmo valor ServiceLocation que a representação anterior. Este uso do atributo ServiceLocation atua como uma dica para dispositivos indicando que buscar segmentos para a nova representação irá ter um desempenho semelhante (por exemplo, o ajuste de disponibilidade) como segmentos buscados a partir da representação anterior via BaseURLs com o mesmo valor ServiceLocation.

[0080] PROBLEMAS COM BROADCAST DASH SOBRE EMBMS: A entrega sequencial de segmentos de mídia DASH (por exemplo, arquivos de mídia), constitui um serviço de streaming de mídia que pode incluir a transmissão sequencial de arquivos de mídia ou segmentos de mídia DASH. Entrega de streaming de mídia usando a RTP também é possível, mas o transporte RTP normalmente não é adequado para segmentos DASH.

[0081] Em algumas redes de broadcast, conteúdo transmitido via broadcast também pode ser disponibilizado e acessado via unicast, como é o caso de broadcast de streaming RTP em eMBMS, por exemplo. Esta entrega alternativa de conteúdo provê uma técnica fallback unicast para acessar o conteúdo para um serviço de streaming de broadcast quando não estiver em cobertura broadcast. Uma técnica de fallback para acessar os arquivos de um serviço de entrega de arquivos de broadcast normalmente não é definida em redes de broadcast.

[0082] Uma vez que a entrega de broadcast de segmentos DASH normalmente faz uso de protocolos de transporte utilizados para os serviços de entrega de arquivos de broadcast (por exemplo, FLUTE), uma alternativa fallback unicast para acessar o conteúdo dos serviços DASH broadcast é necessária.

[0083] Há várias questões a considerar em relação a broadcast DASH sobre eMBMS ou similares. Uma questão é que um serviço DASH de broadcast pode oferecer diferentes versões do conteúdo (por exemplo, diferentes representações) em locais diferentes. Também é possível que diferentes representações só possam estar disponíveis via broadcast, ou apenas disponíveis via unicast, ou disponíveis tanto em via unicast quanto em broadcast. Assim, uma técnica para sinalizar que as representações de um serviço estão disponíveis para o transporte de broadcast ou unicast disponível / desejado atualmente é necessária.

[0084] Outra questão é que o transporte de segmentos DASH pode incorrer no ajuste de disponibilidade de broadcast adicional (por exemplo, retardo ou adiantamento em disponibilidade) dos segmentos de tempo podem estar disponíveis para buscar via unicast, em que o ajuste de disponibilidade de broadcast é uma latência de broadcast de tal um cenário. Disponibilidade de um segmento recebido através da entrega de broadcast pode incorrer em ajuste de disponibilidade adicional a partir do momento do segmento pode ser recebido através da entrega unicast, que pode apresentar problemas quando se muda de um modo de entrega para outro modo de entrega (por exemplo, de broadcast para unicast). A fim de permitir transições perfeitas de unicast para broadcast (UC-BC) e broadcast para unicast (BC-UC) conforme o dispositivo se move para dentro e para fora da cobertura de broadcast, informações sobre o ajuste de disponibilidade de broadcast devem ser comunicadas ao cliente DASH.

[0085] Outra questão é que as representações disponíveis via unicast só podem ser acessíveis em determinadas áreas geográficas. Tais restrições geográficas devem ser sinalizadas para os clientes DASH. No entanto, outra questão é que um serviço de DASH de broadcast também pode transportar múltiplas representações através de diferentes sessões FLUTE; tal como tal, uma técnica é necessária para identificar qual a sessão FLUTE, para permitir uma representação desejada. Por exemplo, múltiplas representações podem estar disponíveis através de broadcast em uma determinada área para prover linguagem alternativa ou opções de resolução de vídeo. A seleção para receber apenas a representação de interesses irá melhorar a vida útil da bateria de entidades móveis.

[0086] Em algumas circunstâncias, pode ser desejável criar um serviço de DASH broadcast sob demanda para reduzir a carga sobre os recursos do sistema causada por múltiplos usuários que buscam conteúdo DASH via unicast. Também pode ser necessário fazer uso de diferentes URLs para sinalizar os dispositivos que elas precisam para mudar de unicast para recepção de broadcasr. Assim, soluções para abordar estas questões são descritas abaixo.

[0087] TRANSPORTE DE INFORMAÇÃO DE SINALIZAÇÃO: A fim de resolver os problemas descritos acima, alguns parâmetros podem ser um sinal para clientes DASH para suportar os segmentos DASH transmitidos. Tais parâmetros podem ser sinalizados como novos parâmetros separados na MPD. No entanto, não pode ser desejável ou aceitável ampliar ainda mais a definição MPD para adicionar suporte a esses parâmetros adicionais que são usados apenas em determinados cenários de DASH broadcast.

[0088] Como tal, as soluções propostas aqui descritas podem sinalizar estes parâmetros como um nome de recurso uniforme (URN), sob um Identificador de Espaço de Nome Registrado (NID) - por exemplo, para 3GPP, o NID é 3GPP para que as URNs sob controle 3GPP são da forma urn:3GPP:{3gpp-URN}. Além disso, a Sequência Específica de Espaço de Nome (NSS) URN provê uma modalidade de como codificar os parâmetros necessários como uma lista de dois pontos separados de pares chave = valor realizadas como sequências no atributo ServiceLocation de BaseURLs ou similares.

[0089] Uma possível abordagem alternativa pode envolver a utilização de uma lista de pares chave = valor separados por vírgulas portados como uma sequência no atributo ServiceLocation de BaseURLs. Outra abordagem alternativa pode envolver a codificação destes parâmetros em uma estrutura XML, por um esquema XML, e portar esses dados XML codificados no atributo ServiceLocation de BaseURLs. Outra abordagem pode envolver a adição de atributos adicionais ou elementos ao esquema XML MPD para capturar a lista de parâmetros realizados na URN, lista separada por vírgulas, ou para a codificação XML ou parâmetros no atributo ServiceLocation.

[0090] Na modalidade em que uma codificação de URN é usada para transportar uma lista de pares chave = valor, as seguintes regras ou exigências podem ser aplicadas. A primeira sequência na URN NSS pode ser: s1 (para ServiceLocation). Por exemplo, no caso de 3GPP URNs, todos os URNs utilizados no atributo ServiceLocation iriam começar com "urn:3GPP:s1". A segunda sequência (ou o primeiro par chave = valor) pode ser ":transporte=" + sequência de valor. Por exemplo, a possível sequência de valores pode ser: "broadcast", "unicast", "ambos". Outros pares chave = valor podem seguir ":transporte=" + sequência de valor, ou suas variações.

[0091] DISPONIBILIDADE UNICAST DE SERVIÇOS DASH DE BROADCAST: DASH provê uma estrutura de streaming unicast, onde cada cliente DASH pode buscar segmentos de mídia via HTTP e em sequência de acordo com um cronograma definido em uma MPD. Os segmentos de DASH também podem ser entregues aos dispositivos, incluindo um cliente DASH por meio de um transporte de broadcast, em que os segmentos de Mídia são transmitidos através de FLUTE ou semelhantes.

[0092] Os sistemas de broadcast geralmente incluem metadados de Informação de Sistema (SI) que descrevem os serviços disponíveis através do transporte de broadcast. Em um sistema de broadcast eMBMS, que SI pode ser referida como a descrição de serviço do usuário (USD) e pode incluir metadados para descrever pacotes de serviços, como mostrado na figura 9. Note-se que outros exemplos de SI são o guia de serviço Broadcast OMA e os metadados de Definição de Serviço de MediaFLO. Com referência à figura 10A, é mostrada uma modalidade de uma USD por eMBMS, em que cada serviço pode ser descrito com parâmetros. Tais parâmetros podem incluir uma lista deliveryMethod (detalhada na figura 11) e uma referência ao identificador de recursos uniforme de MPD (mpdURI) associado com o serviço. a MPDURI pode ligar uma MPD ao serviço. A Figura 10B ilustra uma outra modalidade de uma USD por eMBMS, descrita em mais detalhe abaixo.

[0093] Como figura 11 ilustra um sistema de broadcast de eMBMS, que a SI para um sistema de broadcast pode prover informação relacionada com uma versão em que a versão unicast de conteúdo de serviço de broadcast pode ser encontrada. No caso de serviços de broadcast de eMBMS usando streaming RTP, a SI pode proporcionar através da unicastAccessURI no deliveryMethod um serviço de ponteiro para uma arquivo protocolo de descrição de sessão (SDP), que descreve uma versão de streaming RTP unicast para o mesmo conteúdo. A presença de tal URL também pode funcionar para sinalizar que uma versão unicast do serviço está disponível, enquanto sua ausência indica que o serviço está disponível apenas via broadcast. Note-se que os parâmetros podem ser utilizados para sinalizar a disponibilidade de unicast ou semelhantes. Para um serviço de DASH de broadcast, os atributos podem ser utilizados para sinalizar que, para um serviço de DASH de broadcast, representação unicast (s) está também disponível.

[0094] Para um serviço de DASH de broadcast, sinalização explícita de disponibilidade unicast através de uma URL separada na SI, geralmente não é desejável. Para um serviço de DASH de broadcast tal sinalização explícita poderia prover uma referência a uma MPD adicional descrevendo a entrega de segmentos DASH via unicast. Dado que a substituição das MPDs durante a reprodução tende a ser problemática, usar uma MPD para broadcast (por exemplo, sinalizado através de mpdURI para o eMBMSU SDS) e outra MPD para unicast (por exemplo, sinalizado através do unicastAccessURI para o eMBMS USD) não permitiria uma transição suave de recepção de entrega de broadcast para unicast, e vice-versa. Portanto, é desejável incorporar na sinalização de disponibilidade unicast em uma MPD DASH e aproveitar a sinalização MPD de disponibilidade de segmentos a partir de locais diferentes através de elementos BaseURL do tipo ilustrado na figura 8. Proporciona-se um meio para indicar ao cliente DASH, cujas URL estão sendo utilizadas para recepções de unicast vs broadcast. Desta forma, ao fazer a recepção unicast de serviços de broadcast, o cliente DASH irá atuar como um cliente DASH típico e buscar segmentos usando as URLs HTTP unicast na única MPD.

[0095] Esta abordagem permite uma única MPD para descrever como o serviço pode ser recebido através de broadcast e unicast. Uma única MPD para recepções broadcast e unicast também permite o suporte eficiente de hand-off de recepção UC-BC e BC-UC perfeita conforme o cliente DASH entra e sai da cobertura de broadcast.

[0096] No que diz respeito à identificação de segmento de URLs para recepções unicast e broadcast, figura 12 proporciona uma simplificação da figura 7, que ilustra a lista de BaseURLs disponível no nível MPD enquanto abstraindo outros atributos e elementos da MPD. Para o transporte unicast, vários BaseURLs são normalmente utilizados para sinalizar que segmentos idênticos são acessíveis em vários locais. O atributo ServiceLocation pode ser definido para especificar uma relação entre BaseURLs tal que elementos BaseURL com o mesmo valor ServiceLocation são suscetíveis de ter sua resolução de URLs para serviços em um local de rede comum. Isso permite que um cliente DASH use o ServiceLocation ao decidir qual URL base usar quando mudar representações. Por exemplo, o cliente DASH pode selecionar uma nova representação com um BaseURL que tem o mesmo atributo ServiceLocation que os BaseURL utilizados para a representação antiga.

[0097] Uma vez que vários BaseURLs para uma dada representação descrevem diferentes locais de onde os segmentos para o serviço estão disponíveis para buscar, para serviços DASH sobre sistemas de broadcast, um formato pode ser definido para a sequência ServiceLocation. O formato pode prover informações adicionais para sinalizar se um determinado serviço de DASH de broadcast ou qualquer combinação das representações do mesmo está disponível via apenas broadcast, via apenas unicast, ou via tanto unicast quanto broadcast. Mais especificamente, quando se utiliza o formato de URN, o atributo ServiceLocation pode incluir uma sequência iniciando com: "urn:3GPP:s1", como descrito acima. Sequências subsequentes podem ser concatenadas com a sequência inicial começando com um ":" e seguido por uma sequência proporcionando um par chave = valor. A segunda sequência (ou o primeiro par chave = valor) pode ser ":transporte=" + sequência de valor. Possíveis valores- sequências podem ser: "broadcast", "unicast", "ambos". Podem ser utilizados outros valores. Sequências exemplares para o atributo ServiceLocation podem ser urn:3GPP:s1:transporte=broadcast, ou urn:3GPP:s1:transporte= unicast.

[0098] Outras restrições podem ser impostas sobre o uso de URLs, dependendo das definições de certas sequências de valor. Por exemplo, quando a sequência de valor é "broadcast ", as URLs derivadas usando o elemento BaseURL associado podem ser utilizadas quando o DASH cliente recebe esse serviço via broadcast. Mais especificamente, se apenas um BaseURL existe com uma sequência de valor definido como "broadcast", o serviço ou a representação correspondente só está disponível via broadcast. Se nenhum BaseURL existe com uma sequência de valor definido como "broadcast", o serviço ou a representação correspondente não está disponível via broadcast. Se vários BaseURL com uma sequência de valor definido como "broadcast" existe, múltiplas sessões de transporte de broadcast (por exemplo, FLUTE) podem ser definidas para um serviço ou o serviço descrito pelo MPD inclui diferentes representações que podem ser transmitidas em diferentes áreas geográficas. É também possível que as diferentes representações possam ser transmitidas em diferentes localizações. Para fins ilustrativos apenas, na discussão que se segue, assume-se que existe apenas uma representação de broadcast. Para compatibilidade com a cliente DASHs que não suportam o esquema de codificação aqui descrito, o BaseURL com uma sequência de valor definido como "broadcast" pode ser colocado em último lugar na lista de BaseURLs. O BaseURL com uma sequência de valor definido como "broadcast" pode apontar o cliente DASH para um servidor HTTP local (ou seja, no dispositivo) apontando para o host local: http://localhost/ ou similar.

[0099] Quando o sequência de valor é "unicast", a URL no elemento BaseURL associado pode ser usada quando o cliente DASH acessa o serviço via unicast. Se existirem vários BaseURLs com uma sequência de valor definido como "unicast", o cliente DASH pode usar diferentes abordagens para a seleção de um dos BaseURLs ao acessar o serviço via unicast. Por exemplo, uma abordagem consiste em utilizar os BaseURLs em sequência a partir do primeiro BaseURL na lista.

[00100] Quando o sequência de valor é "ambos", a URL no elemento BaseURL associado pode ser usada quando o cliente DASH acessa o serviço, quer através de unicast, ou enquanto em cobertura broadcast. Se um BaseURL existe com uma sequência de valor definido como "ambos", nenhum BaseURL adicional deve existir para uma representação com uma sequência de valor definido como "broadcast" (supondo que apenas uma representação de broadcast exista). O BaseURL com uma sequência de valor definido como "ambos" irá apontar o cliente DASH para um servidor HTTP externo (ou seja, um servidor de rede acessível). Portanto, quando o cliente DASH está na cobertura de broadcast e esta URL é usada, o dispositivo irá suportar uma técnica para redirecionar o acesso HTTP para o host local.

[00101] COMPORTAMENTO DE CLIENTE DASH EXEMPLAR: Com base na disponibilidade broadcast ou unicast de segmentos DASH sinalizados na MPD, uma implementação de cliente DASH pode utilizar as informações ServiceLocation em BaseURLs como segue. Com relação à recepção inicial na cobertura de broadcast, o cliente DASH pode iniciar a recepção de um serviço de DASH de broadcast (por exemplo, eMBMS) enquanto na cobertura da broadcast. O cliente DASH pode: descobrir que a representação está disponível via broadcast (assumindo uma representação de broadcast); selecionar o BaseURL com um atributo ServiceLocation incluindo ambas as sequências ":transporte=broadcast" ou ":transporte=ambos"; e/ou realizar buscas de segmento de acordo com o comportamento de cliente DASH normal usando o BaseURL selecionado. Determinar qual representação de broadcast está atualmente disponível, enquanto em broadcast pode ser feita através de correspondência dos nomes dos arquivos de segmento de mídia sinalizados através do transporte FLUTE.

[00102] Com relação à transição fora da cobertura de broadcast ao consumir conteúdo via broadcast (BC-UC), o cliente DASH, recebendo um serviço de DASH de broadcast (por exemplo, eMBMS) via broadcast, pode transitar de recepção de broadcast de segmentos e começar recepção de unicast dos segmentos. Transição de cobertura de broadcast pode ser detectada pela ausência de SIB-13 sendo disponível entre os SIBs no transporte LTE, e mais imediatamente a indisponibilidade do portador LTE (atribuído a identidade de grupo móvel temporário de serviço (TMGI) ou semelhantes) portando aqueles serviço DASH transmitido. Em aspectos relacionados, o cliente DASH pode continuar recepção da representação atual, se a largura de banda unicast puder suportar aquela representação e um BaseURL existir para a representação com o atributo ServiceLocation incluindo ambas as sequências ": transporte=unicast" ou ":transporte= ambos ". Caso contrário, o cliente DASH pode mudar para uma representação diferente em que um BaseURL existe com o atributo ServiceLocation incluindo ambas as sequências ":transporte=unicast" ou ":transporte= ambos". Se existirem vários destes BaseURLs, o cliente DASH pode selecionar um. Em aspectos mais relacionados, o cliente DASH pode realizar buscas de segmento de acordo com o comportamento de cliente DASH normal usando o BaseURL selecionado.

[00103] No que diz respeito à recepção inicial fora de cobertura de broadcast (por exemplo, quando SIB-13 não está entre os blocos de informações de sistema (SIBS) no transporte LTE), o cliente DASH pode iniciar a recepção unicast de um serviço disponível DASH broadcast (por exemplo, eMBMS) via unicast enquanto não estiver em cobertura broadcast. O cliente DASH pode: determinar a largura de banda disponível para buscar segmentos e selecionar uma representação para reproduzir; selecionar um BaseURL com atributo ServiceLocation incluindo qualquer uma das sequências ":transporte= unicast" ou ":transporte= ambos"; e/ou realizar buscas de segmento de acordo com o comportamento de cliente DASH normal usando o BaseURL selecionado.

[00104] Com relação à transição para recepção fora de broadcast ao consumir conteúdo via unicast (UC-BC), o cliente DASH, atualmente a receber um serviço de DASH de broadcast (por exemplo, eMBMS) via unicast, pode fazer a transição para a cobertura de broadcast e iniciar a recepção de segmentos de via transmitir. Em aspectos relacionados, o cliente DASH pode descobrir que a representação está disponível na cobertura de broadcast, por exemplo, através do nome do ficheiro de media descrito no transporte FLUTE. Em outros aspectos relacionados, o cliente pode continuar DASH recepção de representação thecurrent se a representação ser de broadcast é o mesmo que a representação a ser acedido via unicast. Neste caso, o cliente DASH pode escolher o BaseURL com o atributo ServiceLocation incluindo ambas as sequências ":transporte= broadcast " ou ":transporte= ambos". Em aspectos adicionalmente relacionados, o cliente DASH pode fazer a transição para a representação de broadcast e selecionar o BaseURL com o atributo ServiceLocation incluindo ambas as sequências ":transporte= broadcast " ou ":transporte= ambos". Em aspectos adicionalmente relacionados, o cliente DASH pode realizar buscas de segmento de acordo com o comportamento de cliente DASH normal usando o BaseURL selecionado.

[00105] RESTRIÇÕES GEOGRÁFICAS EM DISPONIBILIDADE UNICAST DE SERVIÇOS DASH BROADCAST: Mesmo que um serviço de DASH de broadcast seja disponibilizado via unicast, pode haver obrigações contratuais ou outro requisito que restrinjam a disponibilidade unicast do conteúdo de serviço para determinadas áreas geográficas.

[00106] Restrições geográficas sobre a disponibilidade de unicast podem ser indicadas em BaseURLs na MPD para um serviço de DASH de broadcast adicionando outra sequência de valor. Por exemplo, BaseURLs da MPD para o serviço de DASH de broadcast com o atributo associado ServiceLocation incluindo ambas as sequências ":transporte= unicast " ou ":transporte= ambos" pode indicar restrições de disponibilidade geográfica para recepções unicast através de formatos de sequência adicional também realizados no atributo ServiceLocation. Especificamente, o atributo ServiceLocation pode incluir uma sequência, quando se utiliza o formato de urn começando com "urn:3GPP:s1", e pode incluir tanto o ":transporte= unicast" ou ":transporte= tanto" para indicar que o serviço está disponível via unicast.

[00107] A sequência (de formato de par chave = valor) ": uGeo3GppCellId =" + sequência CelID pode indicar através da sequência CelID um ID de célula 3GPP onde o serviço pode ser consumido via unicast. Uma sequência exemplar para o atributo ServiceLocation pode ser urn:3GPP:s1:transporte= unicast: uGeo3GppCellId = 345690 ou similar.

[00108] A sequência (de formato par chave = valor) ":uGeo3Gpp2S+N+Z =" + SID_value + "+" + NID_value + "+" + PZID_value pode indicar através da concatenação de SID, NID, PZID, e sequências " + " um ID de célula 3GPP2 onde o serviço pode ser consumido via unicast. Uma sequência exemplar para o atributo ServiceLocation pode ser urn:3GPP:s1:transporte= unicast: uGeo3Gpp2S+N+Z = 23+34 +45 ou semelhante. Por conseguinte, outras sequências podem ser definidas para capturar outros descritores geográficas que podem estar disponíveis para o dispositivo.

[00109] Com relação ao comportamento do cliente DASH de amostra, com base na disponibilidade unicast de segmentos DASH sinalizados na MPD e quaisquer restrições geográficas, a implementação do cliente DASH pode utilizar as informações ServiceLocation em BaseURLs como segue. Para a recepção unicast sem restrição geográfica, o cliente DASH pode iniciar a recepção de um serviço de DASH de broadcast (por exemplo, eMBMS) via unicast (ou seja, o dispositivo não está na cobertura broadcast e BaseURLs existem com atributo ServiceLocation incluindo ambas as sequências ":transporte= unicast "ou":transporte= ambos"). Em aspectos relacionados, o cliente DASH pode: determinar a largura de banda disponível para buscar segmentos e selecionar uma representação para reproduzir; selecionar um BaseURL com atributo ServiceLocation incluindo ambas as sequências ":transporte= unicast" ou ":transporte= ambos"; verificar se não existe BaseURL onde o ServiceLocation inclui uma sequência começando com ": UGEO"; e/ou realizar buscas de segmento de acordo com o comportamento de cliente DASH normal usando o BaseURL selecionado.

[00110] Para a recepção unicast com restrições geográficas, enquanto na área restrita, o cliente DASH pode iniciar a recepção de um serviço de DASH de broadcast (por exemplo, eMBMS) via unicast. Em aspectos relacionados, o cliente DASH pode: determinar a largura de banda disponível para buscar segmentos e selecionar uma representação para reproduzir; selecionar um BaseURL com atributo ServiceLocation incluindo ambas as sequências ":transporte= unicast " ou ":transporte= ambos"; verificar se existem BaseURLs onde o ServiceLocation inclui uma sequência começando com ": UGEO", decidir que pode entender as informações geográficas fornecidas, e determinar que ele está na área descrita; e/ou enquanto na área descrita, realizar buscas de segmento de acordo com o comportamento do cliente DASH normal, utilizando o BaseURL selecionado.

[00111] Para situações onde não há recepção unicast com restrições geográficas, enquanto fora da área restrita, o cliente DASH pode não iniciar a recepção de um serviço de DASH de broadcast (por exemplo, eMBMS) via unicast e reprodução de serviço iria parar. Em aspectos relacionados, o cliente DASH pode: determinar a largura de banda disponível para buscar segmentos e selecionar uma representação para reproduzir; selecionar um BaseURL com atributo ServiceLocation incluindo ambas as sequências ":transporte= unicast" ou ":transporte= ambos"; verificar se existem BaseURLs onde o ServiceLocation inclui uma sequência começando com ": UGEO", pode decidir que o UE (ou cliente DASH) pode entender as informações geográficas fornecidas, e determinar que o UE não está na área descrita; determinar que a informação geográfica fornecida não pode ser compreendida; e/ou quando não está na área descrita, não realizar buscas de segmento de acordo com o comportamento de cliente DASH normal usando o BaseURL selecionado.

[00112] CONSIDERAÇÃO DE AJUSTE DE DISPONIBILIDADE DE TRANSPORTE: O cronograma para a disponibilidade de segmentos DASH pode ser descrito na MPD, como ilustrado na figura 13. A MPD availabilityStartTime, aqui referida como MPD@availabilityStartTime define o tempo absoluto a partir da qual aquele cronograma está ancorado. O atributo de início no primeiro período da MPD descreve a duração do availabilityStartTime quando o primeiro segmento está disponível para busca. Segmentos subsequentes para a mesma representação são espaçados por um período de tempo apropriado no atributo na MPD para a representação, quando os segmentos são de igual duração (isto é, cada segmento está espaçado por uma duração de segmento). Figura 13 ilustra também que o transporte de broadcast para UEs através de um FLUTE e um portador LTE fazem com que a disponibilidade de segmentos seja depois para entrega FLUTE / LTE do que quando eles são descritos no cronograma de MPD descrito acima. Quando os arquivos de mídia são entregues através de FLUTE, o cliente DASH busca os segmentos a partir de um armazenamento local, ao contrário de uma busca unicast a partir de um servidor remoto. O unicast cronograma de disponibilidade pode ser o cronograma descrito pelo MPD availabilityStartTime e atributos de duração.

[00113] Em aspectos relacionados, o cronograma de disponibilidade de segmento na entrega de broadcast não precisa ser depois da entrega unicast, e pode ser de fato antes da disponibilidade de segmento através da entrega unicast. Neste caso, o cronograma de disponibilidade de segmento de unicast "anunciado", como dado pelo availabilityStartTime e atributos de duração na MPD podem representar os "últimos" instantes quando segmentos de uma Apresentação DASH de Mídia podem ser assegurados de estarem disponíveis (para recuperação HTTP pelo cliente DASH) entre a totalidade de servidores HTTP / Redes de Entrega de Conteúdo no âmbito do documento de MPD. É possível que o tempo de disponibilidade de um segmento de broadcast entregue, que envolve a combinação de uma) recepção do segmento de DASH no BM-SC a partir da fonte de conteúdo, b) transmissão sobre FLUTE através da rede núcleo LTE e RAN para o UE, e/ou c) recepção de FLUTE, decodificação FEC e recuperação de segmento no UE e colocação em cache de HTTP local para buscar, pode ocorrer antes desse segmento chegar a uma Rede de Distribuição de Conteúdo Remota (CDN) ou servidor HTTP. Portanto, o tempo de disponibilidade de segmento de broadcast entregue pode ser mais antes que, ao mesmo tempo, ou mais tarde do que o tempo de disponibilidade unicast. Note-se que a MPD pode estar disponível / fornecida para uma infinidade de dispositivos, e pode referir-se a várias redes de acesso ou CDNs a partir das quais um dispositivo de posse da MPD pode recuperar segmentos DASH. Por exemplo, a entidade que produziu o documento MPD e o provedor de serviço da entrega de conteúdo DASH pode entregar a apresentação de mídia e representações individuais como descrito pela MPD.

[00114] Uma vez que a indicação de tempo de disponibilidade de segmento unicast expressa pela usuário adquirir e exibir o conteúdo DASH mais cedo. Em outras palavras, MPD @ availabilityStartTime é o pior caso para o tempo de início unicast. Haverá diferentes latências para distribuir conteúdo para diferentes CDNs. Isto pode ser feito através do ajuste do cronograma de disponibilidade para os segmentos da representação pelo período de latência definido para aquela representação. Um parâmetro, aqui referido como availabilityTimeAdjustment (mostrado como Período de Proteção na figura 13) pode ser adicionado sob o elemento BaseURL para indicar o ajuste do valor MPD @ availabilityStartTime para uma rede de acesso dada / tecnologia. Em outras palavras, availabilityTimeAdjustment pode ser genericamente utilizado para indicar a tempo de disponibilidade do segmento sobre uma determinada rede unicast ou broadcast, em comparação com o pior caso de tempo de disponibilidade unicast.

[00115] Em aspectos relacionados, o ajuste de disponibilidade por um período inteiro pode ser um valor negativo com um valor absoluto grande o suficiente de forma que os recursos no período estejam acessíveis antes da MPD @ availabilityStartTime, o que permitiria o download precoce de segmentos de dados para melhorar a experiência do usuário.

[00116] Com referência à figura 13, mostra-se um cronograma de disponibilidade de busca que um cliente DASH poderia usar para buscar segmentos via unicast. O cronograma de disponibilidade FLUTE na figura 13 ilustra que há um ajuste de disponibilidade envolvido nos segmentos de broadcast, por exemplo, através de uma sessão FLUTE eMBMS, o que pode ser devido ao empacotamento de segmento e codificação FEC para o transporte, broadcast de pacotes para os UEs, e decodificação FEC e remontagem de segmento no dispositivo. Para um cliente DASH que acessa esses segmentos de broadcast, este ajuste de disponibilidade pode sinalizar que o tempo de disponibilidade para a recuperação de segmentos deve ser diferente dependendo de se o segmento é buscado por unicast ou buscado através da entrega de broadcast. O cliente DASH deve considerar um período de proteção ao solicitar segmentos via broadcast.

[00117] O período de proteção indica ao cliente DASH que a disponibilidade de segmentos para buscar via broadcast será atrasada em relação aos mesmos segmentos buscados via unicast.

[00118] SINALIZAÇÃO DE PERÍODO DE PROTEÇÃO PARA ENTREGA BROADCAST DE SEGMENTOS DASH: Como descrito acima, os BaseURLs da MPD para um serviço de DASH de broadcast com o atributo ServiceLocation associado podem incluir a sequência ":transporte= broadcast" ou ":transporte=ambos" para indicar que a representação é acessível através de um broadcast. A fim de considerar o ajuste de disponibilidade associado com a entrega de broadcast de segmentos um formato de sequência adicional também realizado no atributo ServiceLocation pode ser usado para transmitir a informação de período de proteção. Por exemplo, o atributo ServiceLocation pode incluir uma sequência, quando se utiliza o formato de urn, começando com "urn:3GPP:s1", e pode incluir as sequências ": transporte= broadcast" ou ":transporte= ambos" para indicar que o serviço está disponível via broadcast.

[00119] A sequência (de formato de par chave = valor) ":pp =" + ppValue pode sinalizar via ppValue um período de proteção, por exemplo, em milissegundos ou outros incrementos de tempo, a ser contabilizado quando o cliente DASH solicita segmentos via recepção de broadcast. Uma sequência exemplar para o atributo ServiceLocation pode ser urn:3GPP:s1:transporte= broadcast: pp = 50 ou similar.

[00120] Com relação ao comportamento do cliente DASH de amostra, com base na disponibilidade de broadcast de segmentos DASH sinalizados na MPD, e informações sobre um período de proteção, uma implementação de cliente DASH pode utilizar as informações ServiceLocation em BaseURLs como segue.

[00121] Para a recepção através da entrega de broadcast, o cliente DASH pode: descobrir que a representação está disponível em uma área de broadcast; selecionar o BaseURL com atributo ServiceLocation incluindo ambas as sequências ":transporte= broadcast" ou ":transporte= ambos"; determinar o período de proteção indicado em uma subsequência no atributo ServiceLocation começando com ":pp"; e/ou realizar buscas de segmento de acordo com o cronograma de disponibilidade de segmento na MPD usando o BaseURL selecionado, mas ajustando (ou seja, retardando ou tornando precoce) buscas de segmento por milissegundos de ppValue adicionais indicados na sequência, incluindo ":pp". Isso pode permitir que um móvel em uma determinada área geográfica faça solicitação de segmentos mais cedo do que o anunciado, proporcionando uma experiência menor de latência para o usuário, ou fazendo com que um móvel busque segmentos em um momento posterior, em seguida, anunciado e evitando assim, as condições de erro quando os segmentos só estariam disponíveis mais tarde do que o que é anunciado na MPD.

[00122] Para a recepção fora da cobertura de broadcast, o cliente DASH pode: determinar a largura de banda disponível para buscar segmentos e selecionar uma representação; selecionar um BaseURL com atributo ServiceLocation incluindo ambas as sequências ":transporte= unicast " ou ": transporte= ambos"; e/ou realizar buscas de segmento de acordo com o cronograma de disponibilidade de segmento exato na MPD usando o BaseURL selecionado, sem atraso de busca de segmento adicional realizado.

[00123] ALTERNATIVA PARA SINALIZAÇÃO DE UM PERÍODO DE PROTEÇÃO PARA ENTREGA DE BROADCAST DE SEGMENTOS DASH: Uma alternativa para considerar latências de broadcast é ilustrada na figura 14. Ao invés de explicitamente sinalizar um período de proteção e considerá-lo, enquanto na cobertura de broadcast, a MPD para um serviço de DASH de broadcast pode considerar o ajuste de disponibilidade de transporte de broadcast via parâmetros MPD existentes. Isto é ilustrado na figura 14, acrescentando o período de proteção ao atributo MPD availabilityStartTime ou adicionando o período de proteção ao atributo de início do primeiro período de MPD. O efeito de adicionar o período de proteção de um dos parâmetros como descrito acima, é que buscas unicast também são atrasadas.

[00124] TRANSIÇÕES UC-BC/BC-UC SUAVE: Ao considerar as duas alternativas para considerar o ajuste de disponibilidade adicional no transporte de broadcast, as transições UC-BC e BC-UC na recepção e armazenamento antes da reprodução de segmentos via unicast e broadcast devem ser consideradas. Figura 15 ilustra um momento em que a transição ocorre a partir da recepção de segmentos via unicast para recepções via broadcast em um momento em que segmento N está sendo buscado via unicast.

[00125] Um dos objetivos para uma transição suave é minimizar a interrupção durante a reprodução de mídia quando das transições de cliente DASH entre recepções unicast e broadcast. Para conseguir isso, o cliente DASH pode acumular mais de um segmento antes de iniciar a reprodução. O número de segmentos que se acumulam antes de se iniciar a reprodução pode ser sinalizado por meio do atributo minArmazenamentoTime ou afins na MPD. Figura 16 ilustra uma modalidade com dois cenários de reprodução atrasada (nos tempos tpbi), onde a reprodução de segmentos buscados via unicast (nos tempos Tavi) é adiada por um (cronograma à esquerda) e dois (cronograma à direita) segmentos. Isto implica que um ou dois segmentos, respectivamente, têm de ser acumulados antes da reprodução começar. O exemplo da figura 16 ilustra um cenário onde é preciso uma duração de segmento baixar um segmento via unicast no caso em que os segmentos são do mesmo tamanho, e largura de banda está disponível para baixar um segmento em uma duração de segmento. Note-se que a modalidade da figura 16 é meramente ilustrativa, e que os números semelhantes podem ser direcionados para descrever outros cenários em que os segmentos são variáveis em tamanho e a quantidade de segmentos para armazenamento seria responsável por tal variabilidade.

[00126] A figura 17 ilustra cenários de reprodução de segmento atrasado semelhantes para segmentos recebidos via broadcast (no tempo tpAv). Esses segmentos podem estar imediatamente disponíveis para o cliente, uma vez que foram entregues via broadcast, e disponíveis localmente, como indicado anteriormente. A modalidade da Figura 17 sugere que é preciso uma duração de segmento para entregar um segmento via broadcast, no caso em que os segmentos são do mesmo tamanho e a largura de banda de broadcast é o suficiente para entregar um segmento de uma duração de segmento. Note-se que a modalidade da figura 17 é meramente ilustrativa e que figuras semelhantes podem ser direcionadas para descrever cenários semelhantes onde os segmentos são variáveis em tamanho e a quantidade de segmentos de armazenamento seria responsável por tal variabilidade.

[00127] A figura 17 também ilustra a utilização do mesmo requisito minArmazenamentoTime de um ou dois segmentos antes da reprodução. Além disso, a figura 17 também ilustra que, quando o cliente DASH considera o período de proteção, ou seja, a busca é impulsionada pela disponibilidade de segmento de broadcast (no tempo tpAvi), que é um período de proteção depois da disponibilidade unicast (no tempo Tavi) (ver figura), os segmentos podem ser prontamente disponíveis localmente e podem ser buscados com latência mínima. Os segmentos buscados estão prontos para a reprodução imediatamente após o primeiro ou segundo segmento, quando minArmazenamentoTime é um ou dois segmentos, respectivamente.

[00128] Dados os cronogramas nas figuras 16-17, o impacto para uma transição UC-BC, assumindo que disponibilidade de broadcast é detectada enquanto o cliente DASH recupera segmento N via unicast (ver seta na figura 15), podem incluir o seguinte. Em primeiro lugar, o segmento N não pode ser recebido com sucesso via broadcast (sem símbolos o suficiente para decodificar o FEC), de modo que a transição de UC-BC pode ocorrer em um momento posterior. Em segundo lugar, a recepção bem sucedida de segmentos DASH via broadcast não pode ser garantida até que o primeiro segmento (N + 1) seja recebido via broadcast. Como tal, o cliente DASH pode completar a recuperação de segmento N via unicast e recuperar segmento N + 1 via unicast. Em terceiro lugar, o cliente DASH pode retardar (para unicast) busca de segmentos do segmento N + 2 e pode considerar a entrega de broadcast de segmentos. Em quarto lugar, considerando-se as figuras 16-17, a transição suave pode ser alcançada, em que segmento N + 2 pode estar disponível, ao mesmo tempo que se ele fosse buscado via unicast. Ou seja, a reprodução pode prosseguir sem problemas. Por conseguinte, transições UC-BC suaves podem ser alcançadas se a reprodução for atrasada por um segmento (isto é, por minArmazenamentoTime definido em um segmento). Dependendo das circunstâncias, as transições suaves podem exigir um retardo de segmento maior ou menor.

[00129] A figura 18 ilustra a transição BC-UC reversa, destacando um momento em que a transição BC-UC acontece enquanto a recepção do segmento N está sendo buscada via broadcast. Segmento N não pode ser recebido com sucesso via broadcast (símbolos não suficientes para decodificação FEC), que não pode ser determinado imediatamente. Ao determinar que segmento N não foi recebido com sucesso, o cliente DASH pode iniciar a recuperação do segmento N via unicast para garantir a reprodução contínua. O cliente DASH pode precisar de mudar para uma representação de baixa taxa de dados de coleta.

[00130] Assim, handoff BC-UC suave só pode ser alcançado se segmento N puder ser recuperado via unicast a tempo para a reprodução. Como o cronograma esquerdo da figura 19 mostra, não é possível se minArmazenamentoTime ou semelhante prescrever apenas um segmento. Com minArmazenamentoTime prescrevendo dois segmentos (ver o cronograma certo da figura 19), o cliente DASH tem um tempo de segmento para coletar e evitar interrupções na reprodução. O cliente DASH deve ser instruído a acumular mais de dois segmentos antes da reprodução para acomodar um download de coleta via unicast para uma transição suave de broadcast para unicast.

[00131] Em aspectos relacionados, ao incluir o período de proteção em atributos MPD, o cliente DASH pode ser instruído a acumular mais de dois segmentos antes de reprodução. Como tal, uma desvantagem de incluir o período de proteção de parâmetros existentes na MPD pode ser o ajuste de disponibilidade de segmento adicional.

[00132] USO DE PROTOCOLO DE DESCRIÇÃO DE SESSÃO PARA SINALIZAR ENTREGA DE BROADCAST E AJUSTE DE DISPONIBILIDADE DE BROADCAST ASSOCIADO DE UMA DADA REPRESENTAÇÃO DO SERVIÇO DE STREAMING: Pode ser indesejável em determinadas situações usar diretamente a MPD (por exemplo, através do atributo ServiceLocation ou similar) para indicar o modo de entrega unicast vs broadcast dos segmentos de mídia de uma representação. Por exemplo, em algumas implementações, a geração baseada em rede de segmentos de DASH e MPD associada pode ser agnóstica com o método de transporte do conteúdo de mídia (unicast e/ou broadcast). Em tais casos, pode ser desejável para o modo de entrega de broadcast versus unicast ser sinalizado usando informações de anúncio de serviço (também referido como Informação de Sistema ou SI) ou semelhante.

[00133] Em particular, no caso de MBMS 3GPP, um componente de SI ou USD pode ser um fragmento de metadados de Descrição de Sessão ou semelhantes. Tais parâmetros e sintaxe podem por sua vez ser baseados no SDP especificado pelo IETF RFC 4566. Faz-se notar que os termos "atributos" ou "a=" referem-se à primeira forma de estender SDP, e pode ser definido pelo nível da sessão (ou seja, aplicável a componentes de mídia da sessão FLUTE), ou ao nível da mídia individual dentro de uma sessão. Em aspectos relacionados, os campos de atributos podem ser de duas formas, por exemplo. Em aspectos relacionados, não há atributo de "propriedade" da forma "a = <flag>", e para o qual a presença do atributo simplesmente indica que o atributo é uma propriedade da sessão. Em outros aspectos relacionados, há um atributo de "valor" da forma "a = <attribute>: <value>", para o qual o valor do atributo nomeado é composto por uma sequência de octeto arbitrária ou similar.

[00134] De acordo com os aspectos das modalidades aqui descritas, é proporcionado um novo atributo de nível de sessão "a = <representation-transport-mode>:" para indicar o modo de transporte da sessão associada. O subcampo <valor> definido desse atributo pode ser uma escolha entre a sequências de texto "unicast ", “broadcast”, ou "ambos", significando apenas unicast, apenas broadcast, ou ambos os modos de entrega unicast e broadcast para os segmentos da Representação correspondente ou semelhante.

[00135] Além disso, a entrega broadcast de segmentos pode estar associada a um retardo adicional em relação à entrega unicast, e referida como o "período de proteção". Tal parâmetro (s) pode ser adicionado no atributo acima "modo de transporte de representação" através de um novo subcampo <protection-period> ou semelhantes. Por exemplo, a sintaxe completa do atributo "modo de transporte de representação " pode ser como se segue:

[00136] Em aspectos relacionados, <representation-id>, que é equivalente ao valor do atributo "id" da Representação no fragmento MPD do USD, pode identificar a Representação e segmentos DASH associados ao qual rótulo de modo de entrega subsequente se aplica. Se o modo de transporte é "broadcast" ou "ambos", então o subcampo <protection-period> pode aparecer, que representa o ajuste da disponibilidade de broadcast para aquela representação.

[00137] Em outros aspectos relacionados, espera- se que o Cliente de Anúncio de Serviço irá utilizar as informações de atributo acima para informar ao cliente DASH do modo de entrega para a Representação correspondente na MPD, bem como o período de proteção para o modo de entrega de broadcast.

[00138] USO DE PROTOCOLO DE DESCRIÇÃO DE SESSÃO PARA SINALIZAR AJUSTE DE DISPONIBILIDADE DE BROADCAST DE SESSÃO FLUTE: Uma alternativa para a técnica acima descrita para a sinalização de ajuste de disponibilidade de broadcast é usar o fragmento Descrição de Sessão para sinalizar o retardo de broadcast, enquanto que o modo de transporte é declarado usando o atributo ServiceLocation da MPD. Esta abordagem tem a vantagem de dissociar o ajuste de disponibilidade ou informação de período de proteção de DASH. Em outras palavras, além de entrega FLUTE de conteúdo DASH como um serviço de streaming, poderia haver outros aplicativos de serviço de entrega de arquivos para os quais o conhecimento do ajuste de disponibilidade de broadcast é útil para habilitar o aplicativo para usar o conteúdo entregue mais cedo. Exemplos desses aplicativos incluem o broadcast de notícias dinâmicas ou informações de cotações da bolsa, para a exibição de fundo em tempo real perto de um terminal móvel. Para essas aplicações, os arquivos associados com a entrega FLUTE podem estar protegidos por FEC de Camada de Aplicativos (por exemplo, RaptorQ ou análogos) que pode envolver um tempo significativo intercalando na criação de blocos de símbolos codificados. Anúncio do ajuste de disponibilidade de broadcast / período de proteção genericamente via fragmento Descrição de Sessão permitiria o UE a considerar esse retardo ao programar a reprodução do conteúdo associado.

[00139] A técnica para sinalizar o período de proteção na SDP pode ser implementada, por exemplo, de acordo com o seguinte:

[00140] Espera-se que o Cliente de Anúncio de Serviço (ou seja, uma funcionalidade de um UE capaz de broadcast) irá informar a outra funcionalidade no UE do ajuste de disponibilidade de broadcast de modo considerar esse retardo ao programar a reprodução do modo de entrega de conteúdo associado. Tal funcionalidade de cliente pode envolver o cliente DASH, no caso de entrega de broadcast de conteúdo DASH.

[00141] DETERMINAÇÃO DA SESSÃO FLUTE APROPRIADA: Para alguns serviços de DASH de broadcast, pode ser desejável transmitir simultaneamente duas representações alternativas do serviço. Por exemplo, as duas representações podem diferir na resolução de vídeo. Cada resolução pode ser adaptada para diferentes tipos de dispositivos, um de tamanho da tela pequeno (por exemplo, telefones inteligentes) e outro de tamanho de tela grande (por exemplo, tablets). Uma vez que apenas uma destas representações é tipicamente consumida / utilizada por um dado dispositivo, cada uma das representações pode ser transmitida utilizando diferentes sessões de transporte. No caso de eMBMS broadcast, as representações podem ser duas sessões de FLUTE realizadas em diferentes canais portadores eMBMS, que estão ilustrados na modalidade da figura 20.

[00142] No que diz respeito a associar sessões FLUTE às representações, BaseURLs na MPD para um serviço de DASH de broadcast com o atributo ServiceLocation associado podem incluir ambas as sequências ":transporte= broadcast" ou ":transporte= ambos" para uma representação indicando que a representação está disponível via broadcast. Para sinalizar a sessão de transporte de broadcast apropriada (por exemplo, uma sessão de FLUTE em eMBMS) para uma representação, um formato de sequência adicional pode ser realizado no atributo ServiceLocation como segue.

[00143] Em um primeiro aspecto, quando se utiliza o formato de URN, o atributo ServiceLocation para o BaseURL para uma representação pode incluir uma sequência iniciando com "urn:3GPP:s1", e pode incluir ambos o ":transporte= broadcast " ou ":transporte= ambos" para indicar que a representação está disponível via broadcast. Em um segundo aspecto, a sequência (de formato de par chave = valor) ":FLUTE =" + sourcelPAddValue + "+" + tsiValue pode sinalizar a via sourcelPAddValue e o tsiValue o endereço IP de origem e TSI que juntamente e com exclusividade identifica uma sessão FLUTE. Uma sequência exemplar para o atributo ServiceLocation pode ser urn:3GPP:s1:transporte= broadcast: FLUTE = 198.152.39.10 4567 ou similar.

[00144] Em um terceiro aspecto, uma sequência alternativa (de formato de par chave = valor) ":fluteSDP =" + sdpURLValue pode sinalizar via o sdpURLValue a URL que identifica uma das sessões FLUTE definidas para o serviço de broadcast. Uma sequência exemplar para o atributo ServiceLocation pode ser: urn:3GPP:s1:transporte= broadcast: fluteSDP = http://example.com/serviceX/service.sdp ou similar. Em um quarto aspecto, outras sequências podem ser definidas para designar as sessões de transporte diferentes das sessões de de FLUTE.

[00145] No que diz respeito a comportamento do cliente DASH de amostra, com base na disponibilidade de broadcast de segmentos DASH sinalizados na MPD, e informações do mapeamento de sessões FLUTE para representações, uma implementação de cliente DASH pode utilizar as informações ServiceLocation de BaseURLs para recepção em broadcast cobertura, como se segue. Em um primeiro aspecto, o cliente DASH pode escolher uma representação desejada com base em informações de descrição de mídia (por exemplo, resolução de tela). Em um segundo aspecto, o cliente DASH pode detectar que múltiplas representações estão disponíveis via broadcast, tais como, por exemplo, quando a informação ServiceLocation dos BaseURLs para essas representações incluem ou a sequência ":transporte= broadcast" ou ":transporte= ambos ". Em um terceiro aspecto, o cliente DASH, ao detectar que está na cobertura de broadcast, pode selecionar um BaseURL com um atributo ServiceLocation incluindo ambas as sequências ":transporte= broadcast" ou ": = transporte tanto" que estão associadas com a representação selecionada. Em um quarto aspecto, o cliente DASH pode fazer com que recepção de segmentos via broadcast ocorra através da sessão de FLUTE (no caso de eMBMS) identificada pela sequência incluindo ": FLUTE =" ou ": fluteSDP =" no atributo ServiceLocation do BaseURL selecionado. Em um quinto aspecto, o cliente DASH pode realizar buscas de segmento de acordo com o segmento de disponibilidade no cronograma MPD usando o BaseURL selecionado.

[00146] SINALIZAÇÃO DE UC-BC URLS PARA SERVIÇOS SOB DEMANDA: Um sistema de broadcast pode suportar a definição de serviços de DASH de broadcast sob demanda, como forma de reduzir o uso de recursos do sistema por vários usuários acessando determinado conteúdo DASH via recepção unicast. Em algumas circunstâncias, pode ser necessário redirecionar equipamentos de usuário que consomem conteúdo DASH unicast para um serviço de DASH de broadcast transportando o mesmo conteúdo. Este processo de redirecionamento pode fazer uso de recursos de redirecionamento HTTP para fazer com que os dispositivos de usuário se-solicitem um segmento desejado usando uma URL diferente da URL usada para a solicitação original. O uso dessas URLs redirecionadas pode agir como um acionador para o dispositivo de usuário para determinar a disponibilidade de um novo serviço de DASH de broadcast para o mesmo conteúdo a ser obtido via unicast.

[00147] No que diz respeito à identificação de URLs segmento para recepções unicast-para-broadcast, BaseURLs da MPD para um serviço de DASH de broadcast com o atributo ServiceLocation associado incluindo a sequência ":transporte= unicast" indicam que a representação está disponível via unicast. A fim de adicionalmente indicar ainda que certas URLs unicast são destinadas apenas para suportar a abordagem de redirecionamento, uma sequência de formato adicional também pode ser realizada no atributo ServiceLocation para URLs identificadas utilizadas para redirecionamento. Mais especificamente, o atributo ServiceLocation pode incluir uma sequência, quando se utiliza o formato de urn, começando com "urn:3GPP:s1", e pode incluir a sequência ":transporte= unicast" para indicar que o serviço está disponível via unicast. Além disso, a sequência (de formato par chave = valor) ":transition=" + transvalor pode indicar que a URL é destinado apenas para suportar técnica de redirecionamento onde o transValor pode ser ou UC-BC ou BC-UC. Uma sequência exemplar para o atributo ServiceLocation pode ser urn:3GPP:s1:transporte= unicast: transition= UC-BC ou similar.

[00148] No que diz respeito ao comportamento de cliente de amostra DASH, quando o conteúdo DASH disponível via unicast também podem ser disponibilizado via broadcast para tráfego unicast off-load, a MPD associada com o conteúdo pode sinalizar disponibilidade broadcast e unicast do conteúdo. Informação sobre as URLs de transição pode também estar presente para identificar as URLs para serem utilizadas para o redirecionamento de transição. Para redirecionamento de transição, a aplicação do cliente DASH pode envolver a utilização da informação de ServiceLocation BaseURLs como explicado abaixo.

[00149] Em um primeiro aspecto, o cliente DASH pode iniciar a recepção de unicast do conteúdo DASH onde o cliente DASH: (a) determina a largura de banda disponível para buscar segmentos e seleciona uma representação para reproduzir; (b) seleciona um BaseURL com atributo ServiceLocation incluindo ambas as sequências ":transporte= unicast" ou ":transporte= ambos", exceto BaseURLs incluindo as sequências ":transporte= unicast" e ":Transition="; e/ou (c) realiza buscas os segmentos de acordo com o comportamento de cliente DASH normal usando o BaseURL selecionado.

[00150] Em um segundo aspecto, pode estar sinalizando de disponibilidade do serviço de broadcast ao consumir conteúdo via unicast (ou seja, a indicação de unicast para transição de broadcast). O cliente DASH que recebe conteúdo DASH via unicast pode receber um redirecionamento HTTP para outra URL. O cliente DASH então: (a) avalia se a URL redirecionada corresponde a um BaseURL da MPD para a mesma representação onde o atributo ServiceLocation correspondente inclui sequências ":transporte= unicast" e ": transition= UC-BC"; (b) se tal uma correspondência for encontrada, realiza a transição; e/ou (c) continua buscando os segmentos das URLs redirecionados até disponibilidade de uma versão de broadcast do conteúdo poder ser determinada.

[00151] TRANSPORTAR PARÂMETROS VIA SEQUÊNCIAS SEPARADAS POR VÍRGULAS: Os diferentes parâmetros aqui descritos têm sido codificados utilizando um formato de URN com o propósito de ilustração e não como forma de limitação. Alternativamente, uma sequência separada por vírgulas pode ser empregue. Em uma modalidade, uma sequência separada por vírgulas pode ser implementada como se segue. A primeira sequência a ser realizada no atributo ServiceLocation de BaseURLs pode ser "3gpp-sl" ou algo semelhante. Sequências subsequentes podem ser concatenadas para a sequência inicial começando com a "," e seguidas por uma sequência proporcionando um par chave = valor ou similar.

[00152] A segunda sequência (ou o primeiro par chave = valor) pode ser ",transporte =" + valor-sequência ou similar. Possíveis sequências de valores podem ser: "broadcast", "unicast", "ambos". Sequências exemplares para o atributo ServiceLocation podem ser 3gpp-sl, transporte = broadcast ou 3 GPP-sl, transporte = unicast.

[00153] Em aspectos relacionados, para sinalizar a disponibilidade geográfica de um serviço de DASH de broadcast via unicast, a sequência (de formato par chave = valor), ",uGeo3GppCellId =" + CelID-sequência pode indicar através da CelID-sequência um ID de célula 3GPP onde o serviço pode ser consumido via unicast. Uma sequência exemplar para o atributo ServiceLocation pode ser 3gpp-sl, transporte = unicast, uGeo3GppCellId = 345690 ou similar.

[00154] A sequência (de formato par chave = valor) ",uGeo3Gpp2S + N + Z =" + SID_value + "+" + NID_value + "+" + PZID_value pode indicar através da concatenação de sequências SID, NID, PZID, e "+" um ID de célula 3GPP2 onde o serviço pode ser consumido via unicast. Uma sequência exemplar para o atributo ServiceLocation pode ser: 3GPP-sl, transporte = unicast, uGeo3Gpp2S + N + Z = 23 +34 +45 ou algo semelhante. Outras sequências podem ser definidas para capturar outros descritores geográficos que podem estar disponíveis para o dispositivo.

[00155] Em aspectos relacionados adicionais, a sequência (de formato chave = valor par) ",pp =" + ppValue sinalizará através do ppValue um período de proteção em milissegundos a ser contabilizado quando o cliente DASH solicita segmentos enquanto na cobertura de broadcast . Uma sequência exemplar para o atributo ServiceLocation pode ser: 3GPP-sl, transporte = broadcast, pp = 50 ou semelhante.

[00156] Ainda em aspectos relacionados adicionais, para sinalizar a sessão de transporte de broadcast adequada para a representação, a sequência (de formato par chave = valor) ",flute=" + sourcelPAddValue + "+" + tsiValue pode sinalizar via sourcelPAddValue e o tsiValue o endereço IP de origem e TSI que juntamente e com exclusividade identifica uma sessão FLUTE. Uma sequência exemplar para o atributo ServiceLocation pode ser: 3GPP-sl, transporte = broadcast, FLUTE = 198.152.39.10 4567 ou similar.

[00157] Uma sequência alternativa (de formato par chave = valor) ",fluteSDP =" + sdpURL Valor pode sinalizar através da sdpURLValue URL que identifica uma das sessões FLUTE definidas para o serviço de broadcast. Uma sequência exemplar para o atributo ServiceLocation pode ser: 3GPP-sl, transporte = broadcast, fluteSDP = http://example.com/serviceX/service.sdp ou similar. Outras sequências podem ser definidas para descrever sessões de transporte diferentes de sessões FLUTE.

[00158] Em ainda aspectos relacionados adicionais, a sequência (de formato chave = valor par), "transition=" + transValor pode indicar que a URL se destina a suportar técnica de redirecionamento onde o transvalor poderia ser UC-BC ou BC-UC, por exemplo. Uma sequência exemplar para o atributo ServiceLocation pode ser: 3GPP-sl, transporte = unicast, transition= UC-BC ou similar.

[00159] TRANSPORTAR PARÂMETROS VIA SEQUÊNCIAS XML: Ainda uma outra forma de codificar os diferentes parâmetros descritos, até agora, para o transporte no atributo ServiceLocation de BaseURLs é através de um arquivo XML. A estrutura XML para estes parâmetros pode ser capturada sobre um esquema XML, tal como ilustrado no exemplo da figura 21, que mostra várias transmissões de broadcast para um único serviço.

[00160] Em uma modalidade, para sinalizar o tipo de transporte, o atributo ServiceLocation pode ser como se segue. Para o tipo de broadcast, o atributo ServiceLocation pode ser:

[00161] Para o tipo unicast, o atributo ServiceLocation pode ser:

[00162] Em outra modalidade, para sinalizar a disponibilidade geográfica de um serviço de DASH de broadcast via unicast, pode aplicar:

[00163] Usar IDs de células 3GPP:

[00164] Usar ID da célula 3GPP2:

[00165] Em ainda outra modalidade, para sinalizar o período de proteção, pode aplicar:

[00166] Em ainda outra modalidade, para sinalizar a sessão de transporte de broadcast adequada para uma representação, o seguinte pode ser aplicado:

[00167] Em outra modalidade, para sinalizar a URL usada para o serviço DASH sob demanda, o seguinte pode aplicar:

[00168] OPÇÕES PARA DECLARAR O MODO DE TRANSPORTE DE BROADCAST E/OU AJUSTE DE DISPONIBILIDADE DE BROADCAST: De acordo com os aspectos do tema desta divulgação, há outras opções fornecidas para o uso da MPD para declarar o modo de transporte dos segmentos de DASH, bem como a ajuste de disponibilidade na disponibilidade dos segmentos de mídia entregue por meio de broadcast, em relação à entrega unicast desses mesmos segmentos de mídia. Uma abordagem, descrita acima, envolve o uso do atributo ServiceLocation para transportar tais metadados a respeito do modo de transporte e disponibilidade de broadcast de informações de ajuste. Uma outra abordagem, descrita acima, envolve o uso da descrição de sessão das informações de anúncio de serviço MBMS para prover o modo de transporte e de informação de ajuste de disponibilidade de entrega, por meio de um arquivo de SDP ou semelhantes.

[00169] Em alternativa, ou além disso, o modo de transporte e informação de ajuste de disponibilidade de broadcast pode ser sinalizado dentro de um novo elemento de MPD chamado TransportDescription ou semelhantes. Por exemplo, TransportDescription pode representar um tipo de elemento descritor genérico (por exemplo, como definido pelo DASH MPEG (ISO / IEC 23009-1) ou padrão 3GP-DASH (3GPP TS 26,247)), e serve como um recipiente para transmissão e informações relacionadas ao acesso para as Representações descritas na MPD. Exemplos de tal informação de broadcast e de acesso podem incluir: i) uma topologia de broadcast (unicast, broadcast, ou ambos); ii) um tipo específico de tecnologia de broadcast (por exemplo, MBMS celular sobre GERAN, UTRAN, ou LTE), sistema de broadcast de TV terrestre (por exemplo, ATSC, ISDB-T, T-DMB, CMMB, ou DVB-T), ou tecnologias de broadcast de TV por satélite (por exemplo, DVB-S ou S-DMB); iii) referência a informação relacionada a anúncio / informação de serviço específica para a tecnologia de acesso; e iv) um ajuste de disponibilidade de específico de entrega de broadcast de disponibilidade de Serviço relativa à disponibilidade do segmento de entrega de unicast. O ajuste de disponibilidade específico de broadcast pode aumentar a MPD@availabilityStartTime, fornecendo o valor de retardo de tempo para ser adicionado ao tempo de disponibilidade de segmento unicast. O valor resultante (tempo de disponibilidade de segmento unicast + valor de retardo de broadcast) representa o segmento de broadcast em tempo de disponibilidade.

[00170] Na alternativa, ou além disso, o modo de transporte e informação de ajuste de disponibilidade de broadcast podem ser sinalizados pela definição de um novo parâmetro de extensão sob o elemento BaseURL na MPD. O novo parâmetro de extensão pode incluir um elemento filho ou atributo broadcastDelivery que indica entrega MBMS e, adicionalmente, anuncia o ajuste de disponibilidade de broadcast. O novo parâmetro de extensão pode aparecer sob o elemento filho BaseURL do elemento de representação ou similar. Esta abordagem provê uma indicação de se representações individuais da apresentação de mídia estarão disponíveis para entrega broadcast, e também iria prover uma indicação de todas as latências diferentes.

[00171] Deve ser notado que o TransportDescription pode ser definido para prover apenas um ponto de entrada para a informação de anúncio de serviço. O parâmetro de ajuste de disponibilidade pode ser movido para o elemento BaseURL da MPD. Em aspectos relacionados, quando o elemento TransportDescription é usado para expressar parâmetros específicos de acesso, indicados no caso de transporte de broadcast, a transmissão e informação relacionada com o acesso pode identificar explicitamente a tecnologia (por exemplo, celular, TV terrestre, televisão por satélite, ou semelhante). A tecnologia de broadcast pode ser identificada através do alargamento do elemento BaseURL para transportar os parâmetros específicos de acesso ou semelhantes. Em outros aspectos relacionados, o descritor de transporte pode ser colocado em diferentes níveis hierárquicos da MPD, como, por exemplo, no nível do elemento MPD alto ou em elementos filho da MPD (por exemplo, período, AdaptationSet, Representação, etc.). Deve ser notado que o elemento TransportDescription pode ser um elemento par do BaseURL, ou pode ser um elemento par do SegmentBase.

[00172] Em aspectos relacionados, o descritor de Transportes (ou seja, o elemento TransportDescription) pode ser capaz de lidar com segmentos individuais declarados na MPD, já que cada segmento pode ser entregue em uma rede diferente. Em aspectos mais relacionados, o descritor de Transporte pode ser definido no nível de representação. Por exemplo, o descritor de transporte pode ser adicionado aos seguintes elementos: (a) o elemento BaseURL, que pode então ser utilizado de forma flexível e/ou (b) o elemento SegmentBase (por exemplo, quando não está presente BaseURL), de tal modo que o descritor de transporte pode ser adicionado no período, o AdaptationSet, e/ou os níveis de representação.

[00173] Em aspectos relacionados, o esquema de acesso de descritor de Transporte, representado por um atributo schemeldUri do descritor de Transportes, pode ser construído de tal forma que o cliente DASH, middleware de dispositivo ou outra função UE possa interpretar esse recurso para determinar se a pilha de rede suporta este esquema de transporte. O valor associado a um descritor de Transportes pode provê um ponto de entrada único para o transporte para o anúncio de serviço. Por exemplo, o valor associado pode ser um serviceID ou uma URL para um documento de anúncio de serviço, etc.

[00174] Em aspectos relacionados, no caso de MBMS, o valor de descritor de transporte pode ser uma URL para o usuário do documento de feixe de serviço / fragmento que também inclui o serviceID (por exemplo, codificado como um fragmento na URL). O valor de descritor de Transportes pode incluir informações específicas sobre a sessão FLUTE a ser unida. Em alternativa, ou além disso, a URL para o serviço e acesso à informação descoberta pode também ser disponibilizado em uma página web através de HTTP ou similar. Neste caso, um tipo de conteúdo pode ser definido o qual identifica o documento ligado pela URL como um documento de descrição de feixe de serviço do usuário para o link de broadcast / multicast.

[00175] SINALIZAÇÃO DE DISPONIBILIDADE BROADCAST E/OU UNICAST DE REPRESENTAÇÕES: De acordo com um ou mais aspectos das modalidades aqui descritas, é fornecida uma técnica para a sinalização da disponibilidade de broadcast e/ou disponibilidade unicast de representações de segmentos de dados de mídia em um sistema sem fio broadcast. Com referência à figura 10B, é mostrado um exemplo de USD, incluindo informação para um serviço de eMBMS. O USD foi expandido para descrever a disponibilidade das representações via broadcast, unicast, ou ambos.

[00176] Como figura 10B ilustra, a presença de um elemento de Descrição de Apresentação de mídia 2 atualizado indica que o serviço que a USD descreve é um serviço eMBMS DASH onde o elemento mpdURI provê um link para identificar a MPD que está associado com o serviço DASH.

[00177] O elemento de Descrição de Apresentação de mídia 2 atualizado também provê lista de elementos Representação de broadcast e representação de unicast que identificam as representações de unicast e broadcast. Uma representação identificada em ambas as listas estão disponíveis via unicast e broadcast.

[00178] Uma representação em qualquer lista pode ser identificada: pelo período, através do atributo periodld; pelo conjunto de adaptação, através do atributo adaptationSetId; e/ou pela representação, através do atributo representationld como referências aos respectivos valores identificados na MPD. Representações de broadcast também podem ser associadas com a informação serviceArea que permite que componente de broadcast determine qual a representação está disponível em uma dada área de broadcast.

[00179] Uma vez que os serviços de broadcast podem também incluir vários fluxos de transporte, um serviço de DASH de broadcast pode ter diferentes representações sendo realizadas através de fluxos de transporte distintos. Isso poderia ser feito para oferecer diferentes resoluções que visam diferentes capacidades do dispositivo, ou diferentes linguagens para diferentes preferências do usuário.

[00180] Em um comportamento de cliente de broadcast exemplar, com base na disponibilidade broadcast e/ou unicast de representações DASH sinalizadas na USD para um serviço DASH eMBMS, um cliente eMBMS de broadcast pode ser capaz de: saber quando o dispositivo está dentro ou fora da cobertura de broadcast; e/ou saber qual das representações DASH na MPD está disponível através do serviço de broadcast e que está disponível via unicast pelas informações do sistema (por exemplo, o dólar no eMBMS) como figura10B mostra. Em aspectos relacionados, dependendo do estado de cobertura de broadcast, o cliente de broadcast pode: sinalizar o cliente para selecionar uma das representações de broadcast disponíveis uma vez que o dispositivo está em cobertura de broadcast; e/ou sinalizar o cliente DASH para selecionar uma das representações unicast disponíveis uma vez que o dispositivo não está na cobertura da broadcast. De acordo com aspectos ainda relacionados, dependendo da seleção do cliente DASH de representação de broadcast, o cliente broadcast pode ativar a recepção da sessão de FLUTE que porta a representação selecionada.

[00181] O atributo availabilityTimeAdjustment, se presente, especifica o ajuste para a recepção de broadcast da Representação em relação ao tempo de início disponibilidade de segmento declarado no fragmento MPD (isto é, MPD@availabilityStartTime), e que poderia ser um valor positivo ou negativo. Um valor positivo (negativo) indica que o tempo de disponibilidade de Segmentos da Representação é depois (mais cedo) do que aquele de qualquer representação, se for o caso, da Apresentação de Mídia entregue via unicast. Os elementos serviceArea e sessionDescription, se presentes, denotam a área de serviço (s) sobre a qual a Representação está disponível e a sessão FLUTE portando aquela representação, respectivamente. O elemento unicastRepresentation, se presente, identifica cada Representação, que é oferecida através de unicast para entrega de recuo. Uma representação de entrega unicast pode ser a mesma representação que também é entregue ao portador MBMS, ou pode ser uma representação que só é entregue ao portador unicast.

[00182] Em virtude de vários sistemas mostrados e descritos aqui, as metodologias que podem ser implementadas de acordo com o objeto divulgado, irão ser melhor apreciadas com referência a vários fluxogramas. Enquanto, para efeitos de simplicidade de explicação, as metodologias são mostradas e descritas como uma série de atos / blocos, deve ser entendido e apreciado que a matéria reivindicada não está limitada pelo número ou ordem de blocos ou, como alguns blocos podem ocorrer em ordens diferentes e/ou substancialmente ao mesmo tempo com outros blocos a partir do que é mostrado e aqui descrito. Além disso, nem todos os blocos ilustrados podem ser necessários para implementar as metodologias aqui descritas. Deve ser apreciado que a funcionalidade associada com os blocos poderão ser implementadas através de software, hardware, uma combinação destes ou quaisquer outros meios adequados (por exemplo, dispositivo de sistema, processo, ou componentes). Além disso, deve ser ainda apreciado que as metodologias divulgadas ao longo desta especificação são capazes de serem armazenadas em um artigo de fabricação para facilitar o transporte e transferência de tais metodologias de vários dispositivos. Os versados na técnica compreenderão e apreciarão que uma metodologia pode ser alternativamente representada como uma série de estados ou eventos, tais como, em um diagrama de estado interrelacionado.

[00183] De acordo com um ou mais aspectos das modalidades aqui descritas, com referência à figura 22A, mostra-se uma metodologia 2200, operável por uma entidade móvel (por exemplo, um UE ou semelhante). O método 2200 pode envolver, em 2210, receber uma MPD, a MPD compreendendo parâmetros para recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast (por exemplo, em resposta à ativação de uma sessão de entrega de arquivos). Deve ser notado que, no caso de broadcast, os dados podem residir localmente sobre o cache HTTP do UE, ao passo que no caso unicast os dados podem residir em um servidor HTTP ou "em nuvem". O método 2200 pode envolver, em 2220, determinar se a transmissão de broadcast ou a transmissão de unicast é apropriada para a recepção dos segmentos de dados. O método 2200 pode envolver, em 2230, a seleção de uma determinada representação dentre as múltiplas representações do conteúdo com base em um critério da entidade móvel. O método 2200 pode envolver, em 2240, receber os segmentos de dados para a dada representação com base, pelo menos em parte nos parâmetros para a transmissão determinada da transmissão de broadcast e transmissão de unicast.

[00184] Com referência às figuras 22B-D, são mostradas operações adicionais ou aspectos do método 2200 que são opcionais e podem ser realizados por uma entidade móvel ou semelhante. Se o método 2200 inclui, pelo menos, um bloco das Figuras 22B ou 22C, em seguida, o método 2200 pode terminar após o pelo menos um bloco, sem ter necessariamente de incluir qualquer bloco a jusante subsequente (s) que pode ser ilustrado. Note-se ainda que os números de referência dos blocos não implicam uma ordem específica em que os blocos podem ser realizados de acordo com o método 2200. Por exemplo, a entidade móvel pode operar em um sistema móvel de broadcast, um serviço de DASH de broadcast pode ser definido por meio de metadados de informação de sistema que incluem a MPD, e o método pode envolver a determinação dos parâmetros da MPD se entrega alternativa do serviço de DASH de broadcast estiver disponível através da transmissão de unicast (bloco 2250).

[00185] O método 2200 pode envolver a determinação da disponibilidade da transmissão de broadcast de uma localização atual da entidade móvel (bloco 2252), e na ausência da disponibilidade da transmissão de broadcast, que determina a disponibilidade da transmissão de unicast como uma alternativa para a transmissão de broadcast (bloco 2254).

[00186] Os critérios podem incluir, pelo menos, uma das capacidades de resolução de tela, capacidade de linguagem, compatibilidades de rede sem fio da entidade móvel, ou disponibilidade de canal sem fio para suportar os requisitos de largura de banda das representações (bloco 2256). Informação para uma sessão de entrega de arquivo de broadcast associada à representação é usada para ativar a sessão de entrega de arquivo de broadcast para a recepção de segmentos de mídia (bloco 2258).

[00187] O método 2200 pode envolver selecionar uma representação para recepção de broadcast, selecionar entre representações de broadcast disponíveis que podem ser recebidas em uma área de serviço de broadcast atual (bloco 2260).

[00188] O método 2200 pode envolver a seleção de uma representação para recepção unicast, selecionar entre representações unicast disponíveis para entrega alternativa que podem ser recebidas na área de serviço unicast atual (bloco 2262).

[00189] Com referência à figura 22C, receber (bloco 2240) pode envolver o ajuste de um cronograma de disponibilidade para os segmentos de dados da representação por um período de ajuste de latência para a dada representação (bloco 2264).

[00190] Receber (bloco 2240) pode envolver: considerar as diferenças de cronograma de disponibilidade para as representações como definidas pelos seus respectivos períodos de ajuste da latência (bloco 2266); considerar características da transmissão de broadcast e transmissão de unicast que impactam acesso aos segmentos de dados (bloco 2268); e ajustar o armazenamento de segmentos de dados para conseguir transições suaves entre a recepção via a transmissão de unicast e a transmissão de broadcast para as respectivas representações do conteúdo (bloco 2270).

[00191] O ajuste de período de latência pode indicar um retardo de tempo ou um avanço temporal na disponibilidade dos segmentos de dados para a dada representação através da transmissão de broadcast, em relação à transmissão de unicast (bloco 2272). Por exemplo, os parâmetros podem indicar um ajuste de disponibilidade para entrega de broadcast dos segmentos de dados, em relação à entrega unicast dos segmentos de dados. Por exemplo, os parâmetros podem indicar um retardo de tempo esperado na disponibilidade de segmentos de dados entregues por broadcast, em relação à sua disponibilidade via entrega unicast. Em alternativa, os parâmetros podem indicar um avanço de tempo esperado na disponibilidade de segmentos de dados entregues por broadcast, em relação a sua disponibilidade através da entrega unicast.

[00192] Os parâmetros podem indicar (a) apenas unicast, (b) apenas broadcast, ou (c) ambas disponibilidade unicast e broadcast dos segmentos de dados (bloco 2274). Pelo menos um dos parâmetros pode pertencer a (b) apenas broadcast ou (c) a ambas disponibilidade unicast e broadcast de segmentos de dados que identifica uma tecnologia de distribuição de broadcast (bloco 2276). Por exemplo, a pelo menos uma tecnologia de distribuição de broadcast pode corresponder a um sistema de broadcast baseado em IP, tais como, por exemplo, a) tecnologia de broadcast celular, b) sistema de TV de broadcast terrestre, ou c) tecnologia de broadcast de TV por satélite.

[00193] Com referência à figura 22D, os parâmetros incluem informações sobre a disponibilidade de uma representação de broadcast em determinadas áreas de serviço de broadcast identificadas (bloco 2278).

[00194] Os segmentos de dados podem ser segmentos de mídia DASH e semelhantes (bloco 2280), e o método 2200 pode ainda envolver acumular os segmentos de mídia para alcançar a reprodução suave dos segmentos de mídia, em resposta à recepção dos segmentos de mídia mudando da transmissão de broadcast para a transmissão de unicast, ou vice-versa (bloco 2282). Os parâmetros podem ser codificados em uma ou mais ocorrências de um elemento de extensão TransportDescription ou similar, na MPD (bloco 2284). Os parâmetros podem incluir um identificador de sessão FLUTE ou similar para uma representação particular de conteúdos de broadcast (bloco 2286).

[00195] Em aspectos relacionados, determinar (bloco 2220) pode envolver a determinação de que a recuperação unicast é apropriada para a recepção dos segmentos de dados. Os parâmetros podem indicar a disponibilidade geográfica dos segmentos de dados para a recuperação unicast. Em outros aspectos relacionados, os parâmetros podem incluir informações para direcionar acessos DASH unicast a uma versão de broadcast sob demanda de conteúdos através de um atributo ServiceLocation na MPD para o conteúdo.

[00196] De acordo com aspectos adicionais relacionados, os parâmetros podem ser codificados em um BaseURL da MPD. Os parâmetros podem compreender uma URN em um NID registrado. Os parâmetros podem compreender uma sequência específica de espaço de nome URN (NSS), que inclui uma lista separada de dois pontos de pares de chave = valor transportados como sequências em um atributo ServiceLocation do BaseURL. Os parâmetros podem estar relacionados com representações DASH que fornecem alternativas para um determinado fluxo de dados.

[00197] Em ainda aspectos adicionais relacionados, os parâmetros podem ser codificados em uma ou mais ocorrências de um elemento de extensão TransportDescription sob a MPD. O elemento de extensão TransportDescription sob a MPD pode residir dentro de uma ou mais dos seguintes diferentes níveis hierárquicos da estrutura de dados MPD: o elemento MPD, elemento Período, elemento AdaptationSet e elemento Representação. O TransportDescription pode ser um tipo de elemento descritor genérico, e pode conter transmissão e informação relacionada a acesso para as representações descritas na MPD. A Transmissão e informação relacionada a acesso transportadas em cada instância do TransportDescription podem indicar pelo menos uma topologia de broadcast: a) unicast, b) broadcast, ou c) ambos unicast e broadcast.

[00198] Se a topologia de broadcast é indicada como broadcast ou ambos broadcast e unicast, a transmissão as informações relacionadas a acesso podem indicar um de um tipo específico de a) tecnologia de broadcast celular, b) sistema de broadcast de TV terrestre, ou c) tecnologia de broadcast de televisão por satélite. A transmissão e informação relacionada a acesso podem indicar informações do ponto de entrada para acessar informações de anúncio / descoberta de serviço para a tecnologia de broadcast. Além de informações de ponto de entrada para o acesso a informações anúncio / descoberta de serviço para a tecnologia de broadcast, a transmissão e as informações relacionadas a acesso podem indicar um ajuste de disponibilidade esperado de segmentos de dados entregues por broadcast, em relação a sua disponibilidade através da entrega unicast. O tempo de disponibilidade via entrega unicast de segmentos de dados pode ser representado por, ou pode ser derivado a partir de, um valor de MPD@availabilityStartTime.

[00199] Em aspectos relacionados, os parâmetros podem ser codificados em um ou mais parâmetros de extensão sob pelo menos um exemplo de um elemento BaseURL na MPD. Os parâmetros de cada um das uma ou mais instâncias do elemento BaseURL podem indicar o modo de transporte transmitir ou unicast. Se o modo de transporte é indicado como a broadcast, os parâmetros associados podem permitir a identificação explícita de uma tecnologia de distribuição de broadcast de um tipo específico de uma) tecnologia de broadcast celular, b) sistema de broadcast de TV terrestre, ou c) tecnologia de broadcast de televisão por satélite. Os parâmetros podem indicar um ajuste de disponibilidade esperado de segmentos de dados entregues por broadcast, em relação a sua disponibilidade através da entrega unicast. Os parâmetros podem indicar se as representações individuais de uma apresentação de mídia estarão disponíveis para transmissões. Se o modo de transporte é indicado como unicast, os parâmetros associados podem permitir a identificação explícita de uma rede de acesso unicast ou tipo de rede de Entrega de Conteúdo (CDN). Os parâmetros podem indicar um ajuste de disponibilidade esperada de segmentos de dados para a recuperação nesta rede de acesso unicast ou CDN, em relação à sua disponibilidade via entrega unicast.

[00200] De acordo com um ou mais aspectos das modalidades aqui descritas, são proporcionados dispositivos e aparelhos para realizar as metodologias descritas acima com referência às figuras 22A-D. Com referência à figura 23, é proporcionado um aparelho exemplar 2300, que pode ser configurado como uma entidade móvel, ou como um processador ou outro dispositivo semelhante / componente para utilização. O aparelho 2300 pode incluir blocos funcionais, que podem representar funções implementadas por um processador, software ou uma combinação destes (por exemplo, firmware). Por exemplo, o aparelho 2300 pode incluir um componente elétrico ou módulo 2312 para receber uma MPD, a MPD compreendendo parâmetros para recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O aparelho 2300 pode incluir um componente 2314 para determinar se a transmissão de broadcast ou a transmissão de unicast é apropriada para a recepção dos segmentos de dados. O aparelho 2300 pode incluir um componente 2316 para a seleção de uma determinada representação dentre as múltiplas representações do conteúdo com base em um critério de uma entidade móvel. O aparelho 2300 pode incluir um componente 2318 para receber os segmentos de dados para a dada representação com base, pelo menos em parte nos parâmetros para a dada transmissão da transmissão de broadcast e transmissão de unicast.

[00201] Em aspectos relacionados, o aparelho 2300 pode, opcionalmente, incluir um componente de processador / controlador 2350 que tem pelo menos um processador, no caso do aparelho 2300 configurado como uma entidade móvel e não como um processador. O processador 2350, em tal caso, pode estar em comunicação operativa com o componente (s) 23122318 através de um barramento 2352 ou semelhante. O processador 2350 pode efetuar a iniciação e programação dos processos ou funções executadas pelo componente (s) 23122318.

[00202] Em outros aspectos relacionados, o aparelho 2300 pode incluir um componente transceptor de rádio frequência (RF) 2354. Um receptor autônomo e/ou transmissor autônomo pode ser usado em vez de ou em conjunto com o transceptor 2354. Aparelho 2300 pode, opcionalmente, incluir um componente para armazenamento de informações, tais como, por exemplo, um dispositivo / componente de memória 2356. O meio legível por computador ou o componente de memória 2356 pode ser acoplado operacionalmente aos outros componentes do aparelho por meio do barramento 2300 2352 ou semelhante. O componente de memória 2356 pode ser adaptado para armazenar instruções legíveis por computador e dados para efetuar os processos e comportamento do componente (s) 2312-2318, e subcomponentes dos mesmos, ou o processador 2350, ou os métodos descritos acima, com referência às figura 22A-D. O componente de memória 2356 pode reter as instruções para a execução de funções associadas com o componente (s) 2312-2318. Embora mostrado como sendo externo à memória 2356, deve ser entendido que o componente (s) 2312-2318 pode existir no interior da memória 2356. Note-se ainda que o componente (s) na figura 23 pode incluir processadores, dispositivos eletrônicos, dispositivos de hardware, subcomponentes eletrônicos, circuitos lógicos, memórias, códigos de software, códigos de firmware, etc., ou qualquer combinação destes.

[00203] De acordo com um ou mais aspectos das modalidades descritas aqui, a figura 24 mostra uma outra metodologia exemplar 2400 operável por uma entidade móvel ou semelhante. O método 2400 pode envolver, em 2410, receber a informação de sistema, que inclui: (a) uma MPD DASH; e (b) os parâmetros para recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O método 2400 pode envolver, em 2415, determinar se a transmissão de broadcast ou a transmissão de unicast é apropriada para a recepção dos segmentos de dados. O método 2400 pode envolver, em 2420, selecionar uma determinada representação dentre as múltiplas representações do conteúdo com base nos parâmetros e um critério da entidade móvel. O método 2400 pode envolver, em 2430, que recebe os segmentos de dados para a dada representação.

[00204] De acordo com um ou mais aspectos das modalidades descritas aqui, a figura 25 mostra um desenho de um aparelho 2500 (por exemplo, uma entidade móvel ou componente (s) deste) para a realização do método 2400 descrito acima com referência à figura 24. Por exemplo, o aparelho 2500 pode incluir um componente elétrico ou módulo 2512 para receber informação de sistema, que inclui: (a) uma MPD DASH; e (b) os parâmetros para recepção dos segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O aparelho 2500 pode incluir um componente 2513 para determinar se a transmissão de broadcast ou a transmissão de unicast é apropriada para a recepção dos segmentos de dados. O aparelho 2500 pode incluir um componente 2514 para selecionar uma dada representação dentre as múltiplas representações do conteúdo com base nos parâmetros e um critério da entidade móvel. O aparelho 2500 pode incluir um componente 2516 para receber segmentos de dados para a dada representação. Por uma questão de concisão, o resto dos detalhes sobre o aparelho 2500 não são elaborados adiante; no entanto, deve ser entendido que muitas das características e aspectos do aparelho 2500 são substancialmente semelhantes as descritas anteriormente com respeito ao aparelho 2300 da figura 23.

[00205] De acordo com um ou mais aspectos das modalidades aqui descritas, com referência à figura 26, é mostrada uma metodologia 2600, operável por uma entidade de rede (por exemplo, um eNB ou semelhante). O método 2600 pode envolver, em 2610, o envio de uma MPD, a MPD compreendendo parâmetros para recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O método pode envolver 2600, em 2620, receber uma solicitação para uma dada representação do conteúdo. O método 2600 pode envolver, em 2630, enviar os segmentos de dados para a dada representação através da transmissão de broadcast ou transmissão de unicast com base pelo menos em parte nos parâmetros. O método pode opcionalmente envolver sinalizar quais representações de um serviço estão disponíveis para a transmissão de broadcast ou a transmissão de unicast (bloco 2640). Por exemplo, enviar os segmentos de dados (bloco 2630) pode envolver enviar os segmentos de dados para a dada representação através da transmissão de unicast e em paralelo enviar os segmentos de dados para, pelo menos, uma representação diferente através da transmissão de broadcast (bloco 2650).

[00206] De acordo com um ou mais aspectos das modalidades descritas aqui, a figura 27 mostra um projeto de um aparelho 2700 (por exemplo, uma entidade de rede ou componente(s) deste) para a realização do método 2600 descrito acima com referência à figura 26. Por exemplo, aparelho 2700 pode incluir um componente elétrico ou módulo 2712 para enviar uma MPD, a MPD compreendendo parâmetros para recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão de broadcast e transmissão de unicast. O aparelho 2700 pode incluir um componente 2714 para receber uma solicitação para uma dada representação do conteúdo. O aparelho 2700 pode incluir um componente 2716 para enviar os segmentos de dados para a dada representação através da transmissão de broadcast ou transmissão de unicast com base pelo menos em parte nos parâmetros. Por uma questão de concisão, o resto dos detalhes relativos ao aparelho 2700 não são adicionalmente elaborados adiante; no entanto, deve ser entendido que muitas das características e aspectos do aparelho 2700 são semelhantes as descritas acima em relação aos aparelhos 2300 da figura 23. Note-se, contudo, que o aparelho 2700 pode ser uma entidade de rede, tal como um eNB ou semelhantes. Por conseguinte, o aparelho pode incluir componentes de interface de rede (por exemplo, placas de interface de rede ou controladores), bem como outros componentes normalmente encontrados em uma estação base utilizada em um sistema de comunicação sem fio.

[00207] Deve ser notado que o lado da rede descreve a MPD e os parâmetros para o dispositivo móvel / entidade para selecionar entre representações de broadcast e/ou unicast. A rede envia a representação (s) de broadcast e torna a representação de unicast (s) disponível para o dispositivo móvel buscar segmentos. Em aspectos relacionados, o aparelho 2700 pode ainda envolver em resposta à entidade móvel selecionar o modo unicast para a recepção dos segmentos de dados de mídia, enviar uma entidade móvel para a representação selecionada pela entidade móvel de segmentos de dados de mídia através de um HTTP unicast ou similar.

[00208] Os versados na técnica entenderão que a informação e os sinais podem ser representados utilizando qualquer uma de uma variedade de diferentes tecnologias e técnicas. Por exemplo, dados, instruções, comandos, informação, sinais, bits, símbolos, e chips que podem ser referenciados em toda a descrição acima podem ser representados por tensões, correntes, ondas eletromagnéticas, campos magnéticos ou partículas, campos ópticos ou partículas, ou qualquer combinação destes.

[00209] Os versados iriam ainda apreciar que os vários blocos lógicos ilustrativos, módulos, circuitos, e etapas do processo descritas em ligação com a presente descrição podem ser implementados como hardware eletrônico, software de computador, ou combinações de ambos. Para ilustrar claramente esta permutabilidade de hardware e software, vários componentes ilustrativos, blocos, módulos, circuitos, e etapas foram descritos acima, geralmente em termos da sua funcionalidade. Se tal funcionalidade é implementada como hardware ou software depende da aplicação particular e restrições de projeto impostas ao sistema global. Os versados na técnica podem implementar a funcionalidade descrita em diferentes maneiras para cada aplicação em particular, mas tais decisões de execução não devem ser interpretadas como causa de afastamento do âmbito da presente divulgação.

[00210] Os vários blocos lógicos ilustrativos, módulos e circuitos descritos em conexão com a divulgação aqui podem ser implementados ou executados com um processador de propósito geral, um processador de sinal digital (DSP), um circuito integrado de aplicação específica (ASIC), um arranjo de portas programável em campo (FPGA) ou outro dispositivo de lógica programável, porta discreta ou lógica de transistor, componentes de hardware discretos, ou qualquer combinação destes projetada para desempenhar as funções aqui descritas. Um processador de uso geral pode ser um microprocessador, mas em alternativa, o processador pode ser qualquer processador, controlador, microcontrolador, ou máquina de estado convencional. Um processador pode também ser implementado como uma combinação de dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo DSP, ou qualquer outro tipo de configuração.

[00211] As etapas de um método ou processo descritas em ligação com a presente descrição podem ser incorporadas diretamente em hardware, em um módulo de software executado por um processador, ou em uma combinação dos dois. Um módulo de software pode residir na memória RAM, memória flash, memória ROM, memória EPROM, EEPROM, registos, disco rígido, um disco removível, um CD-ROM, ou qualquer outra forma de meio de armazenamento conhecida na técnica. Um meio de armazenamento exemplar é acoplado ao processador de modo que o processador pode ler informação a partir de, e grava informação no meio de armazenamento. Em alternativa, o meio de armazenamento pode ser integral ao processador. O processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um terminal de usuário. Em alternativa, o processador e o meio de armazenamento podem residir como componentes distintos em um terminal de usuário.

[00212] Em um ou mais projetos exemplares, as funções descritas podem ser implementadas em hardware, software, firmware, ou qualquer combinação dos mesmos. Se implementadas em software, as funções podem ser armazenadas em ou transmitidas através de uma ou mais instruções de código ou um meio legível por computador. Mídia legível por computador inclui ambos os meios de armazenamento em computador e meios de comunicação, incluindo qualquer meio que facilite a transferência de um programa de computador de um lugar para outro. Os meios de armazenamento podem ser qualquer mídia disponível, que pode ser acessada por um computador de propósito geral ou computador de propósito especial. A título de exemplo, e não como limitação, tais meios legíveis por computador podem incluir RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco óptico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser utilizado para portar ou armazenar elementos de código de programa desejados na forma de instruções ou estruturas de dados e que pode ser acessado por um computador de propósito geral ou de propósito especial, ou um processador de propósito geral ou de propósito especial. Além disso, qualquer conexão é corretamente considerada um meio legível por computador. Por exemplo, se o software é transmitido de um site, servidor, ou outra fonte remota usando um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fio não transitórias, então o cabo coaxial, cabo de fibra óptica, par trançado, DSL, ou as tecnologias sem fio não transitórias estão incluídos na definição de meio. Disco e disquete, como aqui utilizado, incluem disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco Blu-ray, onde disquetes geralmente reproduzem dados magneticamente, enquanto que discos reproduzem dados opticamente com lasers. Combinações dos anteriores também devem ser incluídas no âmbito de meios legíveis por computador.

[00213] A descrição anterior da divulgação é fornecida para permitir que qualquer versado na técnica possa fazer ou utilizar a divulgação. Várias modificações à divulgação serão facilmente evidentes para os versados na técnica, e os princípios gerais aqui definidos poderão ser aplicados a outras variações, sem se afastar do espírito ou âmbito da divulgação. Assim, a descrição não se destina a ser limitada aos exemplos e desenhos aqui descritos, mas deve ser dado o mais amplo âmbito consistente com princípios e novas características aqui descritos.

Claims (14)

1. Método operável por uma entidade móvel para comunicação sem fio quando da transição entre recepção de segmentos de dados via transmissão de broadcast e transmissão de unicast, o método caracterizado pelo fato de que compreende: receber (2210) uma descrição de apresentação de mídia (MPD) que compreende parâmetros para recepção de segmentos de dados para múltiplas representações de conteúdo através de transmissão broadcast ou transmissão unicast ou uma combinação das mesmas; determinar (2220) um protocolo apropriado para recepção de segmentos de dados a partir da transmissão de broadcast ou da transmissão de unicast com base nos parâmetros; selecionar (2230, 2256) uma representação a partir das múltiplas representações do conteúdo com base em um critério da entidade móvel, em que o critério compreende pelo menos uma dentre capacidade de resolução de exibição, capacidade de linguagem, compatibilidade de rede sem fio da entidade móvel, ou disponibilidade de canal sem fio para suportar os requisitos de largura de banda das representações (2230); determinar diferenças de cronograma de disponibilidade entre uma representação selecionada e pelo uma outra dentre as múltiplas representações, em que as diferenças de cronograma de disponibilidade são definidas pelos respectivos períodos de ajuste de latência; determinar características que impactam acesso aos segmentos de dados para uma primeira representação para recepção através da transmissão broadcast e uma segunda representação para recepção através da transmissão unicast, em que uma dentre a primeira e a segunda representações é a representação selecionada; ajustar armazenamento temporário de segmentos de dados para a representação selecionada com base nas diferenças de cronograma de disponibilidade determinadas para alcançar uma transição sem interrupção; e receber (2240) os segmentos de dados para uma representação selecionada de acordo com o protocolo de transporte apropriado.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a entidade móvel opera em um sistema móvel de broadcast, em que um serviço DASH de broadcast é definido através dos metadados de informações de sistema que incluem a MPD, o método compreendendo adicionalmente determinar (2250) a partir dos parâmetros na MPD se entrega alternativa do serviço DASH de broadcast está disponível através da transmissão unicast considerando transição de broadcast para unicast.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que determinar o protocolo de transporte apropriado compreende adicionalmente: determinar (2252) uma disponibilidade da transmissão broadcast em uma localização atual da entidade móvel; e determinar (2254) uma disponibilidade da transmissão unicast como uma alternativa para a transmissão broadcast quando a transmissão broadcast não está disponível.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que informações de uma sessão de entrega de arquivo de broadcast associada à representação selecionada dentre as múltiplas representações de conteúdo são usadas para ativar a sessão de entrega de arquivo de broadcast para a recepção dos segmentos de mídia (2258).

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que múltiplas representações do conteúdo incluem representações de broadcast do conteúdo, em que selecionar uma representação dentre as múltiplas representações do conteúdo compreende adicionalmente selecionar uma representação de broadcast para recepção broadcast disponível em uma área de serviço de broadcast atual, ou em que as múltiplas representações do conteúdo incluem representações unicast do conteúdo, em que selecionar uma representação a partir das múltiplas representações do conteúdo compreende adicionalmente selecionar uma representação unicast para recepção unicast para distribuição alternativa disponível na área de serviço unicast atual.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que receber os segmentos de dados para a representação selecionada compreende adicionalmente ajustar (2264) um cronograma de disponibilidade para os segmentos de dados da representação por um período de ajuste de latência para a representação selecionada.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que o período de ajuste de latência indica um retardo de tempo ou um avanço de tempo na disponibilidade dos segmentos de dados para a representação selecionada via a transmissão broadcast, em relação à transmissão unicast.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que: os parâmetros para recepção dos segmentos de dados indicam uma disponibilidade para cada segmento de dados por pelo menos dentre apenas unicast, apenas broadcast, ou tanto unicast quanto broadcast; e em que pelo menos um entre apenas broadcast ou tanto unicast quanto broadcast identifica uma tecnologia de distribuição de broadcast.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que: os segmentos de dados compreendem Streaming Adaptativo Dinâmico sobre segmentos de mídia HTTP (DASH), em que receber os segmentos de dados para uma representação compreende adicionalmente: armazenar temporariamente os segmentos de mídia DASH para alcançar reprodução sem interrupção dos segmentos de mídia, em resposta à transição entre a transmissão broadcast e a transmissão unicast ou vice- versa.

10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que : os parâmetros para recepção de segmentos de dados são codificados em uma ou mais ocorrências de um elemento de extensão na MPD que indica modos de transporte, em que os modos de transporte significam modos de distribuição por unicast, broadcast, ou tanto unicast quanto broadcast; e os parâmetros compreendem uma entrega de arquivo sobre o identificador de sessão de transporte unidirecional, FLUTE, para uma representação específica de conteúdo de broadcast.

11. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que cada representação dentre as múltiplas representações de conteúdo compreende pelo menos um URL Base que define um atributo de localização de serviço indicando que segmentos de dados estão disponíveis através de a transmissão broadcast ou transmissão unicast ou uma combinação das mesmas.

12. Entidade móvel para comunicação sem fio quando da transição entre recepção de segmentos de dados via transmissão de broadcast e transmissão de unicast caracterizada pelo fato de que compreende meios para realizar as etapas do método conforme definido em qualquer uma das reivindicações 1 a 11.

13. Entidade móvel, de acordo com a reivindicação 12, caracterizada pelo fato de que a entidade móvel é adaptada para funcionar em um sistema móvel de broadcast, no qual um serviço DASH de broadcast é definido através de metadados de informações de sistema que incluem a MPD, a entidade móvel compreendendo adicionalmente meios para determinar a partir dos parâmetros na MPD se entrega alternativa do serviço DASH de broadcast está disponível através da transmissão unicast.

14. Memória legível por computador não transitória caracterizada pelo fato de que compreende instruções armazenadas na mesma para fazer com que um computador realize as etapas do método conforme definido em qualquer uma das reivindicações 1 a 11.

Images