ES2304879B1 - Procedimiento para evitar sobrecarga en redes de telefonia movil por 'always-on' en el caso de una llamada entrante. - Google Patents
Procedimiento para evitar sobrecarga en redes de telefonia movil por 'always-on' en el caso de una llamada entrante. Download PDFInfo
- Publication number
- ES2304879B1 ES2304879B1 ES200700881A ES200700881A ES2304879B1 ES 2304879 B1 ES2304879 B1 ES 2304879B1 ES 200700881 A ES200700881 A ES 200700881A ES 200700881 A ES200700881 A ES 200700881A ES 2304879 B1 ES2304879 B1 ES 2304879B1
- Authority
- ES
- Spain
- Prior art keywords
- address
- user
- ggsn
- sgsn
- aaa server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H04W76/02—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Abstract
Procedimiento para evitar sobrecarga en redes de
telefonía móvil por "always-on" en el caso de
una llamada entrante.
Procedimiento para evitar sobrecarga en redes de
telecomunicaciones con IMS por "always-on" para
una llamada recibida por un usuario;
- si el GGSN va a desactivar un PDP Context de
usuario por inactivo, la asociación [IP usuario, IP GGSN, IP SGSN]
no se elimina del servidor AAA que previamente ha guardado esta
asociación, y además el P-CSCF del usuario añade un
indicador de que dicho usuario está en IMS pero sin PDP Context
activo; y,
al recibir una llamada entrante:
- el P-CSCF comprueba el estado
del PDP Context mediante dicho indicador, y si no está activo, se
reactiva dicho PDP Context para lo cual el P-CSCF
informa al GGSN sobre la dirección IP a asignar a dicho usuario,
y
- si dicha dirección IP no ha sido asignada a
otro usuario, se intenta reactivar el PDP Context usando la
dirección dada por el P-CSCF.
Description
Procedimiento para evitar sobrecarga en redes de
telefonía móvil por "always-on" en el caso de
una llamada entrante.
La invención se engloba dentro del campo de las
telecomunicaciones móviles, y más en concreto, en cómo se puede
evitar la sobrecarga estática en SGSN y GGSN cuando PDP
Context con necesidades de "always-on"
("siempre presentes") son requeridos para servicios de tiempo
real como IMS.
Es sabido que en el campo de telefonía móvil se
utilizan frecuentemente abreviaciones y acrónimos. A continuación
se expone un glosario de acrónimos/términos que son utilizados a lo
largo de la presente memoria descriptiva:
El "always-on" es un bien y
viejo conocido problema en el entorno de PS. En teoría, cualquier
usuario que ejecute un PDP Context Request (realice una
petición para un nuevo contexto) y reciba una respuesta positiva,
está usando recursos IP en una forma de always-on,
i.e. siempre presentes y asignados, incluso si el usuario no genera
ningún tráfico de datos IP. El tipo de recursos usados es más bien
de carácter estático (dirección IP, carga de memoria en los nodos,
etc.) que dinámico (radio canales, etc.), pero aún así se trata de
recursos escasos. De hecho, los actuales GGSNs están configurados
para cerrar cualquier PDP Context sin actividad, con el
ánimo de ahorrar el máximo número de recursos como sea posible. El
elemento que define qué PDP inactivo debe ser cerrado, es el APN
con el que se está accediendo.
Cuando el sistema IMS sea masivamente adoptado,
es posible que se presente una situación paradójica. El uso del IMS
para servicios en tiempo real implica una asunción de total
alcanzabilidad del usuario en cualquier momento y en cualquier
lugar, con vistas a mantener el mismo nivel de servicio que tiene
actualmente el usuario con CS. Eso significa que el PDP
Context para señalización SIP utilizado por el usuario, debe
estar siempre disponible (desde el punto de vista de IMS, cerrar el
contexto de señalización significa de-registrar de
facto al usuario), incluso si la inactividad del usuario se
prolonga por largo tiempo. Por tanto, los requisitos de IMS no
harán sino empeorar el problema del consumo de recursos IP sin
tráfico real asociado.
Antes de explicar la solución propuesta a este
problema mediante la presente invención, se expone a continuación
lo que sucedería con la situación actual. Supongamos que hay un
usuario IMS ya registrado en el sistema y con el contexto de
señalización activo, por lo que es capaz de iniciar y recibir
llamadas. Si el GGSN decidiera cerrar ese PDP Context de
señalización porque el usuario no ha realizado ninguna interacción
adicional con la red, el usuario pasaría a un estado semejante al
de de-registrado, siendo incapaz de iniciar o
recibir ninguna llamada hasta que realice una petición para un
nuevo contexto y se vuelva a registrar en el sistema. Esto implica
señalización adicional, y además incrementa el retardo esperado al
establecer cualquier tipo de llamada.
Mediante el procedimiento de la presente
invención se aligera el uso de los recursos que el modelo de
"always-on" impondrá sobre la infraestructura
PS cuando el IMS sea adoptado.
La invención propuesta se fundamenta en el
concepto de la separación de capas, lo cual significa romper la
dependencia entre lo que le sucede al PDP context y el estado del
usuario en la red IMS.
La invención se refiere a un procedimiento para
evitar sobrecarga en redes de telecomunicaciones con IMS por
"always-on" para una llamada recibida por un
usuario;
De acuerdo con un primer aspecto de la
invención:
- -
- dicho usuario envía un mensaje de petición para activar un nuevo PDP Context a su SGSN, quien lo remite a un GGSN;
- -
- el GGSN envía un mensaje Accounting Request a un servidor AAA, incluyendo además en el campo 3GPP Vendor Attributes de dicho mensaje Accounting Request las direcciones IP del GGSN y del SGSN en el que dicho usuario está acampado; y
- -
- si el GGSN va a desactivar dicho PDP Context por haber estado inactivo durante un periodo de tiempo preestablecido, dicha asociación [dirección IP de usuario, dirección IP del GGSN, dirección IP del SGSN] en el servidor AAA no se elimina, y además el GGSN le informa al P-CSCF en el que está presente dicho usuario añadiendo el P-CSCF un indicador que describe que dicho usuario está registrado en IMS pero sin un PDP Context activo; y,
cuando se recibe una llamada entrante:
- -
- un S-CSCF de la red envía una petición de PDP Context al P-CSCF en el que está presente dicho usuario;
- -
- dicho P-CSCF comprueba el estado del PDP Context del usuario usando dicho indicador, y si el PDP Context no está activo, se vuelve a activar dicho PDP Context para lo cual el P-CSCF informa al GGSN sobre la dirección IP que se debe asignar a dicho usuario, y
- -
- si dicha dirección IP de la asociación no ha sido asignada por el GGSN a otro usuario, se intenta reactivar el PDP Context usando la dirección dada por el P-CSCF para lo cual
- -
- el GGSN usa el procedimiento Network-Requested PDP context activation, siendo necesaria una consulta Access-Request al servidor AAA que usa esa dirección IP como principal parámetro de consulta;
- -
- el servidor AAA usa dicha dirección IP como un índice y responde al GGSN usando un mensaje de Access-Accept con la dirección IP del SGSN bajo el cual está localizado el usuario;
- -
- y si dicha dirección IP ha sido asignada a otro usuario, se procede a reiniciar tras el fallo del intento de llamada.
Preferiblemente y para evitar en lo posible que
la dirección IP haya sido asignada a otro usuario, en el GGSN al
liberar una dirección IP se guarda en la última posición de una cola
de direcciones IP.
Preferiblemente y para detectar si el usuario
que recibe la llamada entrante se ha movido desde el momento de la
desactivación del PDP Context, cambiando por tanto de SGSN de
servicio:
- -
- el servidor AAA realiza una consulta al correspondiente HSS/HLR utilizando el mensaje de Accounting-Request-START, antes de responderle al GGSN con el mensaje de Access-Accept, incluyendo la dirección del SGSN que el servidor AAA tiene actualmente guardada entre otros parámetros relacionados IMSI/MSISDN;
- -
- si la dirección del SGSN guardada en el HSS/HLR difiere de la enviada en ese mensaje para el IMSI/MSIDN reportado, el HSS/HLR responde con un Accounting-Response-START actualizando dicha dirección del SGSN;
- -
- y esta información es transferida hacia el GGSN en el mensaje de Access-Accept.
De acuerdo con esta realización preferida, se
exige una interposición del procedimiento de Accounting
antes de cerrar el procedimiento de Access, cuyo comportamiento no
estándar de Radius le es indicado al servidor AAA mediante un
parámetro en un campo del mensaje que inicia el protocolo el
Access-Request.
El procedimiento también puede comprender
que:
- -
- el servidor AAA indique al correspondiente HSS/HLR para qué usuario o usuarios precisa información sobre sus respectivos SGSNs, y
- -
- el HSS/HLR, cada vez que se produce una modificación de la dirección del SGSN que tiene guardada para ese usuario o esos usuarios, informa al servidor AAA de dicha actualización de la dirección del SGSN.
De esta forma, mediante la presente invención se
da una solución a la situación expuesta anteriormente, cumpliendo
los siguientes objetivos:
- \bullet
- La red sigue pudiendo cerrar PDP Context largamente inactivos.
- \bullet
- El usuario es alcanzable para cualquier llamada entrante de tiempo real.
- \bullet
- La solución minimiza la señalización necesaria.
- \bullet
- La solución no requiere nuevos desarrollos o adopción de nuevos elementos en la arquitectura. De hecho, es deseable el uso de protocolos y funcionalidades actualmente implementadas o previstas a incorporar a la red en el corto plazo.
A continuación se pasa a describir de manera muy
breve una serie de dibujos que ayudan a comprender mejor la
invención y que se presentan como ejemplos ilustrativos pero no
limitativos de ésta.
La Figura 1 muestra un ejemplo de procedimiento
estándar de Network-Requested PDP Context
Activation ejecutado con éxito.
La Figura 2 muestra cómo la Interim Solution de
IMS involucra traspaso de información relevante al problema del
"always-on" descrito en este documento.
A continuación se pasan a explicar cómo mediante
el procedimiento de la invención se implementa una solución para
los siguientes casos: llamada acabada en el móvil (caso MT).
Es conveniente entender el terminal de IMS como
una entidad formada por dos elementos: el terminal UMTS propiamente
dicho y el cliente IMS (con el stack de SIP). El cliente IMS es el
elemento que gestiona toda la señalización IMS y usa servicios del
terminal UMTS (básicamente, el soporte de PDP Context) para
proporcionar el servicio adecuado al usuario.
En el caso de una llamada acabada en el terminal
móvil, la red debe forzar al usuario a levantar un nuevo PDP
Context cuando se reciba una llamada entrante.
Una posible forma de hacer esto es a través del
procedimiento descrito en los estándares como
Network-Requested PDP Context Activation
(Activación de PDP Context requerido por la red). En la
figura 1 se muestra un ejemplo en el que se lleva a cabo un
procedimiento de Network-Requested PDP Context
Activation con éxito. Este procedimiento consiste en una
consulta por parte del GGSN al HLR para encontrar la dirección del
SGSN actualmente responsable del usuario buscado. Una vez
encontrado se hace llegar al usuario, vía el mencionado SGSN, un
requerimiento para que inicie un PDP Context, porque los PDP
Contexts son siempre iniciados por el móvil.
Es útil comprender el estado actual de esta
funcionalidad en las redes GPRS/UMTS. Hasta la fecha, los GGSN
presentes en las redes reales son capaces de iniciar esta clase de
interacción, es decir, son capaces de crear el mensaje requerido
para el Network-Requested PDP Context
Activation usando el protocolo GTP. Sin embargo, es requisito
necesario para la implementación de este procedimiento que el GGSN
envíe dicho mensaje hacia el SGSN correcto, bajo el cual es usuario
está acampado. Conseguir dicha información requiere una interacción
entre GGSN y HLR a través de un interfaz denominado Gc. Este
interfaz, aunque estándar, no está presente en muchas de las redes
reales y no se prevé su presencia en el corto/medio plazo.
En una primera aproximación una realización del
procedimiento de la presente invención para este caso de llamada
acabada en el terminal móvil MT hace uso de esta funcionalidad, pero
superando estas limitaciones que han impedido, de hecho, el uso de
este procedimiento en las redes actuales GPRS/UMTS.
Para ello, se utilizan algunos elementos
arquitecturales que van a ser implantados para el despliegue de IMS,
salvando algunos problemas de seguridad (Interim Security
Solution). En este caso se requiere el uso de un servidor AAA
(authentication, authorization, and accounting server) de
autenticación para garantizar el acceso a redes IMS de usuarios con
módulos SIM (no USIM) y terminales antiguos (o mejor, no
completamente adaptados a las soluciones estándares de IMS,
básicamente, sin IPSec). Esta solución proporciona un menor nivel de
seguridad en el acceso IMS, pero se considera suficiente debido a
que evita peligrosas amenazas de seguridad como el IP spoofing,
suplantación de usuario, etc.
En la solución propuesta el GGSN envía un
mensaje de Accounting-Request hacia el
servidor AAA, informando sobre ciertos atributos del usuario como
la dirección IP asignada, el MSISDN, etc., durante el procedimiento
IMS de Registro. El GGSN implementa también los campos optativos
definidos como 3GPP Vendor Attributes en dicho mensaje
Accounting-Request. Estos campos optativos
contienen información importante, como son las direcciones IP del
GGSN y del SGSN, siendo esta última especialmente importante en este
caso.
Recapitulando la situación: después del
procedimiento de Registro IMS usando la solución descrita en lo
anterior, hay un servidor AAA con las direcciones IP del usuario,
del GGSN y SGSN que actualmente le están proporcionando servicio.
De acuerdo con el procedimiento de la invención, dicha información
no es eliminada de dicho servidor AAA cuando el PDP Context
es eliminado por el GGSN en caso de sobrecarga e inactividad -es
decir, el GGSN no envía ningún mensaje de
Accounting-Request-STOP hacia
el servidor AAA-, porque dicha información es usada en la solución
propuesta al problema del always-on.
Así, cuando se recibe una llamada entrante, el
S-CSCF envía dicha petición hacia el
P-CSCF adecuado, bajo el cual se supone está
presente el usuario demandado. Dicho P-CSCF ha de
chequear el estado actual del PDP Context del usuario,
usando para ello un indicador que se ha añadido a la lista de PDP
Context (más concretamente, a la lista de las Security
Association de IPSec) cuando el GGSN informó que iba a cerrar dicho
PDP Context. El significado de dicho indicador describe, por
tanto, que el usuario está registrado en IMS pero no tiene ningún
PDP Context activo. Es necesario, por tanto, volver a activar
dicho PDP Context, teniendo como requisito necesario la
indicación al GGSN sobre la dirección IP que se debe asignar al
usuario, que es la misma que la guardada en la asociación IMS.
Dicha indicación es enviada por el P-CSCF hacia el
GGSN usando el interfaz descrito como Gx+. Dicha indicación puede
incluirse en algún mensaje Diameter de dicho interfaz, o también
podría definirse un mensaje adicional para ello.
Si el GGSN no ha asignado la dirección IP
requerida a otro usuario, se intenta reactivar el PDP Context
usando la dirección IP indicada por el P-CSCF. Para
tal propósito, el GGSN usará el mencionado procedimiento de
Network-Requested PDP Context Activation,
siendo necesaria una consulta al servidor AAA (mensaje
Access-Request) usando la dirección IP como
el principal parámetro de consulta. El servidor AAA usa dicha
dirección IP como un índice y responde al GGSN usando un mensaje de
Access-Accept con la dirección IP del SGSN
bajo el cual está localizado el usuario.
El procedimiento descrito puede encontrarse con
un problema. Si el usuario se ha movido desde el momento de la
desconexión del PDP Context, cambiando de Routing Area de
servicio (es decir, ha cambiado de SGSN de servicio), ¿cómo puede
actualizarse la información relativa al SGSN de servicio en el
servidor AAA para tener en cuenta este caso?. El elemento de la red
que dispone de esa información relativa a movilidad actualizada es
el HSS (HLR), por lo que se puede resolver este problema realizando
una consulta a este elemento (HSS/HLR). El procedimiento de la
Interim Security en IMS define el uso del protocolo Radius entre el
servidor AAA y el HSS, por lo que se reutiliza en la solución de
este caso. La idea es que el servidor AAA realice una consulta al
HSS antes de responderle al GGSN con el mensaje de
Access-Accept. Esta consulta utiliza el
mensaje de
Accounting-Request-START
hacia el HSS, incluyendo la dirección del SGSN que el servidor AAA
tiene actualmente guardada, entre otros parámetros relacionados
(IMSI, MSISDN, etc.). Si la dirección del SGSN guardada en el
HSS/HLR difiere de la enviada en ese mensaje para el IMSI/MSIDN
reportado, el HSS/HLR debe responder con un
Accounting-Response-START
actualizando dicha dirección del SGSN. Después de esto, esta
información es transferida hacia el GGSN en el mensaje de
Access-Accept.
Access-Accept.
No obstante, el comportamiento descrito
anteriormente difiere ligeramente de lo especificado en el estándar
del protocolo RADIUS. Dicho estándar establece que el procedimiento
de Access se completa antes de empezar el procedimiento de
Accounting. Pero en este caso se le está exigiendo una
interposición del procedimiento de Accounting antes de
cerrar el procedimiento de Access. En definitiva, se está exigiendo
un comportamiento no estándar para un caso muy específico. Por
tanto, la exigencia de este cambio de comportamiento debe ser
indicada al servidor AAA en algún campo del mensaje que inicia el
protocolo: el Access-Request.
De esta forma, la solución aquí descrita es, sin
duda, la más "elegante" de todas las posibles y la que permite
un menor retardo en el establecimiento de las llamadas.
Claims (5)
1. Un procedimiento para evitar sobrecarga en
redes de telecomunicaciones con IMS por
"always-on" para una llamada recibida por un
usuario;
caracterizado porque
- -
- dicho usuario envía un mensaje de petición para activar un nuevo PDP Context a su SGSN, quien lo remite a un GGSN;
- -
- el GGSN envía un mensaje Accounting Request a un servidor AAA, incluyendo además en el campo 3GPP Vendor Attributes de dicho mensaje Accounting Request las direcciones IP del GGSN y del SGSN que están proporcionando servicio a dicho usuario; y
- -
- si el GGSN va a desactivar dicho PDP Context por haber estado inactivo durante un periodo de tiempo preestablecido, dicha asociación [dirección IP de usuario, dirección IP del GGSN, dirección IP del SGSN] en el servidor AAA no se elimina, y además el GGSN le informa al P-CSCF en el que está presente dicho usuario añadiendo el P-CSCF un indicador que describe que dicho usuario está registrado en IMS pero sin un PDP Context activo; y,
cuando se recibe una llamada entrante:
- -
- un S-CSCF de la red envía una petición de PDP Context al P-CSCF en el que está presente dicho usuario;
- -
- dicho P-CSCF comprueba el estado del PDP Context del usuario usando dicho indicador, y si el PDP Context no está activo, se vuelve a activar dicho PDP Context para lo cual el P-CSCF informa al GGSN sobre la dirección IP que se debe asignar a dicho usuario, y
- -
- si dicha dirección IP de la asociación no ha sido asignada por el GGSN a otro usuario, se intenta reactivar el PDP Context usando la dirección dada por el P-CSCF para lo cual
- -
- el GGSN usa el procedimiento Network-Requested PDP context activation, siendo necesaria una consulta Access-Request al servidor AAA que usa esa dirección IP como principal parámetro de consulta;
- -
- el servidor AAA usa dicha dirección IP como un índice y responde al GGSN usando un mensaje de Access-Accept con la dirección IP del SGSN bajo el cual está localizado el usuario;
- -
- y si dicha dirección IP ha sido asignada a otro usuario, se procede a reiniciar tras el fallo del intento de llamada.
2. Procedimiento según la reivindicación 1,
caracterizado porque
- -
- el servidor AAA realiza una consulta al correspondiente HSS/HLR utilizando el mensaje de Accounting-Request-START, antes de responderle al GGSN con el mensaje de Access-Accept, incluyendo la dirección del SGSN que el servidor AAA tiene actualmente guardada entre otros parámetros relacionados IMSI/MSISDN;
- -
- si la dirección del SGSN guardada en el HSS/HLR difiere de la enviada en ese mensaje para el IMSI/MSIDN reportado, el HSS/HLR responde con un Accounting-Response-START actualizando dicha dirección del SGSN;
- -
- y esta información es transferida hacia el GGSN en el mensaje de Access-Accept.
3. Procedimiento según la reivindicación 2,
caracterizado porque se exige una interposición del
procedimiento de Accounting antes de cerrar el procedimiento
de Access, cuyo comportamiento no estándar de RADIUS le es indicado
al servidor AAA mediante un parámetro en un campo del mensaje que
inicia el protocolo el Access-Request.
4. Procedimiento según la reivindicación 1,
caracterizado porque
- -
- el servidor AAA indica al correspondiente HSS/HLR para qué usuario o usuarios precisa información sobre sus respectivos SGSNs, y
- -
- el HSS/HLR, cada vez que se produce una modificación de la dirección del SGSN que tiene guardada para ese usuario o esos usuarios, informa al servidor AAA de dicha actualización de la dirección del SGSN.
5. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque en el GGSN
al liberar una dirección IP se guarda en la última posición de una
cola de direcciones IP.
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200700881A ES2304879B1 (es) | 2007-04-03 | 2007-04-03 | Procedimiento para evitar sobrecarga en redes de telefonia movil por 'always-on' en el caso de una llamada entrante. |
| US12/594,813 US8233394B2 (en) | 2007-04-03 | 2008-04-03 | Method for preventing overload in mobile telephone networks by using ‘always-on’ in the case of incoming calls |
| PCT/ES2008/000202 WO2008119860A2 (es) | 2007-04-03 | 2008-04-03 | Procedimiento para evitar sobrecarga en redes de telefonía móvil por 'always-on' en el caso de una llamada entrante. |
| DE602008004834T DE602008004834D1 (de) | 2007-04-03 | 2008-04-03 | Verfahren zur Verhinderung von Überlastungen in Mobiltelefonnetzwerken durch Permanentverbindung im Fall eingehender Anrufe |
| EP08761450A EP2146512B1 (en) | 2007-04-03 | 2008-04-03 | Method for preventing overload in mobile telephone networks using 'always-on' in the case of incoming calls |
| AT08761450T ATE497685T1 (de) | 2007-04-03 | 2008-04-03 | Verfahren zur verhinderung von überlastungen in mobiltelefonnetzwerken durch permanentverbindung im fall eingehender anrufe |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200700881A ES2304879B1 (es) | 2007-04-03 | 2007-04-03 | Procedimiento para evitar sobrecarga en redes de telefonia movil por 'always-on' en el caso de una llamada entrante. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2304879A1 ES2304879A1 (es) | 2008-10-16 |
| ES2304879B1 true ES2304879B1 (es) | 2009-10-23 |
Family
ID=39735713
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200700881A Active ES2304879B1 (es) | 2007-04-03 | 2007-04-03 | Procedimiento para evitar sobrecarga en redes de telefonia movil por 'always-on' en el caso de una llamada entrante. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US8233394B2 (es) |
| EP (1) | EP2146512B1 (es) |
| AT (1) | ATE497685T1 (es) |
| DE (1) | DE602008004834D1 (es) |
| ES (1) | ES2304879B1 (es) |
| WO (1) | WO2008119860A2 (es) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4976672B2 (ja) * | 2005-09-13 | 2012-07-18 | キヤノン株式会社 | ネットワークデバイス装置、データ処理方法及びコンピュータプログラム |
| CN101018128A (zh) * | 2006-02-10 | 2007-08-15 | 朗迅科技公司 | 向互联网协议多媒体子系统(ims)鉴权可移除的用户身份模块 |
| US9535762B2 (en) * | 2010-05-28 | 2017-01-03 | At&T Intellectual Property I, L.P. | Methods to improve overload protection for a home subscriber server (HSS) |
| ES2526457T3 (es) * | 2010-06-17 | 2015-01-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Solicitudes de radiobúsqueda emitidas por P-GW/GGSN |
| US9319433B2 (en) | 2010-06-29 | 2016-04-19 | At&T Intellectual Property I, L.P. | Prioritization of protocol messages at a server |
| CN102511175B (zh) | 2011-12-19 | 2014-04-02 | 华为技术有限公司 | 控制分组数据协议上下文下发的方法和装置 |
| CN103517266B (zh) | 2012-06-29 | 2017-03-22 | 国际商业机器公司 | 移动网络侧激活移动终端的方法和移动网关系统 |
| US9262200B2 (en) | 2014-06-25 | 2016-02-16 | Independenceit, Inc. | Methods and systems for provisioning a virtual resource in a mixed-use server |
| AU2018244293A1 (en) | 2017-03-28 | 2019-09-05 | Netapp, Inc. | Methods and systems for providing wake-on-demand access to session servers |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002032170A1 (en) * | 2000-10-09 | 2002-04-18 | Nokia Corporation | Address de-registration in ip multimedia networks |
| US20020138622A1 (en) * | 2001-03-21 | 2002-09-26 | Motorola, Inc. | Apparatus and method of using long lived addresses in a private network for push messaging to mobile devices |
| GB0112202D0 (en) * | 2001-05-18 | 2001-07-11 | Nokia Corp | Charging in communication networks |
| US7457253B2 (en) * | 2002-03-26 | 2008-11-25 | Telefonaktiebolaget Lm Ericsson (Publ) | System, an arrangement and a method relating to IP-addressing |
| US20030220900A1 (en) * | 2002-03-28 | 2003-11-27 | Bajko Gabor | Method and apparatus for deprecating IP addresses |
| US20040187021A1 (en) * | 2003-02-10 | 2004-09-23 | Rasanen Juha A. | Mobile network having IP multimedia subsystem (IMS) entities and solutions for providing simplification of operations and compatibility between different IMS entities |
| EP1560368A1 (fr) * | 2004-01-30 | 2005-08-03 | France Telecom | Procédé d'établissement d'une session multimédia entre un équipement appelant et un équipement appelé d'un réseau du type à sous domaine multimédia et système de communication mettant en oeuvre ce procédé |
| US7978684B2 (en) * | 2004-06-15 | 2011-07-12 | Nokia Corporation | Session set-up for time-critical services |
| KR100656401B1 (ko) * | 2004-12-27 | 2006-12-11 | 한국전자통신연구원 | Ｗｌａｎ-ｇｐｒｓ 연동 망에서 ｓｉｐ를 이용한 등록되지않은 가입자의 착신 처리 방법 |
| US7693134B2 (en) * | 2004-12-30 | 2010-04-06 | Alcatel-Lucent Usa Inc. | Method and apparatus for providing multimedia ringback services to user devices in IMS networks |
| EP1705859A1 (en) * | 2005-03-24 | 2006-09-27 | Orange SA | Packet radio network and method for activation of a packet data protocol context |
| KR100910801B1 (ko) * | 2005-05-02 | 2009-08-04 | 엘지전자 주식회사 | Ｓｉｐ 기반의 세션 셋업 방법 및 장치 |
| US20080232306A1 (en) * | 2005-08-24 | 2008-09-25 | Dirk Kopplin | Preserved Bearers |
| US8611334B2 (en) * | 2006-05-16 | 2013-12-17 | Aylus Networks, Inc. | Systems and methods for presenting multimedia objects in conjunction with voice calls from a circuit-switched network |
| US8432899B2 (en) * | 2007-02-22 | 2013-04-30 | Aylus Networks, Inc. | Systems and methods for enabling IP signaling in wireless networks |
| US7809003B2 (en) * | 2007-02-16 | 2010-10-05 | Nokia Corporation | Method for the routing and control of packet data traffic in a communication system |
| US8180375B2 (en) * | 2008-03-31 | 2012-05-15 | At&T Mobility Ii Llc | Potential call drop indicator |
-
2007
- 2007-04-03 ES ES200700881A patent/ES2304879B1/es active Active
-
2008
- 2008-04-03 AT AT08761450T patent/ATE497685T1/de not_active IP Right Cessation
- 2008-04-03 DE DE602008004834T patent/DE602008004834D1/de active Active
- 2008-04-03 US US12/594,813 patent/US8233394B2/en active Active
- 2008-04-03 WO PCT/ES2008/000202 patent/WO2008119860A2/es active Application Filing
- 2008-04-03 EP EP08761450A patent/EP2146512B1/en active Active
Non-Patent Citations (1)
| Title |
|---|
| "{}3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 7)"{} 3GPP TS 23.228 V7.6.0, [Online] 12 Diciembre 2006 (12.12.2006), páginas 1-215, Recuperado de internet: URL:http://www.3gpp.org/ftp/Specs/archive/ 23\_series/ 23.228/23228-760.zip>. Páginas 61-77,100-118. * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2146512B1 (en) | 2011-02-02 |
| US8233394B2 (en) | 2012-07-31 |
| WO2008119860A2 (es) | 2008-10-09 |
| ATE497685T1 (de) | 2011-02-15 |
| EP2146512A2 (en) | 2010-01-20 |
| ES2304879A1 (es) | 2008-10-16 |
| DE602008004834D1 (de) | 2011-03-17 |
| WO2008119860A3 (es) | 2008-12-04 |
| US20100214924A1 (en) | 2010-08-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2304879B1 (es) | Procedimiento para evitar sobrecarga en redes de telefonia movil por 'always-on' en el caso de una llamada entrante. | |
| CN111183662B (zh) | 通过中继用户设备认证用户设备 | |
| US9961526B2 (en) | Emergency call support for VoLTE roaming within S8 home routing architecture | |
| US9374699B2 (en) | Proximity-based service registration method and related apparatus | |
| ES2733213T3 (es) | Método para procesamiento de datos asociados con gestión de sesión y gestión de movilidad | |
| ES2335885T3 (es) | Metodos y aparatos de seleccion de red con prioridad de red local en las regiones fronterizas del pais. | |
| ES2703279T3 (es) | Métodos y nodos para establecer múltiples conexiones de paquetes de datos para un equipo de usuario hacia un punto de acceso | |
| ES2751653T3 (es) | Método y nodos para gestionar acceso a servicios de EPC a través de una red no de 3GPP | |
| ES2446851B2 (es) | Mejoras en redes inalámbricas para soportar comunicación de Servicio de Mensajes Cortos (SMS) en el dominio de la conmutación de paquetes | |
| US20140113609A1 (en) | Notifying a user equipment ue, over a mobile network, of an ue application trigger request from a network application server | |
| ES2719490T3 (es) | Método, dispositivo y sistema para autorización de servicio de proximidad | |
| US20110188411A1 (en) | System and method for packetized emergency messages | |
| ES2906624T3 (es) | Gestión de números de emergencia locales | |
| KR20150115674A (ko) | 롱 텀 에볼루션 네트워크에서 보이스 오버 롱 텀 에볼루션을 위한 등록 향상 방법 및 시스템 | |
| US10887754B2 (en) | Method of registering a mobile terminal in a mobile communication network | |
| ES2307418B1 (es) | Procedimiento para evitar sobrecarga en redes de telefonia movil por "always-on" en el caso de una llamada iniciada por el movil. | |
| EP3163920B1 (en) | Method for processing prose service authorization change, first network element and second network element | |
| WO2016167222A1 (ja) | Ｓｉｐ制御装置、移動通信システム及び緊急呼制御方法 | |
| ES2313173T3 (es) | Entrega de mensaje corto para terminales que itineran entre sistema voip y gsm. | |
| ES2897439T3 (es) | Procesamiento GTP-C distribuido multicapa | |
| WO2017157333A1 (zh) | 寻呼方法及通信系统 | |
| JP2014027550A (ja) | 移動通信システム、移動局、ネットワーク装置及び移動通信方法 | |
| WO2017006696A1 (ja) | Ｓｉｐ制御装置、移動通信システム及び通信制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20081016 Kind code of ref document: A1 |