PT1917817E

PT1917817E - Processo e instalação para estabelecer uma sessão de comunicação multimédia

Info

Publication number: PT1917817E
Application number: PT57987745T
Authority: PT
Inventors: Mattias Lidstroem; Per Synnergren; Tony Larsson; Mona Matti; Niklas Bjoerk
Original assignee: Ericsson Telefon Ab L M
Priority date: 2005-08-22
Filing date: 2005-11-01
Publication date: 2013-08-26
Also published as: JP5113916B2; ES2414874T3; EP1917817B1; MX2008001911A; WO2007024169A1; CA2616417C; EP1917817A4; JP4685938B2; JP2009505609A; US20090168696A1; PL1917817T3; CA2616417A1; CN101248685A; DK1917817T3; JP2011130458A; CN101248685B; US7907541B2; EP1917817A1

Description

ΡΕ1917817 1

DESCRIÇÃO "PROCESSO E INSTALAÇÃO PARA ESTABELECER UMA SESSÃO DE COMUNICAÇÃO MULTIMEDIA"

Campo técnico A presente invenção refere-se genericamente a um processo e instalação para estabelecer uma sessão de comunicação multimédia que envolve um terminal móvel.

Antecedentes da invenção e técnica anterior

Com o surgimento da telefonia móvel 3G, foram desenvolvidas novas tecnologias de comunicação baseadas em pacotes para suportar a comunicação multimédia. Por exemplo, as tecnologias GPRS (General Packet Radio Service - Serviço geral de radiocomunicações por pacotes) e WCDMA (Wideband Code Division Multiple Access - acesso múltiplo por divisão de código em banda larga) suportam serviços de telefonia multimédia sem fios que envolvem a comunicação de comutação por pacotes de dados que representam imagens, textos, documentos, animações, ficheiros de áudio, ficheiros de video, etc., adicionalmente às chamadas de voz tradicionais por comutação de circuitos.

Os serviços multimédia normalmente implicam a 2 ΡΕ1917817 transmissão de dados codificados que representam textos, documentos, imagens, ficheiros de áudio e ficheiros de vídeo em diferentes formatos e combinações. 0 termo "multimédia" será utilizado na presente descrição como geralmente referindo-se a qualquer escolha de meios transmitidos utilizando a tecnologia de transporte IP (Internet Protocol) baseada em pacotes.

Uma arquitectura de rede denominada "IP Multimedia Subsystem" (IMS - Subsistema multimédia IP) foi desenvolvida pelo 3rd Generation Partnership Project (3GPP) como um padrão aberto para lidar com serviços de multimédia e sessões no domínio dos pacotes. IMS é uma plataforma para permitir serviços baseados no transporte IP, mais ou menos independente da tecnologia de acesso utilizada, não sendo restrita a quaisquer serviços específicos. Assim, uma rede IMS controla sessões multimédia mas não é usada para a transferência real de dados de carga útil que é encaminhada através de redes de acesso e quaisquer redes de transporte intermédios. 0 documento "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications Systems (UMTS); General Packet Radio Service (GPRS); Service Description; Stage 2 (3GPP TS 23.060 version 5.9.0 Release 5); ETSI TS 123 060, 96.MPEG Meeting; 21.03.2011 -25.03.2011; Genebra; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/EG11) , LIS, Sophia Antipolis Cedex, França, vol. 3-SA2, no. V5.0.0, 1 Setembro 2004 (2004-09- 3 ΡΕ1917817 01) descreve um processo para determinar se é necessário um segundo contexto de protocolo de dados por pacotes, PDP, o que sugere um procedimento de activação de contexto PDP pedido de rede. 0 documento Dl descreve como uma decisão deverá ser tomada na rede em vez de pelo UE. O documento "Network Initiated Secondary PDP Context activation procedure", projecto 3GPP; S2-99D27, 3RD Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route des Lucioles; F-06921 Sophia-Antipolis Cedex; França, vol. SA WG2, no. Abiko; 19991208, 8 Dezembro 1999 (1999-12-08) descreve um procedimento de activação de contexto PDP secundário iniciado por rede que permite que o GGSN inicie a activação de um contexto PDP secundário. 0 procedimento de activação de contexto PDP secundário só pode ser iniciado quando já está estabelecido um contexto PDP para o mesmo endereço PDP. Uma decisão de activação de um contexto PDP secundário com base nos pedidos de QdS não está totalmente sob o controlo da rede, mas pode ser tomada em colaboração com o UE. O documento WO 03/058866 A2 descreve um processo para activar um contexto PDP numa rede celular o que pode incluir a activação do contexto PDP com base na determinação de que pode ser baseada num disparo que ocorre quando é enviada uma notificação para o nó de suporte de GPRS, SGSN. A figura 1 é uma ilustração esquemática 4 ΡΕ1917817 simplificada de uma estrutura de rede básica para proporcionar serviços multimédia por meio de uma rede de serviço IMS. Um primeiro terminal móvel A encontra-se ligado a uma primeira rede de acesso por rádio 100 e comunica com um segundo terminal móvel B ligado a uma segunda rede de acesso por rádio 102, numa sessão de comunicação S que envolve um ou mais serviços multimédia. Também pode haver uma rede de base intermédia, não representada, bem como ligando as redes de acesso 100 e 102.

