PT1987647E - Canal de controlo compatível com ims para iptv - Google Patents

Description

1 DESCRIÇÃO "CANAL DE CONTROLO COMPATÍVEL COM IMS PARA IPTV"

Campo da Invenção A presente invenção refere-se à provisão de um canal de controlo compatível com subsistema multimédia em IP (IP Multimedia Subsystem) (IMS) para um serviço de iptv, preferentemente, mas não necessariamente, utilizando um conversor (set top box) (STB).

Antecedentes Invenção

Os serviços de multimédia em IP proporcionam uma combinação dinâmica de voz, vídeo, mensagens, dados, etc. dentro da mesma sessão. Aumentado o número de aplicações básicas e as médias que são possíveis de combinar, é possível aumentar o número de serviços oferecidos aos utilizadores finais, e assim enriquecer a experiência de comunicação interpessoal. Isto levará a uma nova geração de serviços de comunicação multimédia rico, personalizado, incluindo os denominados serviços "multimédia em IP combinacional" que serão considerados em mais detalhe abaixo. 0 subsistema multimédia em IP (IMS) é a tecnologia definida pelo Projecto de parceria de 3a geração (Third Generation Partnership Project) (3GPP) para proporcionar serviços multimédia em IP sobre redes de comunicação por telemó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 publicações 5 a 7). 0 IMS proporciona características chave para enriquecer a experiência de comunicação pessoa-a-pessoa do utilizador final através da utilização de compatibilizadores de serviço IMS padronizados, que facilita novos serviços de comunicação pessoa-a-pessoa (cliente-a-cliente) ricos, assim como serviços pessoa-a-conteúdo (cliente-a-servidor) sobre redes baseadas em IP. 0 IMS faz uso do protocolo de iniciação de sessão (Session 2

Initiation Protocol) (SIP) para ajustar e controlar chamadas ou sessões entre terminais de utilizadores (ou terminais de utilizadores e servidores de aplicação). 0 protocolo de descrição de sessão (Session Description Protocol) (SDP), suportado por sinalização de SIP é utilizado para descrever e negociar os componentes de média da sessão. Enquanto que o SIP foi criado como um protocolo utilizador-a-utilizador, o IMS permite que operadores e prestadores de serviço controlem o acesso do utilizador a serviços e carregar utilizadores consequentemente.

As fronteiras entre os serviços proporcionador pelos operadores de telecomunicação, operadores de TV, e prestadores de serviço de Internet estão desaparecendo, e tais companhias estão todas oferecendo aos clientes todos os três serviços (denominado "oferta tripla" (triple play)). Para os operadores de telecomunicação que desejam oferecer serviços TV, uma escolha popular é utilizar a denominada IPTV que distribui o serviço de TV sobre IP e a conexão de banda larga do cliente (por exemplo, ADSL, VDSL, Ethernet pública, etc.). A 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). A distribuição de conteúdo linear, em que todos os canais numa assinatura ("pacote de programas") são simultaneamente distribuídos ao conversor (STB), não é adequada para IPTV devido à largura de banda limitada. A capacidade da conexão xDSL varia dependendo da versão de dsl utilizada e a distância da "primeira milha". ADSL pode proporcionar uma capacidade entre 3 até 8 Mbps, enquanto que ADSL2 promete distribuir até 25 Mbps a jusante e taxas de dados VSDL superiores a 30 Mbps. A qualidade padrão de conteúdo MPEG2 requer 2 Mbps por canal, e a HDTV requererá 8-10 Mbps por canal. Por sorte, o novo padrão MPEG4 diminuirá largura de banda requerida para a metade com a mesma qualidade que o 3 conteúdo codificado de MPEG2. Não obstante, a largura de banda disponível é um recurso escasso, e soluções para IPTV devem limitar o número de canais a serem distribuídos sobre a "primeira milha".

As soluções time-shift/chase-play existentes são ou baseadas em tecnologia de rede do proprietário ou em PVR na residência. A solução descrita no presente documento, utiliza o sistema de comunicação IMS padronizado e sua arquitectura de rede, e um PVR residente na Rede para limitar o tráfego transmitido sobre a conexão primeira milha a uma residência.

Com a convergência entre serviços de IPTV e a Infra-estrutura de IMS um novo conjunto de possibilidades se abrem para o utilizador final utilizar o conjunto de TV. Videoconferência, jogos interactivos, anúncios personalizados ou programas de TV interactivos com retorno dos espectadores se torna uma realidade que é facilmente alcançável utilizando o IMS. Contudo, muitas destas aplicações requerem a comunicação extensiva entre o STB e os diferentes servidores de aplicação, de modo que, a cada momento um novo serviço requer ser adicionado à experiência do utilizador (por exemplo, quando o utilizador recebe uma chamada de videoconferência enquanto está assistindo TV) utilizando um sistema de IPTV convencional, existe um atraso de ajuste associado com o ajuste de diferentes canais de controlo e recepção da informação requerida. "Digital cellular teleocommunications system (Phase 2+)", ETSI standards, European Telecommunications Standards Institute, Sophia-Antipo, FR, Bd. 3-CN1, Nr. V5150, Dezembro de 2005, apresenta um protocolo de controlo de chamada para utilização na rede de núcleo multimédia em IP baseado em SIP.

