ES2543731T3 - Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS (subsistema multimedia IP) - Google Patents

Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS (subsistema multimedia IP) Download PDF

Info

Publication number
ES2543731T3
ES2543731T3 ES09778002.7T ES09778002T ES2543731T3 ES 2543731 T3 ES2543731 T3 ES 2543731T3 ES 09778002 T ES09778002 T ES 09778002T ES 2543731 T3 ES2543731 T3 ES 2543731T3
Authority
ES
Spain
Prior art keywords
emsc
server
user agent
source
target
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
Application number
ES09778002.7T
Other languages
English (en)
Inventor
Andreas Kunz
Bernd Lamparter
Stefan Schmid
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Europe Ltd
Original Assignee
NEC Europe Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by NEC Europe Ltd filed Critical NEC Europe Ltd
Application granted granted Critical
Publication of ES2543731T3 publication Critical patent/ES2543731T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08Upper layer protocols
    • H04W80/10Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS, subsistema multimedia IP, en el que dicho terminal móvil está conectado a una femtocélula o a una macrocélula - célula fuente - y en el que se realiza un traspaso de una sesión real de dicho terminal móvil a otra femtocélula o macrocélula - célula objetivo -, en el que dichas femtocélulas y dichas macrocélulas están equipadas con, o están conectadas a, una función de servidor eMSC, servidor central de conmutación móvil mejorado para servicios centralizados IMS, y en el que dicha función de servidor eMSC de la célula fuente aloja un agente de usuario fuente y dicha función de servidor eMSC de la célula objetivo aloja un agente de usuario objetivo, y en el que dicho agente de usuario fuente contacta con dicho agente de usuario objetivo directa o indirectamente antes de ejecutar el traspaso real, y en el que dicho agente de usuario fuente prepara dicho agente de usuario objetivo junto con la red de acceso correspondiente intercambiando información relacionada con el traspaso, caracterizado porque dicha función de servidor eMSC de la célula objetivo, en el momento de recibir la solicitud de traspaso desde un servidor de aplicaciones alojado en dicha arquitectura IMS o desde dicha función de servidor eMSC de la célula fuente, procesa dicha solicitud de traspaso descargando el perfil de usuario del abonado de dicho terminal móvil y registrando dicho abonado en el IMS.

Description