Uma rede IMS 104 encontra-se ligada à primeira rede de acesso por rádio 100 e manipula a sessão em relação ao terminal A. Nesta figura, uma rede IMS correspondente 106 manipula a sessão em nome do terminal B, sendo que as duas redes IMS 104 e 106 pode ser controladas por diferentes operadores. Alternativamente, os terminais A e B podem, evidentemente, ser ligados à mesma rede de acesso e/ou podem pertencer à mesma rede IMS. 0 terminal A pode também comunicar com um terminal fixo ou computador ou servidor em vez disso, por exemplo, para descarregar alguns meios através da Internet, desde que a outra parte seja passível de comunicação SIP. Além disso, se um terminal estiver em roaming numa rede de acesso visitada, os serviços multimédia são tratados pela rede "doméstica" IMS do terminal. A sessão S apresentada na figura 1 é gerida por nós específicos em cada rede IMS, aqui geralmente 5 ΡΕ1917817 designados como "nós gestores de sessão" 108. Esses nós incluem tipicamente S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) e P-CSCF (Proxy Call Session Control Function). Cada rede IMS 104, 106 inclui também um ou mais servidores de aplicação 110 para permitir vários serviços multimédia. Além disso, um elemento de base de dados principal HSS (Home Subscriber Server) 112 armazena dados de assinantes e autenticação bem como informações de serviço, entre outras coisas. A rede IMS 106 é basicamente semelhante à rede 104. As várias funções especificas dos elementos de rede apresentados 108-112 são geralmente conhecidas na técnica, mas não são necessárias para descrever aqui adicionalmente para compreender o âmbito da presente invenção. Claro que as redes IMS 104, 106 contêm vários outros nós e funções não mostrados aqui por razões de simplicidade.

Uma especificação para o manuseio de sessões em redes IMS foi definida com a denominação "SIP" (Session Initiation Protocol, de acordo com o padrão IETF RFC 3261) . SIP é um protocolo de controlo de camada de aplicação para sinalização, para criar e geralmente manusear sessões através de uma lógica de comutação por pacotes. O padrão SIP é deste modo utilizado por sistemas IMS e terminais activados para SIP para estabelecer e controlar as comunicações multimédia IP. O SIP em si não proporciona serviços de multimédia, mas disponibiliza um conjunto de primitivas que outros protocolos ou aplicações podem usar para realmente implementar tais serviços. 6 ΡΕ1917817

Por exemplo, encontra-se definida em SIP uma mensagem denominada "INVITE" para iniciar uma sessão de multimédia durante o estabelecimento da sessão, quando uma determinada aplicação tiver sido invocada. A mensagem SIP INVITE inclui normalmente, entre outras coisas, uma descrição da sessão, ou seja, informações sobre o(s) codec(s) necessário(s) e outros parâmetros de comunicação necessários para a próxima sessão. 0 SIP utiliza um protocolo adicional denominado de Protocolo de Descrição de Sessão (Session Description Protocol), SDP, para descrever sessões multimédia, que podem ser incorporadas como um corpo auto-contido dentro de mensagens SIP. 0 SDP pode ser utilizado por terminais para trocar informações sobre as suas capacidades e preferências especificas, a fim de negociar e chegar a acordo sobre os parâmetros de sessão, codec's em particular, para utilizar durante uma próxima sessão multimédia, tal como é bem conhecido na técnica. Os parâmetros de sessão preferidos ou necessários podem ser indicados como atributos designados como "pré-condições" na informação do SDP.

Muitas aplicações móveis exigem uma certa qualidade de serviço QdS a fim de proporcionar um resultado satisfatório para os utilizadores finais. Para redes UMTS, foram definidas quatro classes principais de trânsito: "classe de conversação", "classe de fluxo", "classe interactiva" e "classe de segundo plano", a fim de classificar as diferentes necessidades no que se refere às 7 ΡΕ1917817 taxas de bits e atrasos. Estas classes de tráfego são principalmente distinguidas pelos seus requisitos relativos a atrasos de transferência, de tal forma que as aplicações da classe de conversação toleram apenas pequenos atrasos, por vezes também designados como "em tempo real", enquanto que a classe de segundo plano é aplicada às aplicações menos sensíveis ao atraso, às vezes também designadas como "melhor esforço". A selecção de uma classe de tráfego UMTS para uma aplicação é utilizada para atribuir um canal físico adequado na rede de acesso, geralmente designado como um RAB (Radio Access Bearer), a fim de optimizar os escassos recursos de rádio na rede de acesso, enquanto se mantém qualidade aceitável para o utilizador final.

Os terminais móveis passíveis de multimédia são tipicamente configurados para identificar para cada aplicação inerente, uma classe de tráfego UMTS, tal como ilustrado esquematicamente na figura 2. Assim, um terminal móvel pode reter uma série de aplicações 200, designadas como Al, A2, A3, A4, A5.... Uma função de mapeamento 202 no terminal traduz cada aplicação para uma determinada classe de tráfego UMTS 204, das quais apenas duas são mostradas aqui. Neste caso, as aplicações Al, A2 e A4 são mapeadas para a mesma classe 2 de tráfego UMTS, uma vez que elas têm necessidades semelhantes em relação à taxa de bits e atraso, enquanto que as aplicações A3 e A5 são mapeadas para uma classe 1 de tráfego UMTS. Deste modo, várias ΡΕ1917817 aplicações com características semelhantes podem ser mapeadas para o mesmo RAB, cumprindo as suas exigências.

No entanto, antes que um terminal móvel possa trocar quaisquer mensagens SIP com a rede IMS, deve ser estabelecido um "contexto PDP (Packet Data Protocol) " para o terminal. Basicamente, um contexto PDP pode ser activado uma vez que o terminal tiver sido ligado. A activação de um contexto PDP para um terminal móvel inclui a alocação de um endereço de IP temporário para o terminal, para ser passível de comunicar pacotes de dados com o terminal. Um contexto PDP também significa que um canal físico se encontra alocado na rede de acesso, geralmente designado como um .RAB (Radio Bearer Access) , para comunicação IP Deste modo, as mensagens SIP só podem ser enviadas através de um contexto PDP. A figura 3 ilustra a activação gradual de um terminal móvel A prestes a comunicar multimédia com outra parte B, que envolve basicamente cinco fases 3:1 - 3:5 tal como ilustrado, cada um compreendendo várias mensagens de ida e volta. Estas mensagens são bem conhecidas na técnica e não serão descritas em qualquer pormenor. 0 terminal A está localizado sob a cobertura de rádio de uma rede de acesso móvel 300, que se encontra dividida numa parte da rede por rádio 300a e uma parte da rede de base 300b. A rede de base 300b apresentada na figura 3 inclui um GGSN (Gateway GPRS Switching Node) 304 e uma 9 ΡΕ1917817 "unidade política" 306, muitas vezes designada como PDF (Policy Decision Function) ou PCRF (Policy and Charging Rule Function). A unidade política é basicamente responsável por autorizar as sessões de comunicação. Claro que a rede 300 contém numerosos outros nós e elementos que não é necessário descrever para compreender o contexto da presente invenção. Para simplificar, a rede IMS de terminal A está aqui apenas representada como um "núcleo IMS" 308, que contém vários nós, não mostrados, envolvidos nos procedimentos que serão descritos a seguir.