Sumário da Invenção 4 É um objecto da presente invenção proporcionar um canal de controlo compatível com IMS para um serviço de IPTV.

De acordo com um primeiro aspecto da presente invenção é proporcionado um método para proporcionar um canal de controlo compatível com IMS para um serviço de IPTV, o método compreendendo: receber numa função de serviço do controlador de estado de chamadas (S-CSCF) uma mensagem de protocolo de iniciação de sessão (SIP) register, a mensagem sip register identificando o utilizador de origem; receber no utilizador de origem uma resposta da S-CSCF indicando que o utilizador de origem foi autorizado; enviar uma mensagem SIP invite da S-CSCF para estabelecer um canal de controlo persistente aberto com um Servidor de aplicação (AS) IPTV seleccionado; e enviar e/ou receber mensagens de controlo ou informação como forma do canal de controlo persistente aberto.

Pela manutenção de um canal de controlo persistente aberto com o IPTV AS, a invenção oferece uma redução substancial nos tempos de atraso de ajuste para diferentes aplicações, assim como um único canal de controlo de dados comum que pode ser utilizado para contactar um STB. 0 IPTV AS assim se torna a 'porta de ligação comum' ao STB. A utilização de mecanismos de IMS para ajustar um canal de controlo persistente entre o STB e o IPTV AS desta maneira e a utilização do canal de controlo para distribuir toda a informação de controlo requerida desde o STB até o IPTV AS e desde o IPTV AS até o STB proporciona vantagens particulares em utilização. Em particular isto permite que um único canal de controlo seja utilizado para todas as informações de controlo diferentes das diferentes aplicações que podem ser mostradas na TV, assim como para toda a infra-estrutura de IMS para ajustar o canal de 5 controlo e controlar estas aplicações. 0 canal de controlo nunca será utilizado para o fluxo de média. A invenção é capaz de proporcionar um canal de controlo compatível com IMS para um conversor (STB) de IPTV. 0 canal de controlo pode ser ajustado utilizando procedimentos de IMS padrão e pode ser utilizado mais tarde para enviar mensagens de controlo, tais como para começar a jogar, começar a gravar, parar de jogar, etc. do STB, ao servidor de aplicações de IPTV, assim como para a distribuição de conteúdo personalizado, tais como anúncios, respostas de votação, desencadeamentos de votação personalizada e eventos interactivos dirigidos. A invenção proporciona uma solução para interacção com STB personalizada com um iptv AS permitindo o envio e a recepcão de comandos de controlo e itens particulares de informação que são somente requeridos para ser enviados desde, ou recebidos por, um seleccionado dos STB conectados aos AS.

Na concretização preferida da invenção a ser descrita abaixo canal de controlo 'sempre ligado' reduz o tempo de espera de ajuste para tal interacção com o IPTV AS, proporcionando uma canalização de dados controlado por TCP encriptado que está sempre pronta para enviar e receber as diferentes mensagens requeridas. O canal de controlo também proporciona o IPTV AS com o meio para controlar o comprimento e o estado de conexão das diferentes subscrições de IPTV, assim como proporcionar um canal seguro facilmente acessível para actualizações de software. A invenção permite uma mistura de serviços de IPTV, serviços de comunicação de IMS e serviços de informação personalizada.

De acordo com um aspecto adicional da presente invenção é proporcionado código de programa de computador para levar a cabo o método do primeiro aspecto da invenção. Breve Descrição dos Desenhos 6 A fim de que a invenção possa ser mais completamente compreendida, uma concretização preferida de acordo com a invenção será descrita agora, como forma de exemplo, com referência aos desenhos que acompanham, em que: A figura 1 é um diagrama esquemático que ilustra uma sequência no registo do STB; A figura 2 é um diagrama esquemático que ilustra uma sequência adicional no registo do STB; A figura 3 é um diagrama esquemático que ilustra o estabelecimento de uma conexão TCP/TLS segura; e A figura 4 é um diagrama esquemático que ilustra uma subsequência de "Busca de dados de utilizador"; e A figura 5 é um diagrama esquemático que ilustra o estabelecimento de um guia de programa electrónico (electronic program guide) (EPG).

Descrição Detalhada dos Desenhos

Como forma de base da concretização preferida o seguinte é uma breve descrição de como o subsistema multimédia em IP (IMS) se ajusta na arquitectura de rede de telemóvel no caso de uma rede de acesso GPRS/PS. Funções do controlador de sessão de chamadas (CSCF) operam como SIP proxies dentro do IMS. A arquitectura 3GPP define três tipos de CSCF: a Proxy CSCF (P-CSCF) que é o primeiro ponto de contacto dentro do IMS para um SIP terminal; o serviço CSCF (S-CSCF) que proporciona serviços ao utilizador que o utilizador é subscrito a; e o interrogante CSCF (I-CSCF) cujo papel e identificar o S-CSCF correcto e encaminhar a aquela S-CSCF uma requisição recebida de um terminal SIP via um P-CSCF.

