ES2317445T3 - Sistema y metodo para determinar que un numero maximo de sesiones ip ha sido establecido. - Google Patents
Sistema y metodo para determinar que un numero maximo de sesiones ip ha sido establecido. Download PDFInfo
- Publication number
- ES2317445T3 ES2317445T3 ES06122308T ES06122308T ES2317445T3 ES 2317445 T3 ES2317445 T3 ES 2317445T3 ES 06122308 T ES06122308 T ES 06122308T ES 06122308 T ES06122308 T ES 06122308T ES 2317445 T3 ES2317445 T3 ES 2317445T3
- Authority
- ES
- Spain
- Prior art keywords
- sessions
- request
- mobile device
- maximum number
- network
- 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
- 238000000034 method Methods 0.000 title claims abstract description 62
- 230000006870 function Effects 0.000 claims abstract description 41
- 238000009826 distribution Methods 0.000 claims abstract description 3
- 238000004891 communication Methods 0.000 claims description 53
- 230000004044 response Effects 0.000 claims description 41
- 230000008859 change Effects 0.000 claims description 4
- 230000009849 deactivation Effects 0.000 claims description 3
- 239000002253 acid Substances 0.000 claims 1
- 235000019580 granularity Nutrition 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000003321 amplification Effects 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000003199 nucleic acid amplification method Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- IRLPACMLTUPBCL-KQYNXXCUSA-N 5'-adenylyl sulfate Chemical compound C1=NC=2C(N)=NC=NC=2N1[C@@H]1O[C@H](COP(O)(=O)OS(O)(=O)=O)[C@@H](O)[C@H]1O IRLPACMLTUPBCL-KQYNXXCUSA-N 0.000 description 1
- 208000033368 Right sided atrial isomerism Diseases 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- 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/10—Architectures or entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/04—Arrangements for maintaining operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/02—Access restriction performed under specific conditions
- H04W48/06—Access restriction performed under specific conditions based on traffic conditions
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
-
- 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]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Multimedia (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Emergency Protection Circuit Devices (AREA)
Abstract
Un método de un disopositivo móvil que comprende transmitir (2-1) al menos una solicitud de un tipo predefinido; recibir (2-2) una indicación de que una solicitud dada de la, al menos una, solicitud no puede ser satisfecha debido a que el número máximo de sesiones de Protocolo de Internet ''''IP'''' ya está establecido para el dispositivo móvil; determinar (5-1) el número máximo de sesiones IP soportado para el dispositivo móvil en un área de red dada como el número de sesiones IP establecidas para el dispositivo móvil cuando se recibe la indicación; y habiendo determinado el número máximo de sesiones IP soportado para el dispositivo móvil en el área de red dada, gestionar activamente (5-2, 11-1) el reparto de sesiones IP en donde hay menos sesiones IP que funciones de dispositivo que necesitan sesiones IP, con respecto al número máximo de sesiones IP soportado.
Description
Sistema y método para determinar que un número
máximo de sesiones IP ha sido establecido.
La solicitud se refiere generalmente a la
comunicación sin cable y más concretamente a sesiones de IP.
Las comunicaciones entre dispositivos móviles y
el correspondiente nudo se procesan en una red UTMS (Sistema de
Telecomunicaciones de Móvil Universal) a través de nudos de
servicios GPRS (Servicio de Radio de paquete General). Los nudos de
servicio GPRS incluyen un SGNS (Nudo de Soporte GPRS de Servicio) y
un GGSN (Nudo de soporte GPRS de Puerta). Tal intercambio de
comunicación entre el dispositivo móvil y el correspondiente nudo
implica el intercambio de comunicación entre el dispositivo móvil y
el SGSN. Los intercambios de comunicación tales como la
comunicación en el plano del usuario (por ejemplo tráfico de datos
IP) entre el dispositivo móvil y el nudo SGSN utilizan uno o más
contextos PDP. Puede haber muchos contextos PDP dependiendo de
cuantas aplicaciones diferentes del dispositivo móvil estén
comunicando en los contextos PDP. Sin embargo, el número de
contextos PDP para el dispositivo móvil puede estar limitado por el
número de contextos PDP soportados en el área de encaminamiento en
la que reside en dispositivo móvil.
Diferentes áreas de encaminamiento pueden
soportar diferentes números de contexto PDP. Sin embargo, el
dispositivo móvil ignora cuantos contextos PDP soporta un área de
encaminamiento para el dispositivo móvil. Esto puede llevar a
situaciones indeseables. Por ejemplo, el dispositivo móvil podría
solicitar que un nuevo contexto PDP sea establecido mientras ignora
que el número máximo de sesiones IP está ya establecido. Por lo
tanto, el dispositivo fracasará en el establecimiento de un nuevo
contexto PDP. Además, en algunos casos, el dispositivo móvil
ignora por qué el establecimiento del nuevo contexto PDP no es
exitoso. Si el dispositivo móvil ignora el número máximo de
sesiones IP soportado para el dispositivo móvil, entonces el
dispositivo móvil no puede gestionar adecuadamente los contextos
PDP. Si son solicitados por el usuario más servicios que utilizan un
contexto PDP de los que son soportados por la red, entonces puede
haber alguna clase de multiplexado en la que se retrasen algunos,
etc.
Una posible solución es que el dispositivo móvil
asuma siempre que sólo es soportado un contexto PDP. Sin embargo,
está solución no se aprovecha de que sean soportados los contextos
PDP adicionales. Esto puede dar lugar a usuarios descontentos en
redes que soportaron más de un contexto PDP.
El documento
US-A-6430619 expone una red de
comunicación de datos con una pluralidad de puntos de servidores de
presencia. Una base de datos central contiene un número máximo de
sesiones de red privada virtual para proporcionar a un grupo de
usuarios. Se toman entonces acciones cuando el grupo intenta exceder
este máximo. Esto es una decisión comercial y no concierne a la
capacidad de una red para soportar sólo un número máximo de
usuarios.
De acuerdo con un aspecto amplio, se puede
proporcionar un método en un dispositivo móvil que comprende:
transmitir al menos una solicitud de un tipo predefinido; recibir
una indicación de que una solicitud dada de la al menos una
solicitud no puede ser satisfecha debido a que un número máximo de
sesiones IP ya está establecido para el dispositivo móvil;
determinar el número máximo de sesiones IP soportado para el
dispositivo móvil en un área de red dada siendo el número de
sesiones IP establecidas para el dispositivo móvil cuando la
indicación es recibida; y habiendo determinado el número máximo de
sesiones IP soportado para el dispositivo de móvil en el área de
red dada, gestionando activamente el reparto (5-2,
11-1) de las sesiones IP en las que hay menos
sesiones IP que funciones de dispositivo que necesitan sesiones IP,
en lo que se refiere al número máximo de sesiones IP soportado.
De acuerdo con otro aspecto amplio, se puede
proporcionar un medio que puede leer un ordenador que tiene
almacenadas en el mismo instrucciones ejecutables por un procesador
de manera que se implementen todas las etapas de cualquiera de los
métodos anteriormente resumidos.
De acuerdo con otro aspecto amplio, se puede
proporcionar un dispositivo móvil que comprenda: una radio de
acceso sin cable adaptada para comunicar con una red inalámbrica; y
una función de gestión de sesión IP adaptada para: transmitir al
menos una solicitud de un tipo predefinido; recibir una indicación
de que una solicitud no puede ser satisfecha debido a que ya está
establecido un número máximo de sesiones IP para el dispositivo
móvil; determinar el número máximo de sesiones IP soportado para el
dispositivo móvil en un área de red dada como el número de sesiones
IP establecido para el dispositivo móvil cuando se recibe la
indicación; y habiendo determinado el número máximo de sesiones IP
soportado para el dispositivo móvil en el área de red dada,
gestionar activamente el reparto (5-2,
11-1) de las sesiones IP cuando haya menos sesiones
IP que las funciones de dispositivo que necesitan sesiones IP, en
lo referente al número máximo de sesiones IP soportado.
De acuerdo con otro aspecto amplio, se puede
proporcionar un método en una red inalámbrica que comprende: tras
recibir desde un dispositivo móvil que reside en un área de red dada
una solicitud de un tipo predefinido: determinar si existe un
número máximo de sesiones IP ya establecido para el dispositivo
móvil para el área de red dada; y si el número máximo de sesiones
IP ya está establecido. Transmitir al dispositivo móvil una
respuesta indicando que la solicitud no puede ser satisfecha debido
a que ya está establecido el número máximo de sesiones IP.
\newpage
De acuerdo con otro aspecto amplio, se puede
proporcionar un medio que pueda leer un ordenador que tenga
instrucciones ejecutables por el ordenador almacenadas en el mismo
para la ejecución por un procesador de manera que se lleva a cabo
el método resumido anteriormente.
De acuerdo con otro aspecto amplio, se puede
proporcionar una red inalámbrica que comprende una función de
sesión IP adaptada para: tras recibir de un dispositivo móvil que
reside en un área de red dada una solicitud de un tipo predefinido:
determinar si existe un número máximo de sesiones IP ya establecido
para el dispositivo móvil para el área de red dada; y si el número
máximo de sesiones IP ya está establecido, transmitir al dispositivo
móvil una respuesta que indica que la solicitud no puede ser
satisfecha debido a que el número máximo de sesiones IP ya está
establecido.
\vskip1.000000\baselineskip
Las realizaciones se describirán con referencia
a los dibujos adjuntos en los que:
La Fig. 1A es un diagrama de bloques de una red
inalámbrica a modo de ejemplo y un dispositivo móvil;
la Fig. 1B es un diagrama de bloques del
dispositivo móvil mostrado en la Fig. 1A;
la Figura 1C es un diagrama de bloques de otro
dispositivo móvil;
la Fig. 2 es una carta de flujo de un método a
modo de ejemplo de determinación de que el número máximo de
sesiones IP ya está establecido;
la Figura 3A y 3B son tablas de un elemento de
información de causa GMM;
las Figuras 4A y 4B son tablas de un ejemplo de
elemento de información de causa SM;
las Figuras 5 a 7 son cartas de flujo de los
métodos a modo de ejemplo de gestión de sesiones IP basadas en el
número máximo de sesiones IP que puede ser soportado para el
dispositivo móvil; y
la Figura 8 es una carta de flujo de un método
de determinación del número de contextos PDP soportados;
la Figura 9 es una carta de flujo de un método
de mantenimiento de la información de historia;
la Figura 10 es una tabla de un formato a modo
de ejemplo en el cual la información de historia se puede
mantener;
la Figura 11 es una carta de flujo de un método
a modo de ejemplo de mapeo de sesiones IP; y
la Figura 12 es una carta de flujo de un método
a modo de ejemplo de transmisión de una respuesta que indica que
una solicitud no puede ser satisfecha debido a que el número máximo
de sesiones IP ya está establecido;
\vskip1.000000\baselineskip
Haciendo ahora referencia a la Figura 1A, se
muestra un diagrama de bloques de una red inalámbrica a modo de
ejemplo 100 y un dispositivo móvil 10. La red inalámbrica 100 tiene
una primera área de encaminamiento 30 y una segunda área de
encaminamiento 40. Puede haber otras áreas de encaminamiento, pero
no están mostradas por simplificación. Cada área de encaminamiento
tiene al menos un RNC (Controlador de Red de Radio). En el ejemplo
ilustrado, la primera área de encaminamiento 30 tiene un primer RNC
31 y un segundo RNC 32 mientras que la segunda área de
encaminamiento 40 tiene un único RNC 41. Cada RNC 31, 32, 41 está
asociado con un respectivo RNC Id. El primer RNC 31 y el segundo
RNC 32 de la primera área de encaminamiento 30 tiene un Id RNC 31a y
Id RNC 32a, respectivamente, mientras que el único RNC 41 de la
segunda área de encaminamiento 40 tiene un Id RNC 41a. Cada celda
(no mostrada) dentro de un RNC (a través de un Nudo B) está asociada
con una RAI (Identificación de Área de Encaminamiento) de una
manera jerárquica. Una RAI puede incluir una o más celdas y
extenderse a través de los RNCs. En algunas implementaciones, cada
RAI es una combinación de un código de país, un código de red y un
código de área de encaminamiento. Las RAIs pueden ser diferentes
para otras redes inalámbricas.
En el ejemplo ilustrado, cada RNC 31, 32, 41
está unido a un SGSN (Nudo de soporte de servicios de radio de
Paquete General de Servicio) 50, que a su vez está unido a un GGSN
(Nudo de Soporte de GPRS de Puerta) 60, que a su vez está unido a
una PDN (Red de Datos de Paquete) 70. La PDN 70 puede, por ejemplo,
ser Internet. El SGSN 50 tiene una función de sesión IP 51 unida a
un procesador 52 y puede tener otros componentes, pero no se
muestran por simplificación.
\newpage
La red inalámbrica 100 se muestra con un único
dispositivo móvil, a saber, el dispositivo móvil 100. Puede haber
otros dispositivos móviles, pero no se muestran por simplificación.
Con referencia a la Figura 1B, se muestra un diagrama de bloques
del dispositivo móvil 10 mostrado en al Figura 1A. El dispositivo
móvil 10 tiene un procesador 12, que está acoplado a una radio de
acceso sin cable 11, una función de gestión de sesión IP 13,
aplicaciones 14, y una interfaz de usuario 15. El dispositivo móvil
10 puede tener otros componentes, pero no se muestran por
simplificación. Con referencia de nuevo a la Figura 1A, el
dispositivo móvil 10 está actualmente situado dentro de la primera
área de encaminamiento 31. Sin embargo, el dispositivo móvil 10
puede moverse a otra área de encaminamiento tal como la segunda
área de encaminamiento 40 indicada mediante la flecha de movimiento
19.
Durante el funcionamiento, el dispositivo móvil
10 está adaptado para comunicarse con la red inalámbrica 100
utilizando su radio de acceso inalámbrica 11. Tal comunicación puede
por ejemplo ser comunicación de voz, mensajes electrónicos, o
cualquier otra forma apropiada de comunicación soportada por las
aplicaciones 14. Al menos alguna comunicación con la red
inalámbrica 100 está sobre una o más sesiones IP entre el
dispositivo móvil 10 y el SGSN 50. Una sesión de PDP (Protocolo de
Paquete de Datos) es un ejemplo de una sesión IP. Puede haber
muchas sesiones IP entre el dispositivo móvil 10 y el SGSN 50
dependiendo de cuántas de las aplicaciones 14 tengan una sesión IP
establecida. Sin embargo, el número de sesiones IP está típicamente
limitado por el área de encaminamiento en la que el dispositivo
móvil 10 reside, que actualmente es la primera área de
encaminamiento 30.
Hay casos en los que el dispositivo móvil 10
transmite una solicitud de un tipo predeterminado tal como una
Solicitud de Sesión IP Activada o una Solicitud de Servicio de
Sesión IP. La red inalámbrica 100 recibe la solicitud y determina
si hay un número máximo de sesiones IP ya establecidas para el
dispositivo móvil 10. De acuerdo con una realización de la
aplicación, la función de sesión IP 51 implementa un método en la
red inalámbrica 100 de manera que en el caso de que el número
máximo de sesiones IP ya esté establecido para el dispositivo
móvil, la red inalámbrica transmite una respuesta que indica que la
solicitad requerida no puede ser satisfecha debido a que el número
máximo de sesiones IP ya está establecido. El dispositivo móvil 10
recibe la respuesta. De acuerdo con otra realización de la
aplicación, la función de gestión de sesión IP 13 implementa un
método en el dispositivo móvil 10 de manera que determina, sobre la
base de las respuestas, que el número máximo de sesiones IP ya está
establecido. Esto permite que el dispositivo móvil 10 determine el
número máximo de sesiones IP que se pueden soportar de manera que
por consiguiente las sesiones IP se pueden gestionar por el
dispositivo móvil 10. Se proporcionan a continuación detalles
adicionales con referencia a las Figuras 2 a 11.
En el ejemplo ilustrado, se supone que dentro de
cada área de encaminamiento están soportadas el mismo número de
sesiones IP para el dispositivo 10 independientemente de cuantos RNC
estén presentes. Típicamente un área de encaminamiento tiene un
único RNC, tal es el caso con la segunda área de encaminamiento 40.
El número de sesiones IP soportado para un dispositivo móvil está
actualmente limitado por el RNC. Por lo tanto, aunque el factor
limitante es realmente el RNC, el área de encaminamiento puede
típicamente ser considerada como el factor limitante. Sin embargo,
un área de encaminamiento podría tener más de un RNC, tal es el caso
con la primera área de encaminamiento 30. Por lo tanto, es posible
que un área de encaminamiento soporte un número diferente de
contextos PDP para un dispositivo móvil dependiendo del área de
encaminamiento en donde resida el dispositivo móvil. Este es el
caso en el que el área de encaminamiento no puede ser considerada
como el factor limitante. Aunque los ejemplos presentados aquí se
refieren a "áreas de encaminamiento" que limitan el número de
sesiones IP para el dispositivo móvil, se ha de entender que de
manera más general un "área" de la red limita el número de
sesiones IP para el dispositivo móvil. El "área" puede ser un
área de encaminamiento, una parte de un área de encaminamiento como
está definida por ejemplo por un RNC Id, una red, una celda id, o
cualquier otra área en la que el número de sesiones IP soportado
para el dispositivo móvil esté limitado.
En algunas implementaciones, hay sutilezas entre
el estado Conectado/Activo (Celda_DHC, Celda_FACH) y el estado
Parado (Celda_PCH, URA_PCH, PARADO) para el dispositivo móvil. El
área de encaminamiento se conoce para el dispositivo móvil mientras
está en el estado parado; sin embargo, el id RNC no es típicamente
conocido. Mientras está en el estado Parado, un dispositivo móvil
se mueve al estado Conectado/Activo para averiguar su id RNC de
servicio. Esto puede consumir la vida de la batería, etc. Por lo
tanto, en algunas implementaciones, el número de sesiones IP
soportado se considera para un área de encaminamiento
independientemente de si éste es el nivel más bajo de
granularidad.
Existen muchas posibilidades para la función de
gestión de sesión IP 13 de un dispositivo móvil 10. En el ejemplo
ilustrado, la función de gestión de sesión 13 se implementa como
software y se ejecuta en el procesador 12. Sin embargo, de manea
más general, la función de gestión de sesión IP 13 se puede
implementar como software, hardware, firmware o cualquier
combinación apropiada de los mismos. En el ejemplo ilustrado, la
función de gestión de sesión IP 13 se muestra como un único
componente. Sin embargo, de manera más general, la función de
gestión de sesión 13 se puede implementar como uno o más
componentes. Un ejemplo en el que la función de gestión de sesión
de IP 13 incluye más de un componente se describe a
continuación.
En algunas implementaciones, la función de
gestión de sesión IP 13 incluye un NAS (Estrato Sin Acceso) un AS
(Estrato de Acceso). El NAS incluye una capa de gestión de sesión y
gestiona las sesiones IP. El NAS puede por ejemplo iniciar un
mensaje de solicitud de contexto PDP para que sea enviado al SGSN
50. El AS gestiona una interfaz de aire de la radio de acceso sin
cable 11 e incluye un respectivo RAB (Soporte de Acceso de Radio)
para cada sesión IP activa. Un RAB es un identificador para un canal
RF (radio Frecuencia). Puede haber sesiones IP latentes sin
respectivas RABs. El AS puede por ejemplo iniciar un mensaje de
solicitud de servicios para ser enviado al RNC.
Existen muchas posibilidades para la función de
sesión IP 51 de la red inalámbrica 100. En el ejemplo ilustrado, la
función de sesión IP 51 es implementada como software y es ejecutada
en un procesador 52. Sin embargo, de manera más general, la función
de sesión IP 51 puede ser implementada como software, hardware,
firmware o cualquier combinación apropiada de los mismos. En el
ejemplo ilustrado, la función de sesión IP 51 se muestra como un
único componente del SGSN 50. Sin embargo, de manera más general, la
función de sesión IP 51 puede ser implementada como uno o más
componentes y puede ser implementada como parte de, o separada de,
el SGSN 50. El uno o más componentes pueden ser distribuidos a
través de la red inalámbrica 100 o residir en una posición común.
Son posibles otras implementaciones.
Existen muchas posibilidades para la red
inalámbrica 100. En el ejemplo ilustrado, la red inalámbrica 100 es
una red UTMS (Sistema de Telecomunicaciones de Móvil Universal). Sin
embargo, de manera más general, la red inalámbrica 100 puede ser
una red inalámbrica en la que las áreas de encaminamiento restringen
cuantas sesiones IP se pueden establecer para un dispositivo móvil
dado.
Existen muchas posibilidades para el dispositivo
móvil 10. Haciendo ahora referencia a la Figura 1C, se muestra un
diagrama de bloques de otro dispositivo móvil 80 que puede
implementar cualquiera de los métodos descritos aquí. Se ha de
entender que el dispositivo móvil 80 se muestra con detalles muy
específicos sólo a modo de ejemplo.
Un dispositivo de procesamiento (un
microprocesador 128) se muestra esquemáticamente unido entre un
teclado 114 y un elemento de presentación 126. El microprocesador
128 controla el funcionamiento del elemento de presentación 126,
así como el funcionamiento total del dispositivo móvil 80, en
respuesta a la actuación de las teclas en el teclado 114 por un
usuario.
El dispositivo móvil 80 tiene un alojamiento que
puede ser verticalmente alargado, o puede adoptar otros tamaños y
formas (incluyendo estructuras de alojamiento de valva de almeja).
El teclado 114 puede incluir una tecla de selección de modo, u otro
hardware o software para la conmutación entre la entrada de texto y
la entrada de telefonía.
Además del microprocesador 128, se muestran
esquemáticamente otras partes del dispositivo móvil 80. Estas
incluyen: un subsistema de comunicaciones 170; un subsistema de
comunicaciones de corto alcance 102; el teclado 114 y el elemento
de presentación 126, junto con los dispositivos de entrada/salida
que incluyen un conjunto de LEDS 104, un conjunto de dispositivos
I/O (entrada/salida) auxiliares 106, un puerto en serie 108, un
altavoz 11 y un micrófono 112, así como dispositivos de memoria que
incluyen una memoria temporal 116 y una Memoria de Acceso Aleatoria
(RAM) 118; y otros diversos subsistemas de dispositivo 120. El
dispositivo móvil 80 puede tener una batería 121 para alimentar los
elementos activos del dispositivo móvil 80. El dispositivo móvil 80
es en algunas realizaciones un dispositivo de comunicación de radio
frecuencia (RF) de dos direcciones que tiene capacidades de
comunicación de voz y datos. Además, el dispositivo móvil 80 en
algunas realizaciones tiene la capacidad de comunicarse con otros
sistemas de ordenador a través de Internet.
El software de sistema de funcionamiento
ejecutado por el microprocesador 128 está en algunas realizaciones
almacenado en un almacén permanente, tal como la memoria temporal
116, pero puede estar almacenado en otros dispositivos de memoria,
tales como una memoria de sólo lectura (ROM) o un elemento de
almacenamiento similar. Además, el software del sistema. Las
aplicaciones del dispositivo específicas, o partes del mismo, pueden
estar temporalmente cargadas en un almacén volátil tal como la RAM
118. Las señales de comunicación recibidas por el dispositivo móvil
80 también pueden ser almacenadas en el RAM 118.
El microprocesador 128, además de sus funciones
de sistema de funcionamiento, es capaz de la ejecución de
aplicaciones de software sobre el dispositivo móvil 80. Un conjunto
predeterminado de aplicaciones de software, tales como un módulo de
comunicación de voz 130A y un módulo de comunicación de datos 130B,
pueden estar instalados en el dispositivo móvil 80 durante la
fabricación. Además, un módulo de aplicación de gestión de
información personal (PIM) 130C también puede estar instalado en el
dispositivo móvil 80 durante la fabricación. La aplicación de PIM
es, en algunas realizaciones, capaz de organizar y gestionar
artículos de datos, tales como, artículos de correo electrónico,
eventos de calendario, mensajes de voz, citas, y de tareas. La
aplicación de PIM también es, en algunas realizaciones, capaz de
enviar y recibir artículos de datos a través de una red inalámbrica
110. En algunas realizaciones, los artículos de datos gestionados
por la aplicación de PIM son integrados sin juntura, sincronizados
y actualizados a través de la red inalámbrica 110 con los artículos
de datos correspondientes al dispositivo de usuario almacenados o
asociados con un sistema de ordenador anfitrión (host). También, los
módulos de software adicional, ilustrados como otro módulo de
software 130N, pueden ser instalados durante la fabricación.
Las funciones de comunicación, que incluyen
comunicaciones de datos y voz, se realizan a través del subsistema
de comunicación 170 y posiblemente a través del subsistema de
comunicaciones de corto alcance 170. El subsistema de comunicación
170 incluye un receptor 150, un transmisor 152 y uno o más antenas,
ilustradas como una antena de recepción 154 y una antena de
transmisión 156. Además, el subsistema de comunicación 170 incluye
también un módulo de procesamiento, tal como un procesador de señal
digital (DSP) 158 y osciladores locales (LOs) 160. El diseño
específico y la implementación del subsistema de comunicación 170
dependen de la red de comunicación en la que esté destinado o
funcionar el dispositivo móvil 80. Por ejemplo, el subsistema de
comunicación 170 del dispositivo móvil 80 puede estar diseñado para
funcionar con el Mobitex^{TM}, DataTAC^{TM} o redes de
comunicación de datos de móvil de Servicio de Radio de Paquete
General (GPRS) y también diseñado para funcionar con cualquier
variedad de redes de comunicación de voz, tal como el Servicio de
Teléfono Móvil Avanzado (AMPS), Acceso Múltiple de División de
Tiempo (TDMA), Acceso Múltiple de División de Código CDMA, Servicios
de Comunicaciones Personal (PCS) Sistema Global para Comunicaciones
de Móvil (GSM), etc. También se pueden utilizar con el dispositivo
móvil 80 otros tipos de redes de voz y de datos, tanto separadas
como integradas.
El acceso de red puede variar dependiendo del
tipo de sistema de comunicación. Por ejemplo, en las redes
Mobitex^{TM} y DataTAC^{TM}, los dispositivos móviles son
registrados en la red utilizando un único Número de Identificación
Personal (PIN) asociado con cada dispositivo. En redes GPRS, sin
embargo, el acceso de red está típicamente asociado con un
subscriptor o usuario del dispositivo. Por tanto, un dispositivo
GPRS tiene típicamente un módulo de identidad de subscriptor,
comúnmente referido con tarjeta de Módulo de Identidad de
Subscriptor (SIM), para funcionar en una red GPRS.
Cuando los procedimientos de registro o
activación de red han sido completados, el dispositivo móvil 80
puede enviar y recibir señales de comunicación en la red de
comunicación 110. Las señales recibidas desde la red de
comunicación 110 por la antena de recepción 154 son conducidas al
receptor 150, lo que proporciona la amplificación de señal,
conversión de baja frecuencia, filtrado, selección de canal, etc., y
puede también proporcionar conversión analógica a digital. La
conversión analógica a digital de la señal recibida permite que el
DSP 158 realice más funciones de comunicación complejas, tales como
la desmodulación o descodificación. De manera similar, las señales
que van a ser transmitidas a la red 110 son procesadas (por ejemplo,
moduladas y codificadas) por el DSP 158 y son después
proporcionadas al transmisor 152 para la conversión de digital a
analógica, conversión de alta frecuencia, filtrado, amplificación y
transmisión a la red (o redes) de comunicación 110 a través de la
antena de transmisión 156.
Además de procesar las señales de comunicación,
el DSP mantiene el control del receptor 150 y del transmisor 152.
Por ejemplo, las ganancias aplicadas a las señales de comunicación
en el receptor 150 y el transmisor 152 pueden ser controladas de
manera adaptativa a través de algoritmos de control de ganancia
automáticos implementados en el DSP 158.
En el modo de comunicación de datos, una señal
recibida, tal como un mensaje de texto o descarga de página web, es
procesada por el subsistema de comunicación 170 y es introducida en
el microprocesador 128. La señal recibida es entonces procesada
adicionalmente por el microprocesador 128 para una salida del
elemento de presentación 126, o alternativamente a algún otro
dispositivo I/O auxiliar 106. Un usuario de dispositivo también
puede componer artículos de datos, tales como mensajes de correo
electrónico, utilizando el teclado 114 y/o algún otro dispositivo
I/O auxiliar 106, tal como una zona táctil, un interruptor
oscilante, una rueda de pulgar, o algún otro tipo de dispositivo de
entrada. Los artículos de datos compuestos pueden entonces ser
transmitidos sobre la red de comunicación 110 a través del
subsistema de comunicación 170.
En un modo de comunicación de voz, el
funcionamiento total del dispositivo es sustancialmente similar al
modo de comunicación de datos, excepto en que las señales recibidas
son extraídas a un altavoz 111, y las señales para la transmisión
son generadas por un micrófono 112. Los subsistemas de I/O de voz o
audio alternativos, tales como un subsistema de registro de mensaje
de voz, también pueden ser implementados en el dispositivo móvil
80. Además, el elemento de presentación 126 también puede ser
utilizado en el modo de comunicación de voz, por ejemplo, para
presentar la identidad del grupo que llama, la duración de una
llamada de voz, o otra información de llamada de voz.
El subsistema de comunicación de corto alcance
102 hace posible la comunicación entre el dispositivo móvil 80 y
otros subsistemas o dispositivos próximos, que no necesitan
necesariamente ser dispositivos similares. Por ejemplo, el
subsistema de comunicaciones de corto alcance puede incluir un
dispositivo de infrarrojos y circuitos y componentes asociados, o
un módulo de comunicación de Bluetooth^{TM} para mantener
comunicación con sistemas y dispositivos capacitados de manera
similar.
Haciendo ahora referencia a la Figura 2, se
muestra una carta de flujo de un método a modo de ejemplo de
determinación de que ya se ha establecido el máximo número de
sesiones IP. Este método puede ser implementado en un dispositivo
móvil, por ejemplo, por la función de gestión de prioridad de sesión
IP 13 del dispositivo móvil 10 mostrado en la Figura 1B, o por el
dispositivo móvil 80 mostrado en la Figura 1C.
En la etapa 2-1, el dispositivo
móvil trasmite una solicitud de un tipo predefinido. La red
inalámbrica recibe y procesa la solicitud. En este ejemplo, se
supone que la red inalámbrica no puede satisfacer la solicitud
debido a que el número máximo de sesiones IP ya está establecido
para el dispositivo móvil. La red inalámbrica transmite una
respuesta que es recibida por el dispositivo móvil en la etapa
2-2. La respuesta indica que la solicitud no puede
ser satisfecha debido a que ya está establecido el número máximo de
sesiones IP para el dispositivo móvil. En la etapa
2-3, el dispositivo móvil determina sobre la base de
la respuesta que el máximo número de sesiones IP ya está
establecido.
Hay muchas formas de que la respuesta pueda
indicar que la solicitud no puede ser satisfecha debido a que el
número máximo de sesiones IP ya está establecido para el dispositivo
móvil. En algunas implementaciones, la respuesta incluye un código
de causa que indica que la solicitud no puede ser satisfecha debido
a que el número máximo de sesiones IP ya está establecido para el
dispositivo móvil. De manera más general, la respuesta puede
incluir cualquier indicación apropiada de que la solicitud no puede
ser satisfecha debido a que el máximo número de sesiones IP ya está
establecido para el dispositivo móvil.
Haciendo ahora referencia a la Figura 3A y 3B,
se muestran tablas de un elemento de información de causa GMM a
modo de ejemplo. Se ha de entender que el elemento de información de
causa GMM mostrado en el ejemplo ilustrado es una implementación
específica de un código de causa sólo con fines de ejemplo. La
finalidad del elemento de información de causa GMM es indicar la
razón de por qué una solicitud GMM procedente del dispositivo móvil
es rechazada por la red inalámbrica. Como se muestra en la Figura
3A, la causa de GMM es un elemento de información de tipo 3 con
longitud de dos octetos. El segundo octeto es para el valor de
causa. Como se muestra en la Figura 3B, son posibles muchos valores
de causa. El valor de causa "01100110" indica que el número
máximo de contextos PDP ya ha sido activado. En algunas
implementaciones el valor de causa es parte de las causas referidas
a fallos de red específicos PLMN y Fallos de
congestión/Autentificación.
Haciendo ahora referencia a las Figuras 4A y 4B,
se muestran tablas de un ejemplo de elemento de información de
causa SM. Se ha de entender que el elemento de información de causa
SM mostrado en el ejemplo ilustrado es una implementación
específica de un código de causa a modo de ejemplo. La finalidad del
elemento de información de causa SM es indicar la razón de por qué
una solicitud de gestión de sesión es rechazada. Como se muestra en
la Figura 4A, la causa SM es un elemento de información de 3 tipos
con dos octetos de longitud. El segundo octeto es para el valor de
causa. Como se muestra en la figura 4B, son posibles muchos valores
de causa. El valor de causa "01100110" indica que el máximo
número de contextos PDP ya ha sido activado, En algunas
implementaciones, el valor de causa es parte de los valores de
causa para Gestión de Sesión GPRS.
En algunas implementaciones, un valor de causa
de 102 indica que el número máximo de contextos PDP ya ha sido
activado. De manera más general, cualquier valor de causa apropiado
puede ser implementado.
Hay muchas posibilidades para la solicitud del
tipo predefinido y la respuesta. En algunas implementaciones, el
tipo de respuesta depende del tipo de solicitud. A continuación, se
proporcionan ejemplos.
En un ejemplo, la solicitud puede ser una
Solicitud de Sesión de IP activada para solicitar que se establezca
una nueva sesión IP, mientras la respuesta sea un Rechazo de Sesión
IP Activa para rechazar la Solicitud de sesión IP. En algunas
implementaciones, la solicitud de Sesión de IP activa es una
solicitud de contexto PDP Activa mientras la respuesta sea un
Rechazo de contexto PDP Activo.
En otro ejemplo, la solicitud es una solicitud
de Servicio de sesión IP para solicitar el servicio para una sesión
IP existente, mientras la respuesta es un Rechazo de servicio IP
para rechazar la Solicitud de Servicio de sesión IP. En algunas
implementaciones, la Solicitud de Servicio de sesión IP es una
solicitud de servicios y el rechazo de Servicio IP es un Rechazo de
Servicio.
En otro ejemplo, la solicitud es una solicitud
de contexto PDP activa para solicitar que un nuevo contexto PDP sea
establecido, mientras la respuesta sea un Rechazo desactivado de
PDP MT para desactivar un contexto PDP existente. Esto puede
ocurrir, por ejemplo, si el dispositivo móvil transmite la solicitud
de contexto PDP Activa en un área que no soporta suficientes
contextos PDP para satisfacer la solicitud. En este ejemplo, dado
que el nuevo contexto PDP no está inicialmente establecido en
respuesta a la solicitud de contexto PDP activa, la solicitud se
considera que es no está satisfecha. Sin embargo, en alguna
implementación, después de que un contexto PDP existente sea
desactivado, el nuevo contexto PDP que fue solicitado se
establece.
En otro ejemplo, una solicitud de una respuesta
RAU para solicitar cambiar a una nueva área de encaminamiento,
mientras que la respuesta es un Solicitud Desactivada MT PDP para
desactivar un contexto PDP existente. Esto puede ocurrir, por
ejemplo, si el dispositivo móvil transmite la solicitud RAU después
de moverse a una nueva área de encaminamiento que no soporta
sufrientes contextos PDP para satisfacer la solicitud. Son posibles
otras solicitudes y respuestas correspondientes.
Se han proporcionado anteriormente mensajes a
modo de ejemplo para la respuesta a la solicitud. En algunas
implementaciones, los mensajes están basados en mensajes definidos
en 3GPP (Proyecto de Asociaciones de 3ª Generación) TS 24.008
V7.5.0 con modificación apropiada para indicar que la solicitud no
puede ser satisfecha debido a que el máximo número de sesiones IP
ya se ha establecido para el dispositivo móvil. Son posibles otras
implementaciones.
En algunas implementaciones, el tipo de
solicitud depende del estado del dispositivo móvil. Por ejemplo, el
tipo de solicitud puede variar dependiendo de si el dispositivo
móvil está en estado Parado comparado con el Estado
Activo/conectado. En algunas implementaciones, el dispositivo móvil
podría transmitir un mensaje de Solicitud de Servicio de Sesión IP
de manera que se solicite el servicio para una Sesión IP extiende
mientras está en el Estado Activo/Conectado. Sin embargo, en
algunas implementaciones, el dispositivo móvil nunca transmite un
mensaje de Solicitud de Servicio de Sesión IP mientras está en el
estado parado. En algunas implementaciones, las solicitudes del
tipo predefinido son transmitidas sólo mientras el dispositivo móvil
está en el Estado Activado/Conectado. Son posibles otras
implementaciones.
En algunas implementaciones, el dispositivo
móvil gestiona las sesiones IP sobre la base del máximo número de
sesiones IP que se puede soportar para el dispositivo móvil. Un
ejemplo se proporciona con referencia a la Figura 5. En la etapa
5-1, el dispositivo móvil determina el máximo número
de sesiones IP que se puede soportar para el dispositivo móvil
sobre la base de la respuesta. En la etapa 5-2, el
dispositivo móvil gestiona las sesiones IP sobre la base del máximo
número de sesiones IP que puede ser soportado para el dispositivo
móvil.
Existen muchas formas para que el dispositivo
móvil determine el número máximo de sesiones IP que puede ser
soportado. En algunas implementaciones, la manera en la cual el
dispositivo móvil determina el número máximo de sesiones IP que se
puede soportar depende de la solicitud del tipo predefinido. Por
ejemplo, si la solicitud es una solicitud de contexto PDP Activado
y el dispositivo móvil conoce cuantas sesiones IP están
establecidas antes de la solicitud, entonces después de recibir una
respuesta indicando que la solicitud no puede ser satisfecha debido
a que el máximo número de sesiones IP ya está establecido, el
dispositivo móvil podría determinar que el número máximo de
sesiones IP que se puede soportar es igual a cuantas sesiones IP
están establecidas antes de la solicitud. Existen otras
posibilidades para determinar el número máximo de sesiones IP que se
puede soportar. Se proporcionan más adelante otros ejemplos con
referencia a la Figura 8.
Existen muchas formas de que el dispositivo
móvil pueda gestionar sesiones IP sobre la base del máximo número
de sesiones IP que se pueden soportar para el dispositivo móvil. A
continuación se proporcionan ejemplos con referencia a las Figuras
6 y 7. Se ha de entender que estos ejemplos son específicos y
destinados sólo a ser meros ejemplos. Son posibles otras
implementaciones.
Haciendo primero referencia a la Figura 6, en la
etapa 6-1 el dispositivo móvil acepta una solicitud
procedente de una aplicación para establecer una nueva sesión IP.
La aplicación puede ser cualquier aplicación que se ejecute en el
dispositivo móvil que esté adaptada para comunicarse en una sesión
IP. En la etapa 6-2, el dispositivo móvil determina
si solicita la nueva sesión IP desde la red inalámbrica sobre la
base del máximo número de sesiones IP que se pueden soportar para
el dispositivo móvil. El dispositivo móvil puede por ejemplo
solicitar la nueva sesión IP sólo si el número de sesiones IP que
están establecidas es menor que el máximo número de sesiones IP que
se puede soportar para el dispositivo móvil.
Haciendo referencia a continuación a la Figura
7, en la etapa 7-1 el dispositivo móvil da prioridad
a las sesiones IP. En etapa 7-2, el dispositivo
móvil mantiene las sesiones IP de mayor prioridad delante de las
sesiones IP de menor prioridad cuando las sesiones IP están
restringidas por el máximo número de sesiones IP que se pueden
soportar para el dispositivo móvil.
Se ha de entender que una sesión IP está
indicada de prioridad "alta" cuando su prioridad está
generalmente indicada mayor que otras sesiones IP. En algunas
implementaciones, esta es la sesión IP con la prioridad más alta.
Una sesión IP indicada de prioridad alta puede no ser una sesión IP
de prioridad alta per se, pero sin embargo está indicada de
prioridad más alta que otras sesiones IP.
Existen muchas formas de que el dispositivo
móvil pueda establecer prioridad de las sesiones IP. En algunas
implementaciones, el dispositivo móvil acepta la entrada del usuario
para determinar una respectiva prioridad para cada sesión IP. Por
consiguiente, el dispositivo móvil determina la respectiva prioridad
para cada sesión IP en bases a la entrada del usuario. En otras
realizaciones, el dispositivo móvil mantiene un registro de un
nivel de prioridad predefinido para cada sesión IP de un tipo
predefinido. Por consiguiente, el dispositivo móvil determina la
respectiva prioridad para cada sesión IP sobre la base del
registro. Son posibles otras implementaciones.
En un ejemplo específico de un método que
establece el contexto PDP, cuando un teléfono móvil GPRS establece
un contexto PDP, se determina un Nombre de Punto de Acceso (APN), y
el punto de acceso es entonces utilizado en una interrogación DNS a
una red DNS privada. Este proceso (llamado resolución APN)
proporciona finalmente la dirección IP del GGSN que debería servir
al punto de acceso. En este punto, se puede activar un contexto
PDP.
Las redes GPRS y UTMS tienen una limitación en
el número de contextos PDP simultáneos que son soportados. El
número de contextos PDP puede variar cuando un dispositivo móvil se
mueve entre diferentes partes de una red, o entre diferentes redes.
Actualmente no hay información suministrada al dispositivo móvil
para informarle del número de contextos PDP soportados. El
resultado es que un dispositivo móvil se mueve desde una primera
área en la que hay suficientes contextos PDP soportados para
satisfacer las necesidades del dispositivo móvil hasta una segunda
área en la que no hay suficientes contextos PDP soportados para
satisfacer las necesidades del dispositivo móvil, la red podría
reducir uno o más de los contextos PDP existentes de una manera
impredecible. Este problema está especialmente extendido en redes
UTMS ya que muchas sólo soportan un contexto PDP. En tales redes,
sólo una función de dispositivo puede tener conectibidad en un
tiempo y así los servicios siempre disponibles, tales como el
correo electrónico de impulsión no pueden funcionar simultáneamente
con "surfing" WAP (punto de acceso sin cable) en un APN
específico de red.
Se proporciona un caso basado en el método para
determinar el número de contextos PDP en un área de red dada. Un
área de red dada puede ser toda una red o parte de una red. Lo que
sigue son ejemplos específicos de casos que pueden ocurrir cuando
están activados contextos PDP que son uno más del número
soportado.
- Solicitud Desactivada PDP MT;
- Rechazo Activado PDP
\newpage
En algunas realizaciones, los códigos de causa
dentro de los mensajes son utilizados para permitir la
diferenciación entre las desactivaciones y los rechazos por otras
razones legítimas. Cuando alguno de estos eventos ocurre con el
código de causa correcto, se cuenta el número de contextos PDP
activos y este se almacena como marca de agua al número de
contextos PDP soportados por la red. En algunas realizaciones, las
etapas para determinar el número de PDP soportados se puede hacer
de forma proactiva en el inicio (es decir, descubrimiento) o en el
fondo cuando son solicitadas diferentes APNs.
Haciendo referencia a la Figura 8, se muestra
una carta de flujo de un método para determinar el número de
contextos PDP soportados. Este método se puede llevar a cabo en un
dispositivo móvil, por ejemplo mediante la función de gestión de
prioridad de sesión IP 13 del dispositivo móvil 10 mostrado en la
Figura 1B o mediante el dispositivo móvil 80 mostrado en la Figura
1C. En la etapa 8-1, un dispositivo móvil intenta
establecer contextos PDP simultáneos con un área de red dada y
recibe respuestas a tales intentos. En la etapa 8-2
sobre la base de los intentos para establecer contextos PDP, y las
respuestas a tales intentos, el dispositivo móvil determina un
número de contextos PDP soportados por el área de red dada.
En algunas realizaciones, un valor de fallo para
el número de contextos PDP soportado por un área de red se utiliza
sobre la base de las capacidades de la red inalámbrica. Tal fallo
representará también un número máximo de contextos PDP que una red
puede soportar desde el punto de vista de un dispositivo dado. Por
ejemplo, si un dispositivo móvil dado soporta un máximo de 6
contextos PDP, entonces el valor de fallo inicialmente es 6, y será
reducido una vez que el dispositivo intenta establecer muchos
contextos simultáneos sin éxito.
En algunas realizaciones, establecer un número
de contextos PDP soportados por un área de red dada implica
realizar un contaje de cuantos contextos PDP simultáneos se han
establecido. Esto se puede hacer sobre una base de continuidad al
ser añadidos nuevos contextos. Alternativamente, el contaje se puede
realizar después de que uno de los escenarios indique que no son
soportados más contextos.
En algunas realizaciones, determinar el número
de contextos PDP soportados por el área de red dada implica
observar las respuestas definidas específicas a los intentos de
establecer un contexto PDP. Una vez que tal respuesta definida es
recibida, una conclusión de que el intento más reciente para
establecer un contexto PDP fue un intento para establecer un
contexto PDP más que es soportado por la red actual. Como tal, el
número de contextos PDP soportados por el área de red dada se puede
fijar al número de contextos simultáneos que han sido establecidos.
Esto puede implicar observar un contaje en curso que fue realizado.
O realizar el contaje después de recibir la respuesta definida.
El ajuste de una o más respuestas definidas que
pueden desencadenar el comportamiento anterior es específico de
implementación. Lo que sigue es un conjunto de respuestas definidas
específicas, una o más de las cuales podrían ser implementadas:
una respuesta de rechazo activada PDP con un
código de causa 26;
una respuesta de rechazo activada PDP con código
de causa 38;
una respuesta de rechazo activada PDP con
código de causa 101;
una respuesta que solicita la desactivación de
otro contexto existente;
una respuesta que solicita la liberación del
soporte de radio asociado con otro contexto existente; y
una respuesta específicamente configurada para
indicar que no hay más contextos PDP disponibles.
Haciendo ahora referencia a la Figura 9, se
muestra una carta de flujo de un método para mantener la información
de historia. Este método se puede realizar en un dispositivo móvil,
por ejemplo mediante la función de gestión de prioridad de sesión
IP 13 del dispositivo móvil 10 mostrado en la Figura 1B o mediante
el dispositivo móvil 80 mostrado en la Figura 1C. En la etapa
9-1, para áreas de red previamente visitadas, el
dispositivo móvil mantiene la información de historia indicando el
número de contextos PDP soportados por cada área de red. En la
etapa 9-2, en cada momento tiene lugar un cambio en
el área de red. Si el área de red forma parte de la lista de la
información de historia, el dispositivo móvil observa el número de
contextos PDP soportados por el área de red en la información de
historia, o de otro modo, establece un número de contextos PDP
soportados por el nuevo área de red.
Haciendo ahora referencia a la Figura 10, se
muestra una tabla 200 de un formato a modo de ejemplo en el que se
puede mantener la información de historia. La tabla 200 tiene una
primera columna 202 para almacenar identificadores de área, y una
segunda columna 204 para almacenar el número de contextos PDP
soportados. Una entrada genérica para la tabla se indica en 206. La
información de soporte de contexto se puede mantener en un área de
red la granularidad definida sobre unas bases específicas de
implementación. En algunas realizaciones, la granularidad es para
la del identificador PLMN, y una registro a modo de ejemplo se
indica en 208; en algunas realizaciones la granularidad es para la
de PLMN y LAC (código de área local) combinados, y un registro a
modo de ejemplo se ilustra en 210; en algunas realizaciones la
granularidad es para la de RAC combinado (código de área de
encaminamiento) e ID RNC y un registro a modo de ejemplo está
indicado en 212. Otras granularidades pueden ser utilizadas
alternativamente. La granularidad no necesita ser consistente a
través de todas las áreas de red.
En algunas realizaciones, habiendo determinado
el número de contextos que son soportados, los contextos son
gestionados teniendo en cuenta esta información, por ejemplo,
controlando qué contextos PDP están activados y desactivados para
hacer el comportamiento más predecible. La gestión de contexto es
particularmente útil cuando hay menos contextos PDP que funciones
de dispositivo que necesitan contextos PDP.
Haciendo ahora referencia a la Figura 11, se
muestra una carta de flujo de un método a modo de ejemplo de
gestión de sesiones. Este método puede ser implementado en un
dispositivo móvil, por ejemplo, mediante la función de gestión de
prioridad de sesión IP 13 del dispositivo móvil 10 mostrado en la
Figura 1B o mediante el dispositivo móvil 80 mostrado en la Fig.
1C. En la etapa 11-1, utilizando información que
identifica un número de sesiones IP soportado por un área de red
dada, un dispositivo móvil gestiona activamente el reparto de
sesiones IP en donde hay menos sesiones IP que funciones de
dispositivo que necesitan sesiones IP, con respecto al número de
sesiones IP soportado.
El número de contextos se puede determinar
utilizando cualquiera de los métodos descritos anteriormente. De
manera más general, el dispositivo móvil necesita de alguna manera
haber determinado o conocer el número de contextos soportado. Por
ejemplo, en algunas realizaciones, el dispositivo móvil recibe la
información de soporte de contexto procedente del área de red dada,
por ejemplo cuando el dispositivo móvil se conecta primero en un
área de red. En algunas realizaciones, el dispositivo móvil está
configurado previamente con la información de soporte de contexto
para una pluralidad de áreas de red. En algunas realizaciones, cada
pluralidad de dispositivos móviles determina el número de contextos
PDP soportados por las áreas de red que el dispositivo móvil
visita, y hace que está información esté disponible para la
pluralidad de dispositivos móviles. En algunas realizaciones, el
dispositivo móvil determina la información que identifica el número
de contextos PDP soportados por un área de red dada realizando una
interrogación.
En un ejemplo de gestión de contexto, antes de
cambiar las áreas de red desde una primera área de red a una
segunda área de red en la que son soportados menos contextos PDP que
en la primera área de red, el dispositivo móvil desactiva de
manera vaciada previamente al menos un contexto PDP seleccionado.
Por ejemplo, si se conoce que un primer contexto PDP particular se
debe mantener, pero ese un segundo contexto PDP se puede reducir,
entonces reduciendo el segundo contexto antes de cambiar las áreas
de red, la posibilidad de que el primer contexto no se caiga
después de cambiar las áreas de red aumenta. Este ejemplo supone que
la información de historia de la siguiente red está disponible.
En algunas realizaciones, la gestión activa del
reparto de contextos PDP implica establecer prioridades en las
funciones del dispositivo, y repartir los contextos PDP por
prioridad.
En algunas realizaciones, después de cambiar las
áreas de red de una primera área de red a una segunda área de red
en la cual están soportados menos contextos PDP que en la primera
área de red, el dispositivo móvil determina selectivamente en qué
funciones del dispositivo van a ser repartidos los contextos PDP de
la segunda área de red y establece éstas si no están ya
establecidas y desactiva otras si no están ya desactivadas. El
comportamiento de la nueva red puede ser inapreciable después de
moverse desde una primera área de red hasta una segunda área de red
con menos contextos soportados. Esta solución básicamente implica
ejecutar el movimiento, y después evaluar qué funciones de
dispositivo se dieron contextos PDP y cuales no, y después realizar
los ajustes necesarios estableciendo y/o desactivando
contextos.
Los métodos resumidos anteriormente pueden
encontrar aplicación en escenarios de Intra-RAT
(tecnología de acceso de radio), (por ejemplo con redes WCDMA/UTMS)
así como en escenarios Inter-RAT tales como
transferencia de GPRS a UTMS.
La descripción anterior ha supuesto que es el
número de contextos PDP soportados simultáneamente lo que se va a
determinar, y después se gestiona en algunas implementaciones. De
manera más general, una solución similar se puede utilizar para
determinar el número de sesiones IP simultaneas soportado, siendo un
contexto PDP un ejemplo específico de una sesión IP.
\vskip1.000000\baselineskip
Haciendo ahora referencia a la Figura 12, se
muestra una carta de flujo de un método a modo de ejemplo para
transmitir una respuesta que indica que una solicitud no puede ser
satisfecha debido a que el número máximo de sesiones IP ya está
establecido. Este método se puede realizar en una red inalámbrica,
por ejemplo mediante la función de sesión IP 51 de la red
inalámbrica 100 mostrada en la Figura 1A.
Las etapas de la carta de flujo se ejecutan
después de recibir desde un dispositivo móvil una solicitud de un
tipo predefinido. En la etapa 12-1, la red
inalámbrica determina sin el número máximo de sesiones IP ya está
establecido para el dispositivo móvil. En la etapa
12-2, si el número máximo de sesiones IP ya está
establecido para el dispositivo móvil, entonces la red inalámbrica
transmite al dispositivo móvil una respuesta indicando que la
solicitud no puede ser satisfecha debido a que el número máximo de
sesiones IP ya está establecido.
Hay muchas formas de que la respuesta pueda
indicar que la solicitud no puede ser satisfecha debido a que el
número máximo de sesiones IP ya está establecido para el dispositivo
móvil. Ya se han presentado ejemplos anteriormente y por tanto no
se repetirán aquí.
Existen muchas posibilidades para la solicitud
del tipo predefinido y la respuesta. Ya se han presentado ejemplos
anteriormente y por tanto no se repetirán aquí.
En los ejemplos presentados anteriormente, se
hace referencia a las sesiones IP. Se ha de entender que hay muchas
posibilidades para las sesiones IP. Las sesiones IP pueden, por
ejemplo, incluir cualquiera de las sesiones IP Siempre- Activada,
sesión IP IM (Gestión Instantánea), sesión IP WAP (Protocolo de
Aplicación Inalámbrica), sesión IP MMS (servicio de Mensaje
Multimedia), sesión IP DUN (Acción de red Conmutada), sesión IP
LBS (Servicios de Base de Posición), sesión IP de Módem IP, y sesión
IP PIT (Pulsar para Hablar). La naturaleza de las sesiones IP
específica de implementación y depende típicamente de la red
inalámbrica. en algunas implementaciones, la red inalámbrica es una
red UTMS y cada sesión IP es parte de un respectivo contexto PDP
(Protocolo de Datos de Paquete).
Son posibles numerosas modificaciones y
variaciones de la presente aplicación a la luz de las técnicas
anteriores. Se ha entender, por tanto, que dentro del campo de las
reivindicaciones adjuntas, la aplicación se puede llevar a la
práctica de otra forma distinta a la descrita aquí.
Claims (27)
1. Un método de un dispositivo móvil que
comprende:
transmitir (2-1) al menos una
solicitud de un tipo predefinido;
recibir (2-2) una indicación de
que una solicitud dada de la, al menos una, solicitud no puede ser
satisfecha debido a que el número máximo de sesiones de Protocolo
de Internet "IP" ya está establecido para el dispositivo
móvil;
determinar (5-1) el número
máximo de sesiones IP soportado para el dispositivo móvil en un área
de red dada como el número de sesiones IP establecidas para el
dispositivo móvil cuando se recibe la indicación; y
habiendo determinado el número máximo de
sesiones IP soportado para el dispositivo móvil en el área de red
dada, gestionar activamente (5-2,
11-1) el reparto de sesiones IP en donde hay menos
sesiones IP que funciones de dispositivo que necesitan sesiones IP,
con respecto al número máximo de sesiones IP soportado.
2. El método de la reivindicación 1, en el
que:
transmitir (2-1) la, al menos
una, solicitud comprende y transmitir (8-1) una
pluralidad de solicitudes en un intento para establecer sesiones IP
simultáneas;
recibir (2-2) la indicación
comprende recibir (8-1) respuestas a la pluralidad
de solicitudes; y
determinar (5-1) el número
máximo de sesiones IP soportado comprende determinar
(8-2) un número de sesiones IP soportado por un
área de red dada sobre la base de los intentos para establecer
sesiones IP en las respuestas a tales intentos.
3. El método de la reivindicación 2, en el que
determinar (5-1) el número máximo de sesiones IP
soportado además comprende:
establecer un valor de fallo para el número
máximo de sesiones IP soportado sobre la base de las capacidades de
la red inalámbrica.
4. El método de una cualquiera de las
reivindicaciones 1 a 3, en el que determinar (5-1)
el número máximo de sesiones IP soportado comprende además:
realizar un contaje de cuántas sesiones IP
simultáneas ha sido establecidas.
5. El método de la reivindicación 4, en el que
determinar (5-1) el máximo número de sesiones IP
soportado comprende además:
tras la recepción de una respuesta definida a un
intento para establecer una sesión IP, establecer el número de
sesiones IP soportado por el área de red dada para el contaje de
cuantas sesiones IP simultáneas han sido establecidas.
6. El método de la reivindicación 5, en el que
la respuesta definida es cualquiera de:
una respuesta de rechazo activada de Protocolo
de Datos de Paquete PDP con un código de causa 26;
una respuesta de opción de servicio no funciona
temporalmente, con un código de causa de 34;
una respuesta de rechazo activada PDP con un
código de causa de 38;
una respuesta de rechazo activada PDP con un
código de causa de 101;
una solicitud de respuesta de desactivación de
otro contexto existente;
una solicitud de respuesta de liberación del
soporte de radio asociado con otro contexto existente; o
una respuesta específicamente configurada para
indicar que no hay más contextos PDP disponibles.
7. El método de una cualquiera de las
reivindicaciones 1 a 6 que además comprende:
para áreas de red previamente visitadas,
mantener (9-1) la información de historia (200) que
indica el número máximo de sesiones IP soportado por cada área de
red; y
después de moverse a un nuevo área, si la nueva
área forma parte de la lista de información de historia, observar
(9-2) el máximo número de sesiones IP soportado por
la nueva área de red.
8. El método de la reivindicación 7, en el que
la información de historia (200) es mantenida por las áreas de red
a una granularidad de cualquiera de: Red de Móvil de Tierra Pública
"PLMN" (208); PLMN y código de área local "LAC" (210); o
Código de Área de Encaminamiento "RAC" en Identificador de
Controlador de Red de Radio "Id RNC" (212).
9. El método de cualquiera de las
reivindicaciones 1 a 8 que además comprende:
antes de cambiar las áreas de red de una primera
área de red a una segunda área de red en la que son soportadas
menos sesiones IP que en la primera área de red, desactivar por el
dispositivo móvil de manera vaciada previamente al menos una sesión
IP seleccionada.
10. El método de cualquiera de las
reivindicaciones precedentes, en el que la gestión activa
(5-2, 11-1) del reparto de sesiones
IP comprende:
dar prioridad a sesiones IP de mayor prioridad
delante de las sesiones IP de menor prioridad cuando las sesiones
IP están restringidas por el máximo número de sesiones IP que se
puede soportar para el dispositivo móvil.
11. El método de una cualquiera de las
reivindicaciones 1 a 9, en el que la gestión activa
(5-2, 11-1) del reparto de sesiones
IP comprende:
dar prioridad a las funciones de dispositivo, y
repartir las sesiones IP de acuerdo con la prioridad.
12. El método de las reivindicaciones 1 a 9 ó
11, en el que la gestión activa (11-1) del reparto
de sesiones IP comprende:
después de cambiar las áreas de red de una
primera área de red a una segunda área de red en la que son
soportadas un menor número de sesiones IP que en la primera área
de red, determinar selectivamente en qué funciones de dispositivo
van a ser repartidas las sesiones IP de la segunda área de red, y
establecer éstas si ya no han sido establecidas y desactivar otras
si ya no están desactivadas.
13. El método de una cualquiera de las
reivindicaciones 1 a 12, en el que recibir la indicación
comprende:
recibir (2-2) una respuesta a la
solicitud dada, comprendiendo la respuesta un código de causa que
indica que la solicitud dada no puede ser satisfecha debido a que
el máximo número de sesiones IP ha está establecido para el
dispositivo móvil.
14. El método de la reivindicación 13, en el que
el código de causa tiene un valor de causa de 102 que indica que el
número máximo de sesiones IP ya está activado.
15. El método de la reivindicación 13 ó la
reivindicación 14, en el que:
la solicitud dada es una solicitud de contexto
PDP Activada para solicitar que sea establecido un nuevo contexto
PDP, y la respuesta es un rechazo de contexto PDP Activado para
rechazar la solicitud de contexto PDP Activada; o
la solicitud dada es una solicitud de servicio
de contexto PDP para solicitar servicio para un contexto PDP
existente, y la respuesta es un rechazo de servicio para rechazar la
solicitud de servicio de contexto PDP; o
la solicitud es una solicitud de contexto PDP
Activada para solicitar que se establezca un nuevo contexto PDP, y
la respuesta es una Solicitud Desactivada PDP "MT" de terminal
móvil para desactivar un contexto PDP existente; o
la solicitud dada es una solicitud de
Actualización de Área de Encaminamiento "RAU" para solicitar
cambiar a una nueva área de encaminamiento, y la respuesta en una
Solicitud Desactivada PDP MT para desactivar un contexto PDP
existente.
16. El método de una cualquiera de las
reivindicaciones 1 a 15, que además comprende: aceptar
(6-1) una solicitud procedente de una aplicación
para establecer una nueva sesión IP;
en el que gestionar activamente
(2-2, 11-1) el reparto de sesiones
IP comprende determinar (6-2) si se solicita la
nueva sesión IP de la red inalámbrica sobre la base del máximo
número de sesiones IP soportado.
17. El método de una cualquiera de las
reivindicaciones 1 a 15 comprende además:
dar prioridad (7-1) a sesiones
IP;
en donde gestionar activamente
(5-2, 11-1) el reparto de sesiones
IP comprende gestionar (7-2) sesiones IP de mayor
prioridad delante de sesiones IP de menor prioridad cuando las
sesiones IP están restringidas por el número máximo de sesiones IP
soportado.
18. El método de una cualquiera de las
reivindicaciones 1 a 17, en el que cada sesión IP es parte de un
respectivo contexto PDP.
19. Un medio (13) que puede leer un ordenador
que tiene almacenado en el mismo instrucciones ejecutables por un
procesador (12) de un dispositivo de ordenador para implementar
todas las etapas del método de una cualquiera de las
reivindicaciones 1 a 18.
20. Un dispositivo móvil (10) que comprende:
una radio de acceso sin cable (11) adaptada para
comunicación una red inalámbrica; y
una función de gestión de sesión IP (13)
adaptada para:
transmitir (2-1) al menos una
solicitud de un tipo predefinido;
recibir (2-2) una indicación que
de una solicitud de la, al menos una, solicitud no puede ser
satisfecha debido a que el máximo número de sesiones IP ya está
establecido para el dispositivo móvil;
determinar (5-1) el máximo
número de sesiones IP soportado para el dispositivo móvil en un
área de red dada como el número de sesiones IP establecidas para el
dispositivo móvil cuando la indicación es recibida; y
habiendo determinado el número máximo de
sesiones IP soportado para el dispositivo móvil en el área de red
dada, gestionar activamente (5-2,
11-1) el reparto de sesiones IP cuando hay menos
sesiones IP que funciones de dispositivo que necesitan sesiones IP,
con respecto al número máximo de sesiones IP soportado.
21. Un método en una red inalámbrica, que
comprende:
después de recibir desde un dispositivo móvil
que reside en un área de red dada una solicitud de un tipo
predefinido:
determinar (12-1) si hay un
número máximo de sesiones IP ya establecido para el dispositivo
móvil para el área de red dada; y
si el máximo número de sesiones IP ya está
establecido, transmitir (12-2) al dispositivo móvil
una respuesta que indica que la solicitud no puede ser satisfecha
debido a que el número máximo de sesiones IP ya está
establecido.
22. El método de la reivindicación 21, en el que
la respuesta comprende un código de causa, indicando el código de
causa que la solicitud no puede ser satisfecha debido a que el
máximo número de sesiones IP ya está estable-
cido.
cido.
23. El método de la reivindicación 22, en el que
el código de causa tiene un valor de causa de 102 que indica que el
número máximo de sesiones IP ya está establecido.
24. El método de una cualquiera de las
reivindicaciones 21 a 23, en el que:
la solicitud del tipo predefinido es una
Solicitud de Sesión IP Activada para solicitar que una nueva sesión
IP sea establecida, y la respuesta es un Rechazo de Sesión IP para
rechazar la Solicitud de Sesión IP Activada; o
la solicitud del tipo predefinido es una
solicitud de Servicio de Sesión IP para solicitar servicio para una
sesión IP existente, y la respuesta es un Rechazo de Servicio IP
para rechazar la Solicitud de Servicio de Sesión IP; o
la solicitud del tipo predefinido es una
solicitud de contexto PDP Activada para solicitar que se establezca
un nuevo contexto PDP, y la respuesta es un Rechazo Desactivado PDP
"MT" de terminal móvil para desactivar un contexto PDP
existente; o
la solicitud del tipo predefinido es una
solicitud de Actualización de área de Encaminamiento "RAU" para
solicitar cambiar a una nueva área de encaminamiento, y la
respuesta es una solicitud Desactivada PDP MT para desactivar un
contexto PDP existente.
25. El método de una cualquiera de las
reivindicaciones 21 a 24, en el que cada sesión IP es parte de un
respectivo contexto PDP.
26. Un medio (51) que puede leer un ordenador
que tiene almacenado en el mismo instrucciones ejecutables por un
procesador (52) de un dispositivo de ordenador o sistema de
ordenador para implementar todas las etapas del método de una
cualquiera de las reivindicaciones 21 a 25.
\newpage
27. Una red inalámbrica (100) que comprende una
función (51) de sesión IP adaptada para:
después de recibir desde un dispositivo móvil
residente en un área de red dada una solicitud de un tipo
predefinido:
determinar (12-1) si existe un
número máximo de sesiones IP ya establecido para el dispositivo
móvil para el área de red dada; y
si el número máximo de sesiones IP está ya
establecido, transmitir (12-2) al dispositivo móvil
una respuesta que indica que la solicitud no puede ser satisfecha
debido a que el número máximo de sesiones IP ya está
establecido.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US82342706P | 2006-08-24 | 2006-08-24 | |
| US823427P | 2006-08-24 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2317445T3 true ES2317445T3 (es) | 2009-04-16 |
Family
ID=37404105
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06122308T Active ES2317445T3 (es) | 2006-08-24 | 2006-10-13 | Sistema y metodo para determinar que un numero maximo de sesiones ip ha sido establecido. |
Country Status (8)
| Country | Link |
|---|---|
| EP (1) | EP1898567B1 (es) |
| JP (1) | JP5171913B2 (es) |
| KR (2) | KR101251146B1 (es) |
| CN (3) | CN101309206B (es) |
| AT (1) | ATE415763T1 (es) |
| DE (1) | DE602006003901D1 (es) |
| ES (1) | ES2317445T3 (es) |
| HK (1) | HK1160714A1 (es) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009126072A1 (en) | 2008-04-08 | 2009-10-15 | Telefonaktiebolaget L M Ericsson (Publ) | A poc server and a mobile terminal comprising a poc client for providing poc communication services |
| US8402165B2 (en) * | 2008-05-09 | 2013-03-19 | Research In Motion Limited | Methods and apparatus for prioritizing assignment of a packet data session for a plurality of applications of a mobile communication device |
| CN102938942B (zh) * | 2012-11-20 | 2015-08-05 | 华为终端有限公司 | Pdp连接的自适应处理方法及其装置、终端设备 |
| CN102984815A (zh) * | 2012-12-07 | 2013-03-20 | 华为终端有限公司 | 分组数据连接的处理方法、终端设备、网络侧设备及系统 |
| EP3195676B1 (en) | 2014-08-22 | 2022-04-13 | Samsung Electronics Co., Ltd. | Apparatus and method for operating resource in wireless local area network system supporting multi-user transmission scheme |
| CN111800889B (zh) * | 2019-08-27 | 2022-05-20 | 维沃移动通信有限公司 | 一种处理协议数据单元会话的方法、终端设备和网络设备 |
| CN112153678B (zh) * | 2020-09-09 | 2023-07-14 | Oppo广东移动通信有限公司 | 会话管理方法、装置、相关设备及存储介质 |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6430619B1 (en) | 1999-05-06 | 2002-08-06 | Cisco Technology, Inc. | Virtual private data network session count limitation |
| DE19950653B4 (de) * | 1999-10-21 | 2020-01-16 | Ipcom Gmbh & Co. Kg | Verfahren zum Betreiben eines Mobilfunknetzes |
| US7320032B2 (en) * | 2001-05-21 | 2008-01-15 | Hewlett-Packard Development Company, L.P. | Methods and structure for reducing resource hogging |
| US6975863B1 (en) * | 2001-12-11 | 2005-12-13 | Cisco Technology, Inc. | System and method for selecting a wireless serving node |
| US7061887B2 (en) * | 2002-01-25 | 2006-06-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Multiple mobile IP sessions with dynamically allocated home IP address |
| FR2848052B1 (fr) * | 2002-11-29 | 2005-03-18 | Orange France | Systeme et procede de selection dans un terminal pour une architecture dediee a un reseau de communication |
| JP2004187094A (ja) * | 2002-12-04 | 2004-07-02 | Mitsubishi Electric Corp | 通信確立装置 |
| JP4044855B2 (ja) * | 2003-02-17 | 2008-02-06 | 日本電信電話株式会社 | セッションフィルタリング方法および負荷分散装置 |
| US7590122B2 (en) * | 2003-05-16 | 2009-09-15 | Nortel Networks Limited | Method and apparatus for session control |
| BRPI0412014A (pt) * | 2003-06-27 | 2006-08-15 | Nokia Corp | método e sistema para reserva de recurso em uma rede de comunicação sem fio, dispositivo de transmissão e de recepção de comunicação, e, dispositivo de comunicação sem fio |
| ATE506822T1 (de) * | 2003-09-23 | 2011-05-15 | Panasonic Corp | Protokolkontextübertragung in einem mobilfunkkommunikationsystem |
| EP1653655B1 (en) * | 2004-10-29 | 2006-11-29 | Research In Motion Limited | System and method for verifying digital signatures on certificates |
| KR100590487B1 (ko) * | 2004-11-25 | 2006-06-19 | 에스케이 텔레콤주식회사 | ＷＣＤＭＡ망에서의 ＧＧＳＮ 노드에서의 과부하 제어 및ＱｏＳ 제어 방법 |
| JP2006195749A (ja) * | 2005-01-13 | 2006-07-27 | Sanyo Electric Co Ltd | 情報処理システム、サーバ装置及びクライアント端末装置 |
-
2006
- 2006-10-13 DE DE602006003901T patent/DE602006003901D1/de active Active
- 2006-10-13 ES ES06122308T patent/ES2317445T3/es active Active
- 2006-10-13 EP EP06122308A patent/EP1898567B1/en active Active
- 2006-10-13 AT AT06122308T patent/ATE415763T1/de not_active IP Right Cessation
-
2007
- 2007-08-24 CN CN2007101861826A patent/CN101309206B/zh active Active
- 2007-08-24 CN CN201110068871.3A patent/CN102143550B/zh active Active
- 2007-08-24 CN CN201210465060.1A patent/CN103024864B/zh active Active
-
2010
- 2010-08-13 KR KR1020100078468A patent/KR101251146B1/ko active IP Right Grant
- 2010-09-27 JP JP2010216157A patent/JP5171913B2/ja active Active
-
2011
- 2011-09-28 KR KR1020110098607A patent/KR101300340B1/ko active IP Right Grant
-
2012
- 2012-01-31 HK HK12100870.1A patent/HK1160714A1/xx unknown
Also Published As
| Publication number | Publication date |
|---|---|
| CN102143550A (zh) | 2011-08-03 |
| CN101309206B (zh) | 2013-01-02 |
| CN103024864B (zh) | 2015-09-23 |
| CN101309206A (zh) | 2008-11-19 |
| ATE415763T1 (de) | 2008-12-15 |
| EP1898567B1 (en) | 2008-11-26 |
| CN102143550B (zh) | 2014-08-27 |
| CN103024864A (zh) | 2013-04-03 |
| HK1160714A1 (en) | 2012-08-10 |
| KR101300340B1 (ko) | 2013-08-28 |
| EP1898567A1 (en) | 2008-03-12 |
| DE602006003901D1 (de) | 2009-01-08 |
| KR20100095503A (ko) | 2010-08-31 |
| JP5171913B2 (ja) | 2013-03-27 |
| KR101251146B1 (ko) | 2013-04-04 |
| KR20110118116A (ko) | 2011-10-28 |
| JP2011055512A (ja) | 2011-03-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2018203437B2 (en) | Use of an oma management object to support application-specific congestion control in mobile networks | |
| ES2942676T3 (es) | Método y terminal para admitir servicio de voz y servicio de datos simultáneamente | |
| ES2317445T3 (es) | Sistema y metodo para determinar que un numero maximo de sesiones ip ha sido establecido. | |
| ES2777349T3 (es) | Procedimiento y aparato para la configuración inicial del enlace WLAN | |
| ES2390000T3 (es) | Procedimiento y dispositivo para reducir la latencia del establecimiento de llamada | |
| CN113938845B (zh) | 上下文管理方法及装置 | |
| JP5072963B2 (ja) | デュアルｓｉｍ無線通信装置を動作させる方法 | |
| CA2675887C (en) | System and method to identify voice call continuity (vcc) subscriber | |
| US9237509B2 (en) | System and method for determining that a maximum number of IP sessions have been established | |
| ES2360742T3 (es) | Agrupamiento de señales de comunicación para mayor eficacia. | |
| BRPI0719192A2 (pt) | Sistema e método para desativação de sessões de ip de prioridade baixa | |
| EP4149125A1 (en) | Message exchange for wearable devices | |
| ES2374720T3 (es) | Métodos y sistemas de bloqueo y/o desatención de datos y terminales inalámbricos y proveedores de servicios inalámbricos relacionados. | |
| CN118741624A (zh) | 根据应用功能请求朝向局域数据网络的流量路由 | |
| JP4629075B2 (ja) | Ｉｐセッションの最大数が確立されていることを決定するシステムおよび方法 | |
| KR20220152950A (ko) | 네트워크 슬라이스 승인 제어(nsac) 발견 및 로밍 향상들 | |
| JP5145344B2 (ja) | 何個のｉｐセッションがサポートされているかに基づくｉｐセッション管理のシステムと方法 | |
| KR100893007B1 (ko) | 이기종 무선 네트워크 시스템에서의 페이징 방법 및 이를위한 장치 | |
| EP2418911B1 (en) | Method, public land mobile network, user equipment and program for controlling the establishment of a packet data connection | |
| WO2021088060A1 (zh) | 通信方法及装置 | |
| KR100718382B1 (ko) | 사용자 상태 표시방법 | |
| CN118055519A (zh) | 信息传输方法、会话建立方法、装置及存储介质 | |
| JP2002223246A (ja) | 通信ネットワーク制御システムおよび方法、ルータ | |
| CN102111904A (zh) | Cdma基站系统及其消息的传输方法 |