PT1510090E - Método para controlar as partes das comunicações de grupos de dados em tempo real usando pacotes de recepção - Google Patents

Description

Descrição

MÉTODO PARA CONTROLAR AS PARTES DAS COMUNICAÇÕES DE GRUPOS DE DADOS EM TEMPO REAL USANDO PACOTES DE RECEPÇÃO

Campo da Invenção A invenção relaciona-se com sistemas de comunicações, e especialmente comunicação de informação em tempo real (duas partes ou múltiplas partes) em sistemas de comunicações.

Antecedentes da Invenção 0 tipo de chamada mais comum é uma chamada estabelecida entre duas partes para comunicação um a um. 0 modo padrão para definir uma chamada entre duas partes necessita de um plano de controlo explicito, assinalando que permite que as partes da chamada estabeleçam um canal onde a informação áudio pode ser transferida, e para gerir as capacidades de comunicação; por exemplo, o código áudio e a taxa de compressão relativa podem ser determinados nesta fase. De seguida, a comunicação por voz pode iniciar-se e a informação áudio pode ser transmitida pelas partes envolvidas na chamada. 0 Voz sobre Internet (Voice over Internet Protocol - VoIP) permite uma comunicação falada sobre uma ligação IP. 0 Protocolo de Iniciação de Sessão (SIP, RFC 2543) é convencionalmente usado para estabelecer uma chamada em sistemas de comunicações baseados em "VoIP".

Um sistema de comunicações móveis refere-se geralmente a qualquer sistema de telecomunicações o qual permita comunicação quando os utilizadores se estão a mover dentro da área de serviço do sistema. Um sistema de comunicações típico 1/30 é a Rede Pública de Telecomunicação Móvel (Public Land Mobile Network - PLMN) . A rede de comunicações móveis é, muitas vezes, uma rede de acesso que fornece a um utilizador um acesso sem fios a redes, anfitriões, ou serviços externos fornecidos por fornecedores de serviços específicos.

Byung-Won On et al. "A Reliable Multicast Protocol in Networks With Mobile Hosts", IEEE - ISBN 0-7695-0819-7, descreve um método para gerir e armazenar mensagens para um grupo de entidades, em elementos de rede baseados nos reconhecimentos de chegada de mensagem, a partir de anfitriões móveis alvo. O método procura evitar uma sobrecarga dos elementos de rede. Similarmente a Byung-Won On et al. acima referenciado, Byung-Won On et al. Ά Hierarchical Ack-Based Protocol for Reliable Multicast in Mobile Networks', IEEE - ISBN 0-7695-0777-8, relaciona-se com um método para evitar uma sobrecarga de elementos da rede em comunicações entre um grupo de entidades. 0 documento US 5809018 descreve um sistema de rádio que fornece um subscritor móvel com a possibilidade de seleccionar uma chamada de grupo, na qual o subscritor irá participar em todas as chamadas de grupo a serem feitas no local actual em que o subscritor se encontra, enquanto a estação do subscritor já se encontra a participar em outra chamada de grupo. Isto é conseguido ao enviar informação sobre outras chamadas de grupo a serem realizadas para uma estação subscritora, enquanto a estação subscritora está já a participar numa primeira chamada de grupo. Esta informação pode ser mostrada ao subscritor que pode mudar para a nova chamada de grupo caso assim o decida. A estação subscritora também transmite ao sistema de rádio um sinal que indica que a estação subscritora foi iniciada para participar numa certa chamada de grupo. O documento US 6181685 descreve uma solução para fornecer um controlo de potência reversa para comunicações de chamada de grupo em sistemas CDMA. A solução é baseada na utilização de um canal de ajuste de potência para a chamada de 2/30 grupo. A identificação de pelo menos um canal de ajustamento de potência é enviada para pelo menos algumas das unidades subscritoras no grupo. HONG Y. S. ET AL.: 'Distributed real-time simulation of the group manager executing the multicast protocol RFRM', PROCEEDINGS INTERNATIONAL SYMPOSIUM ON OBJECT-ORIENTED REAL-TIME DISTRIBUTED COMPUTING, 29 de Abril de 2002, páginas 173-176 apresenta um gestor de participação no grupo que executa o protocolo de múltiplas entidades RFRM (Release-time based Fault-tolerant Real-time Multicast), que é baseado na ideia de anexar o tempo de libertação oficial para cada mensagem enviada para o grupo. O gestor de participação no grupo mantém uma visão do grupo, isto é, a lista actual de membros activos no grupo e envia a nova visão de grupo para os seus membros sempre que ocorre uma alteração de visão. Na abordagem proposta, a aplicação do cliente não envia mensagens para o gestor de participantes do grupo. Usando o esquema proposto, é possível reduzir o atraso da terminação do evento de alteração de visão do grupo. RING S. :'Digital advanced wireless Services (DAWS)-the ETSI standardization of the next generation mobile platform for public safety, law enforcement and non-tactical military' EUROCOMM 2000, apresenta o futuro desenvolvimento e padronização de uma nova tecnologia de banda larga móvel, DAWS. A ideia básica é desenvolver um conjunto de padrões que apoiem a procura crescente para aplicações móveis profissionais que necessitam de altas taxas de transferência. Os requisitos para DAWS são discutidos relativamente a serviços e aplicações a serem aqui fornecidos. O documento WO 02 01780 A2 apresenta um método para receber um sistema de comunicação por rádio, onde o fardo de processamento da ligação descendente é partilhado entre um grupo de estações locais. Em vez de cada estação móvel respectiva descodificar e desmodular independentemente a ligação descendente da 3/30 estação base, a tarefa de descodificação é distribuída entre um grupo de estações móveis. 0 documento US-A-5 375 068 descreve um método e aparelho de teleconferência vídeo para estações de trabalho computorizadas, ligadas por uma rede de informação digital que inclui uma porção fonte de transmissão para uma estação de trabalho local para enviar informação de teleconf erência áudio e vídeo ao longo da rede, para uma ou mais estações de trabalho, e, um receptor para a estação de trabalho local para receber informação de teleconferência áudio e vídeo das estações de trabalho remotas. Um processo escravo na estação de trabalho remota emite uma mensagem de reconhecimento de frame para cada frame de informação de vídeo recebida com sucesso a partir da estação de trabalho local na estação de trabalho remota.

Os sistemas de rádio móvel ou rádios móveis privados profissionais (PMR) são sistemas rádio dedicados desenvolvidos primariamente para utilizadores profissionais e governamentais, tal como a polícia, forças militares, fábricas de petróleo, etc. Os serviços PMR são oferecidos através de redes PMR dedicadas construídas com tecnologias PMR dedicadas. Este mercado está dividido entre várias tecnologias -analógica, digital, convencional e truncada - nenhuma tem um papel dominante. O TETRA (Terrestrial Trunked Radio) é um padrão definido pela ETSI (European Telecommunications Standards Institute) para sistemas PMR digitais.

Uma característica especial fornecida pelos sistemas PMR é a comunicação em grupo. O termo "grupo", como aqui usado, refere-se a qualquer grupo lógico de três ou mais utilizadores que querem participar na mesma comunicação de grupo, por exemplo, uma chamada. A comunicação de grupo com uma característica de carregar-para-falar é uma das características essenciais de qualquer rede PMR. Geralmente, 4/30 com uma numa comunicação em grupo através de voz, característica "carregar-para-falar, libertar-para-ouvir", uma chamada de grupo é baseada no uso de um botão (PTT, interruptor carregar-para-falar) num telefone como um interruptor: ao pressionar um PTT, o utilizador indica o seu desejo de falar, e o equipamento do utilizador envia um pedido de serviço à rede. A rede rejeita o pedido ou aloca os recursos do pedido com base em critérios predeterminados, tais como a disponibilidade de recursos, prioridade do utilizador requerente, etc. Ao mesmo tempo, é estabelecida uma ligação a todos os outros utilizadores activos no grupo subscritor especifico. Após ter sido estabelecida a ligação por voz, o utilizador requerente pode falar, e os outros utilizadores podem ouvir no canal. Quando o utilizador liberta o PTT, o equipamento do utilizador sinaliza uma mensagem de libertação à rede, e os recursos são libertos. Assim, os recursos são apenas reservados para actual transacção de discurso ou item de discurso, em vez de reservar os recursos para uma "chamada". Uma vantagem interessante da comunicação carregar-para-falar, ou mais em geral, comunicação item-de-discurso-por-item-de-discurso, é um curto período de definição de chamada, o qual também torna tal comunicação de discurso atractiva para vários outros tipos de utilizadores. 0 documento de Patente U.S. 6,141,347 descreve um sistema de comunicações sem fios, o qual usa endereçamento multi-partes e processamento descentralizado em chamadas de grupo.