E09778002
27-07-2015
DESCRIPCIÓN
Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS (subsistema multimedia IP).
La presente invención se refiere a un procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS (Subsistema multimedia IP), en el que dicho terminal móvil está conectado a una femtocélula o a una macrocélula – célula fuente – y en el que se realiza un traspaso de una sesión real de dicho terminal móvil a otra femtocélula o macrocélula – célula objetivo -, en el que dichas femtocélulas y dichas 10 macrocélulas están equipadas con, o están conectadas a, una función de servidor eMSC (servidor central de conmutación móvil mejorado para servicios centralizados IMS), y en el que dicha función de servidor eMSC de la célula fuente aloja un agente de usuario fuente y dicha función de servidor eMSC de la célula objetivo aloja un agente de usuario objetivo, y en el que dicho agente de usuario fuente contacta con dicho agente de usuario objetivo directa o indirectamente antes de ejecutar el traspaso real, y en el que dicho agente de usuario fuente prepara dicho
15 agente de usuario objetivo junto con la red de acceso correspondiente intercambiando información relacionada con el traspaso.
En las redes celulares móviles, un terminal móvil – en 3GPP indicado comúnmente como equipo de usuario (UE) – está ubicado típicamente dentro del área de cobertura de múltiples estaciones de base (BS) de macrocélula al
20 mismo tiempo. La decisión, de cuál BS dará servicio al UE, depende de diversos factores, siendo el factor más importante la calidad de los canales radioeléctricos entre el UE y las BS en cuestión. Cuando el canal radioeléctrico entre el UE y las BS de servicio se deteriora por debajo de un umbral dado, tiene que tomarse una decisión de traspasar el UE a otra BS con mejor calidad de canal radioeléctrico y se inicia el proceso de traspaso.
25 Además, actualmente existe un interés por parte de los operadores de redes móviles en desplegar las denominadas femtocélulas (también conocidas como estaciones de base domésticas, BTS domésticas, picocélulas, NB domésticas, o femtoestaciones de base radioeléctricas) que se instalarían dentro de los hogares de los clientes de los operadores (véase por referencia el informe técnico de Airvana, “Femtocells: Transforming The Indoor Experience”). Tales estaciones de base domésticas están conectadas a una conexión de internet de banda ancha
30 normal, similar a una estación de base WiFi, pero la interfaz radioeléctrica está basada en estándares de redes celulares de áreas extensas tales como WiMAX (Interoperabilidad mundial para acceso por microondas), UMTS (Sistema de telecomunicaciones móviles universales) o 3GPP LTE (Evolución a largo plazo).
En un escenario general, un UE que está en una llamada de voz se mueve hacia el límite del área de cobertura de
35 una femtocélula usada actualmente, por ejemplo una femtocélula con capacidades IMS, y debería ser traspasado a una BS normal de la macrorred del operador. De lo contrario, la llamada se interrumpiría cuando la cobertura de la femtocélula se pierde completamente. El procedimiento estándar para tal traspaso inter-MSC está basado en una conexión directa entre las dos funciones de servidor MSC (Centro de conmutación móvil) implicadas para la señalización y para el transporte de voz después del traspaso. En el caso de la femtocélula la función de servidor
40 MSC está incorporada, de este modo el tráfico de voz necesita ser encaminado desde la red a la femtocélula y desde allí a la otra función de servidor MSC, es decir, el tráfico sería transportado dos veces por la conexión DSL (Línea de abonado digital). Además, sería necesaria una asociación entre la función de servidor MSC y todas las femtocélulas de su área.
45 En la Publicación 8 del 3GPP, se especificó un nuevo tipo de MSC, el cual es capaz de cambiar una llamada de voz CS (con conmutación de circuitos) a una llamada IMS, es decir, un agente de usuario SIP (Protocolo de inicio de sesión) está ejecutándose en el servidor MSC en nombre del usuario. Este nuevo tipo de MSC se denomina servidor MSC mejorado para Servicios Centralizados IMS (eMSC). No obstante, los traspasos inter-MSC aún no están solucionados aquí a nivel de IMS y, en cambio, están basados en la interfaz E existente. La interfaz E proporciona
50 comunicación entre dos MSC e intercambia datos relacionados con un traspaso entre los MSC fuente y objetivo usando el protocolo MAP/E.
Las femtocélulas IMS son femtocélulas mejoradas para Servicios de Centralización IMS similares al eMSC. Sin embargo, no existe movilidad basada en SIP/IMS para sesiones activas de las femtocélulas SIP/IMS, en particular
55 entre femtocélulas y macrocélulas así como entre funciones de servidor eMSC, en caso de que esta movilidad no pueda ser manejada mediante el protocolo MAP (Parte aplicación móvil), por ejemplo entre las funciones de servidor MSC que carecen de una interfaz MAP o las funciones de servidor MSC de diferentes dominios administrativos.
El problema resulta del hecho de que la propia Continuidad de servicio IMS sólo puede conmutar el recorrido entre
E09778002
27-07-2015
los dos agentes de usuario SIP. Sin embargo, la función de servidor eMSC objetivo además tiene que ser informada de a qué BS encaminar la llamada. Por otra parte, no existe registro por defecto de la función de servidor eMSC prevista, así que la función de servidor eMSC de transferencia hacia fuera (agente de usuario SIP fuente) no tiene un punto de contacto registrado en la función de servidor eMSC transferida hacia dentro (agente de usuario SIP
5 objetivo) a donde encaminar la llamada.
El documento WO2007/015068A1 desvela un procedimiento para soporte de movilidad basada en red para un terminal móvil en una red de comunicaciones móviles, en el que la red de comunicaciones móviles comprende una PLMN, que tiene una pluralidad de nodos de red, un nodo de anclaje de red medular, y un punto de acceso, que 10 sirve como estación de base en la red de comunicaciones móviles, en el que la estación de base está conectada por una red pública de área extensa al nodo de anclaje de red medular. En el caso de un traspaso entre el punto de acceso y otro de los nodos de red de la PLMN, la información de traspaso se envía entre el punto de acceso y el nodo de anclaje de red medular por la red pública de área extensa. Más específicamente, el nodo de red medular comprende un IMS-MSC (Centro de conmutación móvil IMS) que está adaptado para establecer una conexión de
15 canalización, de manera que, en el caso de un traspaso, la información de traspaso se envía entre el punto de acceso y el IMS-MSC por la red pública de área extensa.
El documento “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Handover procedures (3 GPP TS 23.009 version7.0.0 Release 7), ETSI TS 123 009”, del 1 de marzo de
20 2007, Estándares ETSI, contiene una descripción detallada de los procedimientos de traspaso que han de usarse en las PLMN. El documento considera traspasos intra- e inter-MSC, así como procedimientos de traspaso/reubicación intra- e inter-3G_MSC.
El documento WO2007/038272A2 desvela un procedimiento y sistema para soporte de un traspaso entre un dominio
25 con conmutación de circuitos (CS) y un dominio IMS para proporcionar continuidad de llamada. El sistema incluye una unidad de transmisión/recepción inalámbrica (WTRU) y una red inalámbrica. La WTRU incluye una entidad de control de continuidad de llamada para soporte de la continuidad de llamada entre un dominio CS y un dominio IMS, y una entidad de traspaso independiente de medios (MIH) configurada para proporcionar servicios MIH para proporcionar información de manera independiente de los medios.
30 Por lo tanto, un objeto de la presente invención es mejorar y desarrollar aún más un procedimiento del tipo descrito inicialmente para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS de tal modo que empleando mecanismos que son fáciles de implementar se lleva a cabo un traspaso sin discontinuidades entre funciones de servidor eMSC y/o femtocélulas a nivel de IMS.
35 De acuerdo con la invención, el objeto anteriormente mencionado se logra mediante un procedimiento que comprende las características de la reivindicación 1. Según esta reivindicación, tal procedimiento está caracterizado porque dicha función de servidor eMSC de la célula objetivo, en el momento de recibir la solicitud de traspaso desde un servidor de aplicaciones alojado en dicha arquitectura IMS o desde dicha función de servidor eMSC de la célula
40 fuente, procesa dicha solicitud de traspaso descargando el perfil de usuario del abonado de dicho terminal móvil y registrando dicho abonado en el IMS.
Según la invención, en primer lugar se ha reconocido que puede proporcionarse un traspaso inter-MSC aplicando un intercambio de mensajes independiente del protocolo entre dos funciones de servidor eMSC – fuente y objetivo – 45 ubicadas en un servidor eMSC y/o en una femtocélula. Además, se ha reconocido que puede lograrse un traspaso sin discontinuidades entre funciones de servidor eMSC y/o femtocélulas cuando el agente de usuario fuente contacta con el agente de usuario objetivo directa o indirectamente antes de ejecutar el traspaso real. El agente de usuario fuente prepara el agente de usuario objetivo junto con la red de acceso correspondiente intercambiando información relacionada con el traspaso. De este modo, la señalización adicional para preparar la función de servidor eMSC de
50 la célula objetivo que aloja el agente de usuario y la red objetivo permite un traspaso sin discontinuidades. Además, la función de servidor eMSC de la célula objetivo, en el momento de recibir la solicitud de traspaso desde un servidor de aplicaciones o desde la función de servidor eMSC de la célula fuente, procesa la solicitud de traspaso descargando el perfil de usuario del abonado del terminal móvil y registrando el abonado en el IMS.
55 El procedimiento según la invención puede aplicarse convenientemente, por ejemplo, en una arquitectura IMS. Sin embargo, ha de entenderse que la invención puede aplicarse a cualquier traspaso de sesión sin discontinuidades entre dos agentes de usuario, en particular agentes de usuario SIP, en los que al menos uno de los agentes de usuario está ubicado en la red, y por lo tanto confía en una forma de señalización adicional desde el agente de usuario fuente hasta el agente de usuario objetivo con el fin de preparar la entidad objetivo antes del traspaso de
E09778002
27-07-2015
sesión real. El procedimiento según la invención puede usarse para traspaso basado en SIP/IMS entre entidades de la misma red de acceso (por ejemplo, eMSC de 3GPP, H(e)NB de 3GPP) o para movilidad de sistema inter-acceso (por ejemplo entre 2G/3G/LTE y WiMAX o WLAN). Además, el procedimiento puede usarse para traspaso basado en SIP/IMS ente entidades del mismo dominio de red, por ejemplo por razones de equilibrio de carga o como
5 mecanismo de conmutación por error. Por consiguiente, cuando la invención se describe con respecto a IMS o SIP en lo siguiente, esta referencia ha de entenderse únicamente como una referencia ejemplar, y ha de señalarse expresamente que su intención no es en ningún modo limitar la invención en modo alguno.
En una realización preferente de la invención la solicitud de traspaso puede incluir información respecto a la red de
10 acceso de la célula objetivo. La solicitud de traspaso proporciona información esencial de la red de acceso a la función de servidor eMSC de la célula objetivo para permitir que la entidad objetivo configure los recursos de la red de acceso (por ejemplo, los portadores radioeléctrico y de acceso). La información relacionada con la red de acceso de la célula objetivo puede incluir información respecto a, por ejemplo, pero no limitada a, el ID de la célula, la intensidad de la señal, el tipo de RAT (Tecnología de acceso radioeléctrico), el SSID (Identificador del conjunto de
15 servicios), el canal de RF (radiofrecuencia), los informes de medición y/o la carga de la célula objetivo.
En una realización preferente de la invención la decisión de traspaso puede tomarse por parte de un servidor de aplicaciones o una función de servidor de aplicaciones similar alojado en la arquitectura IMS basándose en la información relacionada con la red de acceso recibida desde la función de servidor eMSC de la célula fuente. El
20 servidor de aplicaciones puede estar configurado para que sea responsable de la sesiones de anclaje y de ejecutar la transferencia de sesión entre redes de acceso para la sesión.
Ventajosamente, el servidor de aplicaciones descubre la función de servidor eMSC de la célula objetivo basándose en la información relacionada con la red de acceso recibida desde la función de servidor eMSC de la célula fuente.
25 El servidor de aplicaciones puede tomar la decisión de traspaso ya sea localmente o interrogando a una función de descubrimiento, por ejemplo el servidor de abonado residencial (HSS).
Con respecto a informar al agente de usuario objetivo del registro IMS exitoso anclado en el servidor de
30 aplicaciones, puede preverse que el servidor de aplicaciones señalice el registro IMS exitoso al agente de usuario objetivo por medio de un mensaje de respuesta.
Ventajosamente, el agente de usuario objetivo envía un mensaje de invitación para realizar la transferencia de sesión del trayecto de medios al servidor de aplicaciones, incluyendo el mensaje de invitación un identificador de la
35 sesión que se ha de asumir.
Con respecto a una evitación eficiente de pérdidas durante la transmisión de datos, el mensaje de invitación puede incluir una bandera adicional que indica que se permite un bi-casting de los medios de la sesión tanto hacia la función de servidor eMSC de la célula fuente como la función de servidor eMSC de la célula objetivo. Además, el
40 mensaje de invitación o un mensaje de reinvitación pueden soportar una opción de temporizador máximo para el bicasting. El bi-casting puede ser detenido desde el acceso a la fuente o al objetivo mediante una indicación explícita, por ejemplo en señalización SIP.
Con respecto a un procesamiento eficiente del traspaso, el servidor de aplicaciones puede actualizar el tramo de
45 acceso remoto y puede enviar un mensaje acusando recibo del mensaje de invitación a la función de servidor eMSC de la célula objetivo.
Por último, la función de servidor eMSC de la célula fuente, en el momento de ser informada de la preparación exitosa del traspaso de sesión en la función de servidor eMSC de la célula objetivo, puede liberar la sesión.
50 Existen varios modos de cómo diseñar y desarrollar aún más la enseñanza de la presente invención de manera ventajosa. Con este fin, ha de hacerse referencia a las reivindicaciones de patente subordinadas de la reivindicación de patente 1 y a la siguiente explicación de ejemplos preferentes de realizaciones de la invención, ilustrados por las figuras. En relación con la explicación de los ejemplos preferentes de realizaciones de la invención mediante la
55 ayuda de las figuras, se explicarán realizaciones generalmente preferentes de la invención y desarrollos adicionales de la enseñanza.
En los dibujos:
E09778002
27-07-2015
La fig. 1 es una vista esquemática de una arquitectura de red típica que ilustra un ejemplo de un escenario de aplicación para realizar un traspaso entre una femtocélula y un servidor eMSC,
la fig. 2 es una vista esquemática de una arquitectura de red típica que ilustra un ejemplo de otro escenario de 5 aplicación para realizar un traspaso entre dos servidores eMSC,
la fig. 3 es una vista esquemática que ilustra una realización de un procedimiento de soporte de movilidad basada en red según la presente invención,
10 la fig. 4 es un diagrama que muestra flujos de llamada de ejemplo de la realización según la fig. 3 usando un mensaje HO_REQUEST,
la fig. 5 es un diagrama que muestra flujos de llamada de ejemplo de la realización según la fig. 3 que correlacionan el mensaje HO_REQUEST con un mensaje SIP REFER existente,
15 la fig. 6 es una vista esquemática otra realización de un procedimiento de soporte de movilidad basada en red según la presente invención,
la fig. 7 es un diagrama que muestra flujos de llamada de ejemplo de la realización según la fig. 6 para descubrir el 20 servidor eMSC objetivo empleando el registro de nivel de aplicación, y
la fig. 8 es un diagrama que muestra flujos de llamada de ejemplo de la realización según la fig. 6 que emplean un mensaje NOTIFY.
25 La fig. 1 muestra una vista esquemática de una arquitectura de red típica que ilustra un ejemplo de un escenario de aplicación para realizar un traspaso entre una femtocélula y un servidor eMSC. La fig. 1 muestra un UE que está conectado por medio de un femtopunto de acceso a la red IMS que presenta un SCC AS, un HSS y una CSCF. El femtopunto de acceso presenta un MSC incorporado y aloja al agente de usuario SIP fuente (SIP UA) en nombre del usuario. En caso de realizar el traspaso, la fig. 1 muestra el servidor eMSC objetivo que aloja el SIP UA objetivo.
30 Después del traspaso, el US se conecta por medio del BTS (Sistema transceptor de base) o en NodoB y el BSC (Controlador de estación de base) o el RNC (Controlador de red radioeléctrica) al servidor eMSC objetivo que está enlazado a la arquitectura IMS. El femtopunto de acceso y el servidor eMSC son los elementos de red que hacen de puente para la separación entre sistemas telefónicos CS UMTS existentes y redes IP IMS con conmutación de paquetes.
35 La fig. 2 muestra una vista esquemática de una arquitectura de red típica que ilustra un ejemplo de otro escenario de aplicación para realizar un traspaso de UE. Este escenario de aplicación se distingue del escenario de aplicación ilustrado en la fig. 1 en realizar un traspaso entre dos servidores eMSC. De este modo, la fig. 2 muestra, a diferencia de la fig. 1, el servidor eMSC fuente y objetivo que están conectados a la red IMS.
40 La fig. 3 muestra una vista esquemática que ilustra una realización de un procedimiento de soporte de movilidad basada en red según la presente invención. En particular, cuando una femtocélula IMS o un servidor MSC mejorado para ISC (servidor eMSC) está implicado en un traspaso inter-MSC, entonces la entidad de inicio de traspaso, es decir, la femtocélula IMS o el servidor MSC de origen mejorado para ICS incluye la información de la célula objetivo
45 en el alto nivel correspondiente, el mensaje de solicitud de traspaso general HO_REQUEST, el cual podría ser, por ejemplo, correlacionado con un mensaje SIP, por ejemplo un mensaje re-INVITE, REFER, o NOTIFY.
En la solución ilustrada en la fig. 3, un SCC AS (servidor de aplicaciones de continuidad y coherencia de servicios) toma la decisión de traspaso y selecciona el servidor MSC objetivo (o femtopunto de acceso) basándose en 50 información de acceso detallada (procedente tanto del acceso a la fuente como al objetivo) – por ejemplo, un informe de medición procedente del UE.
En caso de que se use señalización basada en SIP para los mensajes recién propuestos, todos los servidores MSC mejorados con ICS deben registrarse por sí mismos. Otra posibilidad – sin usar SIP – sería que el SCC AS (o una
55 función similar) conozca la dirección IP del servidor MSC usando DNS o cualquier otro servicio de directorio (por ejemplo LDAP). Esto es necesario para enviar el mensaje HO_REQUEST (el cual puede llevar la información de contexto requerida desde el servidor MSC fuente al objetivo) y para recibir un ACK. Puede aplicarse el mismo principio entre dos entidades cualesquiera que estén alojando un SIP-UA con el fin de intercambiar información entre las entidades antes de ejecutar el traspaso real.
E09778002
27-07-2015
Cabe destacar que el término SCC AS se usa como servidor de aplicaciones ejemplar que podría asumir la responsabilidad/función descrita. La función también podría proporcionarse mediante otro (nuevo) servidor de aplicaciones u otra (nueva) entidad funcional, que estén implementados específicamente en la red.
En lo siguiente, se describen con algo más de detalle las etapas individuales de la realización ejemplar ilustrada en la fig. 3. En una primera etapa (1) el femtopunto de acceso/servidor eMSC fuente envía una HO_REQUEST al SCC AS o un servidor de aplicaciones similar. Dentro de esta solicitud de traspaso se proporciona información acerca de la sesión que ha de transferirse y el usuario de origen, así como información relacionada con el acceso objetivo y/o
10 la red objetivo (por ejemplo, ID de la célula objetivo, tipo de RAT objetivo, SSID, canal de RF, etc.).
El SCC AS decide, basándose en la información deducida en la etapa (1), qué servidor MSC (o femtopunto de acceso) será el objetivo para la sesión. El SCC AS envía el mensaje HO_REQUEST hacia el servidor MSC seleccionado (2). El SCC AS también toma la decisión de traspaso – puede tenerse en cuenta la información de
15 acceso detallada (tanto del acceso a la fuente como al objetivo) (por ejemplo, un informe de medición procedente del UE).
En la etapa (3) el servidor MSC procesa la solicitud de traspaso, descarga el perfil de usuario del abonado – por ejemplo, del registro de posiciones base (HLR) – y registra el abonado en el IMS (o el servidor SIP/similar al SIP que
20 ancla el control de sesión) en nombre del usuario. El servidor MSC objetivo también puede tener que deducir el ID de usuario público de la IMSI (identidad internacional de abonado del servicio móvil) usada para el registro IMS del SIP UA. Si es necesario, el servidor MSC también solicitará los recursos requeridos en la red de acceso radioeléctrico (RAN) para la célula objetivo o simplemente preparará la red de acceso.
25 Después de un registro IMS/SIP exitoso, anclado en el SCC AS (o una función de AS similar), el SCC AS envía un 200 OK al SIP UA en el servidor MSC (4).
Posteriormente el agente de usuario está listo para asumir la sesión y envía en la etapa (5) un INVITE con una referencia al ID de sesión de la sesión que ha de asumir. Dentro de esta etapa (5) también podría insertarse una
30 bandera adicional para indicar que debería comenzar el bicasting (duplicación de paquetes IP a dos destinos) de los medios hacia el femtopunto de acceso y el servidor eMSC.
En una siguiente etapa, el SCC AS actualiza el tramo remoto y acusa recibo de INVITE (6). Posteriormente, el servidor MSC objetivo (o femtopunto de acceso) envía entonces un acuse de recibo de traspaso hacia el SCC AS
35 (7). El SCC AS reenvía el mensaje HO_ACK al femtopunto de acceso/servidor eMSC fuente (8).
El femtopunto de acceso/servidor eMSC fuente ahora sabe que el traspaso está preparado en el eMSC/femtopunto de acceso objetivo, libera la sesión, y envía un BYE al SCC AS (9). Este mensaje BYE detiene el bicasting iniciado potencialmente en la etapa (5). En este punto, el femtopunto de acceso/servidor eMSC fuente también enviará o
40 activará el envío de un mensaje de comando de traspaso hacia el UE, para indicar que el traspaso debería tener lugar ahora. Por último, el SCC AS acusa recibo del BYE con un 200 OK.
Alternativamente, en lugar de conmutar el trayecto de datos hacia el servidor eMSC (o femtopunto de acceso) objetivo en la etapa 5, la conmutación de trayecto también podría ser activada por la etapa 9 (es decir, cuando el
45 femtopunto de acceso/servidor eMSC fuente deja de estar registrado).
Además, todos los servidores MSC mejorados para ICS dentro de la red se registran en el IMS con su dirección de contacto, la cual también se proporciona al SCC AS, es decir, la señalización de control SIP se ancla allí. El SCC AS proporciona la dirección del servidor MSC objetivo responsable mejorado para ICS, esto podría hacerse, por
50 ejemplo, mediante una consulta en una base de datos de todos los servidores MSC registrados. La femtocélula IMS conoce el ID de la célula objetivo, ya que se comunicó mediante los informes de medición del UE a la femtocélula, que entonces toma la decisión de traspaso.
La fig. 4 ilustra un diagrama que muestra flujos de llamada de una realización según la fig. 3 usando un mensaje
55 HO_REQUEST. La femtocélula inicia una solicitud de traspaso con el ID de la célula objetivo y el ID de transferencia de sesión por medio de las CSCF (funciones de control de sesión de llamada) al SCC AS. El SCC AS mantiene una base de datos para seleccionar la dirección de contacto correspondiente del servidor MSC responsable mejorado para ICS. El SCC AS selecciona el servidor MSC apropiado mejorado para ICS y reenvía la solicitud de traspaso. Una vez que el servidor MSC mejorado para ICS recibe el mensaje de solicitud de traspaso, comienza a configurar
E09778002
27-07-2015
recursos para la célula objetivo e inicia el registro IMS en nombre del UE con el ID de usuario público deducido especial. El servidor MSC además inicia la transferencia de sesión enviando un mensaje INVITE hacia el SCC AS. Este mensaje INVITE tiene como objetivo el identificador de transferencia de sesión (STI) que identifica la sesión que ha de transferirse. El mensaje INVITE también indica al SCC AS que realice la transferencia de acceso con
5 transferencia de medios completa. El SCC AS identifica la sesión basándose en el STI y actualiza la sesión sobre el tramo de acceso remoto. El SCC AS completa la configuración de la sesión con el servidor MSC mejorado para ICS en el nuevo tramo de acceso y libera la antigua sesión basándose en procedimientos IMS estándar.
La fig. 5 ilustra un diagrama que muestra flujos de llamada de una realización según la fig. 3 correlacionando el
10 mensaje HO_REQUEST con un mensaje SIP REFER existente. El femtopunto de acceso envía un REFER hacia el id de célula objetivo. Después del procesamiento en el SCC AS, enviará un NOTIFY con toda la información a la instancia de servidor eMSC registrada. Esto activa el registro IMS en nombre del usuario con un id de usuario público deducido especial. La instancia de servidor eMSC acusa recibo del NOTIFY y activa el agente de usuario ahora registrado para enviar un INVITE con la información de STI hacia el SCC AS, el cual actualizará el tramo de
15 acceso remoto y después liberará el tramo fuente.
La fig. 6 muestra una vista esquemática que ilustra otra realización de un procedimiento de soporte de movilidad basada en red según la presente invención. Esta segunda solución es que el femtopunto de acceso/servidor eMSC fuente se comunicará “directamente” con el servidor eMSC (o femtopunto de acceso) objetivo sin pasar por el SCC 20 AS (o una función de servidor de aplicaciones similar). Para permitir esto, el nodo fuente tiene que obtener de algún modo una identidad encaminable del nodo objetivo. Como consecuencia, el femtopunto de acceso/servidor eMSC fuente realizará una consulta explícita o implícita de la dirección del MSC (o femtopunto de acceso) objetivo antes del mensaje HO_REQUEST. El femtopunto de acceso/servidor eMSC fuente puede, por ejemplo, inquirir al SCC AS (o una función de AS similar) o una función de descubrimiento/consulta dedicada para obtener el servidor MSC (o
25 femtopunto de acceso) objetivo.
Otra posibilidad es que cuando el femtopunto de acceso fuente se registra en el IMS, entonces el SCC AS determina el servidor eMSC responsable del traspaso de macro potencial. Esta dirección del servidor eMSC se vuelve a proporcionar luego al femotpunto de acceso, por ejemplo dentro del mensaje 200 OK.
30 Otra posibilidad sería que el femtopunto de acceso/servidor eMSC fuente, basándose en la información obtenida por la red de acceso (por ejemplo, informe de medición, ID de la célula objetivo, SSID, etc.), deduce un identificador/nombre de SIP encaminable por IMS, que permite que el nodo fuente se dirija directamente al nodo objetivo. En este caso, el IMS se encarga del encaminamiento de los mensajes HO_REQUEST (es decir, cada
35 femtopunto de acceso/servidor eMSC será registrado en el IMS con fines de control).
Por último, también puede haber soluciones que no estén basadas en SIP. Por ejemplo, el femtopunto de acceso/servidor eMSC fuente podría usar Diameter/Radius, DNS o cualquier otro servicio de directorio (por ejemplo LDAP) para obtener la dirección del servidor eMSC (o el femtopunto de acceso) objetivo. Al igual que en SIP, en
40 caso de usarse Diameter el femtopunto de acceso/servidor eMSC fuente también puede enmascarar la información relevante en el identificador de destino Diameter y luego permitir que la función de encaminamiento Diameter haga la selección final.
En esta segunda solución, la decisión de traspaso se toma por parte del femtopunto de acceso/servidor eMSC
45 fuente basándose en información de acceso detallada (procedente tanto del acceso a la fuente como al objetivo) – por ejemplo, un informe de medición procedente del UE.
Así, la fig. 6 debe extenderse de la siguiente manera. Insertando dos etapas opcionales antes de las primeras etapas denominadas (a) HO_TARGET_LOOKUP y (b) HO_TARGET_RESPONSE. Estas etapas son opcionales
50 porque sólo se ejecutan en caso de mecanismo de consulta explícita. Para consultas implícitas (por ejemplo, basadas en la configuración en la entidad fuente o basadas en encaminamiento SIP/IMS o DIAMETER) estas etapas no serían necesarias.
En lo siguiente, se describen con más detalle las etapas individuales de la realización ejemplar ilustrada en la fig. 6.
55 En una primera etapa (1) el femtopunto de acceso envía una HO_REQUEST directamente al servidor MSC. Dentro de esta solicitud, se proporciona información acerca de la sesión que ha de transferirse y el usuario de origen así como el ID de la célula objetivo.
El servidor MSC procesa la solicitud de traspaso, descarga el perfil de usuario del abonado desde el HLR al VLR y
E09778002
27-07-2015
deduce el ID de usuario público de la IMSI usada para el registro IMS del SIP UA. El SIP UA envía entonces un mensaje de registro IMS en nombre del usuario (2). El servidor MSC también solicita recursos en la RAN para el ID de la célula objetivo.
5 Después del registro IMS exitoso, anclado en el SCC AS, el SCC AS envía un 200 OK al SIP UA en el servidor MSC (3). El servidor MSC envía entonces en la etapa (4) un acuse de recibo de traspaso hacia el femtopunto de acceso con la información de dirección SIP UA.
Posteriormente, el femtopunto de acceso envía un REFER al SIP UA en el servidor MSC para asumir la sesión
10 activa (5). El servidor MSC procesa el REFER y envía un INVITE con una referencia al SCC AS (6). Dentro de esta etapa también podría insertarse una bandera adicional para indicar que debería comenzar el bicasting de los medios hacia el femtopunto de acceso y el servidor eMSC.
En la etapa (7), el SCC AS actualiza el tramo remoto y acusa recibo del INVITE con un 200 OK. El servidor MSC
15 acusa recibo del REFER al femtopunto de acceso con un 200 OK (8). El femtopunto de acceso ahora sabe que el traspaso está preparado en el servidor MSC y libera la sesión y envía un BYE al SCC AS (9). Este mensaje BYE detiene el bicasting potencial, iniciado en la etapa (6). Por último, en la etapa (6), el SCC AS acusa recibo del BYE con un 200 OK.
20 Alternativamente, en lugar de conmutar el trayecto de datos hacia el servidor eMSC (o femtopunto de acceso) objetivo en la etapa (6), el conmutador de trayecto también podría ser activado por la etapa (9), es decir, cuando el femtopunto de acceso/servidor eMSC fuente deja de estar registrado.
La fig. 7 ilustra un diagrama que muestra flujos de llamada de ejemplo de una realización según la fig. 6 para
25 descubrir el servidor eMSC objetivo empleando el registro de nivel de aplicación. Después de que el UE ha obtenido conectividad IP, el UE realiza el registro IM enviando un mensaje de registro al P-CSCF (intermediario de la función de control de sesión de llamada). El P-CSCF envía el mensaje de registro al I-CSCF (interrogador CSCF) el cual envía un mensaje Cx-Query/Cx-Select-Pull al HSS. El HSS comprueba si el usuario ya está registrado. El HSS indica si al usuario se le permite registrarse en esa red P-CSCF según la suscripción del usuario y las
30 limitaciones/restricciones del operador si las hubiera. Se envía un Cx-Query Resp/Cx-Select-Pull Resp que contiene el nombre S-CSCF del HSS al I-CSCF. De este modo, el I-CSCF puede enviar el mensaje de registro al S-CSCF seleccionado. El S-CSCF envía un Cx-Put/Cx-Pull al HSS. El HSS almacena el nombre S-CSCF para ese usuario y devuelve la información de usuario empleando el Cx-Put Resp/Cx-Pull Resp al S-CSCF. Acto seguido el S-CSCF envía un mensaje de registro al SCC AS para determinar el servidor eMSC que se registró previamente como
35 contacto para itinerancia saliente del usuario de la femtocélula. El SCC AS envía un mensaje 200 OK que incluye el eMSC SIP URI del servidor eMSC objetivo a través de los CSCF hasta el femtopunto de acceso. De este modo, después de descubrir el servidor eMSC objetivo, la femtocélula sólo tiene que almacenar la dirección para el caso de que se considere que sea necesario un traspaso de macrocélula.
40 La fig. 8 ilustra un diagrama que muestra flujos de llamada de ejemplo de una realización según la fig. 6. Si se evalúan los informes de medición y la femtocélula decide realizar un traspaso al servidor eMSC, entonces la femtocélula envía un mensaje NOTIFY a través de los CSCF a la dirección del servidor eMSC almacenada. Este mensaje NOTIFY contiene adicionalmente el ID de la célula objetivo y el identificador de transferencia de sesión (STI) para la sesión que ha de ser transferida. El servidor eMSC identifica la solicitud de traspaso basándose en el
45 mensaje NOTIFY y el SIP UA en el servidor eMSC se registra en el IMS en nombre del UE con un ID de usuario público deducido especial. Después del registro exitoso el servidor MSC acusa recibo del NOTIFY con un 200 OK y la dirección del SIP UA registrada. El femtopunto de acceso (FAP) ahora sabe que el SIP UA está registrado y envía directamente al SIP UA en el servidor eMSC un REFER con el UE2 objetivo en el identificador uniforme de recursos (URI). Además se proporciona la información de STI. El SIP UA en el servidor eMSC envía entonces un Re-INVITE
50 al UE2. Después de que el UE2 vuelve a enviar el 200 OK, el SIP UA en el servidor MSC podría actualizar el tramo de acceso remoto directamente o esperar hasta que expire un temporizador cuando se asume que el tramo fuente ha sido liberado. La femtocélula libera el tramo de acceso fuente cuando recibe la respuesta 200 OK relacionada con el mensaje REFER.
55 Muchas modificaciones y otras realizaciones de la invención expuesta en este documento acudirán a la mente de un experto en la materia a la cual pertenece la invención que tiene el beneficio de las enseñanzas presentadas en la descripción precedente y los dibujos asociados. Por lo tanto, ha de entenderse que la invención no estará limitada a las realizaciones específicas desveladas y se pretende que dentro del alcance de las reivindicaciones adjuntas estén incluidas modificaciones y otras realizaciones. Aunque en este documento se emplean términos específicos, se usan
E09778002
27-07-2015
únicamente en sentido genérico y descriptivo y no con fines de limitación.

