ES2829592T3

ES2829592T3 - Actualización de una función de red móvil

Info

Publication number: ES2829592T3
Application number: ES18248007T
Authority: ES
Inventors: Shaoji Ni; Francis Pak Kwan Tam
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2015-02-18
Filing date: 2015-02-18
Publication date: 2021-06-01
Anticipated expiration: 2035-02-18
Also published as: US20170346682A1; WO2016131480A1; ES2718385T3; EP3254189A1; CN111683380B; EP3757778B1; EP3528114A1; CN107409062B; EP3254189B1; EP3757778A1; CN111683380A; EP3528114B1; US11115274B2; CN107409062A

Abstract

Un módulo de decisión de gestión de tráfico para su utilización en una entidad de red de un sistema de comunicación móvil, en donde el módulo de decisión de gestión de tráfico se proporciona dentro de una instancia que implementa, en la entidad de red, una función de red móvil de acuerdo con una versión actual de software, en donde el módulo de decisión de gestión de tráfico comprende: un submódulo de recepción configurado para recibir tráfico del plano de control, comprendiendo el tráfico del plano de control peticiones a la función de red móvil; caracterizado por: un submódulo de decisión configurado para decidir, para cada petición recibida, si la petición respectiva va a ser procesada por una instancia que implementa la función de red móvil de acuerdo con la versión actual de software o una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software; en donde el submódulo de decisión está configurado para tomar su decisión en función de una o más políticas configuradas por una entidad de gestión de la red de comunicación móvil; un submódulo de encaminamiento configurado para encaminar cada petición a una instancia que implementa la función de red móvil de acuerdo con la versión actual de software o a una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software, en función de la decisión del submódulo de decisión; en donde las una o más políticas incluyen una política de acuerdo con la que las peticiones del tráfico del plano de control asociadas a una nueva portadora o sesión a establecer después de la activación de la política se van a encaminar a una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software.

Description

DESCRIPCIÓN

Actualización de una función de red móvil

Campo de la invención

La invención está relacionada con la actualización de una función de servicio de red dentro de una red de comunicación móvil. En este contexto, la invención está relacionada con un módulo de decisión de gestión de tráfico que distribuye una petición entrante del plano de control a instancias que implementan una función de la red móvil bien en función de la versión actual de software o una versión actualizada de software. Además, la invención está relacionada con un método, una entidad de red y un medio legible por un ordenador para actualizar una función de red móvil.

Antecedentes técnicos

Evolución a Largo Plazo (LTE)

El Programa de Asociación de 3a Generación (3GPP) ha estandarizado un nuevo sistema de comunicación móvil denominado Evolución a Largo Plazo (LTE). LTE se ha diseñado para satisfacer las necesidades de transporte para datos de alta velocidad y transporte de medios así como un soporte de voz de alta capacidad. La especificación del elemento de trabajo sobre Evolución a Largo Plazo (LTE) denominado Acceso Radio Terrestre UMTS (UTRA) Evolucionado y Red de Acceso Radio Terrestre UMTS (UTRAN) se han publicado como Versión 8 (Ver. 8 de LTE). El sistema LTE proporciona un acceso radio basado en paquetes y redes de acceso radio con una funcionalidad completa basada en IP con una baja latencia y bajos costes. LTE especifica múltiples anchos de banda de transmisión para conseguir un despliegue flexible del sistema. En el enlace descendente, se utiliza un acceso radio basado en Multiplexación por División de Frecuencia Ortogonal (OFDM), mientras que en el enlace ascendente se ha adoptado un acceso radio basado en acceso múltiple por división de frecuencia de una única portadora (SC-FDMA). Se utilizan muchas técnicas clave de acceso de paquetes radio incluyendo técnicas de transmisión de canal de múltiples entradas múltiples salidas (MIMO) y en la Ver. 8/9 de LTE se consigue una estructura de señalización de control altamente eficiente.

El espectro de frecuencia para IMT Avanzado (4G) se decidió en la Conferencia Mundial de comunicación Radio 2007 (WRC-07). El IMT Avanzado, que incluye L^tE Avanzado (también conocido como LTE-A o Ver. 10 de LTE), proporciona una plataforma global sobre la que construir las siguientes generaciones de servicios móviles interactivos que proporcionarán un acceso de datos más rápido, capacidades de itinerancia mejoradas, mensajería unificada y multimedia de banda ancha. La especificación de LTE-A introdujo mejoras como, por ejemplo, agregación de portadoras, mejoras multiantena y repetidores (Nodos de Repetición). La especificación del 3GPP de LTE-A finalizó en marzo de 2011 y soporta velocidades pico de datos de hasta 3,5 Gbit/s en el enlace descendente y 1,5 Gbit/s en el enlace ascendente. Además, LTE-A introduce el soporte de Redes Auto Organizadas (SON), Difusión Multimedia/Servicio de multidifusión (MBMS) y Redes Heterogéneas (HetNet). Otras mejoras de LTE-A sobre LTE incluyen mejoras de arquitectura para (e)NodosB Domésticos (esto es, femtoceldas), descarga de tráfico IP local, optimizaciones para comunicaciones máquina a máquina (M2C o MTC), mejoras SRVCC, mejoras eMBMS, etc.

En diciembre de 2012, en el 3GPP se estandarizaron mejoras adicionales a LTE-A en la Ver. 11 de LTE-A. Esta es la última versión de LTE-A actual, y presenta características como transmisión/recepción Coordinada Multipunto (CoMP), mejoras de Coordinación de Interferencias Entre Celdas (ICIC), Mejoras de Red para la Comunicación de Tipo Máquina (NIMTC), etc.

Arquitectura LTE

La Fig. 1 muestra a modo de ejemplo la arquitectura de LTE, la cual también aplica igualmente a LTE-A. La E-UTRAN comprende el eNodoB (que también se puede denominar estación base). El eNodoB proporciona el plano de usuario de E-UTRA (PDCP/RlC/MAC/PHY) y terminaciones del protocolo del plano de control (RRC) hacia el equipo de usuario (UE). El eNodoB (eNB) aloja las capas Física (PHY), de Control de Acceso al Medio (MAC), de Control del Enlace Radio (RLC) y del Protocolo de Control de Paquetes de Datos (PDCP) que incluyen la funcionalidad de compresión y cifrado de cabeceras del plano de usuario. El eNodoB también es responsable de gestionar la funcionalidad de Control de Recursos Radio (RRC) correspondiente al plano de control y también implementa varias funciones de gestión adicionales que incluyen la gestión de recursos radio, el control de admisión, la planificación, la aplicación de una Calidad de Servicio (QoS) negociada del enlace ascendente, difusión de información de celda, cifrado/descifrado de datos del plano de usuario y de control, y compresión/descompresión de cabeceras de paquetes del plano de usuario del enlace descendente/enlace ascendente. Los eNodosB se interconectan entre sí mediante la interfaz X2.

