BRPI0621350A2

BRPI0621350A2 - método para fornecer um canal de controle habilitado por ims para um serviço de iptv, canal de controle habilitado por ims para um serviço de iptv, e, código de programa de computador

Info

Publication number: BRPI0621350A2
Application number: BRPI0621350-2A
Authority: BR
Inventors: Bo Astrom; Ignacio Mas Ivars; Hans Carlsson; Yi Cheng; Karl Norrman
Original assignee: Ericsson Telefon Ab L M
Priority date: 2006-02-24
Filing date: 2006-02-24
Publication date: 2012-10-09
Also published as: ATE487314T1; WO2007096001A1; CN101385303A; DE602006018070D1; CN101385303B; EP1987647A1; JP4927879B2; US20090235299A1; PT1987647E; US8078733B2; EP1987647B1; JP2009527956A

Abstract

MéTODO PARA FORNECER UM CANAL DE CONTROLE HABILITADO POR IMS PARA UM SERVIçO DE IPTV, CANAL DE CONTROLE HABILITADO POR IMS PARA UM SERVIçO DE IPTV, E, CóDIGO DE PROGRAMA DE COMPUTADOR. Um canal de controle habilitado por IMS para um serviço de IPTV é fornecido através da recepção em um fução de controle de estado/chamada de serviço (S-CSCF), uma mensagem de REGISTER do protocolo de iniciação de sessão (SIP), a mensagem de REGISTER do SIP identificando o usuário de origem, recebendo no usuário de origem uma resposta da S-CSCF indicando que o usuário de origem foi autorizado, e enviando uma mensagem de INVITE do SIP da S-CSCF para estabelecer uma conexão de canal aberto com Servidor de Aplicativo (AS) de IPTV selecionado. Esta conexão de canal aberto pode então ser usada para a transmissão de mensagens de controle, tais como para então ser usada para a transmissão de mensagens de controle, tais como para iniciar execução, iniciar gravação, parar execução, etc., entre a STB e o Servidor de Aplicativo de IPTV, assim como para a entrega de conteúdo personalizado, tal como anúncios, respostas de votação, acionamentos de votação personalizados e eventos interativos alvos. Através da manutenção de um canal de controle aberto com o AS de IPTV, este oferece uma redução substancial nos tempos de retardo de configuração para aplicativos diferentes.

Description

1

"MÉTODO PARA FORNECER UM CANAL DE CONTROLE HABILITADO POR IMS PARA UM SERVIÇO DE IPTV, CANAL DE CONTROLE HABILITADO POR IMS PARA UM SERVIÇO DE IPTV, E, CÓDIGO DE PROGRAMA DE COMPUTADOR" Campo da Invenção

A presente invenção se refere ao fornecimento de um canal de controle habilitado do Subsistema de Multimídia de IP (IMS) para um serviço de IPTV, preferencialmente mas não necessariamente utilizando uma caixa de topo de aparelho (STB). Fundamentos da Invenção

Serviços de Multimídia de IP fornecem uma combinação dinâmica de voz, vídeo, tratamento de mensagem, dados, etc. dentro da mesma sessão. Através do aumento do número de aplicações básicas e da mídia que é possível combinar, é possível aumentar o número de serviços 15 oferecidos para os usuários finais, e assim sendo enriquecer a experiência de comunicação entre pessoas. Isto vai conduzir a uma nova geração de serviços de comunicação de multimídia ricos e personalizados, incluindo os assim chamados serviços de "Multimídia de IP de combinações" que são considerados em mais detalhes abaixo. Subsistema de Multimídia de IP (IMS) é a tecnologia definida pelo Projeto de Sociedade de Terceira Geração (3GPP) para fornecer serviços de Multimídia de IP sobre redes de comunicação móvel (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 e TS 29.329 Liberações 5 a 7). IMS fornece recursos importantes para enriquecer a experiência de comunicação de pessoa a pessoa do usuário final através do uso de Habilitadores de Serviço do IMS padronizados, que facilita novos ricos serviços de comunicação pessoa a pessoa (cliente a cliente) assim como serviços de pessoa para conteúdo (cliente para servidor) sobe redes baseadas em IP. O IMS faz uso do Protocolo de Iniciação de Sessão (SIP) 2

para configurar e controlar chamadas ou sessões entre terminais de usuário (ou terminais de usuário e servidores de aplicativo). O Protocolo de Descrição de Sessão (SDP), carregado pela sinalização do SIP é usado para descrever e negociar os componentes de mídia da sessão. Enquanto SIP foi criado como um protocolo de usuário para usuário, IMS permite os operadores e provedores de serviço controlar o acesso do usuário aos serviços e conseqüentemente cobrar os usuários.

As fronteiras entre os serviços fornecidos pelos operadores de telecomunicações, operadores de TV, e provedores de serviço de internet estão desaparecendo, e tais companhias estão todas oferecendo aos clientes todos os três serviços (assim chamados de "tripla execução "). Para operadores de telecomunicações desejando oferecer serviços de TV, uma escolha popular é utilizar o assim chamado IPTV que despacha serviço de TV sobre IP e uma conexão de banda larga (e. g. ADSL, VDSL, Ethernet Pública, etc.).