Numa primeira fase 3:1 é activado um contexto PDP de base, designado como "primário", para obter uma ligação IP. Activar o contexto PDP primário inclui obter um RAB, para mensagens de sinalização SIP sobre IP comutadas por pacotes. O contexto PDP é criado pela GGSN 304. Este .RAB é tipicamente baseado na denominada comunicação de "melhor esforço" sem requisitos específicos quanto à taxa de bits e atraso, uma vez que se destina apenas a ocasionalmente transportar mensagens SIP limitadas.

Numa fase seguinte 3:2, o terminal A regista-se no núcleo IMS 308, como basicamente tratado por um nó S-CSCF e HSS no mesmo, não apresentado. 0 registo IMS envolve uma certa quantidade de sinalização baseada em SIP sobre o contexto PDP primário.

De seguida, deverá ser estabelecida uma sessão multimédia com a parte B numa fase seguinte 3:3. Nesta fase 10 ΡΕ1917817 é usado o protocolo SDP acima mencionado dentro das mensagens SIP, tal como INVITE, para comunicar parâmetros específicos de sessões incluindo codec's, em que alguns parâmetros podem ser indicados como condições prévias.

Tipicamente, um terminal chamador propõe um ou mais codec'sr juntamente com outros parâmetros, para utilizar durante a sessão tal como especificado numa mensagem INVITE, sendo que o terminal chamado responde confirmando um codec proposto adequado, e quaisquer outros parâmetros propostos, numa mensagem "OK {INVITE)". A fase 3:3 inclui adicionalmente autorizar a sessão na unidade política 306, com base nos dados da sessão e dados de assinantes armazenados. A fase 3:3 também inclui um procedimento de reserva de recursos de comunicação na rede móvel 300 que se encontram adaptados para a próxima sessão com a parte B e de acordo com os parâmetros confirmados por ambas as partes no seu diálogo SIP. O estabelecimento da sessão e reserva de recursos implica que um contexto PDP secundário seja activado para o terminal A, aqui indicado como uma fase separada 3:4, que deve ser adaptada para o(s) tipo(s) de média envolvidos na próxima sessão. Os seguintes parâmetros de QdS podem ser indicados no contexto PDP secundário: Classe de tráfego, taxa de bits máxima (ligação ascendente/ligação descendente), taxa de bits garantida (ligação ascendente/ligação descendente), atraso na transferência (ligação ascendente/ligação descendente), ordem de entrega, 11 ΡΕ1917817 tamanho máximo de SDU (Service Data Unit - Unidade de Dados de Serviço) e um Source Statistic Descriptor (descritor de estatística de fonte). 0 contexto PDP secundário é tratado pelo GGSN da mesma maneira que para o contexto PDP primário na fase 3:1. Deste modo, o contexto PDP secundário deve ser definido de modo a cumprir os requisitos da sessão com respeito à informação de parâmetros de QdS bem como outros factores, a fim de obter um RAB adequado para meios a serem comunicados. 0 novo RAB é assim mais estável e fiável em comparação com o primeiro um associado com o contexto PDP primário, e deve proporcionar uma QdS "garantida".

Quando o contexto PDP secundário tiver sido finalmente estabelecido, a sessão deve ser reconhecida e os recursos reservados activados, tal como ilustrado numa fase 3:5, antes do início da sessão real numa fase ilustrada final 3:6, sobre o contexto PDP secundário. A activação dos recursos de rede é por vezes designada como "abertura de portas". 0 processo de estabelecer uma sessão, reservar recursos de rede, activar o contexto PDP secundário e activar os recursos reservados, tal como ilustrado nas fases 3:3-3:5, exige uma quantidade significativa de sinalização sequencial, conforme ditado por protocolos normalizados. Além disso deve ter lugar um procedimento semelhante para a outra parte, pelo menos se a outra parte 12 ΡΕ1917817 for também um terminal móvel. Em particular, a fase 3:3 não pode ser executada simultaneamente em ambos os lados, uma vez que o lado-B neste caso irá reservar recursos de rede antes de confirmar os parâmetros de sessão para o lado-B, de acordo com as normas em vigor. Assim, os recursos de rede de reserva no lado A têm que esperar até que os parâmetros da sessão confirmados tenham sido recebidos do lado B. A comunicação dos meios é deste modo adiada pela ampla sinalização sequencial necessária de acordo com os procedimentos convencionais de estabelecimento para sessões multimédia. No campo da comunicação móvel, é geralmente desejável minimizar esses atrasos para tornar os serviços multimédia mais atraentes para os utilizadores finais. Por exemplo, ao usar o serviço denominado "Push-to-talk over Cellular (PoC)", que emula um serviço de walkie-talkie, os utilizadores desejam falar imediatamente depois de pressionar um botão de pressionar para falar ou semelhante, embora isto basicamente desencadeie todo o processo das fases 3:3-3:5 acima descritas.

Além disso, a reserva de recursos de rede é iniciada pelo terminal móvel e encontra-se por isso parcialmente fora de controlo por um operador de rede. É deste modo geralmente desejável para os operadores de rede obter o controlo total da alocação de recursos de rede para diferentes utilizadores. 13 ΡΕ1917817

