ES2954260T3

ES2954260T3 - Método y sistema para reducir la señalización de mensajes

Info

Publication number: ES2954260T3
Application number: ES20194932T
Authority: ES
Inventors: Adrian Buckley; Jan Hendrik Lucas Bakker; Alexander Shatsky
Original assignee: BlackBerry Ltd
Current assignee: BlackBerry Ltd
Priority date: 2010-01-14
Filing date: 2011-01-14
Publication date: 2023-11-21
Anticipated expiration: 2031-01-14
Also published as: EP3764617A1; EP2524527A1; EP2524527B8; EP4290823A3; EP2524527B1; WO2011085495A8; TW201146030A; EP3764617B1; CA2786785A1; WO2011085495A1; EP2524527A4; US20110173434A1; EP3764617C0; US9197676B2; EP4290823A2; CN102835134A

Abstract

Se divulga un sistema para comunicar un mensaje usando un segundo protocolo de señalización. El segundo protocolo de señalización proporciona un canal de control de sesión entre un agente de usuario (UA) y un nodo de red y puede incluir, por ejemplo, el protocolo I1. El sistema identifica una primera cadena a transmitir dentro de un primer mensaje. El primer mensaje se codifica según un primer protocolo de señalización. El sistema asocia la primera cadena con una primera clave y almacena la primera cadena y la primera clave en una base de datos. La base de datos asocia la primera cadena y la primera clave. El sistema codifica la primera clave dentro de un segundo mensaje y transmite el segundo mensaje utilizando el segundo protocolo de señalización. La primera cadena puede incluir una pluralidad de valores de datos. El sistema clasifica la pluralidad de valores de datos en un orden y asocia cada uno de la pluralidad de valores de datos con una clave. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método y sistema para reducir la señalización de mensajes

Referencias cruzadas

Antecedentes