IPTV tem uma largura de banda limitada a sua disposição na "primeira milha "do acesso de banda larga a partir do modem xDSL e o acesso de banda larga (DSLAM). Despacho de conteúdo linear, no qual todos os canais de uma subscrição (" pacote de programa ") are despachados de forma simultânea para a caixa de topo de aparelho (STB), não é adequado para IPTV devido a largura de banda limitada. A capacidade de conexão de xDSL varia dependendo da versão de DSL usada e da distância da "primeira milha". ADSL pode fornecer uma capacidade entre 3 a 8 Mbps, ao passo que ADSL2 promete despachar até 25Mbps no fluxo de descida e taxa de dados de VSDL maiores do que 30 Mbps. Conteúdo de MPEG2 de qualidade padrão requer 2 Mbps por canal, e HDTV vai requerer 8-10 Mbps por canal. Afortunadamente, o novo padrão MPEG4 vai diminuir a largura de banda requerida para a metade com a mesma qualidade que o conteúdo codificado de MPEG2. Independentemente, a largura de banda disponível é um recurso escasso, e soluções de IPTV precisam limitar o número de canais a serem despachados sobre a "primeira milha ".

Soluções de deslocamento de tempo / perseguir a execução existentes são, ou baseadas em tecnologia de rede proprietária ou em PVRs na casa. Uma solução descrita aqui, utiliza o sistema de comunicação de IMS padronizado e sua arquitetura de rede, e um PVR residindo na Rede para limitar o tráfego transmitido através da conexão da primeira milha para uma origem.

Com a convergência entre serviços de IPTV e a infra-estrutura do IMS, uma nova pletora de possibilidades abertas para o usuário final utilizar o aparelho de TV. Vídeo-conferência, jogos interativos, anúncios personalizados ou programas de TV interativos com realimentação dos telespectadores se tornaram uma realidade que é facilmente alcançável usando IMS. Contudo, muitas dessas aplicações requerem extensiva comunicação entre o STB e os diferentes servidores de aplicativo, tal que, cada vez que um novo serviço requeira ser adicionado à experiência do usuário (por exemplo quando o usuário recebe uma chamada de videoconferência enquanto vendo TV) usando um sistema de IPTV convencional, há um retardo de configuração associado com a configuração dos diferentes canais de controle e recepção da informação requerida. Sumário da Invenção

É um objeto da presente invenção para fornecer um canal de controle habilitado por IMS para um serviço de IPTV.

De acordo com um primeiro aspecto da presente invenção é fornecido um método para fornecer um canal de controle habilitado por IMS para um serviço de IPTV, o método compreendendo:

- receber em uma Função de Controle de Estado/Chamada de Serviço (S-CSCF), uma mensagem REGISTER de um Protocolo de Iniciação de Sessão (SIP), a mensagem de REGISTER do SIP identificando o usuário de origem;

- receber no usuário de origem uma resposta da S-CSCF indicando que o usuário de origem foi autorizado;

- enviar um mensagem de INVITE do SIP da S-CSCF para estabelecer uma conexão de canal aberto com um Servidor de aplicativo de

IPTV (AS) de IPTV selecionado; e

- enviar e / ou receber mensagens de controle ou de informação através da conexão do canal aberto.

Mantendo um canal de controle aberto com o AS de IPTV, a invenção oferece uma redução substancial nos tempos de retardo de configuração para aplicativos diferentes, assim como um canal de dados de controle comum único que pode ser usado para contatar uma STB. O AS de IPTV, assim sendo se torna o "ponto de conexão comum "para a STB.

O uso dos mecanismos do IMS para configurar um canal de controle persistente entre a STB e o AS de IPTV desta maneira e o uso do canal de controle para despachar toda a informação de controle requerida a partir da STB para o AS de IPTV e a partir do AS de IPTV para a STB fornece particulares vantagens no uso. Em particular isto possibilita um canal de controle único a ser usado para toda a informação de controle diferente dos aplicativos diferentes que poderiam ser exibidas na TV, assim como para toda a infra-estrutura do IMS para configurar o canal de controle e controlar aqueles aplicativos. O canal de controle nunca será usado para fluxo de mídia.

A invenção é capaz de fornecer um canal de controle habilitado por IMS para uma caixa de topo de aparelho (STB) de IPTV. O canal de controle pode ser configurado usando os procedimentos do IMS padrões e ele mais tarde pode ser usado para enviar mensagens de controle, tais como para, iniciar execução, iniciar gravação, parar execução, etc. da STB, para o Servidor de Aplicativo de IPTV, assim como para entrega de conteúdo personalizado, tal como anúncios, respostas de votação, acionamentos de votação personalizados e eventos interativos alvos.

A invenção fornece uma solução para a interação da STB personalizada com um AS de IPTV possibilitando envio e recepção de comandos de controle e itens particulares de informação que são somente requeridos para serem enviados de, ou recebidos por, uma das STBs selecionada conectada ao AS.