Los eNodosB también se conectan al EPC (Núcleo de Paquetes Evolucionado) mediante la interfaz S1, más específicamente a la MME (Entidad de Gestión de Movilidad) mediante la interfaz S1-MME y a la Pasarela de Servicio (S-GW) mediante la interfaz S1-U. La interfaz S1-U utiliza el GTP-U (Protocolo de Tunelización de GPRS Plano de Usuario), mientras que la interfaz S1-MME implementa SCTP (Protocolo de Trasmisión de Control de Flujos) o S1-AP (S1 - Protocolo de Aplicación). La interfaz S1 soporta una relación muchos a muchos entre las MME/Pasarelas de servicio y los eNodosB.

La S-GW encamina y reenvía paquetes de datos de usuario, mientras que también actúa como el anclaje de movilidad para el plano de usuario durante los traspasos entre eNodosB y como el anclaje para movilidad entre LTE y otras tecnologías 3GPP. La S-GW termina las interfaces S4 y S12 y reenvía el tráfico entre sistemas 2G/3G (vía SGSN) y la GW PDN (P-GW). Para los UE en estado inactivo, la S-GW termina la ruta de datos del enlace descendente y activa la búsqueda cuando llegan los datos del enlace descendente para el UE. Gestiona y almacena contextos del UE, por ejemplo, parámetros del servicio de portadora IP o información de encaminamiento interno de red. También realiza una replicación del tráfico de usuario en el caso de una intercepción legal.

La MME es el nodo de control clave para la red de acceso LTE. Es responsable del procedimiento de seguimiento y búsqueda para el UE en modo inactivo, incluyendo las retransmisiones. Está involucrada en el proceso de activación/desactivación de portadoras y también es responsable de seleccionar la S-GW para un UE en una conexión inicial y en el momento de un traspaso dentro de LTE que conlleve una relocalización de un nodo de la Red Central (CN). Es responsable de autenticar al usuario (interactuando con e1HSS). La señalización del Estrato de No Acceso (NAS) termina en la MME y también es responsable de la generación y asignación de identidades temporales a los UE. Comprueba la autorización del UE para utilizar la Red Móvil Pública Terrestre (PLMN) del proveedor de servicio y fuerza las restricciones de itinerancia del UE. La MME es el punto de terminación en la red para el cifrado/la protección de integridad para la señalización NAS y se ocupa de la gestión de claves de seguridad. La MME también soporta la intercepción legal de señalización. La MME también proporciona la función de plano de control para movilidad entre LTE y las redes de acceso 2G/3G con la interfaz S3 que termina en la MME desde la SGSN.

La MME también termina la interfaz S6a hacia el HSS local para la itinerancia de los UE. Además, la MME también está conectada al CSS (Servidor de Abonados CSG) a través de la interfaz S7a y al EIR (Registro de Identidad de Equipos) a través de la interfaz S13.

Actualizaciones de Software

La estructura de una comunicación móvil como, por ejemplo, LTE o LTE-A, es muy compleja y se descompone en entidades lógicas más gestionables conocidas como entidades de red. Una entidad de red puede ser bien una instalación o bien un equipo que realiza algunas funciones de la red móvil. Ejemplos de funciones de la red móvil son SGSN, MME, MSC (Centro de Conmutación Móvil), MSS (Servidor de Conmutación móvil), S-GW, GGSN y P-GW.

La Fig. 2 muestra una implementación de ejemplo y general de una función de red móvil. Una instancia de una función de red móvil consiste típicamente en una aplicación que implementa la función de red móvil específica, una plataforma software para servicios que se utilizan comúnmente (algunas veces también denominado middleware) y un sistema operativo ejecutándose en algún hardware informático. Para propósitos como, por ejemplo, compartición o balanceo de carga, alta disponibilidad, etc., se pueden proporcionar múltiples instancias de la función de red móvil que operan en paralelo. Una instancia de función de red móvil puede cooperar con otras instancias equivalentes en cada capa de implementación, esto es, aplicación, plataforma y sistema operativo. En función de la utilización y los requisitos de capacidad de entrada de tráfico en una red concreta, se puede desplegar un número variable de instancias de función de red móvil con el fin de satisfacer estos requisitos.

Uno de los problemas en este tipo de implementación es que el software para la aplicación, la plataforma y el sistema operativo puede evolucionar en el tiempo y es necesaria su actualización para arreglar errores y/o añadir nuevas funcionalidades. Sin embargo, las redes móviles tienen un requisito muy estricto sobre la disponibilidad de los servicios a los usuarios finales. Por lo tanto, se espera que cuando sea necesario actualizar las funciones de red móvil, la red móvil debería seguir funcionando y proporcionando servicios de comunicación a los usuarios finales con muy poca o ninguna interrupción.

Otro problema asociado con la actualización es que la nueva versión del software puede no ser compatible con la versión antigua del software. Esto significa que la nueva versión de software y la versión antigua de software no se pueden ejecutar al mismo tiempo. Esto es porque las versiones incompatibles, por definición, se comportan de forma diferente. Tanto si exhiben una interfaz diferente o se producen los datos en un formato diferente, el efecto resultante es que instancias de una función de red móvil de estas versiones incompatibles no pueden cooperar como se desea. Además, el tráfico que llega a una función de red móvil consiste típicamente en servicios orientados a conexión y con estado. Esta información de estado (por ejemplo, información de contexto) se debe preservar en una actualización con el fin de evitar interrumpir conexiones existentes, lo cual provocaría interrupciones del servicio a los usuarios finales.

Previamente se han realizado intentos para resolver los problemas de actualización de software con una mínima o ninguna interrupción de servicio, incluso cuando las versiones antigua y nueva de software son incompatibles. El documento US 7.669.073 B2 describe un método en el que un sistema a actualizar se puede dividir en un número de subsistemas operacionales independientes, siendo uno el sistema activo que continúa proporcionando servicios a los usuarios normalmente y siendo actualizados los otros subsistemas. Por último, los subsistemas aislados se pueden combinar y se reanudará la operación normal.

