BRPI0609263A2

BRPI0609263A2 - decisão para a alocação e designação de recursos para no mìnimo um fluxo de dados e no mìnimo uma conexão útil

Info

Publication number: BRPI0609263A2
Application number: BRPI0609263-2A
Authority: BR
Inventors: Peter Braun; Friedrich Grosse-Rhode; Dorothea Lampe; Mirko Schramm
Original assignee: Nokia Siemens Networks Gmbh
Priority date: 2005-03-30
Filing date: 2006-03-09
Publication date: 2010-03-09
Also published as: RU2384001C2; EP1867111A1; DE102005014852A1; WO2006103153A1; RU2007139914A

Abstract

DECISãO PARA A ALOCAçãO E DESIGNAçãO DE RECURSOS PARA NO MìNIMO UM FLUXO DE DADOS E NO MìNIMO UMA CONEXãO úTIL. A presente invenção refere-se a um processo, um nó de controle e um sistema para a determinação da alocação de fluxos de dados para conexões úteis por meio de notificação de um nó de controle (PS) de uma rede de comunicação através de uma função de aplicação (AF) e através de um dispositivo terminal (UE). De acordo com a invenção, uma unidade de rede (GGSN) envia ao nó de controle (PS) no mínimo uma informação de filtro de pacote, recebida do dispositivo terminal (UE), referente à conexão útil a ser empregada para a transmissão de dados de no mínimo um fluxo de dados e no mínimo um atributo. Além disso, uma função de aplicação (AF) envia ao nó de controle (PS) no mínimo uma informação referente aos dados a serem enviados de no mínimo um fluxo de dados. O nó de controle (PS) compara entre si a, no mínimo uma, informação de filtro de pacote, o, no mínimo um, atributo e a, no mínimo uma informação da função de aplicação (AF) e decide se a conexão útil a ser empregada para PS dados a serem enviados de no mínimo um fluxo de dados pode ser autorizada, e, no caso de uma comparação positiva, o nó de controle (PS) autoriza PS dados de no mínimo um fluxo de dados para a conexão útil.

Description

Relatório Descritivo da Patente de Invenção para "DECISÃOPARA A ALOCAÇÃO E DESIGNAÇÃO DE RECURSOS PARA NO MÍNIMO UM FLUXO DE DADOS E NO MÍNIMO UMA CONEXÃO ÚTIL".

A presente invenção refere-se a um processo, a um nó de controle e a um sistema para a determinação da alocação de fluxos de dadospara conexões úteis por meio de notificação ao nó de controle de uma redede comunicação por meio de uma função de aplicação e da avaliação dasinformações disponíveis no nó de controle e da autorização subseqüente daconexão útil.