Na modalidade preferida da invenção a ser descrita abaixo o cana de controle "sempre ativo "reduz a latência de configuração para tal interação com o AS de IPTV, fornecendo um tubo de dados controlados por TCP criptografados que está sempre pronto para enviar e receber as diferentes mensagens requeridas. O canal de controle também fornece o AS de IPTV com os meios para controlar o comprimento e estado da conexão das diferentes subscrições de IPTV, assim como fornecer um canal seguro acessível de forma fácil para atualizações de softwares.

A invenção permite uma mistura de serviços de IPTV, serviços de comunicação de IMS e serviços de informação personalizados.

De acordo com ainda um aspecto da presente invenção é fornecido código de programa de computador para realizar o método do primeiro aspecto da invenção.

Descrição breve dos Desenhos

De modo que a invenção possa ser mais totalmente entendida, uma modalidade preferida de acordo com a invenção será agora descrita, por meio de exemplo, com referência aos desenhos anexos, nos quais:

Figura 1 é um diagrama esquemático ilustrando uma seqüência no registro da STB;

Figura 2 é um diagrama esquemático ilustrando ainda uma seqüência no registro da STB;

Figura 3 é um diagrama esquemático ilustrando o estabelecimento de uma conexão de TCP/TLS segura; e Figura 4 é um diagrama esquemático ilustrando uma seqüência secundária de "Dados de Usuário de Busca"; e

Figura 5 é um diagrama esquemático ilustrando o estabelecimento de um guia de programa eletrônico (EPG).

Descrição Detalhada dos Desenhos

Por meio do conhecimento da modalidade preferida o seguinte é uma descrição breve de como o Subsistema de Multimídia de IP (IMS) se encaixa na rede de arquitetura móvel no caso de uma rede de acesso de GPRS/OS. A Funções de Controle de Sessão/Chamada (CSCFs) operam como procuradores do SIP dentro do IMS. A arquitetura de 3GPP define três tipos de CSCFs: a CSCF Proxy (P-CSCF) que é o primeiro ponto de contato dentro do IMS para um terminal de SIP; a CSCF de Serviço (S- CSCF) que fornece serviços para o usuário aos quais o usuário está subscrito; e a CSCF de Interrogação (I-CSCF) cujo papel é identificar a correta S-CSCF e passar adiante para aquela S-CSCF uma solicitação recebida a partir de um terminal de SIP através de uma P- CSCF.

Um usuário se registra com o IMS usando o método de REGISTER do SIP especificado. Este é um mecanismo para conectar com o IMS e anunciar para o IMS o endereço no qual uma identidade de usuário de SIP pode ser alcançada. O usuário recebe um Identificador de Fonte Uniforme (URI) único da S-CSCF a ser usado quando ele inicia um diálogo. No 3GPP, quando um terminal de SIP efetua um registro, o IMS autentica o usuário, e aloca uma S-CSCF para aquele usuário do conjunto de S-CSCFs disponíveis. Enquanto o critério para alocar uma S-CSCFs não está especificado pelo 3GPP, estes podem incluir compartilhamento de carga e requisitos do serviço. É notado que a alocação de uma S-CSCF é primordial para controlar (e cobrar por) o acesso do usuário aos serviços baseado no IMS. Operadores podem fornecer um mecanismo para prevenir sessões de SIP de usuário para usuário direto que ao contrário pularia a S- CSCF. Durante o processo de registro, é a responsabilidade da I- CSCF para selecionar uma S-CSCF se uma não está já selecionada. A I-CSCF recebe as capacidades da S-CSCF requeridas a partir do Servidor de Assinante de Origem (HSS) da rede doméstica, e seleciona uma S-CSCF apropriada com base nas capacidades recebidas, (é notado que a alocação da S-CSCF é também realizada para um usuário através de uma I-CSCF no caso onde o usuário é chamado por uma outra parte, e o usuário não está correntemente alocado em uma S-CSCF.) Quando um usuário registrado de forma subseqüente envia uma solicitação de sessão (e. g. INVITE DE SIP) para o IMS, a solicitação vai incluir os URIs da P-CSCF e da S-CSCF, tal que a P-CSCF é capaz de passar adiante a solicitação para a S-CSCF selecionada. Isto se aplica para ambos nos lados originando e terminando (do IMS), (para a chamada terminando, a solicitação vai incluir o endereço da P-CSCF e o endereço do equipamento de usuário (UE)).

Dentro da rede de serviço do IMS, os Servidores de Aplicativo (ASs) são fornecidos para implementar a funcionalidade de serviço do IMS. ASs fornecem serviços para usuários sinais em um sistema de IMS, e podem ser conectados ou como pontos finais sobre a interface Mr definida pelo 3GPP, ou "conectada" através de uma S-CSCF over sobre a interface ISC definida pelo 3GPP. No último caso, Critério de Filtro Inicial (IFC) são usados por uma S-CSCF para determinar que ASs devem ser "conectados "durante um estabelecimento de sessão do SIP. Diferentes IFCs podem ser aplicados para diferentes casos de chamada. Os IFCs são recebidos pela S- CSCF provenientes de um HSS durante o Procedimento de registro no IMC como parte de um Perfil de Usuário (UP) do usuário. Certos ASs vão efetuar ações dependentes das identidades do assinante (ou do assinante chamado ou de quem chama, que sempre é "possuído "pela rede controlando o AS). Por exemplo, no caso de passar adiante a chamada, o servidor de aplicativo (terminando) apropriado vai determinar um nova parte de término para que a chamada seja passada adiante para um dado assinante.