Las Fig. 3a a 3e ilustran un ejemplo de cómo dicha actualización en modo división se puede utilizar en el contexto de actualizar una función de red móvil que sigue una estructura de instancia general con una aplicación, una plataforma y un sistema operativo. En un primer paso, tal como se muestra en la Fig. 3a, las instancias de función de red móvil se dividen en dos mitades. En la Fig. 3a, las instancias en la parte derecha dejan de servir tráfico de usuario, y como resultado la función de red móvil presta el servicio con aproximadamente la mitad de capacidad. Obsérvese que, por supuesto, existen alternativas sobre cómo se pueden dividir las instancias de función de red móvil. Por ejemplo, en otra implementación que contiene instancias redundantes, dividiendo las instancias en activas y redundantes durante una actualización, se mantiene la capacidad completa pretendida aunque en este caso no existe protección mediante redundancia contra ningún fallo.

En un paso posterior, tal como se muestra en la Fig. 3b, se actualizan las instancias de función de red móvil detenidas previamente en la parte derecha, tal como se indica mediante el rayado de los bloques. Las instancias de función de red móvil actualizadas todavía no sirven tráfico; y como resultado la función de red móvil sigue prestando el servicio a aproximadamente la mitad de la capacidad pretendida, o no existe protección mediante redundancia contra fallos en el caso de la otra implementación mencionada anteriormente.

En el siguiente paso, tal como se muestra en la Fig. 3c, los datos generados por las instancias de función de red móvil que implementan el software con la versión antigua de software se convierten (en formato) para ajustarse al software de la nueva versión de software (si las dos son incompatibles). Ahora el tráfico conmuta desde las instancias de función de red móvil con la versión antigua de software a las instancias de función de red móvil que implementan el software de la versión nueva actualizada. Como resultado, las nuevas instancias de función de red móvil actualizadas prestan de nuevo el servicio a aproximadamente la mitad de la capacidad pretendida debido a que la versión antigua de software de la parte izquierda ya no está sirviendo tráfico de usuario.

En el siguiente paso, tal como se muestra en la Fig. 3d, se actualizan las instancias de función de red móvil en la parte izquierda. Las nuevas instancias de función de red móvil actualizadas en la parte izquierda se combinan con las instancias de función de red móvil actualizadas previamente en la parte derecha, tal como se muestra en la Fig. 3e y ahora el tráfico es servido de nuevo por todas las instancias de función de red móvil actualizadas con la capacidad total pretendida, o en la otra implementación mencionada anteriormente con la protección deseada mediante redundancia.

Si los formatos de datos generados por las versiones antigua y nueva de software son incompatibles, la conversión de datos de la versión de software antigua a la nueva se debe realizar como se ha explicado más arriba. Dicho tipo de conversión de datos se describe, por ejemplo, en el documento US 2009/0089774 A1. Dicha conversión de datos tiende a ser tediosa y requiere una descripción exacta de las diferencias entre las dos versiones de software. El proceso de conversión también suele ser propenso a errores. Por ejemplo, el alto volumen de datos dinámicos que se necesitan convertir en una red móvil típica es probable que conlleve dificultad en la conversión de datos, produciendo algunas interrupciones de servicio involuntarias.

Además, la capacidad de servicio durante la actualización entre los pasos ilustrados en las Fig. 3a a 3c se ha reducido a aproximadamente la mitad, limitando de este modo la flexibilidad para planificar una actualización para que se lleve a cabo únicamente en periodos que no sean pi

bajo una instancia que contiene instancias redundantes, dividiendo las instancias en activas y redundantes durante una actualización, la capacidad total pretendida se mantiene aunque en este caso no existe protección mediante redundancia contra ningún fallo.

Además, si la nueva versión del software no funciona bien después de la acción de cambio en el paso explicado junto con la Fig. 3b más arriba, la recuperación del fallo consiste en reiniciar la versión antigua de software de la función de red móvil, lo cual provocará a su vez un corte del servicio durante el periodo de reinicio.

Ambos documentos WO 94/01819 y WO 2014/122637 divulgan módulos de decisión de gestión de tráfico.

Un objetivo de la invención es sugerir un mecanismo que permita atenuar uno o más de los problemas potenciales mencionados más arriba relacionados con la actualización de una función de red móvil. Otro objetivo de la invención es sugerir un mecanismo que permita una actualización de una función de red móvil en uso. Un objetivo adicional de la invención es sugerir un mecanismo que permita una actualización de una función de red móvil en uso que no interrumpa los servicios y/o que no necesite conversión de datos. Objetivos adicionales son evitar la reducción de la capacidad de servicio o la protección contra fallos mediante redundancia mientras que el sistema se está actualizando, y permitir una recuperación rápida si falla la actualización del software.

Aspectos de la presente invención se definen en las reivindicaciones adjuntas.

Breve descripción de las figuras

A continuación se describen los siguientes modos de realización de la invención con más detalle haciendo referencia a las figuras y dibujos adjuntos. Detalles parecidos o correspondientes en las figuras están marcados con los mismos números de referencia.

Fig. 1 muestra la arquitectura de un sistema LTE/LTE-A;

Fig. 2 muestra una implementación de ejemplo y general de una función de red móvil;

Fig. 3a a 3e muestran un ejemplo de cómo se puede utilizar una actualización en modo división en el contexto de actualización de una función de red móvil que sigue una estructura general de instancias con aplicación, plataforma y sistema operativo;

Fig. 4 muestra un procedimiento de actualización de ejemplo para actualizar una versión actual de software de una función de red móvil a una nueva versión de software de acuerdo con un modo de realización de la invención;

Fig. 5 muestra un equipo de ejemplo para implementar un método de actualización de software en servicio de acuerdo con un modo de realización de ejemplo;

Fig. 6 muestra un diagrama de flujo de un procedimiento de actualización de acuerdo con un modo de realización de ejemplo de la invención desde la perspectiva de una entidad de red de la red de comunicación móvil que controla el procedimiento de actualización;

Fig. 7 muestra una implementación de ejemplo del paso 601 de preparación de la actualización de la Fig. 6; y

Fig. 8 muestra una implementación de ejemplo del procedimiento de limpieza de la actualización en el paso 612 de la Fig. 6.

Descripción detallada