Um problema com tal comunicação item-a-item é ser necessária uma disciplina rigorosa ou protocolo pelas partes envolvidas na comunicação do discurso, ou outro tipo de comunicação de informação em tempo real. Adicionalmente, especialmente em comunicação em grupo, é difícil saber quais são as partes da comunicação em cada momento específico, e assim a comunicação deve incluir questões faladas e reconhecimentos. 5/30

Sumário da Invenção

Um objecto da invenção é fornecer uma nova forma de controlar as partes numa comunicação item-a-item em tempo real.

Este objecto da invenção é conseguido através de métodos, sistemas e terminais como definido nas reivindicações independentes em anexo. Várias realizações da invenção são definidas nas reivindicações dependentes em anexo.

Na presente invenção, cada terminal de utilizador receptor reconhece a recepção de um item de informação em tempo real ao enviar o reconhecimento do item de informação em tempo real após o final do mesmo. Numa realização da invenção, o relatório de recepção pode ser enviado após uma recepção bem sucedida do item de informação em tempo real, a recepção não sucedida do item de informação em tempo real ou em ambos os casos, dependendo da implementação e/ou da selecção do utilizador. Numa realização da invenção, o relatório pode também conter informação relativamente à qualidade da ligação. Numa realização da invenção, o terminal receptor envia um relatório de recepção apenas em resposta a um pedido especifico enviado pelo terminal de utilizador emissor a partir do qual o item de informação em tempo real originou, e não é enviado relatório de outro modo. Esta realização permite que sejam evitados relatórios desnecessários se a parte que envia não tem interesse neles. Em outra realização da invenção, o relatório é enviado por defeito. Numa realização da invenção, cada relatório de recepção é enviado através de um sistema de comunicação para o terminal de utilizador que envia, a partir do qual o item de informação em tempo real originado. Nesta realização, não é necessária funcionalidade extra na infra-estrutura do sistema de comunicação para a presente invenção. Noutra realização da invenção, a infra-estrutura do 6/30 sistema de comunicação recolhe relatórios de recepção a partir de uma pluralidade de terminais de utilizadores receptores e envia um relatório de recepção combinado para o terminal de utilizador emissor a partir do qual o item de tempo real originou. Esta realização necessita de funcionalidade extra na infra-estrutura do sistema de comunicação para a invenção mas, por outro lado, necessita de menos capacidade de transmissão. Quando o terminal de utilizador emissor recebe o(s) relatório (s) após o item de informação em tempo real terminar, pode mostrar informação que indica a um utilizador emissor quais o (s) terminal(ais) ou utilizador(es) receberam o item de informação em tempo real anterior. Assim, a presente invenção alivia o problema de conhecer quem actualmente recebe a informação transmitida em tempo real. Com a presente invenção, o utilizador emissor sabe automaticamente quem recebeu o item de informação em tempo real anterior. Consequentemente, já não é necessário que os utilizadores forneçam eles próprios esta informação, como é o caso dos sistemas da técnica anterior.

Numa realização da invenção, é empregue a incorporação (isto é, implícito) de sinalização num tráfico de informação em tempo real para transferir um pedido para um relatório de recepção e/ou o(s) relatório(s) de reconhecimento. A sinalização incorporada torna desnecessário reservar outro portador para a sinalização de controlo, a qual economiza recursos de rede e permite conseguir um curto período de sinalização. Noutra realização, o(s) relatório(s) de reconhecimento é(são) transferido(s) usando sinalização de saída, tal como sinalização STP.

Em algumas realizações da invenção, é empregue comunicação de discurso em modo de pacotes, tal como pacotes Protocolo Internet (IP) ou comunicações em discurso VoIP. 7/30

Numa realização da invenção, a sinalização incorporada compreende enviar um pacote inicial a partir de um terminal de utilizador emissor para, pelo menos, um terminal de utilizador receptor. 0 pacote inicial inicia o item de informação em tempo real. Numa realização da invenção, o pacote inicial é empregue para solicitar ao(s) terminal(ais) de utilizador receptor(es) envie(m) um relatório de recepção quando o item de informação de tempo real respectivo termina. Após o pacote inicial, são enviados os pacotes áudio que podem não conter sinalização mas que podem conter apenas parte do item de informação em tempo real. Um pacote final é a última parte do item de informação em tempo real e pode ser usado pelo(s) terminal(ais) de utilizador receptor(es) para detectar o final do item de informação em tempo real.

Breve Descrição dos Desenhos

No seguinte, a invenção irá ser descrita com maior detalhe através das realizações preferidas e com referência aos desenhos em anexo, nos quais:

As Figuras 1 e 2 mostram diagramas em bloco, que ilustram exemplos de um sistema de comunicação, onde a presente invenção pode ser aplicada; A Figura 3 é um diagrama em bloco simplificado, que ilustra um exemplo de um terminal de utilizador, onde a presente invenção pode ser aplicada; A Figura 4 é um diagrama de fluxo, que ilustra um exemplo da operação de um terminal de utilizador, a partir do qual é originado um item de discurso; A Figura 5 é um diagrama de fluxo, que ilustra um exemplo da operação de um terminal de utilizador, o qual recebe um item de discurso; 8/30

As Figuras 6 e 7 são tabelas de mensagens que ilustram dois exemplos da transferência de um pacote inicial, pacotes áudio, pacote final e relatórios de recepção através de um sistema de comunicação; A Figura 8 mostra um exemplo de um menu de activação de relatório de recepção que pode ser mostrado ao utilizador, A Figura 9 mostra um exemplo de um relatório de recepção mostrado ao utilizador; A Figura 10 mostra um exemplo de um pacote RTP encapsulado em UDP e pacotes IP, A Figura 11 mostra um exemplo de um pacote inicial RTP que contém um pedido de relatório de recepção; A Figura 12 mostra um exemplo de um pacote RTP que contém um relatório de recepção.

Realizações Preferidas da Invenção A presente invenção é aplicável a qualquer sistema de comunicações que permita comunicação de informação em tempo real entre utilizadores finais na base de item por item. A informação em tempo real pode incluir áudio em tempo real (por exemplo, discurso), video em tempo real, ou qualquer outra informação em tempo real, ou combinação dos mesmos, isto é, multimédia em tempo real. A presente invenção é especialmente aplicável a qualquer sistema de comunicações que permita comunicação de informação em tempo real em modo de pacote, tal como comunicação por pacotes IP entre utilizadores finais. Assim, a comunicação de informação em tempo real pode ser feita entre os terminais do utilizador final, por exemplo, através da Internet. A presente invenção oferece uma melhoria significativa para comunicações de discurso em modo pacote. Em algumas realizações 9/30 da invenção, o método de comunicação por voz IP utilizada é o Voz sobre IP (VoIP) , mas a invenção não é limitada a este método em particular.

Um campo de aplicação da invenção reside em sistemas de comunicações por rádio em pacotes móveis. No seguinte, as realizações da invenção irão ser descritas através de um serviço de rádio de pacotes tipo GPRS e o sistema UMTS ou GSM, sem limitar a invenção a estes sistemas de comunicação. A Figura 1 ilustra um exemplo em que um serviço de comunicação de discurso em modo pacote é realizado numa rede baseada num servidor (CN) com controlo diferente e entidades lógicas de plano de utilizador, que serve os subscritores ligados à mesma. Este conceito e arquitectura são ilustrados com mais pormenor nos pedidos de patentes U.S. 09/835,867 e 09/903,871. As transmissões dos subscritores são proxied e enviadas por estas entidades CN, as quais não permitem transmissões directas de ponta-a-ponta entre os subscritores. Deverá ser notado que os servidores de processamento de chamadas (CPS) e funções do plano do utilizador (Bridge) podem também ser encontrados na rede de comunicação de acesso, fornecendo uma camada de protocolo de topo para a rede de acesso. O sistema de comunicação 12 pode ser uma rede de acesso rádio móvel (RAN), a qual fornece o serviço de informação de pacotes IP, o qual pode ser baseado numa arquitectura GPRS que usa uma tecnologia de acesso de rádio de segunda geração (2G) ou terceira geração (3G) . Similarmente, qualquer sistema de comunicação que suporte uma comunicação por voz em modo de pacotes pode ser empregue em vez da rede móvel acima descrita. Deverá ser notado que o tipo da camada de rede subjacente (isto é, "a rede de acesso") não é essencial para a invenção básica. Algumas realizações da invenção podem ser realizadas nos 10/30 terminais do utilizador final sem qualquer funcionalidade de apoio no lado da rede.