Na estandardização 3GPP, para a autorização, em função doserviço, de estabelecimento de conexões úteis IP através da rede de rádiomóvel orientada por pacotes, a assim chamada "General Packet Radio Service" (GPRS), acha-se estandardizada a assim chamada "Service BasedLocal Policy" (SBLP) na TS 23.207, bem como TS 29.207, TS 29.208 e TS29.209. As conexões úteis de GPRS são conexões ponto-a-ponto e tambémsão chamadas de contextos de "Packet Data Protocol" (PDP). O estabelecimento e a modificação de contextos PDP impulsionados pelo dispositivoterminal móvel, o assim chamado "User Equipment" (UE), são autorizadosno assim chamado "Gateway GPRS Support Node" (GGSN) através da assim chamada interface Go pela assim chamada "Policy Decision Function"(função de decisão sobre recursos) (PDF), a qual conhece PS serviços usados pelo dispositivo terminal naquele momento. A PDF é informada atravésdesses serviços a respeito de uma ou mais das assim chamadas "Applications Functions" (funções de aplicação (AF), que trocam com o dispositivoterminal mensagens de sinalização para a negociação dos serviços, como,por exemplo, o protocolo SIP, IETF RFC 3261, usado no assim chamado "IPMultimedia core network Subsystem" (IMS) da 3GPP. A autorização fixa aassim chamada "Quality of Services" (qualidade do serviço) (QoS) permitidapara o contexto PDP, ou seja a largura de faixa e o retardamento permitidodos pacotes por meio da assim chamada classe QoS.

A PDF sabe quais fluxos de dados IP pertencem a um serviço.Aqui, um fluxo de dados significa uma seqüência de pacotes de dados com omesmo endereço de remetente e destinatário, bem como com o mesmo tipode dados úteis daí transportados. No caso de transporte IP/UDP ou IP/TCP,o fluxo de dados IP deve ser caracterizado adicionalmente pelos mesmosnúmeros de porta UDP, respectivamente TCP, do remetente e do destinatário. É possível que um dispositivo terminal estabeleça e use ao mesmo tempo vários contextos PDP para o GGSN. Por isso, para a autorização de umcontexto PDP, a PDF tem que saber quais correntes de dados IP são aí res-pectivamente transportados.

A solução para SBLP até aqui estandardizada na TS 29.207,que permite que a PDF identifique quais fluxos de dados IP são transportados em um contexto PDP, utiliza o assim chamado "token de autorização".Esse token é gerado para uma sessão de serviço pela PDF, por solicitaçãoda função de aplicação e é sinalizado pela função de aplicação para o dispositivo terminal. O dispositivo terminal utiliza o token, bem como o assim chamado "Flow Identifier", ou seja, índices adicionais que indicam o fluxo dedados IP dentro de um serviço, para no estabelecimento e alteração de umcontexto PDP na sinalização correspondente indicar para quais fluxos dedados IP deve ser empregado o contexto PDP. Token de autorização e FlowIdentifier são chamados juntos de "Binding Info". O GGSN encaminha essainformação a partir da sinalização de contexto PDP para a PDF através dainterface Go.

No entanto, a utilização do token de autorização tem como conseqüência uma série de desvantagens. Nesse sentido, a sinalização entre afunção de aplicação e o dispositivo terminal tem que apoiar o transporte dotoken, o que atualmente é o caso apenas para a sinalização SIP. Além disso, a sinalização pertencente à conexão útil na rede de acesso também temque apoiar o transporte da Binding Info, fato este que realmente se aplicapara PS contextos PDP do GPRS, mas não para redes de acesso alternativas que sejam de interesse na 3GPP, como por exemplo WLAN ou DSL

Para o GPRS existe a limitação de que o primeiro contexto PDP estabelecido pelo dispositivo terminal não apoia nenhuma Binding Info, e por isso o dispositivo terminal, ao receber um token, tem que estabelecer outros con-textos PDP. Por isso, o primeiro contexto PDP estabelecido não pode sermonitorado através de SBLP.

No caso de GPRS, o estabelecimento ou a modificação de umcontexto PDP é impulsionado pelo dispositivo terminal por meio de sinalização estandardizada na TS 29.060. Nesse caso, o dispositivo terminal comunica ao GGSN, por meio de filtro de pacote no assim chamado "Traffic FlowTemplate" (TFT, codificação conforme a TS 24.008), como PS fluxos de dados IP recebidos da rede central IP devem ser distribuídos por contextosPDP com a finalidade de serem encaminhados ao dispositivo terminal.

O objetivo da invenção é propor uma possibilidade simples eeficiente para a determinação da alocação de dados de no mínimo um fluxode dados para uma conexão útil e para a disponibilização dos recursos.

Esse objetivo é alcançado de acordo com a invenção por meiodos objetos das reivindicações independentes. Formas de desenvolvimentoda invenção são apresentadas nas demais reivindicações.

Um núcleo da invenção consiste em que para a determinação daalocação de fluxos de dados para conexões úteis, notifica-se a um nó decontrole de uma rede de comunicação, através de uma função de aplicação,de uma unidade de rede, por exemplo um nó de apoio GPRS de gateway

(GGSN), uma unidade de rede de gateway de pacote etc, e através de umdispositivo terminal. De acordo com a invenção, a unidade de rede envia aonó de controle no mínimo uma informação de filtro de pacote, como por exemplo um filtro de pacote TFT, recebida pelo dispositivo terminal, referenteà conexão útil a ser empregada para a transmissão de dados de no mínimo um fluxo de dados juntamente com no mínimo um atributo. Além disso, umafunção de aplicação envia ao nó de controle no mínimo uma informação,como por exemplo uma informação de fluxo IP de mídias (Media IP flow info), referente aos dados a serem enviados no mínimo de um fluxo de dados.O nó de controle compara a, no mínimo uma, informação de filtro de pacotecom o, no mínimo um, atributo, e com a, no mínimo uma, informação da função de aplicação e decide se a conexão útil a ser empregada, como por exemplo um contexto PDP, pode ser autorizada para PS dados a serem envi-ados de no mínimo um fluxo de corrente. No caso de uma comparação positiva, o nó de controle autoriza PS dados de no mínimo um fluxo de dadospara a conexão útil e envia, por exemplo, no mínimo um gate para a instalação em uma unidade de rede e fixa a qualidade do serviço para PS dadosdo, no mínimo um, fluxo de dados. Evidentemente, de acordo com a invenção também é possível que o dispositivo terminal também envie diretamenteao nó de controle a, no mínimo uma, informação de filtro de pacote. Nessecaso, a unidade de rede enviaria separadamente ao nó de controle o, nomínimo um, atributo, como por exemplo o endereço PDP, a informação QoS, o MSISDN etc.

Portanto, com a invenção é possível identificar fluxos de dadosIP, respectivamente fluxos de dados, através de uma conexão com um nó decontrole, como por exemplo um servidor de recursos, com parâmetros, quepossam ser recebidos para uma conexão útil. Também é proposta uma solução que propõe uma nítida identificação de serviço e autorização de serviçocom base em informações mínimas do Transport-Layer. Além disso, com ainvenção é possível autorizar fluxos de dados "uplink", ou seja, fluxos de dados do dispositivo terminal para a rede central IP. De acordo com a invenção, o nó de controle recebe informações tais como, por exemplo, uma a|teração da largura de faixa, erros ou problemas de recursos em uma unidadede rede de Transport-Layer (por exemplo dispositivo terminal, GGSN etc).Essa informação pode ser usada, por exemplo, para que a função de aplicação seja informada sobre isso e para nova distribuição dos recursos. Dessemodo, o usuário de um dispositivo terminal pode utilizar um serviço com amáxima qualidade admissível do serviço.

A invenção se baseia no emprego de um nó de controle (servidor de recursos = policy server) com base em uma função de decisão derecursos (Policy Decision Function = PDF). Em um elemento de memória,como por exemplo um banco de dados, do nó de controle poderiam ser armazenadas regras de decisão de recursos para a alocação de um fluxo dedados a uma conexão útil, que sejam levados em conta no caso de um resultado de comparação positivo de acordo com a invenção ao ocorrer a alo-cação. Além disso, em um outro elemento de memória poderia ser armazenado o, no mínimo um, atributo e as, no mínimo uma, informações de filtrode pacote para o exemplo de um ulterior emprego. Um servidor de aplicação, respectivamente uma função de aplicação (por exemplo um servidor deserviço, uma P-CSCF (Proxy-Call-State-Control-Function), disponibiliza parao nó de controle informações tais como, por exemplo, informações de MediaIP-Flow, no caso de uma ativação de serviço por meio de um dispositivoterminal. Nesse caso, o dispositivo terminal tem que estabelecer uma conexão útil, como por exemplo um contexto PDP, para uma unidade de rede,como por exemplo um nó de suporte de gateway-GPRS (Gateway-GPRS-Support-Node GGSN), uma unidade de rede de Paket-Gateway etc, da redede comunicação. Durante a ativação de serviço, podem ser estabelecidasconexões úteis adicionais, que possuem, por exemplo, uma QoS diferente(qualidade do serviço = Quality of Service). Nesse caso, um dispositivo terminai pode ser um aparelho de rádio móvel, um computador móvel, um Organizer móvel, um computador etc. Como rede de comunicação pode serempregada uma rede de rádio móvel celular, uma rede de comunicação detransmissão de pacotes, uma rede IP, uma rede WLAN etc. Uma unidade derede da rede de comunicação controla e monitora o tráfego de dados IP entre o dispositivo terminal e um outro dispositivo terminal ou entre o dispositivo terminal e uma função de aplicação. Em uma rede GPRS emprega-secomo unidade de rede o nó de suporte de Gateway-GPRS. As conexõesúteis em uma rede GPRS são denominadas em geral de contextos PDP. Emgeral, uma conexão útil é considerada como um canal lógico com recursosindividuais.

Uma configuração vantajosa da invenção é a nova alocação dinâmica e reautorização de recursos no caso de uma modificação do serviçoativo ou da conexão útil, bem como no caso de novo estabelecimento deuma outra conexão útil. Nesse caso, podem ser integradas informações opcionais de Transport-Layer (por exemplo a prioridade do filtro de pacote IP, aqualidade do serviço etc). Desse modo é possível decidir dinamicamente se,por exemplo, um contexto PDP deve ser modificado ou se um novo contextoPDP deve ser estabelecido.

Uma vantagem da invenção consiste em que o esforço de implementação no caso dos elementos de rede individuais, tal como o dispositivo terminal, o nó de controle, a unidade de rede etc, pode ser mantido reduzido. Especialmente para o dispositivo terminal não é necessária nenhuma modificação do comportamento mesmo quando um determinado modode preencher o filtro de pacote TFT possa otimizar o mecanismo de aloca-ção.

A invenção será explicada detalhadamente a seguir com baseem um exemplo de execução mostrado em uma figura. Nesse caso, mostra-se:

Figura 1: o processo de acordo com a invenção, com base emuma arquitetura simplificada de rede;

Figura 2: uma tabela para a comparação de acordo com a invenção;

Figura 3: um exemplo para a reautorização;

Figura 4: duas tabelas para a reautorização de acordo com a invenção;

Figura 5: um dispositivo de acordo com a invenção.

A figura 1 mostra o processo de acordo com a invenção combase em uma arquitetura simplificada de rede.

Conceitos gerais:

Endereços IP de dispositivos terminais (UE IP address): endereços IP de dispositivos terminais destinatários na direção Downlink, ou seja,da rede central IP para o dispositivo terminal.

Endereços PDP: endereços IP (prefixo de endereços de 64 bit,em Ipv6), que alocam o GGSN ao contexto PDP e ao dispositivo terminalcorrespondente.

Conexão de função de aplicação, respectivamente conexão AF(AF session): estabelecimento por meio de um protocolo de sinalização denível de aplicação, que é oferecido pela função de aplicação e um estabelecimento de conexão condicionante (session set-up) com descrição explícitada conexão antes da utilização do serviço.

Informação de fluxo IP de mídias, respectivamente informaçãode fluxo de dados (Media IP flow): fluxo de dados de uma conexão de funçãode aplicação que é descrito por meio de um filtro de pacote.

Identificador de fluxo de dados (Flow Identifier): o identificadorde fluxo de dados com um componente de mídias, que é associado com aconexão de função de aplicação, é usado para a identificação da informaçãode fluxo IP de mídias. O meio que é descrito por meio dos componentes demídias pode ser bidirecional ou unidirecional. Por isso, um identificador defluxo de dados identifica um fluxo de dados (para um componente de mídiasunidirecional) ou dois fluxos de dados (para um componente de mídias bidirecional).

Para o exemplo de execução são feitas as duas suposições seguintes:

- supõe-se que um identificador inequívoco de dispositivo terminal (por exemplo um endereço IP de dispositivo terminal, um MSISDN etc.)encontra-se alocado a cada conexão AF e a cada contexto PDP.

- fluxos de dados "uplink" e "downlink" com o mesmo identificador de fluxo de dados estão alocados ao mesmo contexto PDP (por exempio, fluxos de dados "uplink" e "downlink" de RTP e/ou RTCP estão alocadosao mesmo contexto PDP).

De acordo com a invenção, atributos de contexto PDP, como porexemplo PS endereços PDP, PS filtros TFT, a informação QoS, o MSISDNetc, são comparados com as informações (informações de fluxo de dados)de uma função de aplicação AF. Nesse caso, busca-se uma coincidênciados atributos de contexto PDP, que são enviados pela unidade de redeGGSN ao nó de controle PS, com as informações que são enviadas pelafunção de aplicação AF para o nó de controle PS. O dispositivo terminal UE,com um filtro de pacote TFT em uma rede GPRS, fixa, segundo uma decisãointerna, qual serviço qual contexto PDP deve usar. De acordo com a invenção, PS filtros de pacote TFT não são usados para a alocação do fluxo dedados "downlink" a contextos PDP através da unidade de rede GGSN, se-não que eles são encaminhados aos nós de controle PS pela unidade derede GGSN. Nesse caso, são instaladas gates de recepção junto à unidadede rede GGSN para a alocação dos fluxos de dados. Segundo o SBLP jáestandardizado, o nó de controle instala PS assim chamados "gates" noGGSN para PS contextos PDP controlados pelo SBLP. Um "gate" contémum filtro de pacote, bem como informações para o GGSN sobre se ele deverejeitar ou encaminhar pacotes IP correspondentes, ou seja, sobre como PSdados devem ser processados. Quanto mais informações detalhadas estejam contidas nos filtros de pacote TFT, melhor pode ser efetuada uma autorização para as solicitações de QoS do serviço. A unidade de rede GGSNenvia ao nó de controle todos PS atributos de contexto PDP disponíveis,como, por exemplo, PS endereços PDP, PS filtros de pacote TFT, a informação QoS, o MSISDN no caso da autorização da solicitação de conexão útil -e a modificação da conexão útil. O nó de controle PS armazena esses atributos para cada contexto PDP em um elemento de memória do nó de controle PS. PS atributos PDP podem ser utilizados para a comparação de acordo com a invenção.

De acordo com a invenção, PS filtros de fluxo IP de mídias, queforam enviados pela função de aplicação AF ao nó de controle PS, e PS filtros de pacote TFT mais PS endereços PDP que foram enviados pela unidade de rede GGSN ao nó de controle PS, são comparados na busca por coincidências. Nesse caso, a comparação é feita em função da prioridade dosfiltros de pacote TFT. A partida é dada com o filtro de pacote TFT máximo apartir do valor. Um filtro de fluxo IP de mídias tem uma coincidência com umfiltro de pacote TFT de um contexto PDP, quando a direção for igual, o endereço PDP for igual ao endereço IP de destinatário de downlink do dispositivoterminal da informação de conexão AF, as IDs de protocolo forem iguais ouforem munidas de um suporte de ajuste, e as portas (porta de recepção dedispositivo terminal UE e/ou porta-fonte AF da função de aplicação) foremiguais ou forem munidas de um suporte de ajuste. No caso de uma faixa denúmero de portas em um filtro de pacote TFT, só é requerida uma sobreposição parcial.União de Fluxo IP de Mídias

Em duas situações é executada uma comparação de acordocom a invenção: a) no caso de uma ativação ou no caso de uma modificaçãode um contexto PDP (por exemplo, quando o nó de controle receber umasolicitação para autorização); b) no caso de um estabelecimento de conexãode uma conexão AF (por exemplo por meio do recebimento de novas informações de conexão que o nó de controle recebe da função de aplicação).