Sumário da invenção É um objecto da presente invenção tornar possível evitar no geral ou pelo menos reduzir os problemas descritos acima. Mais especificamente, é um objecto da presente invenção tornar possível reduzir o atraso antes que um terminal móvel possa iniciar meios de comunicar, e para permitir que um operador de rede obtenha controlo sobre os recursos de rede.

Estes objectos e outros são obtidos ao proporcionar um processo e instalação de acordo com as reivindicações independentes anexadas a seguir.

De acordo com um aspecto da invenção, é proporcionado um processo de estabelecimento de uma sessão multimédia comutada por pacotes para um terminal móvel em comunicação com outra parte, em que foi activado um contexto primário PDP (Packet Data Protocol - protocolo de dados por pacotes) numa rede móvel para o terminal móvel. 0 processo de acordo com a invenção pode ser executado na rede móvel. É recebida informação sobre a próxima sessão, a qual foi negociada e acordada entre as partes que se comunicam. Em seguida é determinado se quaisquer recursos de rede que proporcionam um QdS desejado são necessários para a sessão na rede móvel. Também é determinado se um contexto PDP secundário deverá ser activado para o terminal móvel e a próxima sessão. Se forem necessários recursos de rede e um contexto PDP secundário tiver que ser activado, a 14 ΡΕ1917817 activação do referido contexto PDP secundário é accionado, sendo que os referidos passos de determinação e passo de accionamento são executados por uma unidade política basicamente responsável por autorizar as sessões de comunicação na rede móvel. A informação de sessão pode ser incluída numa resposta de uma parte chamada para um convite de sessão de uma parte chamadora, confirmando efectivamente a referida resposta os parâmetros de sessão propostos no convite de sessão. A informação de sessão pode ser derivada de um SDP (Session Description Protocol - Protocolo de descrição de sessão) dado na referida resposta. A presença de uma referência de meio no SDP recebido e descrição da sessão no próprio SDP, podem ser usadas para determinar se são necessários para a sessão quaisquer recursos de rede que proporcionam uma QdS exigida, de modo que uma indicação "activo" no SDP implica que foram reservados recursos de rede, não sendo por isso necessários, enquanto que a referida referência do meio que indica "inactivo" no SDP implica que os recursos de rede não foram reservados, sendo por isso necessários. As pré-condições dadas como atributos no SDP podem também ser usadas para determinar se são necessários quaisquer recursos de rede que proporcionam uma QdS requerida, de modo que são necessários recursos de rede quando as pré-condições dadas não se encontram actualmente presentes, e vice-versa. 15 ΡΕ1917817

Os dados de inscrição e autenticação para o referido terminal móvel e seu utilizador, e também o tipo de aplicação ou serviço que foi invocado para a próxima sessão, podem ser usados para determinar se um contexto PDP secundário deve ser activado para a próxima sessão. A unidade política pode ser uma PDF (Policy Decision Function) ou uma PCRF (Policy and Charging Rule Function). A activação do contexto PDP secundário pode ser desencadeada enviando um pedido para o terminal para activar um contexto PDP secundário, para uma GGSN na rede móvel. 0 pedido de activação de um contexto PDP secundário pode ser incluído numa mensagem existente modificada "Credit Control Request CCR", que pode ser enviada para a GGSN através de um protocolo Gx baseado em DIAMETER. Em resposta a receber o referido pedido para activar um contexto PDP secundário, a GGSN pode instalar regras para a próxima sessão e pode enviar um pedido para o terminal móvel para iniciar um contexto PDP secundário.

De acordo com um outro aspecto da invenção, é proporcionado uma instalação numa rede móvel para estabelecer uma sessão multimédia comutada por pacotes para um terminal móvel em comunicação com outra parte, em que foi activado um contexto primário PDP (Packet Data Protocol - protocolo de dados por pacotes) na rede móvel para o terminal móvel. A instalação compreende meios para receber 16 ΡΕ1917817 informações sobre a próxima sessão que foi negociada e acordada entre as partes que se comunicam, meios para determinar se são necessários quaisquer recursos de rede que proporcionam uma QdS garantida para a sessão, meios para determinar se um contexto PDP secundário será activado para o terminal móvel e a próxima sessão, e meios para desencadear a activação do referido contexto PDP secundário se os recursos de rede que proporcionam uma QdS exigida são necessários, sendo que será activado um contexto PDP secundário, onde o referido meio determinante e meio de desencadeamento estão incluídos numa política basicamente responsável por autorizar as sessões de comunicação na rede móvel. A instalação pode adicionalmente compreender meios para extrair a referida informação de sessão de uma resposta de uma parte chamada para um convite de sessão de uma parte chamadora, confirmando efectivamente a referida resposta os parâmetros de sessão propostos no convite de sessão. A instalação pode adicionalmente compreender meios para derivar a informação de sessão de um SDP (Session Description Protocol - Protocolo de descrição de sessão) dado na referida resposta. A instalação pode adicionalmente compreender meios para usar a presença de uma referência de meio no SDP recebido e descrição da sessão no próprio SDP, para determinar se são necessários para a sessão quaisquer recursos de rede que proporcionam uma QdS exigida, de modo 17 ΡΕ1917817 que uma indicação "activo" no SDP implica que foram reservados recursos de rede, não sendo por isso necessários, enquanto que a referida referência do meio que indica "inactivo" no SDP implica que os recursos de rede não foram reservados, sendo por isso necessários. A instalação pode adicionalmente compreender meios para utilizar pré-condições dadas como atributos no SDP para determinar se quaisquer recursos de rede que proporcionam uma QdS requerida são necessários, de modo que são necessários recursos de rede quando as pré-condições dadas não se encontram actualmente presentes, e vice-versa. A instalação pode adicionalmente compreender meios para utilizar dados de inscrição e autenticação para o referido terminal móvel e seu utilizador, e também o tipo de aplicação ou serviço que foi invocado para a próxima sessão, para determinar se um contexto PDP secundário deve ser activado para a próxima sessão. A unidade política pode ser uma PDF (Policy Decision Function) ou uma PCRF (Policy and Charging Rule Function). A instalação pode adicionalmente compreender meios para desencadear a activação do contexto PDP secundário enviando um pedido para o terminal para activar um contexto PDP secundário, para uma GGSN na rede móvel. A instalação pode adicionalmente compreender meios para incluir o referido pedido para activar um contexto PDP secundário numa mensagem existente modificada "Credit 18 ΡΕ1917817