Na Figura 1, uma camada de comunicação por voz em modo pacote 13 (ou uma rede central CN) é fornecida no topo de uma rede móvel, de modo a fornecer serviços de comunicação aos terminais do utilizador através do sistema de comunicação, por exemplo, rede móvel. Esta camada pode ser chamada de camada Push-To-Talk Over Cellular (PoC). Conceptualmente, a camada de comunicação por voz em modo pacote 13 pode compreender um par de entidades lógicas básicas, uma ponte 10 e um servidor de processamento de chamada (CPS) 11. A ponte 10 e o servidor CPS 11 correm aplicações de comunicação por voz em modo pacote, as quais comunicam com a(s) aplicação (ões) de comunicação por voz em modo pacote nos terminais de utilizador sobre as ligações IP fornecidas pelo sistema de comunicação IP. Esta comunicação inclui os pacotes de sinalização e pacotes de comunicação de voz (grupo ou um-a-um). O CPS 11 pode ser responsável pela gestão do plano de controlo das comunicações por voz em modo pacote. A sua importante função pode necessitar de várias funcionalidades, gerindo a actividade do utilizador e criação e eliminação de conexões lógicas do plano do utilizador com um protocolo de controlo apropriado, tal como o Protocolo de Inicio de Sessão (Session Initiation Protocol) SIP, e gestão dos perfis do utilizador (direitos de chamada, participação activa no grupo, definições de pesquisa, etc.); SIP Proxy/Location Server - fornece o local do utilizador e funcionalidades de encaminhamento da sinalização SIP; SIP Registrar - para registo e autenticação do utilizador; e Media Gateway Controller - controla as entidades da rede (pontes PoC) envolvidas na distribuição de informação de camada IP, de acordo com a informação especifica de utilizador e do grupo (membro, direitos, definições de 11/30 pesquisa, etc.) . Contudo, como aqui usado, o termo comum CPS refere-se a todas as funcionalidades possíveis do CPS.

Referindo a uma realização adicional mostrada na Figura 2, uma vez que os requisitos de gestão PMR podem ser divididos em requisitos específicos para grupo ou utilizador, podem existir dois tipos de CPS. As sessões SIP para comunicações por grupo são geridas por um Group Control Plane Function (G-CPF) 23 (por exemplo, num servidor) . Quando um utilizador se liga a um grupo, o G-CPF 23 gere a transacção do convite SIP relativo e executa o mapeamento das definições entre o receptor do utilizador e as entidades da rede responsáveis pela distribuição relativa de tráfego. A User - Control Plane Function (U-CPF) 22 (por exemplo, um servidor proxy do plano de controlo) é basicamente a interface do plano de controlo entre a rede IP e o utilizador (na Figura 2, é fornecida U-CPF22 ao MSI e a U-CPF27 é fornecida ao MS2). Por esta entidade de rede, os utilizadores iniciam sessão no sistema e negociam as suas definições operacionais (definições de pesquisa, grupo seleccionado, etc.) Gere o perfil do utilizador e gere as suas chamadas um-a-um. Deverá ser notado que isto é apenas uma separação lógica, e os dois tipos de CPS podem estar situados no mesmo computador. Ao separar G-CPF e U-CPF permite que os utilizadores participem em grupos PoC geridos por G-CPF em diferentes intranets ou em redes móveis de diferentes operadores e domínios IP. A divisão também traz escala ao permitir, na prática, um número infinito de grupos ou utilizadores no sistema. Uma Subscriber and Group Management Function (SGMF) 25 pode ser fornecida para gerir a informação do subscritor e grupo. Os utilizadores finais ou outros utilizadores podem ligar-se ao SGMF 25 ao usar qualquer método de comunicação. Numa realização da invenção, a interface de controlo é baseada na WWW e acessível ao usar um navegador de internet normal. 12/30

Fazendo novamente referência à Figura 1, a ponte 10 é responsável pela distribuição em tempo real dos pacotes VoIP para os terminais dos utilizadores de acordo com o seu grupo, as suas definições de pesquisa, e eventuais casos de preempção ou de emergência. Cada ponte reencaminha tráfego apenas entre ligações válidas programadas pelo CPS. Aponte 10 pode executar uma ou mais das seguintes funcionalidades.

Verificação de entrada: para identificar e autenticar a fonte do tráfego (opcionalmente, a mnemónica no pacote RTP líder, a qual irá ser discutida em baixo, precisa ser aqui processada) . A verificação de entrada pode também incluir acções para realizar e apoiar procedimentos de segurança.

Filtragem de entrada: para conseguir que apenas um participante fale de cada vez num grupo (isto é, concede um item de discurso) , e opcionalmente dar prioridade a itens de voz com maior prioridade.

Multiplicação: após o processo de filtragem, a ponte 10 tem de verificar os membros activos do grupo para o qual o tráfego está destinado, e gerar, a partir do pacote a chegar, um pacote de "ligação descendente" para cada membro activo.

Filtragem de pesquisa: para seleccionar de entre múltiplos fluxos de tráfego de entrada destinados ao mesmo utilizador, o qual tem de ser encaminhado para o seu receptor de acordo com as definições de pesquisa do utilizador.

De novo, uma vez que a multiplicação e filtragem de entrada são processos específicos do grupo, enquanto a verificação de entrada e filtragem de pesquisa são específicos do utilizador, a ponte pode compreender duas partes lógicas, como ilustrado na Figura 2. 13/30

Em primeiro lugar, uma Group - User Plane Function (G-UPF) G-UPF 21 (por exemplo, num servidor) é uma entidade de rede para a qual os pacotes áudio dos membros do grupo são enviados (através da sua U-UPF) e onde a filtragem de entrada e processos de multiplicação são executados. Para cada novo grupo, a G-CPF 23 atribui uma única G-UPF 21 de acordo com os critérios de equilíbrio de carga, os quais distribuem o tráfego entre as G-UPF o mais equilibrado possível. A User - User Plane Function (U-UPF) U-UPF20 (por exemplo, num servidor) desempenha a verificação de entrada e processos de pesquisa para os subscritores individuais que lhe são designados pela U-CPF 22 (Na Figura 2, a U-UPF 20 é fornecida ao MSI e a U-UPF 26 é fornecida ao MS2). Para efeitos de segurança, a U-UPF 20 pode ter associações de segurança para cada terminal móvel gerido. O U-UPF 20 esconde a complexidade da rede dos terminais móveis, de modo que o utilizador apenas precisa de enviar todo o seu tráfego de plano do utilizador para esta unidade que mais tarde o reencaminha, de acordo com as definições de mapeamento da U-CPF 22 adequada. Deste modo, não há necessidade de estabelecer canais seguros entre cada utilizador e todas as entidades da rede IP, as quais apenas têm de confiar na U-UPF 20, da qual recebem pacotes.

Para os elementos do Plano de Controlo, esta divisão lógica não precisa necessariamente de uma separação física entre as implementações G-UPF e U-UPF, e assim podem estar situados no mesmo computador.

As U-CPF 22 e 27, as quais são responsáveis por gerir as sessões dos utilizadores, podem necessitar de sinalização específica do plano de controlo. As especificações ETSI 3GPP (European Telecommunications Standards Institute, 3rd Generation Partnership Project) incluem comunicações por voz baseadas em 14/30 IP numa chamada "rede toda IP". Uma dita "rede toda IP" permite também comunicações por voz numa rede IP (voz sobre IP, VoIP) . Para VoIP, é especificada a sinalização de controlo de chamada, tal como o Protocolo de Iniciação de Sessão (SIP), o qual é definido no RFC 2543.

Contudo, algum outro protocolo de sessão IP pode ser usado em substituição. Por exemplo, Megaco (definido no RFC 3015) pode ser usado pelas U-CPF 22 e 27 para controlar as U-UPF 20 e 26 envolvidas na distribuição de tráfego da camada IP. Contudo, alguns outros protocolos correspondentes para controlar a troca dos elementos do plano do utilizador podem ser usados em substituição. Adicionalmente, o RTP (Protocolo de Transporte em Tempo real, definido em RFC1889) pode ser escolhido para gerir a transferência na realização preferida, e podem ser usados mecanismos QoS para gerir a entrega do pacote por voz (VoIP) . O Protocolo de Transporte em Tempo real (RTP), desenvolvido pelo IETF para apoiar o transporte de fluxos em tempo real para comunicações áudio sobre redes de pacotes, pode ser usado sobre o UDP, de modo a evitar os atrasos introduzidos por protocolos de transporte mais fiáveis (não solicitado neste contexto) , tal como o TCP. Com o RTP e a latência da memória intermédia no terminal receptor, pode ser gerido o tempo (problema de instabilidade), ordenação de pacotes, sincronização de múltiplos fluxos, eliminação de pacotes duplos e continuidade de fluxos. O protocolo SIP define a sinalização de mensagens para controlo de chamadas, localização e registo de utilizador, e estes podem ser usados para gerir comunicações de voz especificas e os utilizadores participantes relacionados (estabelecimento, participação e desmontagem de sessão de chamada, registo do 15/30 utilizador nos serviços, negociação do perfil de utilizador, etc) .