As modalidade preferidas a serem descritas abaixo se referem a um canal de controle habilitado por IMS para uma caixa de topo de aparelho (STB) de IPTV. O canal de controle é configurado usando procedimentos do IMS padrões e é mais tarde usado para enviar mensagens de controle para o Servidor de Aplicativo de IPTV, assim como para despachar conteúdo personalizado, tal como anúncios, respostas de votação, acionamentos de votação personalizados e eventos interativos alvos. Com relação a isto é importante apreciar que a configuração do canal de controle pode ser feita diretamente a partir da própria STB do usuário ou pode ser feita de forma remota, usando o outro ID, de uma outra STB.

Há uma subscrição de IPTV única tendo uma identidade privada do IMS que pode ser a mesma como a "Assinatura IMS de linha de origem" como usado na "Arquitetura Rechon", EAB-05:045608, Rev A, .2005-12-22. As subscrição de IPTV contém vários IDs Públicos de IMS (IMPUs), isto é, um IMPU para cada STB. Mais precisamente, o IMPU é alocado para a MTRX, tal que, por exemplo, o IMPU é usado como um padrão para a MTRX se nenhum usuário individual (membro da família) se registrou nele (e. g. sip:tvl_subscrl7525@imsop.com). Há zero, um ou várias Identidades Públicas adicionais associadas com a Subscrição de IPTV, cada uma representando um usuário. Elas são usadas quando o usuário se registra à STB para serviços personalizados (e. g. sip:sickan@imsop.com). Identidades Públicas adicionais para usuários com Identidades Particulares (PIs) separadas, isto é IMPUs que não são da ISIM de IPTV ISIM, e. g. sip:sickan_mob@imsop2.com, são também possíveis. Elas são usadas quando o usuário se registra com esta identidade externa para o serviço de IPTV. Quando a STB inicia, primeiro se registra na rede de IMS rede usando o ID privado de IMS (IMPI - o endereço privado da STB) da identidade e o Módulo de IMS (IMOD) no cabeçalho de autorização, e o endereço público "STB da família "nos cabeçalhos "De" e "Para" (como na mensagem de REGISTER do SIP normal). Ambos IMPUs representando os Receptores/Transmissores de Mídia (MTRXs) e IMPUs representando os usuários podem se registrar. Para personalização de serviços, a rotina de uso de "Conexão de Usuário para o AS de MW de IPTV "mostrada na Figura 1 é executada. No máximo um usuário pode ser conectado ao AS para um MTRX a cada vez. (Quando um novo usuário se conecta, o AS ou recusa a nova conexão ou substitui o usuário antigo pelo um novo). Todas essas rotinas de uso secundário vão trabalhar na mesma maneira independente de se o acesso é proveniente de um telefone de comunicação móvel ou proveniente de uma STB com fio.

Referindo à Figura 1, a rotina de uso de "Conexão de Usuário para o AS de MW de IPTV "compreende os seguintes passos do processo (referindo para os números na figura):

1.0 MTRX é ligado e envia e envia uma indicação a este efeito para o IMOD que inclui seu endereço de IP.

2. O IMOD envia a Mensagem de REGISTER do SIP para a P-CSCF. O IMPU do MTRX é usado no cabeçalho de "Para ". O URI de SIP doméstico do nome do domínio da rede doméstica é incluído na Solicitação de URI. O IMPI do IMOD é incluído no cabeçalho de "Autorização ". O cabeçalho de contato inclui o endereço de IP do IMOD. Se o provedor de rede de acesso e o Operador do IMS são os mesmos, então a descoberta da P- CSCF é tratada através de um procedimento de DHCP (conforme as normas de IMS existentes). Se este não é o caso, a descoberta da P-CSCF poderia ser tratada através da configuração do SIM do IMS (ISIM). O ISIM contém um código de EF onde o endereço da P-CSCF é armazenada, tal que este é configurada através do operadora antes do ISIM ser distribuído para o usuário.

3. A P-CSCF usa o "nome de domínio doméstico "na mensagem de REGISTER do SIP para descobrir o ponto de entrada para rede domestica (isto é a I-CSCF). A P-CSCF envia a mensagem de REGISTER do SIP (endereço / nome da P-CSCF, Identidade Pública do Usuário, Identidade Privada do Usuário, identificador de rede da P-CSCF, endereço de IP do IMOD IP) para a I-CSCF. Um mecanismo de resolução de endereço de nome é utilizado de modo a determinar o endereço da rede doméstica a partir do nome de domínio doméstico. Um identificador de rede da P-CSCF é uma seqüência de dados que identifica, na rede doméstica, a rede onde a P-CSCF esta localizada. Por exemplo, o identificador de rede da P-CSCF pode ser o nome do domínio da rede da P-CSCF, conforme as normas de IMS existentes.