Claims (8)

  1. REIVINDICACIONES
    1. Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS, subsistema multimedia IP,
    5 en el que dicho terminal móvil está conectado a una femtocélula o a una macrocélula – célula fuente – y en el que se realiza un traspaso de una sesión real de dicho terminal móvil a otra femtocélula o macrocélula – célula objetivo -,
    en el que dichas femtocélulas y dichas macrocélulas están equipadas con, o están conectadas a, una función de 10 servidor eMSC, servidor central de conmutación móvil mejorado para servicios centralizados IMS, y
    en el que dicha función de servidor eMSC de la célula fuente aloja un agente de usuario fuente y dicha función de servidor eMSC de la célula objetivo aloja un agente de usuario objetivo, y
    15 en el que dicho agente de usuario fuente contacta con dicho agente de usuario objetivo directa o indirectamente antes de ejecutar el traspaso real, y en el que dicho agente de usuario fuente prepara dicho agente de usuario objetivo junto con la red de acceso correspondiente intercambiando información relacionada con el traspaso,
    caracterizado porque dicha función de servidor eMSC de la célula objetivo, en el momento de recibir la solicitud de
    20 traspaso desde un servidor de aplicaciones alojado en dicha arquitectura IMS o desde dicha función de servidor eMSC de la célula fuente, procesa dicha solicitud de traspaso descargando el perfil de usuario del abonado de dicho terminal móvil y registrando dicho abonado en el IMS.
  2. 2. Procedimiento según la reivindicación 1, en el que se toma una decisión de traspaso por parte de
    25 dicho servidor de aplicaciones basándose en información respecto a la red de acceso de dicha célula objetivo recibida desde dicha función de servidor eMSC de la célula fuente.
  3. 3. Procedimiento según la reivindicación 2, en el que dicho servidor de aplicaciones descubre dicha
    función de servidor eMSC de la célula objetivo basándose en dicha información relacionada con la red de acceso 30 recibida desde dicha función de servidor eMSC de la célula fuente.
  4. 4. Procedimiento según cualquiera de las reivindicaciones 1 a 3, en el que dicho servidor de aplicaciones toma dicha decisión de traspaso localmente.
    35 5. Procedimiento según cualquiera de las reivindicaciones 1 a 4, en el que dicho servidor de aplicaciones toma dicha decisión de traspaso interrogando a una función de descubrimiento.
  5. 6. Procedimiento según cualquiera de las reivindicaciones 1 a 5, en el que dicho servidor de aplicaciones
    señaliza un registro IMS exitoso a dicho agente de usuario objetivo por medio de un mensaje de respuesta. 40
  6. 7. Procedimiento según la reivindicación 6, en el que dicho agente de usuario objetivo envía un mensaje de invitación para realizar la transferencia de sesión del trayecto de medios a dicho servidor de aplicaciones, incluyendo dicho mensaje de invitación un identificador de la sesión que se ha de asumir.
    45 8. Procedimiento según la reivindicación 7, en el que dicho mensaje de invitación incluye una bandera adicional que indica que se permite un bi-casting de dichos medios de la sesión tanto hacia dicha función de servidor eMSC de la célula fuente como dicha función de servidor eMSC de la célula objetivo.
  7. 9. Procedimiento según la reivindicación 7 u 8, en el que dicho servidor de aplicaciones actualiza el
    50 tramo de acceso remoto y envía un mensaje acusando recibo de dicho mensaje de invitación a dicha función de servidor eMSC de la célula objetivo.
  8. 10. Procedimiento según cualquiera de las reivindicaciones 7 a 9, en el que dicha función de servidor
    eMSC de la célula fuente, en el momento de ser informada de la preparación exitosa de dicho traspaso de sesión en 55 la función de servidor eMSC de la célula objetivo, libera dicha sesión.
    10