Na primeira situação, o nó de controle analisa PS atributos decontexto PDP (por exemplo endereço PDP, TFT, MSISDN, QoS) e identifica,em uma primeira etapa, as conexões de função de aplicação que correspondem ao endereço PDP de um modo tal que o parâmetro de identificador dedispositivo terminal que foi recebido pela função de aplicação seja igual aoidentificador de dispositivo terminal do contexto PDP. Em uma segunda etapa, PS fluxos de dados correspondentes dessa(s) conexão(ões) AF determinante(s) são verificados por meio do processo de acordo com a invenção.Cada fluxo de dados que tenha sido identificado no sentido de que ele podeser transportado através do contexto PDP (existe, portanto, possibilidadepara o transporte através do contexto PDP) será permitido, respectivamenteunido, para esse contexto PDP. PS gates correspondentes são instaladosem função da prioridade do correspondente filtro de pacote TFT na unidadede rede GGSN, e uma qualidade combinada do serviço (classe de tráfego dedados, taxa de dados etc.) será fixada e poderá ser autorizada. No caso emque o fluxo de dados úteis (Media IP Flow = fluxo IP de mídias) tenha sidounido a um outro contexto PDP, PS gates e a fração da qualidade do serviçono contexto PDP são eliminados de outro contexto PDP.