Los siguientes párrafos describirán varios modos de realización de los diferentes aspectos. Tal como se ha indicado más arriba, un primer aspecto de la invención está relacionado con una migración desde la utilización de instancias que proporcionan una función de red móvil implementada con una versión antigua (actual) de software a instancias que proporcionan la función de red móvil implementada con una versión nueva (actualizada) de software. Una de las características principales de este primer aspecto es que ambas, las versiones antigua y nueva de software del software que implementa la función de red móvil se ejecutan al mismo tiempo durante la actualización, lo cual permite eliminar los problemas que se producen de incompatibilidad de las dos versiones de software. La disponibilidad de las dos versiones diferentes del software que se ejecuta en una entidad de red se puede conseguir añadiendo a las una o más instancias existentes que implementan la función de red móvil de acuerdo con el software actual, esto es, antiguo, otras una o más instancias que implementan la función de red móvil de acuerdo con el software nuevo, esto es, actualizado. El número de instancias que implementan la función de red móvil de acuerdo con el software actual se puede reducir, por ejemplo, en uno o más pasos hasta que no exista ninguna instancia más. Al mismo tiempo y/u opcionalmente, se pueden añadir una o más instancias que implementan la función de red móvil de acuerdo con el nuevo software actualizado, por ejemplo, en uno o más pasos, con el fin de completar la migración del software. En este proceso de migración, una o más de las instancias gestionan el tráfico de control que proporciona la función de red móvil implementada con una versión antigua (actual) de software. Estas una o más instancias distribuyen las peticiones a las instancias que implementan la función de red móvil de acuerdo con el software actual y actualizado. La distribución se puede controlar mediante diferentes criterios o mediante uno o más perfiles que podrían ser configurados, por ejemplo, por una entidad de gestión.

La actualización de una función de red móvil de acuerdo con uno de los varios modos de realización descritos en la presente solicitud más abajo se puede implementar en una entidad de red como, por ejemplo, pero no limitada a, una estación base (Nodo B), una MME, una PDN-GW, una S-GW, una SGSN una GGSN, una PCRF, etc. por supuesto, la invención no está limitada a la actualización de entidades de red en un sistema de comunicación móvil basado en 3GPP.

La Fig. 4 ilustra un procedimiento de actualización de ejemplo para actualizar una versión actual de software de una función de red móvil a una nueva versión de software de acuerdo con un modo de realización de la invención. En este procedimiento, en un primer paso 401, se siguen ejecutando una o más instancias de la versión actual de software que implementan la función de red móvil. Mientras que estas una o más instancias de la versión antigua de software sirven todo el tráfico (del plano de control y del plano de usuario), se inicia/añade la nueva versión de software con capacidad limitada, pero todavía no da servicio a ningún tráfico real. En el segundo paso 402 posterior, el nuevo tráfico de control que comprende nuevas peticiones de servicio se encamina a las una o más instancias establecidas de la nueva versión de software, mientras que el tráfico existente sigue siendo soportado por la versión antigua de software. En un tercer paso 403 posterior, aumenta la capacidad de servicio de la nueva versión de software, por ejemplo, añadiendo (sucesivamente) instancias adicionales que implementan la función de red móvil basada en la nueva versión de software, mientras que disminuye la capacidad de servicio de la versión antigua de software, por ejemplo, eliminando (sucesivamente) instancias que implementan la función de red móvil basada en la versión antigua de software. Tal como se indica en 404, el tamaño de la capacidad de servicio de la versión antigua de software puede disminuir sucesivamente hasta que, en el cuarto paso 405, no existe nada o existe muy poco tráfico servido por la(s) instancia(s) de la versión antigua de software. En este cuarto paso 405, todo el tráfico que entra en la entidad de red se puede dirigir a la(s) instancia(s) que implementa(n) la función de red móvil de acuerdo con la nueva versión de software.

Obsérvese que cuando se pasa del tercer paso al cuarto paso, esto puede conllevar la migración de algunos usuarios actualmente servidos por las instancias de la versión antigua de software internamente a las instancias de la versión antigua de software. Sin embargo, esto no es obligatorio, también es posible eliminar la última instancia de acuerdo con la versión antigua de software cuando esta instancia ya no sirve a ningún usuario. La reducción (sucesiva) de instancias/capacidad que ejecuta la versión antigua de software también puede conllevar el traslado del servicio de algunos usuarios de una primera instancia que ejecuta la versión antigua de software a otra segunda instancia que ejecuta la versión antigua de software, de modo que la primera instancia se pueda eliminar.

Una versión del software puede estar formada por una pila completa consistente en la aplicación, la plataforma y el sistema operativo, pero no es obligatorio. Una versión del software también puede implementar uno o un subconjunto de un grupo de módulos que comprende la aplicación, la plataforma y el sistema operativo. También se debería observar que en el caso de que el tráfico de control comprenda una nueva petición de servicio se encamina a una instancia implementada por la nueva versión de software, el procesamiento de la petición de servicio por parte de la instancia implementada por la nueva versión de software puede conllevar la creación de un plano de usuario. A continuación el tráfico de plano de usuario es servido por esta instancia implementada por la nueva versión de software.

Las ventajas del proceso de migración descrito más arriba para actualizar un software que implementa una función de red móvil pueden incluir:

1. Los servicios/sesiones/portadoras en curso no se interrumpen. Esto es debido a que es posible que los servicios/sesiones/portadoras ya establecidos al iniciar el proceso de actualización pueden seguir siendo servidos por una instancia implementada de acuerdo con la versión antigua de software, y únicamente las nuevas peticiones de servicio serán gestionadas por una instancia que está implementada con la nueva versión de software.

2. La actualización de software se podría hacer en cualquier momento del día ya que se sigue proporcionando la capacidad completa pretendida incluso durante la actualización y/o se sigue proporcionando la protección frente a fallos mediante redundancia.

3. Para la actualización son necesarios unos mínimos recursos adicionales debido al aumento y disminución de utilización de recursos incremental sobre las versiones nueva y antigua de software.

4. El test de la nueva versión de software se puede realizar con tráfico real, mientras que la versión antigua de software sigue sirviendo el tráfico existente al iniciar la actualización (y opcionalmente una parte de los nuevos servicios). Por lo tanto, la(s) instancia(s) de la versión antigua de software siempre puede(n) ofrecer una capacidad de servicio completa, incluso durante el test inicial.

5. El proceso de migración permite una recuperación rápida en caso de errores, ya que la versión antigua de software se sigue ejecutando en una o más instancias y reanudará el servicio a capacidad completa tan pronto como la nueva versión de software se desconecte.

6. La coexistencia de las versiones antigua y nueva de software reduce de forma significativa el problema de gestión de incompatibilidad entre versiones ya que no es necesaria una sincronización de datos en tiempo real entre las versiones antigua y nueva de software.

7. Se soporta el concepto de actualización incremental asignando una cantidad limitada de tráfico a la nueva versión de software en cada etapa. Si se comprueba que la nueva versión de software funciona correctamente, gradualmente se puede encaminar más tráfico a la nueva versión de software hasta que la nueva versión de software gestione todo el tráfico. Si se produce un error en la nueva versión de software, el impacto es limitado, tal como se pretende.

8. El esquema de migración propuesto permite una actualización uniforme en la mayor parte de susbsistemas lógicos de negocio en una red móvil.