La presente descripción se refiere generalmente a una señalización más eficiente y más específicamente a un sistema y aparato para reducir una cantidad de información comunicada usando un primer protocolo de señalización (por ejemplo, protocolo de iniciación de sesión (SIP) o un segundo protocolo de señalización (por ejemplo, señalización de interfaz I1).

Como se usa en el presente documento, los términos “Agente de Usuario” y “ UA” pueden referirse a dispositivos inalámbricos tales como teléfonos móviles, asistentes digitales personales (PDA), ordenadores de mano o portátiles y dispositivos similares u otro equipo de usuario (“ UE” ) que tienen capacidades de telecomunicaciones. En algunas realizaciones, un UA puede referirse a un dispositivo inalámbrico móvil. El término “ UA” también puede referirse a dispositivos que tienen capacidades similares pero que generalmente no son transportables, tales como ordenadores de sobremesa, decodificadores, o nodos de red. A lo largo de esta descripción, el U^apuede referirse a un SIP UA tal como un dispositivo inalámbrico, un decodificador, u otros dispositivos de comunicación y es intercambiable con el término UA.

En los sistemas del Proyecto de Asociación de Tercera Generación (3GPP), un subsistema multimedia (IMS) de protocolo de internet (IP) permite la entrega de servicios multimedia IP. Utilizando IMS, un UA puede transmitir y recibir comunicaciones multimedia y/o de voz por conmutación de paquetes (PS) a través de una estación base que implementa uno o más Componentes Funcionales IMS. Para implementar IMS, las redes dependen del protocolo de iniciación de sesión (SIP - Session Initiation Protocol) para proporcionar un protocolo de señalización basado en texto que puede usarse para comunicar entre un UA y la red central (CN) IMS, entre la CN IMS y los Servidores de Aplicaciones, y entre otros componentes de la Red IMS.

En redes existentes, servicios centralizados IMS (ICS) permiten que diversos servicios IMS se proporcionen a un UA usar una red inalámbrica donde se proporcionan comunicaciones de voz sobre una portadora de conmutación de circuitos (CS) y otros componentes de medios se proporcionan sobre portadores de conmutación de paquetes (PS) y el control de la señalización puede realizarse usando IMS u otro protocolo denominado I1 que está siendo definido en 3GPP TS 24.294. Redes de ejemplo pueden incluir redes de evolución a largo plazo (LTE), sistemas de datos mejorados para comunicación móvil (GSM) para las redes de datos de Acceso por Radio (GERAN) de evolución de GSM (EDGE), o redes de la Red de Acceso por Radio Terrestre del Sistema Universal de Telecomunicaciones Móviles (UMTS). El ICS también puede configurarse para proporcionar control de servicio para características en la red IMS en circunstancias cuando el dispositivo inalámbrico está conectado a una red que no es IMS, tal como cuando el UA está conectado a un centro de conmutación móvil (MSC). Las características controladas por ICS pueden incluir retención de llamadas, transferencia de llamada, identidad de línea de llamada, etc.

En general, los ICS requieren el soporte simultáneo de una portadora para voz y una portadora para soportar la señalización de control que usa señalización de SIP. En algunas circunstancias, sin embargo, la portadora para soportar la señalización SIP puede no estar disponible, por ejemplo, porque la conectividad Gm no existe (p. ej., no existe un acuerdo de itinerancia de PS o un acuerdo de itinerancia IMS), el UA no puede registrarse con la infraestructura IMS debido a problemas operativos, o el modo de transferencia dual (DTM) no está disponible en la celda o el dispositivo inalámbrico. En ese caso, el protocolo I1 como se define en 3GPP TS 24.294 le permite a un dispositivo inalámbrico implementar un protocolo de señalización usando una portadora CS en el lugar de la interfaz Gm. El protocolo de señalización puede ser un protocolo de tipo SIP. En ese caso, el protocolo 11 usa o se une a o se envuelve en protocolos de transporte tales como, pero sin limitarse a, servicio de mensajes cortos (SMS) o datos de servicio complementarios no estructurados (USSD), etc. El uso de estos protocolos de transporte limita la carga útil de información por mensaje o señalización, generalmente, a un máximo de 160 octetos. Desafortunadamente, SIP es un protocolo basado en caracteres verbosos y, como resultado, los mensajes de señalización codificados por SIP a menudo no se ajustan en una carga útil limitada tal como la proporcionada por SMS o USSD. La Tabla 1 ilustra un ejemplo de mensaje codificado por SIP.

Tabla 1

Con referencia a la Tabla 1, hay varios elementos de datos que se incluyen dentro del mensaje SIP que se suman a la verbosidad del mensaje. Por ejemplo, la identidad de la parte original (“ P-Preferred-Identity: <sip:user2_public1@home1.net><tel: 1-212-555-2222>” ) puede incluir un identificador de recurso uniforme SIP (URI) y tel URI. Sin embargo, las cadenas SIP de Identidad de Usuario Publica y tel URI (que también se pueden transportar en mensajes SIP en otros campos de encabezado SIP que el campo de encabezado de P-Preferred-Identity) pueden ser relativamente verbosos ya que toman la forma de “ usuario@dominio” Aunque son verbosos, es importante designar una Identidad de Usuario Pública dentro de un mensaje de SIP ya que un usuario puede tener muchas identidades (por ejemplo, identidades de Trabajo, Casa o privadas) que están todas registradas con un dispositivo inalámbrico particular. En consecuencia, cuando se transmite un mensaje SIP, el dispositivo inalámbrico debe determinar qué Identidad de Usuario Pública usar para la identificación e incluir esa información en el mensaje de SIP. De manera similar, cuando un UA recibe una llamada (por ejemplo, una sesión terminada en un dispositivo inalámbrico), el usuario sabe a qué identidad se le llamó, para que sepa cómo responder a la llamada. Por consiguiente, la información de identidad de usuario se incluye en mensajes SIP enviados y recibidos desde un UA.

También se pueden incluir diversas capacidades de UA de SIP en el mensaje de SIP (p. ej., “Accept-Contact: *;+g.3gpp.icsi-ref=“ urn%3Aurn-7 %3gpp-service.ims.icsi.mmtel” ). Las capacidades de UA de SIP proporcionan a la red una indicación de las capacidades del dispositivo inalámbrico. Debido a que un dispositivo inalámbrico puede admitir muchos servicios, la parte de capacidades de UA de SIP del mensaje de SIP puede incluir una cantidad significativa de datos necesarios para que una red se comunique efectivamente con un UA. El mensaje SIP también puede incluir un campo de encabezado de ID-ID (por ejemplo, “ Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6” ) que puede usarse para referirse a una sesión SIP existente usando una Diana-Diálogo, tal como en el caso de un mensaje 11 que añade un componente de voz a través de una portadora CS.

En consecuencia, los mensajes SIP pueden incluir varios elementos de datos que incluyen valores de datos verbosos tales como definiciones de identidades públicas, capacidades del dispositivo y identificadores de sesión SIP existentes. En los sistemas que implementan protocolos similares a SIP sobre interfaces I1, aunque estos puntos de datos pueden eliminarse, generalmente es preferible que se incluyan para proporcionar un interfuncionamiento más fácil y mapearse entre 11 y, por ejemplo, SIP. Desafortunadamente, estos puntos de datos verbosos pueden generar mensajes I1 que son más grandes que la carga útil máxima de la interfaz I1, lo que resulta en una transmisión ineficiente. Por consiguiente, existe una necesidad de comprimir o minimizar de otro modo el tamaño de mensajes similares a SIP en interfaces similares a I1,

El documento de la técnica anterior US-2009129388 A1 divulga un nuevo protocolo de reducción de encabezado de SIP que funciona en una red de comunicación para comprimir los campos de encabezado de SIP en mensajes de control de SIP utilizados para iniciar una sesión de comunicación SIP.

Breve descripción de los dibujos

Para una comprensión más completa de esta descripción, ahora se hace referencia a la siguiente breve descripción, tomada en relación con los dibujos adjuntos y la descripción detallada, en donde los números de referencia similares representan partes similares.

La Figura 1 es una ilustración de un flujo de mensajes para el inicio de sesión mediante el uso de una interfaz 11 en donde un agente de usuario (UA) proporciona un indicio a la red que identifica una Identidad de Usuario Pública;

La Figura 2 es una ilustración de un flujo de mensajes para un inicio de sesión con terminación de UA mediante el uso de una interfaz I1 mediante el uso de un indicio para identificar una Identidad de Usuario Pública;

La Figura 3 es una ilustración de una función hash para convertir a partir de una Identidad de Usuario Pública con un resultado resumen, el resultado hash es más pequeño que la Identidad de Usuario Pública y se usa para determinar un indicio para cada Identidad de Usuario Pública;

La Figura 4 ilustra un flujo de mensajes para registro de UA dentro de una red;

La Figura 5 ilustra un flujo de información de pila en donde el dispositivo diana se direcciona usando tel URI o usuario=teléfono de URI de SIP;

La Figura 6 es una ilustración de un flujo de mensajes de ejemplo para optimizar las comunicaciones de cadena entre un Remitente de Cadena y una entidad Destinataria de Cadena;

La Figura 7 es un diagrama de un sistema de comunicaciones inalámbricas que incluye un UA operable para algunas de las diversas realizaciones de la divulgación;

La Figura 8 es un diagrama de bloques de un UA operativo para algunas de las diversas realizaciones de la divulgación;

La Figura 9 es un diagrama de un entorno de software que puede implementarse en un UA operable para algunas de las diversas realizaciones de la divulgación; y

La Figura 10 es un sistema informático de propósito general ilustrativo adecuado para algunas de las diversas realizaciones de la divulgación.

Descripción detallada

Para este fin, algunas realizaciones incluyen un método para comunicar un mensaje usando una interfaz I1. La interfaz I1 proporciona un canal de control de sesión entre un agente de usuario (UA) y un nodo de red. El método incluye identificar una primera cadena, recuperar una primera clave asociada con la primera cadena y codificar la primera clave dentro de un mensaje. El procedimiento incluye transmitir el mensaje a al menos uno de un UA y un nodo de red usando un canal de control de sesión.

Otras realizaciones incluyen un método para comunicar un mensaje mediante el uso de una interfaz I1. La interfaz I1 proporciona un canal de control de sesión entre un agente de usuario (UA) y un nodo de red. El método incluye recibir el mensaje mediante el uso de la interfaz I1, recuperar una primera clave del mensaje y recuperar una primera cadena asociada con la primera clave. La primera cadena puede incluir un valor codificado de valor de longitud (LV).

Otras realizaciones incluyen un método para comunicar un mensaje usando un segundo protocolo de señalización. El segundo protocolo de señalización proporciona un canal de control de sesión entre un agente de usuario (UA) y un nodo de red. El método incluye identificar una primera cadena a transmitir dentro de un primer mensaje. El primer mensaje se codifica de acuerdo con un primer protocolo de señalización. El método incluye asociar la primera cadena con una primera clave y almacenar la primera cadena y la primera clave en una base de datos. La base de datos asocia la primera cadena y la primera clave. El método incluye codificar la primera clave dentro de un segundo mensaje, y transmitir el segundo mensaje usando el segundo protocolo de señalización.

Otras realizaciones incluyen un método para comunicar un mensaje usando un segundo protocolo de señalización. El segundo protocolo de señalización proporciona un canal de control de sesión entre un agente de usuario (UA) y un nodo de red. El método incluye recibir un primer mensaje codificado de acuerdo con un primer protocolo de señalización. El primer mensaje incluye una primera cadena. El método incluye asociar la primera cadena con una primera clave y almacenar la primera cadena y la primera clave en una base de datos. La base de datos asocia la primera cadena y la primera clave. El método incluye codificar la primera clave dentro de un segundo mensaje, y transmitir el segundo mensaje usando el segundo protocolo de señalización.

Otras realizaciones incluyen un aparato para comunicar un mensaje usando una interfaz I1. La interfaz I1 proporciona un canal de control de sesión. El aparato puede ser al menos uno de un agente de usuario (UA) y un nodo de red. El aparato comprende un procesador configurado para identificar una primera cadena a transmitir dentro de un mensaje. La primera cadena incluye un valor codificado de valor de longitud (LV). El procesador está configurado para recuperar una primera clave asociada con la primera cadena, codificar la primera clave dentro del mensaje y transmitir el mensaje a al menos uno de un UA y un nodo de red usando la interfaz I1.

Otras realizaciones incluyen un aparato para comunicar un mensaje usando un segundo protocolo de señalización. El segundo protocolo de señalización proporciona un canal de control de sesión. El aparato puede incluir al menos uno de un agente de usuario (UA) y un nodo de red. El aparato puede comprender un procesador configurado para recibir un primer mensaje codificado de acuerdo con un primer protocolo de señalización. El primer mensaje incluye una primera cadena. El procesador está configurado para asociar la primera cadena a una primera clave y almacenar la primera cadena y la primera clave en una base de datos. La base de datos asocia la primera cadena y la primera clave. El procesador está configurado para codificar la primera clave dentro de un segundo mensaje, y transmitir el segundo mensaje usando el segundo protocolo de señalización.

Para la realización de los fines anteriores y relacionados, la descripción, a continuación, comprende las características descritas completamente a continuación. La siguiente descripción y los dibujos adjuntos exponen en detalle ciertos aspectos ilustrativos de la descripción. Sin embargo, estos aspectos son indicativos de algunas de las diversas formas en las que pueden emplearse los principios de la divulgación. Otros aspectos, ventajas y características novedosas de la divulgación se harán evidentes a partir de la siguiente descripción detallada de la divulgación cuando se considera junto con los dibujos.

Los diversos aspectos de la presente divulgación se describen ahora con referencia a los dibujos adjuntos, en los que números similares se refieren a elementos similares o correspondientes en todas partes. Sin embargo, debe entenderse que los dibujos y la descripción detallada relacionados con los mismos no pretenden limitar el objeto reivindicado a la forma particular descrita. Más bien, la intención es cubrir todas las modificaciones, equivalentes y alternativas que caen dentro del alcance del objeto reivindicado.

Como se usa en el presente documento, los términos “ componente” , “ sistema” y similares están destinados a referirse a una entidad relacionada con el ordenador, ya sea hardware, una combinación de hardware y software, software o software en ejecución. Por ejemplo, un componente puede ser, pero no se limita a ser, un proceso que se ejecuta en un procesador, un procesador, un objeto, un ejecutable, un hilo (thread) de ejecución, un programa y/o un ordenador. A modo de ilustración, tanto una aplicación que se ejecuta en un ordenador como el ordenador pueden ser un componente. Uno o más componentes pueden residir dentro de un proceso y/o hilo (thread) de ejecución y un componente puede localizarse en un ordenador y/o distribuirse entre dos o más ordenadores.

Además, la materia objeto divulgada puede implementarse como un sistema, método, aparato o artículo de fabricación usando técnicas estándar de programación e/o ingeniería para producir software, firmware, hardware o cualquier combinación de los mismos para controlar un dispositivo basado en ordenador o procesador para implementar aspectos detallados en el presente documento. El término “ artículo de fabricación” (o alternativamente, “ producto de programa informático” ) como se usa en la presente descripción pretende abarcar un programa informático accesible desde cualquier dispositivo, portador o medio legible por ordenador. Por ejemplo, los medios legibles por ordenador pueden incluir, pero no se limitan a, dispositivos de almacenamiento magnético (por ejemplo, disco duro, disquete, tiras magnéticas ...), discos ópticos (p. ej., disco compacto (CD), disco versátil digital (DVD) ...), tarjetas inteligentes y dispositivos de memoria flash (p. ej., tarjeta, memoria extraible). Además, debe apreciarse que puede emplearse una onda portadora para transportar datos electrónicos legibles por ordenador tales como los utilizados en la transmisión y recepción de correo electrónico o para acceder a una red tal como Internet o una red de área local (LAN). Por supuesto, los expertos en la técnica reconocerán muchas modificaciones pueden realizarse a esta configuración sin apartarse del alcance del objeto reivindicado.

Mensajes de protocolo de iniciación de sesión (SIP) pueden incluir varios elementos de datos verbosos que incluyen definiciones de Identidades de Usuario Públicas, capacidades de dispositivo y identificadores de sesión SIP existentes, etc. En sistemas que implementan protocolos de tipo SIP sobre interfaces I1, por ejemplo, aunque estos puntos de datos pueden eliminarse, generalmente es preferible que se incluyan para proporcionar un interfuncionamiento más fácil y mapeo entre I1 y SIP. Desafortunadamente, estos puntos de datos verbosos pueden generar mensajes SIP que son más grandes que la carga útil máxima de, por ejemplo, la interfaz I1, lo que da como resultado una transmisión ineficiente.

El presente sistema compacta información verbosa, que incluye, por ejemplo, elementos de datos tales como las identidades públicas, capacidades del dispositivo y identificadores de sesión SIP existentes encontrados dentro de mensajes SIP u otros, por ejemplo, mensajes codificados por SIP, tales como mensajes configurados para transmitirse usando la interfaz 11. Las realizaciones descritas también podrían ser aplicables a otros elementos de información SIP. La información compactada puede comunicarse entre dos entidades y leerse por cualquiera de las partes para recuperar, reproducir o determinar la información original. Por ejemplo, las entidades pueden incluir un Remitente de Cadena y Destinatario de Cadena, que cada uno puede incluir un UA, un nodo de red u otras entidades de red. El presente sistema puede configurarse para proporcionar compresión estática o dinámica. En el caso de la compresión estática, el mapeo de compresión se define previamente y el mismo tanto en el UA como en la red. En la compresión dinámica, el mapeo de compresión puede variar de manera que los mismos datos originales puedan dar como resultado diferentes datos comprimidos en diferentes momentos. Aunque la presente divulgación proporciona ejemplos que muestran la compresión de partes particulares de los mensajes, tales como encabezados particulares o elementos de datos, cualquiera del contenido del mensaje puede ser elegible para la compresión de acuerdo con la presente divulgación.

Aunque la presente descripción presenta ejemplos del presente sistema como el sistema se refiere a minimizar la cantidad de datos incluidos dentro de los mensajes de SIP o codificados de tipo SIP para la transmisión usando la interfaz I1 u otras interfaces, el presente sistema puede usarse en cualquier implementación que tenga protocolos de señalización primero y segundo donde un mensaje puede codificarse de acuerdo con un primer protocolo de señalización y transmitirse usando un segundo protocolo de señalización. Alternativamente, el sistema puede usarse para minimizar la cantidad de datos incluidos dentro de un mensaje codificado de acuerdo con un primer protocolo de señalización, donde el mensaje también se transmite mediante el uso del primer protocolo de señalización.

En el presente sistema, el UA y la red están configurados para asignar cadenas de identificador, claves o indicios a cada uno de varios valores que pueden incluirse dentro de un mensaje. En varias implementaciones, las cadenas de identificador, claves o indicios pueden incluir símbolos, identificadores, referencias, ID, hashes, números, cadenas alfanuméricas, valores hexadecimales o cualquier otro dato que pueda usarse como un valor o identificador de referencia. En una realización, las cadenas de identificador, claves o indicios codificados están correlacionados con otros bytes/palabras o cadenas de caracteres usando diccionarios. Los términos “ cadenas” , “ claves” o “ indicio” / “ indicios” se usan en la presente descripción indistintamente y pueden considerarse que tienen el mismo significado. Cuando se comunica, el UA y la red usan esos indicios en lugar de los valores originales, que pueden ser relativamente grandes. Debido a que los indicios incluyen menos datos que los propios valores originales, la cantidad de datos transmitidos entre el UA y la red puede minimizarse. Dependiendo de la implementación del sistema, la asignación de los indicios puede ser explícita (por ejemplo, proporcionando un diccionario predeterminado de indicios) o implícita (por ejemplo, tal como cuando un ordenamiento de las Identidades de Usuario Públicas determina que se usará el indicio). Los indicios pueden incluir cadenas de texto, Código de Estándar Americano para cadenas de Intercambio de Información (ASCII), datos hexadecimales o cualquier otra información o datos que puedan asociarse con una cadena o valor de datos particular Los indicios pueden incluir índices numéricos o contadores, o partes de las cadenas a las que se refieren los indicios. Generalmente, varios indicios que se relacionan con posibles valores para un único elemento de datos dentro de un mensaje son únicas y distintas. Sin embargo, en los elementos de datos, puede haber varios indicios que comparten el mismo valor. Por ejemplo, los indicios “ 1” , “ 2” y “ 3” pueden definirse para un primer elemento de datos dentro de un mensaje, y los indicios “ 1” , “ 2” , “ 3” y “ 4” pueden definirse para un segundo elemento de datos dentro de un mensaje. Alternativamente, la ausencia de cualquier indicio dentro de un mensaje SIP o I1 puede constituir indicios implícitos que indican que debe usarse un valor predeterminado. Además, en algunos contextos, la necesidad de valores reservados es evidente. Por ejemplo, en caso de “ retirada de control de sesión” como se analiza en 3GPP TS 24.294 y/o 3GPP TS 24.292, un encabezado puede estar presente en un mensaje I1 pero el valor del encabezado preferiblemente no se usa, porque, si está presente, la información recibida sobre Gm o usando SIP o de otro modo se usa en el lugar del valor del encabezado. En tal caso, sería ventajoso si se usa un valor reservado o indicios. El valor reservado puede indicar una cadena predeterminada tal como un Identificador de Usuario Público en ausencia de valores recibidos sobre Gm o usando SIP, o el valor reservado puede indicar que los valores recibidos sobre Gm o usando SIP deben usarse.

En una implementación específica, el UA y el nodo de red pueden asignar cadenas de identificador, claves o indicios a cada una de las identidades públicas de usuario asociadas con un UA o un usuario particular. Cuando se comunica, el UA y la red usan esos indicios para referirse a las Identidades de Usuario Públicas. Los indicios, que son más cortos que la Identidad de Usuario Pública asociada, pueden pasar hacia atrás y hacia adelante entre el UA y la red para referirse a una Identidad de Usuario Pública particular y minimizar las comunicaciones de tráfico de datos. En esta implementación, el UA incluye una memoria para almacenar las identidades públicas y los indicios asociadas. La memoria puede ser interna, externa o extraíble al UA y puede incluir, por ejemplo, (U)SIM, flash compacto, digital seguro, miniSD u otras tarjetas de memoria o dispositivos de almacenamiento. Alternativamente, la memoria puede residir dentro del UA tal como en un medio de memoria no volátil. Para los fines del resto de esta solicitud cuando el término memoria parece entenderse que la memoria puede ser interna o extraíble, o una combinación de las mismas, donde la memoria extraíble podría ser al menos cualquiera de las identificadas previamente u otras formas.

Las Identidades de Usuario Públicas pueden proporcionarse al UA y almacenarse en una base de datos en memoria en un orden de prioridad. Las Identidades de Usuario Públicas pueden asociarse entonces con un indicio, donde el indicio incluye un identificador único para cada identidad. Los indicios a asociar con cada Identidad de Usuario Pública puede determinarse por el orden de prioridad. Por ejemplo, se puede implementar una prioridad posicional en la que una Identidad de Usuario Pública enumerada primero dentro de la memoria tiene una prioridad más alta sobre la Identidad de Usuario Pública enumerada por debajo de esta y los indicios son números que reflejan la prioridad (por ejemplo, la Identidad de Usuario Pública de prioridad más alta se hace referencia al uso del indicio “ 1” , la segunda Identidad de Usuario Pública de prioridad más alta se denomina usando el indicio “ 2” , y así sucesivamente). En una implementación jerárquica, una Identidad de Usuario Pública a la izquierda puede tener una prioridad más alta que la que está a la derecha. En algunos casos, se puede usar una función hash para asociar cada Identidad de Usuario Pública con un identificador único que es determinante del indicio para asociarse con cada Identidad de Usuario Pública. Alternativamente, se puede proporcionar una clasificación de prioridad explícita en la que se agrega un indicador que indica la prioridad de las Identidades de Usuario Públicas o se incorpora de otro modo en la estructura de base de datos y se usa como el indicio. Por ejemplo, un valor de prioridad de 0 puede indicar la Identidad de Usuario Pública que tiene la prioridad más alta. Cuando no se proporciona ningún indicador de prioridad, se pueden suponer o interpretar que todas las Identidades de Usuario Públicas tienen una prioridad igual.

En el presente sistema, puede proporcionarse un indicio para identificar de manera única cada Identidad de Usuario Pública listada. La Identidad de Usuario Pública de prioridad más alta también puede conocerse como la identidad de usuario predeterminada o una Identidad de Usuario Pública única puede ser proporcionada que se conoce o identifica como la identidad de usuario predeterminada. El indicio que se refiere a cada Identidad de Usuario Pública puede determinarse explícita o implícitamente (por ejemplo, implícita cuando se determina por el orden de prioridad de las Identidades de Usuario Públicas, tal como por un número asignado a cada posición de ordenación de las Identidades de Usuario Públicas) y puede usarse por una función de red (por ejemplo, un UA o nodo de red tal como una coherencia de servicio y un servidor de aplicación de continuidad (SCC AS)) para señalizar a la función correspondiente (por ejemplo, el SCC AS o UA) la Identidad de Usuario Pública que se va a transportar. Por ejemplo, en una implementación específica, la primera Identidad de Usuario Pública almacenada en el archivo USIM eF^impucomo se define en la subcláusula 4.2.4 de 3GPP TS 31.103 o la primera Identidad de Usuario Pública almacenada en la hoja de usuario de objeto de gestión de IMS OMA, como se define en la subcláusula 5.16 de 3GPP TS 24.167 se define como la Identidad de Usuario Pública predeterminada. En algunos casos, después de un registro exitoso, la Identidad de Usuario Pública predeterminada puede modificarse, por ejemplo, como la 200OK que indica una respuesta exitosa puede contener el URI de P-Asociado que puede contener una Identidad de Usuario Pública que luego puede convertirse en la Identidad de Usuario Pública predeterminada.

Cuando el UA establece una sesión originada, el UA incluye un indicio en la solicitud de inicio de sesión. El indicio se usa en lugar de e identifica la Identidad de Usuario Pública de que el UA usará para identificarse. Por ejemplo, si se basa en el ordenamiento posicional, el indicio para la primera Identidad de Usuario Pública enumerada puede ser el número “ 1” , y el indicio para la segunda identidad enumerada puede ser el número “ 2” . La Figura 1 es una ilustración del flujo de mensajes para el inicio de sesión mediante el uso de una interfaz I1 donde el UA proporciona un indicio a la red y el indicio identifica una Identidad de Usuario Pública. El indicio se usa para minimizar un tamaño del mensaje. Obsérvese que el flujo de mensajes en la Figura 1 también puede aplicarse a mensajes SIP.

En la primera etapa 14, el UA 10 inicia el origen de la sesión usando el protocolo I1. El protocolo I1 puede usarse, por ejemplo, porque la DTM no está disponible, un registro SIP sobre Gm no puede establecerse, o Gm no está disponible. En la etapa 16, el UA 10 envía un INVITE I1 al dispositivo 12 de red (por ejemplo, un SCC AS). El INVITE l1 puede incluir una dirección 'De' que contiene una identificación de indicio de que debe usarse Identidad de Usuario Pública para identificar el dispositivo. En el ejemplo que se muestra en la Figura 1, el indicio es igual a “ 1” y se refiere a una Identidad de Usuario Pública particular almacenada en la memoria tanto del UA 10 como del dispositivo de red 12. Alternativamente, el INVITE I1 puede no incluir un campo 'De'. En ese caso, puede considerarse que el indicio tiene un valor nulo. La Identidad de Usuario Pública identificada como la Identidad de Usuario Pública predeterminada puede usarse si el encabezado 'De' no indica un valor particular. La Identidad de Usuario Pública predeterminada puede almacenarse en la memoria tanto del UA 10 como del dispositivo de red 12. Por ejemplo, la Identidad de Usuario Pública predeterminada puede almacenarse como la primera entrada en un Archivo de Usuario Público (EFMPU) de archivos elementales IMS en un Módulo de identidad IMS (ISIM), en un objeto (MO) gestionado por la gestión de dispositivo (OMA) móvil (OMA) como la primera entrada, o en una hoja de Identidad de Usuario Pública predeterminada explícita. Alternativamente, la Identidad de Usuario Pública predeterminada puede construirse a partir del número de red Digital de servicios integrados de abonado móvil (MSISDN) del dispositivo inalámbrico si se almacena en el EFMSISDN de Módulo de Identidad de Abonado Universal (USIM). Si se usa el C-MSIDSN, el campo 'De' puede estar ausente del mensaje I1. De manera similar, si la dirección de origen está en el sobre de SMS o USSD, el campo 'De' puede estar ausente. El propio nombre de encabezado 'DE' puede no estar incluido dentro del mensaje 11 para ahorrar espacio o octetos consumidos por el texto “ DE” . Una dirección 'De' que no contiene indicios indica que la Identidad de Usuario Pública predeterminada puede usarse para identificar el dispositivo. La Identidad de Usuario Pública predeterminada puede definirse, por ejemplo, como la primera identidad enumerada en la memoria del UA 10 y el dispositivo de red 12.

Como tal, en una implementación, el sistema funciona de acuerdo con las siguientes reglas al inspeccionar el contenido de los encabezados PARA y DE (De-id): 1) si la Identidad de Usuario Pública para identificar la parte de origen es la Identidad de Usuario Pública predeterminada, entonces no puede incluirse ningún 'De'-id 2) si la Identidad de Usuario Pública para identificar la parte de origen no es la Identidad de Usuario Pública predeterminada que incluye un identificador que identifica la Identidad de Usuario Pública, entonces esa identidad puede usarse para identificar la Parte de origen; y 3) si no se puede obtener un identificador, el SCC AS puede usar ya sea un URI SIP o un número E.164 para identificar el SES Ua .