No caso do primeiro contexto PDP (aquele sem filtro de pacoteTFT), o nó de controle une cada fluxo de dados úteis das conexões AF determinantes a esse contexto PDP. Segundo, por exemplo, uma configuraçãode um provedor de rede, o nó de controle poderia estar autorizado a autorizar a qualidade do serviço para essa combinação do fluxo de dados úteis oua autorizar uma qualidade do serviço pré-configurada em geral pelo provedorde rede. A qualidade do serviço pré-configurada pelo provedor de rede pode-ria depender, por exemplo, da classe QoS, respectivamente da classe detráfego UMTS do contexto PDP.

Na segunda situação, o nó de controle PS analisa as informações de conexão AF e identifica, em uma primeira etapa, se a conexão AFcorresponde a um endereço PDP existente. Se for esse o caso, então o nóde controle PS compara PS fluxos de dados úteis da conexão AF com PSfiltros de pacote TFT armazenados dos contextos PDP existentes. Se acomparação for positiva, o fluxo de dados úteis será unido a esse contexto esua qualidade de serviço será considerada na fixação da qualidade autorizada do serviço para o contexto PDP. PS gates correspondentes serão instalados e a qualidade combinada do serviço será autorizada. A qualidade doserviço de um contexto PDP será então modificada somente quando o dispositivo terminal iniciar uma modificação do contexto PDP.