4. A I-CSCF envia os dados de Cx-Query/Cx-Select-Pull dados (Identidade Publica do Usuário, Identidade Privada do Usuário, Identificador de rede da P-CSCF) para o HSS, conforme as normas de IMS existentes. O HSS verifica se o usuário já está registrado. O HSS indica se ao usuário é permitido se registrar naquela rede da P- CSCF (identificada através de um identificador de rede da P-CSCF) de acordo com a usuário subscrição do usuário e das limitações / restrições (Cx-Query Resp/Cx-Select-Pull Resp/Cx-AV-Resp), se qualquer, conforme as normas de IMS existentes.

5. Os dados de Cx-Query Resp/Cx-Select-Pull Resp são enviados a partir do HSS para uma I-CSCF e contém o nome da S-CSCF, se este é conhecido pelo HSS, e as capacidades da S-CSCF, se for necessário para selecionar uma nova S-CSCF. Quando a resposta contém ambos o nome da S-CSCF e as capacidades da S-CSCF, a I- CSCF pode efetuar um nova atribuição. Quando somente as capacidades da S-CSCF são retornadas, a I- CSCF efetua a nova função de seleção da S-CSCF com base nas capacidades da S-CSCF retornada. Se a verificação no HSS fornece um resultado negativo, a Cx-Query Resp rejeita a tentativa de registro, conforme as normas de IMS existentes.

6. A I-CSCF, usando o nome da S-CSCF, determina o endereço da S-CSCF através de um mecanismo de resolução de endereço de nome. A I-CSCF então envia a mensagem de REGISTER do SIP (endereço / nome da P-CSCF Identidade Pública do Usuário, Identidade Privada do Usuário, Identificador de rede da P-CSCF, endereço de IP do IMOD) para a S-CSCF selecionada. O ponto de contato da rede doméstica é usado por uma P-CSCF para passar adiante uma mensagem de início de sessão para a rede doméstica. A S-CSCF armazena um endereço / nome da P-CSCF, como fornecido pela rede visitada, representando o endereço / nome que a rede doméstica emite no sinal de sessão terminando subseqüente para o IMOD. A S-CSCF armazena a informação do ID de rede da P- CSCF, conforme as normas de IMS existentes.

7-CSCF envia a solicitação de Cx-AV-Req solicitação para o HSS para solicitar o vetor de autenticação vetor, conforme as normas de IMS existentes.

8. O vetor de autenticação é recebido na Cx-AV-Resp, conforme as normas de IMS existentes.

9. A S-CSCF retorna uma resposta de 401 Não Autorizado com o vetor de autenticação, de acordo com as normas de IMS existentes.

10. A I-CSCF emite ρ vetor de autenticação para a P-CSCF em uma resposta de Não Autorizado, de acordo com as normas de IMS existentes.

11. A P-CSCF envia uma resposta de 401 Não Autorizado com um desafio (parte de RAND parte do vetor de autenticação) e uma rede de ficha de autenticação (AUTN) para o IMOD. O IMOD verifica que a AUTN está correto e calcula uma resposta para enviar para a rede. Neste passo o IMOD pode calcular o material de chave, com base no par de chave de CK e IK e um algoritmo conhecido (o algoritmo é publico e conhecido de ambos o IMOD e o AS de MW de IPTV).

Figura 2, de forma esquemática, ilustra os seguintes passos adicionais desta rotina (referindo aos números na figura):

1. O envio da mensagem de REGISTER do SIP a partir do IMOD para a P- CSCF em resposta ao desafio, desta vez com a resposta ao desafio incluída, de acordo com as normas de IMS existentes.

2. O envio da mensagem de REGISTER do SIP incluindo a resposta ao desafio a partir da P-CSCF para a I-CSCF, de acordo com as normas de IMS existentes. 3. O envio da mensagem de REGISTER do SIP incluindo a resposta ao desafio a partir da I-CSCF para a S-CSCF, de acordo com as normas de IMS existentes.

4. A verificação através de uma S-CSCF verifica que a resposta ao desafio está correta, e a transmissão dos dados de Cx-Put/Cx-Pull (Identidade Pública do Usuário, Identidade Privada do Usuário, nome da S- CSCF) para o HSS, de acordo com as normas de IMS existentes.

5. O armazenamento no HSS do nome da S-CSCF para aquele usuário e o retorno do dados da Cx-Put Resp/Cx-Pull Resp (informação do usuário) para a S-CSCF. A informação do usuário (Critério Inicial de Filtro) passado a partir do HSS para a S-CSCF inclui informação de nome e de endereço que pode ser usada para acessar a plataforma(s) usada para controle do serviço enquanto o usuário é registrado nesta S-CSCF. A S-CSCF armazena a informação para o usuário indicado.