Um utilizador regista com o IMS utilizando o método SIP REGISTER especificado, isto é um mecanismo para unir ao IMS e anunciar ao IMS o endereço no qual uma identidade de utilizador SIP pode ser alcançada. 0 utilizador recebe um identificador uniforme de recurso (Uniform Resource Identifier) (URI) único da S-CSCF para ser utilizado quando 7 inicia um diálogo. Em 3GPP, quando um terminal SIP realiza um registo, o IMS autentica o utilizador, e aloca uma S-CSCF para aquele utilizador a partir do conjunto de S-CSCF disponíveis. Embora os critérios para alocar S-CSCF não é especificado pelo 3GPP, estes podem incluir a partilha de carga e requisições de serviço. É notado que a alocação de uma S-CSCF é chave para controlar (e carregar para) acesso do utilizador a serviços baseados em IMS. Os operadores podem proporcionar um mecanismo para prevenir sessões SIP directo de utilizador-a-utilizador que de outra maneira desviaria da S-CSCF.

Durante o processo de registo, é a responsabilidade da I-CSCF seleccionar uma S-CSCF se uma ainda não está seleccionada. A I-CSCF recebe as capacidades de S-CSCF requeridas do servidor local do assinante (Home Subscriber Server) (HSS) da rede local, e selecciona um S-CSCF apropriado baseado nas capacidades recebidas. (Observa-se que a alocação de S-CSCF é também levada a cabo para um utilizador pela I-CSCF no caso em que o utilizador é chamado pela outra parte, e o utilizador não está actualmente alocado numa S-CSCF) . Quando um utilizador registado posteriormente envia uma requisição de sessão (por exemplo, SIP INVITE) ao IMS, a requisição incluirá os URI de P-CSCF e S-CSCF de modo que a P-CSCF é capaz de encaminhar a requisição à S-CSCF seleccionada. Isto se aplica tanto no lado de origem como de terminação (do IMS). (Para terminação da chamada a requisição incluirá o endereço da P-CSCF e o endereço do equipamento do utilizador (User Equipment) (UE)).

Dentro da rede de serviço de IMS, Servidores de aplicação (AS) são proporcionados para implementar a funcionalidade de serviço de IMS. AS proporcionam serviços a utilizadores finais num sistema de IMS, e podem estar conectados ou como pontos finais sobre a interface Mr definida por 3GPP, ou "ligados" (línked in) por uma S-CSCF 8 sobre a interface ISC definida por 3GPP. No último caso, critérios de filtro inicial (Initial Filter Criteria) (IFC) são utilizados por uma S-CSCF para determinar que AS deveriam ser "ligadas" durante um estabelecimento de sessão SIP. Diferentes IFC podem ser aplicados para diferentes casos de chamadas. Os IFC são recebidos pela S-CSCF de um HSS durante o procedimento de registo de IMS como parte de um Perfil de Utilizador (User Profile) (UP) do utilizador. Certos AS realizarão acções dependentes das identidades do assinante (ou o assinante chamado ou que chama, qualquer que seja é "possuído" pelo controlador de rede o AS) . Por exemplo, no caso de encaminhamento de chamadas, o servidor de aplicação apropriado (terminação) determinará a nova parte de terminação ao qual uma chamada a um dado assinante será encaminhada. A concretização preferida a ser descrita a seguir refere-se a um canal de controlo compatível com IMS para um conversor (STB) de IPTV. 0 canal de controlo é ajustado utilizando procedimentos de IMS padrão e é utilizado posteriormente para enviar mensagens de controlo ao servidor de aplicações de IPTV, assim como para distribuir conteúdo personalizado, tais como anúncios, respostas de votação, desencadeamentos de votação personalizada e eventos interactivos dirigidos. Com respeito a isso é importante apreciar que o ajuste do canal de controlo pode ser feito directamente do próprio STB do utilizador ou pode ser feito remotamente, utilizando a outra ID, desde outro STB .

Existe uma única assinatura de IPTV tendo uma identidade privada de IMS que pode ser igual que a "assinatura de IMS de linha local " como utilizado em "Rechon Architecture" ', EAB-05 :045608, Rev A, 2005-12-22 . A assinatura de IPTV contém vários ID públicos de IMS ( IMS Public ID) (IMPU), que é um IMPU para cada STB. Mais precisamente, o IMPU é alocado ao MTRX, de modo que, por 9 exemplo, o IMPU é utilizado como um predefinido (default) para o MTRX se nenhum utilizador individual (membro da família) iniciou sessão no mesmo (por exemplo, sip: tvl_subscrl7525@imsop.com). Existem zero, um ou várias identidades públicas adicionais associadas com a assinatura de IPTV, cada uma representando um utilizador. Estas são utilizadas quando o utilizador inicia sessão no STB para serviços personalizados (por exemplo, sip: sickan@imsop.com). Identidades públicas adicionais para utilizadores com identidades privadas (Private Identities) (Pi) separadas, que é IMPUs que não são da IPTV ISIM, por exemplo, sip: sickan_mob0imsop2.com, são também possíveis. Estas são utilizadas quando o utilizador inicia sessão com esta identidade externa ao serviço de IPTV.