Control Request CCR" que é enviada para a GGSN através de um protocolo Gx baseado em DIAMETER. A instalação pode adicionalmente compreender meios numa GGSN pode instalar regras para a próxima sessão e para enviar um pedido para o terminal móvel para iniciar um contexto PDP secundário em resposta à recepção do referido pedido para activar um contexto PDP secundário.

Outras caracteristicas da presente invenção e os seus benefícios serão explicadas na descrição pormenorizada a seguir.

Breve descrição dos desenhos A presente invenção será agora pormenorizadamente descrita por meio de formas de realização preferidas e tomando como referência os desenhos anexos. As figuras representam:

Figura 1 vista esquemática de uma estrutura de rede convencional para a comunicação multimédia entre dois terminais móveis.

Figura 2 diagrama esquemático que ilustra o mapeamento de aplicações em classes de tráfego UMTS num terminal móvel.

Figura 3 diagrama de sinalização que ilustra diferentes fases no processo de estabelecimento de uma sessão multimédia de acordo com a técnica 19 ΡΕ1917817 anterior .

Figura 4 fluxograma que ilustra um processo para o estabelecimento de uma sessão multimédia, de acordo com um aspecto da presente invenção.

Figura 5 diagrama de sinalização que ilustra diferentes fases de mensagens para estabelecer uma sessão multimédia, de acordo com uma forma de realização preferida.

Descrição das formas de realização preferidas

Na presente invenção, a tarefa de desencadear a activação de um contexto PDP secundário para um terminal móvel é deslocado do terminal para a sua rede de base, ou antes rede de base móvel "doméstica" se o terminal estiver em roaming em outro lugar. Deste modo, o operador de rede pode obter o controlo total sobre os seus recursos de rede, pode ser reduzido o atraso antes do começo da sessão, e podem ser evitados os conflitos de sinalização.

Será agora descrito um processo esquemático para estabelecer uma sessão multimédia para duas partes comunicantes, incluindo um terminal móvel, de acordo com um aspecto da presente invenção tomando como referência um fluxograma apresentado na figura 4. Supõe-se que foi pedida uma sessão de comunicação que envolve o terminal móvel, tanto pelo referido terminal móvel como por uma parte oposta. Num primeiro passo 400, é recebida informação sobre a próxima sessão a qual foi negociada e acordada entre as 20 ΡΕ1917817 partes que se comunicam. A informação de sessão pode ser derivada do SDP dado como resposta de uma parte chamadora a um convite para uma sessão, confirmando a resposta efectivamente os parâmetros de sessão propostos, tais como a mensagem de resposta denominada OK (INVITE) mencionada acima.

Num próximo passo 402 é determinado se são necessários quaisquer recursos de rede que proporcionam um QdS necessário para a sessão na rede móvel. De acordo com diferentes formas de realização, isto pode ser determinado pela verificação da presença de uma "referência de meio" denominada "inactiva", que é um atributo actualmente existente no SDP utilizado para indicar se os recursos multimédia estão inactivos. Por outro lado, se a referência "inactiva" do meio não estiver presente, os recursos do meio estão activos. Numa forma de realização da presente invenção, propõe-se a utilização da referência do meio de modo que se a referência do meio não estiver presente (activo), isso implica que os recursos da rede foram reservados, e portanto não é necessária nenhuma reserva de recursos, por meio da activação de um contexto PDP secundário. No entanto, quando a referência do meio se encontra presente (inactivo), nenhuns recursos de rede foram reservados, o que é, portanto, necessário.

Alternativamente os atributos marcados como pré-condições no SDP podem ser usados para determinar se os recursos de rede que proporcionam uma QdS requerida são 21 ΡΕ1917817 necessários ou não, de modo que são necessários recursos de rede quando as pré-condições dadas não se encontram actualmente presentes, e vice-versa.

Deve notar-se que pode ser usado qualquer mecanismo para indicar a necessidade de reserva de recursos, e que a presente invenção não se encontra limitada aos exemplos descritos acima.

Se for determinado no passo 402 que não são realmente necessários recursos de rede que fornecem uma QdS desejada, não é necessário activar um contexto PDP secundário, de modo correspondente, sendo que pode ser utilizado um procedimento normal para completar 0 estabelecimento de sessão, tal como indicado por um passo 404 .

Contudo, se foi determinado no passo 402 que são necessários os recursos de rede que fornecem uma QdS desejada, é adicionalmente determinado, num passo seguinte 406, se deverá ser activado ou não um contexto PDP secundário para a sessão seguinte. A decisão para activar um contexto PDP secundário é adicionalmente baseada em vários dados de inscrição e autenticação, e também o tipo de aplicação ou serviço que foi invocado para a próxima sessão. Por exemplo, determinadas aplicações podem necessitar de uma QdS exigindo um contexto PDP secundário, ao passo que outras não. Uma assinatura de utilizador móvel pode permitir uma certa QdS e/ou determinadas preferências 22 ΡΕ1917817 para determinados serviços, ou pode negar o acesso a outros serviços, etc..

Se foi determinado no passo 406 que não é necessário activar um contexto PDP secundário, pode ser utilizado o procedimento normal para completar o estabelecimento de sessão, tal como indicado pelo passo 404. Se é para ser activado um contexto PDP secundário, ou seja, se a sessão puder ser autorizada, o processo passa para um passo final ilustrado 408, para desencadear a activação de contexto PDP secundário para o terminal móvel e a próxima sessão. Quando o procedimento de acordo com a presente invenção é executado de acordo com os passos 400, 402, 406 e 408 acima, o operador de rede irá ganhar controlo total sobre a alocação de recursos geralmente associados à activação de contexto PDP secundário. O atraso de estabelecimento pode também ser reduzido, uma vez que o processo requer geralmente menos sinalização e pode ter lugar em simultâneo e de forma independente para o terminal oposto, o que se tornará visível da descrição da figura 5 a seguir.