En la etapa 18, el nodo de red 12 recibe el mensaje de INVITE I1 y decodifica el mensaje. El nodo 12 de red identifica el transporte subyacente (p. ej., SMS o USSD) y de ahí puede obtener el abonado C-MSISDN (también conocido como Correlación-MSISDN). Si el transporte es USD, el nodo 12 de red obtiene la identidad de la C-MSISDN/usuario público del abonado del elemento de servicio de MAP o un equivalente de la cadena de direcciones RDSI de servicio de MAP de acuerdo con la TS 29.002 de 3GPP. Alternativamente, si se usó SMS como protocolo de transporte, el nodo de red 12 obtiene los abonados C-MSISDN/Identidad de Usuario Pública del elemento de servicio de MAP o un equivalente del elemento de información de mensaje corto de audio de MAP-RP-OA de acuerdo con TS de 3GPP 29.002. En el caso posterior, si la interfaz con el SCC AS se basa en SMPP como se define en la especificación de protocolo de punto a punto de SMS Forum de SMS, por ejemplo en la PDU “ deliver_sm” en el elemento de información “ source_addr” , el elemento de información de “ service_type” también podría codificarse para indicar que este es un mensaje I1.

El nodo de red 12 identifica entonces que un elemento de información “ De” está presente en el mensaje de INVITE I1 (el mensaje puede incluir alternativamente un mensaje de creación de 11 sesiones o un mensaje de configuración de sesión de I1 donde un mensaje de INVITE I1 es un mensaje de configuración de sesión de I1) y busca el indicio asociado con el elemento 'De'. Si no hay indicio presente, el nodo de red 12 utiliza la Identidad de Usuario Pública predeterminada para identificar el UA 10. De manera similar, si no está presente el campo “ De” en el mensaje de INVITE I1, el nodo de red 12 puede configurarse para usar la Identidad de Usuario Pública predeterminada para el UA 10. Sin embargo, si está presente un indicio, el nodo de red 12 busca la Identidad de Usuario Pública correspondiente al indicio. La Identidad de Usuario Pública puede usarse para identificar los servicios a los que se ha abonado el usuario. Además, la Identidad de Usuario Pública determinada puede asignarse al encabezado 'De' un SIP INVITE saliente en una tabla almacenada en memoria o accesible en una base de datos que es local o remota al dispositivo de red 12. La dirección también puede usarse en el encabezado de contacto o, si ya hay un diálogo SIP asociado con el usuario como se identifica a partir de la C-MSISDN que luego se mapea a una identidad de usuario privada correspondiente, entonces esa misma Identidad de Usuario Pública para diálogo en curso puede usarse y el encabezado de contacto puede usar el mismo valor. En la etapa 20, el nodo de red 12 construye una solicitud SIP INVITE que incluye un campo de encabezado P-Asserted-ldentity establecido en la Identidad de Usuario Pública, donde la Identidad de Usuario Pública se determina como se describió anteriormente. La Identidad de Usuario Pública puede recuperarse de una base de datos o memoria. La misma Identidad de Usuario Pública también se puede usar en el campo de encabezado 'De' y campo de encabezado 'Contacto'.

En algunos casos, la se comunica en un Elemento de Información de Identidad ilustrado en la Tabla 2. El elemento de información de Información de Identidad puede contener un URI de SIP o un número de teléfono (por ejemplo, número internacional, número nacional) o un valor de identificador que identifica una identidad pública conocida. Si la Información de Identidad a usar es un URI de Tel o un URI de SIP con el usuario del parámetro URI = teléfono, entonces los bits de campos específicos de código 3, 2, y 1 pueden establecerse en “ 001” . Si un URI Tel o SIP se identifica como globalmente único identificado por la presencia de carácter “ ” al inicio de la cadena de dígitos, el tipo de Número puede considerarse en formato internacional. La identificación del Plan de numeración se puede establecer en E.164. Todos los demás formatos pueden considerarse desconocidos y el tipo de Número puede establecerse para desconocido y el plan de numeración desconocido.

Tabla 2

Si la Información de Identidad es un URI de SIP como se define en RFC 3261, por ejemplo SIP:username@domainname:PORT, entonces los bits de campos específicos de código 3,2, y 1 pueden establecerse en “ 010” y pueden codificarse a una cadena de octetos de acuerdo con reglas de codificación UTF-8 como se especifica en ITF RFC 3629 u otras reglas de codificación.

La Figura 2 es una ilustración del flujo de mensajes para el inicio de sesión con terminación de UA mediante el uso de una interfaz 11 mediante el uso de un indicio para identificar una Identidad de Usuario Pública. En la etapa 30, el nodo de red 12 (por ejemplo, un SCC AS) recibe un método SIP, por ejemplo, SIP INVITE y determina que la interfaz I1 debe usarse en comunicación con el UA 10. En la etapa 32, el nodo de red 12 envía un INVITE I1 al UA 10. El I1 INVITE incluye una dirección “ Para” que contiene un indicio que identifica la Identidad de Usuario Pública para usar para identificar el UA 10. La Identidad de Usuario Pública se toma de la invitación de SIP entrante y el nodo de red 12 usa una tabla de búsqueda para determinar la identificación de que la Identidad de Usuario Pública. Alternativamente, la INVITE I1 puede no incluir un campo de dirección “ Para” que indica que debe usarse la Identidad de Usuario Pública predeterminada. La Identidad de Usuario Pública predeterminada puede almacenarse en el servidor de abonado local (HSS) o el SCC AS, por ejemplo. Alternativamente, el SCC AS puede recuperar la Identidad de Usuario Pública predeterminada del h Ss que podría ser la C-MSISDN u otro valor.

En algunos casos, la Identidad de Usuario Pública predeterminada se define como la primera Identidad de Usuario Pública enviada en el URI de P-Asociado. Cuando se envía el mensaje USSD, puede ser necesario que la cadena RDSI de la MAP Open contiene la C-MSISDN y esto es equivalente a la Identidad de Usuario Pública predeterminada. Una dirección 'Para' que no contiene ningún indicio puede identificar que la Identidad de Usuario Pública predeterminada debe usarse para identificar el dispositivo.

En la etapa 34, el UA 10 recibe el mensaje de INVITE de I1 y decodifica el protocolo asociado. El UA puede determinar que un elemento de información “ Para” está presente y busca el indicio contenido en el elemento de información 'Para'. Si no hay indicio presente, el UA 10 puede suponer que la Identidad de Usuario Pública predeterminada debe usarse para identificar el dispositivo. La Identidad de Usuario Pública predeterminada podría almacenarse en el ISIM del UA 10 en la EF^impuarchivo, en una OMA DM MO como primera entrada o en una hoja de Identidad de Usuario Pública predeterminada explícita, se puede recibir en el 200 OK P Associat-URI (ver más abajo) cuando el UA se registra inicialmente SIP, o se puede construir del MSISDN si se almacena en la (U)SIM EF^msisdnpor ejemplo Alternativamente, si no está presente el campo de dirección “ Para” , puede usarse una Identidad de Usuario Pública predeterminada. Si, sin embargo, está presente un indicio, el UA 10 busca el valor en una tabla almacenada en la memoria o accesible en una base de datos que es local o remota para encontrar la Identidad de Usuario Pública que corresponde al indicio y que debe usarse en SIP INVITE saliente. En la etapa 36, el UA 10 puede mostrar o proporcionar alguna indicación al usuario de la Identidad de Usuario Pública usada para abordar el dispositivo.

En otras implementaciones, al recibir un mensaje inicial 11, un SCC AS puede almacenar la información recibida en el mensaje de Invitación de I1, incluida la identidad de parte llamada incluida en el elemento de información Para-id, el tipo de privacidad solicitado incluido en el elemento de información de privacidad, el valor de encabezado de secuencia-ID y la información de capa de transporte que identifica la conexión de transporte sobre la que se recibió el mensaje de Invitación de I1 contra la identidad privada IMS del UE del usuario de origen. La identidad privada IMS para almacenar la información se puede determinar comparando la C-MSISDN asociada con la identidad privada IMS con respecto a la cadena de direcciones RDSI de MAP, como se especifica en la TS de 3GPP 29.002 [bb] si la USSD se usa como el protocolo de transporte para el mensaje, o el mensaje Corto de Reenvío MAP sm-RP-OA como se especifica en el elemento de información de 3GPP TS 29.002 [bb] si se usa SMS como protocolo de transporte para el mensaje. Si no se incluyó una encabezado 'De', la Identidad de Usuario Pública predeterminada para la identidad privada IMS asociada con el ID de Llamada puede almacenarse contra 11 INVITE y usarse en cualquier método SIP correspondiente para identificar la Parte A. Si se incluye, el identificador recibido puede mapearse contra las Identidades de Usuario Públicas almacenadas para esa identidad privada IMS asociada con la iD de Llamada. Las identidades públicas de usuario mapeadas recuperadas pueden almacenarse contra INVITE de I1 y usarse en cualquier método SIP correspondiente para identificar la Parte A. Si el campo de encabezado de Solicitud de URI (R-URI) en la solicitud SIP INVITE recibida es la Identidad de Usuario Pública predeterminada para el UA de terminación, entonces el valor de encabezado Para puede no incluirse. Si el R-URI en la solicitud SIP INVITE recibida no es la Identidad de Usuario Pública predeterminada para el UA de terminación, entonces el encabezado Para puede incluirse e incluir un identificador que se mapea a la Identidad de Usuario Pública que coincide con la recibida en el R-URI en la solicitud SIP INVITE.

Existen varios mecanismos de codificación para proporcionar el Indicio con referencia a una Identidad de Usuario Pública dentro de mensajes SIP. Por ejemplo, la Tabla 3 ilustra un mapeo general de la Identidad de Usuario Pública al valor de Indicio o valor de índice. La tabla puede almacenarse en una memoria de un UA o dispositivo de red.

Tabla 3

La Tabla 4 muestra un mensaje SIP ilustrativo que usa este esquema de codificación que incluye un indicio que se refiere a una Identidad de Usuario Pública. En algunos casos, el esquema de codificación puede ajustarse a un URI. El URI puede incluir un esquema de URI tal como hsip o csip o isip. El esquema de URI hsip indica que el fragmento que sigue a “ :” es un valor hash. El esquema de URI csip indica que el fragmento que sigue a “ :” es un valor comprimido, después de algún esquema de compresión mutuamente entendido (los detalles del esquema de compresión pueden intercambiarse usando un Objeto de Gestión de Dispositivo OMA, tal como por ejemplo el IMS MO en 3GPP TS 24.167), y el esquema de URI isip indica el valor que sigue es un mapeo de índice para, por ejemplo, un SIP o tel URI.

Tabla 4

Otra codificación se ejemplifica de la siguiente manera: urn: isip: 12; urn:csip:JeertoE; urn:hsip:34.

La Tabla 5 ilustra un ejemplo de esquema de codificación de mensajes 11.

Tabla 5

Dentro del 11 mensaje ilustrado en la Tabla 5, el campo de encabezado 'De' podría construirse como se ilustra en la Tabla 6.

Tabla 6

Con referencia a la Tabla 6, dentro del campo Longitud, Bit 7 es una bandera para indicar si el encabezado 'De' contiene un valor de indicio. Dentro del campo de Indicio, Bits 0-7 son codificados binarios y la codificación se correlacionaría con el valor de indicio. Los expertos en la materia apreciarán que hay otros métodos de identificación cuando el siguiente octeto contiene un indicio.

En algunas implementaciones, se puede usar una función hash para mapear una Identidad de Usuario Pública particular con un indicio. Si se usa una función hash, la función hash puede configurarse de manera que múltiples entradas no se evalúen al mismo resultado hash o valor hash. Después de ingresar la Identidad de Usuario Pública en la función hash, el valor hash resultante puede usarse para determinar indicios para referirse a las Identidades de Usuario Públicas y puede transmitirse por el UA o dispositivo de red. Por ejemplo, los valores hash pueden clasificarse con el orden resultante que determina que un indicio se asocia con cada Identidad de Usuario Pública.

La Figura 3 es una ilustración de una función hash para convertir a partir de una Identidad de Usuario Pública con un resultado resumen, el resultado hash es más pequeño que la Identidad de Usuario Pública y se usa para determinar un indicio para cada Identidad de Usuario Pública. Con referencia a la Figura 3, se proporcionan Identidades de Usuario Públicas 40 a la función hash 42. La función hash 42 recibe las Identidades de Usuario Públicas e implementa un algoritmo para generar la tabla de hash 44. La tabla de hash 42 asocia cada una de las Identidades de Usuario Públicas recibidas con un valor de hash. Los valores de hash pueden disponerse en orden numérico o alfabético y un indicio se mapea a cada valor de hash y, por lo tanto, a cada Identidad de Usuario Pública. Tanto el remitente como el destinatario implementan la misma función hash y usan el Indicio apropiado para identificar una Identidad de Usuario Pública cuando se comunican.

En una implementación, las Identidades de Usuario Públicas recibidas se disponen en orden alfabético. A continuación, se pueden asignar indicios a las Identidades de Usuario Públicas en orden alfabético. Alternativamente, el valor ASCII para cada parte de la Identidad de Usuario Pública puede convertirse en un número. Los valores numéricos pueden concatenarse y clasificarse numéricamente para clasificar las Identidades de Usuario Públicas y asociarlas con los indicios. Por ejemplo, ABC sería 65667, mientras que abc sería 979899, lo que permite clasificar los resultados numéricos.