Quando o STB inicia, ele primeiro regista na rede de IMS utilizando a ID privada de IMS (IMS Private ID) (IMPI -o endereço privado do STB) do módulo de identidade e IMS (identity and IMS Module) (IMOD) no cabeçalho de autorização, e o endereço público de 'STB familiar' predefinido nos cabeçalhos "De" e "Para" (como na mensagem SIP REGISTER normal). Ambas IMPU representando os transmissores/receptores de média (Media Transmitter/Receivers) (MTRX) e IMPU representando utilizadores podem registar. Para personalização de serviços, a "Conexão de Utilizador a IPTV MW AS" que utiliza a rotina representada na figura 1 é executada. No máximo um utilizador pode ser conectado ao AS para um MTRX num momento. (Quando um novo utilizador conecta, o AS ou recusa a nova conexão ou substitui o antigo utilizador com o novo). Todas estas rotinas de sub-utilização trabalharão da mesma maneira independentemente se o acesso é desde um telemóvel ou desde um STB de telefonia fixa.

Referindo-se a Figura 1, a rotina de utilização "Conexão de utilizador a IPTV MW AS" compreende as 10 seguintes etapas de processo (referindo-se aos números na figura) : 1. O MTRX é inicializado e envia uma indicação para este efeito ao IMOD que inclui seu endereço de IP. 2. O IMOD envia uma mensagem SIP REGISTER à P-CSCF. A IMPU do MTRX é utilizada no cabeçalho "para". O URI de SIP local do nome de dominio de rede local é incluído na requisição de URI. A IMPI do IMOD é incluída no cabeçalho de "Autorização". O cabeçalho de contacto inclui o endereço de IP do IMOD. Se o provedor de rede de acesso e o operador de IMS são o mesmo, então a descoberta de P-CSCF é manejada por um procedimento DHCP (como para padrões de IMS existentes). Se este não é o caso, a descoberta de P-CSCF poderia de manejada pela configuração de IMS SIM (ISIM) . O ISIM contém um EF onde o endereço de P-CSCF é armazenado, de modo que isto é configurado pelo operador antes do ISIM ser distribuído ao utilizador. 3. A P-CSCF utiliza o "nome de domínio local" na mensagem SIP REGISTER para descobrir o ponto de entrada à rede local (isto é, a I-CSCF). A P-CSCF envia a mensagem SIP REGISTER (endereço de P-CSCF/nome,

Identidade de utilizador público, Identidade de utilizador privado, identificador de rede da P-CSCF, Endereço de IP do IMOD) à I-CSCF. Um mecanismo de resolução de nome-endereço é utilizado a fim de determinar o endereço da rede local a partir do nome de domínio local. O identificador de rede da P-CSCF é uma cadeia de caracteres que identifica, na rede local, a rede onde a P-CSCF está localizada. Por exemplo, o identificador de rede da P-CSCF pode ser o nome de domínio da rede P-CSCF, como para padrões de IMS existentes. 4. A I-CSCF envia os dados de Cx-Query/Cx-Select-Pull (Identidade de utilizador público, Identidade de 11 utilizador privado, identificador de rede da P-CSCF) ao HSS, como para padrões de IMS existentes. O HSS averigua se o utilizador já está registado. O HSS indica se o utilizador é permitido para registar naquela rede da P-CSCF (identificada pelo identificador de rede da P-CSCF) de acordo com a assinatura do utilizador e limitações/restrições do operador (Cx-Query Resp/Cx-Select-Pull Re-sp/Cx-AV-Resp), se existe alguma, como para padrões de IMS existentes. 5. Os dados de Cx-Query Resp/Cx-Select-Pull Resp são enviados desde o HSS até a I-CSCF e contém o nome da S-CSCF, se é conhecida pelo HSS, e as capacidades da S-CSCF, se é necessário para seleccionar uma nova S-CSCF. Quando a resposta contém tanto o nome da S-CSCF como as capacidades da S-CSCF, a I-CSCF pode realizar uma nova atribuição. Quando somente as capacidades da S-CSCF são retornadas, a I-CSCF realiza a nova função de selecção de S-CSCF baseada nas capacidades da S-CSCF retornadas. Se a averiguação no HSS proporciona um resultado negativo, o Cx-Query Resp rejeita a tentativa de registo, como para padrões de IMS existentes. 6. A I-CSCF, utilizando o nome da S-CSCF, determina o endereço da S-CSCF através de um mecanismo de resolução de nome-endereço. A I-CSCF então envia a mensagem SIP REGISTER (endereço de P-CSCF/nome, Identidade de utilizador público, Identidade de utilizador privado, identificador de rede da P-CSCF, Endereço de IP do imod) à S-CSCF seleccionada. 0 ponto de contacto da rede local é utilizado pela P-CSCF para encaminhar uma mensagem de iniciação de sessão à rede local. A S-CSCF armazena o endereço de P-CSCF/nome, como fornecido pela rede visitada, representando o endereço/nome que a rede local encaminha no posterior sinal de terminação de sessão ao IMOD. A S-CSCF armazena a informação de ID de rede da P-CSCF, como para padrões de IMS existentes. 12 7. A S-CSCF envia a requisição Cx-AV-Req ao HSS para requerer o vector de autenticação, como para padrões de IMS existentes. 8. 0 vector de autenticação é recebido no Cx-AV-Resp, como para padrões de IMS existentes. 9. A S-CSCF retorna uma resposta 401 Unauthorized com o vector de autenticação, como para padrões de IMS existentes. 10. A I-CSCF encaminha o vector de autenticação à P-CSCF em uma resposta 401 Unauthorized, como para padrões de IMS existentes. 11. A P-CSCF envia uma resposta 401 Unauthorized com um desafio (parte RAND do vector de autenticação) e um testemunho de autenticação de rede (network authentication token) (AUTN) ao IMOD. O IMOD verifica que o AUTN é correcto e calcula uma resposta para enviar à rede. Nesta etapa o IMOD pode calcular o material chave, baseado no par de chaves CK e IK e um algoritmo conhecido (o algoritmo é público e conhecido tanto para o IMOD como para o IPTV MW AS). A figura 2 ilustra esquematicamente as seguintes etapas adicionais desta rotina (referindo-se aos números na figura): 1. O envio de uma mensagem SIP REGISTER desde o IMOD à P-CSCF em resposta ao desafio, esta vez com o desafio e resposta incluído, como para padrões de IMS existentes. 2. O envio da mensagem SIP REGISTER incluindo o desafio e resposta desde a P-CSCF à I-CSCF, como para padrões de IMS existentes. 3. O envio da mensagem SIP REGISTER incluindo o desafio e resposta desde a I-CSCF à S-CSCF, como para padrões de IMS existentes. 4. A verificação pela S-CSCF verifica que o desafio e resposta é correcto, e a transmissão dos dados de Cx-Put/Cx-Pull (Identidade de utilizador público, 13

Identidade de utilizador privado, S-CSCF nome) ao HSS, como para padrões de IMS existentes. 5. O armazenamento no HSS do nome da S-CSCF para aquele utilizador e o retorno dos dados Cx-Put Resp/Cx-Pull Resp (informação do utilizador) à S-CSCF. A informação do utilizador (critérios de filtro inicial) passado desde o HSS à S-CSCF inclui informação de nome e endereço que pode ser utilizado para aceder a(s) plataforma(s) utilizada(s) para controlo de serviço enquanto que o utilizador é registado na sua S-CSCF. A S-CSCF armazena a informação para o utilizador indicado. 6. 0 retorno pela S-CSCF de uma resposta 200 OK. 7. O encaminhamento pela I-CSCF da resposta 200 OK. 8. O encaminhamento pela P-CSCF da resposta 200 OK. 9. A transmissão da "mensagem Registered" desde o IMOD a MTRX.