6. O retorno através da S-CSCF de uma resposta de 200 OK.

7. A passagem adiante através da CSCF da resposta de 200 OK.

8. A passagem adiante através da P-CSCF da resposta de 200 OK.

9. A transmissão da mensagem "Registrado "mensagem a partir do IMOD para a MTRX.

Uma vez que a STB é registrada, ela estabelece uma conexão de TCP/TLS segura com o AS de IPTV, usando uma INVITE de SIP. O procedimento é como segue indicado de forma esquemática na Figura 3 (referindo aos números na figura):

1. O MTRX (o ponto final da mídia STB) indica para o IMOD (a parte de transporte de autenticação / ISIM da STB) que a conexão para o AS de MW de IPTV deve ser estabelecida. A diferenciação entre o IMOD e o MTRX é opcional, e pode ser visto como uma realização interna da STB. Uma STB não tendo esta diferenciação se comportaria de forma idêntica em relação à rede de IMS.

2. O IMOD envia uma INVITE de SIP para a P-CSCF. A Identidade Pública de Serviço do AS de MW de IPTV é usada para endereçar o AS de MW de IPTV e pode ser pré-configurada no ISIM ou configurada através de procedimentos de gerenciamento do dispositivo. Uma descrição do SDP de uma sessão de TLS / TCP é incluída. Um procedimento alternativo seria usar um protocolo de enquadramento de aplicação sobre um canal de TCP / TLS puro, tal como MSRP. Neste caso a descrição do SDP contém MSRP / TLS / TCP em vez de somente TLS / TCP.

3. A INVITE de SIP é passada adiante para a I-CSCF. 3GPP 23.228 descreve encaminhamento de PSI alternativo no lado de término, a saber:

a. A I-CSCF interroga I HSS onde o HSS trata cada PSI como um "usuário "e retorna instruções de encaminhamento para o ponto final representando a PSI.

b. Interrogação da I-CSCF para o HSS onde o HSS retorna o usuário alocado S-CSCF. A S-CSCF encaminha a Invite de PSI endereçado de acordo com a informação armazenada por "assinante de PSI ". A "assinante de PSI "é designada uma S-CSCF.

c. Encaminhamento de domínio secundário em uma I-CSCF onde a I-CSCF usa DNS para resolver a PSI em um endereço de IP para o 14

ponto final representando a PSI. Esta solução requer a Alternativa b.

4.A I-CSCF usa DNS para traduzir a Identidade Pública de Serviço para o endereço de IP endereço do servidor efetivo que vai tratar este usuário desta vez (compartilhamento de carga pode ser aplicado aqui). A S- CSCF então envia a INVITE de SIP para o AS de MW de IPTV escolhido. O AS de MW de IPTV então executa a subseqüência de "Dados de Usuário de Busca".

5.O AS de MW de IPTV retorna uma resposta de 200 OK. AO URL do portal de serviço de TV do usuário é incluído no SDP, como, por exemplo, um corpo de XML que é interpretado na STB mas não nos nós intermediários.

6.A S-CSCF emite a resposta de 200 OK.

7.A P-CSCF emite a resposta de 200 OK.

8.O IMOD recebe o URL do portal de serviço de TV do usuário padrão (isto é o portal associado com o IMPU do MTRX), e é incluído no SDP. Esta informação pode ser incluída como um corpo de XML na mensagem de 200 OK, mas outros meios também são possíveis.

9.O IMOD envia a resposta de ACK do SIP.

10.A P-CSCF emite a resposta de ACK do SIP.

11.A S-CSCF emite a resposta de ACK do SIP.

12.O IMOD configura uma conexão de TLS/TCP para o AS de MW de IPTV usando um certificado do lado do servidor.

A conexão de TLS/TCP pode então ser usada como um canal de controle "sempre conectado "dedicado para todas as mensagens de controle e de informação a serem transmitidas entre a STB e AS de IPTV. As mensagens de informação podem incorporar conteúdo personalizado que é armazenado em um banco de dados comum em algum lugar na rede de infra- estrutura. Este conteúdo será filtrado através dos registros de perfil do usuário que são armazenados no HSS ou algum outro "banco de dados de perfil de usuário e então despachado para algum As de IPTV(ou alternativamente o AS de IPTV pode ele mesmo direcionar o conteúdo de acordo com os filtros). O conteúdo é fornecido a partir do AS de IPTV para a STB por meio do canal de controle. As diferentes CSCF's não podem ver o conteúdo do canal criptografado e de fato o conteúdo não atravessa qualquer outro dos nós do IMS. O canal de controle é uma conexão fim a fim entre a STB e AS de IPTV.

Este procedimento também pode ser expandido para adicionar distribuição de chaves para proteção do serviço (a.k.a. acesso condicional) se a proteção do serviço no sistema é baseada em codificar as seqüências de conteúdo. Isto envolveria passos adicionais após o último passo acima nos quais, por exemplo, as chaves poderiam ser obtidas através do HTTP. Se os diferentes usuários têm diferentes agrupamentos de canais, então aquele tipo de passo também seriam necessário após procedimento de "Conexão do usuário, Usuário Local ".