Um ponto essencial do processo de acordo com a invenção é abusca por uma comparação positiva entre um filtro de fluxo IP de mídias,enviado pela função de aplicação AF ao nó de controle PS, e um filtro depacote TFT mais endereço IP do dispositivo terminal, enviado pela unidadede rede GGSN ao nó de controle.

Nesse caso, existem as seguintes exigências para o emprego dofiltro de pacote TFT para o mecanismo de união:

- com o filtro de pacote TFT são identificados apenas filtros depacote IP de "downlink", de tal modo que uma unidade de rede é informadasobre como PS pacotes de dados que entram podem ser conduzidos por elapara dentro do contexto PDP correto. Até então, só é estandardizado o fatode que o dispositivo terminal envia o filtro de pacote TFT com PS filtros depacote "downlink". Desse modo, a conexão com um contexto PDP não funciona no caso de fluxos de dados úteis "uplink" unidirecionais. Como resultado disso, o nó de controle não pode saber qual contexto PDP é pensadopara PS fluxos de dados úteis "uplink" do dispositivo terminal UE. Como solução para isso, o nó de controle deve autorizar cada fluxo de dados úteis"uplink" unidirecionais da conexão AF que corresponda ao endereço PDP docontexto PDP.- No caso de que um fluxo de dados úteis "downlink" tenha recebido a mesma ID de fluxo que o fluxo de dados úteis "uplink", então PS dois fluxos de dados úteis são unidos ao mesmo contexto PDP. Por isso pode serempregado o contexto PDP que é pensado para o fluxo de dados úteis. Esteé derivado do filtro de pacote TFT do correspondente fluxo de dados úteis"downlink".

- PS filtros de pacote TFT dependem do dispositivo terminal e desua implementação. Nesse caso, o nó de controle só pode executar umacomparação com informações de conexão AF quando essas informaçõestambém estiverem presentes em um determinado tempo. Adicionalmente, ainformação de conexão AF enviada pela função de aplicação AF ao nó decontrole PS depende do tipo de AF, respectivamente do tipo da função deaplicação AF. Por isso, poderia ocorrer que não fosse encontrada nenhumacomparação positiva em uma conexão AF durante uma solicitação de autorização para um contexto PDP, ou que as informações de comparação nãofossem suficientes para determinar o contexto PDP "correto" para o fluxo dedados úteis. Se nenhuma conexão AF puder ser encontrada, então será autorizada uma qualidade geral (default) do serviço (classe de tráfego de dados e taxa de dados) para o contexto PDP. Além disso, Gates gerais podemser enviadas à unidade de rede GGSN ou a solicitação de autorização serárecusada. Esse procedimento poderia ser configurado, por exemplo, pelooperador de rede. Poderia ocorrer que um fluxo de dados úteis que já seacha alocado a um contexto PDP apresente uma comparação positiva comum filtro de pacote TFT de um outro (ulterior) contexto PDP. Nesse caso, épossível que o nó de controle "reautorize" PS recursos para o fluxo de dadosúteis.

- Poderia ser que não se encontre presente nenhuma informação TFT quando da solicitação para o estabelecimento de um segundo con-texto PDP, caso ela tenha sido anteriormente adicionada ao primeiro contexto PDP. Nesse caso, é autorizada uma QoS geral (classe de tráfego de dados e taxa de dados) para o contexto PDP. Além disso, Gates gerais podemser enviadas à unidade de rede GGSN ou a solicitação de autorização serárecusada. Esse procedimento poderia ser configurado, por exemplo, pelooperador de rede.