Uma vez que o STB é registado, estabelece uma conexão TCP/TLS segura com o IPTV AS, utilizando um SIP INVITE. O procedimento é como segue como indicado esquematicamente na figura 3 (referindo-se aos números na figura): 1. O MTRX (o ponto final de média do STB) indica ao IMOD (a parte portadora de Autenticação / ISIM do STB) que uma conexão ao IPTV MW AS deve ser estabelecida. A diferenciação entre o IMOD e o MTRX é opcional, e pode ser vista como uma realização interna do STB. Um STB que não tem esta diferenciação se comportaria de maneira idêntica em relação à rede do IMS. 2. O IMOD envia um SIP INVITE à P-CSCF. A identidade de serviço pública do IPTV MW AS é utilizada para dirigir o IPTV MW AS e pode ser preconfigurada no ISIM ou configurado por procedimentos de gestão de dispositivo. Uma descrição de SDP de uma sessão TLS/TCP é incluída. Um procedimento alternativo poderia ser utilizar um protocolo de enquadramento de aplicação sobre o canal 14 TCP/TLS puro, tal como MSRP. Neste caso a descrição de SDP contém MSRP/TLS/TCP ao invés de somente TLS/TCP. 3. O SIP INVITE é encaminhado à I-CSCF. 3GPP 23.228 descreve encaminhamento de PSI alternativo no lado de terminação, concretamente: a. A I-CSCF interroga I HSS onde o HSS trata cada PSI como um "utilizador" e retorna instruções de encaminhamento ao ponto final representando o PSI. b. Interrogação da I-CSCF ao HSS onde o HSS retorna o S-CSCF alocado ao utilizador. A S-CSCF encaminha o convite endereçado a PSI de acordo com a informação de IFC armazenada por "PSI-assinante". O "PSI-assinante' é designado uma S-CSCF. c. Encaminhamento de subdominio na I-CSCF onde a I-CSCF utiliza DNS para resolver o PSI num endereço de IP para o ponto final representando o PSI. Esta solução requer alternativa b. 4. A I-CSCF utiliza DNS para traduzir a Identidade de serviço pública ao endereço de IP do servidor actual que manejará este utilizador esta vez (a partilha de carga pode ser aplicada aqui). A S-CSCF então envia o SIP INVITE ao IPTV MW AS escolhido. O IPTV MW AS então executa a subsequência de "Busca de dados de utilizador". 5. O IPTV MW AS retorna uma resposta 200 OK. O URL do portal de serviço de TV do utilizador é incluído no SDP, como, por exemplo, um corpo XML que é interpretado no STB, mas não nos nós intermediários. 6. A S-CSCF encaminha a resposta 200 OK. 7. A P-CSCF encaminha a resposta 200 OK. 8. O IMOD recebe o URL do portal de serviço de TV do utilizador predefinido (isto é, o portal associado à IMPU do MTRX), e é incluído no SDP. Esta informação pode ser incluída como um corpo XML na mensagem 200 OK, mas outros meios são também possíveis. 15 9. 0 IMOD envia uma resposta SIP ACK. 10. A P-CSCF encaminha a resposta SIP ACK. 11. A S-CSCF encaminha a resposta SIP ACK.