Tal como se ha indicado más arriba, para la migración desde una versión antigua de software a una nueva versión de software de acuerdo con el procedimiento anterior descrito junto con la Fig. 4, se pueden involucrar los siguientes dos procedimientos. En primer lugar, se puede prever la migración pasiva o activa de un usuario servido por una instancia implementada por la versión antigua de software a una instancia implementada por la versión nueva de software (o viceversa), por ejemplo, con el fin de conseguir un aumento y disminución graduales de la capacidad de servicio de la(s) instancia(s) implementada(s) de acuerdo con las versiones nueva y antigua de software. Por ejemplo, y sin perder generalidad, los estándares de redes móviles como, por ejemplo, aquellos proporcionados por el 3GPP especifican típicamente que los recursos asociados con un usuario se liberan cuando se encuentran en estado “reposo” o “no activo”, permitiendo la migración de los usuarios desde una instancia de función de red a otra sin interrumpir el servicio. Por ejemplo, se podrían implementar la MME y la SGSN utilizando los procedimientos estándares de conexión/desconexión y la eliminación no forzada de contextos PDP. La GGSN, PGW y SGW se podrían implementar mediante el estándar de eliminación no forzada de contextos PDP.

Por lo tanto, para una migración pasiva, las instancias de la versión antigua de software pueden seguir proporcionando servicio a aquellos servicios existentes hasta el inicio del procedimiento de actualización y se pueden eliminar una vez que todos los servicios hayan terminado (por ejemplo, cuando se hayan eliminado todos los contextos asociados con dichos servicios). Esto también puede involucrar el traslado de algunos servicios en curso (por ejemplo, contextos asociados) desde una instancia implementada por la versión antigua de software a otra, con el fin de hacer posible la eliminación de algunas instancias implementadas por la versión antigua de software. En una migración activa, algunos usuarios podrían ser activamente traspasados durante un servicio en curso desde sus instancias (de servicio iniciales) implementadas por la versión antigua de software a otra instancia implementada por la versión antigua de software.

En segundo lugar, y en línea con el segundo aspecto de la invención, se diferencia entre tráfico antiguo y nuevo (o con más precisión, entre servicios existentes y nuevos servicios) y se distribuye en consonancia el tráfico entrante. De acuerdo con este segundo aspecto de la invención, se sugiere un módulo de decisión de gestión de tráfico que gestione la distribución de una petición de servicio entrante del plano de control a instancias que implementan la función de red móvil de acuerdo con la versión actual de software o con una versión actualizada de software. Mediante el control del tráfico del plano de control mediante un módulo de decisión de gestión de tráfico, se puede evitar la necesidad de conversiones de datos ya que los servicios portadores o sesiones que se están ejecutando al iniciar la actualización pueden seguir siendo servidos por instancias implementadas utilizando la versión antigua (actual) de software.

En el contexto de ejecución simultánea de las versiones antigua y nueva de software, el mantenimiento de servicios orientados a conexión sin interrupción durante una actualización puede requerir, entre otros, que el módulo de decisión de gestión de tráfico encamine el tráfico del plano de control de los servicios ya establecidos (por ejemplo, sus correspondientes sesiones y/o portadoras) a la versión antigua de software con el fin de garantizar que no existe interrupción del servicio. Además, el módulo de decisión de gestión de tráfico también puede encaminar a la nueva versión de software las nuevas peticiones de servicio (por ejemplo, conexión, creación de contexto PDP, peticiones de creación de sesión, etc.) y su tráfico de señalización posterior. El plano de control creará en la nueva versión de software los datos de estado relacionados con el tráfico de usuario correspondiente (por ejemplo, el contexto PDP del plano de usuario) y el tráfico de usuario será soportado en la nueva versión de software. Obsérvese que el tráfico de plano de usuario se establece mediante el plano de control y se encamina a una instancia de una versión antigua o nueva de software, por ejemplo, en función de qué instancia ha creado el plano de usuario.

Como consecuencia, se generan por separado los datos del tráfico antiguo y nuevo en las versiones antigua y nueva de software respectivamente. Esto puede permitir eliminar la necesidad de realizar la conversión de los datos dinámicos generados por la versión antigua de software a la nueva durante la actualización. Durante la actualización se puede dar servicio a capacidad completa o más que capacidad completa combinando la capacidad de las instancias de función de red móvil implementadas por las versiones antigua y nueva de software. Si la nueva versión de software no funciona correctamente, la recuperación es rápida ya que la versión antigua de software sigue ejecutándose y sirviendo tráfico.

La diferenciación entre servicios/tráfico ya establecido y nuevo puede ser más exigente. Los servicios/tráfico viejos y nuevos pueden no diferenciarse en los protocolos de las capas inferiores (por ejemplo, física, enlace de datos o capa de enlace) sino que típicamente sólo se producen en las capas superiores dentro del módulo de gestión del protocolo específico de una función de red móvil. La diferenciación entre los nuevos servicios y los servicios existentes es importante cuando se consideran protocolos con estado, ya que la interrupción del servicio durante una actualización es particularmente relevante con respecto a protocolos con estado. Como ejemplo, la Fig. 1 presenta las interfaces y protocolos entre las entidades de una red EPC que proporcionan funciones de red móvil en una red móvil. Los protocolos con estado que se muestran en la EPC son, por ejemplo, GTP-C, PMIP, SCTP/Diameter y SCTP/S1 -AP.

La Fig. 5 muestra un equipo de ejemplo para implementar un método de una actualización de software en uso de acuerdo con un modo de realización de ejemplo. El equipo se puede implementar, por ejemplo, en una entidad de red de un sistema de comunicación móvil. El equipo está formado por una instancia que implementa la función de red móvil de acuerdo con una versión antigua de software (“instancia de versión antigua de software”), y otra instancia que implementa la misma función de red móvil de acuerdo con una nueva versión de software (“instancia de nueva versión de software”). En la parte de la versión antigua de software, se implementa un decisor de tráfico (también denominado módulo de decisión de gestión de tráfico en la presente solicitud), un agente de actualización y un conjunto de reglas (política/políticas) asociadas con un protocolo específico en la instancia que implementa la función de red móvil. En la parte de la versión nueva de software, la instancia se implementa utilizando la nueva versión de software de la función de red móvil, un agente de actualización y un conjunto de reglas asociadas con un protocolo específico para la misma función de red móvil.