Para cada comunicação, a sessão SIP é estabelecida e gerida pelo CPS que a está a gerir (G-CPF 23 e U-CPF 22/27 para comunicações de grupo e um-a-um, respectivamente). Quando um utilizador se quer tornar num membro activo de um grupo, ele deverá entrar na sessão correspondente. Para chamadas um-a-um, as U-CPF PoC mantêm uma sessão entre as U-CPF participantes para cada chamada um-a-um.

Todo o tráfego de saída e entrada passa pela U-UPF 20/26 que foi designada ao utilizador. Em particular, na ligação ascendente, o tráfego do utilizador é verificado pela sua U-UPF 20/26 e reencaminhado para a G-UPF 21 que gere o grupo para o qual o tráfego é destinado ou, no caso de comunicação um-a-um, para a U-UPF 20/26 que gere tal parte.

Na ligação descendente, o tráfego é então distribuído para as U-UPF 20/26 dos utilizadores de destino (através de multiplicação de pacotes na G-UPF 21 no caso de comunicação de grupo, os pacotes são multiplicados e encaminhados para cada U-UPF, as quais servem os membros activos do grupo). Na U-UPF, os processos de pesquisa dos utilizadores são executados e o tráfego é multiplicado e encaminhado para cada utilizador que ouve o grupo, de acordo com as suas definições de pesquisa actuais.

Esta abordagem PoC é independente do acesso, o que significa que pode correr sobre GSM, WCDMA, WLAN ou tecnologias equivalentes desde que estas sejam capazes de suportar os portadores VoIP sempre ligados. A distribuição de áudio da camada IP usa mecanismos padrão VoIP (tal como o RTP) , enquanto protocolos de internet ou interfaces específicos serão usados 16/30 para ligar entidades de rede suplementares, tais como Subscriber and Group Management Function (SGMF) 25, um Domain Name Server (DNS) 24, WWW/WAP (World Wide Web/Wireless Application Protocol) e servidores de gestão de segurança. Cada entidade de rede é obviamente associada a pelo menos um endereço IP através do qual os pacotes IP são transferidos e encaminhados, mas o papel dos elementos de rede também precisa ser definido do ponto de vista do SIP. Cada MS é um Agente de Utilizador (UA) do SIP, e assim cada um tem um endereço SIP (URL), o qual normalmente é "username@hostname", em que o hostname pode ser, mas não necessariamente, associado com a U-CPF 22/27, na qual é necessário o registo dos MS. Esta U-CPF 22/27 pode funcionar como um servidor SIP Registrar, Location and Proxy, de modo a permitir que os MS sob o seu controlo sejam atingidos e para apoiar o encaminhamento de sinalização SIP. As G-UPF 21 e U-UPF 20/26, as quais são exclusivamente envolvidas na distribuição de informação áudio, não têm um papel nos mecanismos SIP actuais e a rede principal é simplesmente vista como um atalho de rede IP única. Ao nível de sinalização SIP, os URL são usados para identificação do utilizador e grupo. Os URL podem ser sip: os URL, como definido no RFC 2543, tel: os URL que representam números telefónicos, como definido no RFC 2806, ou quaisquer outros formatos URL. O método REGISTER é usado com um sip: o URL, isto é, SIP URL é a identidade principal do utilizar no sistema PoC. As chamadas de utilizadores para um número de plano de numeração privado (apenas) é possível usando o tel: URL no To: cabeçalho (sip: o URL deve conter sempre a indicação do anfitrião). Uma identidade secundária pode ser usada para, por exemplo, endereçar a b-party para chamadas um-a-um se esta for da mesma Rede Privada Virtual (VPN) . Os grupos podem ser endereçados com sip: os URL, onde o nome do grupo é usado em vez do nome do utilizador, e o anfitrião que gere o grupo (G-CPF exacto, se possível) na indicação do anfitrião. 17/30 0 equipamento do utilizador, ou estações móveis MS, podem ter uma aplicação de comunicação por voz em modo de pacote numa camada de utilizador no topo do pacote do protocolo padrão usado no sistema de comunicações móveis especifico. Os protocolos SIP e RTP empregam os protocolos TCP, UDP e IP adjacentes, os quais empregam os recursos de camada fisica, tais como os recursos rádio. Poderá ser assumido que pelo menos nos terminais dos utilizadores, o IPv6 é implementado, enquanto em algumas entidades de rede básica poderá ser necessário para suportar também o IPv4 (pacote duplo IPv6/v4) de modo a assegurar a interoperabilidade com eventuais sub-redes ainda a usá-lo. 0 MS, quando é seleccionado pelo utilizador o modo de comunicação por voz em modo pacote, define dois contextos GPRS: a) um a ser usado para a sinalização do plano de controlo (SIP/UDP/IP), b) um para fluxos áudio em tempo real (RTP/UDP/IP) com classe de qualidade IP de conversação ou semelhante, e compressão de cabeçalho suficiente sobre o trajecto rádio. 0 pacote de protocolo RTP/UDP/IP é usado comummente no mundo VoIP para transmissão de informação áudio em tempo real, e é assim também seleccionado para um plano de utilizador na realização preferida da invenção. Se um telemóvel ou rede móvel não suporta contextos simultâneos, o telemóvel pode desimpedir a ligação RTP duração a transacção de sinalização SIP. 0 MS deve sempre manter os contextos para a ponte 10 quando o modo de comunicação por voz em modo pacote está ligado. De preferência, o contexto SIP encontra-se também sempre ligado, mas se isto causa problemas à capacidade da rede, o contexto SIP pode ser definido também para a duração das transacções de sinalização. Neste caso, a rede celular poderá suportar o contexto iniciado pela rede definida. As sessões SIP são sinalizadas ao ligar ou aquando da activação do modo de comunicação por voz em modo pacote. As sessões SIP estão sempre ligadas e assim não é necessária sinalização para os itens de voz em modo pacote. Toda 18/30 a voz é transmitida após activação PTT ou qualquer outra activação manual ou por voz (tal como a detecção de actividade de voz, VAD) através dos contextos existentes.

Como exemplo de uma possível implementação de uma estação MS móvel é ilustrado num simples diagrama em bloco mostrado na Figura 3. Uma parte RF 301 representa qualquer radiofrequência e hardware requeridos por uma interface aérea empregue. A implementação actual de uma parte RF 301 não é relevante para a presente invenção. Um processamento de sinal banda de base 302 representa qualquer processamento de sinal base de banda necessário em qualquer implementação específica, tal com uma conversão analógica-digital (A/D) do sinal de discurso analógico do microfone 303, codificação-vo, construção de pacote IP, construção de moldura, desmolduração, desconstrução de pacote IP, descodificação-vo, conversão digital-analógica (D/A) do sinal do discurso digital recebido em sinal analógico aplicado a um altifalante 304. A parte RF 301 e o processamento de sinal base de banda são controlados por um controlador 305. O controlador 305 controla a sinalização, outband (SIP) e incorporado, assim como a construção e desconstrução de pacote IP. O início e paragem dos itens de discurso são definidos pelo interruptor PTT 306, o qual pode ser substituído por qualquer dispositivo operado pelo utilizador, por exemplo, um detector de actividade por voz (VAD) . Tais mecanismos alternativos para iniciar e terminar um item de discurso em vez do PTT são óbvios para os especialistas da técnica. Uma interface de utilizador pode incluir um visor 307 e um teclado 308 . Deverá ser apreciado que os blocos ilustrados na Figura 3 são blocos funcionais, os quais podem ser implementados numa variedade de configurações de circuitos diferentes. Por exemplo, o processamento de base de banda e o controlador podem ser implementados numa única unidade programável (por exemplo, um CPU ou processador de sinal) ou numa pluralidade de unidades. O funcionamento, de 19/30 acordo com a presente invenção, é primariamente relacionado com a parte do controlador do MS, e a invenção básica pode ser implementada como modificações de programa no programa de controlo do MS, por exemplo. Deverá ser notado que a presente invenção não pretende ser restrita às estações móveis e sistemas móveis, mas o terminal pode ser qualquer terminal com uma capacidade de comunicação de discurso. Por exemplo, o terminal de utilizador pode ser um terminal (tal como um computador pessoal) com acesso à Internet e uma capacidade VoIP para comunicação por voz na Internet.