12. O IMO D ajusta uma conexão TLS/TCP ao IPTV MW AS utilizando um certificado lateral de servidor. A conexão TLS/TCP então pode ser utilizada como um canal de controlo dedicado "sempre ligado" (always on) para todo o controlo requerido e mensagens de informação para serem transmitidas entre o STB e o IPTV AS. As mensagens de informação podem incorporar conteúdo personalizado que é armazenado numa base de dados comum em algum lugar na infra-estrutura da rede. Este conteúdo será filtrado através dos registos de perfil do utilizador que são armazenados no HSS ou alguma outra 'base de dados de perfil de utilizador', e então distribuída ao IPTV AS (ou alternativamente o próprio IPTV AS pode direccionar o conteúdo de acordo com os filtros). O conteúdo é fornecido do IPTV AS ao STB como forma do canal de controlo. As diferentes CSCF não podem ver o conteúdo do canal encriptado e de facto o conteúdo não atravessa nenhum dos outros nós de IMS. O canal de controlo é uma conexão fim-afim entre o STB e o IPTV AS.

Este procedimento também pode ser expandido para adicionar distribuição de chaves para protecção de serviço (também conhecido como acesso condicional) se a protecção do serviço no sistema é baseada em cifrar as correntes de conteúdo. Isto envolveria etapas adicionais após a última etapa acima em que, por exemplo, as chaves poderiam ser buscadas via HTTP. Se os diferentes utilizadores têm diferentes grupos de canais, então aquele tipo de etapa também seria necessária após o procedimento de "Conexão de utilizador, Utilizador Local".

Este procedimento também poderia ser executado somente numa base "conforme necessário" (as needed) (isto é, a conexão não seria automaticamente ajustada no registo, mas 16 somente quando o acesso ao IPTV MW AS é requerido), mas a alternativa preferida é que a conexão seja estabelecida imediatamente após os registos STB/MS. Isto é de modo que o atraso em ajustar esta conexão pode ser evitado num momento quando a interacção com o IPTV MW AS é requerida.

Um novo canal de controlo é estabelecido para cada MTRX que é para ser conectado ao IMOD, como descrito no "IMS IPTV Architecture Study" ("Rechon Architecture", EAB-05:045608, Rev A, 2005-12-22). O canal de controlo descrito permite muitas funcionalidades, como controlo remoto no IPTB STB, como descrito em "IMS IPTV Architecture Study", EAB-06: 001721, Rev A, 2006-02-08, ou os casos de utilizador descritos na próxima secção. A subsequência de "Busca de dados de utilizador" citada anteriormente é utilizada pelo IPTV MS AS para obter o material chave baseado no par de chaves CK e IK (que resulta da autenticação IMS AKA durante o procedimento de registo) da S-CSCF. O material chave pode ser derivado de CK e IK ou por algum outro meio. A derivação actual pode ocorrer num nó diferente da S-CSCF, que requereria alguma sinalização adicional entre a S-CSCF e o nó derivado da chave (não mostrado na figura) . Isto não é por padrões de IMS existentes, de modo que isto teria um produto e impacto de padrões. Outra possibilidade seria que a S-CSCF distribui o vector de autenticação ao AS quando encaminha o INVITE. O procedimento é como segue, como mostrado esquematicamente na figura 4 (referindo-se aos números na figura): 1. A Função de aplicação de rede (Network Application function) (NAF) no IPTV AS emite uma requisição de 'Material chave de busca' à S-CSCF. 17 2. A função de arranque do servidor (Bootstrapping Server Function) (BSF) da S-CSCF contacta a Diameter proxy (D-Proxy) para obter o material chave. 3. A D-Proxy contacta a BSF da S-CSCF no domínio local para o STB. 4. A BSF no domínio local do STB distribui o material chave ao D-Proxy no domínio do iptv AS. 5. 0 D-Proxy distribui o material chave à S-CSCF, que por sua vez o distribui ao IPTV-AS. 6. Baseado no material chave e um protocolo/ algoritmo conhecido (o protocolo/algoritmo é público e conhecido tanto para o IMOD como para o IPTV MW AS, por exemplo, Autenticação Digest) o IMOD é autenticado. Deve ser observado que o IMOD pode derivar o mesmo material chave que o IPTV MW AS recebido na sequência INVITE anterior.

Outra possível implementação é ter a BSF separada da S-CSCF que requereria sinalização GAA/GBA explícita do STB e o IPTV AS aos respectivos BSF.