O processo de união básico de fluxo de dados úteis também poderia ser expandido por meio de: a) limitação dos fluxos de dados úteis unidos e de sua QoS autorizada; b) aperfeiçoamento da sinalização de contextoPDP. No caso do primeiro ponto, o nó de controle PS tenta limitar PS fluxosde dados úteis unidos para as conexões AF, que, em última instância, utilizam o contexto PDP. Isso ocorre já durante o estabelecimento do contextoPDP. Cada contexto PDP estabelecido ulteriormente terá um filtro de pacoteTFT com uma prioridade maior. Essa prioridade resulta da união do fluxo dedados úteis com o contexto PDP. Para que essa re-união e a sinalização aela correlacionada possam ser evitadas, PS esforços no nó de controle poderiam ser no sentido de que seja considerada adicionalmente a classe QoSsolicitada, respectivamente a classe de tráfego UMTS do contexto PDP durante o procedimento de união. Para cada corrente de dados úteis que apresente uma comparação positiva com um filtro de pacote TFT de um contextoPDP, será analisada em uma terceira etapa a classe QoS desse fluxo dedados úteis. Somente esses fluxos de dados úteis, que possuem uma classeQoS superior ou a mesma classe QoS que aquela que foi solicitada para ocontexto PDP, é que também serão, em última instância, unidos ao contextoPDP. Isso impede uma união de uma corrente de dados úteis com uma classe QoS mais baixa autorizável. Para um fluxo de dados úteis desse tipo poderia ser estabelecido um contexto PDP próprio. Pelo outro lado é permitidocada fluxo de dados úteis com uma classe QoS superior autorizável paraesse contexto PDP, pois existe a possibilidade de que a classe QoS solicitada do dispositivo terminal UE tenha sido rebaixada pela rede de comunicação. O segundo ponto visa o aperfeiçoamento da sinalização de contextoPDP em casos em que ocorrem dificuldades na autorização. O SBLP disponibiliza meios para a verificação de componentes de mídia que têm a permissão para serem alocados ao mesmo contexto PDP. O dispositivo terminalUE é informado através dessas limitações por meio de, por exemplo, umindicador de fluxo de reserva (single reservation flow indicator) (IETF RFC3524), de que componentes individuais de mídia não podem ser misturadoscom outros. Se for descoberta uma mistura desse tipo, a autorização serárecusada. Ao contrário, o nó de controle poderia se comportar no sentido deque a atual configuração dos contextos PDPe o filtro de pacote TFT não sejam considerados como sendo finais. Em vez da recusa da autorização, o nóde controle poderia tentar descobrir o maior grupo possível permitido de fluxos de dados úteis e autorizar PS mesmos. Em certas circunstâncias, esseprocedimento tem que ser repetido no caso de um estabelecimento ulteriorde um contexto PDP.

Por "reautorização" de recursos entende-se que um fluxo de dados úteis de uma conexão AF, que já tenha sido atribuído a um contextoPDP, será afastado desse contexto PDP atual (por exemplo, um PrimeiroContexto PDP (Primary PDP-Kontext) e será unido a um novo (ulterior) contexto PDP. Para cada contexto PDP que nessa etapa perde um fluxo de dados úteis, o nó de controle envia uma decisão de autorização de acordo comPS fluxos de dados úteis que ainda estejam unidos a esses recursos. O nóde controle fixa, portanto, a autorização para PS fluxos de dados remanescentes no contexto PDP. PS recursos alocados, a qualidade do serviço, serão modificados correspondentemente. Uma reautorização também deve serexecutada nos casos de modificação de um serviço ativo, pois isso afeta acomparação com PS atributos PDP modificados (por exemplo, são modificados atributos de serviço que têm que ser comparados com o filtro de pacoteTFT já existente). No caso de um serviço ativo, dados em pelo menos umfluxo de dados são transmitidos e são usados atualmente pelo dispositivoterminal, respectivamente o serviço é disponibilizado atualmente por umafunção de aplicação AF, por exemplo. As regras para a execução de umareautorização (por exemplo a remoção da união de um fluxo de dados úteisdo contexto PDP originalmente alocado) são configuráveis pelo provedor derede. Um fluxo de dados úteis, que já se acha alocado a um contexto PDP eque fornece um resultado positivo de comparação no caso de uma comparação com um filtro de pacote TFT de uma outra solicitação de autorização decontexto PDP, será sempre separado do contexto PDP anterior quando aprioridade do filtro de pacote TFT for maior.

A figura 2 mostra uma tabela para a comparação de acordo coma invenção. Nessa tabela são apresentados exemplos para resultados positivos de comparação e resultados negativos de comparação (o endereço IPdos dispositivos terminais é igual para todos PS filtros) no processo de acordo com a invenção. PS filtros dos primeiros três fluxos de dados úteis têmum resultado positivo de comparação com PS dois filtros de pacote TFT,pois a direção é igual (TFT é sempre "downlink"). Além disso, as IDs de protocolo são iguais ou são ocupadas por um suporte de ajuste, e cada endereço IP, cada porta e cada faixa de números de porta é igual, é ocupado porum suporte de ajuste ou são sobrepostos (para a faixa de números de porta). PS filtros dos três últimos fluxos de dados úteis possuem um resultadonegativo de comparação com PS dois filtros de pacote TFT, pois sempre háum atributo que é diferente em relação ao atributo do filtro de pacote TFTocupado por um suporte de ajuste.

A figura 3 mostra um exemplo para a reautorização. Não é levada em consideração uma segunda solicitação de autorização de contextoPDP com apenas um fluxo de dados "uplink" ou sem TFT, pois nesses casosa solicitação de autorização é rejeitada ou é autorizada com valores geraispara o contexto PDP. O dispositivo terminal UE ativa um segundo contextoPDP x com um fluxo de dados "downlink" (4) e PS fluxos de dados "uplink"(5)e (6), e um segundo contexto PDP y com PS fluxos de dados "downlink"(1)e (3) e com o fluxo de dados "uplink" (2). De acordo com a invenção, afunção de aplicação AF envia uma informação de conexão segundo a figura4 a) ao nó de controle PS. Essa informação de conexão deve ficar à disposição no caso da solicitação de autorização de contexto PDP. O endereço decontexto PDP e o filtro de pacote TFT para PS segundos contextos PDP segundo a figura 4 b) são enviados pela unidade de rede GGSN para a identificação do fluxo de dados úteis ao nó de controle PS.

