Diseño evolutivo de red.

Scientific Reports volumen 13, número de artículo: 11644 (2023) Citar este artículo

71 Accesos

Detalles de métricas

En los últimos años, han surgido muchos nuevos servicios orientados a la red, y dichos servicios deberán virtualizarse en el entorno informático de acceso múltiple, que actualmente se está estandarizando junto con la tecnología de red de quinta generación. El entorno que rodea la red de funciones de servicio cambia con el tiempo, como cambios importantes en las API, y estos cambios afectan los servicios. El diseño del servicio debe ser adaptable a los requisitos del usuario y a los cambios ambientales para dar cabida a una gran cantidad de servicios a bajo costo. Además, se requiere no sólo asumir cambios ambientales al diseñar inicialmente la red de funciones de servicio, sino también permitir que la red continúe cambiando su estructura para adaptarse a nuevos cambios ambientales en el futuro. En este artículo, proponemos un método para hacer evolucionar toda la red de funciones de servicio basándose en una estructura núcleo/periferia. La ventaja de la estructura núcleo/periferia es que ayuda a reducir los costos de mantenimiento o cambio de servicios al dividir las funciones del servicio en funciones centrales y periféricas. Proponemos un método para desarrollar una red de funciones de servicio basada en esta estructura núcleo/periferia. Nuestro método desarrolla la estructura de la red de funciones de servicio a bajo costo manteniendo las funciones centrales y periféricas en la escala adecuada. Además, nuestro método propuesto se adapta a casi el 100 % de las cadenas de servicios generadas aleatoriamente y mantiene su longitud en menos del doble de la longitud mínima de la cadena. Los resultados de nuestra simulación revelan que la estructura de las redes de funciones de servicio puede continuar evolucionando a un bajo costo y mantener una alta tasa de acomodación de servicios.

En los últimos años han surgido muchos nuevos servicios orientados a redes y las redes de información han ido cambiando rápidamente. Por ejemplo, los servicios de telepresencia1 en rápido desarrollo permiten a los usuarios humanos experimentar estar presentes en un lugar remoto virtualmente operando un robot remoto como si fuera su propio cuerpo y utilizando otras tecnologías de realidad virtual o realidad mixta. Se espera que en el futuro surjan varios servicios diferentes que aún están por realizarse. Dichos servicios deberán virtualizarse en el entorno informático de borde multiacceso2,3,4, que actualmente se está estandarizando junto con la tecnología de red de quinta generación.

Los servicios orientados a la red consisten en funciones de servicio implementadas en múltiples dispositivos. Las funciones de servicio han sido desarrolladas por varios desarrolladores y algunas de ellas están disponibles desde otras funciones de servicio a través de interfaces de aplicación (API). Es decir, se forma y pone a disposición una red de funciones de servicio. El proveedor de servicios combina algunas de las funciones de servicio como una cadena de servicios y las proporciona para satisfacer las necesidades del usuario.

El entorno que rodea la red cambia con el tiempo. Por ejemplo, a medida que aumentan los requisitos de nuevos servicios, es posible que se desarrollen nuevas funciones de servicio o que cambie la popularidad de algunas funciones de servicio. Además, debido a cambios importantes en las API, es posible que los usuarios no puedan utilizar el servicio y que los proveedores de servicios tengan que crear nuevas cadenas de servicios. Xavier et al.5 examinaron los cambios de API y su impacto en las bibliotecas Java y las aplicaciones cliente, y descubrieron que el número de API afectadas aumenta con el tiempo; La frecuencia de cambios importantes en una API determinada aumenta con el tiempo, de aproximadamente 0,29 veces en el primer año de desarrollo a aproximadamente 0,49 veces en el quinto año. Frente al cambio importante u otros posibles cambios, algunos de los servicios se reconfiguran para utilizar las API nuevas o alternativas. La reconfiguración de los servicios y su alojamiento requiere costos de desarrollo, incluido el costo de desarrollo de interfaces para la conexión a API nuevas o alternativas. Por lo tanto, los costos de desarrollo serán altos cuando se desarrollen nuevas interfaces cada vez que se requieran o cuando se conecten a muchas API por adelantado. Por lo tanto, se requiere un diseño de red de funciones de servicio adaptable para permitir que la red de funciones de servicio acomode nuevos servicios a bajo costo. La adaptación a los cambios ambientales requiere la adición de interfaces entre funciones de servicio o el desarrollo de nuevas funciones de servicio. Así, cuando se toman decisiones de diseño que son convenientes en el corto plazo, aumentan los costes de mantenimiento y adaptación de este sistema en el futuro, lo que se conoce como deuda técnica6.

Al predecir los cambios de API y los servicios que probablemente requieran ser adaptados nuevamente y conectar las funciones de servicio requeridas para ellos con menos interfaces, se puede componer una red de funciones de servicio adaptable en ese momento. Sin embargo, no puede satisfacer nuevas demandas de servicios impredecibles. Es difícil predecir cambios en una red de funciones de servicio que consta de funciones de servicio desarrolladas por diferentes desarrolladores. Por lo tanto, se requiere una red de funciones de servicio que continúe adaptándose a cambios impredecibles con bajos costos de desarrollo.

Nos referimos a la red de funciones de servicio que cambia la estructura a bajo costo manteniendo la capacidad de proporcionar nuevos servicios, como una red de funciones de servicio evolutiva.

Los algoritmos con capacidad de evolución incluyen algoritmos genéticos (GA) y estrategias de evolución, que se han aplicado a una variedad de problemas7,8. Sin embargo, estos algoritmos se basan en la presunción de que el problema a resolver se describe como un problema de optimización. Los cambios ambientales en las redes de funciones de servicios incluyen un aumento significativo de las funciones de servicios, y los servicios nuevos, rara vez utilizados, pueden crecer, por ejemplo, debido a una mayor popularidad, pero es difícil predecir qué cambios ambientales ocurrirán en el futuro. Los cambios ambientales que pueden ocurrir en el futuro son demasiado numerosos para enumerarlos y es difícil representar matemáticamente los cambios ambientales futuros como objetivos de problemas de optimización. Por tanto, los métodos para abordar los problemas de optimización tradicionales no pueden mantener una red de funciones de servicio evolucionable a largo plazo.

