19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 26 3 1 Int. Cl.: H04Q 7/38 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: 030481. 86 Fecha de presentación : 27.02.03 87 Número de publicación de la solicitud: 134766 87 Fecha de publicación de la solicitud: 24.09.03 4 Título: Procesamiento de petición de servicio desde un terminal itinerante. Prioridad: 04.03.02 FI 0411 73 Titular/es: TeliaSonera Finland Oyj Teollisuuskatu 1 00 Helsinki, FI 4 Fecha de publicación de la mención BOPI: 16.02.07 72 Inventor/es: Laukkanen, Jussi; Väänänen, Kai; Julkunen, Mika; Korhonen, Jouni y Tuomela, Frans 4 Fecha de la publicación del folleto de la patente: 16.02.07 74 Agente: Elzaburu Márquez, Alberto ES 2 26 3 T3 Aviso: En el plazo de nueve meses a contar desde la fecha de publicación en el Boletín europeo de patentes, de la mención de concesión de la patente europea, cualquier persona podrá oponerse ante la Oficina Europea de Patentes a la patente concedida. La oposición deberá formularse por escrito y estar motivada; sólo se considerará como formulada una vez que se haya realizado el pago de la tasa de oposición (art. 99.1 del Convenio sobre concesión de Patentes Europeas). Venta de fascículos: Oficina Española de Patentes y Marcas. Pº de la Castellana, 7 28071 Madrid
DESCRIPCIÓN Procesamiento de petición de servicio desde un terminal itinerante. 1 2 3 4 0 6 Antecedentes de la invención La invención se refiere al soporte de establecimiento de conexión entre un terminal y un servidor de aplicación para proporcionar un servicio al terminal. Un terminal que está itinerante en una red visitada transmite una petición de servicio que, al menos indirectamente, indica un servidor pedido desde el cual se pide el servicio. Sin embargo, el terminal no conoce el identificador o la dirección de red de un servidor de aplicación que sea capaz de proporcionar el servicio pedido. La gestión de movilidad convencional para el propósito de manejar llamadas se explica, por ejemplo, en A. Napolitano et al.: UMTS all-ip mobility management, call and session control procedure. El área de la aplicación primaria de la invención es el uso de los servicios del sistema IMS. El IMS (Internet Protocol Multimedia Subsystem) se define en la recomendación 23.228 de 3GPP (Third Generation Partnership Project). En este caso, la petición de servicio puede estar basada en señalización de SIP (SIP = Session Initiation Protocol), por ejemplo. En la red local, las llamadas pueden hacerse ya sea usando números completos (que incluyen códigos de país, etc.) o sólo datos del abonado (identificador del operador + parte del abonado). Cuando se hacen llamadas al extranjero, el número de teléfono usado es casi sin excepción el número completo (código del país, operador, parte del abonado). Un objeto de una llamada del IMS es soportar el uso de números cortos y/o identificadores alfanuméricos (por ejemplo taxi ). El inconveniente más importante del uso de números cortos/identificadores alfanuméricos es que la dirección de destino no está necesariamente completa. En una visita a la red, esto crea el problema de cómo encaminar una petición de servicio hacia el citado sistema de servicio del IMS de la red visitada. Además, no hay certeza de si el abonado pide el servicio de la red visitada o de la red local. Por ejemplo, la patente de US 946 623, de Steven Spradlin, describe una técnica en la cual el sistema de encaminamiento informa a un lugar de servicio local de la situación de un terminal. Breve descripción de la invención Un objeto de la invención es proporcionar un método y equipo para implementar el método para resolver los problemas anteriores. El objeto de la invención se logra mediante un método y un sistema que se caracterizan por lo que se establece en las reivindicaciones independientes. Las realizaciones preferidas se describen en las reivindicaciones adjuntas. La invención se basa en la idea de añadir un identificador que identifica la red visitada a la petición de servicio. La petición de servicio es dirigida hacia la red local del terminal, y la red local usa el identificador que identifica la red visitada en la petición de servicio para concluir si el servidor de aplicación está en la red local o en la red visitada, y encamina la petición de servicio hacia el servidor de aplicación. El identificador que identifica la red visitada puede ser por ejemplo un identificador de celda globalmente único que incluye un código de país MCC (Mobile Country Code) y un código de red MNC (Mobile Network Code), y el identificador de celda dentro de la citada red. En la mayoría de los casos, este último no es necesario, siendo normalmente suficiente cualquier identificador que identifique la red, por el cual sólo el código de país MCC y el código de red MNC deben añadirse a la petición de servicio. Por otro lado, dirigir el identificador de celda completo por medio de la red local hacia un servidor de aplicación de una red visitada puede soportar algunos servicios dependientes de la situación, tales como dirigir una llamada a los taxis de un área dada. El identificador que identifica la red visitada es añadido a la petición de servicio preferiblemente en el terminal. El terminal puede incluir por ejemplo un agente de software para identificar el mensaje saliente, por ejemplo, SIP INVITE, y para añadir el identificador de celda al mensaje. Un problema asociado con el uso de números cortos e identificadores de nombre es que cuando se usa el servicio de IMS de una red visitada, la red local debe ser capaz de convertir los números cortos e identificadores de nombre en una dirección de red del sistema de IMS de la red visitada, por ejemplo una dirección de IP. Para encaminar es suficiente que una red local sea capaz de encaminar la petición de servicio (el mensaje de SIP) hacia la red visitada, puesto que la red visitada es típicamente capaz de dirigir el mensaje hacia el servidor de aplicación que proporciona el citado servicio. Hay al menos dos soluciones alternativas para esto. En la red local, puede mantenerse una base de datos local que incluya una tabla de conversión de las redes de todas las partes contratantes del operador de la red local. Alternativamente, puede transmitirse una pregunta desde la red local hasta un servicio de nombre global DNS (domain name server/service). La presunción de utilizar el DNS es que el DNS soporta la funcionalidad del DDDS (Dynamic Delegation Discovery System). La funcionalidad del DDDS permite, por ejemplo, la conversión de series de números parcialmente jerarquizadas, tales como una Cell-ID, en direcciones y nombres conocidos para el mundo de IP. También es factible un híbrido de estos métodos. En otras palabras, el objetivo es convertir primeramente un número corto o un identificador de nombre en una dirección de red completa basada en la base de datos de la red local, pero si la dirección de red que corresponde al número corto o al identificador de nombre no se encuentra en la base de datos de la red local, se transmite una pregunta al servicio de nombre global. 2
1 2 3 Una ventaja del método y sistema de la invención es la capacidad de un abonado itinerante en una red visitada para usar los servicios de una red visitada sin conocer el identificador del operador de la red visitada. La característica esencial de la invención es que el abonado está registrado siempre en el sistema de IMS local S-CSCF, que sirve como un punto de acceso a servicio (normalmente el S-CSCF decide a qué servidor de aplicación se dirige el servicio pedido). Otro problema de usar números cortos e identificadores de nombre es que los servicios en la red local y en una red visitada pueden tener el mismo identificador, es decir, la petición de servicio no indica de forma fiable si el abonado quiere usar los servicios de la red local o de la red visitada. El problema puede ser resuelto mediante varios métodos o combinaciones de métodos. De acuerdo con una realización, la petición de servicio es dirigida a la red local, y el servidor de aplicación concluye ahí, basándose en el tipo de servicio, si el abonado quiere usar los servicios de la red local o de la red visitada. La dirección de destino (red local o visitada) de una suscripción/servicio puede ser concluida por: a) el usuario que introduce el identificador manualmente, b) el terminal/usim que pregunta por la red de destino del usuario, c) la red local que pregunta por la red de destino del servicio, d) la red local que toma una decisión independiente acerca de la red de destino del servicio. Por ejemplo, si el servicio pedido es llamar a un taxi, es prácticamente cierto que el abonado se refiere a servicios de una red visitada. Por el contrario, si el servicio pedido es obtener un billete para una película o un concierto, el tipo de servicio no puede usarse para sacar una conclusión sobre la red cuyo servicio está implicado. Al menos existen dos soluciones para esto. De acuerdo con una solución alternativa, puede añadirse a la petición de servicio un identificador explícito, independiente de la red visitada, y el identificador indica si el servidor de aplicación está en la red local o en la red visitada. Por ejemplo, un signo menos podría indicar servicios de una red visitada y un signo más un servicio de una red local. La expresión identificador independiente de red significa que el identificador es el mismo independientemente de la red visitada, en contraposición con las redes móviles convencionales, en las que el abonado tiene que conocer siempre el identificador de red de la citada red. De acuerdo con una solución alternativa, si el servidor de aplicación indicado por la petición de servicio puede estar en la red local o en la red visitada, la red local transmite una pregunta al terminal con el fin de seleccionar la red. En la pregunta, al abonado se le notifica que la petición de servicio puede estar asociada con el servicio de la red local o de la red visitada, y al abonado se le pide que seleccione el servicio pedido. De acuerdo con una realización particularmente ventajosa, la petición de servicio utiliza una combinación de todos los métodos descritos anteriormente para concluir si la petición de servicio está asociada con el servicio de la red local o de la red visitada. En otras palabras, si la petición de servicio puede ser asociada al servicio de la red local o de la red visitada, y la petición de servicio incluye un identificador explícito que indica si el servicio pedido es el de la red local o el de la red visitada, entonces se hace la selección basándose en este identificador explícito. Si la petición de servicio no incluye tal identificador explícito, entonces la red es seleccionada basándose en el tipo de servicio pedido, si es posible. Si la red no puede ser seleccionada basándose en el tipo de servicio solicitado, al abonado se le transmite una pregunta con respecto a la selección de red. Breve descripción de las figuras 4 En lo que sigue, realizaciones preferidas de la invención se describirán en detalle con referencia a los dibujos que se acompañan, en los cuales la Figura 1 es un diagrama de bloques general que muestra una situación en la que una estación móvil está itinerante en una red visitada, que es una red diferente de la red local de la estación móvil; 0 la Figura 2 muestra una cadena de sucesos potenciales en la situación mostrada en la Figura 1; y la Figura 3 muestra una petición de servicio a la que se le añade un identificador que identifica la red visitada. 6 Descripción detallada de la invención Con el fin de ilustrar, pero no restringir la invención, su operación se describe en asociación con una llamada de IMS. Una llamada de IMS puede ser implementada por ejemplo en una red de GPRS (General Packet Radio Service), en la cual se implementan extensiones de IMS. La figura 1 muestra una situación en la cual una estación móvil MS está itinerante en una red visitada NW2, que es una red diferente de una red local NW1 de la estación móvil. Algunos elementos de red, tales como los elementos que constituyen el camino de radio y conocidos para las personas expertas en la técnica son omitidos en aras de la simplicidad. SGSN (Serving GPRS Support Node) y GGSN (Gateway GPRS Support Node) soportan la movilidad del terminal. P-CSCF (Proxy Call Session Control Function) y S-CSCF (Service Call Session Control Function) son servidores de SIP que atienden el establecimiento, gestión y terminación de la conexión en la capa de aplicación. AS1 y AS2 son servidores de aplicación de la red local NW1 de la estación móvil y de la red visitada NW2, respectivamente. DB es una base de datos para convertir los números cortos y el identificador de nombre en direcciones de red completas. DNS es un servicio o servidor de nombre (área). Por ejemplo GRX (GPRS Roaming Exchange) puede servir como la red central, es decir, red de interconexión, entre operadores móviles. 3
1 2 3 La Figura 2 muestra una cadena potencial de sucesos en la situación mostrada en la Figura 1. En el paso 2-0, el abonado de una estación móvil MS decide hacer una llamada al servidor de aplicación AS2 de la red visitada usando un número corto o el nombre del servicio, por ejemplo, 123 o taxi. Estos números de teléfono pueden ser convertidos por ejemplo al formato SIP-URL para ser encaminados en el teléfono (no es esencial para la invención si el número corto es convertido al formato SIP-URL del terminal, a la P-CSCF o a la S-CSCF). Así el abonado no tiene que conocer el identificador de la red visitada. En el paso 2-2, el agente de Software de la estación móvil MS detecta un mensaje de SIP INVITAR saliente y le añade un identificador de celda. En una situación de un problema primario, la P-CSCF y la S-CSCF están situados en la red local. Así, todas las peticiones de servicio del usuario son siempre dirigidas primero a la red local. En el paso 2-4, el S-CSCF de la red local dirige la petición de servicio hacia el servidor de aplicación AS1. Supongamos que en el paso 2-6, el servidor de aplicación AS1 de la red local descubre que el servicio pedido se implementa en la red local (implementado por el propio AS1 o cualquier otro servidor de aplicación). En el paso 2-8, el AS1 descubre que el abonado está en una red visitada y, en consecuencia, la petición de servicio puede estar asociada con un servicio bien sea de la red local o de la red visitada. El tipo de servicio no indica cuál quiere decir el abonado. En este caso, en el paso 2-, el AS1 transmite al abonado una pregunta acerca de la selección de red, y el abonado contesta a ella en el paso 2-12. Supongamos que el abonado selecciona un servicio de la red visitada. En el paso 2-14, el AS1 transmite una pregunta a la DB (o al servicio de nombre global DNS) y obtiene de allí la dirección de red correspondiente al servicio solicitado, es decir, la dirección de red del sistema de IMS de la red visitada NW2. Ahora, en los pasos 2-16 y 2-18, el AS1 solicita que la S-CSCF encamine la petición de servicio hacia el sistema de IMS de la red visitada, el cual dirige la petición de servicio hacia el servidor de aplicación AS2. En el paso 2-, el AS2 analiza la petición de servicio y proporciona el servicio solicitado en el paso 2-22. La Figura 3 muestra una petición de servicio, a la que se añade un identificador que identifica la red visitada. En este ejemplo, la petición de servicio es transmitida como un mensaje Invitar de SIP. El protocolo de SIP define un número de mensajes de texto que incluyen campos obligatorios y opcionales. En este caso, el campo 31 del mensaje indica que se trata de un mensaje de Invitar. Los campos obligatorios 32 y 33 indican el receptor y el emisor, respectivamente. De acuerdo con la invención, un mensaje de Invitar incluye un identificador que identifica la red visitada. La adición del identificador se implementa por medio de un campo opcional 34, que en este ejemplo incluye un identificador de celda globalmente único, es decir, código del país MCC, código de red MNC y número de celda dentro de la citada red ( 123467 ). Sin embargo, como se ha dicho anteriormente, por lo que se refiere a la invención, sólo es necesaria la adición del identificador 3 que identifica la red visitada, es decir, en este ejemplo, la combinación de código de país (MCC) 36 + código de red (MNC) 37. Se requieren tanto el código de país como el código de red, puesto que las mismas identidades de red pueden usarse en diferentes países, y, por otro lado, pueden existir varias redes diferentes en cada país. Alternativamente, el identificador 3 que identifica la red visitada puede ser alfanumérico, por ejemplo sonera.com, en cuyo caso un identificador puede ser globalmente único. Resulta evidente para una persona experta en la técnica que aunque la tecnología avance, la idea básica de la invención puede ser implementada en una variedad de formas. La invención y sus realizaciones no están por consiguiente limitadas a los ejemplos anteriores, sino que pueden variar dentro del ámbito de las reivindicaciones. Abreviaturas 3GPP = Third Generation Partnership Project 4 AS = Application Server DDDS = Dynamic Delegation Discovery System DNS = Domain Name Server/Service 0 GGSN = Gateway GPRS Support Node GPRS = General Packet Radio Service MCC = Mobile Country Code MNC = Mobile Network Code NAPTR = Naming Authority Pointer IMS = Internet Protocol Multimedia Subsystem P-CSCF = Proxy Call Session Control Function 6 S-CSCF = Service Call Session Control Function SGSN = Serving GPRS Support Node SIP = Session Initiation Protocol 4
REIVINDICACIONES 1 1. Un método para soportar el establecimiento de la conexión entre un terminal (MS) y un servidor de aplicación (AS1, AS2) para proporcionar al terminal un servicio cuando el terminal está en itinerancia en una red visitada (NW2), que es una red diferente de la red local (NW1) del terminal; en cuyo método el terminal (MS) transmite una petición de servicio (2-4, ) a la red visitada, indicando la petición de servicio al menos indirectamente el tipo de servicio, pero cuando se transmite la petición de servicio, el terminal no conoce un identificador o dirección de red del servidor de aplicación; comprendiendo también el método: añadir en el terminal un identificador (34, 3) que identifique la red visitada a la petición de servicio (2-4, ); dirigir la petición de servicio a la red local (NW1) del terminal; y decidir la red local un identificador del servidor de aplicación adecuado para proporcionar el servicio basándose al menos parcialmente en el identificador que identifica la red visitada y que está incluido en la petición de servicio, concluir si el servidor de aplicación está en la red local o en la red visitada; y encaminar la petición de servicio hacia el servidor de aplicación. 2 3 4 0 6 2. Un método de acuerdo con la reivindicación 1, caracterizado porque el identificador (34, 3) identifica la red visitada que incluye un código de país (36) y un código de red (37). 3. Un método de acuerdo con la reivindicación 2, caracterizado porque el identificador identifica la red visitada que incluye también un identificador de celda (38). 4. Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, caracterizado por añadir a la petición de servicio un identificador explícito independiente de la red visitada para indicar si el servidor de aplicación adecuado para proporcionar el servicio está en la red local o en la red visitada.. Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, caracterizado porque si el servidor de aplicación adecuado para proporcionar el servicio puede estar en la red local o en la red visitada, la red local decide la red basándose en el tipo de servicio. 6. Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, caracterizado porque si el servidor de aplicación adecuado para proporcionar el servicio puede estar en la red local o en la red visitada, la red local transmite una pregunta (2-, 2-12) al terminal para la selección de red. 7. Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, caracterizado porque la red local encamina la petición de servicio hacia el servidor de aplicación basándose en una base de datos (DB) local de la red local. 8. Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, caracterizado porque la red local encamina la petición de servicio hacia el servidor de aplicación basándose en un servicio de nombre global (DNS). 9. Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, caracterizado porque la petición de servicio es un mensaje de SIP () de acuerdo con el sistema Protocol Multimedia Subsystem [IMS].. Un terminal (MS) dispuesto para estar itinerante en una red visitada (NW2) y transmitir una petición de servicio (2-4, ) que al menos indirectamente indica un servidor de aplicación (AS1, AS2), caracterizado porque cuando el terminal no conoce el identificador o la dirección de red del servidor de aplicación, el terminal está dispuesto para añadir un identificador (34, 3) de la red visitada a la petición de servicio con el fin de dirigirla hacia la red local del terminal para concluir, basándose en el identificador, si el servidor de aplicación está en la red local o en la red visitada, y para encaminar la petición de servicio hacia el servidor de aplicación (AS1, AS2). 11. Una disposición para soportar el establecimiento de la conexión entre un terminal (MS) y un servidor de aplicación (AS1, AS2) con el fin de proporcionar al terminal un servicio cuando el terminal está itinerante en una red visitada (NW2), que es una red diferente de una red local (NW1) del terminal y cuando el terminal no conoce el identificador o la dirección de red del servidor de aplicación, comprendiendo la disposición: medios para recibir una petición de servicio (2-4, ) de una red visitada, indicando la petición de servicio al menos indirectamente el tipo de servicio;
medios para identificar un identificador (34, 3) que identifica la red visitada y añadir a la petición de servicio (2-4, ) por el terminal; medios para concluir, basándose en el identificador que identifica la red visitada y que se añade a la petición de servicio, si el servidor de aplicación está en la red local o en la red visitada; y medios para encaminar la petición de servicio hacia el servidor de aplicación. 1 2 3 4 0 6 6
7