A identificação de serviço é executada de acordo com a invenção do seguinte modo:Contexto PDP x:

No caso da solicitação de ativação de contexto PDP para o contexto PDP x, a unidade de rede GGSN envia o endereço IP dos dispositivosterminais e a parte TFT (-, UE-Port 3, AF-Port 1, AF-IP, X, Prec=1) ao nó decontrole PS. O nó de controle executa uma comparação com as informaçõesde conexão da função de aplicação AF com o endereço IP de destino = endereço PDP, para que ele (PS) possa identificar o fluxo de dados úteis cor-respondente. No caso das conexões a) - b), foi identificado apenas o fluxode dados 4 (não se acha presente nenhum outro resultado positivo de comparação). A autorização para a qualidade do serviço é executada para essefluxo de dados e para todos PS fluxos de dados "uplink" (não unidos) (6) e(5) dessa conexão a) - d), que não estão aos pares.Contexto PDP v:

No caso da solicitação de ativação de contexto PDP do contextoPDP y, a unidade de rede GGSN envia o endereço PDP UE-IP e a parte TFT((-, UE-Port1, AF-Port2, AF-IP, x, prec=2); (-, AF-IP, x, prec=3)) ao nó decontrole PS. O nó de controle PS compara as informações de conexão dafunção de aplicação AF com o endereço IP de destino = endereço PDP, paraque o correspondente fluxo de dados possa ser identificado. No caso da conexão a) - d), é identificado o fluxo de dados (1) com (-, UE-Port1, AF-Port2,AF-IP, x, prec=2). Já que o fluxo de dados "uplink" (2) se acha presente nosmesmos subcomponentes de mídia, então PS fluxos de dados (1) e (2) sãoautorizados para o contexto PDP y. O filtro de pacote TFT (-, AF-IP, x,prec=3) tem um resultado positivo de comparação com todos PS fluxos dedados "downlink" das conexões a) - d). No caso em que não seja permitidauma reautorização, o processo é executado do seguinte modo: já que PSfluxos de dados "uplink" (5) e (6) e o fluxo de dados "downlink" (4) já estãounidos ao contexto PDP, então só é autorizado o fluxo de dados (3) para ocontexto PDP y. No caso em que seja permitida uma reautorização, o processo é executado em função da prioridade do filtro de pacote TFT. Nessecaso, o fluxo de dados (4) não se encontra unido pelo contexto PDP x, pois aprioridade do filtro TFT correspondente tem o valor 1. O fluxo de dados (3)está autorizado para o contexto PDP y.

A figura 5 mostra um nó de controle PS de acordo com a invenção para a execução do processo segundo as figuras de 1 a 4. O nó de controle PS apresenta uma unidade de recepção E, uma unidade de emissão Se uma unidade de processamento V.

Claims

1. Processo para a determinação da alocação de fluxos de dados para conexões úteis por meio de notificação a um nó de controle (PS) deuma rede de comunicação por meio de uma função de aplicação (AF) e pormeio de um dispositivo terminal (UE), caracterizado pelo fato de que umaunidade de rede (GGSN) envia ao nó de controle (PS) no mínimo uma informação de filtro de pacote, recebida do dispositivo terminal (UE), referenteà conexão útil a ser empregada para a transmissão de dados de no mínimoum fluxo de dados e no mínimo um atributo, pelo fato de que uma função deaplicação (AF) envia ao nó de controle (PS) no mínimo uma informação referente aos dados a serem enviados de no mínimo um fluxo de dados, pelofato de que o nó de controle (PS) compara entre si a, no mínimo uma, informação de filtro de pacote, o, no mínimo um, atributo e a, no mínimo umainformação da função de aplicação (AF) e decide se a conexão útil a serempregada para PS dados a serem enviados de no mínimo um fluxo de dados pode ser autorizada, e pelo fato de que no caso de uma comparaçãopositiva o nó de controle (PS) autoriza PS dados de no mínimo um fluxo dedados para a conexão útil.

2. Processo de acordo com a reivindicação 1, caracterizado pelofato de que para a autorização, por meio do nó de controle (PS) pelo menosuma gate para a instalação é enviada a uma unidade de rede (GGSN) e éfixada a qualidade do serviço para PS dados do, no mínimo um, fluxo de dados.

3. Processo de acordo com a reivindicação 1, caracterizado pelofato de que a comparação das, no mínimo duas, informações e do, no mínimo um, atributo é executada no caso de uma ativação e/ou no caso de uma modificação da conexão útil.

4. Processo de acordo com a reivindicação 2, caracterizado pelofato de que como conexão útil se emprega um contexto PDP.

5. Processo de acordo com a reivindicação 4, caracterizado pelofato de que o nó de controle (PS) armazena em um elemento de memória o,no mínimo um, atributo e a, no mínimo uma, informação de filtro de pacote.