Tal como será entendido da forma de realização a ser descrita a seguir, o procedimento para o estabelecimento de uma sessão multimédia de acordo com o fluxograma mostrado na figura 4 pode basicamente ser implementado numa unidade de política ou semelhante pertencente a uma rede de acesso móvel, como por exemplo a unidade 306 mostrada na figura 3. A unidade política pode 23 ΡΕ1917817 ser uma PDF (Policy Decision Function) ou uma (Policy and Charging Rule Function) PCRF, e é basicamente responsável por autorizar as sessões de comunicação. Além disso, GGSN 304 e núcleo do IMS 308 da figura 3 podem exigir algumas adaptações ao novo comportamento da unidade política 306. A figura 5 é um diagrama de sinalização que ilustra os diferentes passos para estabelecer uma sessão multimédia entre um terminal móvel A e outra parte B, de acordo com uma forma de realização preferida. Esta forma de realização demonstra como certas mensagens padrão existentes para o estabelecimento da sessão podem ser utilizadas para transmitir as informações necessárias para a activação de um contexto PDF secundário, se necessário. Semelhante à figura 3, os elementos de rede envolvidas incluem uma GGSN 500 e uma unidade de política 502 que pertence a uma rede móvel doméstica do terminal A, e um núcleo IMS 504 associado à mesma rede móvel. O lado oposto da rede, não mostrado, é basicamente semelhante se a parte B for também um terminal móvel.

Assume-se que um contexto PDP primário foi activado para o terminal A para mensagens de sinalização, tal como descrito para o passo 3:1 passo acima. 0 processo começa por um passo 5:1 quando o terminal A envia uma mensagem INVITE para a parte B, a fim de executar uma sessão multimédia que envolve geralmente a comunicação dos meios de comunicação em uma ou em ambas as direcções. A mensagem INVITE contém um SDP com os parâmetros da sessão - 24 - ΡΕ1917817 propostos, e é transportada através do núcleo do IMS 504 para o lado B, tal como indicado por uma seta a tracejado. Uma vez que nenhum meio está a comunicar nesta altura, presume-se que o terminal A definiu a referência do meio como "inactiva" no SDP da mensagem INVITE.

Depois de ter considerado os parâmetros de sessão propostos indicados na mensagem INVITE recebida, B envia uma mensagem de resposta OK (INVITE) de volta para o terminal A, num próximo passo 5:2. Tal como descrito acima, a parte B inclui um SDP correspondente na mensagem OK (INVITE) que contém os parâmetros de sessão confirmados, que podem ser utilizados na próxima sessão por ambas as partes A, B. Além disso, espera-se que a parte B mantenha a referência do meio como inactivo no SDP nesta mensagem.

Quando o núcleo IMS 504 detecta a mensagem de resposta OK de B no passo 5:2 passo, a informação SDP é traduzida num protocolo Rx baseado em DIAMETER, ao qual especificidades de subscrição de terminal A são adicionadas como base para uma rotina de autorização/ autenticação regular. Toda esta informação é então emitida para a unidade política 502 numa mensagem existente denominada de "pedido de autorização/autenticação AAR" para o terminal A, num próximo passo 5:3. Até ao momento, o processo tem sido executado de acordo com os procedimentos normais para iniciar e autorizar a sessão.

No próximo passo 5:4, a unidade política 506 toma 25 ΡΕ1917817 uma decisão se um contexto PDP secundário deverá ser activado para o terminal A e a próxima sessão. A decisão é tomada basicamente tal como descrito acima para os passos 402 e 406 da figura 4, não sendo por conseguinte necessário repetir aqui em nenhum detalhe. Deve-se notar, porém, que a mensagem AAR existente é utilizada nesta forma de realização para transportar a referência do meio para proporcionar uma base para a decisão, juntamente com uma identidade de aplicação dada no SDP e referida especificidade de subscrição. Alternativamente, podem ser proporcionadas pré-condições no SDP como uma base semelhante para a decisão, tal como descrito acima.

Neste exemplo, supõe-se que a unidade política 502 decide no passo 5:4 activar um contexto PDP secundário, por exemplo, depois de ler uma referência de meio inactiva, ou detectar que as pré-condições não foram atendidas. Num próximo passo 5:5, é por conseguinte enviado da unidade política 502 para a GGSN 500 um pedido para iniciar um contexto PDP secundário para o terminal A. Este pedido pode ser transmitido, por exemplo, por meio de uma mensagem de controlo de crédito padrão. Neste exemplo, uma mensagem "Credit Controle Request CCR" existente é modificada para incluir o referido pedido, e é enviada através de um protocolo Gx baseado em DIAMETER para GGSN 500. Esta mensagem, que em procedimentos normais da técnica anterior é normalmente enviada de outro modo da GGSN para a unidade de política durante a activação do contexto PDP, pode deste modo ser utilizada para transporte do pedido para iniciar 26 ΡΕ1917817 um contexto PDP secundário para o terminal A, incluindo os requisitos QdS entre outras coisas. Esta mensagem efectivamente desencadeia a activação de contexto PDP secundário, conforme executado pelo GGSN 500 que agora pode alocar recursos de rede, incluindo um RAB, ao terminal A. Deste modo, a activação é controlada pela unidade de política, ou seja efectivamente o operador da rede, em vez de pelo terminal.