Uma vez que o canal de controlo é estabelecido um guia de programa electrónico (EPG) pode ser buscado a partir do IPTV AS utilizando a conexão segura. O EPG pode ser customizado para a assinatura particular do utilizador actualmente com sessão iniciada ou pode ser o EPG predefinido para o tipo de assinatura que este STB contém. A sequência como apresentado diagramaticamente na figura 5 é como segue (referindo-se aos números na figura): 1. 0 MTRX requer o EPG para o utilizador a partir do IMOD . 2. 0 utilizador de IMOD requer a lista de EPG como uma página html, isto sendo feito utilizando a conexão segura previamente ajustada ao IPTV MW AS. 3. 0 IPTV MW AS requer os dados de EPG a partir do servidor de EPG. 18

4. 0 servidor de EPG envia os dados de EPG XML ao IPTV MW AS. 5. O IPTV MW AS gera a página html com a informação válida para o utilizador actualmente com sessão iniciada e a envia ao IMOD. 6. 0 IMOD retorna o EPG para o utilizador ao MTRX.

Quando um utilizador quer "iniciar sessão" ao serviço de TV para ter acesso a sua EPG pessoal, etc., um botão de personalização é pressionado no controlo remoto, que dispara um novo registo no IMOD utilizando a IMPU do novo utilizador. Se outro utilizador já estava registado para este MTRX, o IMOD fecha a sessão TLS/TCP para aquele utilizador e desregista o utilizador.

Então o IMOD convida o iptv MW AS utilizando o PSI. The P-Preferred-Identity é ajustado ao IMPU do utilizador "blue". Uma descrição de SDP de uma sessão TLS/TCP é incluída. 0 resto do procedimento segue o caso geral.

Em intervalos predefinidos, um conjunto de anúncios baseado em filtros personalizados para utilizador actual são fornecidos sobre o canal de controlo ao MTRX. Estes anúncios podem ser definidos de modo que são apresentados em certas áreas da ecrã enquanto o utilizador está assistindo a TV, ou podem esperar a recepção de um desencadeamento particular para causar que sejam apresentados em ecrã total na TV. Os filtros para anúncios personalizados são baseados na informação de perfil armazenadas das diferentes bases de dados de IMS (HSS e outros), assim como na informação de que o utilizador particular está assistindo. 0 canal de controlo de STB permite que o IPTV AS conheça o estado 'health' dos diferentes STB conectados ao mesmo. Definindo um mecanismo de manutenção adequado, que consumirá muito poucos recursos já que o canal é estará sempre ligado, é possível fornecer actualizações de software ao STB e realizar certas funções iniciadas pelo 19 servidor tais como actualizações de assinatura ou inclusive interacção ISIM a partir do operador. A invenção proporciona uma solução para interacção de STB personalizada com um IPTV AS que pode ser utilizado para enviar e receber comandos de controlo e para distribuir qualquer item particular de informação que somente deve ser enviada de ou recebida por um seleccionado de todos os STB conectados ao AS. 0 canal de controlo 'sempre ligado' reduz o tempo de espera de ajuste para todas interacções com o IPTV AS, proporcionando uma canalização de dados controlado por TCP encriptado que está sempre pronta para enviar e receber as diferentes mensagens requeridas. Este canal de controlo também proporciona o IPTV AS com o meio para controlar o comprimento e o estado de conexão das diferentes subscrições de IPTV, assim como proporcionar um canal seguro facilmente alcançável para actualizações de software. A invenção oferece uma combinação de serviços de IPTV, serviços de comunicação IMS e serviços de informação personalizados.

Será apreciado pelos peritos na especialidade que várias modificações podem ser feitas às concretizações descritas acima sem se afastar do âmbito da presente invenção.

Lisboa, 28/12/2010

Claims (14)

1 REIVINDICAÇÕES 1. Um método para proporcionar um canal de controlo compatível com IMS para um serviço de iptv, o método compreendendo: receber numa função de serviço do controlador de estado de chamadas, S-CSCF, uma mensagem de protocolo de iniciação de sessão, SIP, REGISTER, a mensagem SIP REGISTER identificando o utilizador de origem, receber no utilizador de origem uma resposta da S-CSCF indicando que o utilizador de origem foi autorizado; caracterizado por enviar uma mensagem SIP INVITE da S-CSCF para estabelecer um canal de controlo persistente aberto com um servidor de aplicação AS de IPTV seleccionado; e enviar e/ou receber mensagens de controlo ou informação como forma do canal de controlo persistente aberto.

2. Um método de acordo com a reivindicação 1, em que o canal de controlo persistente aberto é ajustado utilizando procedimentos de IMS padrão.

3. Um método de acordo com a reivindicação 1 ou 2, em que as mensagens de controlo ou informação incluem mensagens de IMS ao IPTV AS.

4. Um método de acordo com qualquer uma das reivindicações anteriores, em que as mensagens de controlo ou informação incluem conteúdo personalizado, por exemplo, relacionado a um anúncio, uma resposta de votação, um desencadeamento de votação personalizada ou um evento interactivo dirigido.

5. Um método de acordo com qualquer uma das reivindicações anteriores, em que a mensagem SIP REGISTER é 2 recebida desde um módulo de identidade e IMS, IMOD, e inclui um endereço de IP do IMOD.