ES09778002.7T 2008-08-21 2009-08-20 Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS (subsistema multimedia IP) Active ES2543731T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP08014849 2008-08-21
EP08014849 2008-08-21
PCT/EP2009/006039 WO2010020417A2 (en) 2008-08-21 2009-08-20 Method for supporting network based mobility for a mobile terminal in an ims (ip multimedia subsystem) architecture

Publications (1)

Publication Number Publication Date
ES2543731T3 true ES2543731T3 (es) 2015-08-21

Family

ID=41506571

Family Applications (1)

Application Number Title Priority Date Filing Date
ES09778002.7T Active ES2543731T3 (es) 2008-08-21 2009-08-20 Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS (subsistema multimedia IP)

Country Status (5)

Country Link
US (1) US20110212723A1 (es)
EP (1) EP2316233B1 (es)
JP (1) JP5198663B2 (es)
ES (1) ES2543731T3 (es)
WO (1) WO2010020417A2 (es)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8913585B2 (en) 2007-06-28 2014-12-16 Motorola Mobility Llc Method and system for providing IMS session continuity to a user equipment across a plurality of communication networks
CN101772221B (zh) * 2010-02-05 2014-12-31 中兴通讯股份有限公司 一种完成平滑割接的方法及割接操作执行设备及装置
JP5288561B2 (ja) * 2010-02-26 2013-09-11 Kddi株式会社 フェムトセル間のハンドオフ方法およびシステム
US20120079054A1 (en) 2010-03-24 2012-03-29 General Instrument Corporation Automatic Memory Management for a Home Transcoding Device
JP2013526087A (ja) * 2010-04-16 2013-06-20 パナソニック株式会社 ローカルipネットワークに接続するueのハンドオーバ方法、ハンドオーバシステム、装置
JP5052642B2 (ja) * 2010-04-21 2012-10-17 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム、ネットワーク装置及び移動通信方法
US8908639B2 (en) * 2011-02-22 2014-12-09 Telefonaktiebolaget L M Ericsson (Publ) Methods for handoff of an active communication connection from a macrocell to a femtocell
CN102238672B (zh) 2010-04-23 2014-08-13 中兴通讯股份有限公司 反向单待业务连续性实现方法及***
US9374744B2 (en) * 2011-08-10 2016-06-21 Kt Corporation Apparatus and method for seamless handoff of a service between different types of networks
US8254377B1 (en) 2011-09-06 2012-08-28 Metropcs Wireless, Inc. System and method for HLR support for IP-MSC feature activation
JP6008390B2 (ja) * 2012-06-07 2016-10-19 日本電気株式会社 通信システム、コントロールノード、変換サーバおよび通信方法
US20140038605A1 (en) * 2012-07-31 2014-02-06 Firouz Behnamfar Devices and methods for cellular communication
US9819578B2 (en) * 2013-08-26 2017-11-14 Nec Corporation Communication device and method in a communication system, and device and method for communication path control
WO2016091287A1 (en) * 2014-12-09 2016-06-16 Nokia Solutions And Networks Oy Handover between circuit switched gateways
US9756088B2 (en) * 2015-09-08 2017-09-05 Qualcomm Incorporated IMS over soft AP admission control and resource management
EP3725114B1 (en) 2017-12-13 2022-10-12 Telefonaktiebolaget LM Ericsson (publ) Network repository function in 5gc

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1911306B1 (en) 2005-08-01 2017-04-05 Ubiquisys Limited Local area cellular basestation
KR101031297B1 (ko) * 2005-09-23 2011-04-29 인터디지탈 테크날러지 코포레이션 콜 연속을 지원하는 무선 통신 방법 및 시스템
JP2009529830A (ja) * 2006-03-09 2009-08-20 インターデイジタル テクノロジー コーポレーション 2種類の無線アクセス技術間でハンドオーバを実施する無線通信方法およびシステム
CA2675843A1 (en) * 2007-01-18 2008-07-24 Interdigital Technology Corporation Method and apparatus for media independent handover