Además de simplificar los mensajes codificados SIP mediante el uso de indicios para referirse a las Identidades Públicas de Usuario del UA, otras porciones del mensaje, tales como las que se refieren a las capacidades del UA, también pueden compactarse usando el presente método. En el caso de señalización de Origen Móvil, si el UA decide enviar un procedimiento SIP o un mensaje I1, el UA puede consultar una base de datos, tabla o memoria interna para identificar un mapeo entre un código de características o etiqueta que el UA desea identificar a la red. Después de encontrar el código o etiqueta de características particular, el Ua puede identificar un indicio particular en referencia a esa etiqueta o código de característica y usar el indicio cuando se comunica con la red.

Cuando el SCC AS o nodo de red recibe el método SIP o el mensaje I1, el nodo de red analiza, decodifica o analiza el mensaje y descubre que las etiquetas de características se codifican usando indicios. Tras recibir el mensaje, si el SCC As necesita crear un método SIP a otro punto final, el nodo de red convierte el indicio en un código o etiqueta de características verbosas usando tablas internas que relacionan cada código o etiqueta de características a un indicio particular.

De manera similar, en el caso de una transmisión de terminación móvil, cuando el SCC AS (nodo de red) recibe un método SIP y necesita enviar un mensaje (método I1 o SIP) al UA, el nodo de red analiza las etiquetas de características utilizadas en el mensaje. Usando tablas almacenadas en la memoria del nodo de red, el nodo elige el valor de indicio correcto para referirse a esa etiqueta de características. El nodo de red puede enviar entonces el mensaje que contiene el valor de indicio al UA. En algunos casos, las etiquetas de características pueden incluir etiquetas ICSI e IARA. Cuando el UA recibe el método SIP o el mensaje l l , el UA analiza, decodifica o analiza el mensaje y descubre que las etiquetas de características se codifican como indicios. A continuación, el UA busca los indicios en la memoria para identificar el código de características particular o la etiqueta asociada con los indicios. El UA realiza entonces las funciones necesarias por las especificaciones del 3GPP e IETF para recibir esa etiqueta de características.

En esta implementación, las etiquetas de características y sus respectivos indicios se aprovisionan tanto en el UA como en el nodo de red antes de la comunicación entre el UA y el nodo de red. La Tabla 7 ilustra una estructura de datos de ejemplo para proporcionar las etiquetas de características y sus respectivas indicios que pueden proporcionarse tanto en el UA como en el nodo de red.

Tabla 7

En un mensaje I1 que implementa el presente método, se pueden definir nuevos encabezados - Encabezado Contacto y Encabezado Aceptar Contacto que son similares a los encabezados SIP correspondientes. Por lo tanto, cuando un UA origina un mensaje INVITE de I1, el UA puede incluir los encabezados adicionales como se muestra en la Tabla 8.

Tabla 8

En algunos casos, puede haber un mapeo de bits para cada una de las etiquetas de características, tal como se muestra en la Tabla 9.

Tabla 9

La Tabla 10 ilustra un ejemplo de mensaje 11 configurado de acuerdo con la presente divulgación. Como se muestra, el mensaje tiene la capacidad de proporcionar varias indicios para identificar los códigos de características o etiquetas soportadas por el UA o solicitados por el nodo de red.

Tabla 10

En implementaciones alternativas del mensaje 11, puede haber dos elementos de información para Encabezado de Contacto y Aceptar Contacto. Dentro del encabezado de Contacto, se puede proporcionar una encabezado de contacto SIP que contiene etiquetas de características definidas dentro del IETF, y un encabezado de contacto del 3GPP que contiene etiquetas de características definidas en las especificaciones del 3GPP. Dentro del encabezado Aceptar Contacto, el encabezado de contacto Aceptar SIP contiene etiquetas de características definidas dentro del IETF, y el encabezado de contacto de aceptación de 3GPP contiene etiquetas de características definidas en las especificaciones de 3GPP. En algunos casos también puede haber uno o más encabezados de Rechazar Contacto. El mensaje puede incluir un elemento de información (IE) de Aceptar Contacto que puede incluirse opcionalmente para identificar las etiquetas de características, un IE de ERAceptar Contacto que puede incluirse opcionalmente para identificar etiquetas de características que han sido calificadas con la preferencia de la característica Explicitar o Solicitar y/o Rechazar IE de Contacto que puede incluirse opcionalmente para identificar etiquetas de características que han sido calificadas con la preferencia de la característica Explicitar o Solicitar. Etiquetas adicionales pueden incluir un IE de EAceptar Contacto que puede incluirse opcionalmente si se indican etiquetas de características que han sido calificadas con la etiqueta de parámetros “ explícitar” , y un IE de RAceptar Contacto que puede incluirse opcionalmente si se indican etiquetas de características que han sido calificadas con la etiqueta de parámetros “ solicitar” . La Tabla 12 muestra una implementación de ejemplo del presente sistema donde la tabla identifica a un nivel de protocolo si los elementos de información son obligatorios (M), opcional (O), formato es valor (v), valor de longitud de etiqueta (tlv), valor de etiqueta (TV) o valor de longitud (VL) y una longitud.

SIP permite que “ explícito” o “ requerido” se agregue a una etiqueta de características para identificar cómo debe ser el mapeo. Como se describe a continuación en la Tabla 11, si se requiere que dicho método se comunique a través de un protocolo similar a I1, se puede usar la siguiente codificación:

Tabla 11

Dentro de la T abla 11, Bit 7 del octeto 2, si se establece 1, identifica para esta etiqueta de características se establecen las opciones Explícitas, y Bit 6 del octeto 2, si se establece 1, identifica para esta etiqueta de características se establecen las opciones Requeridas.

La Tabla 12 es una ilustración de otro mensaje codificado por SIP de ejemplo codificado de acuerdo con la presente divulgación.

Tabla 12

Los elementos de información, Aceptar Contacto, ERAceptar Contacto y Rechazar Contacto pueden expandirse adicionalmente como se ilustra en la Tabla 13. Los expertos en la técnica apreciarán que, aunque la tabla muestra un valor para el elemento de información en esta realización, cada elemento de información requerirá un valor separado. Tabla 13

Los elementos de información consisten en un Código de Elemento de Información y un valor específico de Código. Aceptar Contacto, ERAceptar Contacto y Rechazar Contacto podrían ser elementos de información separados como se muestra en la Tabla 14 como se explicó anteriormente o podrían ser todos un elemento de información usando un valor de código de elemento de información donde por el elemento de Información Específica de Código se usa para distinguir entre los diferentes encabezados.

Tabla 14

En la Tabla 15 hay un ejemplo de cómo se ha usado el elemento Específico de Código para definir 5 elementos de información Aceptar Contacto, EAceptar Contacto, RAceptar Contacto, ERAceptar Contacto y Rechazar Contacto.

Tabla 15

Los expertos en la técnica apreciarán que se podría usar una combinación del código de información y los valores específicos de código para definir el número necesario de elementos de información para transportar las etiquetas de características y sus etiquetas de parámetros opcionales “ explícitar” , “ solicitar” , etc.

La Tabla 16 es una ilustración de otro mensaje codificado por SIP de ejemplo codificado de acuerdo con la presente divulgación.

Tabla 16

Dentro del mensaje codificado por SIP de ejemplo ilustrado en la Tabla 16, el valor de etiqueta de característica (ZZZ) o las otras realizaciones mencionadas anteriormente tales como, pero sin limitarse a, la Tabla 13, el cuerpo de elemento de información puede codificarse de acuerdo con la estructura de datos de ejemplo ilustrada en la Tabla 17-Tabla 20.

El UE puede usar el elemento de información de contacto de etiqueta de característica para identificar características del UE que se van a alcanzar cuando los bits de campo específicos de código 3.2.1 toman un valor entre e incluyendo “000” y “011” . Los identificadores de ASN asociados con las etiquetas de características pueden caracterizar el conjunto de características del UE. Las etiquetas de características pueden calificarse agregando etiquetas de opción “explícitas” y “ requeridas” según procedimientos en RFC 3841]. Cuando aparece una etiqueta de característica sin calificador, el elemento de información de etiqueta de característica con los bits de campos específicos de código 3,2, y 1 puede establecerse en “000” y los valores decimales pueden incluirse en el cuerpo de elemento de información. Cuando una etiqueta de característica se califica con la etiqueta de parámetros “ requerir"’, el elemento de información de etiqueta de característica con los bits de campos específicos de código 3,2, y 1 puede establecerse en “001” y los valores decimales pueden incluirse en el cuerpo de elemento de información. Cuando una etiqueta de característica se califica con la etiqueta de parámetro “explícitar” , el elemento de información de etiqueta de característica con los bits de campos específicos de código 3,2, y 1 puede establecerse en “010” y los valores decimales pueden incluirse en el cuerpo de elemento de información. Cuando la etiqueta de característica se califica con la etiqueta de parámetro “ explícitar” y “ requerir” , el elemento de información de etiqueta de característica con los bits de campos específicos de código 3,2, y 1 puede establecerse en “011” y los valores decimales pueden incluirse en el cuerpo de elemento de información. El UE puede usar el elemento de información de contacto de etiqueta de característica para identificar características del UA que deben evitarse cuando los bits de campo específicos de código 3.2.1 se establecen en “ 100” .

El UE puede incluir el elemento de contacto de la etiqueta de función en el mensaje de 11 Invite para indicar cualquiera preferencia de características llamadas por RFC 3841. El IE puede aparecer varias veces dependiendo de si las etiquetas de características deben calificarse con etiquetas de parámetros “ requeridas” y o “ explícitas” o deben identificarse como rechazadas.

Tabla 17

Tabla 18

Tabla 19

Tabla 20

Otra realización sobre cómo codificar las etiquetas de características es tomar los valores decimales de ASN.1 definidos por IANA y codificarse en el elemento de información.

Tabla 21

La Tabla 21 muestra una realización del uso de la codificación IANA ASN donde el árbol IANA se codifica en octetos 2-4. Esta codificación proporciona un mecanismo por el cual si se crean etiquetas de características/medios en el futuro, se pueden transportar en un mecanismo de prueba futuro. El valor decimal de la etiqueta/etiqueta de medios está codificado en el octeto 6-y, cada característica/etiqueta de medios toma un octeto de modo que puede incluirse una lista de ellos.

En una implementación alternativa, otro elemento de información puede definirse de modo que el prefijo de dígitos tenga 8 bits de longitud, esto permite valores en el árbol que tienen un tamaño máximo de 256, por ejemplo, 256.158.192.45.200.180

a a

Dentro del mensaje codificado por SIP de ejemplo ilustrado en la Tabla 16, el valor de etiqueta de característica (YYY) puede codificarse de acuerdo con la estructura de datos de ejemplo ilustrada en la Tabla 24 y las codificaciones de ejemplo proporcionadas en la T abla 25 en, por ejemplo, lo0s elementos Aceptar, ERAceptar o Rechazar Contacto. La codificación puede ser específica de bit, como se ilustra, o puede usar códigos explícitos para valores de mapeo a valores de octetos particulares.

Tabla 24

Tabla 25

Los indicios relacionados con los códigos o etiquetas de características también pueden codificarse según los requisitos de señalización SIP. Si el UA origina una llamada, como parte de la llamada, el UA puede desear incluir una etiqueta de característica en los Encabezados Aceptar Contacto y Contacto. La Tabla 26 muestra cómo puede codificarse un SIP INVITE donde el indicio de etiqueta de característica está subrayado. El mismo concepto se puede aplicar a otros métodos SIP donde tradicionalmente insertarían la etiqueta de la función en su forma verbosa.

Tabla 26