6. Um método de acordo com qualquer uma das reivindicações anteriores, em que a mensagem SIP REGISTER é enviada em resposta ao recebimento de uma mensagem de inicialização desde um receptor/transmissor de média, MTRX, incluindo um endereço de IP da MTRX.

7. Um método de acordo com qualquer uma das reivindicações anteriores, em que a mensagem SIP REGISTER é recebida por uma função de Proxy do controlador de estado de chamadas, P-CSCF, que encaminha a mensagem SIP REGISTER a uma função de interrogar do controlador de estado de chamadas, I-CSCF, para direccionar a mensagem SIP REGISTER para uma S-CSCF seleccionada.

8. Um método de acordo com qualquer uma das reivindicações anteriores, em que a S-CSCF devolve uma mensagem de autenticação em resposta ao recebimento da mensagem SIP REGISTER.

9. Um método de acordo com qualquer uma das reivindicações anteriores, em que a S-CSCF recebe uma mensagem SIP REGISTER incluindo um desafio e resposta em resposta ao envio de uma mensagem de autenticação.

10. Um método de acordo com a reivindicação 9, em que a S-CSCF realiza uma averiguação de verificação no desafio e resposta e envia uma mensagem permitindo a conexão no caso de verificação positiva.

11. Um método de acordo com qualquer uma das reivindicações anteriores, em que a conexão segura 3 estabelecida é uma conexão TLS/TCP ou uma conexão MSRP/TLS/TCP.

12. Um método de acordo com qualquer uma das reivindicações anteriores, em que uma subsequência de busca de dados do utilizador é iniciada pelo IPTV AS no recebimento da mensagem sip invite.

13. Um sistema de controlo compatível com IMS para um serviço de IPTV, compreendendo: meio de processamento para receber numa função de serviço do controlador de estado de chamadas S-CSCF uma mensagem protocolo de iniciação de sessão, SIP, REGISTER, a mensagem SIP REGISTER identificando o utilizador de origem, o meio de processamento para receber no utilizador de origem uma resposta da S-CSCF indicando que o utilizador de origem foi autorizado, caracterizado por o meio de processamento enviar uma mensagem SIP INVITE da S-CSCF para estabelecer um canal de controlo persistente aberto com um servidor de aplicação, AS de IPTV seleccionado; e o meio de processamento enviar e/ou receber mensagens de controlo ou informação através do canal de controlo persistente aberto.

14. Código de programa de computador para levar a cabo o método de acordo com qualquer das reivindicações 1 a 12. Lisboa, 28/12/2010 MTfiX ÍMOD : Tçwef On" fi-CSCF 2: SfP REGISTAR .........-->;·1· 1/4 i-CSÇF - ··>- HSS 4: GX-Qu»y Sc Οί*Ουείγ*β65β i <£.·.......*....................._ 10:401 urtátAhorfzedk:................... 1: 401 unavihortzecl <------------------------;- Figura 1 &CSCF ; p^lIOiO. irnp^ío C*é '.jptv : O-SiPRSGISTER j 8i C X-AV- R ôô-R&à p jI .....................;s: Θ; 4ói u»iautrwia&0 \ MTRX HWOO ; FM&CF \ 1 KISCF HSS .s^st-esreR ί : 2: Sff> REGKTER , 3: -StP· REGiSTER > > C 200 OK fPTVMÃÀS i 1 ) gTO-MWAS 7.-2000K << B: 200 OK j 9: "ReffSteiwr ι·Ίτ --------- · Figura 2 MTRV 'T iMOR > P-CSCF 2: srp ΓΝΥΤΓΕ .........V·'·-'............>>: SPO judies que uma sessão TIS/TCP deve ser estabelecida e rem um» iines e eem o ewiefeço :p CO ílíTRX O PS! do iPTV MW AS è «wvRtedo A P-Prsfered-icentity contém c IMPU predetinido de MTRXO MfeeçeRto de Contado osfttém c endereço da ÍMOD 100 OK fTorta; UR!.) <---------------------- 8: OoskOoí :C'' 0: SIP ACK > 12; 2/4 Figura 3 "i Γ tiSS 3: SlP INVJTE ·> 6:200 OK (Porta) Uft) 4: St!' tNVTFE ..............1...........

\ Aqui & subsequènosa de \ "Busca de derioa do uttiaainr" i è execuíada Obsei’«-se qu* IMSAS nío é ™ mastetfo. mas se o canal TLS/TEP ft tteftnkfo como serviço da teitdonis i mÍilomaríis, eníaç o líWITE, esc d ; w ACK ííSo ...................; 10: SIP ACK TLCjICP utiii^-aíKiQ <»n{>íic«<íq laterai servido»· rl&ÓK(Port&tURL> 11: SIP ACK 3/4

Figura 4 Observação, 0 D-Proxy e BSF1 tipicamente seriam co-localizada numa implementação de producto 4/4 ! MTRX 1 i IMOD ! 1 IPTVMWÁS 1 l j ! ] ] | 1: Requer EPG :> EPG 2: Requer EPG ------------------------> 3: Requer EPG —.....-..............> K- 4: EPG (XMLj K 5: EPG (HTML) 6: EPG Figura 5