Also Published As

Publication number Publication date
EP2316233A2 (en) 2011-05-04
WO2010020417A3 (en) 2010-08-05
WO2010020417A2 (en) 2010-02-25
US20110212723A1 (en) 2011-09-01
JP2011530916A (ja) 2011-12-22
JP5198663B2 (ja) 2013-05-15
EP2316233B1 (en) 2015-05-20

Similar Documents

Publication Publication Date Title
ES2543731T3 (es) Procedimiento para soporte de movilidad basada en red para un terminal móvil en una arquitectura IMS (subsistema multimedia IP)
US9167486B2 (en) Inter-VPLMN handover via a handover proxy node
CN101983525B (zh) 用于域间切换的方法和实体
DK3073787T3 (en) Methods and Nodes for Selecting a Target Core Network for Transferring a Voice Session to a Terminal
US8830953B2 (en) IMS to CS handover for IMS systems for legacy CS UE with home node B access
KR101354855B1 (ko) 사설 셀을 포함하는 통신 시스템에서 통신 장치에 서비스를 제공하기 위한 장치 및 방법
US11553380B2 (en) Support of CS fallback in an evolved packet system
KR101700448B1 (ko) 이동 통신 시스템에서 보안 관리 시스템 및 방법
ES2433932T3 (es) Método y sistema para el interfuncionamiento de redes celulares y redes de área local inalámbricas
US8340081B2 (en) Communication apparatus for providing services to a communication device through a private base station
US8520682B2 (en) System and method for provision of IMS based services for legacy CS UE with home node B access
CN102378148B (zh) 终端、hss、及核心网网元获知终端能力的方法和***
US9167487B2 (en) Communication system including a gateway device and method thereof
JP2013510488A (ja) ハンドオーバー遅延の最適化
WO2018235791A1 (ja) ユーザ装置、amf、コアネットワーク装置、p-cscf、及び通信制御方法
WO2013156061A1 (en) Failure handling within a network implementing srvcc
US20150092749A1 (en) Handoff of a mobile station between packet-switched and circuit-switched wireless domains
US8971875B2 (en) Device and method for performing a reverse single radio voice call continuity (RSRVCC) procedure
US8467790B2 (en) Mechanism to update the CSG cell access check upon PLMN change at handover
US8644253B2 (en) Picocell system with local voice media support
WO2024140220A1 (zh) 核心网漫游场景下禁止终端接入网络的方法及***
KR20120001361A (ko) 이종무선망간 핸드오버를 위한 방법 및 장치
CN101835222B (zh) 终端从家庭基站切换到宏蜂窝***保持会话的方法和***
KR101436060B1 (ko) 이종 통신망 간 가입자 위치 정보 동기화 방법, 이종 통신망 간 가입자 위치 정보에 기반한 이종 통신망 서비스 처리 방법, 및 그를 위한 장치
CN102469438B (zh) 一种注册时更新切换号码的方法和装置