Este procedimento poderia também ser executado somente em uma base de "conforme necessário "(isto é a conexão não seria automaticamente configurada no registro, mas somente quando acesso do AS de MW de IPTV é requerido), mas a alternativa preferida é que a conexão é estabelecida imediatamente após os registros de STB / MS. Isto é tal que o retardo em configurar esta conexão pode ser evitada no momento quando a interação como AS de MW de IPTV é requerida.

Um novo canal de controle é estabelecido para cada MTRX que é para ser conectado ao IMOD, como descrita na "IMS IPTV Architecture Study" ("Arquitetura Rechon", EAB-05: 045608, Rev A, 2005- 12-22).

O canal de controle descrito uma pletora de funcionalidades, como controle remoto na STB de IPTV, como descrito no "IMS IPTV Architecture Study ", EAB- 06:001721, Rev A, 2006-02-08, ou os casos do usuário descritos na próxima seção.

A subseqüência de "Dados de Usuário de Busca" referenciada acima é usada pelo AS de MS de IPTV para obter o material de chave baseado no par de chave CK e IK (resultando da autenticação de AKA do IMS durante o procedimento de registro) da S- CSCF. O material de chave pode ser derivado de CK e IK ou de algum outro meio. A derivação efetiva pode acontecer em um nó diferente da S- CSCF, que iria requerer alguma sinalização adicional entre a S-CSCF e o nó de derivação da chave (não mostrado na figura). Isto não é conforme as normas de IMS existentes, tal que isto teria um impacto no produto e normas. Uma outra possibilidade seria que a S-CSCF despacha o vetor de autenticação tpar ao A quando passando adiante o INVITE.

O procedimento é como a seguir, conforme mostrado, de forma esquemática, na Figura 4 (referindo aos números na figura):

l. A função de aplicativo de rede (NAF) no AS de IPTV emite uma solicitação de "Material de Chave de Busca" para o S-CSCF.

2. A Função de Servidor de Partida (BSF) da S-CSCF contata o Proxy de Diâmetro (D-Proxy) para obter o material de chave.

3. O D-Proxy contara a BSF da S-CSCF no domínio doméstico para a STB.

4. A BSF no domínio doméstico da STB despacha o material de chave para o D-Proxy no domínio do AS de IPTV.

5. O D-Proxy despacha o material de chave para a S-CSCF, que por sua vez o despacha para o AS de IPTV.