6. Processo de acordo com a reivindicação 4, caracterizado pelofato de que como atributo são empregados o endereço PDP, a informaçãoQoS e/ou a MSISDN.

7. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que como nó de controle (PS) se emprega umservidor de recursos.

8. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que como informação de filtro de pacote se emprega um filtro de pacote TFT.

9. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que a comparação das, no mínimo suas, informações e do, no mínimo um, atributo ocorre em função da prioridade da, nomínimo uma informação de filtro de pacote.

10. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que o nó de controle (PS) compara se é igual adireção em que PS dados de no mínimo um fluxo de dados devem ser transportados.

11. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que o nó de controle (PS) compara se o endereçoPDP corresponde ao endereço IP de destino downlink do dispositivo terminalda informação de conexão da função de aplicação (AF).

12. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que o nó de controle (PS) compara se PS números de identificação de protocolo são iguais ou se para isso são indicadossuportes de ajuste.

13. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que o nó de controle (PS) compara se PS endereços IP de fontes de função de aplicação e/ou as portas são iguais ou se paraisso são indicados suportes de ajuste.

14. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que para a qualidade do serviço são fixadas aclasse de tráfego, a largura de faixa e/ou a taxa de dados.

15. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que ao ocorrer uma ativação de uma outra conexão útil por meio do dispositivo terminal, o nó de controle (PS) compara a, nomínimo uma, informação de filtro de pacote com a, no mínimo uma, informação da função de aplicação (AF) e, com base no resultado da comparação,decide se devem ser enviados dados de no mínimo um fluxo de dados através da outra conexão útil.

16. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que ao ocorrer uma reautorização de dados de nomínimo um fluxo de dados, o, no mínimo um, fluxo de dados, com base emresultado positivo de comparação, é separado da atual conexão útil e é unido a uma nova conexão útil.

17. Processo de acordo com a reivindicação 16, caracterizadopelo fato de que para cada conexão útil, da qual tenha sido separado no mínimo um fluxo de dados devido a uma reautorização, o nó de controle (PS)fixa uma decisão de autorização para PS fluxos de dados que ainda estejamunidos com a conexão útil.

18. Processo de acordo com a reivindicação 17, caracterizadopelo fato de que é fixada a qualidade do serviço para PS fluxos de dadosque ainda estão unidos com a conexão útil.

19. Processo de acordo com a reivindicação 16, caracterizadopelo fato de que uma reautorização é executada ao ocorrer uma modificaçãode um serviço ativo.

20. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que como unidade de rede se emprega um nó desuporte GPRS de gateway (GGSN) e/ou uma unidade de rede de gatewayde pacote.

21. Processo de acordo com uma das reivindicações anteriores,caracterizado pelo fato de que a, no mínimo uma, informação de filtro de pacote é enviada pelo dispositivo terminal (UE) ao nó de controle (GGSN).

22. Nó de controle (PS) de uma rede de comunicação para adeterminação da alocação de fluxos de dados para conexões úteis por meiode notificação através de uma função de aplicação (AF), uma unidade derede (GGSN) e através de um dispositivo terminal (UE),- com uma unidade de recepção (E) e uma unidade de emissão(S) para a execução da comunicação,- com uma unidade de processamento (V) para a recepção deno mínimo uma informação de filtro de pacote, enviada pelo dispositivo terminal (UE) à unidade de rede (GGSN), referente à conexão útil a ser empregada para a transmissão de dados de no mínimo um fluxo de dados e de nomínimo um atributo da unidade de rede (GGSN), para a recepção de no mínimo uma informação referente aos dados a serem enviados de no mínimoum fluxo de dados pela função de aplicação (AF), para a comparação entresi das, no mínimo uma, informações de filtro de pacote, do, no mínimo um,atributo e da, no mínimo uma, informação pela função de aplicação (AF),para decidir se pode ser autorizada a conexão útil a ser empregada para PSdados a serem enviados de no mínimo um fluxo de dados, ao ocorrer umacomparação positiva para a autorização dos dados do, no mínimo um, fluxode dados para a conexão útil.

23. Sistema para a determinação da alocação de fluxos de dados para conexões úteis por meio de notificação de um nó de controle (PS)de uma rede de comunicação através de uma função de aplicação (AF), umaunidade de rede (GGSN) e através de um dispositivo terminal (UE),- com o dispositivo terminal (UE) para a emissão à unidade derede (GGSN) de no mínimo uma informação de filtro de pacote referente àconexão útil a ser empregada para a transmissão de dados de no mínimoum fluxo de dados,- com a unidade de rede (GGSN) para a emissão ao nó de controle (PS) da, no mínimo uma, informação de filtro de pacote recebida pelodispositivo terminal (UE), e de no mínimo um atributo,- com a função de aplicação (AF) para a emissão de no mínimouma informação referente aos dados a serem enviados de no mínimo umfluxo de dados,- com o nó de controle (PS) para a comparação entre si das, nomínimo uma, informações de filtro de pacote, do, no mínimo um, atributo, eda, no mínimo uma, informação da função de aplicação (AF), para decidir sea conexão útil a ser empregada para PS dados a serem enviados de no mínimo um fluxo de dados pode ser autorizada e, no caso de uma comparação positiva, para autorizar PS dados de no mínimo um fluxo de dados para aconexão útil.