Antes de la actualización, en ambas versiones de software antigua y nueva se deben definir reglas específicas para cada protocolo como, por ejemplo, cómo detectar el primer paquete, los criterios para decidir cuál es el tráfico antiguo y cuál el nuevo. Los agentes de actualización se instalan y configuran de acuerdo con las reglas específicas del protocolo de cada versión. El decisor de tráfico se instala y configura en la parte de la versión antigua de software. Durante la operación de actualización, el tráfico de control entra 501 (exclusivamente) a través de la instancia implementada por la versión antigua de software. En función de las reglas específicas del protocolo, el decisor de tráfico separa el tráfico entrante en tráfico viejo o nuevo (esto es, sesiones ya activas iniciadas antes de la actualización y nuevas sesiones), y encamina el tráfico de control correspondiente a la instancia implementada con la nueva versión de software (ver 504) o internamente (ver 502) dentro de la instancia implementada con la versión antigua de software.

En la ruta de tráfico antiguo, el tráfico de control se envía al software de la versión local, antigua de software para su procesamiento y el resultado del procesamiento sale 503 de la parte de la versión antigua de software. Con relación a la ruta del tráfico nuevo, el tráfico de control se envía 504 en primer lugar al agente de actualización local. El agente de actualización local reenvía 505 el tráfico al agente de actualización en la parte de la nueva versión de software. Allí, el agente de actualización en la parte de la nueva versión de software envía 506 el tráfico al software de la nueva versión de software para su procesamiento y el resultado del procesamiento se devuelve 507 al agente de actualización en la parte de la nueva versión de software. El agente de actualización en la parte de la nueva versión de software reenvía 508 el resultado al agente de actualización en la parte de la versión antigua de software. El resultado sale 509 en la parte de la versión antigua de software.

En algunos modos de realización, la operación de actualización la dirige típicamente la entidad de gestión de una red móvil. En el diagrama de flujo de la Fig. 6 se muestra el procedimiento de actualización global, desde el punto de vista de una entidad de gestión, de acuerdo con un modo de realización de ejemplo. Como primer paso, antes de que se pueda realizar la operación de actualización se prepara 601 un sistema software en la entidad de red a actualizar. Los detalles de este paso de preparación se explicarán junto con la Fig. 7 más abajo. En un paso de verificación 602 se verifica si se ha realizado satisfactoriamente la preparación de la actualización. Si existe un error durante la preparación de la actualización, se realiza una gestión 603 de fallo de preparación y se aborta la operación de actualización.

Después de una preparación satisfactoria, tal como se indica en los ejemplos anteriores, durante la operación de actualización en curso, la capacidad de servicio de la versión antigua de software en la entidad de red puede disminuir 604 al tiempo que la capacidad de servicio de la nueva versión de software aumenta 605. En el paso 606 se realiza una verificación de los resultados entregados por la nueva versión de software. Si se produce un error en esta verificación, se realiza 607 una gestión de fallo de actualización y se aborta la actualización. Si los resultados de la actualización se pueden verificar satisfactoriamente en 606, se repiten los pasos 604, 605 y 606 hasta que el paso 608 de verificación determina que la(s) instancia(s) de la nueva versión de software es/son capaz/capaces de gestionar toda la carga de tráfico. Cuando se han cumplido determinadas condiciones predefinidas de la actualización, todo el tráfico restante se conmuta 609 a la(s) nueva(s) instancia(s) de la nueva versión de software. Se realiza una verificación 610 de la operación de conmutación. Si existe un error, se realiza 611 una gestión de fallo de conmutación asociada y se aborta la actualización.

Antes de que se pueda confirmar la actualización se realiza una operación 612 de limpieza. Los detalles de este paso de limpieza se explicarán junto con la Fig. 8 más abajo. De nuevo se verifica 613 si la limpieza se ha realizado satisfactoriamente, y en caso contrario se realiza una gestión 614 de fallo de limpieza. En el caso de que la limpieza haya sido satisfactoria, se confirma 615 la actualización.

La Fig. 7 muestra una implementación de ejemplo de la preparación del procedimiento 601 de actualización de la Fig. 6. Los pasos 702 y 703 de preparación incluyen configurar los agentes de actualización en la instancia de versión antigua de software y la instancia de la nueva versión de software tal como se muestra en la Fig. 5. La preparación 703 específica de aplicación conlleva obtener y configurar las reglas para detectar cuándo se realiza una nueva petición de conexión en el tráfico de control bajo el protocolo específico de aplicación para la función de red móvil dada con el fin de permitir que el decisor de tráfico en la instancia de versión antigua de software de la Fig. 5 discrimine las peticiones de conexión de otro tráfico de control y encamine las nuevas peticiones de conexión a la instancia de la nueva versión de software (asumiendo que las políticas se han configurado en consecuencia). También se realiza 704 una verificación de la operación de preparación.

La Fig. 8 muestra una implementación de ejemplo del procedimiento 612 de limpieza de actualización. La operación de limpieza de ejemplo incluye un procedimiento 801 de limpieza específico de aplicación. Además, se realiza una limpieza de la(s) instancia(s) 802 de la versión antigua de software eliminada(s) y una limpieza de la instalación de la(s) instancia(s) 803 de la nueva versión de software, seguido por la verificación 804 de que los subprocesos de limpieza se han ejecutado satisfactoriamente.

Por razones de gestionabilidad y flexibilidad, la implementación de una red móvil sigue típicamente el principio de diseño de separación de política y mecanismo, lo cual básicamente indica en la política qué es necesario hacer mientras que el mecanismo especifica cómo se realiza. Esto es especialmente predominante en la gestión de una red móvil. En la mayoría de los ejemplos anteriores se ha asumido que la operación de actualización se ha completado cuando la nueva versión de software se hace cargo y sirve la capacidad total del tráfico.

Sin embargo, existen muchos otros escenarios que pueden ser definidos por las políticas, lo cual permite conmutar a la nueva versión de software en los pasos 608 y 609 de la Fig. 6. Por ejemplo, el paso 608 también podría verificar si la nueva versión de software da servicio a un X% de los usuarios, y proceder con la conmutación 609 si éste es el caso. Otra alternativa puede ser comprobar en el paso 608 si la versión antigua de software da servicio a un Y% de la capacidad de tráfico de los usuarios, y proceder con la conmutación 609 si éste es el caso. En aún otro ejemplo el paso 608 podría comprobar si un grupo predeterminado de usuarios han sido migrados a la versión nueva de software, y realizar la conmutación 609 si éste es el caso. Tal como se ha observado más arriba, se pueden definir las políticas para controlar el proceso de migración y decidir cuándo realizar la conmutación 609 a la nueva versión de software.

Un equipo como el que se ejemplifica en la Fig. 6, esto es, cómo está hecho, puede aplicar el mecanismo de actualización correspondiente. Específicamente, el decisor de tráfico proporciona un mecanismo de soporte como parte de su función. En otro modo de realización de la invención, el decisor de tráfico se puede operar en diferentes modos, por ejemplo, en uno de los dos modos: habilitado o inhabilitado. El modo de operación del decisor de tráfico puede influir en el comportamiento del decisor de tráfico cuando en el tráfico de control se encuentra una nueva petición de servicio, basado en el protocolo específico de aplicación para la función de red móvil relevante, esto es si las nuevas peticiones de servicio se encaminan a una instancia de nueva versión de software o a una instancia de versión antigua de software.