6. Com base no material de chave e de uma conhecido protocolo / algoritmo (o protocolo / algoritmo é publico e conhecido de ambos o IMOD e o AS de MW de IPTV, (e. g. Autenticação de Compilação) o IMOD é autenticado. Deve ser notado que o IMOD pode derivar o mesmo material de chave que o AS de MW de IPTV recebido in na seqüência anterior de INVITE.

Uma outra possível implementação é ter a BSF separada da S- CSCF que iria requerer sinalização de GAA / GBA explícita da STB e do AS de IPTV para as respectivas BSFs.

Uma vez que o canal de controle é estabelecido um guia de programa eletrônico (EPG) pode ser obtido a partir do AS de IPTV usando a conexão segura. O EPG pode ser personalizado para a particular subscrição do usuário correntemente registrado ou pode ser o EPG padrão para o tipo de subscrição que está STB contém. A seqüência como mostrado em forma de diagrama na Figura 5 é como a seguir (referindo aos números na figura):

1. O MTRX solicita o EPG para o usuário a partir do IMOD.

2. O usuário do IMOD solicita a lista do EPG como uma página de html, isto sendo feito usando a conexão segura configurada anteriormente para o AS de MW de IPTV.

3. O AS de MW de IPTV solicita os dados do EPG dados a partir do servidor de EPG.

4. O servidor de EPG envia os dados de XML do EPG XML para o AS de MW de IPTV.

5. O AS de MW de IPTV gera a página de html com a informação válida para o usuário correntemente registrado e envia it para o IMOD.

6. O IMOD retorna o EPG para o usuário do MTRX.

Quando um usuário quer ser "registrar "para o serviço de TV

para ter acesso a seu EPG pessoal, etc., um botão personalizado é pressionado no controle remoto, que aciona um novo registro no IMOD usando o IMPU do novo usuário. Se um outro usuário já está registrado para este MTRX, o IMOD fecha a sessão de TLS/TCP para aquele usuário e dês faz o registro do usuário.

Então o IMOD convida o AS de MW de IPTV usando a PSI. A P-Preferred-Identity é configurada para o IMPU do usuário "azul ". Uma descrição do SDP da sessão de TLS/TCP sessão é incluída. O resto do procedimento segue o caso geral.

Em intervalos pré-definidos, um conjunto de anúncios com base em filtros personalizados para o usuário corrente é fornecido através do canal de controle para o MTRX. Esses anúncios podem ser definidos tal que eles são exibidos em certas áreas da tela enquanto o usuário está vendo a TV, ou eles podem esperar a recepção de um particular acionador para forçá-los a serem exibidos em tela total na TV. Os filtros para anúncios personalizados são baseados na informação de perfil armazenada nos diferentes bancos de dados de IMS (HSS e outros) assim como na informação do que o particular usuário está vendo.

O canal de controle da STB permite o AS de IPTV conhecer o estado de "saúde "das diferentes STB conectada a ele. Através da definição de um mecanismo de se manter vivo adequado, que vai consumir muitos pequenos recursos já que o canal está sempre ativo, é possível fornecer atualizações de software para a STB e para efetuar certas funções iniciadas pelo servidor tal como atualizações de subscrição ou mesmo interação de ISIM a partir do operador.

A invenção fornece uma solução para interação da STB personalizada com um As de IPTV que pode ser usado para enviar e receber comandos de controle e para despachar qualquer particular item de informação que deve somente ser enviado de ou recebido por uma das STBs conectadas ao AS selecionada.

O canal de controle "sempre conectado "reduz a latência de configuração para todas as interações com o AS de IPTV, através do fornecimento de um tubo de dados com criptografia controlados por TCP que está sempre pronto a enviar e receber as diferentes mensagens requeridas. Este canal de controle também fornece o AS de IPTV com os meios para controlar o comprimento e estado de conexão status das diferentes subscrições de IPTVs, assim como fornecer um canal seguro alcançável facilmente para atualizações de software.

A invenção oferece uma mistura de serviços de IPTV, serviços de comunicação de IMS e serviços de informação personalizados.

Será apreciado pelas pessoas qualificadas na técnica que várias modificações podem ser feitas às modalidades descritas acima sem fugir do escopo da presente invenção.

Claims

1. Método para fornecer um canal de controle habilitado por IMS para um serviço de IPTV, caracterizado pelo fato de compreender: - receber em uma Função de Controle de Estado/Chamada de Serviço (S-CSCF), uma mensagem de REGISTER do Protocolo de Iniciação de Sessão (SIP), a mensagem de REGISTER do SIP identificando o usuário de origem; - receber no usuário de origem uma resposta da S-CSCF indicando que o usuário de origem foi autorizado; - enviar uma mensagem de INVITE do SIP da S-CSCF para estabelecer uma conexão de canal aberto com um Servidor de Aplicativo (AS) de IPTV selecionado; e - enviar e / ou receber mensagens de controle ou de informação através da conexão do canal aberto.

2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o canal de controle é configurado usando procedimentos do IMS padrões.

3. Método de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que as mensagens de controle ou de informação incluem mensagens do IMS para o AS de IPTV.

4. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que as mensagens de controle ou de informação incluem conteúdo personalizado, por exemplo relacionando um anúncio, uma resposta de votação, um acionamento de votação personalizado ou um evento interativo alvo.

5. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a mensagem de REGISTER do SIP é recebida de uma identidade e do Módulo de IMS (IMOD) e inclui um endereço de IP do IMOD.

6. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a mensagem de REGISTER do SEP é enviada em resposta à recepção de uma mensagem de ligação de um receptor/transmissor de mídia (MTRX) incluindo um endereço de IP da MTRX.

7. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a mensagem de REGISTER do SIP é recebida por uma Função de Controle de Estado/Chamada de Proxy (P- CSCF) que emite a mensagem de REGISTER do SIP para uma Função de Controle de Estado/Chamada de Interrogação (I-CSCF) para direcionar a mensagem de REGISTER do SIP em direção a uma S-CSCF selecionada.

8. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a S-CSCF retorna uma mensagem de autenticação em resposta à recepção da mensagem de REGISTER do SIP.

9. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a S- CSCF recebe uma mensagem de REGISTER do SIP incluindo uma resposta de desafio em reposta ao envio de uma mensagem de autenticação.

10. Método de acordo com a reivindicação 9, caracterizado pelo fato de que a S-CSCF efetua um sinal de verificação na resposta de desafio e envia uma mensagem de habilitação de conexão no evento de verificação positiva.

11. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a conexão segura estabelecida é uma conexão de TLS / TCP ou uma conexão de MSRP / TLS / TCP.

12. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a subseqüência de dados de usuário de busca é iniciada pelo AS de IPTV na recepção da mensagem de INVITE do SIP.

13. Canal de controle habilitado por IMS para um serviço de IPTV, caracterizado pelo fato de compreender: - meios de processamento para receber em uma Função de Controle de Estado/Chamada de Serviço (S-CSCF), uma mensagem de REGISTER do Protocolo de Iniciação de Sessão (SIP), a mensagem de REGISTER do SIP identificando o usuário de origem; para receber no usuário de origem uma resposta da S-CSCF indicando que o usuário de origem foi autorizado; para enviar uma mensagem de INVITE do SIP da S-CSCF para estabelecer uma conexão de canal aberto com um Servidor de Aplicativo (AS) de IPTV selecionado; e para enviar e / ou receber mensagens de controle ou de informação através da conexão do canal aberto.

14. Código de programa de computador, caracterizado pelo fato de realizar o método como definido em qualquer das reivindicações 1 a 12.