BRPI0520180B1

BRPI0520180B1 - Método para iniciar uma comunicação de subsistema multimídia ip para um usuário.

Info

Publication number: BRPI0520180B1
Application number: BRPI0520180-2A
Authority: BR
Inventors: Terrill Stephen; Przybysz Hubert
Original assignee: Telefonaktiebolaget Lm Ericsson
Priority date: 2005-04-01
Filing date: 2005-04-01
Publication date: 2018-08-14
Also published as: ES2379964T3; ATE541393T1; EP1864522A1; EP2317725B1; KR20080007232A; EP1864522B1; WO2006102943A1; JP4960341B2; EP2317725A3; CN101151914B; US20090089435A1; KR101139072B1; CN101151914A; JP2008536379A; BRPI0520180A2; EP2317725A2

Abstract

métodos para iniciar uma comunicação de subsistema multimídia ip para um usuário, para operar um servidor de aplicação, para operar uma função de controle de estado/chamada de interrogação, para operar uma função de controle de estado/chamada de serviço e para assegurar sinalização enviada entre um servidor de função de controle de chamada/estado de um subsistema multimídia ip e um servidor de aplicação de protocolo de iniciação de sessão. método para iniciar uma comunicação de subsistema multimídia ip para um usuário que não está registrado a priori com o subsistema multimídia ip. o método compreende receber uma requisição de comunicação do citado usuário em um servidor de aplicação de protocolo de iniciação de sessão, via uma interface para uma rede externa, ou receber um estímulo gerado internamente ou externamente, requerendo o estabelecimento de uma comunicação de subsistema multirnídia ip, alocar uma função de controle de estado/chamada de serviço para o usuário, redirecionar uma requisição sip a partir do servidor de aplicação à função de controle de estado/chamada de serviço alocada, e estabelecer a comunicação requisitada.

Description

(54) Título: MÉTODO PARA INICIAR UMA COMUNICAÇÃO DE SUBSISTEMA MULTIMÍDIA IP PARA UM USUÁRIO.

(51) Int.CI.: H04L 29/06 (73) Titular(es): TELEFONAKTIEBOLAGET LM ERICSSON (72) Inventor(es): STEPHEN TERRILL; HUBERT PRZYBYSZ (85) Data do Início da Fase Nacional: 28/09/2007

1/14 “MÉTODO PARA INICIAR UMA COMUNICAÇÃO DE SUBSISTEMA MULTIMÍDIA IP PARA UM USUÁRIO”

Campo da invenção [0001] A presente invenção relaciona-se a um método e aparelho para iniciar comunicações baseadas em Subsistema Multimídia IP (IMS) e, em particular, para iniciar comunicações para usuários que não estão registrados com o IMS. Fundamentos da Invenção [0002] Serviços Multimídia IP (IPMM) provêem uma combinação dinâmica de voz, vídeo, geração de mensagens, dados, etc., dentro da mesma sessão. Pelo crescimento dos números de aplicações básicas e meios que é possível combinar, o número de serviços oferecidos aos usuários finais crescerá, e a experiência de comunicação interpessoal será enriquecida. Isto conduzirá a uma nova geração de serviços de comunicação multimídia ricos, personalizados, incluindo os assim chamados serviços “Multimídia IP combinacional” que são considerados em mais detalhe abaixo.