Contudo, o funcionamento da presente invenção é ilustrado com ligação com a arquitectura PoC acima descrita, sem restringir a invenção para este sistema específico. Quando uma parte que realiza uma chamada tem uma ligação lógica, o actual trajecto de comunicação, incluindo os recursos de canal nos extremos de envio e recepção, precisa ser aberto e os recursos devem apenas ser reservados para a duração do item de chamada. A sinalização de estabelecimento de chamada, autenticação, acordo sobre as chaves de encriptação e negociação sobre parâmetros de serviços, não são necessários na fase de reserva de recursos porque as ligações lógicas já existem, mas os recursos físicos são reservados e abertos ao usar os procedimentos de sinalização. Assim, podem ser conseguidos curtos tempos de estabelecimento de ligação curta. Numa realização que use comunicação baseada em VoIP, o conceito inventivo significa que a sinalização incorporada nos pacotes de Protocolo de Transporte em Tempo Real (Real-time Transport Protocol - RTP) será suficiente sem a sinalização SIP demorada. São definidos pacotes RTP específicos com tipos de carga relacionados. Nestes pacotes de objectivos-especiais, o conteúdo de cargas úteis e/ou valores no campo "tipo de carga útil" no cabeçalho RTP é usado como sinalização incorporada. Mais geralmente, o mesmo tipo de sinalização incorporada pode também ser aplicado a 20/30 outro tipo de pacotes de voz em tempo real no IP ou outro ambiente protocolo.

Um exemplo da operação de envio de um terminal de utilizador emissor (quem inicia a chamada), por exemplo MS, é ilustrado na Figura 4. 0 utilizador pressiona o botão PTT 306, o qual é detectado pelo controlador 305 (passo 401). O controlador 305 sinaliza um pedido de item de discurso para a RAN móvel, perguntando a um portador rádio dedicado sobre a duração da totalidade do item de discurso. A RAN móvel cede ao portador da ligação ascendente (por exemplo, um canal de dados de pacote dedicado e um intervalo de tempo fisico). Quando a RAN móvel reconhece a alocação do portador da ligação ascendente, o telemóvel começa a enviar dados através da mesma. Em primeiro lugar, o controlador verifica a partir de uma memória interna, se um modo de relatório áudio está definido no terminal de utilizador (passo 402). Exemplos de como o utilizador pode definir o modo de relatório áudio, são descritos em baixo. O primeiro pacote a ser enviado é uma mensagem RTP que contém o identificador mnemónico da parte falante. Se o modo de relatório áudio for definido, o pacote inicial também contém um pedido de relatório áudio (passo 403) . Exemplos de um pacote inicial com pedido de relatório áudio são descritos em baixo. Se o modo de relatório áudio não estiver definido, o pacote inicial é enviado sem conter um pedido de relatório áudio (passo 404). O pacote inicial é seguido por pacotes de fluxo de voz (pacotes áudio, tais como pacotes VoIP) até que o botão PTT seja libertado (passos 405 e 406) . Quando o controlador 305 detecta que o PTT 306 é libertado, o controlador 305 envia um pacote final (passo 407) e o portador da ligação ascendente de voz é libertado. Assim, nesta realização, o item de discurso é dividido em três partes: um pacote RTP líder, pacote(s) RTP áudio e um pacote RTP final. O pacote inicial contém sinalização incorporada para a chamada. O pacote áudio pode não ter 21/30 sinalização mas apenas partes do discurso. 0 pacote final é a última parte do item de discurso e contém alguma sinalização incorporada. Numa realização da invenção, não é enviado nenhum pacote final mas a parte para quem se liga detecta o final do item de discurso de outro modo. 0 controlador verifica se o modo de relatório áudio está definido (passo 408). Caso contrário, o processo termina. Se o modo de relatório áudio estiver definido, o controlador 305 espera pelo (s) relatório (s) áudio e guarda o(s) relatório(s) áudio recebidos (passo 409). Um exemplo de um relatório áudio é descrito em baixo. O controlador 305 mostra o(s) relatório(s) ou informação vinda dele(s) no visor (passo 410). A informação mostrada contém normalmente pelo menos informação que indica a identidade do(s) destinatário(s) do item de discurso. Assim, o utilizador pode visualizar quais os membros de grupo que receberam o (s) item(s) de discurso anterior(es). O pacote RTP lider e os pacotes VoIP são encaminhados para a U-UPF do utilizador, com base no contexto GPRS activo. A U-UPF da parte que inicia a chamada envia pacotes para a U-UPF da parte que recebe a chamada. O portador da ligação descendente na interface rádio da rede móvel é atribuído pelo SGSN quando detecta um pacote IP que se move através de um contexto existente para uma estação móvel MS. Em primeiro lugar, o SGSN pagina o MS se se encontrar no estado de STANDBY. Após receber um comprovativo do MS, o SGSN solicita que a RAN (por exemplo, o GSM BSS) atribua um portador rádio dedicado, e após a atribuição, o SGSN começa a enviar pacotes (por exemplo, em estruturas LLC) para a RAN. A RAN envia os pacotes (por exemplo, em blocos de rádio) para o MS.

De igual modo, o pacote RTP líder e o pacote VoIP seguinte pode ser enviado através de qualquer sistema de comunicação entre a parte ou partes que iniciam a chamada e a parte ou partes que 22/30 recebem a chamada, como ilustrado nas Figuras 6 e 7. Deverá ser apreciado que em algumas realizações da invenção, a rede de trânsito não faz parte da funcionalidade inventiva. 0(s) sistema(s) de comunicação intermédia apenas fornece(m) um canal de comunicação entre os utilizadores finais.

Um exemplo da operação de um terminal de utilizador receptor (a parte que recebe uma chamada), por exemplo MS, é ilustrado na Figura 5. 0 controlador 305 observa que um pacote inicial é recebido (passo 501) . O controlador 305 verifica se o pacote inicial recebido contém um pedido de relatório áudio (passo 502) . Se o pedido não estiver presente, o controlador 305 procede com a recepção do próximo pacote (isto é, pacote VoIP) . Contudo, se o pedido de relatório áudio estiver presente, o controlador define o modo de relatório áudio. No modo de relatório áudio, o controlador processa os pacotes áudio recebidos para que contenha a informação necessária para criar o relatório áudio, como necessário. De seguida, o controlador 305 recebe e processa os pacotes áudio até um pacote final ser recebido ou o final do item de discurso seja de outro modo detectado, por exemplo, ao não receber um novo pacote da mesma parte que inicia a chamada (passos 504, 505 e 506) . Após detectar o final do item de discurso, o controlador 305 verifica se o modo de relatório áudio está definido (passo 507). Caso contrário, o processo termina. Se o modo de relatório áudio estiver definido, o controlador cria o relatório de áudio, como requerido, e envia o relatório para a parte que inicia a chamada (passo 508). 0 relatório pode ser enviado como sinalização incorporada no plano do utilizador, por exemplo, num pacote semelhante ao pacote inicial, ou como sinalização de saída no plano de controlo, por exemplo, sinalização SIP.

Em algumas realizações da invenção, os relatórios áudio são encaminhados através do sistema de comunicação para a parte que 23/30 inicia a chamada, sem qualquer processamento por parte do sistema de comunicação 12, como ilustrado na Figura 6. Isto permite que a presente invenção seja apenas implementada apenas nos terminais do utilizador, e assim não são necessárias nenhumas funções de infra-estruturas especiais para esta invenção. A desvantagem é a capacidade de transmissão extra necessária para a direcção ascendente e direcção descendente.

Em algumas outras realizações da invenção, o sistema de comunicação 12 intercepta relatórios de processamento de áudio relacionados com a chamada de grupo das partes que recebem a chamada e envia apenas um relatório combinado para a parte que inicia a chamada, como ilustrado na Figura 7. Estas realizações necessitam de menos capacidade de transmissão mas, por outro lado, necessitam de uma funcionalidade especial na infra-estrutura. A entidade que recolhe os relatórios pode ser a ponte 10 ou a U-UPF da parte que inicia a chamada, se a sinalização incorporada for empregue para os relatórios. Se a sinalização de saída, tal como SIP, for empregue, a entidade que recolhe os relatórios pode ser o servidor de processamento de chamadas 11 ou a U-CPF da parte que inicia a chamada.