Em seguida, o nó GGSN inicia o contexto PDP secundário, por exemplo enviando um pedido para o terminal para invocar o procedimento normal para a activação de um contexto PDP secundário com os parâmetros definidos no pedido de iniciação. No entanto, a presente invenção não está limitada a este respeito, e qualquer mecanismo pode ser utilizado para activar o contexto PDP secundário, envolvendo ou não o terminal. Neste exemplo, no entanto, a GGSN 50 0 envia uma mensagem de "pedido de contexto PDP" para o terminal A, num passo 5:6. Esta mensagem efectivamente ordena ao terminal A para "iniciar" o contexto PDP secundário de um modo regular. Neste ponto, a GGSN 500 instala também "regras", tal como indicado por um passo 5:7, que será utilizado durante a sessão para controlar a transferência de meios. A instalação de regras inclui armazenar parâmetros de QdS específicos de sessão e carregar parâmetros, bem como o endereço de IP e um número da porta do terminal A a ser utilizado, etc. Em resposta à mensagem recebida no passo 5:6, o terminal A envia consequentemente uma mensagem "iniciar contexto PDP" para 27 ΡΕ1917817 GGSN 500, num passo 5:8, que é confirmada por meio de uma mensagem "aceita contexto PDP" enviada de volta da GGSN num passo 5:9.

Deve notar-se que o passo 5:7 pode ser executado em qualquer altura após o passo 5:5, mas antes do próximo passo 5:10 no qual GGSN 500 envia uma mensagem padrão modificada Gx CCA, "resposta de controlo de crédito", para a unidade política 502, como uma resposta à mensagem Gx CCR do passo 5:5. A mensagem Gx CCA, normalmente enviada de outro modo da unidade política para GGSN de acordo com a técnica anterior, já foi modificada para conter informação sobre o contexto PDP secundário activado. Desse modo, a mensagem Gx CCA existente é utilizada para transmitir esta informação para a unidade política no passo 5:10, mas ainda pode ser utilizada também para controlo de crédito normal, juntamente com a mensagem Gx CCR do passo 5:5, tal como originalmente pretendido.

Em seguida, a unidade política 502 pode prosseguir com o envio de uma resposta padrão para a mensagem Rx AAR, recebida no passo 5:3, denominada Rx AAA "Authorisation/Authentication Answer - resposta de autorização/autenticação", num passo 5:11. Esta mensagem indica que a sessão de hoje foi autorizada e que foram reservados recursos de rede, permitindo assim que a sessão comece. Após receber a mensagem "Aceitar contexto PDP" no passo 5:9, o terminal A envia agora uma nova mensagem INVITE para a parte B, num passo 5:12, desta vez sem a 28 ΡΕ1917817 referência do meio "inactivo" no SDP indicando assim "activo", sendo que a parte contrária responde consequentemente com uma mensagem de OK (INVITE) com um SDP indicando "activo", num passo seguinte 5:13. Os dois últimos passos confirmam a sessão como activa, sendo que a comunicação dos meios pode ocorrer num passo final 5:14.

Com a implementação da presente invenção, por exemplo, de acordo com as formas de realização descritas acima, o operador de rede terá total controle sobre os seus recursos de rede ao estabelecer uma sessão de multimédia para um terminal móvel, uma vez que o operador, em vez do terminal, pode decidir quando accionar um contexto secundário PDP. 0 atraso antes do inicio da sessão pode também ser reduzido.

Os procedimentos actuais de acordo com o estado da técnica podem ainda resultar em conflitos de sinalização, designados como "condição de corrida", ao definir a referência do meio no SDP para inactivo, já que um utilizador que responde (por exemplo, utilizador B) define o SDP para activo (ou seja, com falta de referência de meio "inactiva") ao aceitar a descrição da sessão. 0 utilizador que responde pode enviar quase simultaneamente a mensagem de aceitaçao de sessão (SIP OK INVITE) e a mensagem de reserva de recursos. Isto permitirá que o utilizador que responde inicie um contexto PDP secundário antes que os recursos sejam reservados na unidade da política na rede móvel, tendo por resultado uma falha no 29 ΡΕ1917817 estabelecimento de PDP, a menos que o sinal de reserva de recursos desencadeado pela resposta aceite pela sessão tenha alcançado primeiro a unidade da política, dai a condição de competição. Utilizar a presente invenção irá evitar um tal conflito.

Embora a invenção tenha sido descrita tomando como referência formas de realização especificas, a descrição em geral só serve para ilustrar o conceito da invenção e não deve ser considerada como sendo uma limitação do escopo da invenção. Por exemplo, o conceito de protocolo de sinalização SIP e IMS tem sido utilizado em toda a parte ao descrever as formas de realização acima, embora basicamente possam ser utilizados quaisquer outros padrões e redes de serviço para permitir a comunicação multimédia. A presente invenção é definida pelas reivindicações anexas.

Lisboa, 7 de Agosto de 2013

Claims