Durante la operación normal, cuando no existe en curso ninguna operación de actualización, el decisor de tráfico se puede encontrar en modo deshabilitado. Esto significa que todo el tráfico (de control) entrante puede evitar el decisor de tráfico y es servido por la versión actual de software. Alternativamente, el modo deshabilitado también podría considerarse un modo en el que el decisor de tráfico sigue recibiendo el tráfico (de control) entrante, pero sin tomar ninguna decisión de encaminamiento de modo que el tráfico es gestionado en exclusiva por la(s) instancia(s) de la versión actual (“antigua”) de software.

En una operación de actualización, el decisor de tráfico puede operar en modo habilitado. En modo habilitado, tal como se explica junto con la Fig. 5, el decisor de tráfico dirige las conexiones establecidas previamente a las versiones correspondientes, esto es, el tráfico antiguo a la versión antigua de software y el tráfico nuevo a la nueva versión de software, o reenvía la petición de creación de nuevas conexiones a la nueva versión de software a través de los agentes de actualización.

En una operación de actualización, cuando el decisor de tráfico opera en modo deshabilitado, el decisor de tráfico dirige las conexiones establecidas previamente a las versiones correspondientes, esto es, el tráfico antiguo a la versión antigua de software y el tráfico nuevo a la nueva versión de software, o dirige una petición de creación de nueva conexión a la versión antigua local de software.

En función de la política de actualización específica que se fuerce en cada momento, en el decisor de tráfico se puede utilizar el mecanismo de soporte para llevar a cabo las acciones necesarias requeridas. Como ejemplo, en un modo de realización en el que la política de actualización es trasladar todo el nuevo tráfico de creación de conexiones solicitadas a la nueva versión de software. Después, la entidad responsable de la gestión de la actualización traslada esta política a la acción habilitando el decisor de tráfico durante la operación de actualización hasta el final de la operación de actualización.

En otro modo de realización, la política de actualización podría determinar que un cierto porcentaje de las conexiones, por ejemplo, el 10% de las conexiones, se trasladen a la(s) instancia(s) de la nueva versión de software. Después, la entidad responsable de la gestión de la actualización traslada esta política a la acción habilitando el decisor de tráfico para crear nuevas conexiones en la(s) instancia(s) de la nueva versión de software. Cuando se ha alcanzado el nivel deseado del 10%, la entidad de gestión responsable de la actualización deshabilita el decisor de tráfico con el fin de no superar el nivel anterior requerido. Durante este periodo de la actualización, las conexiones establecidas, independientemente de si son rutas de tráfico antiguo o nuevo, son dirigidas por el decisor de tráfico en modo deshabilitado a la versión correcta para su procesamiento.

Se debe observar que los dos modos de realización anteriores son a modo de ejemplo. La invención se puede utilizar en muchos más modos de realización en los que las políticas de actualización se pueden trasladar a secuencias de acciones habilitando y deshabilitando el decisor de tráfico durante la operación de actualización. En resumen, los procedimientos de actualización de ejemplo anteriores son útiles para conseguir las siguientes ventajas:

• Como la capacidad completa pretendida se puede servir mediante una combinación de las instancias de las versiones antigua y nueva de software de la función de red móvil, la actualización se puede realizar en cualquier momento, incluso durante el día y no está restringida por la práctica habitual de realizar la actualización únicamente en momentos no pico como, por ejemplo, la noche.

• Debido al aumento y disminución increméntales de utilización de recursos en las versiones nueva y antigua de software, para la operación de actualización se necesita una mínima cantidad de recursos adicionales.

• El hecho de que tanto las versiones antigua como nueva de software se ejecuten al mismo tiempo durante una actualización, hace que los datos generados por las versiones respectivas sean gestionados en consecuencia por la versión correcta. Esto reduce de forma significativa el problema de incompatibilidad entre versiones. Por ejemplo, de este modo no es necesario una sincronización de datos en tiempo real entre las versiones antigua y nueva de software.

• Si la versión recién actualizada no funciona como se esperaba, como acción de recuperación de fallos se puede revertir la función de red móvil a la versión antigua de software. Esta acción de recuperación de fallos se puede realizar muy rápidamente ya que la versión antigua de software se sigue ejecutando. Tan pronto como se restaure la capacidad total pretendida del tráfico sobre la versión antigua de software, se puede desconectar la nueva versión de software y se completa la acción de recuperación de fallos.

• Con el tráfico establecido de servicios orientados a conexión encaminados a la ruta de tráfico antiguo para su procesamiento por parte de la versión antigua de software, se puede garantizar que no existe interrupción en el servicio.

• El test de la nueva versión de software se puede realizar con tráfico real con la confianza de que si no funciona correctamente, se puede realizar muy rápidamente la acción de recuperación de fallos que revierte a la versión antigua de software debido al hecho de que coexisten la versión antigua y nueva de software.

También se debería observar que las características individuales de los diferentes modos de realización de los aspectos descritos en la presente solicitud pueden ser objeto de otra invención individualmente o en una combinación arbitraria.

Aunque algunos aspectos se han descrito en el contexto de un método, es evidente que dichos aspectos también representan una descripción del equipo correspondiente apropiadamente configurado para aplicar dicho método. En dicho equipo, un bloque o dispositivo (funcional o tangible) se puede corresponder con uno o más pasos del método o una característica de un paso del método. De forma análoga, los aspectos descritos en el contexto de un bloque o elemento o característica correspondiente de un equipo correspondiente también se pueden corresponder con los pasos individuales del método correspondiente.

Además, los métodos descritos en la presente solicitud también pueden ser ejecutados por (o utilizar) un equipo hardware, como un procesador, un microprocesador, un ordenador programable o un circuito electrónico. Algunos o más de los pasos más importantes del método pueden ser ejecutados por dicho equipo. Donde un equipo se ha descrito en la presente solicitud en términos de elementos funcionales, por ejemplo, unidad de procesamiento, unidad de recepción, unidad de transmisión, etc., también se debería entender que dichos elementos del equipo se pueden implementar completa o parcialmente como elementos/circuitería hardware. El hardware individual, como un procesador o un microprocesador, una circuitería transmisora, una circuitería receptora, etc., se puede utilizar para implementar la funcionalidad de uno o más elementos del equipo.