Numa realização da invenção, o utilizador pode definir o terminal de utilizador num modo de relatório áudio a partir da interface do utilizador, por exemplo, ao usar um botão ou menu específico. Por exemplo, um menu de activação de relatórios áudio mostrado na Figura 8 pode ser mostrado ao utilizador. O utilizador pode seleccionar entre diferentes opções de relatório, os quais afectam os conteúdos do pedido de relatórios, os conteúdos do relatório áudio, e/ou a informação mostrada ao utilizador. No exemplo mostrado na Figura 8, as opções seleccionáveis para o conteúdo do relatório áudio incluem: 24/30 - Indicar o veredicto de recepção, por exemplo, OK/FAILED. Isto fornece informação ON/OFF (dois estados) relativamente ao sucesso da recepção - Indicar o número total de pacotes recebidos. Esta informação representa a qualidade da comunicação, fornecendo um tipo de valor QoS para a ligação ponta-a-ponta - Indicar o número de pacotes inválidos. Esta informação também representa a qualidade da comunicação, fornecendo um tipo de valor QoS para a ligação ponta-a-ponta - Enviar relatório após uma recepção bem sucedida. Por exemplo, um relatório é enviado após a recepção de um pacote final. Deverá ser notado que a recepção bem sucedida poderá conter pacotes inválidos. - Enviar relatório após falha de recepção. A recepção pode ser determinada como mal sucedida se o número de pacotes inválidos exceder um limite ou um pacote final não estiver presente, por exemplo. 0 terminal envia sempre um pedido para um relatório áudio quando o modo de relatório está activo. Numa realização da invenção, o modo de relatório áudio está activo até o utilizador o desactivar. Numa outra realização, o modo está inactivo por defeito, e o modo deverá ser activado após ligar o terminal, por exemplo.

Exemplos de relatórios de recepção são ilustrados na Figura 9. No canto superior esquerdo existe um pedido de relatório de recepção similar ao mostrado na Figura 8. Todas as opções de reconhecimento foram seleccionadas. 0 utilizador emissor pressiona o PTT para iniciar o item de discurso e um pedido de reconhecimento respectivo é transmitido aos recipientes como acima descrito. 0 utilizador emissor termina o item de discurso e os receptores transmitem os relatórios de recepção acima descritos. Com base nos relatórios de recepção, a estação móvel 25/30 do utilizador emissor cria e mostra ao utilizador um relatório de recepção, o qual pode ter um formato mostrado na parte mais à direita da Figura 9. 0 relatório pode incluir o nome do relatório, por exemplo "Relatório de recepção", o nome do grupo, por exemplo "Equipa de Design", e vários campos relacionados com os membros do grupo destinatário, tal como o campo "Membro", campo "Estado", e campo "Qualidade". 0 campo "Membro" indica os nomes dos destinatários do grupo. 0 campo "Estado" contém um indicador que indica se a recepção do item de discurso anterior foi bem sucedida (o indicador +) ou mal sucedido (o indicador -) para o destinatário especifico, enquanto um campo de estado vazio indica que não foi recebido qualquer relatório. 0 campo "Qualidade" fornece um valor que representa a qualidade da ligação ponta-a-ponta, por exemplo, o número de pacotes inválidos/número total de pacotes *100. Na Figura 9, o relatório 1 indica que todos os membros do grupo receberem com sucesso o primeiro item de discurso. O relatório 2 indica que o próximo item de discurso foi recebido pelo John, Adam e Eve, mas não foi recebido nenhum relatório da Mary e Matt. O relatório 3 indica que o terceiro item de discurso foi recebido com sucesso por todos os destinatários, com excepção do Matt. A Figura 10 ilustra um exemplo de um pacote RTP 100 encapsulado na carga útil de um pacote UDP 110. O pacote UDP 11 é ainda encapsulado na carga útil IP do pacote IP 120. Esta abordagem está conforme o pacote de protocolo RTP/UDP/IP usado frequentemente no mundo VoIP para transmissões de dados áudio em tempo real. O pacote RTP 100 inclui o cabeçalho 101 e a carga útil RTP 102. O cabeçalho RTP 101 está basicamente conforme o RFC 1889. O cabeçalho RTP 101 inclui os seguintes campos e parâmetros, V, P, X, CC, M, PT, número de sequência, marca temporal, identificador de fonte de sincronização (SSRC), identificadores de fonte contribuidora (CSC), etc. Numa 26/30 realização da presente invenção, o campo PT com um valor 105 que indica que a carqa útil RTP 102 contém sinais de controlo incorporados para o PoC. A Figura 11 ilustra um exemplo de um pacote inicial RTP que contém um pedido de relatório de recepção de acordo com a presente invenção. Em primeiro lugar, o valor do campo PT é 105, o que indica que a carga útil RTP contém sinais de controlo incorporados. O sinal de controlo inclui um campo de identificador de sinal, um campo de comprimento de sinal, e um campo sinal. No exemplo, o valor do campo do identificador de sinal é 126, o que indica que o sinal é um pedido de relatório de recepção. O campo de comprimento de sinal indica que o comprimento do sinal é um byte. O sinal ARR (Acknowledgement Report Request) consiste em parâmetros A, V, P, I, S, F, e r. O parâmetro de um bit A indica a versão do pedido de relatório de recepção, por exemplo, o valor 00 = versão 1. Os campos de um bit V, P, I, A e F corresponde às opções seleccionáveis no menu de pedido de relatório áudio mostrado na Figura 8. Quando o valor do parâmetro é 0, a opção respectiva é desactivada (OFF) , e quando o valor é 1, a respectiva opção está activa (ON) . O parâmetro r é reservado para um futuro uso e tem um valor por defeito de 0 . O MS emissor estabelece os valores dos parâmetros de acordo com a selecção do utilizador no menu de pedido de relatório áudio, e transmite o pacote inicial com o ARR no inicio de cada item de discurso, por exemplo. Após receber o pacote inicial com o ARR, o MS receptor configura o modo de reconhecimento, de acordo com os valores dos parâmetros recebidos. A Figura 12 ilustra um exemplo de um pacote de relatório de recepção enviado como um sinal de controlo incorporado na carga útil RTP. Novamente, o valor do campo PT é 105, que indica que a carga útil RTP contém sinais de controlo incorporados. O valor 27/30 do campo identificador de sinal é 127, que indica que o sinal é um relatório de recepção AR. 0 comprimento do sinal tem um valor 1-5, dependendo de quantas opções de relatório de recepção estão activas. 0 campo de relatório de recepção AR contém os parâmetros A, V, P, I, r, RP, e IP. 0 campo de dois bits A indica a versão do relatório de recepção, por exemplo, o valor 00 indica a versão 1.0. O parâmetro de um bit V indica o veredicto da recepção, por exemplo, 0 = mal sucedido, 1 = OK. O campo de um bit P indica se o relatório dos pacotes recebidos está incluído (V = 1) ou não (V = 0) . O campo de um bit V indica se o relatório dos pacotes recebidos está incluído (V = 1) ou não (V = 0). O campo de 16 bits RP contém o número total de pacotes recebidos, sendo capaz de indicar 0 ... 65535 pacotes de discursos. O campo de 16 bits IP indica o número total de pacotes inválidos, sendo capaz de indicar 0 ... 65535 pacotes de discursos. Os campos de um bit r são reservados para um uso futuro e têm um valor por defeito 0. O MS receptor envia o pacote RTP para o MS emissor após cada item de discurso. O MS emissor analisa os conteúdos do(s) relatório(s) de reconhecimento e cria e mostra um relatório de um tipo mostrado na Figura 9, por exemplo.

Com base na descrição acima, as realizações para outro tipo de itens de dados em tempo real será óbvio para um especialista na técnica. Por exemplo, um item de vídeo em tempo real pode ser transportado com um Protocolo de Transporte em Tempo Real (RTP) de modo similar como descrito para o áudio em tempo real (discurso) acima. Adicionalmente, itens multimédia em tempo real que contêm, por exemplo, áudio e vídeo em tempo real, podem ser transportados usando os princípios acima descritos.

Numa realização da invenção, o relatório é feito usando apresentações gráficas, tais como símbolos que representam os receptores. A recepção bem sucedida/mal sucedida do item de 28/30 dados em tempo real pode ser indicada por cor, tipo e/ou forma do símbolo, por exemplo. Numa outra realização, a recepção bem sucedida/mal sucedida é indicada por um alarme audível ou um anúncio oral, tal como "Matt não confirmou" ou "Todos confirmaram". A descrição apenas ilustra algumas realizações da invenção. Contudo, a invenção não é limitada a estes exemplos, mas poderá variar dentro do âmbito das reivindicações em anexo.

Lisboa, 11 de Outubro de 2010 29/30

Claims (34)