ΡΕ1917817 1 REIVINDICAÇÕES 1. Processo para estabelecer uma sessão multimédia comutada por pacotes para um terminal móvel em comunicação com outra parte, em que foi activado um contexto primário de protocolo de dados por pacotes, PDP, na rede móvel para o terminal móvel, o processo compreendendo os seguintes passos, tal como executado na rede móvel: - receber informação sobre a próxima sessão, a qual foi negociada e acordada entre as partes que se comunicam, determinar se quaisquer recursos de rede que proporcionam um QdS desejado são necessários para a sessão na rede móvel, - determinar se um contexto PDP secundário deverá ser activado para o terminal móvel e a próxima sessão, e se os recursos de rede são necessários e um contexto PDP secundário deverá ser activado, - desencadear a activação do referido contexto PDP secundário, em que os referidos passos de determinação e passo de accionamento são executados por uma unidade política basicamente responsável por autorizar as sessões de comunicação na rede móvel.
2. Processo de acordo com a reivindicação 1, em que a referida informação de sessão está incluída numa 2 ΡΕ1917817 resposta de uma parte chamadora a um convite de sessão de uma parte chamadora, confirmando a referida resposta efectivamente os parâmetros de sessão propostos no convite de sessão.
3. Processo de acordo com a reivindicação 2, em que a informação de sessão é derivada de um SDP (Session Description Protocol - Protocolo de descrição de sessão) dado na referida resposta.
4. Processo de acordo com a reivindicação 3, em que a presença de uma referência de meio no SDP recebido e a descrição da sessão no próprio SDP, são usadas para determinar se são necessários quaisquer recursos de rede para a sessão que proporcionam uma QdS exigida, de modo que uma indicação "activo" no SDP implica que foram reservados recursos de rede, não sendo por isso necessários, enquanto que a referida referência do meio que indica "inactivo" no SDP implica que os recursos de rede não foram reservados, sendo por isso necessários.
5. Processo de acordo com a reivindicação 3, em que as pré-condições dadas como atributos no SDP são usadas para determinar se são necessários quaisquer recursos de rede que proporcionam uma QdS requerida, de modo que são necessários recursos de rede quando as pré-condições dadas não se encontram actualmente presentes, e vice-versa.
6. Processo de acordo com quaisquer das 3 ΡΕ1917817 reivindicações 1 a 5, em que os dados de inscrição e autenticação para o referido terminal móvel e seu utilizador, e também o tipo de aplicação ou serviço que foi invocado para a próxima sessão, são usados para determinar se um contexto PDP secundário deve ser activado para a próxima sessão.
7. Processo de acordo com a reivindicação 1, em que a unidade política é uma função de decisão política, PDF, ou uma função de reqra de política e carregamento, PCRF.
8. Processo de acordo com a reivindicação 7, em que a activação do contexto PDP secundário é desencadeada enviando um pedido para o terminal para activar um contexto PDP secundário, para uma GGSN na rede móvel.
9. Processo de acordo com a reivindicação 8, em que o referido pedido de activação de um contexto PDP secundário é incluído numa mensagem existente modificada " Credit Control Request CCR" que é enviada para a GGSN através de um protocolo Gx baseado em DIAMETER.
10. Processo de acordo com as reivindicações 8 ou 9, em que, em resposta a receber o referido pedido para activar um contexto PDP secundário, a GGSN instala regras para a próxima sessão e envia um pedido para o terminal móvel para iniciar um contexto PDP secundário. 4 ΡΕ1917817
11. Instalação numa rede móvel para estabelecer uma sessão multimédia comutada por pacotes para um terminal móvel em comunicação com outra parte, em que foi activado um contexto primário de protocolo de dados por pacotes, PDP, na rede móvel para o terminal móvel, compreendendo: meios para receber informação sobre a próxima sessão, a qual foi neqociada e acordada entre as partes que se comunicam, - meios para determinar se quaisquer recursos de rede que proporcionam um QdS qarantido são necessários para a sessão, - meios para determinar se um contexto PDP secundário deverá ser activado para o terminal móvel e a próxima sessão, e meios para desencadear a activação do referido contexto PDP, se são necessários os recursos de rede que proporcionam uma QdS exiqida e um contexto PDP secundário deverá ser activado, em que os referidos meios de determinação e meios de accionamento se encontram incluídos numa unidade politica basicamente responsável por autorizar as sessões de comunicação na rede móvel.
12. Instalação de acordo com a reivindicação 11, compreendendo adicionalmente meios para extrair a referida informação de sessão de uma resposta de uma parte chamada para um convite de sessão de uma parte chamadora, confirmando efectivamente a referida resposta os parâmetros de sessão propostos no convite de sessão. 5 ΡΕ1917817
13. Instalação de acordo com a reivindicação 12, compreendendo adicionalmente meios para derivar a informação de sessão de um SDP (Session Description Protocol - Protocolo de descrição de sessão) dado na referida resposta.
14. Instalação de acordo com a reivindicação 13, compreendendo adicionalmente meios para usar a presença de uma referência de meio no SDP recebido e a descrição da sessão no próprio SDP, para determinar se são necessários para a sessão quaisquer recursos de rede que proporcionam uma QdS exigida, de modo que uma indicação "activo" no SDP implica que foram reservados recursos de rede, não sendo por isso necessários, enquanto que a referida referência do meio que indica "inactivo" no SDP implica que os recursos de rede não foram reservados, sendo por isso necessários.
15. Instalação de acordo com as reivindicações 13 ou 14, compreendendo adicionalmente meios para utilizar pré-condições dadas como atributos no SDP para determinar se são necessários quaisquer recursos de rede que proporcionam uma QdS requerida, de modo que são necessários recursos de rede quando as pré-condições dadas não se encontram actualmente presentes, e vice-versa.
16. Instalação de acordo com quaisquer das reivindicações 11 a 15, compreendendo adicionalmente meios para utilizar dados de inscrição e autenticação para o referido terminal móvel e seu utilizador, e também o tipo 6 ΡΕ1917817 de aplicação ou serviço que foi invocado para a próxima sessão, para determinar se um contexto PDP secundário deve ser activado para a próxima sessão.
17. Instalação de acordo com a reivindicação 11, em que a unidade política é uma função de decisão política, PDF, ou uma função de regra de política e carregamento, PCRF.
18. Instalação de acordo com a reivindicação 17, compreendendo adicionalmente meios para desencadear a activação do contexto PDP secundário enviando um pedido para o terminal para activar um contexto PDP secundário, para uma GGSN na rede móvel.
19. Instalação de acordo com a reivindicação 18, compreendendo adicionalmente meios para incluir o referido pedido para activar um contexto PDP secundário numa mensagem existente modificada "Credit Control Request CCR" que é enviada para a GGSN através de um protocolo Gx baseado em DIAMETER.
20. Instalação de acordo com as reivindicações 18 ou 19, compreendendo adicionalmente meios numa GGSN pode instalar regras para a próxima sessão e para enviar um pedido para o terminal móvel para iniciar um contexto PDP 7 ΡΕ1917817 secundário em resposta à recepção do referido pedido para activar um contexto PDP secundário. Lisboa, 7 de Agosto de 2013