Además, cuando la información o los datos se van a almacenar en el proceso de implementación de un paso del método del elemento funcional de un equipo en hardware, el equipo puede comprender una memoria o un medio de almacenamiento, el cual puede estar acoplado comunicativamente a uno o más elementos/circuitería hardware del equipo.

También se contempla implementar los aspectos de la invención en hardware, en software o en una combinación de los mismos. Esto se puede hacer utilizando un medio de almacenamiento digital, por ejemplo un disco flexible, un DVD, un Blu-Ray, un CD, una ROM, una PROM, una EPROM, una EEPROM, o una memoria FLASH, teniendo almacenadas en ellas señales de control o instrucciones legibles electrónicamente, las cuales cooperan (o son capaces de cooperar) con un sistema informático programable de modo que se aplique el método respectivo. Se puede proporcionar un soporte de datos que tenga señales de control o instrucciones legibles electrónicamente, las cuales son capaces de cooperar con un sistema informático programable de modo que se aplique el método descrito en la presente solicitud.

También se contempla implementar los aspectos de la invención en forma de producto de programa informático con un código de programa, siendo operativo el código de programa para aplicar el método cuando el producto de programa informático se ejecute en un ordenador. El código de programa se puede almacenar en un soporte legible por una máquina.

La descripción anterior es únicamente ilustrativa, y se entiende que las modificaciones y variaciones de las disposiciones y los detalles descritos en la presente solicitud serán evidentes para otros experimentados en la técnica. Por lo tanto, se pretende estar limitado únicamente por el alcance de las siguientes reivindicaciones y no por los detalles específicos presentados a modo de descripción y explicación más arriba.

Claims

REIVINDICACIONES

1. Un módulo de decisión de gestión de tráfico para su utilización en una entidad de red de un sistema de comunicación móvil, en donde el módulo de decisión de gestión de tráfico se proporciona dentro de una instancia que implementa, en la entidad de red, una función de red móvil de acuerdo con una versión actual de software, en donde el módulo de decisión de gestión de tráfico comprende:

un submódulo de recepción configurado para recibir tráfico del plano de control, comprendiendo el tráfico del plano de control peticiones a la función de red móvil; caracterizado por:

un submódulo de decisión configurado para decidir, para cada petición recibida, si la petición respectiva va a ser procesada por una instancia que implementa la función de red móvil de acuerdo con la versión actual de software o una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software;

en donde el submódulo de decisión está configurado para tomar su decisión en función de una o más políticas configuradas por una entidad de gestión de la red de comunicación móvil;

un submódulo de encaminamiento configurado para encaminar cada petición a una instancia que implementa la función de red móvil de acuerdo con la versión actual de software o a una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software, en función de la decisión del submódulo de decisión; en donde las una o más políticas incluyen una política de acuerdo con la que las peticiones del tráfico del plano de control asociadas a una nueva portadora o sesión a establecer después de la activación de la política se van a encaminar a una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software.

2. El módulo de decisión de gestión de tráfico de la reivindicación 1, en donde la función de red móvil comprende al menos una de una función del plano de control, una función del plano de usuario, o una función de gestión implementada por la entidad de red del sistema de comunicación móvil.

3. El módulo de decisión de gestión de tráfico de una de las reivindicaciones 1 o 2, en donde la función de red móvil comprende funcionalidad implementada por la entidad de red en el sistema de comunicación móvil.

4. El módulo de decisión de gestión de tráfico de una de las reivindicaciones 1 a 3, en donde el módulo de decisión de gestión de tráfico se implementa mediante software de un protocolo con estado de una capa de red o una capa superior dentro de la pila de protocolos OSI.

5. Un método para actualizar una versión actual de software que implementa una función de red móvil sin interrumpir servicios de portadora o sesiones en curso, comprendiendo el método:

proporcionar (401) la función de red móvil en una entidad de red ejecutando una o más instancias que implementan la función de red móvil de acuerdo con la versión actual de software; caracterizado por

añadir (402) en la entidad de red al menos una instancia que implementa la función de red móvil de acuerdo con una versión actualizada de software;

recibir (403), en una o más de las instancias que implementan la función de red móvil de acuerdo con la versión actual de software, tráfico del plano de control que comprende peticiones a la función de red móvil;

decidir en función de una o más políticas, si encaminar una petición respectiva a una instancia que implementa la función de red móvil de acuerdo con la versión actual de software o a una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software;

encaminar (404), un subconjunto de las peticiones dentro del tráfico del plano de control recibido desde la instancia respectiva de una versión actual de software a una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software;

procesar (405), en cada una de las instancias de implementadas por la versión actualizada de software y en cada una de las instancias de la versión actual de software, las peticiones recibidas en las respectivas instancias; en donde las una o más políticas incluyen una política de acuerdo con la que las peticiones del tráfico del plano de control asociadas a una nueva portadora o sesión a establecer después de la activación de la política se van a encaminar a una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software.

6. El método de acuerdo con la reivindicación 5, que comprende, además:

establecer, por parte de una instancia que implementa la función de red móvil de acuerdo con la versión actual de software, una portadora para una sesión como respuesta al procesamiento de la petición dentro de dicha instancia que implementa la función de red móvil de acuerdo con la versión actual de software,

recibir, a través de la portadora establecida, tráfico de plano de usuario de dicha sesión en una instancia que implementa la función de red móvil de acuerdo con la versión actual de software,

establecer, por parte de una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software, una portadora para una sesión como respuesta al procesamiento de la petición dentro de dicha instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software, y

recibir, a través de la portadora establecida, tráfico de plano de usuario de dicha sesión en una instancia que implementa la función de red móvil de acuerdo con la versión actualizada de software.

7. El método de acuerdo con una de las reivindicaciones 5 o 6, que comprende, además, eliminar una o más de las instancias que implementan la función de red móvil de acuerdo con la versión actual de software.

8. El método de acuerdo con la reivindicación 7, en donde se elimina una instancia como respuesta a la eliminación o expiración de la información de contexto mantenida por la función de red móvil implementada de acuerdo con la versión actual de software, o como respuesta al traslado de la información de contexto mantenida con dicha instancia a otra instancia que implementa la función de red móvil de acuerdo con la versión actual de software, y el método comprende, además, añadir en la entidad de red una o más instancias adicionales que implementan la función de red móvil de acuerdo con la versión actualizada de software, y

como respuesta a la eliminación de la última instancia que implementa la función de red móvil de acuerdo con la versión actual de software, recibir tráfico del plano de control en las una o más instancias que implementan la función de red móvil de acuerdo con la versión actualizada de software y procesar todas las peticiones recibidas dentro de las una o más instancias que implementan la función de red móvil de acuerdo con la versión actualizada de software.