Hemos estado investigando una estructura núcleo/periferia9,10 que permite que los componentes del servicio se adapten eficazmente a cada solicitud de usuario y variación ambiental. La estructura núcleo/periferia es un modelo de mecanismos de procesamiento de información flexibles y eficientes en sistemas biológicos; las unidades de procesamiento de información en la estructura núcleo/periferia se clasifican como unidades centrales o periféricas. La ventaja de la estructura núcleo/periferia es que ayuda a reducir los costos de mantenimiento o cambio de servicios al distinguir las funciones de servicio en funciones centrales y periféricas. A diferencia del diseño basado en módulos, una red de funciones de servicio diseñada con base en la estructura núcleo/periferia puede acomodar diferentes servicios modificando solo las funciones periféricas y reutilizando las funciones principales. A largo plazo, al mantener el núcleo y la periferia en tamaños apropiados, se puede esperar que esta arquitectura se adapte a grandes aumentos en las funciones de servicio y cambios en las funciones comúnmente utilizadas. El método de mantener la red basado en la estructura núcleo/periferia puede determinar la estructura de la red en la siguiente etapa basándose únicamente en la topología de la red de funciones de servicio en el momento actual. Por tanto, se espera que pueda seguir evolucionando a un coste estable y bajo, independientemente de la incapacidad de predecir los cambios ambientales.

Nuestros trabajos anteriores11,12,13 demostraron que los servicios orientados a la red diseñados en base a una estructura núcleo/periferia pueden adaptarse a los cambios ambientales con un bajo costo de desarrollo al reutilizar el núcleo y recrear solo la periferia. Investigamos numéricamente las ventajas de la estructura núcleo/periferia para acomodar servicios de información, representados por cadenas de funciones11. Además, nos centramos en un servicio de experiencia de compra utilizando realidad mixta y robots como caso de uso para realizar un escenario de servicio basado en11, implementamos el servicio con un dispositivo real y demostramos que el diseño del servicio que utiliza una estructura central/periferia es efectivo para operación del robot cuando aumenta el número de tipos de dispositivos en el lado del usuario y en el lado remoto12,14.

En este artículo, proponemos un método para evolucionar toda la red de funciones de servicio basándose en una estructura núcleo/periferia. Nuestro objetivo es mantener la red de funciones de servicio que tenga una alta capacidad de servicio y al mismo tiempo proporcione estabilidad y bajo costo de desarrollo. La capacidad de prestación de servicios es la capacidad de dar cabida a muchas cadenas de servicios nuevas y de dar cabida a servicios con cadenas de servicio cortas utilizando sólo las funciones de servicio requeridas. Las cadenas de servicios más cortas conducen a servicios más receptivos. Cuando todas las funciones están escasamente conectadas, es decir, cuando las funciones periféricas ocupan la red, el costo de desarrollo al agregar nuevas funciones es pequeño, pero la longitud de la cadena es larga porque requiere funciones adicionales para acomodar las cadenas de servicios. Cuando la red de funciones de servicio está compuesta en una malla completa, es decir, cuando las funciones principales ocupan la red, todas las cadenas de servicios tienen una longitud corta, pero los desarrolladores deben agregar muchas interfaces para mantener una red completamente mallada al agregar nuevas funciones de servicio. Esto hace que el coste de desarrollo sea significativo y hace imposible mantener los servicios en el futuro.

Por lo tanto, proponemos un método para mantener una escala adecuada de funciones centrales y periféricas, con un equilibrio entre los costos de desarrollo y la capacidad de prestación de servicios. Evaluamos nuestro método en términos de la relación de acomodación del servicio y la longitud de la cadena de servicio para mostrar que las redes de funciones de servicio mantienen una alta capacidad de prestación de servicios cuando se aplica nuestro método. Además, evaluamos los costos de desarrollo necesarios para hacer evolucionar la red de funciones de servicio. Los resultados de nuestra simulación revelaron que las redes de funciones de servicio pueden continuar evolucionando con un bajo costo de desarrollo.

La Figura 1 muestra nuestra propuesta basada en una estructura núcleo/periferia. El lado izquierdo representa una red de funciones de servicio que utiliza una estructura núcleo/periferia que puede adaptarse a nuevos dispositivos y servicios cambiando solo la periferia. El lado derecho muestra el método propuesto en este artículo, que evoluciona toda la red de funciones de servicio renovando el núcleo.

Descripción general de nuestro método propuesto.

Nuestras aportaciones son las siguientes. (1) Proponemos un método para desarrollar una red de funciones de servicio utilizando una estructura núcleo/periferia. (2) Mostramos que una red de funciones de servicio puede continuar evolucionando a bajo costo manteniendo el tamaño y la densidad de un núcleo y sus periferias.

El resto de este documento está organizado de la siguiente manera. La sección "Formulación de problemas de la red de funciones de servicio evolutivas" describe nuestro problema de diseño y la formulación del problema. La sección “Control de densidad de la red de funciones de servicio” describe nuestro método para controlar las redes de funciones de servicio. La sección “Evaluación” describe la evaluación de nuestro método. Finalmente, la sección “Conclusión” proporciona algunas observaciones finales y áreas de estudio futuro.

Los algoritmos con capacidad de evolución incluyen AG y estrategias de evolución, que se han aplicado a una variedad de problemas7. Además, Kashan et al.8 propusieron objetivos variables de forma modular para que el AG se adapte a diferentes entornos. Sin embargo, estos algoritmos se basan en la presunción de que el problema a resolver puede describirse como un problema de optimización. Los cambios ambientales que pueden ocurrir en el futuro son demasiado numerosos para enumerarlos y es difícil representar matemáticamente los cambios ambientales futuros como objetivos de problemas de optimización. Proponemos un método para evolucionar las redes de funciones de servicio para que puedan adaptarse a cambios ambientales impredecibles.

Se han realizado muchos estudios sobre cómo acomodar e implementar cadenas de servicios para la virtualización de funciones de red15,16,17,18. Por ejemplo, Bian et al.17 propusieron un esquema distribuido que aproxima la composición de la cadena con una garantía de desempeño y se adapta a fallas de recursos de manera oportuna. Cai et al.18 propusieron un mecanismo activo de reconfiguración de la cadena de servicios basado en la carga computacional y la demanda de recursos. Estos estudios sólo predicen la demanda de recursos y otros factores basándose en datos anteriores, y no continúan evolucionando la red de funciones de servicio a largo plazo.