En implementaciones alternativas, puede ser necesario cuando se usan indicios en métodos SIP para incluir una etiqueta característica para identificar que se está utilizando la característica de indicio. Por ejemplo, el siguiente método puede definirse “ 3gpp.indicium= [valores de indicio separados por comas, punto my coma, etc.” . Tal etiqueta de característica puede ser una nueva etiqueta de característica o una existente. Si la etiqueta de características es nueva, la etiqueta puede crearse de acuerdo con los procedimientos definidos en 3GPP y/o IETF y/o IANA.

En otra implementación del presente sistema, en lugar de proporcionar un mapeo predeterminado de valores de mensaje a indicios, el mapeo de indicios puede construirse dinámicamente mientras un UA y un nodo de red se comunican. La Figura 4 ilustra un flujo de mensajes para el registro UA dentro de una red. La Figura 4 también ilustra varias acciones adicionales que tienen lugar en la red para completar el registro. En general, el flujo de mensajes mostrado en la Figura 4 es por diversos estándares, sin embargo, varias etapas dentro del procedimiento están resaltadas como susceptibles a la compactación dinámica de mensajes de acuerdo con la presente divulgación. Por consiguiente, usando el presente método, el flujo de mensajes mostrado en la Figura 4 puede modificarse usando indicios dinámicos para generar un flujo de mensajes más eficiente, lo que da como resultado que se comunique menos información entre el UA y el nodo o nodos de red.

En otras implementaciones, puede ser necesario cuando se usan indicios en mensajes SIP para crear una nueva parte de cuerpo (p. ej., un documento MIME de XML) para su inclusión en mensajes SIP o para mejorar una parte de cuerpo existente tal como el reevento o reginformación.

El siguiente ejemplo ilustra cómo se puede usar el presente sistema para crear dinámicamente indicios para hacer referencia a Identidades de Usuario Públicas y capacidades de UA de SIP dentro de un mensaje codificado por SIP, o un mensaje configurado para transmitirse a través de una interfaz I1. Sin embargo, en otras implementaciones, se pueden generar indicios dinámicas para cualquiera de los elementos de datos contenidos dentro de un mensaje. Por ejemplo, en una implementación específica, todos los elementos de un mensaje que se codifican como elementos de datos de Tipo-valor (TLV) o de valor de longitud (LV) son elegibles para la sustitución con indicios de acuerdo con la presente divulgación. En un elemento de datos codificado por LV, por ejemplo, se proporciona una longitud específica del valor de datos. También se proporciona un valor que puede incluir, por ejemplo, datos ASCII y tiene una longitud igual a la proporcionada en el valor de longitud. El uso de elementos de datos codificados por LV permite un análisis y procesamiento eficientes. Como resultado, varios de los elementos de datos codificados dentro de un mensaje SIP, o un mensaje configurado para transmitirse usando la interfaz I1 pueden codificarse como elementos de datos de tipo TLV o LV.

Con referencia a la Figura 4, en la etapa 50 del diagrama de flujo, el UA 10 ha construido un mensaje de registro para transmitirse a la red. Como parte de ese mensaje de registro, el UA 10 incluye capacidades de llamada. Estas capacidades son reflejadas por etiquetas de características que se adjuntan a los procedimientos de encabezado de contacto por RFC 3840. El UA 10 puede indicar el soporte de la funcionalidad propuesta usando la etiqueta de característica “ 3gpp.indium” o sip.schemes = csip, etc. La etiqueta puede insertarse en el encabezado de contacto de un registro SIP (suscripción SIP, otros métodos de SIP/tipos de mensajes) durante el procedimiento de registro. El UA 10 puede usar un campo de encabezado Solicitar (o solicitante de Proxy) con el valor “ pref” si el UA 10 desea estar seguro de que el SCC AS 52 entiende la extensión.

Después de definir las capacidades de llamada dentro del mensaje de registro, el UA 10 crea un mapeo de indicio que, usando los ejemplos anteriores, puede incluir las dos etiquetas de características incluidas en el mensaje de registro para y tener indicios 1 y 2, respectivamente. Por ejemplo, el mapeo de indicios puede ser el de la Tabla 27. Un experto en la técnica, sin embargo, apreciaría que la numeración podría comenzar en cualquier valor. En esta implementación, el punto de inicio de número y los incrementos de número entre el SCC AS 52 y el UA 10 son los mismos (es decir, los mismos puntos de inicio, con incrementos consistentes).

Tabla 27

Alternativamente, el mapeo entre la etiqueta característica y el valor de indicio puede crearse enviando las etiquetas de características a través de una función hash y luego disponiendo los valores de hash en orden numérico y asignando los indicios a las etiquetas de características en ese orden, como se ha descrito anteriormente para hashear el valor de identidad del usuario público.

Después de construir el mapeo, el UA 10 transmite el mensaje de registro con las indicaciones originales de capacidades de llamada (es decir, no usando los indicios) al nodo de red.

En la etapa 54, el SCC AS 52 recibe un registro de terceros desde el UA 10. Parte del registro podría incluir el mensaje de registro descrito anteriormente. El mensaje puede buscar el que se muestra en la Tabla 28, con las etiquetas de características subrayadas.

Tabla 28

Hab¡endo rec¡b¡do el mensaje en la etapa 54. el SCC AS 52 ahora t¡ene una l¡sta de las capac¡dades del UA 10 y puede constru¡r su prop¡a tabla de mapeo. Deb¡do a que el SCC AS 52 usa el m¡smo algor¡tmo de mapeo para constru¡r una tabla que relac¡ona ¡nd¡c¡os part¡culares con capac¡dades. tanto SCC AS 52 como UA 10 pueden usar los ¡nd¡c¡os cuando se ref¡eren a capac¡dades, m¡n¡m¡zando una cant¡dad de datos que deben transfer¡rse entre el UA 10 y la red. Por ejemplo. el SCC AS 52 puede constru¡r el mapeo mostrado en la Tabla 29. En este momento. el SCC AS 52 y el UA 10 t¡enen los m¡smos valores de ¡nd¡c¡o mapeados a las m¡smas et¡quetas de característ¡cas en las tablas almacenadas en la memor¡a de ambos d¡spos¡t¡vos.

Tabla 29

En la etapa 56. el UA 10 rec¡be un mensaje Notificar que cont¡ene todas las ¡dent¡dades reg¡stradas para ese UA 10. La Tabla 30 es un mensaje de not¡f¡cac¡ón de ejemplo que cont¡ene las ¡dent¡dades reg¡stradas para el UA 10. con las ¡dent¡dades que el UA 10 se conoce estando subrayado.

Tabla 30

Después de recibir el mensaje de notificación, el UA 10 crea una tabla que mapea los valores de indicios a las Identidades de Usuario Públicas recibidas. Como anteriormente, el número de partida para los indicios no es importante, solo que el UA 10 y el SCC AS 52 usan el mismo algoritmo para mapear una identidad particular con un indicio particular. Por ejemplo, la Tabla 31 es una ilustración de una tabla de mapeo de ejemplo que puede generarse por el UA 10 después de recibir el mensaje de notificación ¡lustrado en la Tabla 30.

Tabla 31

Alternativamente, el mapeo entre las Identidades de Usuario Públicas y el valor de indicio puede crearse enviando las identidades de usuario a través de una función de hash y luego disponiendo los valores hash en orden numérico y asignando los indicios en ese orden, como se describió anteriormente. O, como se describió anteriormente, podrían disponerse en orden alfanumérico y los indicios creados mediante el orden.

En algunos casos, el UA 10 no se suscribe al paquete de eventos Reg como se muestra en la etapa 58 de la Figura 4, pero usa la información recibida en la etapa 60 en el URI asociado a P para crear los indicios. También podría añadirse un parámetro o campo. Por ejemplo, el URI asociado a P puede incluir: “ P-Associated-URI: user2_public1@home1.net, URI-index=1, <tel:+358504821437>, URI-index=2.” Donde “ URI-index=” es el parámetro añadido que identifica el valor de indicios.

En la etapa 62, el SCC AS 52 usa el mismo algoritmo que se implementa dentro del UA 10 para construir una tabla de mapeo para relacionar indicios con las Identidades de Usuario Públicas recibidas en el mensaje Notificar. Por ejemplo, el SCC AS 52 construye la tabla de mapeo mostrada en la Tabla 32. Con tanto el UA 10 como el SCC AS 52 que tiene un mapeo definido de indicios a Identidades de Usuario Públicas del UA 10, ambas entidades pueden usar esos valores en lugar de las Identidades de Usuario Públicas cuando se comunican.

Tabla 32

Alternativamente, el mapeo entre las Identidades de Usuario Públicas y los valores de indicios se puede crear enviando las Identidades de Usuario Públicas a través de una función hash y luego disponiendo el valor de hash en orden numérico y asignando los indicios a esa de las Identidades de Usuario Públicas cuando se disponen en ese orden, como se describió anteriormente. O, como se describió anteriormente, podrían disponerse en orden alfanumérico con los indicios que se determinan en función de esa ordenación.

Alternativamente, se podría definir un nuevo parámetro de URI de SIP que se adjunta al URI en un paquete de RegEvento. El URI podría configurarse para identificar el valor de indicio para esa Identidad de Usuario Pública, asegurando que el UA obtiene una indicación explícita de la posición en que el SIP/tel URI debería tomar en su tabla de mapeo de indicio. En una implementación adicional, el UA también puede SIP SUBSCRIBE al paquete de Eventos Reg para sí mismo del SCC AS. Este flujo de información puede ser el mismo que el que se muestra en la Figura 4, pero con el SCC AS que es el punto de terminación para SUBSCRIBE y el originador de NOTIFY al UA. Debido a que el SCC AS ya ha creado una tabla de indicios, el SCC AS puede asegurar que el orden de las Identidades de Usuario Públicas en el mensaje de notificación están en el mismo orden de modo que cuando el UA los recibe, se asignan en consecuencia. Otra forma de implementar lo anterior es usar la función hash en base dinámica, por lo que las Identidades de Usuario Públicas se colocan a través de un algoritmo hash que garantiza que cuando se ordenan los valores hash resultantes, el ordenamiento de las Identidades de Usuario Públicas y los indicios asociados son consistentes.

En una implementación alternativa, después de la etapa 56, el UA 10 puede necesitar determinar si la red (por ejemplo, el nodo de red SCC AS 52) soporta el nuevo esquema de URI que hace uso de indicios. En ese caso, el Ua 10 puede configurarse para enviar una solicitud de OPCIONES SIP a la red. La red puede responder, incluyendo una etiqueta de características sip.extensions que especifica si la red soporta el presente esquema de URI. Si el UA 10 recibe la indicación de que se soporta el esquema de codificación, el UA puede usar el esquema de codificación. Además, en la etapa 64 de la Figura 4, si el SCC AS 52 no recibió una etiqueta de característica, el SCC AS 52 puede enviar una petición de OPCIONES al UA 10 para determinar si se admiten los nuevos esquemas de codificación. La respuesta puede señalizarse de vuelta por el UA 10 mediante el uso de la etiqueta de características sip.extensions.

Con referencia al flujo de mensajes ilustrado en la Figura 4, la generación de los indicios y mapeos puede tener lugar en cualquiera de las etapas enumeradas en el diagrama dados los datos necesarios. Además, con referencia a la etapa 66, después de que el UA 10 y la red hayan establecido la mapeo de indicios, el mapeo puede usarse en los mensajes SIP o I1.

En el ejemplo ilustrado en la Figura 4, se ha mostrado un flujo de mensajes para establecimiento de sesión terminado móvil, sin embargo, se apreciará que se puede iniciar una sesión originada en móvil usando el método de mapeo de indicios actual.

En algún punto durante la comunicación entre el UA 10 y la red, puede ser necesario restablecer los mapas de indicios (por ejemplo, los mapas pueden estar fuera de sincronización). Por consiguiente, en una implementación, el UA puede iniciar una actualización usando la solicitud de registro SIP del UA o solicitud para un método. Alternativamente, cuando el SCC AS o UA desea actualizar la mapeo de indicios, en el siguiente mensaje comunicado entre el SCC AS y el UA, la entidad envía un mensaje que incluye una etiqueta de característica, cuerpo XML o valor de encabezado P que especifica que los valores de indicio deben restablecerse/reiniciarse. Mientras solicita el reinicio, la entidad solicitante puede volver a la codificación original de los datos. Alternativamente, el nuevo elemento de datos puede no estar incluido en un mensaje, de modo que cuando una función (por ejemplo, UAs SIP, UAC) recibe la versión verbosa de los datos (es decir, un mensaje que no usa los indicios y en su lugar usa los valores originales) o una indicación explícita de que el mapeo de indicios debe restablecerse, la entidad destinataria puede configurarse para regenerar los datos de la misma manera que los datos de indicio se generaron originalmente. Sin embargo, en algunos casos, cualquier entidad puede indicar que debe usarse un algoritmo diferente para generar los datos de indicios, u otro nodo o dispositivo de red puede informar a las entidades (por ejemplo, UA y SCC AS) de un nuevo algoritmo para usar. Hasta tal tiempo a medida que se han reconstruido los datos, el diálogo SIP puede continuar usando el esquema verboso.

En algunas redes, la parte llamada o llamada puede direccionarse usando un tel URI o un URI SIP con parámetro SIP URI usuario = teléfono. En otras palabras, la parte puede direccionarse usando un número de teléfono. En una implementación del presente sistema, cuando una función de red recibe dicha dirección, la función está configurada para traducir la dirección en la representación binaria de un número E.164. Por ejemplo, la Figura 5 ilustra un flujo de información de pila en donde el dispositivo diana se direcciona usando tel URI o usuario de SIP = teléfono. Con referencia a la Figura 5, en la etapa 70, si el usuario ha elegido un tel URI o un usuario de SIP = dirección telefónica = dirección telefónica, la dirección se pasa al motor I172. Un motor I1 o máquina de estado 72 toma la entrada que incluye el primer URI de tel o el usuario de SIP = mensaje de teléfono y lo adapta al protocolo I1. El mensaje adaptado se coloca entonces en el transporte 1174. Por consiguiente, en la etapa 72, tras la recepción de un tel URI o el usuario SIP URI = teléfono, el UA codifica los números de acuerdo con las especificaciones existentes. El mensaje puede ser recibido por la red en la etapa 76, pasar al motor I1 78 y comunicarse eventualmente al motor SIP 80. Después de recibir la dirección para el dispositivo diana, el motor SIP 80 puede iniciar transmisiones SIP usando, por ejemplo, protocolo de control de transferencia (TCP) o protocolo de datagramas de usuario (UDP) en la etapa 82.

Como ejemplo, la Tabla 33 ilustra una codificación para el usuario del tel o el usuario de SIP = teléfono que puede realizarse en la etapa 72 de la Figura 5.

Tabla 33

Si, como resultado de analizar el URI del tel o URI SIP con URI “ usuario” o conjunto de parámetros SIP en “ teléfono” , el mensaje incluye un signo “ ” en el número, entonces el número puede codificarse como un tipo de número (TON) internacional y los dígitos pueden codificarse en los dígitos Número del número usando decimal codificado binario (BCD). El indicador del plan de numeración se establecerá como en E.164. Si no se puede descubrir un signo “ ” , el número puede codificarse como TON=desconocido, NPI = desconocido. El tel URI también puede incluir un SCC AS PSI DN-un tel URI o URI SIP con el conjunto de parámetros de URI SIP “ usuario” en “ teléfono” , de acuerdo con 3GPP TS 23.003. En ese caso, el encabezado del SCC AS PSI puede codificarse de acuerdo con la Tabla 34 y el cuerpo puede codificarse de acuerdo con la Tabla 35. Con referencia a la Tabla 34 y la Tabla 35, el o los dígitos del número en el octeto 4 precede al o a los dígitos en el octeto 5, etc. El dígito de número que se ingresaría primero se encuentra en el octeto 4, bits 1 a 4. Además, si el número BCD de la parte llamada contiene un número impar de dígitos, los bits 5 a 8 del último octeto pueden llenarse con una marca final codificada como “ 1111” .

Tabla 34

Tabla 35

En una transmisión originada en móvil, la dirección denominada puede ser un usuario del URI SIP del tel URI = teléfono con dígitos codificados por 3GPP TS 24.008 sección 10.5.4.7 para el campo 'Para' en I1 INVITE. La dirección de llamada puede ser un usuario de URI de SIP del tel URI = teléfono en los dígitos codificados por 3GPP TS 24.008 sección 10.5.4.7 para el campo 'De' en I1 INVITE. En una transmisión terminada en móvil, la dirección denominada puede ser un usuario del URI SIP del tel URI = teléfono codificado por 3GPP TS 24.008 sección 10.5.4.7 para el campo 'Para' en I1 INVITE. La dirección de llamada puede ser un usuario del URI SIP del tel URI = teléfono codificado por 3GPP TS 24.008 sección 10.5.4.7 para el campo 'De' en I1 INVITE.

En una implementación general del presente sistema, todos los datos que tienen un tipo de datos de cadena dentro de un mensaje son elegibles para compactar además de la Identidad de Usuario Pública y las capacidades de UA descritas anteriormente. El presente sistema puede configurarse para sustituir todos los datos que tienen un tipo de datos de cadena en un mensaje de protocolo con un indicio que puede incluir un valor entero, binario, hexadecimal, etc. para reducir el tamaño del mensaje. En una implementación específica, todos los datos dentro de un mensaje SIP o mensaje codificado de tipo SIP son elegibles para su reemplazo con valores de indicio, sin embargo, en algunos casos solo un subconjunto de los datos es elegible. Por ejemplo, en una implementación, solo los datos codificados usando métodos de codificación de LV o TLV están sujetos por reemplazo con indicios de acuerdo con la presente divulgación.

El presente sistema permite un protocolo de aplicación cliente/servidor tal como SIP o I1 para enviar un tipo de datos de cadena optimizado, y/o referencias o indicios a las cadenas, y sincronizar los números de referencia o indicios para cadenas en los lados del Remitente de Cadena y Destinatario de Cadena. En esta descripción, el propio Remitente de Cadena y el Destinatario de Cadena son entidades lógicas del mecanismo propuesto y pueden incluir, por ejemplo, aplicaciones que se ejecutan en un UA y un nodo de red tal como un SCC AS. En algunos casos, una aplicación puede tener múltiples instancias de Remitente y Destinatario de Cadena.

Un Remitente de Cadena, cuando comienza, emite una solicitud de sincronización a un Destinatario de Cadena correspondiente. Después de recibir la solicitud de sincronización, el Destinatario de Cadena verifica la existencia de una tabla de sincronización asociada con la instancia de Remitente de Cadena y, si la tabla existe, envía la tabla de vuelta en la respuesta. Si, sin embargo, la tabla no existe, la respuesta puede contener un valor nulo que indica que la tabla no existe y se ha creado la nueva tabla. La tabla de sincronización es una estructura de datos que puede almacenarse en una memoria en comunicación con el Remitente de Cadena y el Destinatario de Cadena. La tabla vincula los valores de las cadenas con números de referencia o indicios a las cadenas. La tabla de sincronización puede compartirse entre las instancias de Remitente/ Destinatario de Cadena. En algunas implementaciones, la tabla de sincronización que contiene las cadenas y sus indicios asociados se puede aprovisionar previamente en el dispositivo y en la red como se describió anteriormente.

El propio Remitente de Cadena y el Destinatario de Cadena también pueden configurarse para enviar una solicitud de reinicio. La solicitud de reinicio ordena al otro interlocutor que borre contenido de la tabla de sincronización. La solicitud puede resultar en un borrado completo de la tabla de sincronización, o puede especificar que solo los valores particulares, o porciones de la tabla deben borrarse. En respuesta a la solicitud de reinicio, la parte destinataria puede indicar un estado de la operación (por ejemplo, Éxito, Fallo, Desconocido, etc.).

La Figura 6 es una ilustración de un flujo de mensajes de ejemplo para optimizar las comunicaciones de cadena entre un Remitente de Cadena y una entidad Destinataria de Cadena. En una primera etapa 100, el Cliente de AP 101 (en este caso, un Remitente de Cadena) se prepara para enviar un mensaje a un Destinatario de Cadena. El Cliente del AP 101 puede incluir, por ejemplo, una aplicación que se ejecuta en un UA o nodo de red, tal como un SCC AS. El mensaje incluye varias cadenas que pueden ser idóneas para la optimización reemplazando las cadenas con indicios. El Cliente del AP 101 pasa a través de cada cadena para determinar si es elegible para la compresión. Por ejemplo, en la etapa 102, el Cliente del AP 101 puede comprobar si un primer valor de cadena contenido dentro del mensaje ya está descrito en la tabla de sincronización del Cliente del Ap . En este ejemplo, el mensaje incluye un valor de cadena “ Esto es una cadena” que no se encuentra en la tabla de sincronización. En la etapa 104, el Cliente del AP 101 también determina que el valor de la cadena se transmite con frecuencia y que el valor de la cadena es adecuado para la optimización. Por consiguiente, en la etapa 106, el Cliente de AP 101 ordena a la tabla de sincronización que almacene el valor de cadena “ Esto es una cadena” . Al valor de la cadena se asigna un valor de referencia o indicio dentro de la tabla de sincronización. Después de transmitir el mensaje que almacena el valor de cadena en la tabla de sincronización, el Cliente del AP 101 recupera un número de referencia o indicio para ese valor de cadena a partir de la tabla de sincronización.

La Tabla 36 ilustra una parte de una tabla de sincronización de ejemplo que almacena una cadena y un número de referencia o indicio asociado con esa cadena que puede ser accesible al Cliente del AP 101. Usando la tabla de sincronización, un Cliente del AP, en lugar de transmitir un valor de cadena que ya está almacenado en la tabla, puede transmitir solo el número de referencia o indicio (suponiendo que el destinatario tiene un registro que asocia la cadena correcta con el número de referencia o indicio).

Tabla 36

En la etapa 108, el Cliente del AP 101 envía un mensaje al Servidor del AP 103 (Destinatario de Cadena) y, en el mensaje, identifica la cadena como un candidato para la optimización. El Servidor del AP 103 puede incluir, por ejemplo, una aplicación que se ejecuta en un UA o nodo de red, tal como un SCC AS. Además de los datos de cadena en sí, el Cliente del AP 101 transmite el número de referencia o indicio (000A) que se usará en lugar de la cadena en futuras transmisiones. El número de referencia o indicio puede adjuntarse a la cadena, incluida como una parte de las encabezados o el cuerpo del mensaje, enviar fuera de banda (por ejemplo, usando otro protocolo y/o una portadora diferente), o transmitirse usando otras opciones (por ejemplo, en el protocolo HTTP).

En la etapa 110, el Servidor del AP 103 recupera el mensaje, determina que el mensaje incluye una cadena y que se ha proporcionado un indicio para esa cadena, y almacena la cadena e indicio a su propia tabla de sincronización, como se muestra en la Tabla 37.

Tabla 37

En este momento, tanto las tablas de sincronización de Cliente 101 como de Servidor 103 están sincronizadas y han almacenado los mismos pares de cadena/indicio. En la etapa 112, el servidor del AP genera una respuesta al mensaje recibido del Cliente del AP. En la respuesta, el servidor del AP 103 puede indicar si la operación de sincronización fue exitosa. El cliente del AP 101, al recibir la respuesta, puede verificar el estado de la operación y, si la operación falló, el cliente del AP 101 puede eliminar la cadena de su tabla de sincronización.

En la etapa 114, el Cliente del AP 101 se prepara para enviar un mensaje que incluye la misma cadena (por ejemplo, “ Esto es una cadena” ) que se almacenó originalmente en la tabla de sincronización en la etapa 106. Nota: la etapa 114 puede ocurrir algún tiempo después de que las cadenas se almacenaron originalmente en la tabla de sincronización - muchos otros mensajes pueden haberse transmitido entre el Cliente del AP 101 y el Servidor del AP 103 entre las etapas 106 y 114 ilustradas en la Figura 6. En la etapa 116, el Cliente del AP 101 busca el valor de cadena en la tabla de sincronización y en la etapa 118 inserta el número de referencia o indicio que corresponde a la cadena en el mensaje. El mensaje se envía entonces al Servidor del AP 103. En este ejemplo, el tamaño del número de referencia o indicio en el mensaje es 2 bytes.

En la etapa 120, el Servidor del AP 103 recibe el mensaje y el número de referencia o indicio, y verifica si el número de referencia o indicio ya existe en la tabla de sincronización. En el ejemplo, se encuentra el número de referencia o indicio. En la etapa 122, el Servidor del AP 103 recupera el valor de cadena que corresponde al número de referencia o indicio y reemplaza el número de referencia o indicio con el valor de cadena.

Usando el procedimiento ilustrado en la Figura 6, el contenido de un mensaje tal como un mensaje codificado de tipo SIP puede compactarse y transmitirse de manera más eficiente entre uno o más componentes de una red de comunicaciones inalámbricas. La Tabla 38 ilustra un ejemplo de mensaje codificado de tipo SIP antes de ser compactado usando el método ilustrado en la Figura 6. El mensaje de ejemplo tiene un tamaño de 449 bytes.

Tabla 38

La Tabla 39 ilustra un mensaje codificado de tipo SIP ilustrativo que se ha compactado usando el método ilustrado en la Figura 6. Varias de las cadenas contenidas dentro del mensaje se han reemplazado con indicios o números de referencia que son más cortas que las cadenas originales. El tamaño del mensaje compactado de ejemplo es solo 94 bytes - una reducción en tamaño del 79 %.

Tabla 39

En consecuencia, en varias implementaciones del presente sistema, si un SICS que puede usar la interfaz I1 se registra con el subsistema CN IMS, el UA puede asociar claves con Identidades de Usuario Públicas. Puede derivarse una Identidad de Usuario Pública si al menos una clave está asociada con una Identidad de Usuario Pública. Cuando un UE establece un canal de control de sesión usando el 11 punto de referencia o cuando un UE genera, por ejemplo, un mensaje de invitación de I1, el mensaje I1 incluye un valor de IE (por ejemplo, el IE de id. de encabezado 'De') que incluye un valor de la siguiente manera. Si la identidad pública indica la Identidad de Usuario Pública predeterminada, el valor se establece en el IE de Información de Identidad (ver Tabla 42) El IE Específico de Código se establece en No Especificado (ver Tabla 43) y la longitud IE se establece en 0. Si existe una solicitud SIP INVITE correlacionada y la identidad pública indica la Identidad de Usuario Pública usada en la solicitud SIP INVITE correlacionada, el IE de Información de Identidad (véase la T abla 42) IE Específica de Código se establece para indicar que la identidad pública se recupera de una sesión SIP correspondiente o una solicitud SIP INVITE correlacionada. Por ejemplo, cuando se indica que la identidad pública se recupera de una sesión SIP correspondiente o una solicitud SIP INVITE correlacionada, la información IE de Información de Identidad (ver Tabla 42) de IE Específica de Código puede establecerse para indicar No Especificado (ver Tabla 43) y la longitud IE se establece en 1 y el octeto se establece a 0” . Si la identidad pública no es la Identidad de Usuario Pública predeterminada y se puede derivar la Identidad de Usuario Pública indicada, el sistema establece el valor en la Información de Identidad (IE) (ver Tabla 42) El IE Específico de Código se establece en identificador (ver Tabla 43) y la longitud IE se establece en la longitud de la clave. Si no se puede derivar un identificador, establecer el IE de Información de Identidad (véase la Tabla 42) IE Específica de Código se establece en un URI SIP (véase la Tabla 43) o un número internacional E.164 (véase la Tabla 43), y será utilizado por el SCC AS para identificar el UE ICS.

Tabla 40

Tabla 41

Si un UE de ICS recibe un mensaje de 11 Invite del SCC AS y el UE determina que no existe sesión I1 para el valor de identificador de llamada recibido, el UE de ICS puede funcionar de acuerdo con las siguientes reglas. Si el valor de encabezado 'Para' (véase la Tabla 41) en el mensaje de I1 Invite como codificado por una Identidad de Información IE (ver Tabla 42) contiene el elemento de Información Específica de Código establecido a No Especificado (ver Tabla 43) y un IE de longitud establecido en 0, entonces la identidad de usuario pública puede establecerse en la Identidad de Usuario Pública predeterminada. Si el valor del encabezado 'Para' (ver Tabla 41) en el mensaje de I1 Invite como codificado por una Información de Información IE (ver Tabla 42) contiene el elemento de Información Específica de Código establecido a no especificado (ver Tabla 43) y la longitud IE se establece en 1 y el octeto 3 se establece totalmente a “ 0” , entonces la Identidad de Usuario Pública del UE puede establecerse en la Identidad de Usuario Pública usada en la solicitud SIP INVITE correlacionada. Por ejemplo, si existe una solicitud de INVITE SIP correlacionada y la identidad pública indica la Identidad de Usuario Pública usada en la solicitud SIP INVITE correlacionada, el IE de Información de Identidad (véase la Tabla 42) IE Específica de Código se establece para indicar que la identidad pública se recupera de una sesión SIP correspondiente o una solicitud SIP INVITE correlacionada. Cuando se indica que la identidad pública se recupera de una sesión SIP correspondiente o una solicitud SIP INVITE correlacionada, la información IE de Información de Identidad (ver Tabla 42) IE Específica de Código puede establecerse para indicar no especificado (ver Tabla 43) y la longitud IE se establece en 1 y el octeto se establece todo en “ 0” . Si el valor de encabezado 'Para' (véase la Tabla 41) en el mensaje de 11 Invite como codificado por un IE de Información de Identidad (véase la Tabla 42) contiene el elemento de información específica de código establecido en “ identificador” (véase la Tabla 43) y un IE de longitud establecido en 4 u otro valor apropiado, entonces la Identidad de Usuario Pública puede derivarse y puede establecerse en el valor de identificador recibido en el cuerpo de elemento de información del encabezado 'Para'. Si el valor de encabezado 'Para' (véase la Tabla 41) en el mensaje I1 Invite como codificado por un IE de Información de Identidad (véase la tabla 42) contiene el elemento de Información Específica de Código establecido en el número internacional (véase la tabla 43) o el URI de SIP (véase la tabla 43), entonces la Identidad de Usuario Pública del UE puede establecerse en la identidad en el cuerpo del elemento de información del valor de encabezado 'Para'. Obsérvese que el UE puede indicar la Identidad de Usuario Pública usada para abordar el UE en la sesión entrante al usuario.

Tras recibir un mensaje inicial 11 Invite desde el UE de ICS a través del punto de referencia I1, el SCC AS puede almacenar la información recibida en el mensaje I1 Invite. En ese caso, la información recibida en el mensaje I1 puede guardarse con un abonado en el nodo de red, por ejemplo, el SCC AS. En una realización, la capa de transporte contiene una Identidad de Usuario Pública tal como un mSiSDN, C-MSISDN, URI de SIP o Tel URI. Como el perfil de abonado recuperado del HSS contiene las Identidades de Usuario Públicas relevantes, el mensaje de I1 entrante puede correlacionarse con los perfiles de abonado y puede identificarse el perfil correcto. Por ejemplo, una C-MSISDN puede usarse como Identidad de Usuario Pública en el protocolo de capa de transporte (p. ej., en el servicio de MAP RDSI Cadena de Dirección RDSI como se especifica en TS 29.002 de 3GPP si la USSD se usa como protocolo de transporte para el mensaje, o el mensaje de mensaje Corto de Reenvío MAP-RP-OA como se especifica en el elemento de información de TS 29.002 de 3GPP si SMS se usa como protocolo de transporte para el mensaje). Elementos de información similares pueden estar presentes en otros protocolos de transporte que se usan para comunicar el mensaje I1 al SCC AS. El MSISDN puede correlacionarse entonces con las MSSISDs que se han almacenado contra el perfil de abonado descargado desde el HSS al SCC AS. Como el MSISDN generalmente es único en el dominio cS, el MSISDN puede usarse para correlacionar el mensaje entrante con perfiles de abonado. Los datos recibidos en el mensaje 11 pueden almacenarse entonces contra el perfil de abonado correcto. En ese caso, el perfil de abonado puede identificarse por la identidad privada de abonado que es una identidad privada IMS o IMSI.

Si el valor del encabezado 'De' (ver Tabla 40) en el mensaje de Invitación de I1 como codificado por una Información de Información IE (ver Tabla 42) contiene el elemento de Información Específica de Código se establece en no especificado (ver Tabla 43) y la longitud IE se establece en 0 la Identidad de Usuario Pública predeterminada puede almacenarse contra 11 Invite. Si el valor del encabezado 'De' (ver Tabla 40) en el mensaje I1 Invite como codificado por una Información de Identidad IE (ver Tabla 42) contiene el elemento de Información Específica de Código se establece en No Especificado (ver Tabla 43) y la longitud IE se establece en 1 y el octeto 3 se establece en su totalidad a “ 0” , entonces la Identidad de Usuario Pública del UE puede establecerse en la Identidad de Usuario Pública usada en la solicitud SIP INVITE correlacionada. Si el valor del encabezado 'De' (ver Tabla 40) en el mensaje I1 Invite como codificado por un IE de Información de Identidad (ver Tabla 42) contiene el elemento de Información Específica de Código se establece en identificador (ver Tabla 43) y la longitud IE se establece en 1, el identificador recibido como se deriva en el párrafo 00120, por ejemplo, puede almacenarse contra I1 Invite. Si el valor del encabezado 'De' (véase la Tabla 40) en el mensaje I1 Invite como codificado por un IE de Información de Identidad (véase la Tabla 42) contiene el elemento de Información Específica de Código se establece para establecer el número internacional o URI de SIP, la identidad contenida en el cuerpo del elemento de información del valor de encabezado 'Para' puede almacenarse contra el I1 Invite.

Si el R-URI en una solicitud SIP INVITE recibida es la Identidad de Usuario Pública predeterminada obtenida en el párrafo 00120, por ejemplo, para el UE de terminación, entonces el IE de Información de Identidad (ver Tabla 42) puede establecerse el elemento de Información Específica de Código No Especificado (véase la Tabla 43) y la longitud IE se establece en 0. Sin embargo, si el R-URI en una solicitud SIP INVITE recibida es la Identidad de Usuario Pública del UE usada en la solicitud SIP INVITE correlacionada, la Información de Identidad IE (ver Tabla 42), elemento de Información Específica de Código puede establecerse en No Especificado (véase la Tabla 43) y la longitud IE se establece en 1 y el octeto 3 se establece en totalmente en “ 0” . Si el R-URI en una solicitud SIP INVITE recibida no es la Identidad de Usuario Pública predeterminada para el UE de terminación, sino que coincide con una de las Identidades de Usuario Públicas, entonces el elemento de Información Específica de Código IE (véase la Tabla 42) puede establecerse el elemento de Información Específica de Código para el identificador (véase la Tabla 43) y el IE de longitud puede establecerse en 1 y el cuerpo de elemento de información del encabezado 'Para' puede ser el valor del identificador que se derivó (véase el párrafo 00120 por ejemplo) y se mapea a la Identidad de Usuario Pública que se recibió en el R-URI en la solicitud SIP INVITE.

En el presente sistema, la Información de Identidad especifica una Identidad de Usuario Pública tal como la identidad del usuario que llama, por ejemplo, el número de la parte que llama (en ese caso, el elemento de información 'De'-id puede contenerse ya sea como un E.164, identificador o un URI de SIP), o la identidad del usuario llamado, por ejemplo, el número de la parte llamada. El elemento de Información de Identidad puede contener un E.164, un URI de SIP o un identificador que identifica una Identidad de Usuario Pública que se usará (véase el párrafo 00120 por ejemplo). La posición del elemento de información en el mensaje y la dirección que se recibió se recibió en identifica si el elemento es la identidad de la llamada o la de las partes de la llamada.

El elemento de información SCC-AS-id (véase, por ejemplo, la Tabla 45) puede contener un URI que incluye una representación de número internacional E.164 del SCC AS PSI DN que apunta al SCC AS. Cuando el UE configura una conexión de portadora CS enviando un mensaje de configuración al servidor MSC, el UE especifica el respectivo URI Internacional E.164 como el número de la parte llamada. Posteriormente, la llamada se enrutará al SCC AS respectivo a través de una MGCF donde el SCC AS PSI se tratará como un PSI comodín como se especifica en 3GPP TS 23.003 [cc] subcláusula 13.5 en la red IMS.

En el presente sistema, el elemento de información de Información de Identidad puede usarse para transportar una identidad pública, por ejemplo, 'Para' Parte, 'De' Parte, etc. El elemento de información de Información de Identidad puede contener un URI de SIP o un número de teléfono (por ejemplo, número internacional, número nacional) o un valor de identificador que identifica una identidad pública conocida. El campo específico de Código, es decir, los bits 3, 2 y 1 del número de octeto 1 especifican el tipo de información contenida en el elemento de información de Información de Identidad.

Si la Información de Identidad a usar es un tel URI o un URI SIP con el usuario del parámetro URI = teléfono, entonces los bits de campos específicos de código 3,2, Y 1 se establecerán en “ 001” Y la identidad deberá codificarse por subcláusula 7.3.2.Y.3. Si un URI de tel o SIP se identifica como globalmente único identificado por la presencia de carácter “ ” al inicio de la cadena de dígitos, el tipo de Número puede considerarse en formato internacional. La identificación del Plan de numeración se puede establecer en E.164. Todos los demás formatos pueden considerarse desconocidos y el tipo de Número debe establecerse para desconocido y el plan de numeración desconocido.

Si la Información de Identidad es un username@domainname de URI de URI, los bits de campos específicos de Código 3, 2 y 1 pueden establecerse en “ 010” y pueden codificarse a una cadena de octetos de acuerdo con las reglas de codificación UTF-8 como se especifica en IETF RFC 3629.

La Tabla 42 ilustra un ejemplo de elemento de información de Información de Identidad.

Tabla 42

La tabla 43 ilustra un ejemplo de elemento de información de Información de Identidad.

Tabla 43

En el presente sistema, el elemento de información SCC-AS-id puede contener una representación de número internacional E.164 del SCC AS PSI DN que apunta al SCC AS. El elemento de información de SCC AS PSI DN puede tener una longitud mínima de 3 octetos y una longitud máxima de 10 octetos.

La Tabla 44 ilustra un formato de encabezado de ejemplo para el elemento de información SCC-AS-id.

Tabla 44

La tabla 45 ilustra un formato de elemento de información de encabezado de SCC AS PSI DN de ejemplo.

Tabla 45

En general, con referencia a la Tabla 45, el dígito o dígitos del número en el octeto 4 precede al dígito o dígitos en el octeto 5, etc. El dígito del número que se ingresaría primero se encuentra en el octeto 4, bits 1 a 4. Si el número BCD de la parte llamada contiene un número impar de cifras, los bits 5 a 8 del último octeto pueden completarse con una marca de fin codificada como “ 1111” .

En el presente sistema, generalmente, un UE y un SCC AS mantienen una tabla de hash que asocia claves con valores. Las claves pueden ser hasheadas lo que resultan de aplicar una función hash a los valores de cadena. SHA-1 puede usarse como el algoritmo hash. El UE y el SCC AS pueden tener una o más tablas que asocian claves con valores. El UE y el SCC AS pueden crear una tabla de hash de los URI presentes en el campo de encabezado de URI de P. Si el UE y el SCC AS también se suscriben al paquete de Reg-Evento como documentado en 3GPP TS 24.229, el UE y el SCC AS pueden crear una tabla de hash de los GRUU para URI recibidos en el paquete de Reg-Evento además de los recibidos en el campo de encabezado de URI asociado a P. Obsérvese que la respuesta 200 (OK) a una solicitud de REGISTRO entrante puede incluir un campo de encabezado de URI Asociado a P y puede ser entregado al SCC AS como parte de los procedimientos de registro de terceros documentados en 3GPP TS 24.229.

La Figura 7 ilustra un sistema de comunicaciones inalámbricas que incluye una realización del UA 10. El UA 10 es operable para implementar aspectos de la divulgación, pero la divulgación no debe limitarse a estas implementaciones. Aunque se ilustra como un teléfono móvil, el UA 10 puede tomar diversas formas que incluyen un auricular inalámbrico, un buscapersonas, un asistente digital personal (PDA), un ordenador portátil, una tableta, un ordenador portátil. Muchos dispositivos adecuados combinan algunas o todas estas funciones. En algunas realizaciones de la divulgación, el UA 10 no es un dispositivo informático de propósito general como un ordenador portátil, portátil o tableta, sino que es un dispositivo de comunicaciones de propósito especial tal como un teléfono móvil, un auricular inalámbrico, un buscapersonas, un PDA o un dispositivo de telecomunicaciones instalado en un vehículo. El UA 10 también puede ser un dispositivo, incluir un dispositivo, o estar incluido en un dispositivo que tiene capacidades similares pero que no es transportable, tal como un ordenador de sobremesa, un decodificador o un nodo de red. El UA 10 puede admitir actividades especializadas tales como juegos, control de inventario, control de trabajo y/o funciones de gestión de tareas, etc.

El UA 10 incluye una pantalla 702. El UA 10 también incluye una superficie sensible al tacto, un teclado u otras teclas de entrada generalmente denominadas 704 para entrada por un usuario. El teclado puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY y tipos secuenciales, o un teclado numérico tradicional con letras alfabéticas asociadas con un teclado telefónico. Las teclas de entrada pueden incluir una rueda de seguimiento, una tecla de salida o escape, una bola de seguimiento y otras teclas funcionales o de navegación, que pueden presionarse hacia adentro para proporcionar una función de entrada adicional. El UA 10 puede presentar opciones para que el usuario seleccione, controles para el usuario para accionar, y/o cursores u otros indicadores para que el usuario dirija.

El UA 10 puede aceptar además la entrada de datos del usuario, incluyendo números para marcar o diversos valores de parámetros para configurar el funcionamiento del UA 10. El UA 10 puede ejecutar además una o más aplicaciones de software o firmware en respuesta a comandos de usuario. Estas aplicaciones pueden configurar el Ua 10 para realizar diversas funciones personalizadas en respuesta a la interacción del usuario. Adicionalmente, el UA 10 puede programarse y/o configurarse sobre el aire, por ejemplo desde una estación base inalámbrica, un punto de acceso inalámbrico o un UA compañero 10.

Entre las diversas aplicaciones ejecutables por el UA 10 hay un navegador web, que permite que la pantalla 702 muestre una página web. La página web puede obtenerse a través de comunicaciones inalámbricas con un nodo de acceso a red inalámbrica, una torre de celdas, un UA 10 par o cualquier otra red o sistema 700 de comunicación inalámbrica. La red 700 está acoplada a una red cableada 708, tal como Internet. A través del enlace inalámbrico y la red cableada, el UA 10 tiene acceso a información en varios servidores, tal como un servidor 710. El servidor 710 puede proporcionar contenido que puede mostrarse en la pantalla 702. Alternativamente, el UA 10 puede acceder a la red 700 a través de un UA 10 par que actúa como un intermediario, en un tipo de retransmisión o de tipo de salto.

La Figura 8 muestra un diagrama de bloques de un UA 10. Si bien se representa una variedad de componentes conocidos de los UA 110, en una realización, se puede incluir un subconjunto de los componentes enumerados y/o componentes adicionales no enumerados en el UA 10. El UA 10 incluye un procesador de señal digital (DSP) 802 y una memoria 804. Como se muestra, el UA 10 puede incluir además una antena y una unidad de extremo frontal 806, un transceptor de radiofrecuencia (RF) 808, una unidad de procesamiento de banda base analógica 810, un micrófono 812, un altavoz de auricular 814, un puerto de auricular 816, una interfaz de entrada/salida 818, una tarjeta de memoria extraíble 820, un puerto de bus serie universal (USB) 822, un subsistema de comunicación inalámbrica de corto alcance 824, una alerta 826, un teclado 828, una pantalla de cristal líquido (LCD), que puede incluir una superficie sensible al tacto 830, un controlador LCD 832, una cámara de dispositivo de carga acoplada (CCD) 834, un controlador de cámara 836 y un sensor de sistema de posicionamiento global (GPS) 838. En una realización, el UA 10 puede incluir otro tipo de pantalla que no proporciona una pantalla sensible al tacto. En una realización, el DSP 802 puede comunicarse directamente con la memoria 804 sin pasar a través de la interfaz de entrada/salida 818.

El DSP 802 o alguna otra forma de controlador o unidad central de procesamiento opera para controlar los diversos componentes del UA 10 de acuerdo con el software integrado o firmware almacenado en la memoria 804 o almacenado en la memoria contenida dentro del propio DSP 802. Además del software o firmware integrado, el DSP 802 puede ejecutar otras aplicaciones almacenadas en la memoria 804 o realizadas a través de medios de soporte de información tales como medios portátiles de almacenamiento de datos como la tarjeta de memoria extraíble 820 o mediante comunicaciones de red cableadas o inalámbricas. El software de aplicación puede comprender un conjunto compilado de instrucciones legibles por máquina que configuran el DSP 802 para proporcionar la funcionalidad deseada, o el software de aplicación puede ser instrucciones de software de alto nivel para ser procesadas por un intérprete o compilador para configurar indirectamente el DSP 802.

La antena y la unidad de extremo frontal 806 pueden proporcionarse para convertir entre señales inalámbricas y señales eléctricas, lo que permite que el UA 10 envíe y reciba información de una red celular o alguna otra red de comunicaciones inalámbricas disponible o de un UA compañero 10. En una realización, la antena y la unidad de extremo frontal 806 pueden incluir múltiples antenas para soportar la formación de haces y/o las operaciones de múltiples entradas y múltiples salidas (MIMO). Como es conocido por los expertos en la técnica, las operaciones MIMO pueden proporcionar diversidad espacial que puede usarse para superar las condiciones de canal difíciles y/o aumentar el rendimiento del canal. La antena y la unidad de extremo frontal 806 pueden incluir componentes de sintonización de antena y/o adaptación de impedancia, amplificadores de potencia de RF y/o amplificadores de bajo ruido.

El transceptor de RF 808 proporciona desplazamiento de frecuencia, convirtiendo las señales de RF recibidas a banda base y convirtiendo las señales de transmisión de banda base a RF. En algunas descripciones, se puede entender que un transceptor de radio o transceptor de RF incluye otra funcionalidad de procesamiento de señales, tal como modulación/demodulación, codificación/decodificación, intercalación/desintercalado, ensanchamiento/despropagación, transformación rápida de Fourier inversa (IFFT)/transformación rápida de Fourier (FFT), anexado/eliminación de prefijo cíclico, y otras funciones de procesamiento de señales. Para fines de claridad, la descripción aquí separa la descripción de este procesamiento de señal de la etapa de RF y/o radio y asigna conceptualmente ese procesamiento de señal a la unidad de procesamiento de banda base analógica 810 y/o el DSP 802 u otra unidad central de procesamiento. En algunas realizaciones, el transceptor de RF 808, partes de la antena y el extremo frontal 806, y la unidad de procesamiento de banda base analógica 810 pueden combinarse en una o más unidades de procesamiento y/o circuitos integrados específicos de aplicación (ASIC).

La unidad de procesamiento de banda base analógica 810 puede proporcionar diversos procesos analógicos de entradas y salidas, por ejemplo procesamiento analógico de entradas del micrófono 812 y el auricular 816 y salidas al auricular 814 y el audífono 816. Para ese fin, la unidad de procesamiento de banda base analógica 810 puede tener puertos para conectarse al micrófono incorporado 812 y al altavoz de auricular 814 que permiten que el UA 10 se use como un teléfono celular. La unidad de procesamiento de banda base analógica 810 puede incluir además un puerto para conectarse a un auricular u otra configuración de micrófono y altavoz manos libres. La unidad de procesamiento de banda base analógica 810 puede proporcionar conversión de digital a analógico en una dirección de señal y conversión de analógico a digital en la dirección de señal opuesta. En algunas realizaciones, al menos parte de la funcionalidad de la unidad de procesamiento de banda base analógica 810 puede ser proporcionada por componentes de procesamiento digital, por ejemplo, por el DSP 802 o por otras unidades centrales de procesamiento.

El DSP 802 puede realizar modulación/demodulación, codificación/decodificación, intercalación/desintercalado, ensanchamiento/despropagación, transformación rápida de Fourier inversa (IFFT)/transformación rápida de Fourier (FFT), anexado/eliminación de prefijo cíclico, y otras funciones de procesamiento de señal asociadas con comunicaciones inalámbricas. En una realización, por ejemplo en una aplicación de tecnología de acceso múltiple por división de código (CDMA), para una función de transmisor el DSP 802 puede realizar la modulación, codificación, intercalado y propagación, y para una función de destinatario el DSP 802 puede realizar desensanchado, desintercalado, decodificación y demodulación. En otra realización, por ejemplo, en una aplicación de tecnología de acceso múltiple por división de frecuencia ortogonal (OFDMA), para la función del transmisor, el DSP 802 puede realizar la modulación, codificación, intercalado, transformación rápida inversa de Fourier y anexado cíclico de prefijo, y para una función de destinatario el DSP 802 puede realizar la eliminación de prefijo cíclico, transformación rápida de Fourier, desintercalado, decodificación y demodulación. En otras aplicaciones de tecnología inalámbrica, el DSP 802 puede realizar otras funciones de procesamiento de señal y combinaciones de funciones de procesamiento de señales.

El DSP 802 puede comunicarse con una red inalámbrica a través de la unidad 810 de procesamiento de banda base analógica. En algunas realizaciones, la comunicación puede proporcionar conectividad a Internet, que permite a un usuario obtener acceso al contenido en Internet y enviar y recibir correo electrónico o mensajes de texto. La interfaz de entrada/salida 818 interconecta el DSP 802 y varias memorias e interfaces. La memoria 804 y la tarjeta de memoria extraíble 820 pueden proporcionar software y datos para configurar el funcionamiento del DSP 802. Entre las interfaces puede ser la interfaz USB 822 y el subsistema de comunicación inalámbrica de corto alcance 824. La interfaz USB 822 puede usarse para cargar el UA 10 y también puede permitir que el UA 10 funcione como un dispositivo periférico para intercambiar información con un ordenador personal u otro sistema informático. El subsistema de comunicación inalámbrica de corto alcance 824 puede incluir un puerto infrarrojo, una interfaz Bluetooth, una interfaz inalámbrica compatible con IEEE 802.11 o cualquier otro subsistema de comunicación inalámbrica de corto alcance, que puede permitir que el UA 10 se comunique de forma inalámbrica con otros dispositivos móviles cercanos y/o estaciones base inalámbricas.

La interfaz de entrada/salida 818 puede conectar además el DSP 802 a la alerta 826 que, cuando se activa, hace que el UA 10 proporcione un aviso al usuario, por ejemplo, sonando, tocando una melodía o vibrando. La alerta 826 puede servir como un mecanismo para alertar al usuario de cualquiera de diversos eventos, tal como una llamada entrante, un nuevo mensaje de texto y un recordatorio de cita vibrando silenciosamente, o tocando una melodía preasignada específica para una persona que llama en particular.

El teclado 828 se acopla al DSP 802 a través de la interfaz 818 para proporcionar un mecanismo para que el usuario realice selecciones, introduzca información y proporcione de otro modo una entrada al UA 10. El teclado 828 puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY y tipos secuenciales, o un teclado numérico tradicional con letras alfabéticas asociadas con un teclado telefónico. Las teclas de entrada pueden incluir una rueda de seguimiento, una tecla de salida o escape, una bola de seguimiento y otras teclas funcionales o de navegación, que pueden presionarse hacia adentro para proporcionar una función de entrada adicional. Otro mecanismo de entrada puede ser el LCD 830, que puede incluir capacidad de pantalla táctil y también visualizar texto y/o gráficos al usuario. El controlador LCD 832 acopla el DSP 802 al LCD 830.

La cámara CCD 834, si está equipada, permite que el UA 10 tome imágenes digitales. El DSP 802 se comunica con la cámara CCD 834 a través del controlador de cámara 836. En otra realización, se puede emplear una cámara que funciona de acuerdo con una tecnología distinta de las cámaras de dispositivo de carga acoplada. El sensor de GPS 838 está acoplado al DSP 802 para decodificar señales de sistema de posicionamiento global, permitiendo así que el UA 10 determine su posición. También pueden incluirse diversos otros periféricos para proporcionar funciones adicionales, por ejemplo, recepción de radio y televisión.

La Figura 9 ilustra un entorno 902 de software que puede implementarse por el DSP 802. El DSP 802 ejecuta controladores del sistema operativo 904 que proporcionan una plataforma a partir de la cual funciona el resto del software. Los controladores de sistema operativo 904 proporcionan controladores para el hardware de UA con interfaces estandarizadas que son accesibles para el software de aplicación. Los controladores del sistema operativo 904 incluyen servicios de gestión de aplicaciones (“AMS” ) 906 que transfieren el control entre aplicaciones que se ejecutan en el UA 10. También se muestra en la Figura 9 una aplicación de navegador web 908, una aplicación de reproductor de medios y applets de Java 912. La aplicación del navegador web 908 configura el UA 10 para operar como un navegador web, permitiendo que un usuario introduzca información en formas y seleccione enlaces para recuperar y ver páginas web. La aplicación del reproductor de medios 910 configura el UA 10 para recuperar y reproducir medios de audio o audiovisuales. Los applets de Java 912 configuran el UA 10 para proporcionar juegos, utilidades y otras funcionalidades. Un componente 914 podría proporcionar funcionalidad descrita en el presente documento.

El UA 10, la estación base 12 y otros componentes descritos anteriormente podrían incluir un componente de procesamiento que es capaz de ejecutar instrucciones relacionadas con las acciones descritas anteriormente. La Figura 10 ilustra un ejemplo de un sistema 1000 que incluye un componente 1010 de procesamiento adecuado para implementar una o más realizaciones descritas en la presente memoria. Además del procesador 1010 (que puede denominarse unidad de procesador central (CPU O DSP), el sistema 1000 podría incluir dispositivos de conectividad de red 1020, memoria de acceso aleatorio (RAM) 1030, memoria de solo lectura (ROM) 1040, almacenamiento secundario 1050 y dispositivos de entrada/salida (E/S) 1060. En algunas realizaciones, un programa para implementar la determinación de un número mínimo de ID de proceso de HARQ puede almacenarse en la ROM 1040. En algunos casos, algunos de estos componentes pueden no estar presentes o pueden combinarse en varias combinaciones entre sí o con otros componentes no mostrados. Estos componentes pueden ubicarse en una única entidad física o en más de una entidad física. Cualquiera de las acciones descritas en el presente documento como tomadas por el procesador 1010 puede ser tomada por el procesador 1010 solo o por el procesador 1010 junto con uno o más componentes mostrados o no mostrados en el dibujo.

El procesador 1010 ejecuta instrucciones, códigos, programas informáticos o scripts que puede acceder a partir de los dispositivos de conectividad de red 1020, RAM 1030, ROM 1040 o almacenamiento secundario 1050 (que podría incluir diversos sistemas basados en disco tales como disco duro, disquete o disco óptico). Aunque solo se muestra un procesador 1010, pueden estar presentes múltiples procesadores. Por lo tanto, aunque las instrucciones pueden ser discutidas como ejecutadas por un procesador, las instrucciones pueden ejecutarse simultáneamente, en serie o de otro modo por uno o múltiples procesadores. El procesador 1010 puede implementarse como uno o más chips de CPU.

Los dispositivos de conectividad de red 1020 pueden tomar la forma de módems, bancos de módem, dispositivos Ethernet, dispositivos de interfaz de bus serie universal (USB), interfaces seriadas, dispositivos Token Ring, dispositivos de interfaz de datos distribuidos por fibra (FDDI), dispositivos de red de área local inalámbrica (WLAN), dispositivos transceptores de radio tales como dispositivos de transmisión múltiple por división de código (CDMA), sistema global para comunicaciones móviles (GSM) dispositivos transceptores de radio, interoperabilidad mundial para acceso por microondas (WiMAX) y/u otros dispositivos bien conocidos para conectarse a redes. Estos dispositivos de conectividad de red 1020 pueden permitir que el procesador 1010 se comunique con Internet o una o más redes de telecomunicaciones u otras redes desde las cuales el procesador 1010 pueda recibir información o a la que el procesador 1010 podría emitir información.

Los dispositivos de conectividad de red 1020 también podrían incluir uno o más componentes transceptores 1025 capaces de transmitir y/o recibir datos de forma inalámbrica en forma de ondas electromagnéticas, tales como señales de radiofrecuencia o señales de frecuencia de microondas. Alternativamente, los datos pueden propagarse en o sobre la superficie de conductores eléctricos, en cables coaxiales, en guías de ondas, en medios ópticos tales como fibra óptica, o en otros medios. El componente transceptor 1025 puede incluir unidades de recepción y transmisión separadas o un único transceptor. La información transmitida o recibida por el transceptor 1025 puede incluir datos que han sido procesados por el procesador 1010 o instrucciones que deben ejecutarse por el procesador 1010. Dicha información puede recibirse y emitirse a una red en la forma, por ejemplo, de una señal de banda base de datos de ordenador o señal incorporada en una onda portadora. Los datos pueden ordenarse de acuerdo con diferentes secuencias como puede ser deseable para procesar o generar los datos o transmitir o recibir los datos. La señal de banda base, la señal integrada en la onda portadora u otros tipos de señales actualmente utilizadas o desarrolladas en lo sucesivo se pueden denominar el medio de transmisión y pueden generarse de acuerdo con varios métodos bien conocidos por un experto en la técnica.

La RAM 1030 podría usarse para almacenar datos volátiles y quizás para almacenar instrucciones que son ejecutadas por el procesador 1010. La ROM 1040 es un dispositivo de memoria no volátil que típicamente tiene una capacidad de memoria más pequeña que la capacidad de memoria del almacenamiento secundario 1050. La ROM 1040 puede usarse para almacenar instrucciones y quizás datos que se leen durante la ejecución de las instrucciones. El acceso tanto a la RAM 1030 como a la ROM 1040 es típicamente más rápido que al almacenamiento secundario 1050. El almacenamiento secundario 1050 está compuesto típicamente por una o más unidades de disco o unidades de cinta y podría usarse para almacenamiento no volátil de datos o como un dispositivo de almacenamiento de datos de desbordamiento si la RAM 1030 no es lo suficientemente grande como para contener todos los datos de trabajo. El almacenamiento secundario 1050 puede usarse para almacenar programas que se cargan en la RAM 1030 cuando dichos programas se seleccionan para su ejecución.

Los dispositivos de E/S 1060 pueden incluir pantallas de cristal líquido (LCD), pantallas táctiles, teclados, teclados numéricos, interruptores, diales, ratones, bolas de seguimiento, reconocedores de voz, lectores de tarjetas, lectores de cinta de papel, impresoras, monitores de video u otros dispositivos de entrada/salida bien conocidos. Además, el transceptor 1025 puede considerarse como un componente de los dispositivos de E/S 1060 en lugar de o además de ser un componente de los dispositivos de conectividad de red 1020. Algunos o todos los dispositivos de E/S 1060 pueden ser sustancialmente similares a diversos componentes representados en el dibujo descrito anteriormente del UA 10, tal como la pantalla 702 y la entrada 704.

Si bien se han proporcionado varias realizaciones en la presente descripción, debe entenderse que los sistemas y métodos descritos pueden incorporarse de muchas otras formas específicas sin apartarse del alcance de la presente descripción. Los presentes ejemplos deben considerarse ilustrativos y no restrictivos, y la intención no debe limitarse a los detalles proporcionados en este documento. Por ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otro sistema o ciertas características pueden omitirse o no implementarse.

Además, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas realizaciones como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas o métodos sin apartarse del alcance de la presente divulgación. Otros elementos mostrados o comentados como acoplados o directamente acoplados o que se comunican entre sí pueden estar indirectamente acoplados o comunicarse a través de alguna interfaz, dispositivo o componente intermedio, ya sea eléctrica, mecánicamente o de otro modo. Otros ejemplos de cambios, sustituciones y alteraciones pueden determinarse por un experto en la técnica y podrían hacerse sin apartarse del alcance descrito en el presente documento.

Para informar al público sobre el alcance de esta divulgación, se hacen las siguientes afirmaciones:

Claims

REIVINDICACIONES

i . Un método para comunicar información compactada entre dos entidades que incluyen un Remitente de Cadena y un Destinatario de Cadena, que incluyen cada uno un agente de usuario, Ua , un nodo de red u otras entidades de red, usando una interfaz I1, la interfaz I1 proporciona un canal de control de sesión, cuyo método que comprende:

el Remitente de Cadena prepara un mensaje codificado por protocolo de inicio de sesión, SIP, que va a transmitirse usando la interfaz I1

el mensaje codificado por SIP incluye varias cadenas y varios elementos de datos verbosos que generan mensajes codificados por SIP que son más grandes que una carga útil máxima de la interfaz I1, reduciendo el tamaño del mensaje codificado por SIP haciendo lo siguiente:

el Remitente de Cadena recorre cada una de las cadenas para determinar si es elegible para la compresión reemplazando cadenas con indicios, identificando la primera cadena que se transmitirá en el mensaje codificado por SIP a al menos uno de un agente de usuario, UA y un nodo de red, la primera cadena incluyendo al menos uno de un identificador de recurso uniforme, URI, una Identidad de Usuario Pública y una capacidad SIP UA;

y en donde el Remitente de Cadena y el Destinatario de Cadena han compartido una tabla de sincronización que asocia la primera cadena y un indicio,

el Remitente de Cadena busca el primer valor de cadena en la tabla de sincronización para identificar el indicio asociado con la primera cadena del mensaje codificado por SIP: y cuando encuentra el primer valor de cadena del mensaje codificado por SIP en la tabla de sincronización, el Remitente de Cadena inserta el indicio que corresponde a la primera cadena en el mensaje codificado por SIP, y

el Remitente de Cadena transmite el mensaje codificado por SIP al Destinatario de Cadena usando la interfaz I1.
2. El método de la reivindicación 1, en donde la primera cadena es una Identidad de Usuario Pública seleccionada de una pluralidad de Identidades de Usuario Públicas, estando clasificadas la pluralidad de Identidades de Usuario Públicas en un orden de prioridad, cuyo orden de prioridad determina una clave asociada con cada una de la pluralidad de Identidades de Usuario Públicas.
3. El método de la reivindicación 2, en donde el orden de prioridad de la pluralidad de Identidades de Usuario Públicas se determina al menos parcialmente mediante un algoritmo hash.
4. El método de la reivindicación 1, en donde la Identidad de Usuario Pública es una Identidad de Usuario Pública predeterminada.
5. El método de la reivindicación 1, en donde una primera clave indica la primera cadena que incluye una Identidad de Usuario Pública predeterminada, o en donde una primera clave asociada con la primera cadena se determina usando un algoritmo hash.
6. El método de la reivindicación 1, que comprende además recuperar la primera clave de la memoria, almacenándose la memoria en un medio de almacenamiento electrónico.
7. Un sistema que comprende un Remitente de Cadena y un Destinatario de Cadena, que incluyen un agente de usuario, U^ay un nodo de red, para comunicarse usando una interfaz I1, cuya interfaz I1 proporciona un canal de control de sesión, estando el sistema adaptado para llevar a cabo todas las etapas del método de cualquier reivindicación anterior.
8. El sistema de la reivindicación 7, en donde la primera cadena es una Identidad de Usuario Pública seleccionada de una pluralidad de Identidades de Usuario Públicas, estando clasificadas la pluralidad de Identidades de Usuario Públicas en un orden de prioridad, cuyo orden de prioridad determina una clave asociada con cada una de la pluralidad de Identidades de Usuario Públicas.
9. El sistema de la reivindicación 8, en donde el orden de prioridad de la pluralidad de Identidades de Usuario Públicas se determina al menos parcialmente mediante un algoritmo hash.