[0003] Subsistema Multimídia IP (IMS) é a tecnologia definida pelo Projeto de Parceria de 3^a Geração (3GPP) para prover serviços Multimídia IP através de redes de comunicação móveis (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 e TS 29.329 Edição 5 e Edição 6. IMS provê características chave para enriquecer a experiência de comunicação de pessoa a pessoa do usuário final, através da integração e interação de serviços. IMS permite novas comunicações pessoa a pessoa (cliente a cliente) bem como pessoa a conteúdo (cliente a servidor) através de uma rede baseada em IP. O IMS faz uso do Protocolo de Iniciação de Sessão (SIP) para configurar e controlar chamadas ou sessões entre terminais de usuário (ou terminais de usuário e servidores de aplicação). O Protocolo de Descrição de Sessão (SDP), transportado pela sinalização SIP, é usado para descrever e negociar os componentes de mídia da sessão. Enquanto o SIP foi criado como um protocolo de usuário para usuário, o IMS permite que operadoras e provedores de serviço controlem o acesso de usuário a serviços e cobrem aos usuários de acordo.

Petição 870180045299, de 28/05/2018, pág. 7/24

2/14 [0004] Figura 1 ilustra esquematicamente como o IMS se ajusta na arquitetura de rede móvel no caso de uma rede de acesso GPRS/PS. As Funções de Controle de Chamada/Sessão (CSCF) operam como proxies SIP com o IMS. A arquitetura 3GPP define três tipos de CSCF: a CSCF Proxy (P-CSCF) que é o primeiro ponto de contato dentro do IMS para um terminal SIP; a CSCF de Serviço (S-CSCF) que provê serviços ao usuário final ao qual o usuário é subscrito; e a CSCF de Interrogação (I-CSCF) cujo papel é identificar a S-CSCF correta e redirecionar para aquela S-CSCF uma requisição recebida de um terminal SIP via uma P-CSCF.

[0005] Um usuário se registra no IMS usando o método SIP REGISTER especificado. Este é um mecanismo para anexar ao IMS e anunciar ao IMS o endereço no qual uma identidade de usuário SIP pode ser alcançada. No 3GPP, quando um terminal SIP efetua um registro, o IMS autentica o usuário, e aloca uma S-CSCF a aquele usuário a partir do conjunto de S-CSCF disponível. Embora os critérios para alocar as S-CSCF não sejam especificados pelo 3GPP, estes podem incluir compartilhamento de carga e exigências de serviço. É notado que a alocação de uma S-CSCF é chave para controlar (e cobrar) acesso de usuário a serviços baseados em IMS. As operadoras podem prover um mecanismo para evitar sessões SIP diretas de usuário a usuário o que, caso contrário, contornaria a S-CSCF.

[0006] Durante o processo de registro, é responsabilidade da I-CSCF selecionar uma S-CSCF, se uma S-CSCF já não foi selecionada. A I-CSCF recebe as capacidades S-CSCF requeridas do Servidor de Assinante Doméstico (HSS) da rede doméstica e seleciona uma S-CSCF apropriada com base nas capacidades recebidas. [É notado que a alocação de S-CSCF é também levada para um usuário pela I-CSCF no caso em que o usuário é chamado por uma outra parte, e o usuário não está correntemente alocado a uma S-CSCF]. Quando um usuário registrado envia subseqüentemente uma requisição de sessão ao IMS, a P-CSCF é capaz de enviar a requisição à S-CSCF selecionada, com base na informação recebida da SCSCF durante o processo de registro.

[0007] Dentro da rede de serviço IMS, servidores de aplicação (AS) são providos para implementar funcionalidade de serviço IMS. Enquanto foi originalmente

Petição 870180045299, de 28/05/2018, pág. 8/24

3/14 visualizado que os AS operariam como “escravos” para os CSCF IMS, respondendo a requisições delegadas pelas S-CSCF, este não precisa ser o caso e realmente não é esperado que os AS possam ter interfaces para redes externas (isto é, não 3GPP), e podem receber um estímulo interno para executar uma ação (por exemplo, expiração de um temporizador). Figura 2 ilustra a interface de Controle de Serviço IMS (ISC) entre um AS e uma S-CSCF, bem como outras interfaces dentro do IMS. Embora o AS na Figura 2 seja mostrado como tendo somente uma única interface com uma S-CSCF, será verificado que, na prática, a interface ISC se estenderá através de uma rede de comunicação a qual muitos (ou todos) os servidores CSCF de uma dada rede de operadora estão conectados, permitindo que um AS se comunique com todos estes CSCF. [Outras entidades ilustradas na Figura 1 serão bem conhecidas dos especialistas na técnica].

[0008] Uma interface adicional (Ut) existe entre o AS e o terminal de usuário (TS 23.002) embora isto não seja mostrado na figura. A interface Ut habilita o usuário a gerenciar informação relacionada a seus serviços, por exemplo, criação e designação de Identidades de Serviço Público, gerenciamento de políticas de autorização que são usadas, por exemplo, por serviços de “presença”, gerenciamento de política de conferência, etc.

[0009] A arquitetura IMS atual permite que um AS inicie uma sessão IMS em resposta à recepção pelo AS de uma requisição apropriada através de uma interface externa. Pode-se, por exemplo, visualizar que uma requisição de sessão IMS é enviada ao AS através de uma interface HTTP, onde um usuário inicia o envio de uma requisição, acessando uma página da web na Internet. Neste caso, na recepção da requisição de sessão, o AS contactará primeiramente um Servidor de Assinante Doméstico (HSS) do usuário iniciador, para determinar se o usuário já é registrado ou não com o IMS. O AS envia ao HSS uma identidade SIP gerada para o usuário e que o HSS pode usar para determinar se o usuário é registrado ou não. Caso afirmativo, o HSS enviará ao AS a identidade da S-CSCF já alocada ao usuário. O AS então enviará um SIP INVITE à S-CSCF identificada e o procedimento de configuração de sessão continuará conforme ilustrado na Figura 3.

Petição 870180045299, de 28/05/2018, pág. 9/24

4/14

Um exemplo de cenário onde esta situação pode surgir é onde um assinante móvel 3GPP é registrado com o IMS, e o assinante então se conecta via um PC doméstico a uma página da web e requisita uma sessão IMS através daquele canal.

[0010] Se é o caso em que o usuário não está registrado ainda com o IMS, e isto é relatado ao AS pelo HSS, a requisição não pode ser processada. TS.228 declara especificamente que “Se o AS não puder adquirir um endereço S-CSCF para a Identidade de Usuário Público, o AS não iniciará uma sessão, em benefício do usuário”.

[0011] Será verificado que um problema similar surge onde o estímulo para estabelecer uma sessão IMS é gerado internamente, dentro do AS. Por exemplo, pode-se visualizar um cenário onde o AS tenha sido requisitado a executar uma atualização de um status de usuário em um servidor de presença em um instante requisitado. Como no caso de um serviço originado externamente, os padrões atuais permitirão que o AS inicie a sessão IMS requerida, somente se o usuário em questão for registrado no IMS.

[0012] Embora a discussão acima se relacione a um usuário que se supõe se um usuário possuindo uma identidade de usuário público, o usuário pode ser uma aplicação, isto é, possuir uma identidade de serviço público.

Sumário da Invenção [0013] É reconhecido que usuários podem desejar acessar serviços IMS mesmo quando ainda não estão registrados no IMS, e em particular onde o meio que estão usando para iniciar a requisição de comunicação IMS não facilita o registro IMS. [0014] De acordo com um primeiro aspecto da presente invenção, é provido um método para iniciar uma comunicação de Subsistema Multimídia IP para um usuário que não está registrado a priori com o Subsistema Multimídia IP, o método compreendendo:

receber uma requisição de comunicação do dito usuário em um Servidor de Aplicação de Protocolo de Iniciação de Sessão, via uma interface para uma rede externa, ou receber um estímulo gerado internamente ou externamente, requerendo o estabelecimento de uma comunicação de Subsistema Multimídia IP;

Petição 870180045299, de 28/05/2018, pág. 10/24

5/14 alocar uma Função de Controle de Estado/Chamada de Serviço para o usuário;

redirecionar uma requisição de Protocolo de Iniciação de Sessão a partir do Servidor de Aplicação à Função de Controle de Estado/Chamada de Serviço alocada; e estabelecer a comunicação requisitada.

[0015] Em uma primeira realização da presente invenção, a etapa de alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário é realizada pelo Servidor de Aplicação. O Servidor de Aplicação obtém capacidades de Função de Controle de Estado/Chamada de Serviço de um Servidor de Assinante Doméstico e aloca uma Função de Controle de Estado/Chamada de Serviço baseado nestas capacidades. [AS precisa ter ou ser capaz de obter conhecimento de uma S-CSCF disponível]. O Servidor de Aplicação então envia uma requisição de Protocolo de Iniciação de Sessão à Função de Controle de Estado/Chamada de Serviço alocada. [0016] Em uma segunda realização da presente invenção, a etapa de alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário é realizada por uma Função de Controle de Estado/Chamada de Interrogação. O Servidor de Aplicação envia uma requisição de Protocolo de Iniciação de Sessão à Função de Controle de Estado/Chamada de Interrogação e em resposta a Função de Controle de Estado/Chamada de Interrogação obtém capacidades de Função de Controle de Estado/Chamada de Serviço a partir de um Servidor de Assinante Doméstico e aloca uma Função de Controle de Estado/Chamada de Serviço com base nestas capacidades. A Função de Controle de Estado/Chamada de Interrogação então envia a requisição de Protocolo de Iniciação de Sessão à Função de Controle de Estado/Chamada de Serviço alocada.

[0017] Em uma terceira realização da invenção, a etapa de alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário é realizada por uma Função de Controle de Estado/Chamada de Serviço. O Servidor de Aplicação envia uma requisição de Protocolo de Iniciação de Sessão a uma Função de Controle de Estado/Chamada de Serviço e em resposta aquela CSCF de Serviço obtém

Petição 870180045299, de 28/05/2018, pág. 11/24

6/14 capacidades de Função de Controle de Estado/Chamada de Serviço de um Servidor de Assinante Doméstico e aloca uma Função de Controle de Estado/Chamada de Serviço com base nestas capacidades. A Função de Controle de Estado/Chamada de Serviço então envia uma requisição de Protocolo de Iniciação de Sessão à Função de Controle de Estado/Chamada de Serviço alocada, se a Função de Controle de Estado/Chamada de Serviço alocada não for ela própria.

[0018] Será verificado que o Servidor de Aplicação pode inicialmente não ter conhecimento de que o usuário não está registrado com o Subsistema Multimídia IP, e enviará um questionamento ao Servidor de Assinante Doméstico para determinar se o usuário é registrado ou não. No sentido de prover segurança melhorada, a resposta do Servidor de Assinante Doméstico informando o Servidor de Aplicação de que o usuário não é registrado, pode ser acompanhada por uma “ficha” de segurança (“security token”). Esta ficha de segurança provê um meio para autenticar o Servidor de Aplicação, e está incluída na requisição de Protocolo de Iniciação de Sessão enviada pelo Servidor de Aplicação. Uma Função de Controle de Estado/Chamada de Serviço alocada é capaz de autenticar a requisição de Protocolo de Iniciação de Sessão como originada de um Servidor de Aplicação válido, por exemplo, redirecionando a ficha de segurança ao Servidor de Assinante Doméstico e se apoiando no Servidor de Assinante Doméstico para retornar as capacidades da Função de Controle de Estado/Chamada de Serviço somente se a ficha é válida.

[0019] De acordo com um segundo aspecto da presente invenção, é provido um método para operar um Servidor de Aplicação, no sentido de iniciar uma comunicação de Subsistema Multimídia IP para um usuário que não está registrado a prioricom o Subsistema Multimídia IP, o método compreendendo:

receber uma requisição de comunicação do dito usuário, via uma interface para uma rede externa, ou receber um estímulo gerado internamente ou externamente requerendo o estabelecimento de uma comunicação de Subsistema Multimídia IP;

alocar uma Função de Controle de Estado/Chamada de Serviço ao

Petição 870180045299, de 28/05/2018, pág. 12/24

7/14 usuário; e redirecionar uma requisição de Protocolo de Iniciação de Sessão à Função de Controle de Estado/Chamada de Serviço alocada [0020] De acordo com um terceiro aspecto da presente invenção, é provido um método para operar uma Função de Controle de Estado/Chamada de Interrogação no sentido de iniciar uma comunicação de Subsistema Multimídia IP para um usuário que não está registrado a priori com o Subsistema Multimídia IP, o método compreendendo:

receber uma requisição de comunicação associada ao dito usuário, de um Servidor de Aplicação;

alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário; e redirecionar uma requisição de Protocolo de Iniciação de Sessão à Função de Controle de Estado/Chamada de Serviço alocada [0021] De acordo com um quarto aspecto da presente invenção, é provido um método para operar uma Função de Controle de Estado/Chamada de Serviço no sentido de iniciar uma comunicação Subsistema Multimídia IP para um usuário que não está registrado a priori com o Subsistema Multimídia IP, o método compreendendo:

alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário; e se a Função de Controle de Estado/Chamada de Serviço alocada é uma Função de Controle de Estado/Chamada de Serviço diferente dela própria, redirecionar uma requisição de Protocolo de Iniciação de Sessão à Função de Controle de Estado/Chamada de Serviço alocada.

[0022] De acordo com os padrões relevantes, a Função de Controle de Estado/Chamada de Serviço alocada recebe um perfil específico de identificador de usuário do Servidor de Assinante Doméstico. Este perfil deveria incluir suporte para

Petição 870180045299, de 28/05/2018, pág. 13/24

8/14 as chamadas de origem não registradas.

[0023] De acordo com um quinto aspecto da presente invenção é provido um método de tornar segura sinalização enviada entre um servidor de Função de Controle de Chamada/Estado de um Subsistema Multimídia IP e um Servidor de Aplicação de Protocolo de Iniciação de Sessão, a sinalização sendo associada a um estabelecimento de comunicação para um usuário, o método compreendendo:

enviar uma ficha de segurança de um Servidor de Assinante Doméstico do usuário a um servidor de Função de Controle de Chamada/Estado ou Servidor de Aplicação de Protocolo de Iniciação de Sessão;

enviar a ficha de segurança recebida do servidor de Função de Controle de Chamada/Estado ou Servidor de Aplicação de Protocolo de Iniciação de Sessão ao outro Servidor de Aplicação de Protocolo de Iniciação de Sessão ou Função de Controle de Chamada/Estado; e no servidor de Função de Controle de Chamada/Estado de recepção ou Servidor de Aplicação de Protocolo de Iniciação de Sessão, verificar a autenticidade da ficha de segurança, comunicando-se com o Servidor de Assinante Doméstico. [0024] O termo “comunicação” conforme usado aqui abrange ambos procedimentos de estabelecimento de sessão e procedimentos de estabelecimento de não-sessão incluindo, por exemplo, trocas de mensagens SIP simples.

Breve Descrição dos Desenhos [0025] Figura 1 ilustra esquematicamente a integração de um Subsistema Multimídia IP em um sistema de comunicações móveis 3G;

[0026] Figura 2 ilustra esquematicamente certas entidades do Subsistema Multimídia IP incluindo um Servidor de Aplicação e uma Função de Controle de Estado/Chamada de Serviço;

[0027] Figura 3 é um diagrama de sinalização ilustrando sinalização associada à iniciação de uma sessão de Subsistema Multimídia IP por um Servidor de Aplicação; [0028] Figura 4 é um diagrama de sinalização ilustrando sinalização associada à iniciação de uma sessão de Subsistema Multimídia IP por um Servidor de Aplicação de acordo com uma primeira realização da invenção;

Petição 870180045299, de 28/05/2018, pág. 14/24

9/14 [0029] Figura 5 é um diagrama de sinalização ilustrando sinalização associada à iniciação de uma sessão de Subsistema Multimídia IP por um Servidor de Aplicação, de acordo com uma segunda realização da invenção; e [0030] Figura 6 é um diagrama de sinalização ilustrando sinalização associada à iniciação de uma sessão de Subsistema Multimídia IP por um Servidor de Aplicação, de acordo com uma terceira realização da invenção.

Descrição Detalhada de Certas Realizações [0031] O problema que a presente invenção equaciona é que, de acordo com o estado da técnica, um Servidor de Aplicação (AS) de Protocolo de Iniciação de Sessão (SIP) não pode iniciar uma requisição SIP em beneficio de um usuário não registrado sem o Subsistema Multimídia IP (IMS), enquanto ainda permite a introdução de uma Função de Controle de Estado/Chamada de Serviço no caminho de sinalização, para prover análise de serviço de origem. Isto pode, entretanto, ser requerido no caso em que o AS está utilizando um outro protocolo (não SIP) para se comunicar com o usuário (por exemplo, HTTP, SMS, MMS, ou outro protocolo multimídia [ou um estímulo interno surge dentro do AS, por exemplo relacionado à atualização do status de presença em um instante especificado], e o usuário requer que o AS inicie uma requisição SIP em seu benefício.

[0032] O conceito básico empregado aqui é alocar uma Função de Controle de Estado/Chamada de Serviço (S-CSCF) quando o AS determina que uma S-CSCF ainda não foi alocada ao usuário (por exemplo, o usuário não está registrado com o IMS). Uma vez que uma S-CSCF tenha sido alocada, a S-CSCF informa ao Servidor de Assinante Doméstico (HSS) que está agora alocada como a CSCF de Serviço, enquanto mantém o status de usuário não registrado, e a S-CSCF transfere o perfil de usuário. A requisição de sessão AS fornecida ao IMS é tratada como uma requisição original. Três realizações alternativas serão agora consideradas, começando do ponto onde o AS tenha recebido uma requisição de iniciação de sessão IMS através de uma interface não SIP. [Outras possibilidades para iniciar o processo incluem a geração de um estímulo interno dentro do AS, por exemplo como um resultado do usuário “programar” o AS via a interface Ut, e a recepção de

Petição 870180045299, de 28/05/2018, pág. 15/24

10/14 um estímulo externo de uma fonte que não o usuário].

Alocação S-CSCF efetuada pelo Servidor de Aplicação [0033] O fluxo de sinalização associado a esta primeira realização é ilustrado na Figura 4, onde as etapas do processo são como segue:

1. O AS tenta recuperar o endereço S-CSCF para o usuário, contatando o Servidor de Assinante Doméstico (HSS) através da interface Sh (Figura 1) enviando uma identidade SIP do usuário, gerada em benefício do usuário, ao HSS. O AS determina que o usuário é não registrado e que uma S-CSCF não foi alocada ao usuário.

2. O AS requisita as capacidades de S-CSCF do HSS.

3. O HSS retorna as capacidades S-CSCF ao AS através da interface Sh. Esta funcionalidade é nova, pois correntemente capacidades S-CSCF podem somente ser transferidas através da interface Cx.

4. O AS executa seleção S-CSCF de acordo com alguns critérios predefinidos, cujos detalhes não são relevantes aqui. (Correntemente, esta funcionalidade reside na I-CSCF).

5. O AS gera uma requisição SIP (por exemplo, um SIP INVITE) incluindo uma identidade de usuário (por exemplo, sip:username@operator.com). A requisição SIP é enviada à S-CSCF selecionada através da interface ISC. [O endereço IP do AS é identificado para a S-CSCF no cabeçalho IP].

6. A S-CSCF recupera o perfil de usuário a partir do HSS e informa ao HSS que este é agora a S-CSCF alocada ao usuário, enquanto mantém o estado não registrado do usuário no HSS. A S-CSCF grava o mapeamento entre a identidade SIP alocada e o endereço IP do AS.

7. O HSS retorna o perfil de usuário à S-CSCF. O perfil de assinante pode agora incluir informação de perfil de serviço não registrado de origem, bem como registrado na origem, registrado na terminação e informação de perfil de serviço não registrado de terminação.

8. A S-CSCF executa qualquer controle de serviço com base no perfil de usuário recebido (por exemplo, conectando a um AS adicional), e grava o

Petição 870180045299, de 28/05/2018, pág. 16/24

11/14 mapeamento entre a identidade SIP alocada e o endereço IP do AS. O controle de serviço pode envolver, por exemplo, utilizar filtros de tela para controlar o acesso do usuário a serviços IMS.

9. A requisição SIP é enviada ao destino apropriado.

10. Uma resposta SIP é recebida do destino.

11. A resposta SIP é enviada ao AS. Isto estabelece a sessão SIP. Alocação S-CSCF executada pela I-CSCF [0034] O fluxo de sinalização associado a esta segunda realização é ilustrado na Figura 5, onde as etapas de processo são conforme segue:

1. O AS tenta recuperar o endereço S-CSCF para o usuário, a partir do HSS. O AS determina que o usuário é não registrado e que uma S-CSCF não foi alocada ao usuário, conforme descrito acima.

2. O AS requisita uma ficha de segurança do HSS. Isto é requerido no sentido da S-CSCF alocada (ver abaixo) confirmar que a requisição é válida. Sem este mecanismo de segurança há o risco de que uma outra entidade SIP (por exemplo, um usuário SIP registrado) possa enviar uma requisição de iniciação de sessão adulterada a uma S-CSCF, e que a S-CSCF seja incapaz de distinguir esta requisição adulterada de uma requisição válida enviada a ela por um AS. Enquanto algum identificador é incluído na requisição para identificar a requisição como originada em um AS, esta é uma identidade que pode ser copiada e pode então trazer uma ameaça de segurança.

3. O HSS retorna ao AS com uma ficha de segurança. O HSS deveria autenticar o AS e deveria autorizar o AS a atuar em benefício do usuário, antes de gerar a ficha de segurança.

4. O AS envia uma requisição SIP, incluindo a ficha de segurança (e a identidade de usuário e o endereço IP do AS) a uma I-CSCF designada.

5. A I-CSCF executa um questionamento Cx e uma troca de seleção por pressão Cx com o HSS, para obter as capacidades S-CSCF requeridas.

6. O HSS responde ao questionamento Cx e seleção por pressão Conexão, provendo as capacidades S-CSCF requeridas.

Petição 870180045299, de 28/05/2018, pág. 17/24

12/14

7. A I-CSCF executa seleção S-CSCF usando os critérios predefinidos.

8. A requisição SIP é enviada da I-CSCF para a S-CSCF novamente com a ficha de segurança. A I-CSCF não deveria Gravar Rota desta requisição pois esta não precisa permanecer no caminho de sinalização SIP após o estabelecimento da sessão.

9. A S-CSCF recupera o perfil de usuário do HSS e informa ao HSS que agora é a S-CSCF para o usuário, enquanto mantém o estado não registrado do usuário. A ficha de segurança é incluída nas requisições Cx-put/Cx-pull. Se a validade da ficha é confirmada pelo HSS, então a S-CSCF sabe que a requisição SIP chegou de um AS válido. Novamente, este perfil pode incluir informação de perfil não registrada de origem.

10. O HSS retorna o perfil de usuário à S-CSCF (supondo que a ficha é válida).

11. A S-CSCF executa qualquer controle de serviço requerido, com base no perfil de usuário recebido.

12. A requisição SIP é enviada ao destino.

13. Uma resposta SIP é recebida do destino.

14. A resposta SIP é enviada à I-CSCF.

15. A resposta SIP é enviada ao AS.

[0035] [SIP especifica que a resposta SIP precisa atravessar os mesmos nós atravessados pela requisição SIP. Daí, o S-CSCF não envia a reposta diretamente ao AS].

Alocação S-CSCF executada pela S-CSCF [0036] O fluxo de sinalização associado a esta terceira realização é ilustrado na Figura 6, onde as etapas do processo são como segue:

1. O AS tenta recuperar o endereço S-CSCF para o usuário. O AS determina que o usuário é não registrado e que uma S-CSCF não foi alocada ao usuário.

2. O AS requisita uma ficha de segurança do HSS. Isto é requerido no sentido da S-CSCF (ver abaixo) verificar que a requisição veio de um AS válido.

Petição 870180045299, de 28/05/2018, pág. 18/24

13/14

3. O HSS responde com uma ficha de segurança. O HSS deveria autenticar o AS e deveria autorizar o AS a agir em benefício do usuário, antes de gerar a ficha de segurança.

4. O AS envia a requisição SIP, incluindo a ficha de segurança, a uma SCSCF adequada, por exemplo, o AS pode fazer uma adivinhação educada como para a S-CSCF mais provável, com base em dados históricos para o usuário em questão.

5. A S-CSCF executa uma troca de questionamento Cx e seleção por pressão Cx com o HSS, para obter as capacidades S-CSCF requeridas.

6. O HSS responde ao questionamento Cx e seleção por pressão Cx, provendo as capacidades S-CSCF requeridas à S-CSCF. Esta é uma nova funcionalidade, pois previamente as capacidades S-CSCF requeridas são somente incluídas nos procedimentos Cx para a I-CSCF.

7. A S-CSCF executa seleção S-CSCF. Esta pode selecionar a si mesma se tiver as capacidades S-CSCF requeridas.

8. A requisição SIP é enviada da S-CSCF de alocação à S-CSCF alocada, juntamente com a ficha de segurança. [A S-CSCF de Seleção não deveria gravar rota da requisição].

9. A S-CSCF alocada recupera o perfil do usuário do HSS e informa ao HSS que é agora a S-CSCF para o usuário, enquanto mantém o status de não registrado do usuário. A ficha de segurança é incluída nas requisições Cx-put/Cxpull. Se a ficha é validada pelo HSS para aquele usuário, então a S-CSCF sabe que a requisição SIP veio de um AS válido.

10. O HSS retorna o perfil do usuário à S-CSCF alocada, supondo que a ficha é válida. Novamente, este perfil inclui informação de perfil não registrado de origem.

11. A S-CSCF executa qualquer controle de serviço requerido com base no perfil de usuário recebido.

12. A requisição SIP é enviada ao destino apropriado.

13. Uma resposta SIP é recebida do destino.

Petição 870180045299, de 28/05/2018, pág. 19/24

14/14

14. A resposta SIP é enviada à primeira S-CSCF.

15. A resposta SIP é enviada ao AS.

[0037] Embora os procedimentos detalhados acima se relacionam a um AS iniciando uma sessão SIP com um usuário associado ao um Identificador de Usuário Público (PUI), estes também são aplicáveis a um AS iniciando uma sessão SIP com um “usuário” associado a um Identificador de Serviço Público (PSI). O PSI é descrito em 3GPP TS 23.228.

[0038] Será verificado por uma pessoa especialista na técnica que várias modificações podem ser feitas às realizações descritas acima, sem se afastar do escopo da presente invenção. Em um exemplo de modificação, o mecanismo de ficha de segurança descrito acima com referência à segunda e terceira realizações, pode também ser empregado com a primeira realização, no sentido de permitir ao HSS (em benefício da S-CSCF alocada) validar o AS a partir do qual uma requisição SIP foi recebida.

[0039] Será adicionalmente verificado pela pessoa especialista na técnica, que o uso de uma ficha de segurança emitida pelo HSS pode ser aplicado para assegurar comunicações relacionadas a IMS que não sejam aquelas relacionadas a prover serviços IMS a usuários não registrados. Por exemplo, uma ficha de segurança emitida pelo HSS pode ser usada em geral para prover um meio melhor de segurança para sinalização enviada da S-CSCF para um AS (isto é, para assegurar toda a sinalização ISC). Em particular, quando a S-CSCF recebe um perfil de usuário do HSS (isto é, no registro SIP do usuário), também receberá uma ficha de segurança. Na recepção desta ficha pelo AS, o AS precisa verificar que a ficha de segurança é válida (comunicando-se com o HSS através da interface Sh). A ficha de segurança provavelmente teria um tempo de vida limitado.

Petição 870180045299, de 28/05/2018, pág. 20/24

1/3

Claims

REIVINDICAÇÕES

1. Método para iniciar uma comunicação de Subsistema Multimídia IP para um usuário que não está registrado a priori com o Subsistema Multimídia IP, caracterizado pelo fato de compreender:

receber uma requisição de comunicação do dito usuário não registrado em um Servidor de Aplicação de Protocolo de Iniciação de Sessão, via uma interface para uma rede externa, ou receber um estímulo gerado internamente ou externamente, requerendo o estabelecimento de uma comunicação de Subsistema Multimídia IP;

alocar uma Função de Controle de Estado/Chamada de Serviço para o usuário não registrado;

enviar uma requisição de Protocolo de Iniciação de Sessão a partir do Servidor de Aplicação à Função de Controle de Estado/Chamada de Serviço alocada; e estabelecer a comunicação requisitada.
2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a dita etapa de alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário é realizada pelo Servidor de Aplicação.
3. Método de acordo com a reivindicação 2, caracterizado pelo fato de que o Servidor de Aplicação obtém capacidades de Função de Controle de Estado/Chamada de Serviço de um Servidor de Assinante Doméstico e aloca uma Função de Controle de Estado/Chamada de Serviço com base nestas capacidades, e então envia uma requisição de Protocolo de Iniciação de Sessão à CSCF de Serviço alocada.
4. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a dita etapa de alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário é realizada por uma CSCF de Interrogação, quando da recepção de uma requisição de Protocolo de Iniciação de Sessão a partir do Servidor de Aplicação.
5. Método de acordo com a reivindicação 4, caracterizado pelo fato de que o Servidor de Aplicação envia a requisição SIP à CSCF de Interrogação, e, em

Petição 870180045299, de 28/05/2018, pág. 21/24

2/3 resposta, a CSCF de Interrogação obtém capacidades de Função de Controle de Estado/Chamada de Serviço de um Servidor de Assinante Doméstico e aloca uma Função de Controle de Estado/Chamada de Serviço com base nestas capacidades, a CSCF de Interrogação enviando então a requisição de Protocolo de Iniciação de Sessão à CSCF de Serviço alocada.
6. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a dita etapa de alocar uma Função de Controle de Estado/Chamada de Serviço ao usuário é realizada por uma CSCF de Serviço.
7. Método de acordo com a reivindicação 6, caracterizado pelo fato de que o Servidor de Aplicação envia a requisição de Protocolo de Iniciação de Sessão a uma CSCF de Serviço, e, em resposta, aquela CSCF de Serviço obtém capacidades de Função de Controle de Estado/Chamada de Serviço de um Servidor de Assinante Doméstico e aloca uma Função de Controle de Estado/Chamada de Serviço com base nestas capacidades, a CSCF de Serviço enviando então a requisição de Protocolo de Iniciação de Sessão à CSCF de Serviço alocada se a CSCF de Serviço alocada for outra que não ela própria.
8. Método de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato de compreender enviar, do Servidor de Assinante Doméstico para o Servidor de Aplicação, uma ficha de segurança, e enviar esta ficha de segurança do Servidor de Aplicação, juntamente com a dita requisição de Protocolo de Iniciação de Sessão, como um meio para validar a requisição.
9. Método de acordo com a reivindicação 8, caracterizado pelo fato de compreender, ao receber a dita requisição na Função de Controle de Estado/Chamada de Serviço alocada, redirecionar a dita ficha de segurança ao Servidor de Assinante Doméstico, o Servidor de Assinante Doméstico validando a ficha em benefício da Função de Controle de Estado/Chamada de Serviço.
10. Método de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato de compreender transferir um perfil de serviço para o usuário do Servidor de Assinante Doméstico para a Função de Controle de Estado/Chamada de Serviço, este perfil de serviço incluindo informação de perfil para requisições não

Petição 870180045299, de 28/05/2018, pág. 22/24

3/3 registradas de origem.

Petição 870180045299, de 28/05/2018, pág. 23/24

1/5