En el campo del desarrollo de software, como metodología de diseño para proporcionar más servicios a menor costo, se ha introducido ampliamente el diseño basado en módulos. En el diseño basado en módulos, los módulos se conectan entre sí a través de interfaces y los desarrolladores pueden desacoplarlos y reutilizarlos19. Sin embargo, una desventaja del diseño basado en módulos es que el desarrollo se vuelve complejo y los productos resultan difíciles de mantener. Albers et al.20 señalaron que las interdependencias entre los módulos utilizados en diferentes productos aumentan porque los cambios en un módulo afectan a otros productos. Como resultado, el desarrollo del módulo se vuelve complejo y resulta difícil mantener el módulo y los productos. Aunque Albers et al.20 se centraron en el desarrollo de vehículos, un diseño de servicios basado en módulos también complica el desarrollo. Los módulos están conectados en pie de igualdad y tienen interdependencias. Más importante aún, los módulos, en nuestro caso las funciones de servicio, a veces son creados por varios desarrolladores diferentes. Por lo tanto, es difícil para los desarrolladores observar el alcance de los efectos de los cambios cuando modifican sus módulos. Esto conducirá a dificultades de mantenimiento y modificación de otros servicios y/o módulos. Por lo tanto, toda la red de funciones de servicio desarrollada por diferentes desarrolladores debe ser adaptable para dar cabida a muchos servicios nuevos.

En este documento, asumimos que hay muchas funciones de servicio creadas por desarrolladores de software y que algunas de las funciones de servicio están conectadas a otras funciones a través de interfaces como API. Describimos nuestro modelo de sistema y definimos sus métricas de evaluación en esta sección.

Consideramos una red que consta de funciones de servicio e interfaces que las conectan. La red de funciones de servicio en el momento t está representada por un gráfico dirigido \(G_t(\{F_{pit}, F_{ct}, F_{pot}\}, L_t)\) que consta de un conjunto de periféricos del lado de entrada. funciones \(F_{pit}\), un conjunto de funciones periféricas del lado de salida \(F_{pot}\), un conjunto de funciones centrales \(F_{ct}\) y un conjunto de enlaces \(L_t\ ). Cada nodo de la red representa una función de servicio, que funciona independientemente de otras funciones. Los enlaces \(L_t\) representan el conjunto de enlaces entre las funciones del servicio. Cuando hay una interfaz disponible desde la función de servicio i a la función de servicio j y puedo llamar a j, existe un enlace (i, j). Los proveedores de servicios intentan conectar las funciones de servicio que utilizan en función de sus datos de entrada y los datos de salida que desean adquirir. El gráfico dirigido que conecta esas funciones de servicio desde el lado de entrada al lado de salida es una cadena de servicios. A una cadena de servicios la llamamos \(sc_t\) que utiliza interfaces existentes una cadena de servicios conocida. Por ejemplo, dada una red de función de servicio \(G_t\) en la Fig. 2, la cadena que se muestra en la Fig. 3 es una cadena conocida y un subgrafo de \(G_t\). Una cadena de servicios conocida está representada por un gráfico dirigido \(G'_t(\{F'_{pit}, F'_{pot}, F'_{ct}\}, L'_t)\). \(G'_t\) es un subgrafo de \(G_t\) porque \(F'_{pit}, F'_{pot}, F'_{ct}\) y \(L'_t\) son subconjuntos de \(F_{pit}, F_{pot}, F_{ct}\) y \(L_t\) respectivamente. Aquí, asumimos que las funciones en \(F_{pi}\) no se usan después de las funciones en \(F_{po}\) y las funciones en \(F_{c}\) y \(F_{pi} \) no se utilizan después de las funciones en \(F_{po}\).

Ejemplo de red de funciones de servicio \(G_t\).

