PT2048836E - Autorização dinâmica dos media em rede móvel - Google Patents
Autorização dinâmica dos media em rede móvel Download PDFInfo
- Publication number
- PT2048836E PT2048836E PT08163110T PT08163110T PT2048836E PT 2048836 E PT2048836 E PT 2048836E PT 08163110 T PT08163110 T PT 08163110T PT 08163110 T PT08163110 T PT 08163110T PT 2048836 E PT2048836 E PT 2048836E
- Authority
- PT
- Portugal
- Prior art keywords
- session
- media
- quot
- stream
- traffic class
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/801—Real time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/808—User-type aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
Description
1
DESCRIÇÃO
"AUTORIZAÇÃO DINÂMICA DOS MEDIA EM REDE MÓVEL" HISTORIAL DA INVENÇÃO ÂMBITO TÉCNICO A presente invenção refere-se a redes móveis, incluindo uma qualidade de ponta a ponta da gestão de serviço (QoS) e, mais especificamente, refere-se a uma autorização dinâmica dos media e à gestão de classes QoS de uma sessão (ligação entre utilizadores ou terminais móveis, ou entre um terminal móvel e um servidor), compreendendo uma série de diferentes tipos de correntes de media (media streams) dentro das redes móveis.
ANTECEDENTES
As redes móveis modem, como as redes padronizadas por especificações 3GPP (Projecto de Parceria de 3° Geração), incluindo todos os GSM (Sistema Global para Comunicações Móveis) e terceiras gerações de redes GSM, são uma integração continua das redes celulares digitais e sistemas de comunicação pessoal para providenciar serviços de telecomunicação, incluindo por ex. serviços de rede de dados móveis e serviços de multimédia IP.
Cada sistema 3GPP pode incluir uma rede central e uma infra-estrutura de rede de acesso de rádio, utilizando o Serviço de Rádio de Pacote Geral (GPRS) e Velocidades de Dados Melhoradas para as tecnologias de Evolução Global 2 (EDGE) ou suportando o Acesso de Rádio Terrestre Universal (UTRA) operável tanto na Divisão de Frequência Duplex (FDD) como na Divisão de Tempo Duplex (TDD). A rede central (CN) pode ser logicamente dividida em domínios de comutação de circuitos (CS) e comutação de pacotes (PS) com entidades CN providenciadas para o tráfego de utilizador e sinalização relacionada, e um Subsistema de Multimédia IP (IMS) com entidades de rede central (CN) providenciadas a serviços de multimédia IP. Algumas entidades CN, como o Servidor de Assinantes Residencial (HSS), o Registo de Localização Residencial (HLR), o Centro de Autenticação (AuC), o Registo de Localização de Visitantes (VLR) e o Registo de Identificação de Equipamento (EIR), podem ser comuns aos domínios PS e CS, enquanto outras entidades CN, como um Centro de Comutação Móvel (MSC) e uma Porta MSC, são específicas do domínio CS para lidar com serviços de comutação de circuitos para/de estações móveis, e a Porta GPRS (serviço de rádio de pacote geral), o Nó de Suporte (GGSN) e o GSN Servidor (SGSN) são específicos do domínio PS para lidar com a transmissão de pacotes para/de estações móveis.
Para os serviços de multimédia IP, podem ser providenciadas entidades funcionais IMS, como a Função de Controlo da Sessão de Chamada (CSCF), para lidar com os procedimentos relacionados CSCF, incluindo estabelecer um contexto PDP (Protocolo de Dados de Pacote, por exemplo, IP) para sinalizar o IMS relacionado, para registar e para outros procedimentos para as sessões IMS. CSCF pode agir como Proxy CSCF (P-CSCF) para servir como um primeiro ponto de contacto para um equipamento de utilizador (UE) (isto é, um dispositivo que permita a um utilizador aceder aos 3 serviços da rede, como um terminal móvel) dentro do subsistema de multimédia IP (IMS), como um CSCF Servidor (S-CSCF) para lidar com estados de sessão na rede ou como um CSCF Interrogatório (I-CSCF) para servir de ponto de contacto dentro de uma rede de operadores para todas as ligações IMS destinadas a um assinante desse operador de rede ou um assinante de itinerância numa determinada área de serviço. Ver a Especificação Técnica 3GPP (TS) 23.002, V5.9.0 (Dezembro 2002) "Network Architecture"; 3GPP TS 23.1 01, V4.0.0 (Abril 2002) "General UMTS Architecture"; e 3GPP TS 23.1 10, V4.0.0 (Abril 2001) "UMTS Access Stratum: Services and Functions"; e a Especificação Técnica 3GPP (TS) 23.228, V6.0.1 (Janeiro 2003) "IP Multimedia Subsystem (IMS)". Todas as especificações 3GPP (GSM13G) podem ser encontradas e descarregadas do servidor 3GPP em ftp://ftp. 3gpp.orglspecs. Podem ainda encontrar-se mecanismos para criar, manter e actualizar especificações 3GPP (incluindo diferentes Comunicados de uma determinada especificação 3GPP com uma funcionalidade nova ou modificada) em Especificação Técnica 3GPP (TS) 21.900 V5.0.1 (Setembro 2002) "Technical Specification Group Working Methods."
Foi padronizada uma Função de Decisão de Políticas (PDF) para supervisionar a gestão da qualidade das classes de serviço (QoS) de uma sessão que compreende uma série de correntes de media, tomar decisões de políticas com base na sessão e na informação relacionada com media, incluindo a máxima classe de tráfego autorizada para um determinado fluxo de media entre dois utilizadores (terminais móveis) ou entre um terminal móvel e um servidor, e depois trocar a informação de decisões pelo GGSN através de uma interface Go, como é definido no 3GPP TS 29.207 V.5.2.0 (Dezembro 4 2002) "Policy Control over Go Interface", Comunicado 5; 3GPP TS 23.207 V.5.6.0 (Dezembro 2002) "End-To-End Quality of Service (QoS) Concept and Architecture", Comunicado 5; e 3GPP TS 29.208 V.5.2.0 (Dezembro 2002) "End-To-End Quality of Service (QoS) signaling flows", Comunicado 5. Esta PDF pode ser integrada no P-CSCF, como é definido na Especificação 3GPP, Comunicado 5 (Dezembro 2002) ou, em alternativa, pode ser implementada num elemento da rede à parte que está separado do P-CSCF, conforme definido na Especificação 3GPP, Comunicado 6 (Janeiro 2003).
De um modo geral, quando uma sessão (ligação) é estabelecida entre equipamentos de utilizador (UE) (por ex. terminais móveis) ou entre um terminal móvel e um servidor, e a sessão é modificada (por ex. do áudio bidireccional e video unidireccional para o video unidireccional apenas), a classe de tráfego é mudada pela PDF (de conversacional para corrente). Isto acontece porque a sessão, conforme está estabelecida entre equipamentos de utilizador (UE) (por ex. terminais móveis) ou entre um terminal móvel e um servidor, compreende um fluxo de áudio bidireccional e um fluxo de video unidireccional. 0 fluxo de áudio bidireccional é utilizado para uma conversação em tempo real e, consequentemente, requer uma classe de tráfego em tempo real de pouco atraso, isto é, a classe de tráfego CONVERSACIONAL. 0 fluxo de video unidireccional é utilizado para transferir imagens de video em movimento numa direcção apenas. Um fluxo de video em tempo real unidireccional deste tipo tolera maiores atrasos de transmissão e variações de atraso (também conhecido por instabilidade) porque o emissor não está à espera de receber qualquer resposta. Como resultado, o fluxo unidireccional em tempo 5 real usa normalmente uma classe de tráfego CORRENTE em prática. Se a sessão for modificada, ou seja, se um dos fluxos de áudio bidireccionais e o fluxo de vídeo unidireccional for concluído e removido da sessão, a classe de tráfego para suportar recursos da sessão tem de ser correspondentemente alterada pela PDF. Por exemplo, se o fluxo de áudio bidireccional com a classe de tráfego CONVERSACIONAL for removido da sessão, o fluxo de vídeo unidireccional, com a classe de tráfego CORRENTE como condição por defeito, tem agora a "classe de tráfego superior" da sessão. Consequentemente, a PDF muda (isto é, para baixo) a classe de tráfego do suporte da sessão da classe, de classe de tráfego CONVERSACIONAL para classe de tráfego CORRENTE.
Porém, alguns parâmetros, como o tamanho da memória temporária no terminal receptor, são diferentes nestas classes de tráfego, e a mudança da classe de tráfego com a mudança inerente do atraso de transmissão vai causar capacidades negativas da memória temporária no terminal receptor ou servidor, reduzindo assim a qualidade da ligação captada pelo utilizador final.
Outro problema significativo pode ocorrer quando é adicionada uma corrente unidireccional (por ex. video) a uma sessão existente, que compreende uma corrente bidireccional (por ex. áudio). 0 pedido da classe de tráfego sinalizada da corrente de vídeo unidireccional é normalmente Corrente. A classe de tráfego da sessão bidireccional é Conversacional. Se as correntes de media possuem uma relação temporal (por ex. explicação verbal da corrente de video na corrente de áudio), a diferença das classes de tráfego vai causar uma diferença nos atrasos de 6 transmissão (devido a diferentes comprimentos de memória temporária nos receptores para compensar os diferentes atrasos e a instabilidades do atraso na transmissão), reduzindo assim a qualidade da ligação captada pelo utilizador final.
Correspondentemente, existe a necessidade de soluções que podem ser aplicadas a todos os sistemas, nos quais uma sessão (ligação entre utilizadores ou terminais móveis, ou entre um terminal móvel e um servidor) pode compreender uma série de diferentes tipos de correntes de media e que se referem à autorização dinâmica de media e melhor gestão da qualidade de classes de serviço (QoS) de uma sessão (ligação entre utilizadores ou terminais móveis, ou entre um terminal móvel e um servidor), compreendendo uma série de diferentes tipos de correntes de media dentro de redes móveis, de modo que quando a(s) corrente(s) de media é/são modificada(s) (novas iniciadas e existentes eliminadas) durante a sessão, a classe de tráfego de uma sessão é definida pelo pedido de classe de tráfego superior pelos fluxos de media pertencentes à mesma sessão para eliminar a diferença de atrasos de transmissão de correntes de media pertencentes à mesma sessão e, consequentemente, melhorando a qualidade da ligação captada pelo utilizador final. A invenção é definida nas reivindicações independentes. Certas versões especificas são definidas nas reivindicações dependentes.
Alguns aspectos da invenção podem ser direccionados para soluções para a autorização dinâmica de media e uma melhor gestão da qualidade das classes de serviço (QoS) de uma sessão (ligação entre utilizadores ou terminais móveis, ou entre um terminal móvel e um servidor), compreendendo 7 uma série de diferentes tipos de correntes de media dentro das redes móveis, de modo que quando uma ou mais correntes de media são modificadas (novas iniciadas e existentes eliminadas) durante a sessão, a classe de tráfeqo de uma sessão é definida pelo pedido de classe de tráfego superior pelos fluxos de media pertencentes à mesma sessão para eliminar a diferença dos atrasos de transmissão dos fluxos de media pertencentes à mesma sessão e, consequentemente, melhorando a qualidade da ligação captada pelo utilizador final.
De acordo com um aspecto da presente invenção, é providenciada uma Função de Decisão de Políticas (PDF) numa rede móvel para determinar uma classe máxima de tráfego autorizada para um determinado fluxo de media de uma sessão entre dois terminais móveis, ou entre um terminal móvel e um servidor. Uma PDF destas é configurada para determinar se uma ou mais correntes de media que requerem a classe de tráfego superior dentro de uma série de diferentes tipos de correntes de media, são removidos da sessão quando uma sessão é estabelecida e modificada entre dois terminais móveis ou entre um terminal móvel e um servidor, através de uma ligação de comunicação; e para manter a classe de tráfego utilizada para as restantes correntes de media na sessão, se uma ou mais correntes de media que requerem a classe de tráfego superior forem removidas da sessão.
De acordo com outro aspecto da presente invenção, é configurada uma Função de Decisão de Políticas (PDF) para determinar se uma corrente unidireccional é adicionada à sessão que compreende uma corrente bidireccional quando uma sessão é estabelecida ou modificada entre dois terminais móveis ou entre um terminal móvel e um servidor, através de 8 uma ligação de comunicação; e para aplicar a classe de tráfego superior atribuída a qualquer uma das correntes de media da sessão, a todas as correntes de media da sessão enquanto dura a sessão, se a corrente unidireccional for adicionada à sessão que compreende a corrente bidireccional numa rede móvel para determinar uma classe máxima de tráfego autorizada para um determinado fluxo de media de uma sessão entre dois terminais móveis ou entre um terminal móvel e um servidor, através de uma ligação de comunicação.
De acordo com um aspecto da presente invenção, é providenciada uma Função de Decisão de Políticas (PDF) numa rede móvel para determinar uma classe máxima de tráfego autorizada para um determinado fluxo de media de uma sessão entre dois terminais móveis, ou entre um terminal móvel e um servidor; determinar se uma corrente unidireccional é adicionada a uma sessão que compreende uma corrente bidireccional, quando a sessão é estabelecida ou modificada entre dois terminais móveis, ou entre um terminal móvel e um servidor, através de uma ligação de comunicação; e aplicar a classe de tráfego superior atribuída a qualquer corrente de media da sessão, a todas as correntes de media da sessão enquanto dura a sessão, se a corrente unidireccional for adicionada que compreende a corrente direccional. A presente invenção é mais especificamente descrita nos seguintes parágrafos, fazendo referência aos desenhos anexos apenas a título de exemplo. 9
BREVE DESCRIÇÃO DOS DESENHOS
Uma apreciação mais completa da presente invenção e de muitas das vantagens inerentes a ela passam a ficar mais claras, na medida em que se tornam mais compreensíveis com referência à seguinte descrição detalhada, quando considerada em conjunto com os desenhos anexos, nos quais os mesmos símbolos de referência indicam componentes iguais ou idênticos, em que: A FIG. 1 ilustra uma arquitectura do sistema de rede exemplificativa para providenciar serviços de telecomunicação, incluindo serviços de multimédia IP de acordo com a Especificação 3GPP, Comunicado 5; A FIG. 2 ilustra uma arquitectura de interface exemplificativa das entidades funcionais IMS de acordo com a Especificação 3GPP, Comunicado 5; A FIG. 3 ilustra uma arquitectura de interface exemplificativa das entidades funcionais IMS de acordo com um versão da presente invenção; A FIG. 4 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis) , ou entre um terminal móvel e um servidor, utilizando novas regras de mapeamento, quando as correntes de media são unidireccionais e têm a mesma direcção de acordo com uma versão da presente invenção; A FIG. 5 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis), ou entre um terminal móvel e um servidor, utilizando novas regras de mapeamento, 10 quando as correntes de media são unidireccionais e não têm a mesma direcção de acordo com uma versão da presente invenção; A FIG. 6 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis), ou entre um terminal móvel e um servidor, utilizando novas regras de mapeamento, quando uma corrente de media é bidireccional e a outra é unidireccional de acordo com uma versão da presente invenção; e A FIG. 7 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis) , ou entre um terminal móvel e um servidor, utilizando novas regras de mapeamento, quando uma corrente de media é bidireccional (não video/áudio) e a outra é unidireccional (áudio/video) de acordo com uma versão da presente invenção.
O MELHOR MÉTODO PARA REALIZAR A INVENÇÃO A presente invenção pode ser aplicada para ser utilizada com todos os tipos de redes que suportam uma série de diferentes tipos de correntes de media, incluindo por ex. segundas e terceiras gerações de redes GSM (Comunicações Móveis para Sistema Global), redes de tráfego como a Internet, Intranets, redes de área local (LAN) e redes de tráfego baseadas em ATM, e redes terminais como redes telefónicas públicas comutadas (PSTN), ISDN, redes IP/LAN, X.25 e Redes Móveis Terrestres Públicas (PLMN), e sistemas interligados e protocolos relacionados utilizados para transferência de voz, mensagem, dados e imagem entre 11 sistemas nessas redes móveis. No entanto, para simplificar, as discussões vão concentrar-se sobretudo numa rede de multimédia simples, incluindo entidades do Subsistema de Multimédia IP (IMS) para providenciar serviços de multimédia IP. A atenção é agora direccionada para os desenhos e, particularmente, para a FIG. 1, que ilustra uma arquitectura do sistema de rede exemplificativa para providenciar serviços de telecomunicação, incluindo serviços de multimédia IP de acordo com a Especificação 3GPP, Comunicado 5. Como se pode ver na FIG. 1, a arquitectura do sistema de rede 100 pode, de um modo geral, incluir por ex. um equipamento de utilizador inicial (UE) 110, um equipamento de utilizador terminal (UE) 120 ou vice-versa e uma ligação de comunicação 130 disposta para ligar os equipamentos de utilizador (UE) 110/120, e pode estender-se a uma única rede ou a diferentes redes, como por ex. uma Rede Móvel Terrestre Pública (PLMN) 132 ou uma ou mais redes de tráfego 134 e uma rede terminal 136. O equipamento de utilizador (UE) 110/120 pode ser qualquer dispositivo ou terminal de utilizador que permita que um utilizador aceda a redes de serviço, incluindo por ex. um servidor remoto ou terminal móvel para GSM conforme definido em 3GPP TS 24.002, V5.0.0 (Dezembro 2001), Comunicado 5.
Cada UE 110/120 pode incluir por ex. uma terminação móvel (MT) 112, um equipamento terminal (TE) 114 e uma função de adaptação terminal (TAF) 116 dispostos de modo a realizar uma transmissão de rádio e funções relacionadas, e muitos contêm aplicações de ponta a ponta para suportar serviços de telecomunicações. 12 A rede de tráfego 134 pode incluir, mas não se limita, a Internet, a Intranet, uma rede de área local (LAN) ou uma rede de tráfego com base em ATM. A rede de terminação 136 pode incluir, mas não está limitada, uma rede telefónica de comutação pública (PSTN), um ISDN, uma rede IP/LAN, X.25 ou outra Rede Móvel Terrestre Pública (PLMN). A FIG. 2 ilustra uma arquitectura de interface exemplificativa das entidades funcionais IMS em redes móveis de acordo com a Especificação 3GPP, Comunicado 5. Como se pode ver na FIG. 2, o Nó de Suporte (GGSN) da porta GPRS (serviço de rádio de pacote geral) 210 e a Função de
Controlo da Sessão de Chamada Proxy (P-CSCF) 220 representam entidades de rede que fazem parte da rede central. GGSN 210 pode ser utilizado para lidar com a transmissão de pacotes para/de UE 110/120 (por ex. estações móveis). P-CSCF 220 pode ser utilizado para servir como um primeiro ponto de contacto para um determinado UE 110/120 e para providenciar serviços de gestão da sessão e procedimentos relacionados com CSCF, incluindo estabelecer contexto PDP (Protocolo de Dados de Pacote, por ex. IP) para a sinalização relacionada com o subsistema de multimédia IP (IMS), o registo e outros procedimentos para sessões IMS.
De acordo com a Especificação 3GPP, Comunicado 5 (Dezembro 2002), é integrada uma Função de Decisão de Políticas (PDF) 222 no P-CSCF 220 para supervisionar uma sessão IMS, quando o UE 110 emite ou recebe uma mensagem SIP (Protocolo de Iniciação de Sessão) com sinalização SDP (Protocolo de Descrição da Sessão) para negociar parâmetros para uma sessão IMS, tomar decisões de políticas baseadas na sessão IMS e informação relacionada com media obtida do 13 P-CSCF 220, incluindo decisões sobre a máxima classe de tráfego autorizada para um determinado fluxo de media entre dois utilizadores (por ex. terminais móveis), ou entre um terminal móvel e um servidor, e depois trocar informação de decisões com o GGSN 210 através de uma interface Go, conforme é definido no 3GPP TS 29.207 V.5.2.0 (Dezembro 2002) "Policy Control over Go interface", Comunicado 5. Além disso, só é permitida uma única sessão IMS para cada contexto PDP (Protocolo de Dados de Pacote, por ex. IP). Em alternativa, a PDF pode também ser implementada num elemento de rede à parte que fica separado do P-CSCF 220, conforme descrito na Especificação 3GPP, Comunicado 6 (Janeiro 2003) .
De acordo com o que foi anteriormente discutido e definido na Especificação 3GPP, Comunicado 5, a PDF 222 pode ser utilizada para criar um conjunto de informações vinculativas (especialmente um testemunho de autorização) , de modo a vincular o nível IMS e o nível de suporte GPRS de uma sessão IMS e enviar a informação vinculativa ao GGSN 210, através do equipamento de utilizador (UE) 110. A informação vinculativa associa o contexto PDP (Protocolo de Dados de Pacote, por ex. IP) a um ou mais componentes de media (fluxos IP) de uma sessão IMS, e é utilizada pelo GGSN 210 para pedir uma informação de política local baseada em serviço (SBLP) da PDF 222. Este tipo de informação vinculativa inclui normalmente: (1) um testemunho de autorização enviado pelo P-CSCF 220 para o UE 110 durante a sinalização SIPISDP, e (2) um ou mais identificadores de fluxo (que podem ser adicionados pelo UE 110 depois de receber a informação 14 vinculativa do P-CSCFIPDF) utilizados pelo UE 110, GGSN 210 e PDF 222 para identificar unicamente o(s) fluxo(s) de media IP associado(s) à sessão SIP.
Depois de receber este tipo de informação vinculativa, o GGSN 210 é utilizado para procurar o endereço PDF do conjunto de informação vinculativa (do testemunho de autorização) recebido pelo EU 110, para identificar a PDF correcta e certificar-se que as operações de contexto PDP pedidas pelo UE 110 cumprem a negociação anterior no nível IMS.
No GGSN 210, o Ponto de Imposição de Políticas (PEP) 212 é uma entidade lógica que comunica com a PDF relativamente ao controlo de política local com base em serviços (SBLP) . Para simplificar, presume-se que o GGSN 210 contém implicitamente o PEP 212, a não ser que tenha sido especificado de outro modo. O GGSN 210 envia pedidos e recebe decisões do PDF 222. O GGSN 210 pode ocultar os dados de decisão de políticas das decisões PDF que podem ser utilizadas mais tarde para uma decisão de política local, o que permite que o GGSN 210 tome decisões de controlo de políticas sobre a qualidade da autorização de serviço (QoS) para modificações do contexto PDP sem requerer interacção adicional com a PDF 222. As funcionalidades PEP para SBLP no GGSN são descritas no 3GPP TS 29.207 V.5.2.0 (Dezembro 2002) "Policy Control over Go Interface", Comunicado 5 e, consequentemente, não há necessidade de as repetir aqui.
Tanto UE 110 como GGSN 210 podem também incluir mecanismos para gerir a qualidade do serviço IP (QoS) de funções de ponta a ponta e fluxos de sinalização 15 relacionados, conforme aqui descrito e incorporado na referência, o 3GPP TS 23.207 V.5.6.0 (Dezembro 2002) "End-To-End Quality of Service (QoS) Concept and Architecture", Comunicado 5, e o 3GPP TS 29.208 V.5.2.0 (Dezembro 2002) "End-To-End Quality of Service (QoS) signaling flows", Comunicado 5. Por exemplo, o UE 110 pode incluir uma aplicação de cliente (não ilustrada), um gestor de serviço de suporte IP (BS) (não ilustrado) , uma função de transferência/mapeamento (não ilustrada) e; opcionalmente um gestor de serviço de suporte UMTS (BS) (não ilustrado). De igual modo, o GGSN 210 também pode incluir um gestor IP BS (não ilustrado), uma função de transferência/mapeamento (não ilustrada) e, opcionalmente, um gestor UMTS BS (não ilustrado). Os gestores IP BS normalmente utilizam mecanismos IP padrão para gerir os serviços de suporte IP. As funções de transferência/mapeamento providenciam o inter-funcionamento entre os mecanismos e os parâmetros utilizados dentro dos serviços de suporte UMTS e aqueles que são utilizados dentro dos serviços de suporte IP, e interagem com os gestores IP BS. Os gestores UMTS BS utilizam mecanismos UMTS padrão para gerir serviços de suporte UMTS (Sistema de Telecomunicações Móveis Terrestres) e as funções de gestão QoS para serviços de suporte UMTS.
De um modo geral, é estabelecida uma sessão (ligação) entre equipamentos de utilizador (UE) (por ex. terminais móveis capazes de transmitir e receber correntes de multimédia IP) ou entre um terminal móvel e um servidor. A sessão conforme está estabelecida entre equipamentos de utilizador (UE) (por ex. terminais móveis) ou entre um terminal móvel e um servidor, compreende por ex. um fluxo 16 de áudio bidireccional e um fluxo de vídeo unidireccional. 0 fluxo de áudio bidireccional é utilizado para uma conversação em tempo real e, consequentemente, requer uma classe de tráfeqo em tempo real de pouco atraso, isto é, a classe de tráfego CONVERSACIONAL. 0 fluxo de vídeo unidireccional é utilizado para transferir imagens de vídeo em movimento numa direcção apenas. Um fluxo de vídeo em tempo real unidireccional deste tipo tolera maiores atrasos de transmissão e variações de atraso (também conhecido por instabilidade) porque o emissor não está à espera de receber qualquer resposta. Como resultado, o fluxo unidireccional em tempo real usa normalmente uma classe de tráfego CORRENTE em prática. A classe de tráfego CONVERSACIONAL é caracterizada por um curto atraso máximo de transmissão e variação de atraso para minimizar o atraso experimentado pelas partes de comunicação (isto é, terminais móveis ou entre um terminal móvel e um servidor), enquanto a classe de tráfego CORRENTE é caracterizada por um atraso mais longo da transmissão máxima e variação de atraso porque não existe uma comunicação bilateral em tempo real com respostas esperadas em tempo real. Como resultado, a classe de tráfego CONVERSACIONAL é conhecida por "uma classe de tráfego superior" relativamente à classe de tráfego CORRENTE que é conhecida por "uma classe de tráfego inferior",
De acordo com 3GPP TS 23.107, podem existir outras classes de tráfego exigidas na sessão exemplificativa, como classes de tráfego INTERACTIVA e classes de tráfego SECUNDÁRIA. Por exemplo, a classe de tráfego INTERACTIVA pode ser caracterizada por tolerar ainda maiores atrasos de transmissão e instabilidades do que a classe de tráfego 17 CORRENTE e é, consequentemente, "uma CORRENTE de tráfego inferior" em relação à classe de tráfego CORRENTE. A classe de tráfego SECUNDÁRIA pode ser caracterizada por tolerar atrasos de transmissão e instabilidades ainda maiores e, como resultado, continua a ser uma classe de tráfego inferior à classe de tráfego INTERACTIVA. No entanto, as correntes de áudio e vídeo da sessão exemplificativa podem ser suportadas pelo mesmo suporte (por ex. um contexto PDP no sistema de rede) ou podem ter uma relação temporal recíproca, o que quer dizer que os recursos do suporte de toda a sessão têm uma classe de tráfego CONVERSACIONAL de acordo com a "classe de tráfego superior" da sessão.
Após algum tempo, a sessão pode ser modificada, ou seja, as partes de comunicação (isto é, terminais móveis ou entre um terminal móvel e um servidor) podem querer terminar, por exemplo, o fluxo de áudio bidireccional na sessão, ao mesmo tempo que mantém o fluxo de vídeo unidireccional na sessão. A classe de tráfego para recursos de suporte da sessão tem de ser correspondentemente mudada pela PDF. Por exemplo, se a sessão for modificada e o fluxo de áudio bidireccional com a classe de tráfego CONVERSACIONAL for removido da sessão, o fluxo de vídeo unidireccional, com a classe de tráfego CORRENTE como condição por defeito, tem agora a "classe de tráfego superior" da sessão. Consequentemente, a PDF muda (isto é, para baixo) a classe de tráfego do suporte da sessão da classe, de classe de tráfego CONVERSACIONAL para classe de tráfego CORRENTE.
Porém, quando a sessão é modificada (por ex. do vídeo bidireccional e vídeo unidireccional para o vídeo unidireccional apenas), e a classe de tráfego é mudada pela 18 PDF 222 (por exemplo, de conversacional para corrente), alguns parâmetros, como o tamanho da memória temporária no terminal receptor, são diferentes nestas classes QoS, podendo a mudança da classe de tráfego com a mudança inerente do atraso de transmissão causar uma capacidade negativa da memória temporária no terminal receptor, reduzindo assim a qualidade da ligação captada pelo utilizador final.
Por exemplo, quando é estabelecida uma sessão (ligação) , os terminais móveis ou um terminal móvel e um servidor iniciam a comunicação com uma corrente de voz bidireccional. Neste ponto, a PDF 222 atribui à corrente de voz a máxima classe de tráfego autorizada igual a CONVERSACIONAL. Algum tempo depois, um dos terminais móveis ou o terminal móvel e o servidor decide adicionar uma corrente de vídeo à comunicação, e a corrente de vídeo é unidireccional. Neste ponto, a PDF 222 verifica a definição actual do fluxo de multimédia IP pertencente à sessão (ligação) e decide atribuir a corrente de vídeo à máxima classe de tráfego autorizada igual a "CONVERSACIONAL". Esta classe é escolhida porque já existe um fluxo de media bidireccional autorizado até à classe de tráfego "CONVERSACIONAL". Como resultado, o terminal móvel ou o servidor, que recebem ambos correntes de voz e de vídeo, são capazes de obter uma sincronização de vídeo áudio. Após algum tempo, os dois terminais móveis ou o terminal móvel e o servidor decidem deixar a comunicação de voz, mas continuar a transmissão de vídeo unidireccional. Neste ponto, a PDF 222 verifica a definição actual dos fluxos de multimédia IP pertencentes à sessão (apenas o fluxo de vídeo unidireccional mantém-se na comunicação) e decide 19 mudar a sua máxima classe de tráfego autorizada "CORRENTE". Isto acontece porque um fluxo de media unidireccional consegue sempre uma máxima classe de tráfego autorizada igual a "CORRENTE".
Porém, se a máxima classe de tráfego autorizada é mudada de "CONVERSACIONAL" para "CORRENTE", esta mudança cria problemas ao terminal móvel ou ao servidor que recebe a corrente de vídeo. Em particular, a mudança iria causar uma renegociação do contexto PDP, onde não é apenas a classe de tráfego que é diferente, mas também o atraso de transferência. Como resultado, um atraso de transferência maior podia causar frequentes e repetidas capacidades negativas da memória temporária no terminal móvel receptor, e um media não contínuo que resulta numa menor qualidade captada pelo utilizador final. Isto acontece porque o terminal móvel ou a memória temporária do servidor é dimensionada de acordo com o atraso de transferência da classe de tráfego "CONVERSACIONAL" e não com o da classe de tráfego "CORRENTE".
Outro problema significativo pode também ocorrer quando é adicionada uma corrente unidireccional (por ex. vídeo) a uma sessão existente, que compreende uma corrente bidireccional (por ex. áudio). 0 pedido da classe de tráfego sinalizada da corrente de vídeo unidireccional é normalmente Corrente. A classe de tráfego da sessão bidireccional é Conversacional. Se as correntes de media possuem uma relação temporal (por ex. explicação verbal da corrente de vídeo na corrente de áudio), a diferença das classes de tráfego vai causar uma diferença nos atrasos de transmissão (devido a diferentes comprimentos de memória temporária nos receptores para compensar os diferentes 20 atrasos e a instabilidades do atraso na transmissão), reduzindo assim a qualidade da ligação captada pelo utilizador final.
Por exemplo, se uma sessão (ligação) inicia com um fluxo unidireccional. Neste ponto, a PDF 222 atribui "CORRENTE" como máxima classe de tráfego autorizada. Após algum tempo, é adicionado um fluxo de chamada de voz bidireccional à comunicação. Neste ponto, a PDF 222 atribui ao fluxo de voz a máxima classe de tráfego autorizada igual a "CONVERSACIONAL". A PDF 222 também volta a verificar a máxima classe de tráfego autorizada da primeira corrente existente e actualiza para "CONVERSACIONAL." Em alguns casos, a actualização pode activar uma renegociação de contexto PDP para o fluxo de multimédia IP, particularmente quando as correntes de multimédia IP estão relacionadas e requerem sincronização. No entanto, na maior parte dos casos, a actualização não é exigida.
No que diz agora respeito à FIG. 3, é ilustrada uma arquitectura de interface exemplificativa das entidades funcionais IMS de acordo com uma versão da presente invenção. A arquitectura de interface como é apresentada na FIG. 3, mantém vantajosamente a classe de tráfego utilizada para a sessão, isto é, para o resto das correntes de multimédia IP, quando as correntes de media que requerem a classe de tráfego superior são removidas da sessão para evitar o problema que ocorre quando a classe de tráfego é mudada, e para aplicar a classe de tráfego superior (tempo real, isto é conversacional, corrente), atribuída a qualquer uma das correntes de media da sessão, a todas as correntes de media (tempo real) da sessão enquanto dura a 21 sessão para evitar o problema que ocorre quando uma corrente de media é adicionada a uma sessão existente.
Como se pode ver na FIG. 3, pode ser implementado um algoritmo 310 como parte da PDF 222, quer a PDF 222 é integrada no P-CSCF 220, quer permanece como uma entidade de rede à parte do P-CSCF 220. No algoritmo 310, pode definir-se a remoção de um ou vários fluxos de multimédia enquanto dura a sessão (ligação) para não reduzir a máxima classe de tráfego autorizada anteriormente atribuída, e pode igualmente definir-se a adição de fluxos de media para atribuir a máxima classe de tráfego dos fluxos a todos os fluxos (tempo real) da sessão (ligação). A utilização de um algoritmo destes 310 pode ser aplicada a todos os sistemas, incluindo todas as futuras redes de multimédia, nas quais uma sessão pode compreender uma série de diferentes tipos de correntes de media, e pode obedecer por ex. a 3GPP TS 23.207 V.5.6.0 (Dezembro 2002) "End-To-End Quality of Service (QoS) Concept and Architecture", Comunicado 5, e a 3GPP TS 29.208 V.5.2.0 (Dezembro 2002) "End-To-End Quality of Service (QoS) signaling flows", Comunicado 5. A sincronização de correntes de media em tempo real também pode ser melhorada através da eliminação da diferença de atrasos de transmissão de correntes de media pertencentes à mesma sessão, melhorando assim a qualidade captada pelo utilizador final. Pode observar-se a desvantagem das classes QoS, atribuídas a algumas correntes de media na sessão, poderem ser superiores ao requerido, reduzindo assim a capacidade geral da rede e, potencialmente, causando também maiores custos de ligação para o utilizador final. 22
Por exemplo, o utilizador 1UE inicia uma sessão ou expande uma sessão com menor fluxo de classe de tráfego, com (a) corrente (s) unidireccional/unidireccionais. Neste ponto, a PDF 222 atribui "CORRENTE" como máxima classe de tráfego autorizada aos fluxos de media relevantes. Mais tarde, durante a duração da sessão, o utilizador 1UE inicia um fluxo bidireccional (por ex. áudio) dentro da mesma sessão. Neste ponto, a PDF 222 atribui ao fluxo de áudio a máxima classe de tráfego autorizada igual a "CONVERSACIONAL". A PDF 222 também volta a verificar a máxima classe de tráfego autorizada da(s) corrente (s) existente (s) . A actualização dos fluxos de media existentes para o valor da classe de tráfego do novo fluxo bidireccional pode ser desnecessária, porque as correntes unidireccionais começaram antes do fluxo conversacional bidireccional e, consequentemente, podem não ter uma relação temporal com o fluxo de conversacional bidireccional. A actualização não é desejada porque as classes QoS atribuídas a algumas correntes de media na sessão podem ser superiores ao requerido, reduzindo assim a capacidade geral da rede e, potencialmente, causando também maiores custos de ligação para o utilizador final.
Porém, a actualização pode ser evitada se a(s) corrente (s) unidireccional/unidireccionais é/são iniciadas primeiro e considerado(s) independente(s) de um fluxo ou fluxos bidireccionais posteriores, ou seja, não existe relação temporal. Não é, assim, requerida qualquer sincronização, isto é, a classe de tráfego permanece "CORRENTE," quando é adicionada uma corrente de media conversacional bidireccional. (Num sistema IMS, os fluxos com diferentes classes de tráfego/QoS usam contextos PDP 23 separados). Em alternativa, se um fluxo conversacional bidireccional começa primeiro e, mais tarde, é adicionada uma corrente unidireccional à sessão, a corrente unidireccional é considerada dependente da bidireccional, isto é, existe uma relação temporal entre elas. A sincronização é, pois, requerido, ou seja, a classe de tráfego da corrente unidireccional é definida para o mesmo valor da classe de tráfego do fluxo bidireccional, isto é, "CONVERSACIONAL" (pela PDF 222) . (Num sistema IMS, os fluxos com diferentes classes de tráfego/QoS podem usar um contexto PDP comum ou contextos PDP separados). A PDF 222, como se pode ver na FIG. 3, pode ser configurada para determinar a máxima classe de tráfego autorizada para um determinado fluxo de media de uma ligação entre dois utilizadores ou terminais móveis, ou entre um terminal móvel e um servidor. Um algoritmo exemplificativo 310 na PDF 222 pode incluir os seguintes:
Se foi atribuída uma máxima classe de tráfego autorizada a um determinado fluxo X, então A adição ou remoção de um ou vários fluxos de media durante a duração de uma sessão (ligação) não produz qualquer mudança para a máxima classe de tráfego autorizada anteriormente atribuída ao fluxo X.
As regras de mapeamento também podem ser exigidas em conformidade com 3GPP TS 29.208 V.5.2.0 (Dezembro 2002) "End-To-End Quality of Service (QoS) signaling flows", Comunicado 5, de modo a poder atribuir uma máxima classe de tráfego QoS apropriada ao serviço de corrente. Estas regras de mapeamento podem ser utilizadas pela PDF 222, como se pode ver na FIG. 3, quando uma sessão é iniciada ou modificada para obter a máxima QoS autorizada apropriada 24 por componente de media. No entanto, é necessário definir um mapeamento adequado para garantir que os futuros serviços não sejam limitados ou sejam sujeitos a uso impróprio, podendo-se evitar fraudes e ineficiências. De um modo geral, um serviço de corrente pode ser caracterizado pela direcção do fluxo de dados - é unidireccional - e pelo tipo de media - áudio ou vídeo. Assim sendo, podem analisar-se todos os componentes de media pertencentes a uma sessão. Por exemplo, se todos os componentes de media de áudio e de vídeo forem unidireccionais e tiverem a mesma direcção, a aplicação pode ser considerada como corrente e, por conseguinte, os limites QoS para a corrente podem aplicar-se como máxima QoS autorizada.
Relativamente às figuras 4-7, são apresentados exemplos das regras de mapeamento. Por exemplo, a FIG. 4 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis), quando as correntes de media são unidireccionais e têm a mesma direcção de acordo com uma versão da presente invenção. A FIG. 5 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis), quando as correntes de media são unidireccionais e não têm a mesma direcção de acordo com uma versão da presente invenção. A FIG. 6 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis), quando uma corrente de media é bidireccional e a outra é unidireccional de acordo com uma versão da presente invenção. Por último, a FIG. 7 ilustra uma sessão de trabalho exemplificativa entre dois equipamentos de utilizador (terminais móveis), quando uma corrente de media é bidireccional (não vídeo/áudio) e o outra é 25 unidireccional (áudio/vídeo) de acordo com uma versão da presente invenção.
Mais especificamente, na FIG. 4, quando as correntes de media (áudio e video) são unidireccionais e têm a mesma direcção, a autorização do fluxo de media é "CORRENTE". Na FIG. 5, quando as correntes de media são unidireccionais e não têm a mesma direcção, a autorização do fluxo de media é "CONVERSACIONAL." Na FIG. 6, quando uma corrente de media é bidireccional e a outra é unidireccional, a autorização do fluxo de media é "CONVERSACIONAL." Na FIG. 7, quando uma corrente de media é bidireccional (não áudio/vídeo) e a outra é unidireccional (áudio/vídeo), a autorização do fluxo de media é "CONVERSACIONAL" para aplicação e "CORRENTE" para vídeo.
As regras de mapeamento podem estender-se para garantir a atribuição adequada da máxima classe QoS autorizada de acordo com o serviço pedido. As regras que definem o mapeamento dos parâmetros SDP para as máximas classes QoS autorizadas estendem-se, por exemplo, para permitir o mapeamento para a classe de corrente no caso de componentes de media unidireccionais do tipo "áudio" ou "vídeo" com a mesma direcção. Encontramos, em baixo, exemplos das regras de mapeamento que podem ser utilizadas pelo UE 110 (por ex. terminal móvel ou servidor) e a PDF 222, como se pode ver nas FIGURAS 2 e 3. Particularmente, a TABELA #1 ilustra regras de mapeamento exemplificativas para derivação das velocidades máximas dos dados autorizadas e a máxima classe do serviço de qualidade (QoS) autorizada por componente de media na PDF 222. Estas regras de mapeamento exemplificativas podem ser incluídas num módulo de software guardado ou providenciado num meio de 26 leitura informático ou, em alternativa, pode ser providenciado por download na Internet ou integrado na PDF 222, como se pode ver nas FIGURAS 2 e 3.
Correspondentemente à TABELA #1, a TABELA #2 ilustra regras de mapeamento exemplificativas para derivação da máxima largura de banda autorizada e a máxima classe de tráfego autorizada por componente de media no UE 110 (por ex. terminal móvel ou servidor). De igual modo, estas regras de mapeamento também podem ser incluídas num módulo de software guardado ou providenciado num meio de leitura informático ou, em alternativa, pode ser providenciado por download na Internet ou integrado no UE 110 (por ex. terminal móvel ou servidor), como se pode ver nas FIGURAS 2 e 3.
TABELA #1 Regras para derivação das Máximas Velocidades de Dados Autorizadas e a Máxima Classe QoS Autorizada por componente de media na PDF
Parâmetro QoS autorizado por componente de media Derivação dos Parâmetros SDP Máxima IF a=recapenas ENTÃO Velocidade de IF <SDP direcção> = móvel inicial THEN Dados Direcção:= ligação descendente; Autorizada DL ELSE móvel terminado */ (Max_DR_D L) Direcção:= ligação ascendente; e UL ENDIF: (Max_DR_UL) OUTRO por componente IF a=envapenas THEN de media IF <direcção SDP> = móvel inicial THEN Direcção:= ligação ascendente; 27 (ver nota 1) ELSE/* móvel terminado */ Direcção:= ligação descendente; ENDIF; ELSE /* envrec ou nenhum atributo de direcção */ Direcção;=ambas: ENDIF; ENDIF;
IF b=AS:<largura de banda> está presente THEN IF Direcção=ligação descendente THEN IF <transporte>"RTP/AVP" then Max_DR_UL:=0,025 *,<largura de banda>; Max_DR_DL:=1,025 * clargura de banda>; ELSE Max_DR_UL:=0 ; Max_DR_DL:=<largura de banda>: ENDIF; ELSE IF Direcção=ligação ascendente THEN IF <Transporte>="RTP/AVP" THEN Mar_DR_UL:= 0,025 * <largura de banda>; Max-DR-DL:=1,025 * clargura de banda>; ELSE Max_DR_UL:=<largura de banda>; Max_DR_DL ;=0; ENDIF; ELSE */ Direcção=ambas */ Max_DR_UL:= 1 ,025 * clargura de banda>; Max_DR_DL:= 1,025 * clargura de banda>; ENDIF; ENDIF; ELSE bw:= conforme definido pelo operador; IF Direcção=ligação descendente THEN Max_DR_UL:=0; Max_DR_DL:=bw; ELSE 28 IF Direcção=ligação ascendente ELSE Max_DR_UL:= bw; Max_DR_DL:=0; ELSE /*Direcção=ambas*/ Max_DR_UL:=bw; Max_DR_DL.:=bw: ENDIF ENDIF: ENDIF; Máxima Classe IF (todos os componentes de media do tipo de media QoS "áudio" ou "vídeo" para a sessão são Autorizada unidireccionais e têm a mesma direcção) THEN [MáxClasse] MaxClassDerivation;=B; /* corrente */ por ELSE Componente de MaxClassDerivation:=A; /*conversacional */ media ENDIF; (ver nota 2, X CASO <media> DE e Y) "áudio": MaxClass:= MaxClassDerivation; "vídeo": MaxClass:= MaxClassDerivation; "aplicação"; MáxClasse:= A; "dados": MáxClasse:=E; /*interactiva com prioridade 3*/ "controlo": MáxClasse:=C; /*interactiva com prioridade 1 */ /* novo tipo de media */ DE OUTRO MODO: MáxClasse:=F: /*secundária */ FIM: ΝΟΤΑ 1: Para um componente de media RIP, as Máximas Velocidades de Dados Autorizados DL/UL são a soma das Máximas Velocidades de Dados Autorizadas DL/UL para as correntes de media RTP e os fluxos associados RTCP IP DL/UL. NOTA 2: A Máxima Classe QOS Autorizada para um fluxo RTCP IP é a mesma da correspondente corrente de media RTP. ΝΟΤΑ X: Quando uma corrente de áudio ou vídeo é removida de uma sessão, as restantes correntes de media na sessão mantêm as máximas classes QoS autorizadas originalmente atribuídas. 29 29 NOTA y: Quando é adicionada uma corrente de áudio ou de vídeo a uma sessão, a PDF deriva a máxima classe QoS autorizada, tendo em conta as correntes de media já existentes dentro da sessão. A PDF 222 deve, por cada sessão em curso, guardar os parâmetros QoS IP autorizados por componente de media. Quando o GGSN 210 requer os parâmetros QoS UMTS autorizados para um contexto PDF activado/modifiçado PDP, que suporta um ou mais componente (s) de media, a PDF 222 pode usar as regras de mapeamento como se pode ver por ex. na TABELA #1, para calcular os parâmetros QoS autorizados.
TABELA #2: As regras para derivação da Máxima Largura de Banda DL/UL Autorizada e a Minima Classe de Tráfego Autorizada por componente de media no UE
Parâmetro UMTS QoS Autorizado por componente de media Derivação dos Parâmetros SDP Máxima Largura de /* Verificar se o contexto IMS (o critério para esta Banda Autorizada verificação é do âmbito do fabricante UE) */ DL (Máx__BW_DL) IF contexto IMS THEN e UL (Máx_BW_UL) por IF a=recapenas ENTÃO componente de IF <direcção SDP> = móvel inicial THEN media Direcção:= ligação descendente; ELSE /* móvel terminado */ Direcção:= ligação ascendente; ENDIF; ELSE; IF a=envapenas THEN IF <direcção SDP> = móvel inicial THEN 30 Direcção: = ligação ascendente; ELSE /* móvel terminado */ Direcção:= ligação descendente; ENDIF; ELSE /* envrec ou nenhum atributo de direcção */ Direcção:=ambas; ENDIF; ENDIF; IF b=AS: clargura de banda> está presente THEN IF Direcção=ligação descendente THEN IF <transporte>="RTP/AVP" então Max_BW_UL:=0,025 * clargura de banda>; Max_BW_DL:=1,025 * clargura de banda>; ELSE Max_BW_UL:=0; Max_BW_DL:=clargura de banda>; ENDIF; ELSE IF Direcção=ligação ascendente ELSE IF ctransporte>="RTP/AVP" then Max_BW_UL:= 1,025 * clargura de banda>; Max_BW_DL:=0,025 * clargura de banda>; ELSE Max_BW_UL:=<largura de banda>; Max_BW_DL:=0; ENDIF: ELSE /* Direcção=ambas */ Max_BW_UL:= 1,025 * clargura de banda>; Max_BW_DL:= 1,025 * clargura de banda>; ENDIF; ENDIF; ELSE bw:= conforme definido pelo fabricante UE; IF Direcção=ligação descendente THEN Max_BW_UL:=0; 31
Max_BW_DL:= bw ; ELSE IF Direcção=ligação ascenden THEN Max_BW_UL:= bw; Max_BW_DL:=0; ELSE /* Direcção=ambas */ Max_BW_UL:= bw; Max_BW_DL:= bw; ENDIF; ENDIF; ENDIF: ELSE Não é dada nenhuma autorização ; ENDIF Máxima Classe de /* Verificar se o contexto IMS (o critério para esta Tráfego verificação é do âmbito do fabricante UE ) */ IF contexto IMS Autorizada THEN [MáxClasseTráfego IF (todos os componentes de media do tipo de media "áudio" ou ] por componente "vídeo" para a sessão são unidireccionais e têm a mesma de media (ver direcção) THEN NOTA x e y) MaxService:= corrente: ELSE MaxService:=conversacional; ENDIF; CASO <media> DE "áudio":MaxTrafficClass:= MaxService; "vídeo"; MaxTrafficClass:= MaxService; "aplicação": MaxTrafficClass:= conversacional; "dados"; MaxTrafficClass:=interactiva com prioridade 3; "controlo": MaxTrafficClass:=interactiva com prioridade 1; /*novo tipo de media*/ OU DE OUTRO MODO: MaxTrafficClass:=secundária; FIM ELSE 32
32 Não é dada nenhuma autorização; ENDIF ΝΟΤΑ X: Quando uma corrente de áudio ou de vídeo é removida de uma sessão, as restantes correntes de media devem manter as máximas classes de tráfego autorizadas que foram originalmente atribuídas. NOTA y: Quando é adicionada rima corrente de áudio ou de vídeo a uma sessão, o UE deriva a máxima classe de tráfego autorizada, tendo em conta as correntes de media já existentes dentro da sessão. A PDF 110 deve, por cada sessão em curso, guardar os parâmetros QoS UMTS autorizados por componente de media. Antes de activar ou modificar o contexto PDP, o UE 110 pode verificar se o requerido UUDL da velocidade de bits garantido (se a Classe de Tráfego for Conversacional ou Corrente) ou se o requerido UUDL da máxima velocidade de bits (se a Classe de Tráfego for Interactiva ou Secundária) não excede o UUDL da máxima largura de banda autorizada por contexto de PDP (calculado de acordo com as regras de mapeamento) . Além disso, o UE 110 pode verificar se a requerida classe de tráfego dos parâmetros QoS UMTS não excede a máxima classe de tráfego autorizada por contexto de PDP (calculado de acordo com as regras de mapeamento).
De acordo com o que foi anteriormente descrito, a arquitectura da interface de rede de acordo com uma versão da presente invenção providencia soluções para a autorização dinâmica de media e a melhor gestão das classes QoS de uma sessão (ligação entre utilizadores ou terminais móveis, ou entre um terminal móvel e um servidor), 33 compreendendo uma série de diferentes tipos de correntes de media dentro das redes móveis, de modo que quando uma ou mais correntes de media são modificadas (novas iniciadas e existentes eliminadas) durante a sessão, a classe de tráfego de uma sessão é definida pelo pedido de classe de tráfego superior pelos fluxos de media pertencentes à mesma sessão para eliminar a diferença dos atrasos de transmissão das correntes de media pertencentes à mesma sessão e, consequentemente, melhora a qualidade da ligação captada pelo utilizador final. A sincronização de correntes de media em tempo real também pode ser melhorada através da eliminação da diferença de atrasos de transmissão de correntes de media pertencentes à mesma sessão, melhorando assim a qualidade captada pelo utilizador final.
Apesar de se ter ilustrado e descrito o que se considera serem versões exemplificativas da presente invenção, os profissionais do ramo entendem que se podem fazer várias alterações e modificações, e que os equivalentes podem ser substituídos por elementos seus sem sair do verdadeiro âmbito da presente invenção. Além disso, pode proceder-se a muitas modificações para adaptar uma situação particular aos ensinamentos da presente invenção sem sair do âmbito central da presente invenção. Por conseguinte, pretende-se que a presente invenção não se limite a uma versão particular apresentada como sendo o melhor modo contemplado para concretizar a presente invenção, mas que a presente invenção inclua todas as versões que se encaixam no âmbito das reivindicações anexas.
Lisboa, 25/10/2010
Claims (10)
1 REIVINDICAÇÕES 1. Um aparelho (222) para gerir a qualidade de serviço de uma sessão, sendo o aparelho (222) configurado para determinar se uma corrente de media (media stream) que requer uma classe de tráfego superior dentro de uma série de correntes de media (media streams) é removida da sessão, quando a sessão estabelecida é modificada entre dois terminais móveis (110, 120) ou entre um terminal móvel e um servidor, através de um ligação de comunicação; caracterizado pelo facto do aparelho (222) ser ainda configurado para manter a classe de tráfego existente para as restantes correntes de media na sessão, se a corrente de media que requer a classe de tráfego superior for removida da sessão.
2. Um aparelho (222) para gerir a qualidade de serviço de uma sessão do aparelho (222), que é configurado para determinar se uma corrente unidireccional é adicionada à sessão que compreende uma corrente bidireccional, quando a sessão é estabelecida ou modificada entre dois terminais móveis (110, 120) ou entre um terminal móvel e um servidor, através de uma ligação de comunicação; caracterizado pelo facto do aparelho (222) ser ainda configurado para aplicar a classe de tráfego superior, atribuída a qualquer uma das correntes de media da sessão, a todas as correntes de media da sessão durante a duração da sessão, se a corrente unidireccional for adicionada à sessão que compreende a corrente bidireccional. 2 3. 0 aparelho (222) de acordo com a reivindicação 1 ou 2, em que o aparelho (222) é configurado para criar um conjunto de informação vinculativa para vincular um nivel do subsistema de multimédia do protocolo da Internet e um nivel de suporte do serviço de rádio de pacote geral de uma sessão do subsistema de multimédia do protocolo da Internet. 4. 0 aparelho (222) de acordo com qualquer uma das reivindicações anteriores, em que o terminal móvel (110, 120) compreende pelo menos uma função do equipamento terminal e da adaptação terminal configurada para realizar a transmissão de rádio e funções relacionadas, e compreendendo aplicações de ponta a ponta para suportar serviços de telecomunicações.
5. O aparelho (222) de acordo com qualquer uma das reivindicações anteriores, em que o aparelho (222) é configurado para supervisionar a gestão das classes de qualidade de serviço da sessão.
6. O aparelho (222) de acordo com qualquer uma das reivindicações anteriores, em que o aparelho (222) está configurado para tomar decisões de políticas com base na sessão e informação relacionada com media.
7. O aparelho (222) de acordo com qualquer uma das reivindicações anteriores, em que o aparelho (222) está configurado para trocar a informação de decisão com uma porta (210). 3 8. 0 aparelho (222) de acordo com a reivindicação 2 ou qualquer reivindicação que depende da reivindicação 2, em que a corrente unidireccional compreende um fluxo de video unidireccional. 9. 0 aparelho (222) de acordo com a reivindicação 2 ou qualquer reivindicação que depende da reivindicação 2, em que a corrente bidireccional compreende um fluxo de áudio bidireccional.
10. Um método para qerir a qualidade de serviço de uma sessão, compreendendo: determinar se uma corrente de media que requer uma classe de tráfego superior dentro de várias correntes de media é removida da sessão, quando a sessão estabelecida é modificada entre dois terminais ou entre um terminal móvel e um servidor, através de uma ligação de comunicação; caracterizado pelo facto do método compreender: manter a classe de tráfego existente para as restantes correntes de media na sessão, se a corrente de media que requer a classe de tráfego superior for removida da sessão.
11. Um método para gerir a qualidade de serviço de uma sessão, compreendendo: determinar se uma corrente unidireccional é adicionada à sessão que compreende uma corrente bidireccional, quando a sessão é estabelecida ou modificada entre dois terminais 4 móveis ou entre um terminal móvel e um servidor, através de uma ligação de comunicação; caracterizado pelo facto do método compreender: aplicar a classe de tráfego superior, atribuída a qualquer uma das correntes de media da sessão, a todas as correntes de media da sessão durante a duração da sessão, se a corrente unidireccional for adicionada à sessão que compreende a corrente bidireccional. 12. 0 método de acordo com a reivindicação 10 ou 11, compreendendo a criação de um conjunto de informação vinculativa para vincular um nível do subsistema de multimédia do protocolo da Internet e um nível de suporte do serviço de rádio de pacote geral de uma sessão do subsistema de multimédia do protocolo da Internet. 13. 0 método de acordo com qualquer uma das reivindicações de 10 a 12, compreendendo a supervisão da gestão de classes de serviço de qualidade da sessão.
14. O método de acordo com qualquer uma das reivindicações de 10 a 13, compreendendo tomar pelo menos uma decisão de política com base na sessão e informação relacionadas com media.
15. O método de acordo com qualquer uma das reivindicações de 10 a 14, compreendendo trocar informação de decisão com uma porta. 5 16. 0 método de acordo com a reivindicação 11 ou qualquer reivindicação que depende da reivindicação 11, em que a corrente unidireccional compreende um fluxo de video unidireccional. 17. 0 método de acordo com a reivindicação 11 ou qualquer reivindicação que depende da reivindicação 11, em que a corrente bidireccional compreende um fluxo de áudio bidireccional.
18. Um produto de programa informático, compreendendo meios de código de programa armazenados num meio de leitura informático, sendo o meio de código do programa adaptado para realizar qualquer uma das reivindicações de 10 a 17 quando o programa corre num processador. Lisboa, 25/10/2010
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US44579903P | 2003-02-10 | 2003-02-10 | |
US10/766,845 US6888821B2 (en) | 2003-02-10 | 2004-01-30 | Dynamic media authorization in mobile networks |
Publications (1)
Publication Number | Publication Date |
---|---|
PT2048836E true PT2048836E (pt) | 2010-10-29 |
Family
ID=32994319
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PT08163110T PT2048836E (pt) | 2003-02-10 | 2004-02-10 | Autorização dinâmica dos media em rede móvel |
Country Status (10)
Country | Link |
---|---|
US (1) | US6888821B2 (pt) |
EP (2) | EP2048836B1 (pt) |
JP (1) | JP4261579B2 (pt) |
KR (1) | KR100742755B1 (pt) |
CN (1) | CN100454912C (pt) |
AT (2) | ATE483305T1 (pt) |
DE (2) | DE602004016980D1 (pt) |
PT (1) | PT2048836E (pt) |
RU (1) | RU2298290C2 (pt) |
WO (1) | WO2004071105A2 (pt) |
Families Citing this family (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7298697B2 (en) * | 2000-04-10 | 2007-11-20 | Nokia Corporation | Setting a communication channel |
US7260640B1 (en) * | 2003-02-13 | 2007-08-21 | Unisys Corproation | System and method for providing an enhanced enterprise streaming media server capacity and performance |
KR100651566B1 (ko) * | 2003-08-26 | 2006-11-28 | 삼성전자주식회사 | 이동통신 단말기에서 출력 버퍼링을 이용한 멀티미디어재생 장치 및 그 제어 방법 |
US7672317B2 (en) * | 2003-12-29 | 2010-03-02 | Nokia Corporation | Method, system, and devices for transmitting information between a user equipment and an IP packet gateway |
US8239547B2 (en) * | 2004-07-09 | 2012-08-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for providing different services in a multimedia communication system |
DE102005013905B4 (de) * | 2005-03-24 | 2007-01-25 | Siemens Ag | Ermittlung der Zuordnung von Datenströmen zu Nutzverbindungen durch Benachrichtigung bei detektierten Daten mindestens eines Datenstroms an einen Steuerungsknoten |
EP1715625A1 (en) * | 2005-04-22 | 2006-10-25 | Alcatel | Apparatuses for controlling service delivery using access-dependent information in a system comprising a core network subsystem |
US8798253B2 (en) * | 2005-07-29 | 2014-08-05 | Verizon Patent And Licensing Inc. | Network routing |
EP1758334A1 (en) * | 2005-08-26 | 2007-02-28 | Matsushita Electric Industrial Co., Ltd. | Establishment of media sessions with media adaptation |
ES2335676T3 (es) * | 2005-10-21 | 2010-03-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Manejo de la calidad de servicio en un sistema de comunicacion. |
EP1964426B1 (en) * | 2005-12-12 | 2010-07-28 | Telefonaktiebolaget LM Ericsson (publ) | Method and devices for specifying the quality of service in a transmission of data packets |
FI20051320A0 (fi) * | 2005-12-22 | 2005-12-22 | Nokia Corp | Menetelmä pakettivirtojen kohdentamiseksi siirtoteille viestintäjärjestelmässä |
FR2895613B1 (fr) * | 2005-12-26 | 2008-02-22 | Alcatel Sa | Dispositif d'optimisation d'utilisation de services dans des reseaux d'acces hybrides |
US7911943B2 (en) * | 2006-01-13 | 2011-03-22 | Nokia Corporation | Optimization of PDP context usage |
US8553851B2 (en) * | 2006-02-15 | 2013-10-08 | Nec Sphere Communications, Inc. | System and method for recording calls in an IP-based communications system |
CN101030962B (zh) * | 2006-02-28 | 2010-12-15 | 华为技术有限公司 | 通信系统用策略决定方法和策略决定系统 |
WO2007098691A1 (fr) * | 2006-02-28 | 2007-09-07 | Huawei Technologies Co. Ltd. | Procédé et système pour assurer la qualité de service dans des systèmes de communication |
US8719342B2 (en) * | 2006-04-25 | 2014-05-06 | Core Wireless Licensing, S.a.r.l. | Third-party session modification |
US20070253365A1 (en) * | 2006-04-27 | 2007-11-01 | Tomas Hedberg | Service-aware quality monitoring and control in a radio access network |
CN1996968B (zh) * | 2006-06-26 | 2010-04-14 | 华为技术有限公司 | 媒体网关控制器向媒体网关下发资源提供决策的方法 |
US20080101412A1 (en) * | 2006-10-30 | 2008-05-01 | Infineon Technologies Ag | Method and apparatus for generating a message in a communication system |
US8929360B2 (en) | 2006-12-07 | 2015-01-06 | Cisco Technology, Inc. | Systems, methods, media, and means for hiding network topology |
US8959239B2 (en) * | 2006-12-29 | 2015-02-17 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for reporting streaming media quality |
GB2447874B (en) * | 2007-03-30 | 2009-07-29 | Cambridge Semiconductor Ltd | Forward power converter controllers |
CN101483847B (zh) * | 2008-01-07 | 2012-10-03 | 华为技术有限公司 | 实现策略控制的方法、装置及系统 |
US8520663B2 (en) | 2008-02-26 | 2013-08-27 | At&T Intellectual Property I, L. P. | Systems and methods to select peered border elements for an IP multimedia session based on quality-of-service |
CN101547140A (zh) * | 2008-03-28 | 2009-09-30 | 华为技术有限公司 | 上报数据业务使用量的方法、系统、媒体处理及控制设备 |
CN102171983B (zh) * | 2008-10-02 | 2014-11-26 | 艾利森电话股份有限公司 | 用于控制通信网络中的会话的方法和装置 |
US9563781B2 (en) * | 2008-10-31 | 2017-02-07 | International Business Machines Corporation | Directional optimization for policy evaluation |
CN102292954B (zh) * | 2008-11-24 | 2015-09-23 | 瑞典爱立信有限公司 | 通过宽带网络提供电路交换呼叫和服务 |
US8085783B2 (en) * | 2009-06-10 | 2011-12-27 | Verizon Patent And Licensing Inc. | Priority service scheme |
US8886790B2 (en) * | 2009-08-19 | 2014-11-11 | Opanga Networks, Inc. | Systems and methods for optimizing channel resources by coordinating data transfers based on data type and traffic |
US9037555B2 (en) * | 2009-11-12 | 2015-05-19 | Bmc Software, Inc. | Asynchronous collection and correlation of trace and communications event data |
US20110145319A1 (en) * | 2009-12-15 | 2011-06-16 | Dolan Michael F | Group session management and admission control of multiple internet protocol flows |
US9241190B2 (en) | 2010-08-24 | 2016-01-19 | Cisco Technology, Inc. | Generating a response to video content request including dynamically processed video content |
KR20120083827A (ko) * | 2011-01-18 | 2012-07-26 | 삼성전자주식회사 | 홈 네트워크를 이용한 통화 방법 및 장치 |
US20140059182A1 (en) * | 2011-03-04 | 2014-02-27 | Fumio Miura | Synchronized content broadcast distribution system |
US9521439B1 (en) | 2011-10-04 | 2016-12-13 | Cisco Technology, Inc. | Systems and methods for correlating multiple TCP sessions for a video transfer |
US8755342B2 (en) | 2011-10-05 | 2014-06-17 | Cisco Technology, Inc. | System and method for dynamic bearer selection for immersive video collaboration in mobile wireless networks |
US8903955B2 (en) | 2011-12-02 | 2014-12-02 | Cisco Technology, Inc. | Systems and methods for intelligent video delivery and cache management |
CN104040991B (zh) * | 2012-01-13 | 2019-01-18 | 瑞典爱立信有限公司 | 用于为ip多媒体子系统补充服务配置和实现通知的方法和设备 |
US9565615B2 (en) * | 2012-05-16 | 2017-02-07 | Qualcomm Incorporated | Evolved hybrid internet protocol (IP) multimedia subsystem (IMS) architecture |
FR3011704A1 (fr) * | 2013-10-07 | 2015-04-10 | Orange | Procede de mise en œuvre d'une session de communication entre une pluralite de terminaux |
KR102202597B1 (ko) * | 2014-06-20 | 2021-01-13 | 삼성전자주식회사 | 이종망 기반 방송 서비스를 제공하는 방법 및 장치 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1376345A (zh) * | 1999-09-25 | 2002-10-23 | 摩托罗拉公司 | 分级式优先级循环(hprr)规划 |
WO2001028160A2 (en) * | 1999-10-14 | 2001-04-19 | Nortel Networks Limited | Establishing a communications session having a quality of service in a communications system |
US6621793B2 (en) * | 2000-05-22 | 2003-09-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Application influenced policy |
FI20001630A (fi) * | 2000-06-30 | 2001-12-31 | Nokia Mobile Phones Ltd | Palvelun laadun määritys datavirroille |
WO2002037869A2 (en) * | 2000-11-06 | 2002-05-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with ip bearer resources |
US7546376B2 (en) * | 2000-11-06 | 2009-06-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Media binding to coordinate quality of service requirements for media flows in a multimedia session with IP bearer resources |
US7106718B2 (en) * | 2001-02-09 | 2006-09-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Signaling quality of service class for use in multimedia communicatations |
US20020184510A1 (en) * | 2001-04-17 | 2002-12-05 | At&T Wireless Services, Inc. | Binding information for IP media flows |
US7609673B2 (en) * | 2002-02-08 | 2009-10-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Packet-based conversational service for a multimedia session in a mobile communications system |
-
2004
- 2004-01-30 US US10/766,845 patent/US6888821B2/en not_active Expired - Lifetime
- 2004-02-10 WO PCT/IB2004/000337 patent/WO2004071105A2/en active Application Filing
- 2004-02-10 EP EP08163110A patent/EP2048836B1/en not_active Expired - Lifetime
- 2004-02-10 EP EP04709662A patent/EP1611719B1/en not_active Expired - Lifetime
- 2004-02-10 RU RU2005128300/09A patent/RU2298290C2/ru not_active IP Right Cessation
- 2004-02-10 AT AT08163110T patent/ATE483305T1/de not_active IP Right Cessation
- 2004-02-10 DE DE602004016980T patent/DE602004016980D1/de not_active Expired - Lifetime
- 2004-02-10 CN CNB2004800036510A patent/CN100454912C/zh not_active Expired - Lifetime
- 2004-02-10 JP JP2006500319A patent/JP4261579B2/ja not_active Expired - Lifetime
- 2004-02-10 AT AT04709662T patent/ATE410868T1/de not_active IP Right Cessation
- 2004-02-10 PT PT08163110T patent/PT2048836E/pt unknown
- 2004-02-10 KR KR1020057014766A patent/KR100742755B1/ko active IP Right Grant
- 2004-02-10 DE DE602004029406T patent/DE602004029406D1/de not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
KR20050105208A (ko) | 2005-11-03 |
US20040190453A1 (en) | 2004-09-30 |
EP2048836A1 (en) | 2009-04-15 |
KR100742755B1 (ko) | 2007-07-27 |
EP1611719A2 (en) | 2006-01-04 |
RU2298290C2 (ru) | 2007-04-27 |
WO2004071105A3 (en) | 2005-06-02 |
DE602004016980D1 (de) | 2008-11-20 |
CN1748394A (zh) | 2006-03-15 |
ATE410868T1 (de) | 2008-10-15 |
EP1611719A4 (en) | 2007-10-24 |
DE602004029406D1 (de) | 2010-11-11 |
EP2048836B1 (en) | 2010-09-29 |
EP1611719B1 (en) | 2008-10-08 |
RU2005128300A (ru) | 2006-03-10 |
JP4261579B2 (ja) | 2009-04-30 |
US6888821B2 (en) | 2005-05-03 |
ATE483305T1 (de) | 2010-10-15 |
CN100454912C (zh) | 2009-01-21 |
JP2007527634A (ja) | 2007-09-27 |
WO2004071105A2 (en) | 2004-08-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
PT2048836E (pt) | Autorização dinâmica dos media em rede móvel | |
ES2674720T3 (es) | Servicios multimedia en un sistema de comunicación | |
EP1374494B1 (en) | Method and apparatus for establishing a protocol proxy for a mobile host terminal in a multimedia session | |
KR101234477B1 (ko) | 자동 서비스 품질 구성 | |
US7746819B2 (en) | Binding mechanism for quality of service management in a communication network | |
BRPI0621025A2 (pt) | mÉtodo para registrar um nà màvel de uma rede de telecomunicaÇÕes para um subsistema da rede, aparelho para uso no registro de um nà màvel de uma rede de telecomunicaÇÕes para um subsistema da rede, mÉtodo para uso atravÉs de um aparelho como parte de um mÉtodo para registrar um nà màvel de uma rede de telecomunicaÇÕes para um subsistema da rede, aparelho para uso em um mÉtodo para registrar um nà màvel de uma rede de telecomunicaÇÕes para um subsistema da rede, e, programa de operaÇço | |
US9578545B2 (en) | Controlling data sessions in a communication system | |
US7286475B2 (en) | GPRS system and in-zone node apparatus, and bearer setting method used therefor | |
EP1947801A1 (en) | A method of qos authorization | |
KR100879164B1 (ko) | 통신 네트워크에서 서비스 품질 관리를 위한 결합 메커니즘 | |
ES2349583T3 (es) | Autorización dinámica de medios en redes móviles. | |
KR20030096676A (ko) | 세션 정보 변경에 따른 종단간 서비스 품질 보장을 위한호 제어방법 | |
Larsen | Mobility schemes for future networks based on the IMS |