1. Reivindicações 1. Um método, que compreende enviar pacotes de dados de um item de dados em tempo real (403; 404; 406) de um primeiro terminal de utilizador de uma parte emissora (MSI) para um segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) num sistema de comunicação, caracterizado pelo facto de que, o primeiro terminal de utilizador da parte emissora (MSI) está configurado para enviar, em associação com o envio do item de dados em tempo real, ao segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) um pedido para enviar um relatório de aviso de recepção de item (403) ; enviar, em reposta ao pedido, um relatório de aviso de recepção de item (508) do segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) para o primeiro terminal de utilizador da parte emissora (MSI) no sistema de comunicação após o final do item de dados em tempo real.
2. 2. O método da reivindicação 1, caracterizado pelo facto de que o método compreende ainda enviar um pedido para um item de dados em tempo real a partir do primeiro terminal de utilizador da parte emissora (MSI) para o sistema de comunicação, o pedido para o item de dados em tempo real que inclui o dito pedido para enviar o relatório de aviso de recepção de item (403). 1/16 3. 0 método da reivindicação 2, caracterizado pelo facto de que o relatório de aviso de recepção de item é enviado como sinalização incorporada. 4. 0 método de qualquer uma das reivindicações 1 a 3, caracterizado pelo facto de que o envio do item de dados em tempo real inclui enviar os pacotes de dados que contêm informação de dados em tempo real (406).
3. 5. O método da reivindicação 4, caracterizado pelo facto de que o envio do item de dados em tempo real inclui enviar pacotes de transporte de dados em tempo real (406). 6. 0 método da reivindicação 6, caracterizado pelo facto de que a sinalização incorporada inclui pacotes de transporte em tempo real com tipos de carga útil específicos.
4. 7. O método da reivindicação 5, caracterizado pelo facto de compreender enviar um pacote inicial a partir do primeiro terminal de utilizador da parte emissora (MSI) para o segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) no sistema de comunicação de modo a iniciar o envio do item de dados em tempo real, o pacote inicial contém o pedido para enviar o relatório de recepção (403), o terminal da parte emissora (MSI) que envia pacotes de dados contendo informação de dados em tempo real (406), o segundo terminal de utilizador de pelo menos uma parte 2/16 receptora (MS2; MS3) que detecta o final do item de dados em tempo real (505), o segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3), responsável por receber o pedido no pacote inicial e detectar do final do item de dados em tempo real, enviando o relatório de aviso de recepção de item para o primeiro terminal de utilizador da parte emissora (508) .
5. 8. O método da reivindicação 7, caracterizado pelo facto da detecção incluir a recepção do pacote final (504). 9. 0 método da reivindicação 1, caracterizado pelo facto de compreender processamento e combinação dos relatórios de recepção do item recebidos do segundo terminal de utilizador de pelo menos duas partes receptoras (MS2; MS3) num elemento de rede no sistema de comunicação, enviar um relatório de aviso de recepção de item combinado a partir do elemento de rede para o primeiro terminal de utilizador da parte emissora (MSI).
6. 10. O método da reivindicação 1 ou 7, caracterizado pelo facto de compreender mostrar num visor no primeiro terminal de utilizador da parte emissora (MSI) a informação do item de dados em tempo real fornecida com base no relatório ou relatórios de recepção do item recebido (410). 3/16 11. 0 método da reivindicação 10, caracterizado pelo facto da visualização (410) compreende mostrar pelo menos informação identificativa relativa ao primeiro terminal de utilizador de pelo menos uma parte receptora, a qual enviou o relatório de aviso de recepção de item para o item de dados em tempo real.
7. 12. O método da reivindicação 1, caracterizado pelo facto de que os dados em tempo real incluem um ou mais dos seguintes: discursos, áudio em tempo real, video em tempo real ou multimédia em tempo real.
8. 13. Um método para utilizar num primeiro terminal de utilizador de uma parte emissora (MSI) que compreende: enviar pacotes de dados de um item em tempo real (403; 404; 406) para um segundo terminal de utilizador de pelo menos um terminal receptor (MS2; MS3) num sistema de comunicação; caracterizado pelo facto de, enviar, em associação com o envio de pacotes de dados em tempo real do item de dados em tempo real, para o segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) um pedido para enviar um relatório de recepção de envio (403) ; receber, em resposta ao pedido, um relatório de aviso de recepção de item originado a partir do segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) após terminar o item de dados em tempo real (409) . 4/16 14. 0 método da reivindicação 13, caracterizado pelo facto do dito relatório de aviso de recepção de item ser um relatório de aviso de recepção de item combinado derivado por um elemento de rede de um sistema de comunicação dos relatórios de recepção do item, recebidos pelos segundos terminais do utilizador de pelo menos duas partes receptoras (MS2; MS3). 15. 0 método da reivindicação 13, caracterizado pelo facto do método compreender a saída, pelo primeiro terminal de utilizador da parte emissora (MSI), informação do item fornecida com base no relatório ou relatórios de recepção do item recebido(s) (410) em que a saída inclui mostrar num visor do primeiro terminal de utilizador da parte emissora (MSI) informação sobre o item de dados em tempo real fornecida com base no relatório ou relatórios de recepção recebidos ( 410) . 16. 0 método da reivindicação 15, caracterizado pelo facto de que a saída inclui a visualização (410) de pelo menos informação identificativa relativa ao segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3), a qual enviou o relatório de aviso de recepção de item para o item de dados em tempo real.
9. 17. O método da reivindicação 13, caracterizado pelo facto de que compreende o envio de um pacote inicial para o segundo terminal de utilizador de pelo menos um terminal receptor (MS2; MS3) num sistema de comunicação de modo a iniciar o envio do item de dados em tempo real, o pacote 5/16 inicial contendo o pedido para enviar um relatório de aviso de recepção de item (403).
10. 18. O método da reivindicação 13, caracterizado pelo facto de que compreende o envio de um pacote final de modo a indicar o final do item de dados em tempo real (407).
11. 19. O método da reivindicação 13, caracterizado pelo facto de que os dados em tempo real incluem um ou mais dos seguintes: discursos, áudio em tempo real, video em tempo real ou multimédia em tempo real.
12. 20. Um método para usar num segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) que compreende: receber pacotes de dados de um item de dados em tempo real (501; 504) a partir de um primeiro terminal de utilizador de uma parte emissora (MSI) num sistema de comunicação; caracterizado por, receber, em associação com os pacotes de dados recebidos do item de dados em tempo real, num segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3), um pedido para enviar um relatório de aviso de recepção de item (503); detectar o final do item de dados em tempo real (505); e enviar, em resposta à recepção do pedido e detecção do final do item de dados em tempo real, um relatório de aviso 6/16 de recepção de item (508) para o primeiro terminal de utilizador da parte emissora (MSI). 21. 0 método da reivindicação 20, caracterizado pelo facto de compreender: receber um pacote inicial do primeiro terminal de utilizador da parte emissora (MSI) num sistema de comunicação de modo a iniciar o envio do item de dados em tempo real, o dito pacote inicial contendo o pedido para enviar um relatório de aviso de recepção de item (501; 502) .
13. 22. O método da reivindicação 20, caracterizado pelo facto de compreender: receber um pacote final que indica o final do item de dados em tempo real (504; 505).
14. 23. O método da reivindicação 20, caracterizado pelo facto dos dados em tempo real incluírem um ou mais dos seguintes: discursos, áudio em tempo real, vídeo em tempo real ou multimédia em tempo real.
15. 24. Um sistema de comunicação, que compreende: 7/16 um primeiro terminal de utilizador de uma parte emissora (MSI) configurado para enviar pacotes de dados de um item de dados em tempo real (403; 40 4; 406) para um segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) num sistema de comunicação, caracterizado pelo facto de que, o primeiro terminal de utilizador da parte emissora (MSI) é configurado para enviar, em associação com o envio do item de dados em tempo real, para o segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3), um pedido para enviar um relatório de aviso de recepção de item ( 403); e o segundo terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) configurada para enviar, em resposta ao pedido, um relatório de aviso de recepção de item para o primeiro terminal de utilizador da parte emissora (MSI) após o final do item de dados em tempo real (508).
16. 25. O método da reivindicação 24, caracterizado pelo facto de que o primeiro terminal de utilizador da parte emissora (MSI) é configurado para enviar um pedido para um item de dados em tempo real para o sistema de comunicação, o pedido para o item de dados em tempo real que inclui o pedido para enviar o relatório de aviso de recepção de item (403).
17. 26. O método da reivindicação 24, caracterizado pelo facto de que o primeiro terminal de utilizador da parte emissora (MSI) é configurado para enviar o pedido de enviar um relatório de aviso de recepção de item como sinalização incorporada, incorporada em tráfego de dados em tempo real, e o segundo terminal de utilizador de pelo menos uma parte 8/16 receptora (MS2; MS3) é configurado para enviar o relatório de aviso de recepção de item incorporado no tráfego de dados em tempo real. 27. 0 sistema de qualquer uma das reivindicações 24 a 26, caracterizado pelo facto de que o primeiro terminal de utilizador da parte emissora (MSI) é configurado para enviar o item de dados em tempo real sob a forma de pacotes de dados, contendo informação de dados em tempo real (406).
18. 28. O sistema da reivindicação 26, caracterizado pelo facto de que a sinalização incorporada compreende pacotes de dados com tipos de carga útil específicos.
19. 29. O sistema da reivindicação 24, caracterizado pelo facto de incluir um elemento de rede configurado para processar os relatórios de recepção de item a partir dos segundos terminais de utilizador de pelo menos duas partes receptoras (MS2; MS3) e para enviar um relatório de aviso de recepção de item combinado para o primeiro terminal de utilizador da parte emissora (MSI).
20. 30. O sistema da reivindicação 24, caracterizado pelo facto de que os dados em tempo real incluem um ou mais dos seguintes: discursos, áudio em tempo real, video em tempo real ou multimédia em tempo real.
21. 31. O sistema da reivindicação 24, caracterizado pelo facto de 9/16 o primeiro terminal de utilizador da parte emissora (MSI) é configurado para enviar pacotes de comunicação em tempo real relacionado a um item em tempo real e endereçado a um grupo de comunicação em grupo; e o sistema que compreende: uma entidade de rede de comunicação em grupo (10) que fornece funções de comunicações específicas para que qualquer pacote de comunicação em tempo real endereçado a um grupo de comunicação é multiplicado e enviado para cada membro receptor no respectivo grupo de comunicação de grupo com base nos seus endereços individuais.
22. 32. O sistema da reivindicação 31, caracterizado pelo facto de compreender: uma entidade de rede de comunicação de utilizador (20; 26) que fornece funções de comunicações especificas a cada utilizador, de modo que quaisquer comunicação relacionada com o grupo de um utilizador gerida pela dita entidade de rede de comunicação do utilizador sendo inicialmente encaminhada para a dita entidade de rede de comunicação de utilizador e depois reencaminhada para a entidade de rede de comunicação de grupo (10), e qualquer pacote de dados em tempo real enviado a partir da dita entidade de rede de comunicação de grupo sendo primeiro encaminhado para a dita entidade de rede de comunicação do utilizador (20; 26) antes de enviar o pacote de dados em tempo real enviado para o respectivo utilizador. 10/16
23. 33. Um terminal de utilizador (MSI; MS2; MS3) que compreende que um mecanismo (301) confiqurado para enviar pacotes de dados de um item em tempo real (403; 404; 406) para um terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) num sistema de comunicação; caracterizado por um mecanismo (301) configurado para enviar, em associação com o envio de pacotes de dados em tempo real, para o terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) um pedido para enviar um relatório de aviso de recepção de item (403); um mecanismo (301) configurado para receber, em resposta ao pedido, um relatório de aviso de recepção de item originado do terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) após terminar o item de dados em tempo real (409) .
24. 34. O método da reivindicação 33, caracterizado pelo facto de compreender: um mecanismo (301) configurado para enviar um pacote inicial para o terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) num sistema de comunicação de modo a iniciar o envio do item de dados em tempo real, o pacote inicial contendo um pedido para enviar um relatório de aviso de recepção de item (403).
25. 35. O terminal de utilizador da reivindicação 33, caracterizado pelo facto de compreender: um mecanismo (301) configurado para enviar um pacote final sob a forma de um pacote de transporte em tempo real, de 11/16 modo a indicar o final do item de dados em tempo real (407).
26. 36. O terminal de utilizador da reivindicação 33, caracterizado pelo facto de que o terminal de utilizador compreende um mecanismo configurado para emitir informação (304; 307) fornecido com base no relatório ou relatórios de recepção de item (410), em que o mecanismo de saida é configurado para mostrar pelo menos informação de identificação relativa ao terminal de utilizador de pelo menos uma parte receptora (MS2; MS3), a qual enviou o relatório de aviso de recepção de item para o item de dados em tempo real (410) . 37. 0 terminal de utilizador da reivindicação 33 ou 36, caracterizado pelo facto de incluir um mecanismo operado pelo utilizador para iniciar e terminar o item de dados em tempo real.
27. 38. O terminal de utilizador da reivindicação 37, caracterizado pelo facto de incluir um mecanismo de carregar para falar para iniciar e terminar o item de dados em tempo real.
28. 39. Um terminal de utilizador (MSI; MS2; MS3) que compreende: um mecanismo configurado para receber pacotes de dados de um item de dados em tempo real de um terminal de utilizador 12/16 de uma parte emissora (MSI) num sistema de comunicação (301; 501; 504); caracterizado por, um mecanismo configurado para receber, em associação com os pacotes de dados recebidos de um item de dados em tempo real, para o terminal de utilizador de pelo menos uma parte receptora (MS2; MS3) um pedido para enviar um relatório de aviso de recepção de item de dados em tempo real (301; 501; 502) ; um mecanismo configurado para detectar o final do item de dados em tempo real (305; 505) ; e um mecanismo configurado para enviar, em resposta ao dito pedido e detecção do final do item discurso, um relatório de aviso de recepção de item (301; 508).
29. 40. Um terminal de utilizador de acordo com a reivindicação 39, caracterizado por compreender: um mecanismo configurado para receber um pacote inicial de um terminal de utilizador de uma parte emissora (MSI) num sistema de comunicação, de modo a iniciar o envio do item de dados em tempo real, o dito pacote inicial contendo o pedido para enviar um relatório de aviso de recepção de item (501; 502) .
30. 41. Um terminal de utilizador de acordo com a reivindicação 39, caracterizado por compreender: 13/16 um mecanismo configurado para receber um pacote final sob a forma de um pacote de transporte em tempo real, de modo a indicar o final do item de dados em tempo real (504; 505).
31. 42. Uma entidade de rede de comunicação de grupo (10) que fornece funções de comunicações especificas para que qualquer pacote de comunicação em tempo real, endereçado a um grupo de comunicação, seja multiplicado e enviado a cada membro receptor no respectivo grupo de comunicação em grupo, com base nos seus endereços individuais, caracterizada pelo facto de que, a entidade de rede de comunicação em grupo (10) é configurada para: receber, a partir de um terminal de utilizador de um membro emissor (MSI) em associação com pacotes de comunicação em tempo real, relativamente ao item em tempo real (501; 504) e endereçado a um grupo de comunicação, um pedido para enviar um relatório de aviso de recepção de item (503); enviar o pedido para um terminal de utilizador de pelo menos um membro receptor (MS2; MS3); e receber, em resposta ao pedido, um relatório de aviso de recepção de item (508) do terminal de utilizador de pelo menos um membro receptor (MS2; MS3) após o final do item de dados em tempo real.
32. 43. Uma entidade de rede de comunicação em grupo de acordo com a reivindicação 42, caracterizada pelo facto de que a entidade de rede de comunicação em grupo é configurada para: 14/16 verificar membros activos (MS2; MS3) do grupo para o qual os pacotes de comunicação em tempo real estão destinados; e gerar a partir dos pacotes de comunicação em tempo real, um pacote de ligação descendente para cada membro activo (MS2; MS3) .
33. 44. Um método para usar numa entidade de rede de comunicação em grupo (10) que compreende: fornecer funções de comunicações específicas de grupo, de modo que qualquer pacote de comunicação em tempo real endereçado a um grupo de comunicação é multiplicado e enviado para cada membro receptor (MSI; MS2; MS3) no respectivo grupo de comunicação em grupo, com base nos seus endereços individuais; caracterizado por, receber, de um terminal de utilizador do membro emissor (MSI) em associação com os pacotes de comunicação em tempo real relativamente a um item em tempo real (501; 504) e endereçado para um grupo de comunicação, um pedido para enviar um relatório de aviso de recepção de item (503); enviar o pedido para um terminal de utilizador de pelo menos um membro receptor (MS2; MS3); e receber, em resposta ao pedido, um relatório de aviso de recepção de item (508) a partir do terminal de utilizador de pelo menos um membro receptor (MS2; MS3) após o final do item de dados em tempo real. 15/16
34. 45. Um método de acordo com a reivindicação 44 caracterizado por compreender: verificar os membros activos (MS2; MS3) do grupo para o qual os pacotes de comunicação em tempo real são destinados; e gerar, a partir dos pacotes de comunicação em tempo real recebidos, um pacote em ligação descendente para cada membro activo (MS2; MS3). Lisboa, 11 de Outubro de 2010 16/16