Ejemplo de \(G'_t\).

Esta sección describe el alojamiento de las cadenas de servicios. En este artículo, asumimos que se puede acomodar una cadena de servicios cuando hay una combinación de interfaces que permite que las funciones de servicio incluidas en una cadena de servicios se utilicen en el orden dado. Se acomodan todas las cadenas de \(G'_t\) y algunas cadenas de servicios que no son subgrafos de \(G_t\). Por ejemplo, la cadena en la Fig. 4 es desconocida, pero se puede acomodar porque la función de servicio 7 se puede usar entre las funciones 6 y 12. Sin embargo, en este caso, se usan funciones de servicio y comunicaciones que no se requieren originalmente. El eslabón (6, 12) proporciona una cadena más corta y un servicio más eficiente. Llamamos al número mínimo de interfaces necesarias para acomodar una cadena de servicio determinada \(sc_t\) con una longitud de cadena de \(l_{sct}\). No se admiten cadenas de servicio que tengan una combinación de funciones de servicio inalcanzables, como se muestra en la Fig. 5.

Ejemplo de una cadena de servicios que se adapta mediante el uso de otras funciones e interfaces de servicio.

Ejemplo de cadena de servicios que no está acomodada.

Para aumentar la probabilidad de acomodación de la cadena de servicios y proporcionar servicios con longitudes de cadena cortas, se requieren interfaces adicionales entre las funciones de servicio. Con base en la información disponible en el momento t, determinamos las interfaces \(L_{t+1}\) y agregamos un enlace. Definimos el costo de desarrollo C requerido para acomodar una cadena de servicios por el número de eslabones que se agregarán.

Sea \(ac_{sc}=1\) cuando la cadena de servicio sc pueda acomodarse en \(G_t\) y \(ac_{sc}=0\) en caso contrario. Para el conjunto de cadenas de servicios SC que surgen en el momento t, la relación de acomodación AC es

Nuestro objetivo es maximizar \(\alpha AC + \beta C\), que representa la relación de acomodación del servicio para el mismo C cuando se incrementa t. \(\alpha > 0\) y \(\beta < 0\) son parámetros de peso.

Enumeramos nuestros símbolos en la Tabla 1.

Cuando consideramos la realización de una red de funciones de servicio evolutivas, es difícil resolver el problema como un problema de optimización porque es difícil expresar requisitos de servicios futuros desconocidos en forma matemática. Por lo tanto, permitimos que las redes de funciones de servicio evolucionen manteniendo una estructura central/periferia de tamaño y densidad adecuados. Nos referimos a esto como "control de densidad".

Esta sección describe nuestro método para determinar las interfaces \(L_{t+1}\).

En Gu et al.21, para dos bloques dados en el cerebro humano, cuando (fuerza de la conexión dentro del bloque m) > (fuerza de la conexión entre los bloques mandn) > (fuerza de la conexión dentro del bloque n), el bloque m es un bloque central y n es un bloque periférico. Gu et al.21 muestran que en términos de organización de las funciones cerebrales, a medida que el cerebro se desarrolla, los módulos se separan más, aumenta el número de pares centro-periferia y la fuerza de las conexiones dentro de los bloques y la fuerza de las conexiones entre Los bloques están correlacionados negativamente. Es decir, cuanto más separados están, más indican un estado de función bien desarrollada. En la relación de función de servicio, una correlación negativa entre la densidad entre bloques y la densidad dentro de un bloque facilita el desarrollo de la función de cada bloque debido a sus pequeñas dependencias de otros bloques.

Es importante que la densidad entre los bloques esté entre la densidad del bloque central y la densidad de los bloques periféricos. Gu et al.21 explica que, cuando la densidad entre bloques es mayor, no están separados y son una estructura monolítica, y cuando la densidad entre bloques es menor, no existe interrelación entre ellos. Es decir, se requiere que la densidad entre el bloque central y el bloque periférico sea suficientemente menor que la densidad dentro del bloque central para facilitar el desarrollo, pero suficientemente mayor que la densidad dentro de los bloques periféricos para dar cabida a las cadenas de servicios.

Además, este enfoque permite distinguir los bloques centrales de los bloques periféricos y determinar \(L_{t+1}\) únicamente a partir de la información de topología de la red, independientemente del contenido de la función del servicio o la frecuencia de uso. Es concebible determinar la red de funciones de servicio distinguiendo los roles del núcleo y la periferia en función de la frecuencia de uso del servicio y el contenido de la función de servicio, pero es difícil obtener la información para todas las funciones de servicio y predecir información futura.

En una red de funciones de servicio, el papel de la función de servicio puede cambiar para adaptarse a cadenas de servicios desconocidas con el tiempo. Por lo tanto, controlamos la red de funciones de servicio de modo que algunas de las funciones periféricas se consideren nuevamente como funciones centrales manteniendo las desigualdades.

La conexión entre bloques de funciones está representada por una matriz de adyacencia A de bloques myn. \(A_{ij}=1\) cuando las interfaces \(i\in m\) a \(j\in n\) están disponibles, y \(A_{ij}=0\) cuando no lo están. Cuando \(m=n\), es decir, dentro de \(F_{pi}\), \(F_{po}\) y \(F_c\), definimos \(d_m\), la densidad dentro de la función bloque m, como

Definimos \(d_{m, n}\), la densidad entre bloques, como

De ahora en adelante, nos referiremos a la densidad dentro de \(F_{pi}, F_{po} y\ F_{c}\) como \(d_{pi}, d_{po} y\ d_c\), respectivamente, y la densidad entre un bloque central y un bloque periférico como \(d_{c, pi}\ y\ d_{c, po}\), respectivamente.

Ejemplo de funciones de servicio antes de la aplicación del método.

Ejemplo de funciones de servicio después de agregar una función principal.

Ejemplo de funciones de servicio después de agregar enlaces entre funciones periféricas.

Nos centramos en la función de servicio \(fp \in F_{p}\), donde fp está conectado a una o más de las funciones de servicio en \(F_{c}\). Sea \(L_{fp, c}\) el conjunto de enlaces que conectan fp y \(F_{c}\), y \(L_{fp, p}\) el conjunto de enlaces que conectan fp y el bloque donde fp pertenece.

\(G_{t+1}\) está determinado por el Algoritmo 1. En nuestras simulaciones, controlamos la densidad en el siguiente orden, pero podemos obtener los mismos resultados si se cambia el orden. La Figura 6 muestra un ejemplo de la red de funciones de servicio antes de aplicar el método, a medida que las funciones periféricas aumentan en el lado de entrada. En las líneas 1 a 5, controlamos \(d_c\). Seleccionamos dos funciones al azar en \(F_c\) y agregamos enlaces entre ellas. Nuestro método selecciona aleatoriamente qué nodos vincular. Los nodos a los que se agregan enlaces se pueden determinar en función de información como la frecuencia de uso o el grado. Debido a que las cadenas de servicios que surgirán en el futuro son difíciles de predecir, agregar enlaces aleatoriamente conduce a acomodar una variedad de cadenas de servicios. Para hacer que la densidad de los bloques centrales sea suficientemente mayor que la densidad entre bloques, agregamos enlaces hasta que se cumplan las siguientes condiciones: \(d_{c}-d_{c, pi} > th_{c,cp}\), \( d_{c}-d_{c,po} > th_{c,cp}\), y \(d_c \ge dmin_c\). Las funciones centrales requieren una densidad suficientemente mayor que la densidad entre los bloques central y periférico, porque la disponibilidad de un bloque de funciones suficientemente densamente conectado proporciona una longitud de cadena más corta, es decir, un servicio más eficiente. La Figura 7 muestra un ejemplo de la red de funciones de servicio cuando se completa este proceso.

En las líneas 6 a 11, controlamos el tamaño del núcleo. Seleccionamos aleatoriamente \(fp \in F_{p}\) y nodos en \(F_c\) y agregamos enlaces entre ellos para que fp pueda considerarse como \(fp \in F_{c}\). \(F_c\) incluido fp se convierte en el nuevo bloque central. El sistema pasa al siguiente estado cuando se cumple al menos una de las siguientes condiciones: \(coresize \ge coresize_{max}\) o (\(d_{c} - d_{c, cpi} > th_{c,cp} \) y \(d_{c} - d_{c, cpo} > th_{c,cp}\)). Se requiere que el tamaño del núcleo esté dentro de un cierto rango, porque mantener un núcleo grande requiere una gran cantidad de enlaces adicionales, lo que aumenta el costo de desarrollo, y un núcleo demasiado pequeño no puede mantener suficiente capacidad de prestación de servicios (proporción de alojamiento y cadena). longitud).

En las líneas 12 a 21, controlamos \(d_{c, pi}\) y \(d_{c, po}\). Seleccionamos aleatoriamente nodos en \(F_{p}\) y nodos en new \(F_c\) y agregamos los enlaces entre ellos. Para que la densidad entre bloques sea suficientemente mayor que la densidad dentro de los bloques periféricos, agregamos enlaces hasta que se cumplan las siguientes condiciones: \(d_{c, pi}-d_{pi} > th_{cp,p}\), \( d_{c}-d_{c,pi} \le th_{c,cp}\), \(d_{c, po}-d_{po} > th_{cp,p}\), y \(d_{ c}-d_{c,po} \le th_{c,cp}\). Establecemos la segunda y cuarta condiciones para evitar agregar un número ilimitado de enlaces.

En las líneas 22 a 29, controlamos \(d_{pi}\) y \(d_{po}\). Seleccionamos aleatoriamente nodos periféricos en el mismo bloque y agregamos enlaces entre ellos. Para hacer que la densidad dentro de los bloques periféricos sea lo suficientemente grande como para convertirse en bloques funcionales, agregamos enlaces hasta que se cumplan las siguientes condiciones: \(d_{c, pi}-d_{pi} \le th_{cp,p}\), \( d_{pi} \ge dmin_p\), \(d_{c, po}-d_{po} \le th_{cp,p}\) y \(d_{po} \ge dmin_p\). Establecemos la segunda y cuarta condiciones para evitar agregar un número ilimitado de enlaces. La Figura 8 muestra un ejemplo de la red de funciones de servicio cuando se completa este proceso.

Evaluamos la efectividad de nuestro método de control de densidad comparándolo con otros tres métodos. El primero es el método de “adaptación del camino más corto”. Este método agrega enlaces para conectar todos los nodos de cada cadena de servicios de modo que cada cadena de servicios en t sea un subgrafo de \(G_t\). La longitud de la cadena se minimiza para las cadenas de servicios acomodadas, pero el costo de desarrollo es alto porque se deben agregar eslabones para todas las diferentes cadenas de servicios. Por lo tanto, comparamos los índices de alojamiento de servicios cuando se utiliza el mismo costo de desarrollo para el control de la densidad. El segundo método es el “alojamiento de bajo coste”. El control de la densidad requiere un costo de desarrollo para agregar vínculos entre las funciones de servicio, independientemente de si se produce una cadena de servicios porque mantiene el tamaño y la densidad de las funciones centrales y periféricas. El alojamiento de bajo costo permite que las cadenas de servicios ocurran en t con el menor costo de desarrollo posible. Específicamente, calculamos cuánto aumenta la relación de acomodación por cada enlace entre todos los nodos y agregamos el enlace con el valor más grande. Lo repetimos hasta que no queden más enlaces disponibles para aumentar el ratio de alojamiento. El tercer método es “aleatorio”, en el que se seleccionan nodos aleatoriamente y se añaden enlaces entre ellos con el mismo coste de desarrollo que el del control de densidad. Tenga en cuenta que los enlaces que pueden agregar los métodos, excepto la acomodación del camino más corto, son los de \(F_{pi}\) a \(F_c\), \(F_{pi}\) a \(F_{po}\) , o \(F_{c}\) a \(F_{po}\).

Nuestro programa de simulación ejecuta el algoritmo en el siguiente orden en cada paso t. Primero, damos el estado inicial de la red de funciones de servicio en t. La red consta de un bloque central \(F_c\), un bloque periférico del lado de entrada \(F_{pi}\) y un bloque periférico del lado de salida \(F_{po}\). En segundo lugar, ocurre un cambio ambiental en t. Sumamos funciones periféricas con probabilidad p. Específicamente, generamos un número aleatorio r. Cuando \(\frac{2}{p}

Evaluamos los métodos con las siguientes tres métricas.

Primero, calculamos el índice de acomodación de las cadenas de servicios para evaluar la capacidad de nuestro método para acomodar nuevas cadenas de servicios. Supusimos que los métodos de acomodación aleatorios y de ruta más corta pueden utilizar el mismo costo de desarrollo que nuestro método de control de densidad en cada paso.

Creamos 30 cadenas de servicios para cada paso de la siguiente manera. Primero, seleccionamos un nodo de entrada y un nodo de salida al azar. Los nodos en \(F_p\) que son hojas son candidatos para nodos de entrada y salida de cadenas de servicios, respectivamente. En segundo lugar, seleccionamos nodos aleatoriamente para generar la cadena de servicios a partir de todos los nodos distintos de los nodos de entrada y salida. El número de nodos en el paso t es \(N_t\). El número de nodos seleccionados aquí se establece entre 1 y \(\frac{N_i}{3}\). Tenga en cuenta que están conectados en el orden de los nodos en \(F_{pi}\), los nodos en \(F_c\) y los nodos en \(F_{po}\). La cadena que conecta los nodos de entrada, los nodos seleccionados y los nodos de salida es una cadena de servicios. Aquí, 15 de las cadenas de servicios se seleccionan basándose en la clasificación núcleo/periferia en \(t=0\), y las 15 restantes se seleccionan basándose en la clasificación núcleo/periferia cuando se aplica el control de densidad. Esto es para centrarse en nuevas cadenas de servicios que utilizan funciones básicas que anteriormente no se utilizaban como funciones principales.

En segundo lugar, utilizamos el costo de desarrollo. El método de alojamiento de bajo costo intenta acomodar las cadenas de servicios con el menor costo posible, por lo que su costo de desarrollo es menor que el del control de densidad. Para demostrar que nuestro método puede cambiar la estructura de la red de funciones de servicio con un costo de desarrollo suficientemente bajo, evaluamos el costo de desarrollo. Calculamos el costo de desarrollo de cada método para lograr sus objetivos en cada paso para evaluar cuánto más costo de desarrollo requieren los métodos de control de densidad y acomodación del camino más corto en comparación con el método de acomodación de bajo costo para acomodar las mismas cadenas de servicios. Calculamos el costo de desarrollo de acomodar todas las cadenas de servicios generadas en cada t en la distancia más corta con un costo de desarrollo ilimitado disponible para el método de acomodación del camino más corto. Los costos de desarrollo de otros métodos son los mismos que se explican en la sección sobre "Formulación de problemas de redes de funciones de servicios evolutivas".

En tercer lugar, utilizamos la longitud de la cadena. En el método de alojamiento de bajo costo, se espera que la CA sea mayor, pero tiene la desventaja de requerir que se tomen caminos adicionales para acomodar la cadena de servicios. Cadenas más largas significan el uso de funciones de servicio y vías de comunicación que no son necesarias para proporcionar el servicio, lo que conduce a la degradación de la capacidad de respuesta del servicio. Por lo tanto, calculamos la longitud de la cadena \(l_{sc}\) con nuestro método de control de densidad y la longitud con el método de acomodación de bajo costo. Para una cadena de servicios sc que consta de funciones \(N_{sc}\), el valor mínimo es \(N_{sc}-1\) cuando la cadena de servicios dada es un subgrafo de \(G_t\). En esta simulación, calculamos \(\frac{l_{sc}}{N_{sc}-1}\), que representa cuántas veces más larga es la longitud de la cadena \(l_{sc}\) en comparación con \(N_ {sc} -1\), la longitud mínima de la cadena, como indicador de la capacidad de respuesta del servicio.

Usamos la red representada en la Fig. 9 y los parámetros que se muestran en la Tabla 2. Ejecutamos los métodos hasta \(t=40\) y repetimos esto 100 veces.

Red de función de servicio en \(t=0\).

Ejemplo de ratios de alojamiento para todas las cadenas de servicios.

Ratios de alojamiento para todas las cadenas de servicios.

Los resultados de los cálculos del índice de acomodación se muestran en las Figs. 10 y 11. La relación de acomodación para un ejemplo de la evolución de todos los caminos para cada red de funciones de servicio se muestra en la Fig. 10. La Figura 11 muestra la relación de acomodación para 100 ejecuciones de cada método, es decir, la relación de acomodación para las siguientes 100 ejecuciones. caminos evolutivos. Extractamos los pasos 30 y posteriores, cuando el efecto del estado inicial de la red ha disminuido. El eje horizontal representa los pasos evolutivos y el eje vertical representa AC. Tenga en cuenta que los métodos de acomodación aleatoria y de ruta más corta pueden utilizar el mismo costo de desarrollo que nuestro método de control de densidad en cada paso.

A medida que se ejecutan los pasos, la relación de acomodación se acerca a casi 1 cuando se aplica el control de densidad, pero con el método de acomodación de bajo costo disminuye. Esto se debe a que hay menos nodos que están vinculados bidireccionalmente (es decir, menos funciones que se usan mutuamente) y la red no puede acomodar las cadenas de servicios que no utilizan nuevas funciones centrales. En el método de control de densidad, el número de combinaciones de funciones que se pueden usar mutuamente aumenta conectando densamente funciones periféricas como nuevas funciones centrales. Como resultado, ahora es posible dar cabida a cadenas de servicios que utilizan funciones centrales que antes no formaban parte del núcleo.

La relación de acomodación no es estable cuando los nodos de la cadena de servicios que llegan a cada paso están conectados utilizando el mismo costo de desarrollo que nuestro método de control de densidad. A medida que aumenta el tamaño de la red a lo largo de la evolución, aumenta la longitud de las cadenas de servicios. Debido a que el método de acomodación del camino más corto incurre en un mayor costo de desarrollo para dar cabida a cadenas de servicios más largas, la relación de acomodación es menor cuando surgen cadenas de servicios más largas.

Cuando se aplica el método de control de densidad, la relación de acomodación es cercana a 1,0 para casi todos los caminos evolutivos. Cuando se aplican métodos aleatorios y de acomodación por el camino más corto, la variación en las proporciones de acomodación es grande. Cada método tiene el mismo costo para API (enlaces) adicionales entre funciones de servicio para acomodar las cadenas de servicios emergentes. El método de acomodación del camino más corto intenta minimizar la longitud de la cadena en el paso sin considerar el posible uso futuro de las API. Nuestros resultados sobre los índices de acomodación muestran que, en el método de acomodación del camino más corto, pocos eslabones agregados en pasos anteriores se reutilizan al acomodar una nueva cadena de servicios. Random también tiene una gran variación en la proporción de alojamiento de servicios. El control de densidad también utiliza la aleatoriedad en algunos procesos. Sin embargo, el hecho de que la tasa de acomodación no aumenta con el método aleatorio, que agrega enlaces completamente al azar. Este resultado indica que es efectivo mantener la relación entre la escala centro y periferia basada en una estructura centro/periferia.

Ejemplo de costo de desarrollo.

Costo de desarrollo.

Los resultados del cálculo del costo de desarrollo en cada paso se muestran en las Figs. 12 y 13. El eje horizontal representa los pasos evolutivos y el eje vertical representa el costo de desarrollo de cada paso.

El método de control de densidad suma aproximadamente 10 veces más enlaces que el método de alojamiento de bajo coste con nuestra configuración. Sin embargo, el alojamiento de bajo coste calcula los ratios de alojamiento para todos los enlaces posibles. Cuanto más grande es la red de funciones de servicio, más difícil resulta encontrar el enlace óptimo para agregar entre las vastas combinaciones posibles de nodos.

El costo del método de adaptación del camino más corto que se muestra en la Fig. 12 es el costo de desarrollo necesario para dar cabida a todas las cadenas de servicios, incluidas las que no se incluyen, como se muestra en las Figs. 10 y 11. El costo de desarrollo del método de acomodación del camino más corto aumenta significativamente porque los enlaces agregados en t rara vez se reutilizan en el futuro. El costo de desarrollo de alojamiento de bajo costo y alojamiento de ruta más corta depende en gran medida de la configuración de los parámetros, como la longitud y el número de cadenas de servicios que llegan a cada t, y es difícil predecir qué cadenas de servicios ocurrirán en el futuro. Sin embargo, el costo de desarrollo para el control de densidad no depende del contenido de la cadena de servicios porque se basa únicamente en la topología de la red.

Las longitudes de las cadenas con control de densidad y alojamiento de bajo costo se muestran en las Figs. 14 y 15, respectivamente. El método de control de densidad requiere solo 1 o 2 veces la longitud más corta de las cadenas de servicios porque controlamos la densidad entre \(F_c\) y \(F_{p}\). El método de alojamiento de bajo costo requiere entre 3 y 5 veces la longitud más corta de las cadenas de servicios. Agrega vínculos entre funciones periféricas porque determina los vínculos en función de la relación de acomodación. Como resultado, las funciones periféricas se acercan más a estar conectadas en forma de anillo. Si el método de acomodación de bajo costo se modifica para tener una longitud de cadena más corta, realiza el mismo proceso que el método del camino más corto y el costo de desarrollo aumenta como se muestra en las Figs. 12 y 13.

Longitud de cadena (control de densidad).

Longitud de la cadena (alojamiento de bajo coste).

Los resultados de nuestra simulación revelaron que nuestro método propuesto permite que la red de funciones de servicio evolucione para acomodar más cadenas de servicios nuevas. El método de control de densidad logra relaciones de acomodación de la cadena de servicio altas y estables en múltiples rutas de evolución. Además, el costo de desarrollo utilizado para aplicar el control de densidad es independiente del número o longitud de las futuras cadenas de servicios. Esto proporciona una ventaja para cambiar la estructura de la red de funciones de servicio en el futuro durante un largo período de tiempo, porque otros métodos requieren costos de desarrollo adicionales para acomodar nuevos servicios dependiendo del número o la longitud de las cadenas de servicios, y es difícil de predecir. qué cadenas de servicios surgirán en el futuro. Esperamos que esta ventaja se vuelva más significativa a medida que el tamaño de la red de funciones de servicio y las cadenas de servicios crezcan.

Establecimos la frecuencia de desarrollo de nuevas funciones periféricas en aproximadamente un mes por paso. Es decir, los resultados de nuestra simulación muestran la relación de alojamiento del servicio y el costo de desarrollo durante aproximadamente 40 meses. Aplicar nuestro método a la red de funciones de servicio permite que la red evolucione a un menor costo, lo que facilita el desarrollo de servicios más rápidamente. Luego, como cada paso evolutivo es más corto, se pueden dar muchos pasos en los mismos 40 meses, como en nuestra simulación. A medida que se toman más medidas, aumenta la diferencia con el alojamiento de bajo costo en términos de proporción de alojamiento con servicios, y aumenta la diferencia con el alojamiento de ruta más corta en términos de costo de desarrollo. Por tanto, la ventaja de nuestro método es mayor.

La complejidad temporal de nuestro método propuesto es \(O(N_t)\), donde \(N_t\) es el número de nodos en el tiempo t, porque todos los bucles utilizados en el control de densidad son de un solo bucle. Los del método de comparación de acomodación del camino más corto son \(O(N_{sc})\) donde \(N_{sc}\) es el número de nodos de las cadenas de servicios. La complejidad del alojamiento de bajo coste es \(O(N^2)\) porque verifica todos los vínculos posibles. La complejidad espacial de nuestro método propuesto es \(O(N_t)\), porque solo requiere las funciones de servicio redes para la entrada y un número constante de variables para almacenar los nodos para agregar enlaces. Los de los métodos comparables son \(O(N_t)\) también. Por lo tanto, la complejidad tiempo/espacio de nuestro método propuesto no es tan alta como la de otros métodos.

Para dar cabida a una gran cantidad de servicios a bajo costo, el diseño del servicio debe ser adaptable a los requisitos del usuario y a los cambios ambientales. Nuestros trabajos anteriores han demostrado que los servicios orientados a la red diseñados en base a una estructura núcleo/periferia pueden adaptarse a los cambios ambientales con un bajo coste de desarrollo mediante la implementación de un servicio específico orientado a la red. Sin embargo, en la práctica, los proveedores de servicios combinan varias funciones de servicio desarrolladas por varios desarrolladores a través de interfaces como API y brindan el servicio a los usuarios. Por tanto, toda la red de funciones de servicios debe adaptarse a cambios ambientales difíciles de predecir. En este artículo, propusimos un método para hacer evolucionar toda la red de funciones de servicio. Nuestro método hace evolucionar la red de funciones de servicio con un bajo costo de desarrollo manteniendo las funciones centrales y periféricas en la escala adecuada. Evaluamos nuestro método en términos del índice de acomodación del servicio y la longitud de la cadena de servicio para mostrar que las redes de funciones de servicio mantienen una alta capacidad de prestación de servicios al aplicar nuestro método. Además, evaluamos el costo de desarrollo requerido para desarrollar la red de funciones de servicio. Los resultados de nuestra simulación revelaron que nuestro método propuesto permite que la red de funciones de servicio continúe evolucionando y acomode más cadenas de servicios nuevas con longitudes de cadena más cortas. El trabajo futuro incluye abordar el problema de dónde colocar las funciones de servicio y proporcionar un método para adaptar la red de funciones de servicio a la indisponibilidad de algunas funciones de servicio.

Los datos de este estudio están disponibles del autor correspondiente previa solicitud razonable.

Tachi, S. Telexistence: Permitir que los humanos sean prácticamente ubicuos. Computación IEEE. Grafico. Aplica. 36, 8-14 (2016).

Artículo PubMed Google Scholar

Hu, YC, Patel, M., Sabella, D., Sprecher, N. & Young, V. La computación de borde móvil, una tecnología clave hacia 5G (2015).

Taleb, T. y col. Sobre informática de borde de acceso múltiple: un estudio de la arquitectura y orquestación de la nube de borde de la red 5G emergente. Comunicaciones IEEE. Sobrevivir. Tutor. 19, 1657–1681 (2017).

Artículo de Google Scholar

Baktir, AC, Ozgovde, A. y Ersoy, C. ¿Cómo puede la informática de punta beneficiarse de las redes definidas por software: una encuesta, casos de uso y direcciones futuras? Comunicaciones IEEE. Sobrevivir. Tutor. 19, 2359–2391 (2017).

Artículo de Google Scholar

Xavier, L., Brito, A., Hora, A. & Valente, MT Análisis histórico y de impacto de los cambios importantes de API: un estudio a gran escala. En actas de la 24.ª Conferencia internacional del IEEE de 2017 sobre análisis, evolución y reingeniería de software (SANER), 138–147 (2017).

MacCormack, A. & Sturtevant, DJ Deuda técnica y arquitectura del sistema: el impacto del acoplamiento en la actividad relacionada con defectos. J. Sistema. Software. 120, 170–182 (2016).

Artículo de Google Scholar

Adam, S. y Halina, K. Algoritmos evolutivos y sus aplicaciones a problemas de ingeniería. Computación neuronal. Aplica. 20, 12363–12379 (2020).

Google Académico

Kashtan, N. & Alon, U. Evolución espontánea de la modularidad y motivos de red. Proc. Nacional. Acad. Ciencia. Estados Unidos 102, 13773–8 (2005).

Artículo ADS CAS PubMed PubMed Central Google Scholar

Csermely, P., Londres, A., Wu, L.-Y. & Uzzi, B. Estructura y dinámica de redes centro-periferia. J. Red compleja. 1, 93-123 (2013).

Artículo de Google Scholar

Miele, V., Ramos-Jiliberto, R. & Véizquez, DP Dinámica centro-periferia en una red planta-polinizador. J.Anim. Ecológico. 89, 1670–1677. https://doi.org/10.1111/1365-2656.13217 (2020).

Artículo PubMed Google Scholar

Tsukui, Y., Arakawa, S., Takagi, S. y Murata, M. Diseño y ubicación de funciones de red virtualizadas para solicitudes de servicio que cambian dinámicamente basadas en una estructura central/periférica. Acceso IEEE 8, 166294–166303 (2020).

Artículo de Google Scholar

Takagi, S., Arakawa, S. & Murata, M. Diseño, implementación y evaluación de servicios de realidad mixta orientados a redes basados ​​en núcleo/periferia. J. Servicio de Internet. Aplica. 12, 1-10 (2022).

Artículo de Google Scholar

Takagi, S., Arakawa, S. & Murata, M. Diseño, implementación y evaluación de un servicio orientado a red con adaptabilidad ambiental basado en una estructura núcleo/periferia (Presentado para publicación) (2022).

Takagi, S., Arakawa, S. y Murata, M. Sobre la implementación y evaluación de un servicio de realidad mixta orientado a red basado en una estructura central/periférica. Informe técnico de IEICE (NS2019-218) 221–226 (2020).

Liu, J., Lu, W., Zhou, F., Lu, P. y Zhu, Z. Sobre el despliegue y reajuste de la cadena de funciones de servicios dinámicos. Traducción IEEE. Neto. Serv. Administrar. 14, 543–553 (2017).

Artículo de Google Scholar

Moens, H. & De Turck, F. Cadenas de funciones personalizables: gestión de la variabilidad de la cadena de servicios en redes híbridas NFV. Traducción IEEE. Neto. Serv. Administrar. 13, 711–724 (2016).

Artículo de Google Scholar

Bian, S., Huang, X., Shao, Z., Gao, X. y Yang, Y. Composición de la cadena de servicios con fallas de recursos en sistemas NFV: una perspectiva de la teoría de juegos. Traducción IEEE. Neto. Serv. Administrar. 18, 224–239 (2021).

Artículo de Google Scholar

Cai, J., Qian, K., Luo, J. & Zhu, K. Sarm: Mecanismo de reconfiguración activa de la cadena de funciones de servicio basado en la predicción de carga y demanda. En t. J. Intel. Sistema. 37, 6388–6414. https://doi.org/10.1002/int.22848 (2022).

Artículo de Google Scholar

Baldwin, CY & Clark, KB Gestión en una era de modularidad. Harv. Autobús. Rev. 75, 84–93 (1997).

CAS PubMed Google Académico

Albers, A. y col. Ingeniería de sistemas basada en modelos en diseño modular. Des. Ciencia. 5, 1–33 (2019).

Artículo de Google Scholar

Gu, S. y col. Unificando las nociones de modularidad y estructura centro-periferia en las redes cerebrales funcionales durante la juventud. Cerebro. Corteza 30, 1087-1102 (2019).

Artículo PubMed Central Google Scholar

Descargar referencias

Este trabajo fue financiado en parte por el Instituto Nacional de Tecnología de la Información y las Comunicaciones de Japón.

Escuela de Graduados en Ciencia y Tecnología de la Información, Universidad de Osaka, 1-5 Yamadaoka, Suita, Osaka, Japón

Shiori Takagi, Shin'ichi Arakawa y Masayuki Murata

También puedes buscar este autor en PubMed Google Scholar.

También puedes buscar este autor en PubMed Google Scholar.

También puedes buscar este autor en PubMed Google Scholar.

MM contribuyó a la concepción de este estudio. ST y SA propusieron el método. ST realizó la evaluación y escribió el manuscrito. Todos los autores han leido y aprobado el manuscrito.

Correspondencia a Shiori Takagi.

Los autores declaran no tener conflictos de intereses.

Springer Nature se mantiene neutral con respecto a reclamos jurisdiccionales en mapas publicados y afiliaciones institucionales.

Acceso Abierto Este artículo está bajo una Licencia Internacional Creative Commons Attribution 4.0, que permite el uso, compartir, adaptación, distribución y reproducción en cualquier medio o formato, siempre y cuando se dé el crédito apropiado al autor(es) original(es) y a la fuente. proporcione un enlace a la licencia Creative Commons e indique si se realizaron cambios. Las imágenes u otro material de terceros en este artículo están incluidos en la licencia Creative Commons del artículo, a menos que se indique lo contrario en una línea de crédito al material. Si el material no está incluido en la licencia Creative Commons del artículo y su uso previsto no está permitido por la normativa legal o excede el uso permitido, deberá obtener permiso directamente del titular de los derechos de autor. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by/4.0/.

Reimpresiones y permisos

Takagi, S., Arakawa, S. & Murata, M. Diseño evolutivo de servicios orientados a la red basados ​​en una estructura núcleo/periferia. Representante científico 13, 11644 (2023). https://doi.org/10.1038/s41598-023-38695-5

Descargar cita

Recibido: 06 de enero de 2023

Aceptado: 12 de julio de 2023

Publicado: 19 de julio de 2023

DOI: https://doi.org/10.1038/s41598-023-38695-5

Cualquier persona con la que compartas el siguiente enlace podrá leer este contenido:

Lo sentimos, actualmente no hay un enlace para compartir disponible para este artículo.

Proporcionado por la iniciativa de intercambio de contenidos Springer Nature SharedIt

Al enviar un comentario, acepta cumplir con nuestros Términos y pautas de la comunidad. Si encuentra algo abusivo o que no cumple con nuestros términos o pautas, márquelo como inapropiado.