ES3044783T3

ES3044783T3 - Platform independent application programming interface configuration

Info

Publication number: ES3044783T3
Application number: ES21713603T
Authority: ES
Inventors: Emmanouil Pateromichelakis; Ishan Vaishnavi; Ravi Kuchibotla
Original assignee: Lenovo Singapore Pte Ltd
Current assignee: Lenovo Singapore Pte Ltd
Priority date: 2021-03-16
Filing date: 2021-03-16
Publication date: 2025-11-27
Anticipated expiration: 2041-03-16
Also published as: EP4309311A1; BR112023018957A2; PL4309311T3; AU2021434516A1; KR20230156833A; US20240193021A1; CA3208903A1; EP4309311C0; EP4309311B1; CN116998141A; WO2022194359A1

Abstract

Se describen aparatos, métodos y sistemas para configurar interfaces de programación de aplicaciones (API) independientes de la plataforma. Un aparato (700) incluye un transceptor (725) que recibe (805) un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica. El sistema de comunicación inalámbrica incluye una o más plataformas. El aparato (700) incluye un procesador (705) que determina (810) una interfaz de programación de aplicaciones (API) independiente de la plataforma basándose en el parámetro de servicio para al menos un servicio de red del sistema de comunicación inalámbrica. (Traducción automática con Google Translate, sin valor legal)

Description

[0001] DESCRIPCIÓN

[0002] Configuración de la interfaz de programación de aplicaciones independientes de la plataforma

[0003] CAMPO

[0004] La materia patentable divulgada en el presente documento se refiere en general a las comunicaciones inalámbricas y, más concretamente, a la configuración de interfaces de programación de aplicaciones independientes de la plataforma.

[0005] ANTECEDENTES

[0006] Es posible que las interfaces de programación de aplicaciones ("API") de una red de comunicaciones inalámbricas, como las API de servicios que se exponen a los desarrolladores de aplicaciones verticales y segmentadas, no sean transferibles entre implementaciones de distintos proveedores y tecnologías.

[0007] BREVE SUMARIO

[0008] De acuerdo con los aspectos de la presente divulgación, se proporciona un aparato de acuerdo con la reivindicación 1 y un método de acuerdo con la reivindicación 15.

[0009] Se divulgan procedimientos para configurar interfaces de programación de aplicaciones independientes de la plataforma. Un primer método de una entidad de aplicación de confianza (por ejemplo, soporte intermedio) para configurar interfaces de programación de aplicaciones independientes de la plataforma incluye recibir un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica. El sistema de comunicación inalámbrica comprende una o varias plataformas. El primer método, en algunas realizaciones, incluye la determinación de una interfaz de programación de aplicaciones ("API") independiente de la plataforma basada en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica.

[0010] Un primer aparato (por ejemplo, un servidor de aplicaciones de confianza, un soporte intermedio o similar) para configurar interfaces de programación de aplicaciones independientes de la plataforma incluye un transceptor que recibe un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica. El sistema de comunicación inalámbrica puede incluir una o más plataformas. En una realización adicional, el primer aparato incluye un procesador que determina una interfaz de programación de aplicaciones ("API") independiente de la plataforma basándose en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica. BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0011] Se realizará una descripción más particular de las realizaciones brevemente descritas anteriormente mediante referencia a realizaciones específicas que se ilustran en los dibujos adjuntos. Entendiendo que estos dibujos representan sólo algunas realizaciones y que, por tanto, no deben considerarse limitativas de su ámbito, las realizaciones se describirán y explicarán con mayor especificidad y detalle a través de los dibujos adjuntos, en los que:

[0012] La figura 1 es un diagrama esquemático de bloques que ilustra una realización de un sistema de comunicación inalámbrica para configurar interfaces de programación de aplicaciones independientes de la plataforma;

[0013] La figura 2 es un diagrama que ilustra una realización de un procedimiento para una arquitectura de red y un flujo de señalización para configurar interfaces de programación de aplicaciones independientes de la plataforma; La figura 3 es un diagrama que ilustra el flujo de señalización de una realización de un procedimiento para configurar interfaces de programación de aplicaciones independientes de la plataforma para los segmentos de red;

[0014] La figura 4 es un diagrama que ilustra el flujo de señalización para una realización de un procedimiento para configurar interfaces de programación de aplicaciones independientes de la plataforma para la portabilidad; La figura 5 es un diagrama que ilustra el flujo de señalización de una realización de un procedimiento para configurar interfaces de programación de aplicaciones independientes de la plataforma para O-RAN;

[0015] La figura 6 es un diagrama que ilustra una realización de un aparato de equipo de usuario que puede utilizarse para configurar interfaces de programación de aplicaciones independientes de la plataforma;

[0016] La figura 7 es un diagrama que ilustra una realización de un aparato de equipamiento de red que puede utilizarse para configurar interfaces de programación de aplicaciones independientes de la plataforma; y

[0017] La figura 8 es un diagrama de flujo que ilustra una realización de un método que puede utilizarse para configurar interfaces de programación de aplicaciones independientes de la plataforma.

[0018] DESCRIPCIÓN DETALLADA

[0019] [0007] Como podrá apreciar un experto en la técnica, algunos aspectos de las realizaciones pueden plasmarse en forma de sistema, aparato, método o producto de programa. En consecuencia, las formas de realización pueden adoptar la forma de una forma de realización totalmente de hardware, una forma de realización totalmente de software (incluido firmware, software residente, microcódigo, etc.) o una forma de realización que combine aspectos de software y hardware.

[0021] Por ejemplo, las realizaciones divulgadas pueden implementarse como un circuito de hardware que comprenda circuitos personalizados de integración a muy gran escala ("VLSI") o matrices de puertas, semiconductores comerciales como chips lógicos, transistores u otros componentes discretos. Las realizaciones divulgadas también pueden implementarse en dispositivos de hardware programables, como matrices de puertas programables en campo, matrices lógicas programables, dispositivos lógicos programables o similares. Como otro ejemplo, las realizaciones divulgadas pueden incluir uno o más bloques físicos o lógicos de código ejecutable que pueden, por ejemplo, estar organizados como un objeto, procedimiento o función.

[0023] Además, las realizaciones pueden tomar la forma de un producto de programa incorporado en uno o más dispositivos de almacenamiento legibles por ordenador que almacenen código legible por máquina, código legible por ordenador y/o código de programa, denominado en lo sucesivo código. Los dispositivos de almacenamiento pueden ser tangibles, no transitorios y/o de no transmisión. Los dispositivos de almacenamiento pueden no incorporar señales. En una determinada realización, los dispositivos de almacenamiento sólo emplean señales para acceder al código.

[0025] Puede utilizarse cualquier combinación de uno o más medios legibles por ordenador. El medio legible por ordenador puede ser un medio de almacenamiento legible por ordenador. El medio de almacenamiento legible por ordenador puede ser un dispositivo de almacenamiento que almacena el código. El dispositivo de almacenamiento puede ser, por ejemplo, pero no exclusivamente, un sistema, aparato o dispositivo electrónico, magnético, óptico, electromagnético, infrarrojo, holográfico, micromecánico o semiconductor, o cualquier combinación adecuada de los anteriores.

[0027] Entre los ejemplos más específicos (una lista no exhaustiva) del dispositivo de almacenamiento se incluirían los siguientes: una conexión eléctrica con uno o más cables, un disquete de ordenador portátil, un disco duro, una memoria de acceso aleatorio ("RAM"), una memoria de sólo lectura ("ROM"), una memoria de sólo lectura programable borrable ("EPROM" o memoria Flash), una memoria de sólo lectura de disco compacto portátil ("CD-ROM"), un dispositivo de almacenamiento óptico, un dispositivo de almacenamiento magnético o cualquier combinación adecuada de los anteriores. En el contexto de este documento, un medio de almacenamiento legible por ordenador puede ser cualquier medio tangible que pueda contener o almacenar un programa para su uso por o en conexión con un sistema de ejecución de instrucciones, aparato o dispositivo.

[0029] El código para llevar a cabo las operaciones de las realizaciones puede tener cualquier número de líneas y puede estar escrito en cualquier combinación de uno o más lenguajes de programación, incluyendo un lenguaje de programación orientado a objetos como Python, Ruby, Java, Smalltalk, C++, o similares, y lenguajes de programación procedimentales convencionales, como el lenguaje de programación "C", o similares, y/o lenguajes de máquina como los lenguajes de ensamblaje. El código puede ejecutarse íntegramente en el ordenador del usuario, parcialmente en el ordenador del usuario, como un paquete de software independiente, parcialmente en el ordenador del usuario y parcialmente en un ordenador remoto o íntegramente en el ordenador o servidor remoto. En este último caso, el ordenador remoto puede estar conectado al ordenador del usuario a través de cualquier tipo de red, incluida una red de área local ("LAN") o una red de área extensa ("WAN"), o la conexión puede hacerse a un ordenador externo (por ejemplo, a través de Internet utilizando un proveedor de servicios de Internet).

[0031] La referencia a lo largo de esta especificación a "una realización" o lenguaje similar significa que un rasgo, estructura o característica particular descrita en relación con la realización está incluida en al menos una realización. Por lo tanto, las expresiones "en una realización" y expresiones similares a lo largo de esta especificación pueden, pero no necesariamente, referirse a la misma realización, pero significan "una o más, pero no todas las realizaciones", a menos que se especifique expresamente lo contrario. Los términos "comprendiendo", "incluyendo", "teniendo" y sus variantes significan "incluyendo pero sin limitarse a", a menos que se especifique expresamente lo contrario. Una enumeración de elementos no implica que alguno o todos los elementos sean mutuamente excluyentes, salvo que se especifique expresamente lo contrario. Los términos "un", "una" y "el/la" también se refieren a "uno o más", a menos que se especifique expresamente lo contrario.

[0033] Como se utiliza aquí, una lista con una conjunción de "y/o" incluye cualquier elemento de la lista o una combinación de elementos de la lista. Por ejemplo, una lista de A, B y/o C incluye sólo A, sólo B, sólo C, una combinación de A y B, una combinación de B y C, una combinación de A y C o una combinación de A, B y C. Tal como se utiliza en el presente documento, una lista que utilice la terminología "uno o más de" incluye cualquier elemento individual de la lista o una combinación de elementos de la lista. Por ejemplo, uno o más de A, B y C incluye sólo A, sólo B, sólo C, una combinación de A y B, una combinación de B y C, una combinación de A y C o una combinación de A, B y C. Tal y como se utiliza en el presente documento, una lista que utilice la terminología "uno de" incluye uno y sólo uno de cualquier elemento de la lista. Por ejemplo, "uno de A, B y C" incluye sólo A, sólo B o sólo C y excluye combinaciones de A, B y C. Como se usa en el presente documento, "un miembro seleccionado del grupo que consiste en A, B y C", incluye uno y sólo uno de A, B o C y excluye combinaciones de A, B y C". Tal como se utiliza en el presente documento, "un miembro seleccionado del grupo formado por A, B y C y sus combinaciones" incluye sólo A, sólo B, sólo C, una combinación de A y B, una combinación de B y C, una combinación de A y C o una combinación de A, B y C.

[0034] Además, los rasgos, estructuras o características descritos de las realizaciones pueden combinarse de cualquier manera adecuada. En la siguiente descripción, se proporcionan numerosos detalles específicos, como ejemplos de programación, módulos de software, selecciones de usuario, transacciones de red, consultas de bases de datos, estructuras de bases de datos, módulos de hardware, circuitos de hardware, chips de hardware, etc., para proporcionar una comprensión completa de las realizaciones. No obstante, los expertos en la técnica reconocerán que las realizaciones pueden llevarse a la práctica sin uno o varios de los detalles específicos, o con otros métodos, componentes, materiales, etc. En otros casos, no se muestran o describen en detalle estructuras, materiales u operaciones bien conocidas para evitar oscurecer aspectos de una realización.

[0036] A continuación se describen aspectos de las realizaciones con referencia a diagramas de flujo esquemáticos y/o diagramas de bloques esquemáticos de métodos, aparatos, sistemas y productos de programa según las realizaciones. Se entenderá que cada bloque de los diagramas esquemáticos de flujo y/o diagramas esquemáticos de bloques, y combinaciones de bloques en los diagramas esquemáticos de flujo y/o diagramas esquemáticos de bloques, puede implementarse mediante código. Este código puede proporcionarse a un procesador de un ordenador de propósito general, un ordenador de propósito especial u otro aparato programable de procesamiento de datos para producir una máquina, de forma que las instrucciones, que se ejecutan a través del procesador del ordenador u otro aparato programable de procesamiento de datos, creen medios para implementar las funciones/actos especificados en los diagramas de flujo y/o diagramas de bloques.

[0038] El código también puede almacenarse en un dispositivo de almacenamiento que puede dirigir un ordenador, otro aparato programable de procesamiento de datos u otros dispositivos para que funcionen de una manera determinada, de forma que las instrucciones almacenadas en el dispositivo de almacenamiento produzcan un artículo de fabricación que incluya instrucciones que implementen la función/acto especificado en los diagramas de flujo y/o diagramas de bloques.

[0040] El código también puede cargarse en un ordenador, en otro aparato programable de procesamiento de datos o en otros dispositivos para hacer que se ejecuten una serie de etapas operativas en el ordenador, en otro aparato programable o en otros dispositivos para producir un proceso implementado por ordenador de tal manera que el código que se ejecuta en el ordenador o en otro aparato programable proporcione procesos para implementar las funciones/actos especificados en los diagramas de flujo y/o en los diagramas de bloques.

[0042] Los diagramas de flujo y/o diagramas de bloques de las figuras ilustran la arquitectura, funcionalidad y operación de posibles implementaciones de aparatos, sistemas, métodos y productos de programa de acuerdo con diversas realizaciones. En este sentido, cada bloque en los diagramas de flujo y/o diagramas de bloques puede representar un módulo, segmento o porción de código, que incluye una o más instrucciones ejecutables del código para implementar la(s) función(es) lógica(s) especificada(s).

[0044] Se debe tener en cuenta también que, en algunas implementaciones alternativas, las funciones implementadas en el bloque pueden aparecer fuera del orden indicado en las figuras. Por ejemplo, dos bloques mostrados en sucesión pueden, de hecho, ejecutarse sustancialmente de forma concurrente, o los bloques pueden a veces ejecutarse en orden inverso, dependiendo de la funcionalidad implicada.

[0046] Aunque pueden emplearse diversos tipos de flechas y líneas en los diagramas de flujo y/o de bloques, se entiende que no limitan el ámbito de las realizaciones correspondientes. De hecho, algunas flechas u otros conectores pueden utilizarse para indicar únicamente el flujo lógico de la realización representada. Por ejemplo, una flecha puede indicar un período de espera o supervisión de duración indeterminada entre las etapas enumeradas de la realización representada. También se observará que cada bloque de los diagramas de bloques y/o diagramas de flujo, y combinaciones de bloques en los diagramas de bloques y/o diagramas de flujo, pueden implementarse mediante sistemas basados en hardware para fines especiales que realicen las funciones o actos especificados, o combinaciones de hardware para fines especiales y código.

[0048] La descripción de los elementos de cada figura puede referirse a elementos de las figuras siguientes. Los números semejantes se refieren a elementos semejantes en todas las figuras, incluidas las variantes de realización de elementos semejantes.

[0050] En general, la presente divulgación describe sistemas, métodos y aparatos para configurar interfaces de programación de aplicaciones independientes de la plataforma. Se divulga aquí la configuración y el aprovisionamiento de la asignación de un nuevo tipo de interfaz de programación de aplicaciones ("API") (por ejemplo, una API independiente de la plataforma, una API de segmento de red y/o una API de portabilidad, descritas a continuación) a las implementaciones dependientes de la plataforma de las API de plano de gestión o control.

[0052] [0024] Como antecedente, en 3GPP SA6 se ha especificado una capa de soporte de aplicaciones para aplicaciones verticales, conocida como capa de habilitación de aplicaciones verticales (servidor de habilitación v 2x en Ts 23.286, servidor de habilitación FF en TR 23.745, servidor de habilitación UAS en TR 23.755) que actúa como soporte intermedio para exponer las API en dirección norte a verticales, así como para proporcionar algunas funcionalidades de soporte servidor-cliente para los dispositivos conectados. Asimismo, 3GPP SA6 ha proporcionado una capa habilitadora común para todas las verticales conocida como SEAL (TS 23.434).

[0054] Asimismo, en 3GPP SA6 se ha definido una capa de arquitectura de habilitación de servicios ("SEAL") como plataforma de servicios comunes para proporcionar funcionalidades de soporte (por ejemplo, gestión de recursos de red, gestión de la localización, gestión de la configuración, gestión de grupos y/o similares) para todas las verticales. La SEAL (TS 23.434) ha introducido un nuevo servicio, Habilitador de Segmento de Red, que tiene un servidor y una aplicación cliente homólogos. La capa NSE proporciona una capacidad de adaptación/migración del segmento de red para todos los dispositivos que ejecutan una aplicación, lo que requiere una interacción entre el servidor OAM y el servidor NSE, así como entre el servidor NSE y el cliente NSE en el lado del dispositivo (para aplicar la adaptación del segmento).

[0056] Además, 3GPP SA6 está especificando un Marco Común de API ("CAPIF") fue desarrollado para permitir un marco unificado de API en dirección norte a través de las funciones de red 3GPP, y para asegurar que hay un enfoque único y armonizado para el desarrollo de API (TS 23.222). Algunas funcionalidades clave de CAPIF son:

[0058] - Función Núcleo CAPIF ("CCF") es un repositorio de todas las API de servicios, PLMN y de terceros;

[0059] - Función de Exposición API ("AEF") es la proveedora de los servicios como API;

[0060] - Invocador API es típicamente las aplicaciones que requieren el servicio de los proveedores de servicios;

[0062] Además, tal como se utiliza en el presente documento, O-RAN es una alianza que investiga la virtualización del dominio de acceso y considera la virtualización de las funcionalidades de control ("R<r>C"/"RRM") a un Controlador Inteligente RAN ("RIC") de nueva definición que puede co-localizarse con el gNB o puede desplegarse para un clúster de gNB. En este contexto, teniendo en cuenta el despliegue y los requisitos funcionales (tiempo real, tiempo no real, casi tiempo real), así como las políticas de aislamiento de segmentos, las funcionalidades RRM/RRC pueden localizarse / situarse de forma flexible en la CU/DU o en controladores RIC dedicados, por ejemplo, RIC RT Cercano y RIC no RT.

[0064] A continuación figuran algunos términos y definiciones utilizados en el presente documento:

[0066] - RIC no RT: función lógica que permite el control y la optimización en tiempo no real de los elementos y recursos de la RAN, el flujo de trabajo de inteligencia artificial/aprendizaje automático, incluida la formación y actualización de modelos, y la orientación basada en políticas de aplicaciones/funciones en RIC RT Cercano.

[0067] - RIC y funciones marco de la RAN cercana: función lógica que permite el control y la optimización en tiempo casi real de los elementos y recursos de la RAN mediante la recopilación de datos y acciones detalladas (por ejemplo, en función del equipo de usuario o de la célula) a través de la interfaz E2. RIC RT Cercano comprende funciones básicas/de marco de RIC RT Cercano que pueden ser, por ejemplo, gestión de suscripciones, mitigación de conflictos, terminación E2 ("E2T"), servicios de gestión, etc.

[0068] - Servicios de Gestión ("MnS"): Los servicios de gestión de la plataforma RIC incluyen la gestión del ciclo de vida ("LCM") de xApp y la gestión FCAPS de RIC RT Cercano. Estos servicios pueden ser proporcionados por el RIC RT Cercano a la xApp (a través de la API abierta) o por el SMO (RIC no RT) a las xApp (a través de 01).

[0069] - xApp: Una aplicación diseñada para ejecutarse en el RIC RT Cercano. Es probable que una aplicación de este tipo conste de uno o varios microservicios y que, en el momento de su incorporación, identifique qué datos consume y qué datos proporciona. La aplicación es independiente del CIR RT Cercano y puede ser proporcionada por cualquier tercero. El E2 permite una asociación directa entre la xApp y la funcionalidad RAN.

[0070] - E2: Interfaz que conecta el RIC RT Cercano y una o más O-CU-CP, una o más O-CU-UP, y una o más O-DU.

[0071] - Nodo E2: nodo lógico que termina la interfaz E2.

[0072] - E2SM: Descripción de los servicios expuestos por una función RAN específica dentro de un nodo E2 a través de la interfaz E2 hacia el RIC RT Cercano.

[0073] - E2AP: El Protocolo de Aplicación E2 ("E2AP") soporta las funciones de la interfaz E2 mediante los procedimientos de señalización definidos en el presente documento.

[0074] - API abierta/O-RAN APE La API abierta está en proceso de definición en RIC RT Cercano y es la interfaz entre las funciones del marco y las xAPP.

[0075] - Habilitación de API: Los servicios de habilitación de API permiten a la plataforma RIC proporcionar soporte para las API de O-RAN (las API de O-RAN pueden definirse como las API abiertas dentro del ámbito de O-RAN), que pueden ser proporcionadas por el marco RIC o la(s) xApp(s) de una manera basada en servicios. En concreto, los servicios de habilitación de API incluyen: Servicios de repositorio/registro para las API O-RAN, Servicios que permiten descubrir las API O-RAN registradas, Servicios para autenticar las xApp para el uso de las API O-RAN, Servicios que permiten la suscripción genérica y la notificación de eventos. La(s) xApp(s) puede(n) acceder a los servicios de habilitación de la API a través de una API de "habilitación" de la xApp, para soportar el descubrimiento de la API, proporcionando autenticación y suscripción genérica y notificación de eventos.

[0077] [0029] Las API de servicios expuestas a los desarrolladores de aplicaciones verticales y segmentadas deben ser portables entre implementaciones de proveedores y tecnologías. Esto puede lograrse mediante una API uniforme y estandarizada a la que puedan adaptarse las implementaciones de todos los proveedores o tecnologías. Este asignación de una API portátil dependiente del proveedor a una independiente del proveedor tendría que configurarse en función de varios factores, principalmente, la autorización para utilizar la interfaz dependiente del proveedor del vertical concreto. El problema de alto nivel que debe resolver esta divulgación es cómo configurar las API de servicio para que sean consumidas por los clientes verticales/segmentos.

[0079] Las nuevas API independientes de la plataforma simplifican las interacciones dinámicas entre las aplicaciones del cliente vertical y la infraestructura subyacente de telecomunicaciones ("telco") (por ejemplo, los dominios de control y gestión). Esto permite interacciones uniformes entre el cliente y la infraestructura de telecomunicaciones en todos los dominios tecnológicos y de proveedores, y facilita la portabilidad de las aplicaciones a través de redes de múltiples proveedores, múltiples instancias de las redes de telecomunicaciones y a través de diferentes plataformas tecnológicas (por ejemplo, si la aplicación #A se mueve de la EDN #1 que se conecta a la Red A, a la EDN#2 que se conecta a la Red B, con esta solución el soporte intermedio maneja todos los aspectos de la reubicación, y el impacto en la API de Servicio será mínimo).

[0081] Tal como se utiliza en el presente documento, un sistema de comunicación inalámbrica incluye una o más unidades de red y unidades remotas y una o más plataformas. Una unidad de red puede ser un elemento de red, una red de acceso radioeléctrico, una red central, una función de control de red, una función de plano de usuario, una función de gestión de red, una función de computación perimetral móvil, una función de habilitación de aplicaciones o una combinación de estas. En algunas realizaciones, las unidades de red (o cualquier abstracción de estas) pueden virtualizarse en una o más plataformas en la nube. Una plataforma en nube puede ser una plataforma en nube periférica, regional o central.

[0083] Como ejemplo de caso de uso que implica configuraciones de API entre proveedores/sistemas de múltiples proveedores, considerando el hecho de que el sistema 5G ("5GS") puede ser de múltiples proveedores (con múltiples planos de control y gestión que pueden virtualizarse en diferentes plataformas en la nube), y las API serán ofrecidas por diferentes puntos de terminación 5GS, es de vital importancia simplificar el suministro de API al cliente vertical proporcionando API de manera estándar. Por ejemplo, un cliente vertical puede utilizar simultáneamente servicios prestados por una empresa de telecomunicaciones (por ejemplo, servicios de plano de control y de plano de gestión) ofrecidos por varias redes o servicios proporcionados por sistemas de distintos proveedores dentro de la misma red de operador (por ejemplo, sistema de gestión E2E del proveedor A, sistema de gestión de la red de acceso radioeléctrico ("RAN") del proveedor B, red central CP del proveedor C, red central UP del proveedor D). Cuando el cliente vertical interactúa con dicho sistema multiproveedor a través de API, esto puede requerir que las aplicaciones de los clientes verticales conozcan la oferta de API y la información de los dominios de red. Esto puede añadir complejidad. Para simplificar la interacción entre el cliente y el proveedor de telecomunicaciones, se recomienda ocultar esta complejidad al cliente, por ejemplo, habilitando una capa de abstracción que se ocupe de asignar los requisitos a los puntos de control dentro de la red.

[0085] En un segundo ejemplo de caso de uso que implica la portabilidad de aplicaciones entre plataformas de nube, por ejemplo, la reubicación del servidor de aplicaciones o la movilidad del cliente de aplicaciones, algunas aplicaciones del cliente vertical pueden desplegarse o migrarse a diferentes plataformas de nube (por ejemplo, para un escenario de vehículo a todo ("V2X"), algunas aplicaciones del fabricante de automóviles X pueden reubicarse en una nube perimetral conectada a CN-U A, mientras que otras aplicaciones se despliegan en la nube regional conectada a CN-U B). Esto requerirá que, para consumir servicios de gestión y control, las API tengan que configurarse hacia aplicaciones del mismo vertical de forma diferente. Esto puede incluir la información de la API (por ejemplo, puntos de terminación), así como los protocolos de la API (por ejemplo, para garantizar el cumplimiento de los requisitos de latencia). Esto puede resultar complejo, sobre todo cuando intervienen varios proveedores.

[0087] Un ejemplo de caso de uso para RAN abierta ("O-RAN"), pero no limitado a O-RAN, comprende la introducción de un SDK de portabilidad para soportar la exposición de servicios de una plataforma en la nube a las aplicaciones, que están alojadas en esta plataforma. Tales aplicaciones podrían ser, por ejemplo, aplicaciones de computación móvil perimetral ("MEC") en sistemas MEC, o xApp en arquitectura O-RAN. La necesidad de este kit de desarrollo de software ("SDK") es permitir la portabilidad de aplicaciones entre plataformas sin depender de parámetros y lenguajes de programación dependientes de la plataforma. Dicho SDK puede considerarse como un SDK independiente de la plataforma que comprende una API simplificada sobre las API proporcionadas por la plataforma (por ejemplo, las API en C de la plataforma del controlador inteligente RAN ("RIC") se trasladan a API en Python simplificadas).

[0089] La configuración del asignación del SDK de portabilidad a las API de servicio y la configuración de las API simplificadas basadas en las API proporcionadas por la plataforma, es uno de los retos a resolver en este caso de uso, ya que son múltiples los factores para tener en cuenta. Estos factores pueden ser 1) los permisos que tiene la aplicación final, 2) los aspectos de seguridad (por ejemplo, la topología de red oculta a terceros), 3) los requisitos dinámicos de los servicios nuevos/modificados que deben exponerse, y 4) el estado/disponibilidad de las API, se necesita cierto control en la plataforma para saber cómo configurar o adaptar la asignación (la asignación puede no ser estático).

[0091] [0036] En este caso, dos plataformas en nube, la plataforma en nube # 1 y la plataforma en nube # 2, podrían pertenecer al mismo proveedor y ser, naturalmente, del mismo dominio tecnológico. Sin embargo, en caso de que las plataformas en la nube estén bajo diferentes entidades de gestión, la aplicación xAPP/MEC tendría que actualizar la localización en la que accede a los servicios de gestión para utilizar una nueva instancia para la plataforma en la nube # 2. Esto es complejo, ya que también requiere que el contexto de la aplicación xApp/MEC se mueva a través de los sistemas de gestión y una forma de que la aplicación xApp/MEC sepa que ahora necesita utilizar la nueva instancia de servicios de gestión/API.

[0093] En un tercer ejemplo de caso de uso relacionado con la habilitación de segmentos de red, el segmento de red es una característica clave de 5G que introduce subredes lógicas de extremo a extremo correspondientes a diferentes verticales. La fragmentación de la red permite desplegar múltiples redes lógicas conocidas como instancias de segmentación de red ("NSI") que ofrecen a terceros y a sectores verticales servicios de comunicación personalizados ("CS") sobre una infraestructura compartida. Basada en una red física que puede ser operada por un operador público o una empresa, la 5G proporciona los medios para ejecutar múltiples segmentos con distintos propósitos de comunicación. La 5G permite que los segmentos funcionen de forma independiente y, si se desea, aislados entre sí. Una instancia de segmento de red, que puede definirse como segmento privado o público en función del escenario, puede constar de una parte RAN y una parte de red central ("CN"). Una subparte de una instancia de subdivisión de red se denomina instancia de subred de subdivisión de red ("NSSI"), que a su vez puede contener más NSSI. La aplicación hasta ahora no tiene la posibilidad en la red de telecomunicaciones actual de cambiar, o aprovisionar nuevas o reemplazar las entidades gestionadas que utilizan. Una aplicación puede utilizar cualquiera de las siguientes entidades gestionadas: CS, NSI, NSSI, funciones de red u otros recursos de las redes de telecomunicaciones, como las funciones de red virtualizadas ("VNF") o entidades físicas como las funciones de red físicas ("PNF").

[0095] Un aspecto clave en la configuración y el aprovisionamiento de instancias de red es la exposición de capacidades al cliente de segmento/vertical/arrendatario de la instancia:

[0097] - relacionados con el plano de control para un determinado segmento o una sesión dentro de un segmento (a través de la función de exposición de capacidad de servicio ("SCEF")/función de exposición de red ("NEF")). Podría tratarse, por ejemplo, de análisis de segmentos de red desde la función de análisis de datos de red ("NWDAF"), o de la influencia de la dirección del tráfico/calidad del servicio ("QoS") por parte de la aplicación para un usuario dentro de un segmento. - relacionados con el plano de gestión para una o varias segmentos o subredes de segmentos concretas (por ejemplo, RAN, CN). Esto, por ejemplo, podría estar relacionado con la modificación o supervisión de NSI/NSSI por parte del cliente basándose en el simulador a nivel de sistema ("SLS").

[0099] Las capacidades de exposición antes mencionadas, que pueden ser específicas de cada segmento o específicas de cada segmento, requieren el uso de API entre el 5GS y las aplicaciones desplegadas por el cliente de segmento de red. En el caso de las interacciones del plano de control, se realiza a través de las API NEF/SCEF en dirección norte; mientras que en el caso de la exposición del servicio de gestión, se realiza a través de las API MEF/función de gestión de gobernanza de la exposición ("EGMF").

[0101] En este caso, los servicios relacionados con el control y la gestión pueden estar fuertemente acoplados, ya que la gestión de los segmentos afecta al plano de control y viceversa; al mismo tiempo, el cliente de segmento puede tener solicitudes dinámicas/bajo demanda que afectan tanto al plano de control como al de gestión. Un cliente, si tiene permiso, puede querer influir en las decisiones relacionadas con el plano de control o gestión. En este caso, una entrada para decidir solicitar una adaptación de la red puede ser activada por un evento que llega al sistema de gestión. Es posible que haya que tenerlo en cuenta a la hora de configurar las API relacionadas con la exposición de la capacidad de segmento.

[0102] - Ejemplo 1: La alta carga/indisponibilidad de recursos de la RAN NSSI puede afectar a los parámetros de segmento por equipo de usuario ("UE"). El cliente de segmento puede requerir la adaptación del plano de control (por ejemplo, adaptación de recursos, direccionamiento de tráfico, reasignación de app a segmento) basándose en un evento del plano de gestión.

[0103] - Ejemplo 2: La movilidad de un grupo de UE puede afectar a las políticas de gestión de recursos radioeléctricos ("RRM") del segmento para una o más áreas de celda (según lo configurado por la administración y mantenimiento de la operación ("OAM"); sin embargo, sin tener en cuenta el comportamiento del UE).

[0105] Es posible que el cliente de segmento no quiera entender los parámetros de red específicos proporcionados por el operador de red móvil ("ORM") (relacionados con el servicio que se va a exponer), pero necesita una salida que sea comprensible (por ejemplo, una alerta del ORM, una instrucción para obtener más recursos/más funciones de plano de usuario ("UPF")). Al mismo tiempo, el ORM puede querer ocultar la topología de la red mientras proporciona la información necesaria al cliente de segmento. Un caso es cuando una aplicación cambia el comportamiento, por ejemplo, cambio del nivel de automatización del servicio, cambio de la distancia entre vehículos en un pelotón, cambio de velocidad). Otro caso es solicitar una acción de control o de plano de gestión para garantizar el cumplimiento de estos requisitos. Esto puede implicar la selección de otra red pública de telefonía móvil terrestre ("PLMN") o tecnología de acceso radioeléctrico ("RAT") para hacer frente a un descenso previsto. Además, puede que el vertical sólo quiera una alerta que no sea necesariamente de degradación de la red/QoS, sino un evento para el que el vertical se ha suscrito (por ejemplo, alerta cuando la localización de un dron se desvía si se utilizan servicios de localización, alerta cuando la mejora de la QoS/calidad de la experiencia ("QoE") está disponible en un área determinada).

[0107] [0042] En estos casos de uso, pueden estar disponibles diferentes segmentos en todas las frecuencias proporcionadas o en un subconjunto de ellas (por ejemplo, FR1 o FR2 solamente) en función del acuerdo entre el MNO y el proveedor de servicios de aplicaciones ("ASP") (y de las capacidades de la red para soportar un requisito de segmento). Por ejemplo, un operador de redes móviles ha proporcionado un conjunto de segmentos de red (segmento#l, segmento#2, segmento#3), que pueden ser utilizados por diferentes ASP (por ejemplo, segmento#l para servicios de vídeo en línea, segmento#2 para juegos, segmento#3 para banda ancha móvil mejorada ("eMBB") o servicio de Internet de las cosas ("IOT")). Diferentes ASP pueden utilizar estos segmentos (o un subconjunto de ellos) para diferentes servicios que ofrecen. Además, cuando una aplicación cambia los segmentos de red a los que se accede, debe ser independiente de los UE que acceden al servicio y debe realizarse automáticamente. Para permitir tales cambios proporcionados por ASP, se requiere la exposición de la capacidad de segmento para influir en el plano de control (para solicitar adaptaciones relacionadas con la sesión, por ejemplo, reasignación del nombre de red de datos ("DNN"), reasignación de segmento) y en el plano de gestión (adaptación de parámetros NSFNSSI como políticas RRM o cobertura). Esto se hará a través de API tanto desde el plano de control como desde el de gestión (aunque de forma descoordinada). En este ejemplo, la aplicación vertical necesita saber qué entidad ofrece qué API y cuáles son los requisitos de protocolo para el consumo de la API.

[0109] Para todos estos casos de uso (por ejemplo, soporte de múltiples proveedores, portabilidad, fragmentación), existe un problema común, que es cómo configurar la exposición de los servicios a través de las API de forma que sea 1) independiente de la infraestructura de telecomunicaciones subyacente, 2) oculte la complejidad de la infraestructura de telecomunicaciones, 3) no afecte/restrinja el nivel de exposición a la vertical, y 4) que sea resistente a los cambios dinámicos que puedan producirse debido a la portabilidad de las aplicaciones o a los cambios de estado de las API soportadas por las telecomunicaciones. Por lo tanto, el problema que hay que resolver es cómo configurar las API para exponer las capacidades proporcionadas por la plataforma en nube/telco (específicas, de control y de gestión) a las aplicaciones del cliente vertical (que pueden desplegarse de forma centralizada o distribuida en diferentes nubes) para hacer frente a la cuestión mencionada.

[0111] La figura 1 representa un sistema de comunicación inalámbrica 100 para configurar interfaces de programación de aplicaciones independientes de la plataforma, de acuerdo con realizaciones de la divulgación. En diversas realizaciones, el sistema de comunicación inalámbrica 100 incluye al menos una unidad remota 105, una red de acceso radioeléctrico ("RAN") 110 y una red central móvil 120. La rA n 110 y la red básica móvil 120 forman una red de comunicaciones móviles. La RAN 110 puede estar compuesta por una unidad base 111 con la que la unidad remota 105 se comunica utilizando enlaces de comunicación inalámbrica 115. Aunque en las figuras 1A-1C se representa un número específico de unidades remotas 105, unidades base 111, enlaces de comunicación inalámbrica 115, RAN 110, y redes centrales móviles 120, un experto en la técnica reconocerá que en el sistema de comunicación inalámbrica 100 puede incluirse cualquier número de unidades remotas 105, unidades base 111, enlaces de comunicación inalámbrica 115, RAN 110, y redes centrales móviles 120.

[0113] En una implementación, la RAN 110 cumple con el sistema 5G especificado en las especificaciones 3GPP. En otra implementación, la RAN 110 cumple con el sistema LTE especificado en las especificaciones 3GPP. En términos más generales, sin embargo, el sistema de comunicación inalámbrica 100 puede implementar alguna otra red de comunicación abierta o propietaria, por ejemplo WiMAX, entre otras redes. La presente divulgación no pretende limitarse a implementar ninguna arquitectura o protocolo de sistema de comunicación inalámbrica en particular.

[0115] En la figura 1, el sistema de comunicación inalámbrica 100 soporta un despliegue de servicio de computación perimetral que incluye al menos una red de datos perimetral ("EDN") 141 soportando un área de servicio EDN 143. La EDN 141 incluye al menos un Servidor de Aplicaciones Perimetrales ("EAS") 177 soportando una instancia de una aplicación. Cuando una unidad remota 105 está localizada en el área de servicio EDN 143, el cliente 179 de la Aplicación Edge es capaz de acceder al EAS 177. Sin embargo, cuando la unidad remota 105 está fuera de cualquier área de servicio EDN, el cliente EA 179 es capaz de acceder a una instancia de la aplicación utilizando el servidor de aplicaciones 171 situado en la red de datos 150 (es decir, una red de datos regional). La EDN 141 también incluye un servidor de habilitación perimetral ("EES") 173, un servidor de habilitación de aplicaciones soporte intermedio, mientras que la unidad remota 105 incluye un cliente de habilitación perimetral ("EEC") 175. En otras realizaciones, el sistema de comunicación inalámbrica puede soportar una vertical de fábricas futuras ("FF") y/o una vertical V2X (no representada).

[0117] En una realización, las unidades remotas 105 pueden incluir dispositivos informáticos, como ordenadores de sobremesa, ordenadores portátiles, asistentes digitales personales ("PDA"), tabletas, teléfonos inteligentes, televisores inteligentes (por ejemplo, televisores conectados a Internet), electrodomésticos inteligentes (por ejemplo, electrodomésticos conectados a Internet), descodificadores, consolas de juegos, sistemas de seguridad (incluidas cámaras de seguridad), ordenadores de a bordo de vehículos, dispositivos de red (por ejemplo, enrutadores, conmutadores, módems) o similares. En algunas realizaciones, las unidades remotas 105 incluyen dispositivos portátiles, como relojes inteligentes, pulseras de aptitud física, pantallas ópticas montadas en la cabeza o similares. Además, las unidades remotas 105 pueden denominarse UE, unidades de abonado, móviles, estaciones móviles, usuarios, terminales, terminales móviles, terminales fijos, estaciones de abonado, terminales de usuario, unidad inalámbrica de transmisión/recepción ("WTRU"), un dispositivo, o por otra terminología utilizada en la técnica.

[0119] [0048] Las unidades remotas 105 pueden comunicarse directamente con una o más de las unidades base 111 en la RAN 110 a través de señales de comunicación de enlace ascendente ("UL") y enlace descendente ("DL"). Además, las señales de comunicación UL y DL pueden transportarse a través de los enlaces de comunicación inalámbrica 115. En este caso, la RAN 110 es una red intermedia que proporciona a las unidades remotas 105 acceso a la red central móvil 120. Tal y como se ha representado, la unidad remota 105 puede incluir recursos de hardware y software para ejecutar un cliente SEAL 107 y/o un cliente de aplicación móvil 109.

[0121] En algunas realizaciones, las unidades remotas 105 se comunican con un anfitrión de comunicación (por ejemplo, el servidor de aplicaciones perimetral 149 y/o el servidor de aplicaciones 153) a través de una conexión de red con la red básica móvil 120. Por ejemplo, una aplicación móvil (por ejemplo, navegador web, cliente multimedia, aplicación de teléfono/VoIP, cliente de aplicación móvil 109) en la unidad remota 105 puede activar la unidad remota 105 para establecer una sesión PDU (u otra conexión de datos) con la red central móvil 120 a través de la RAN 110. A continuación, la red central móvil 120 retransmite el tráfico entre la unidad remota 105 y el anfitrión de comunicaciones (es decir, el servidor de aplicaciones) utilizando la sesión PDU. Obsérvese que la unidad remota 105 puede establecer una o más sesiones PDU (u otras conexiones de datos) con la red básica móvil 120. Como tal, la unidad remota 105 puede tener concurrentemente al menos una sesión PDU para comunicarse con un servidor de aplicaciones y al menos una sesión PDU adicional para comunicarse con otro servidor de aplicaciones (no mostrado).

[0123] Las unidades base 111 pueden estar distribuidas por una región geográfica. En ciertas realizaciones, una unidad base 111 también puede denominarse terminal de acceso, punto de acceso, base, estación base, Nodo-B, eNB, gNB, Nodo-B doméstico, nodo de retransmisión o cualquier otra terminología utilizada en la técnica. Las unidades base 111 suelen formar parte de una red de acceso radioeléctrico ("RAN"), como la RAN 110, que puede incluir uno o más controladores acoplados de forma comunicable a una o más unidades base 111 correspondientes. Estos y otros elementos de la red de acceso de radio no se ilustran, pero son bien conocidos en general por aquellos que tienen habilidad ordinaria en la técnica. Las unidades base 111 se conectan a la red básica móvil 120 a través de la RAN 110.

[0125] Las unidades base 111 pueden dar servicio a un número de unidades remotas 105 dentro de un área de servicio, por ejemplo, una célula o un sector de célula, a través de un enlace de comunicación inalámbrica 115. Las unidades base 111 pueden comunicarse directamente con una o más de las unidades remotas 105 mediante señales de comunicación. Generalmente, las unidades base 111 transmiten señales de comunicación DL para dar servicio a las unidades remotas 105 en el dominio temporal, frecuencial y/o espacial. Además, las señales de comunicación DL pueden transportarse a través de los enlaces de comunicación inalámbrica 115. Los enlaces de comunicación inalámbrica 115 pueden ser cualquier portador adecuado en el espectro de radio con o sin licencia. Los enlaces de comunicación inalámbrica 115 facilitan la comunicación entre una o más de las unidades remotas 105 y/o una o más de las unidades base 111.

[0127] En una realización, la red básica móvil 120 es un núcleo 5G ("5GC") o el núcleo de paquetes evolucionado ("EPC"), que puede estar acoplado a una red de paquetes de datos 150, como Internet y las redes privadas de datos, entre otras redes de datos. Una unidad remota 105 puede tener una suscripción u otra cuenta con la red básica móvil 120. Cada red básica móvil 120 pertenece a una única red pública de telefonía móvil terrestre ("PLMN"). La presente divulgación no pretende limitarse a implementar ninguna arquitectura o protocolo de sistema de comunicación inalámbrica en particular.

[0129] La red básica móvil 120 incluye varias funciones de red ("NF"). Como se muestra, la red central móvil 120 incluye múltiples funciones de plano de usuario ("UPF") 121. La red básica móvil 120 también incluye múltiples funciones de plano de control, entre las que se incluyen una función de gestión de acceso y movilidad ("AMF") 123 que da servicio a la RAN 110, una función de gestión de sesiones ("SMF") 125, una función de control de políticas ("PCF") 127, una función de exposición a la red ("NEF") 128 y una función de gestión unificada de datos ("UDM") 129. En determinadas realizaciones, la red básica móvil 120 también puede incluir una Función de Servidor de Autenticación ("AUSF"), una Función de Repositorio de Red ("NRF") (utilizada por las distintas NF para descubrir y comunicarse entre sí a través de API), u otras NF definidas para el 5GC. En algunas realizaciones, el UDM 129 está co-localizado con un Repositorio de Datos de Usuario ("Ud R").

[0131] En diversas realizaciones, la red básica móvil 120 incluye servicios de red de corte (no mostrados) que son producidos por una unidad de red. La unidad de red puede incluir un servicio de plano de control producido por una función de red, un servicio de gestión de red producido por una función de gestión, un servicio de computación móvil perimetral producido por una función de red, un servicio de habilitación de aplicaciones producido por una función de habilitación de aplicaciones, un servicio RIC producido por una unidad O-RAN, y/o similares.

[0133] En diversas realizaciones, la red básica móvil 120 soporta diferentes tipos de conexiones de datos móviles y diferentes tipos de segmentos de red, en las que cada conexión de datos móviles utiliza un segmento de red específica. Aquí, un "segmento de red" se refiere a una porción de la red básica móvil 120 optimizada para un determinado tipo de tráfico o servicio de comunicación. Una instancia de segmento de red puede identificarse mediante un S-NSSAI, mientras que un conjunto de segmentos de red para los que la unidad remota 105 está autorizada a utilizar se identifica mediante NSSAI. En ciertas realizaciones, los distintos segmentos de red pueden incluir instancias separadas de funciones de red, como la SMF 125 y la UPF 121. En algunas realizaciones, los diferentes segmentos de red pueden compartir algunas funciones de red comunes, como la AMF 123. En la figura 1 no se muestran los distintos segmentos de la red para facilitar la ilustración, pero se da por supuesto que los soportan.

[0135] [0056] El sistema de comunicación inalámbrica 100 incluye una función OAM/Gestión 130. La función OAM/Gestión 130 puede proporcionar parámetros de segmento (por ejemplo, capacidades de segmento, políticas de segmento, información de disponibilidad de segmento, vertical a suscripciones y permisos de segmento, indicadores clave de rendimiento de segmento, acuerdos de nivel de servicio ("SLA") de segmento, y/o similares) a los servidores habilitadores (por ejemplo, EES 145). En varias realizaciones, la función de OAM/Gestión 130 realiza la instanciación de segmento, por ejemplo, en respuesta a una solicitud de un proveedor de servicios.

[0137] Tal y como se representa, la red de datos 150 puede incluir un servidor VAL 151, un servidor de aplicaciones 153 y/o un servidor SEAL 155. En 3GPP, se ha especificado una capa de soporte de aplicaciones para aplicaciones verticales, conocida como capa habilitadora de aplicaciones verticales. Algunos ejemplos de habilitadores de aplicaciones verticales son el servidor de habilitación V2X, el servidor de habilitación FF y el servidor de habilitación UAS. La capa de habilitación de aplicaciones verticales puede actuar como un soporte intermedio distribuido o centralizado, que puede residir en el dominio del operador de telefonía móvil o del proveedor de servicios verticales/terceros, para exponer las API en dirección norte a los verticales, así como para proporcionar algunas funcionalidades de soporte servidor-cliente para los dispositivos conectados.

[0139] La capa de arquitectura de habilitación de servicios ("SEAL") proporciona una capa de habilitación común para todos los verticales. La SEAL comprende funcionalidades de servidor (por ejemplo, Gestión de Recursos de Red, Gestión de Localización, Gestión de Configuración, Gestión de Grupos, Gestión de Identidades, Gestión de Claves, Habilitación de Cortes de Red, y/o similares) así como funcionalidades de cliente en los dispositivos finales. La SEAL también comprende la función AF cuando interactúa con la red principal 5G. El servidor VAL 151 es una variante de un servidor facilitador o de un servidor específico de una aplicación, que consume los servicios proporcionados por las funcionalidades del servidor SEAL. En algunas realizaciones, el servidor SEAL 155 y/o el servidor de habilitación residen en la Red de Datos 150 o en la Red de Datos de Borde 141. En otras realizaciones adicionales, el servidor SEAL 155 y el servidor de habilitación están ubicados conjuntamente.

[0141] Además, existen dos modelos: dentro y fuera de la red. En el modelo dentro de la red, el cliente de SEAL 107 se comunica con el servidor de SEAL 155 a través del punto de referencia SEAL-UU, mientras que fuera de la red, el cliente de gestión de identidades del UE1 se comunica con el cliente de SEAL 107 del UE2 a través del punto de referencia SEAL-PC5.

[0143] Aunque en la figura 1 se representan números y tipos específicos de funciones de red, los expertos en la técnica reconocerán que en la red básica móvil 120 puede incluirse cualquier número y tipo de funciones de red. Además, cuando la red básica móvil 120 es un EPC, las funciones de red representadas pueden sustituirse por entidades EPC apropiadas, como un MME, S-GW, P-GW, HSS y similares. En determinadas realizaciones, la red básica móvil 120 puede incluir un servidor AAA.

[0145] Aunque la figura 1 muestra componentes de una RAN 5G y una red central 5G, las soluciones descritas se aplican a otros tipos de redes de comunicación y RAT, incluidas las variantes de IEEE 802.11, GSM, GPRS, UMTS, variantes de LTE, CDMA 2000, Bluetooth, ZigBee, Sigfoxx y similares. Por ejemplo, en una variante LTE que incluya un EPC, la AMF 123 puede asignarse a un MME, la SMF a una porción de plano de control de un PGW y/o a un m Me , la UPF a un SGW y a una porción de plano de usuario del PGW, el UDM/UDR a un HSS, etc.

[0147] En las siguientes descripciones, el término eNB/gNB se utiliza para la estación base, pero puede sustituirse por cualquier otro nodo de acceso radioeléctrico, por ejemplo, BS, eNB, gNB, AP, NR, etc. Además, las operaciones se describen principalmente en el contexto de la 5G N<r>. Sin embargo, las soluciones/métodos propuestos también son igualmente aplicables a otros sistemas de comunicaciones móviles que soportan el reajuste de segmentos y/o DNN asistido por soporte intermedio para aplicaciones verticales y/o despliegues de redes perimetrales.

[0149] En el presente documento se describe un mecanismo (por ejemplo, en una función de habilitación de aplicaciones/intermediario que puede residir en el dominio de un tercero/proveedor de servicios (SP) o el MNO o un proveedor de plataforma en nube) para configurar interfaces de programación de aplicaciones independientes de la plataforma. Las nuevas API independientes de la plataforma simplifican las interacciones dinámicas entre las aplicaciones del cliente vertical y la infraestructura subyacente de telecomunicaciones ("telco") (por ejemplo, los dominios de control y gestión). Esto permite interacciones uniformes entre el cliente y la infraestructura de telecomunicaciones en todos los dominios tecnológicos y de proveedores, y facilita la portabilidad de aplicaciones en redes de múltiples proveedores, múltiples instancias de redes de telecomunicaciones y diferentes plataformas tecnológicas.

[0151] La vinculación - simplificación de las API a los SDK, que pueden ser independientes de la plataforma o personalizables sobre las API proporcionadas por las empresas de telecomunicaciones, requiere alguna forma de configuración a partir de una capa de abstracción. Dicha configuración puede consistir en la asignación de API de servicio a SDK en función del nivel de exposición del servicio/ranura, así como en la configuración de las API simplificadas/trasladadas que se publicarán en las aplicaciones de los clientes.

[0153] Dicha configuración podría proporcionarse inicialmente, por ejemplo, cuando el proveedor de infraestructura de telecomunicaciones proporciona un SLA/SLS, o podría actualizarse dinámicamente. Una razón para estas actualizaciones dinámicas pueden ser los eventos relacionados con el estado/disponibilidad de la API. Otras razones podrían ser la adaptación dinámica de los requisitos de exposición al servicio para un área o momento o tipo de servicio concretos.

[0154] Además, dicha adaptación de la configuración puede ser el resultado de la reubicación de un cliente o servidor de aplicaciones en diferentes plataformas (por lo que las API proporcionadas por el proveedor de telecomunicaciones/nube tendrán que cambiar).

[0156] La materia aquí tratada, en una realización, resuelve este problema proporcionando una capa de abstracción para configurar la asignación de API de servicio a API personalizadas de segmento/vertical, para permitir la exposición de servicios telco de fácil aplicación (que pueden ser proporcionados por múltiples dominios y vendedores). En ciertas implementaciones, la presente divulgación propone un método en una aplicación o entidad de red de confianza que está configurada para determinar la asignación de "API de segmento" a los servicios expuestos proporcionados. Las API de segmento, tal y como se utilizan en el presente documento, se definen como conjuntos personalizados de API de servicio, que pueden ser de control o gestión o API proporcionadas por terceros y que pueden asignarse a instancias de segmento concretas. Las API de segmento pueden ser una API agrupada o combinada comprendiendo diferentes tipos de API, que se utilizarán para exponer los servicios de control y gestión que necesite el cliente de segmento.

[0158] En implementaciones adicionales, la solución propuesta determina la correspondencia entre las API dependientes de la plataforma, basándose en los requisitos de exposición del servicio, y las API simplificadas independientes de la plataforma, para permitir la portabilidad de las aplicaciones entre plataformas en nube sin depender del conocimiento del protocolo subyacente.

[0160] La figura 2 representa una arquitectura de red 200 y un flujo de señalización para gestionar la configuración de interfaces de programación de aplicaciones independientes de la plataforma, de acuerdo con realizaciones de la divulgación. En una realización, en la etapa 1, un servidor de soporte intermedio/de habilitación 202 (por ejemplo, un de habilitación de segmento de red, un soporte intermedio, una función de aplicación, una función de red, una función de gestión, o similares), en un perímetro/red regional/núcleo/plataforma 201c, recibe un parámetro de servicio que puede incluir un nivel de exposición de servicio, una indicación de accesibilidad de servicio, una indicación de disponibilidad de servicio, una lista basada en la autorización de la aplicación 204a-b, y/o similares del proveedor de servicios de telecomunicaciones 206, que puede ser el dominio M&O, así como el SLA/SLS para un tipo de aplicación/servicio. En ciertas realizaciones, esto puede estar relacionado con un segmento de red. En este caso, el proveedor de servicios telco 206 es el proveedor de segmento, y esta etapa incluye un asignación de aplicación a segmento basado en las suscripciones de aplicaciones verticales, un asignación de exposición de segmento a servicio del proveedor de segmento, o similares. La entrada para configurar las API de segmento es el SLS proporcionado por el sistema de gestión o GST/NEST proporcionado por GSMA y/o la asignación de aplicación a segmento proporcionado por la aplicación/NSE/red.

[0162] En una realización, en la etapa 2, el servidor de soporte intermedio/de habilitación 202 determina la asignación de las API de servicio a un SDK/ API basándose en el requisito de exposición del servicio. El SDK/API resultante puede ser un SDK/API personalizado en segmentos o vertical. Esto también puede comprender la configuración de las API dependientes de la plataforma 208, y puede comprender los nombres de API, URI, versiones de API, información de protocolo, puntos de terminación por API, tipos de API incluidos, métodos de comunicación (por ejemplo, solicitudrespuesta o suscripción-notificación), validez temporal, y/o similares.

[0164] En una realización, esto puede determinarse basándose en coincidencias entre el nivel de exposición del servicio (por ejemplo, la función CP #a y los permisos de acceso para el Servicio #x) y los parámetros de exposición del segmento (por ejemplo, la función CP #a proporcionada por NEF#1 para el segmento #1 con ciertas políticas de acceso, y por NEF#2 para el segmento #2 con otras políticas de acceso) y encerrando la información de API/protocolo/transporte (así como las herramientas SDK) para acceder a las API de servicio de los productores de API de servicio.

[0166] En ciertas realizaciones, la determinación de la asignación requiere el conocimiento de la disponibilidad de las API dependientes de la plataforma. La disponibilidad de las API dependientes de la plataforma puede mantenerse a través de la recepción periódica de mensajes de siempre activo/persistentes de los productores de API o interactuando con el registro de API (por ejemplo, CCF, habilitación de API) para comprobar la disponibilidad.

[0168] A continuación se muestra un ejemplo de determinación para la asignación entre la API personalizada vertical/de segmento y las API dependientes de la plataforma que están agrupadas. Aquí también podrían determinarse los detalles de implementación:

[0169]

[0172] En una realización, en la etapa 3, el servidor de soporte intermedio/de habilitación 202 se suscribe o registra con las funciones de dominio involucradas, por ejemplo, dominios de gestión 212a-b que interactúan con el soporte intermedio 202 a través de un EGMF, dominios de plano de control 214a-b de una o más redes que interactúan con el soporte intermedio 202 a través de un NEF, MEC, otros servidores, por ejemplo, SEAL, y/o similares, que producen las API dependientes de plataforma basadas en los requisitos de exposición de servicio/segmento. Esta etapa permitirá que el soporte intermedio 202 sea capaz de invocar estas API en nombre de la aplicación 204a-b, que puede ser un cliente vertical/segmento que ha desplegado aplicaciones en diferentes plataformas de nube 201a-b (por ejemplo, nube regional, perimetral).

[0174] En una realización, en la etapa 4, el servidor de soporte intermedio/de habilitación 202 determina las API de SDK independientes de la plataforma 210 y su asignación a las API de SDK dependientes de la plataforma 208 (de la etapa 2). En esta etapa, el protocolo de telecomunicaciones subyacente y los aspectos de transporte se desacoplarán de la API 210 independiente de la plataforma para ser expuestos a las aplicaciones finales 204a-b, permitiendo así una exposición uniforme de los servicios a través de diferentes plataformas. Asimismo, el soporte intermedio 202 puede actuar como repositorio/registro de las API independientes de la plataforma 210, su correspondencia con las API personalizadas de segmento/vertical y sus configuraciones y la correspondencia con las API dependientes de la plataforma constituyente 208 (por ejemplo, gestión, control, proporcionadas por la aplicación). A continuación se muestra un ejemplo:

[0177]

[0180] En una realización, en la etapa 5, el servidor de soporte intermedio/de habilitación 202 crea y publica las API 210 independientes de la plataforma que se expondrán a las aplicaciones verticales/finales 204a-b. Esto también puede incluir herramientas de programación, bibliotecas y/o similares.

[0182] En una realización, en la etapa 6, basándose en eventos de activación (por ejemplo, movilidad de UE, reubicación del servidor de aplicaciones en una plataforma diferente, indisponibilidad de las API proporcionadas por la empresa de telecomunicaciones, indicación de sobrecarga de la API, y/o similares), el soporte intermedio 202 supervisará y adaptará las SDK/API 208 dependientes de la plataforma (de la etapa 2) y su asignación a las SDK API 210 independientes de la plataforma (determinadas en la etapa 4), con el fin de garantizar la continuidad/disponibilidad de las SDK API 210 independientes de la plataforma en entornos que cambian dinámicamente.

[0184] [0077] En la etapa 6, una implementación adicional de un evento de disparo puede ser la carga elevada de la API 208 dependiente de la plataforma, que puede comprobarse, por ejemplo, a través de una función de control/monitorización de la carga de la API en la plataforma, o a través de una operación Reintentar-Después en HTTP/REST. Tal evento de activación permitirá al soporte intermedio 202 ejecutar la auto-aceleración/limitación de velocidad de las API dependientes de la plataforma 208, con el fin de garantizar que las API independientes de la plataforma 210 no se vean afectadas (por ejemplo, por una posible sobrecarga/rechazo).

[0186] Un ejemplo de la industria vertical de vehículos puede ser ilustrativo. El fabricante de automóviles X necesita determinados servicios de 5GS y tiene un acuerdo con el ORM x para consumir estos servicios para un conjunto de aplicaciones V2X (por ejemplo, conducción avanzada, Platooning, etc.) en toda la PLMN. Los servicios telco pueden incluir servicios de gestión, servicios de control, servicios SEAL, servicios MEC y/o similares. Para exponer estos servicios al fabricante de automóviles X y cumplir los requisitos, el proveedor de MNO/SDK forma un paquete SDK/API, por ejemplo, un SDK 208 dependiente de la plataforma con toda la información necesaria. El SDK/API formado puede formarse en una plataforma en la nube e incluye toda la información de protocolo y comunicación para llegar a estos servicios; sin embargo, puede no ser óptimo enviar toda esta información al fabricante de automóviles X. Además, el fabricante de automóviles X puede ejecutar servicios en diferentes regiones en las que se utiliza una infraestructura de telecomunicaciones (y software) diferente para proporcionar estos servicios.

[0188] Así pues, el soporte intermedio 202 (en el MNO o en el proveedor de SDK o en el dominio del proveedor de la nube) necesita formar un SDK 210 adicional independiente de la plataforma para publicarlo en el fabricante de automóviles X (por ejemplo, una API de calidad de servicio predictiva) sin necesidad de conocer los protocolos y la infraestructura subyacentes. Cuando el SDK/API 208 dependiente de la plataforma necesita cambiar, por ejemplo, debido a la falta de disponibilidad de API, movilidad de UE (a través de diferentes plataformas MEC), reubicaciones de aplicaciones, o similares, entonces el SDK 210 independiente de la plataforma necesita mantenerse intacto (por ejemplo, una API de QoS predictiva necesita ser proporcionada, sin importar si NWDAF x o NEF y proporciona los servicios). Por lo tanto, esta solución no sólo configura la asignación de las API de servicio a las API a medida del segmento/vertical en función de las necesidades de la vertical, sino que también realiza una simplificación de estas API, con el fin de permitir la portabilidad con el mínimo conocimiento en las aplicaciones finales 204a-b.

[0190] A modo de ejemplo para la movilidad de los UE entre plataformas, las API proporcionadas por MEC (por ejemplo, el servicio de información de red radioeléctrica ("RNIS")) cambiarán de proveedor de API y posiblemente otros aspectos (por ejemplo, protocolo de API, comunicación, etc.). Además, se pueden utilizar diferentes servicios MEC en diferentes plataformas MEC. En este caso, el SDK 210 independiente de la plataforma sigue siendo el mismo, pero las API 208 dependientes de la plataforma cambiarán. En ciertas realizaciones, un repositorio, por ejemplo, una base de datos, un almacén de datos, o similar, en un UE, un dispositivo de red, y/o similar puede ser utilizado para almacenar las API 210 independientes de la plataforma determinadas y la asignación a las API 208 dependientes de la plataforma.

[0192] La figura 3 representa un diagrama de secuencia de mensajes 300 para una primera realización de la solución propuesta dirigida a una configuración API de segmento de red. En la realización representada, el soporte intermedio 202 es el servidor de habilitación definido por SA6 (NSE o cualquier otro servidor de habilitación vertical) y se supone que la información del segmento ya está anunciada en el cliente de segmento por el proveedor del segmento de red.

[0194] En la etapa 0 (véase el bloque 302), los dominios pertinentes, por ejemplo, el dominio de gestión 212 y el dominio de plano de control 5GC-CP (NEF) 214 determinan el parámetro de servicio, por ejemplo, el nivel de exposición de servicio para la NSI basado en los requerimientos del cliente de segmento.

[0196] En la etapa 1 (véase la mensajería 304), en una realización, los dominios pertinentes 212, 214 del proveedor de segmento de red ("NSP") envían al soporte intermedio 202 el registro/información de segmento correspondiente al cliente vertical para la(s) NSI suscrita(s). Puede provenir del OAM/MD (si está relacionado con los parámetros específicos del segmento) o del 5GC (UDM) si se trata de información de suscripción al segmento relacionado con el usuario/dispositivo. Opcionalmente, esta etapa también puede incluir una instrucción/solicitud al soporte intermedio para gestionar la configuración y exposición de la API de segmento/servicio.

[0198] En la etapa 2a (ver mensajería 306), en una realización, el soporte intermedio envía una petición al dominio(s) de gestión implicado(s) 212 para obtener el estado de la API disponible y las capacidades relacionadas con los servicios de gestión de segmento (por ejemplo, monitorización NS SI/NS I, modificación, o similares). Por ejemplo, el soporte intermedio 202 puede solicitar qué versión de qué norma se soporta y qué partes de la norma son legibles o ejecutables. Los dominios de gestión implicados 212 son conocidos por el soporte intermedio 202 desde la etapa 1 (por ejemplo, basándose en la exposición de la capacidad de servicio). Este mensaje 306 incluye al menos uno de los siguientes parámetros:

[0200] - ID de soporte intermedio

[0201] - Solicitud de nombre API/URI

[0202] - Solicitud de versión de la API

[0203] - Solicitud de formato de datos (por ejemplo, protocolo de serialización)

[0204] - Solicitud de funciones soportadas por la API relacionadas con la sección #X o el servicio #Y

[0205] - Requisito de nivel de exposición para las funciones soportadas

[0206] - Consulta del estado de la API

[0207] - Puntos de terminación de la API

[0208] - Plazo de validez de la solicitud

[0210] En algunas realizaciones, el soporte intermedio 202 puede conocer ya esta información.

[0212] En la etapa 2b (véase la mensajería 308), en una realización, el dominio de gestión 212 proporciona el estado de la API y las capacidades de gestión relacionadas con las segmentos. Este mensaje incluye al menos uno de los siguientes parámetros:

[0214] - MD ID, MnS ID

[0215] - Lista de nombres de API, tipos y formatos de datos

[0216] - Funciones soportadas por la API relacionadas con el segmento/servicio

[0217] - Nivel de exposición de las funciones soportadas

[0218] - Informe de estado de la API

[0220] En la etapa 3a (véase la mensajería 310), en una realización, el soporte intermedio 202 envía una solicitud al plano de control de CN 214 implicado (por ejemplo, NEF/SCEF) para obtener el estado disponible de la API y las capacidades relacionadas con los servicios de control relacionados con los segmentos que pueden exponerse (por ejemplo, suscripciones a segmentos, análisis de segmentos de red, eventos de monitorización de QoS/red, y/o similares). Las NEF implicadas son conocidas por el soporte intermedio 202 desde la etapa 1 (por ejemplo, basándose en la exposición de la capacidad de servicio). Este mensaje incluye al menos uno de los siguientes parámetros:

[0222] - ID de soporte intermedio

[0223] - Solicitud del nombre / URI de la API en dirección norte

[0224] - Solicitud de versión de la API en dirección norte

[0225] - Solicitud de formato de datos (por ejemplo, protocolo de serialización)

[0226] - Solicitud de funciones soportadas por la API en dirección norte relacionadas con la sección #X o el servicio #Y - Requisito de nivel de exposición para las funciones soportadas

[0227] - Consulta del estado de la API

[0228] - Puntos de terminación de la API

[0229] - Validez temporal

[0231] En la etapa 3b (véase la mensajería 312), en una realización, el plano de control 214 proporciona el estado de la API y las capacidades de exposición de control relacionadas con el segmento. Este mensaje incluye al menos uno de los siguientes parámetros:

[0233] - ID NEF

[0234] - Lista de nombres de API, tipos y formatos de datos

[0235] - Funciones soportadas por la API relacionadas con el segmento/servicio

[0236] - Nivel de exposición de las funciones soportadas

[0237] - Informe de estado de la API

[0239] En la etapa 4 (véase el bloque 314), en una realización, el soporte intermedio 202 asigna la NSI a una lista de API de servicio basándose en los requisitos de exposición de la capacidad de servicio para la NSI, la autenticación de la entidad externa y la disponibilidad de API de servicio (en cierta implementación, esto puede ser una tabla de asignación).

[0241] En la etapa 5a (véase la mensajería 316), en una realización, el soporte intermedio 202 envía una solicitud de suscripción a los servicios de gestión afectados del dominio(s) de gestión 212 para suscribirse a los servicios de gestión ("MnS") requeridos por la aplicación. La solicitud de suscripción también puede incluir el nivel de exposición para los servicios de gestión (por ejemplo, permisos, granularidad de los informes y/o similares). En la etapa 5b (véase mensajería 318), el MnS del dominio de gestión 212 envía un acuse de recibo ("ACK") para proporcionar el resultado o un acuse de recibo de la suscripción.

[0243] En la etapa 6a (ver mensajería 320), en una realización, el soporte intermedio 202 envía una solicitud de suscripción a la NEF del dominio(s) de plano de control 214 implicado(s) para suscribirse para consumir API de Control / en dirección norte relacionadas con el segmento. La solicitud de suscripción también puede incluir el nivel de exposición para los servicios de control (por ejemplo, permisos, granularidad de los informes y/o similares). En la etapa 6b (véase mensajería 322), la NEF del plano de control implicado 214 envía un ACK para proporcionar un acuse de recibo de la suscripción.

[0245] [0092] En la etapa 7 (véase el bloque 324), en una realización, el soporte intermedio 202, al suscribirse a los servicios, configura la asignación de los servicios proporcionados a una o más API de segmento para una o más segmentos. El asignación de la API a los servicios incluye el nombre/identificación de la API, los nombres de la API de servicio encerrados, URI, versiones de la API, información de protocolo, puntos de terminación por API, tipos de API incluidos, métodos de comunicación (por ejemplo, solicitud-respuesta o suscripción-notificación), validez temporal, y/o similares. Las API de segmento también pueden incluir API de servicio relacionadas con servicios de valor añadido proporcionados por soporte intermedio. En esta etapa, la información de la API (y las API encerradas) se almacenan en el soporte intermedio 202.

[0247] En la etapa 8 (ver bloque 326), en una realización, el soporte intermedio 202 puede publicar el segmento API al invocador de API 301 (esto podría consistir en API dependientes o independientes de la plataforma).

[0249] En la etapa 9 (véase la mensajería 330), en respuesta a un evento de activación (véase el bloque 328), el evento de activación es capturado por los productores de API (por ejemplo, el plano de control 214, el plano de gestión 212, SEAL, y/o similares) o el lado de la aplicación (por ejemplo, reubicación del servidor de aplicaciones en una EDN/DN diferente, movilidad del UE a una EDN diferente, cambio de comportamiento de la aplicación, y/o similares) o cualquier otro evento relacionado con la API capturado por los servicios de habilitación de API (por ejemplo, fallo, no disponibilidad) o el soporte intermedio 202.

[0251] El soporte intermedio 202, en una realización, procesa el evento de activación 328 y comprueba y actualiza la asignación de las API de servicio a las API de segmento. El objetivo es mantener inalteradas las API de segmento, de modo que el vertical no se entere de ningún cambio. Para ello, puede ser necesario actualizar las API de los servicios. En esta etapa, el soporte intermedio 202 puede proporcionar soporte adicional proporcionando servicios de valor añadido para hacer frente a la falta de disponibilidad de consumo de algunos servicios.

[0253] En la etapa 10 (ver mensajería 332), en una realización, si la información de la API de segmento cambia, el soporte intermedio puede volver a publicar la API de segmento al invocador de API 301 (esto podría consistir en API dependientes de la plataforma).

[0255] Obsérvese que pueden añadirse interacciones adicionales (a partir de las etapas 2, 3, 5, 6 para el control y la gestión) para otros servicios proporcionados por las empresas de telecomunicaciones (por ejemplo, API de nube/MEC, API de SEAL y/o similares).

[0257] La figura 4 representa un gráfico de secuencia de mensajes 400 para una segunda realización de la solución propuesta dirigida a una configuración de asignación SDK/API de portabilidad (por ejemplo, la API/SDK independiente de la plataforma). La realización descrita proporciona una solución para la configuración del SDK/API de portabilidad (independiente de la plataforma), que incluye la asignación de las API de servicio que se van a utilizar y trasladadas al SDK/API de portabilidad (independiente de la plataforma), así como la configuración de las API simplificadas basadas en la asignación.

[0259] En la etapa 1a (ver mensajería 410), en una realización, la entidad de soporte intermedio 202 solicita el nivel de exposición a un orquestador de gestión de servicios ("SMO") 402 para una xApp. Se pueden proporcionar distintos niveles de exposición en función del tipo de xApp (por ejemplo, TS, QoE, RRM, SON o similares) y de las políticas de autorización de los distintos tipos de xApp (por ejemplo, la xApp puede ser propiedad de un RIC, de un proveedor, de un ASP o similares).

[0261] En la etapa 1b (ver mensajería 412), en una realización, el SMO 402 (o M&O) envía a la entidad soporte intermedio 202, que puede ser un sidecar, agente, proxy, servicio de habilitación, o similar, un mensaje indicando el nivel de exposición por servicio, por segmento, por tipo de aplicación, o similar. Esto puede formar parte de una solicitud/suscripción para permitir a la entidad de software intermedio 202 configurar el SDK/API de portabilidad (independiente de la plataforma) o un informe a la entidad de software intermedio 202 sobre el nivel de exposición actualizado.

[0263] En la etapa 2 (véase la mensajería 414), en una realización, la entidad de software intermedio 202 comprueba con los servicios de habilitación de API 404 la disponibilidad de las API basándose en el nivel de exposición del servicio. Esta comprobación puede realizarse a través de una consulta a los servicios de habilitación de API 404 para descubrir qué API están disponibles y solicita otra información sobre la API (por ejemplo, el nombre de la URI, el tipo de API, la versión de la API, el método de comunicación, el protocolo soportado y/o similares). Aquí, se asume que la entidad de soporte intermedio 202 puede interactuar con los servicios de habilitación de API 404. Si la entidad de software intermedio 202 no forma parte de la plataforma, en ciertas realizaciones, la entidad de software intermedio 202 puede necesitar haber descubierto ya la API de habilitación (por ejemplo, la entidad de software intermedio 202 puede conocer el URI para la API de habilitación) para interactuar con los servicios de habilitación de API 404.

[0265] En la etapa 3 (véase mensajería 416), en una realización, la entidad de software intermedio 202 recibe una respuesta de descubrimiento de API con la información solicitada en la etapa 2. Esta respuesta puede comprender un informe que comprenda uno o varios de los elementos siguientes: Nombre de la API, tipo de API, versión de la API, protocolos de la API, permisos y, opcionalmente, información sobre el estado de la API y/o similares.

[0267] En la etapa 4 (véase el bloque 418), en una realización, la entidad de soporte intermedio 202 asigna las API a una API/SDK dependiente de la plataforma basándose en el tipo de servicio, tipo de aplicación, segmento, o similar, y el nivel de exposición proporcionado en la etapa 1. Dicha correspondencia puede formar parte de una tabla de correspondencia, como la que se muestra a continuación, aunque sin limitarse a ella:

[0268]

[0271] Cabe señalar que, en tal caso, un proveedor de SDK, un MNO, un proveedor de infraestructura de telecomunicaciones, un proveedor de servicios de aplicaciones, un proveedor de servicios verticales, un proveedor de nube, un proveedor de plataforma de soporte intermedio o similar puede proporcionar la información de SDK/API dependiente de la plataforma. También se señala que, aparte de la asignación, podrían ser posibles otras representaciones.

[0273] En la etapa 5a (véase la mensajería 420), en una realización, la entidad de soporte intermedio 202 envía una solicitud de suscripción a los servicios de gestión afectados del dominio(s) de gestión 408 para suscribirse para consumir las API de servicio MnS relacionadas con el segmento. La solicitud de suscripción también puede incluir el nivel de exposición para los servicios de gestión (por ejemplo, permisos, granularidad de los informes o similares). Esta suscripción puede realizarse también a través del servicio de habilitación API/habilitación API 404. En la etapa 5b (ver mensajería 422), en una realización, el MnS del dominio de gestión (o servicio de habilitación de API 404) envía un mensaje ACK para proporcionar un acuse de recibo de la suscripción.

[0275] En la etapa 6a (véase mensajería 424), en una realización, la entidad de soporte intermedio 202 envía una solicitud de suscripción a la función de gestión de suscripciones del RIC 406 (o servicios de habilitación de API 404) para suscribirse para consumir API relacionadas con Control/E2 relacionadas con el segmento. La solicitud de suscripción también puede incluir el nivel de exposición para los servicios de control (por ejemplo, permisos, granularidad de los informes o similares). En la etapa 6b (véase mensajería 426), en una realización, el RIC 406, por ejemplo, la función de gestión de suscripción u otra función RIC, envía un ACK para proporcionar un acuse de recibo de la suscripción.

[0277] En la etapa 7 (véase el bloque 428), en una realización, la entidad de software intermedio 202, tras suscribirse a los servicios, determina la correspondencia de los servicios proporcionados con uno o más SDK/API. Los SDK/API dependientes de la plataforma también pueden incluir API de servicio relacionadas con servicios proporcionados por soporte intermedio de valor añadido.

[0279] En la etapa 8 (véase el bloque 430), en una realización, la entidad de software intermedio 202 configura un SDK/API independiente de la plataforma basándose en los SDK/API dependientes de la plataforma (a partir de la etapa 4) y en los siguientes criterios:

[0281] - impacto en la complejidad/latencia en general para simplificar la API;

[0282] - impactos a nivel de protocolo;

[0283] - requisitos de aplicación para la portabilidad;

[0284] - requisitos relacionados con la loncha para las capacidades de exposición;

[0285] - aspectos de seguridad con respecto al tipo de xApp (por ejemplo, de confianza o no). La topología de la red puede estar oculta;

[0286] - capacidades de la aplicación final;

[0287] - dependencias entre servicios (para ello puede ser necesario combinar servicios en una nueva API. Un ejemplo puede ser un MnS, y un servicio de control relacionado con el aseguramiento del segmento RAN. En este caso, la xApp puede consumir una API simplificada que combine ambos servicios);

[0288] - SLA/SLS

[0289] - requisitos de QoS o QoE para las sesiones de aplicación (por UE o grupo de UE o un área topológica/geográfica/servicio)

[0290] El resultado de este proceso en la entidad de software intermedio 202 será un SDK/API independiente de la plataforma con toda la información necesaria y la correspondencia con las API dependientes de la plataforma. Puede ser en forma de una tabla:

[0291]

[0294] En la etapa 9 (véase la mensajería 432), en una realización, la entidad de software intermedio 202 publica la API independiente de la plataforma para su uso por las aplicaciones finales.

[0296] En la etapa 10 (véase la mensajería 410), en una realización, en respuesta a un evento de activación (véase el bloque 434), el evento de activación es capturado por los productores de a P i (por ejemplo, plano de control, plano de gestión, SEAL, o similares) o el lado de la aplicación (reubicación del servidor de aplicaciones a una EDN/DN diferente, movilidad del UE a una EDN diferente, cambio de comportamiento de la aplicación, o similares) o cualquier otro evento relacionado con la API capturado por los servicios de habilitación de API 404 (por ejemplo, fallo, falta de disponibilidad, o similares).

[0298] La entidad de software intermedio 202 procesa el evento de activación y comprueba y actualiza la asignación de las API de servicio, que consisten en el SDK/ API dependiente de la plataforma, a las SDK/ API de portabilidad (independientes de la plataforma). El objetivo es mantener inalteradas las API de portabilidad (independientes de la plataforma), de modo que el vertical no se entere de ningún cambio. Para ello, puede ser necesario actualizar las API de los servicios. En esta etapa, la entidad de software intermedio 202 puede proporcionar soporte adicional proporcionando servicios de valor añadido para hacer frente a la falta de disponibilidad de consumo de algunos servicios.

[0300] La figura 5 representa un diagrama de secuencia de mensajes 500 para una tercera realización de la solución propuesta dirigida a la configuración y aprovisionamiento de la asignación de un nuevo tipo de interfaz de programación de aplicaciones ("API") (por ejemplo, una API independiente de la plataforma, una API de segmento de red y/o una API de portabilidad, descritas a continuación) a las implementaciones dependientes de la plataforma de las API de plano de gestión o control para O-RAN.

[0302] En la etapa 0 (ver bloque 508), el SMO 402 determina el parámetro de servicio, por ejemplo, el nivel de exposición de servicio para la NSI basado en los requerimientos de segmento de cliente.

[0304] En la etapa 1 (ver mensajería 510), en una realización, el SMO 402 (por ejemplo, el NSP relevante MD) envía a la entidad de soporte intermedio 202, que puede ser una función de habilitación de segmento como una xApp, rApp, o función RIC, la información de suscripción a la aplicación a segmento así como la exposición de capacidad de servicio acordada para la NSI(s) suscrita(s). Esta etapa también puede incluir una instrucción/solicitud para que la entidad de soporte intermedio 502 gestione la configuración y exposición de la API de segmento/servicio.

[0306] En la etapa 2a (ver mensajería 512), en una realización, la entidad de soporte intermedio 202 envía una petición al dominio(s) de gestión implicados para obtener el estado de la API disponible y las capacidades relacionadas con los servicios de gestión de segmento (por ejemplo, monitorización NSSI/NSl, modificación, o similares). Los dominios de gestión implicados son conocidos por la entidad de software intermedio 202 desde la etapa 1 (basándose en la exposición de la capacidad de servicio). Este mensaje incluye al menos uno de los siguientes parámetros:

[0308] - ID de soporte intermedio (ID de xApp/rApp)

[0309] - Solicitud de nombre API/Ur I

[0310] - Solicitud de versión de la API

[0311] - Solicitud de formato de datos (por ejemplo, protocolo de serialización)

[0312] - Solicitud de funciones soportadas por la API relacionadas con la sección #X o el servicio #Y

[0313] - Requisito de nivel de exposición para las funciones soportadas

[0314] - Consulta del estado de la API

[0315] - Puntos de terminación de la API

[0316] - Validez temporal

[0317] En la etapa 2b (ver mensajería 514), en una realización, el dominio de gestión proporciona el estado de la API y las capacidades de gestión relacionadas con los segmentos. Este mensaje incluye al menos uno de los siguientes parámetros:

[0319] - MD ID, MnS ID

[0320] - Lista de nombres de API, tipos y formatos de datos

[0321] - Funciones soportadas por la API relacionadas con el segmento/servicio

[0322] - Nivel de exposición de las funciones soportadas

[0323] - Informe de estado de la API

[0325] En la etapa 3a (véase la mensajería 516), en una realización, la entidad de soporte intermedio 202 envía una solicitud a los servicios de habilitación de API 404 o a la función afectada de control/relacionada con E2504 para obtener el estado disponible de la API y las capacidades relacionadas con los servicios de control relacionados con las segmentos que pueden exponerse (por ejemplo, suscripciones a segmentos, análisis de segmentos de red, eventos de monitorización de QoS/red, y/o similares). Los servicios de habilitación de API 404, así como la API de habilitación, son conocidos por la entidad de soporte intermedio 202 desde la etapa 1 (basándose en la exposición de la capacidad de servicio). Este mensaje incluye al menos uno de los siguientes parámetros:

[0327] - ID de soporte intermedio / ID de xApp o rApp

[0328] - Solicitud de nombre / URI de API relacionada con E2 o de Control

[0329] - Solicitud de una versión de la API de control o relacionada con E2

[0330] - Solicitud de formato de datos (por ejemplo, protocolo de serialización)

[0331] - Solicitud de funciones soportadas por la API de control o relacionadas con E2 en relación con la sección #X o el servicio #Y

[0332] - Requisito de nivel de exposición para las funciones soportadas

[0333] - Consulta de estado relacionada con E2 o Control

[0334] - Puntos de terminación relacionados con E2 o Control

[0335] - Validez temporal

[0337] En la etapa 3b (véase la mensajería 518), en una realización, los servicios de habilitación de API 404 (o la funcionalidad 504 relacionada con el control/E2 pertinente) proporcionan el estado de la API y las capacidades de exposición de control relacionadas con el segmento. Este mensaje incluye al menos uno de los siguientes parámetros:

[0338] - Función RIC ID

[0339] - Lista de nombres de API, tipos y formatos de datos

[0340] - Funciones soportadas por la API relacionadas con el segmento/servicio

[0341] - Nivel de exposición de las funciones soportadas

[0342] - Informe de estado de la API

[0344] En la etapa 4 (véase el bloque 520), en una realización, la entidad de software intermedio 202 asigna la NSI a una lista de API de servicio basándose en los requisitos de exposición de capacidad de servicio para la NSI y la disponibilidad de API de servicio. En determinadas implementaciones, puede tratarse de una tabla de asignación.

[0346] En la etapa 5a (véase la mensajería 522), en una realización, la entidad de soporte intermedio 202 envía una solicitud de suscripción a los servicios de gestión afectados 504 del dominio(s) de gestión para suscribirse para consumir las API de servicio MnS relacionadas con el segmento. La solicitud de suscripción también puede incluir el nivel de exposición para los servicios de gestión (por ejemplo, permisos, granularidad de los informes o similares). Esta suscripción también se puede hacer a través de los servicios de habilitación de API 404/API de habilitación. En la etapa 5b (véase la mensajería 524), en una realización, el MnS del dominio de gestión (o el servicio de habilitación de API 404) envía un ACK para proporcionar un acuse de recibo de la suscripción.

[0348] En la etapa 6a (véase la mensajería 526), en una realización, la entidad de soporte intermedio 202 envía una solicitud de suscripción a una función de gestión 504, por ejemplo, una función de gestión de suscripciones de un RIC (o los servicios de habilitación de API 404) para suscribirse para consumir API relacionadas con Control / E2 relacionadas con el segmento. La solicitud de suscripción también puede incluir el nivel de exposición para los servicios de control (por ejemplo, permisos, granularidad de los informes y/o similares). En la etapa 6b (ver mensajería 528), en una realización, la función de gestión 504, por ejemplo, la función de gestión de suscripción, o cualquier otra función RIC, envía un ACK para proporcionar un acuse de recibo de la suscripción.

[0350] [0123] En la etapa 7 (véase el bloque 530), en una realización, la entidad de software intermedio 202, tras suscribirse a los servicios, configura la asignación de los servicios proporcionados a una o más API de segmento para uno o más segmentos. La asignación de la API de segmento a los servicios incluye el nombre/identificación de la API de segmento, los nombres de API de servicio encerrados, URI, versiones de API, información de protocolo, puntos de terminación por API, tipos de API incluidos, métodos de comunicación (por ejemplo, solicitud-respuesta o suscribir-notificar), validez de tiempo, y/o similares. Las API de segmento también pueden incluir API de servicio relacionadas con servicios proporcionados por soporte intermedio de valor añadido. En esta etapa, la información de la API de segmento, y las API encerradas, se almacenan en la entidad soporte intermedio 202.

[0352] En la etapa 8 (véase la mensajería 532), en una realización, la entidad de soporte intermedio 202 publica las API de segmentos para que las utilicen las aplicaciones finales.

[0354] En la etapa 9 (ver mensajería 536), en una realización, un evento de activación (ver bloque 534) es detectado y capturado por los productores de API O-RAN 504, 506 o la funcionalidad de habilitación de API 404 o el lado de la aplicación (por ejemplo, reubicación del servidor de aplicaciones a una plataforma RIC diferente, movilidad de UE, cambio de comportamiento de la aplicación, y/o similares) o cualquier otro evento relacionado con API capturado por los servicios de habilitación de API 404 (por ejemplo, falla, no disponibilidad).

[0356] La entidad de soporte intermedio 202, en una realización, procesa el evento de activación y comprueba y actualiza la asignación de las API de RIC de O-RAN a las API de segmento. El objetivo es mantener inalteradas las API de segmento, de modo que el vertical no se entere de ningún cambio. Para ello, es posible que sea necesario actualizar las API de O-RAN RIC. En esta etapa, la entidad de software intermedio 202 puede proporcionar soporte adicional proporcionando servicios de valor añadido para hacer frente a la falta de disponibilidad de consumo de algunos servicios.

[0358] En la etapa 10 (véase la mensajería 538), en una realización, la entidad de software intermedio 202 vuelve a publicar las API de segmento, si es necesario.

[0360] La figura 6 muestra un equipo de usuario 600 que puede utilizarse para configurar interfaces de programación de aplicaciones independientes de la plataforma, de acuerdo con las realizaciones de la divulgación. En varias realizaciones, el aparato de equipo de usuario 600 se utiliza para implementar una o más de las soluciones descritas anteriormente. El aparato de equipo de usuario 600 puede implementarse en un dispositivo vertical, como la unidad remota 105, el dispositivo cliente 201 y/o el dispositivo vertical 301, descritos anteriormente. Además, el aparato de equipo de usuario 600 puede incluir un procesador 605, una memoria 610, un dispositivo de entrada 615, un dispositivo de salida 620 y un transceptor 625. En algunas realizaciones, el dispositivo de entrada 615 y el dispositivo de salida 620 se combinan en un único dispositivo, como una pantalla táctil. En ciertas realizaciones, el aparato de equipo de usuario 600 puede no incluir ningún dispositivo de entrada 615 y/o dispositivo de salida 620. En varias realizaciones, el aparato de equipo de usuario 600 puede incluir uno o más de: el procesador 605, la memoria 610, y el transceptor 625, y puede no incluir el dispositivo de entrada 615 y/o el dispositivo de salida 620.

[0362] Tal como se representa, el transceptor 625 incluye al menos un transmisor 630 y al menos un receptor 635. Aquí, el transceptor 625 se comunica con una o más unidades remotas 105. Además, el transceptor 625 puede soportar al menos una interfaz de red 640. En algunas realizaciones, el transceptor 625 soporta una primera interfaz (por ejemplo, interfaz Uu) para comunicarse con una o más unidades base en una RAN, una segunda interfaz (por ejemplo, interfaz N1) para comunicarse con una AMF, y una tercera interfaz para comunicarse con un sistema TSN.

[0364] El procesador 605, en una realización, puede incluir cualquier controlador conocido capaz de ejecutar instrucciones legibles por ordenador y/o capaz de realizar operaciones lógicas. Por ejemplo, el procesador 605 puede ser un microcontrolador, un microprocesador, una unidad central de procesamiento ("CPU"), una unidad de procesamiento gráfico ("GPU"), una unidad de procesamiento auxiliar, una FPGa o un controlador programable similar. En algunas realizaciones, el procesador 605 ejecuta instrucciones almacenadas en la memoria 610 para llevar a cabo los métodos y rutinas descritos en el presente documento. El procesador 605 está acoplado comunicativamente a la memoria 610, al dispositivo de entrada 615, al dispositivo de salida 620 y al transceptor 625. En varias realizaciones, el procesador 605 controla el aparato de equipo de usuario 600 para implementar los comportamientos de UE, comportamientos de dispositivo cliente y/o comportamientos de dispositivo vertical descritos anteriormente.

[0366] El aparato de equipo de usuario 600 soporta una o más interfaces de aplicación 645. Cada interfaz de aplicación 645 soporta la comunicación entre instancias de aplicación que se ejecutan en el equipo de usuario 600 y/o soporta la comunicación con una instancia de aplicación externa, por ejemplo, que se ejecuta en un dispositivo de red o en un UE. En algunas realizaciones, la(s) interfaz(es) de aplicación 645 incluye(n) un conjunto de funciones y procedimientos que permiten a las aplicaciones que se ejecutan en el aparato de equipo de usuario 600 acceder a datos y características de otras aplicaciones, servicios o sistemas operativos. Por ejemplo, un cliente SEAL que se ejecuta en el equipo de usuario 600 puede utilizar una interfaz de aplicación 645 para comunicarse con un servidor SEAL. Como otro ejemplo, una aplicación V2X que se ejecuta en el aparato de equipo de usuario 600 puede utilizar una interfaz de aplicación 645 para comunicarse con un servidor de aplicaciones V2X.

[0368] La memoria 610, en una realización, es un medio de almacenamiento legible por ordenador. En algunas realizaciones, la memoria 610 incluye medios de almacenamiento informático volátiles. Por ejemplo, la memoria 610 puede incluir una RAM, incluyendo RAM dinámica ("DRAM"), RAM dinámica síncrona ("SDRAM"), y/o RAM estática ("SRAM"). En algunas realizaciones, la memoria 610 incluye medios de almacenamiento informático no volátiles. Por ejemplo, la memoria 610 puede incluir una unidad de disco duro, una memoria flash o cualquier otro dispositivo de almacenamiento informático no volátil adecuado. En algunas realizaciones, la memoria 610 incluye medios de almacenamiento informático tanto volátiles como no volátiles.

[0369] En algunas realizaciones, la memoria 610 almacena datos relacionados con la configuración de interfaces de programación de aplicaciones independientes de la plataforma. Por ejemplo, la memoria 610 puede almacenar requisitos de servicio, asignaciones de API, requisitos de aplicación, parámetros relacionados y similares. En ciertas realizaciones, la memoria 610 también almacena código de programa y datos relacionados, como un sistema operativo u otros algoritmos de controlador operando en la unidad remota 105.

[0371] El dispositivo de entrada 615, en una realización, puede incluir cualquier dispositivo de entrada de ordenador conocido, incluyendo un panel táctil, un botón, un teclado, un lápiz óptico, un micrófono, o similares. En algunas realizaciones, el dispositivo de entrada 615 puede estar integrado con el dispositivo de salida 620, por ejemplo, como una pantalla táctil o una pantalla táctil similar. En algunas realizaciones, el dispositivo de entrada 615 incluye una pantalla táctil de tal forma que el texto puede introducirse utilizando un teclado virtual mostrado en la pantalla táctil y/o escribiendo a mano en la pantalla táctil. En algunas realizaciones, el dispositivo de entrada 615 incluye dos o más dispositivos diferentes, como un teclado y un panel táctil.

[0373] El dispositivo de salida 620, en una realización, está diseñado para emitir señales visuales, audibles y/o hápticas. En algunas realizaciones, el dispositivo de salida 620 incluye una pantalla controlable electrónicamente o un dispositivo de visualización capaz de emitir datos visuales a un usuario. Por ejemplo, el dispositivo de salida 620 puede incluir, entre otros, una pantalla LCD, una pantalla LED, una pantalla OLED, un proyector o un dispositivo de visualización similar capaz de mostrar imágenes, texto o similares a un usuario. Como otro ejemplo, no limitante, el dispositivo de salida 620 puede incluir una pantalla portátil separada, pero acoplada comunicativamente al resto del equipamiento del usuario 600, como un reloj inteligente, gafas inteligentes, una pantalla de visualización frontal o similar. Además, el dispositivo de salida 620 puede ser un componente de un teléfono inteligente, un asistente digital personal, un televisor, un ordenador de mesa, un ordenador portátil, un ordenador personal, el salpicadero de un vehículo o similares.

[0375] En ciertas realizaciones, el dispositivo de salida 620 incluye uno o más altavoces para producir sonido. Por ejemplo, el dispositivo de salida 620 puede producir una alerta o notificación audible (por ejemplo, un pitido o un timbre). En algunas realizaciones, el dispositivo de salida 620 incluye uno o más dispositivos hápticos para producir vibraciones, movimiento u otra retroalimentación háptica. En algunas realizaciones, todo o parte del dispositivo de salida 620 puede estar integrado con el dispositivo de entrada 615. Por ejemplo, el dispositivo de entrada 615 y el dispositivo de salida 620 pueden formar una pantalla táctil o una pantalla táctil similar. En otras realizaciones, el dispositivo de salida 620 puede estar localizado cerca del dispositivo de entrada 615.

[0377] El transceptor 625 opera bajo el control del procesador 605 para transmitir mensajes, datos y otras señales y también para recibir mensajes, datos y otras señales. Por ejemplo, el procesador 605 puede activar selectivamente el transceptor (o porciones de este) en momentos determinados para enviar y recibir mensajes.

[0379] En diversas realizaciones, el transceptor 625 está configurado para comunicarse con la(s) red(es) de acceso 3GPP y/o la(s) red(es) de acceso no 3GPP. En algunas realizaciones, el transceptor 625 implementa la funcionalidad de módem para la(s) red(es) de acceso 3GPP y/o la(s) red(es) de acceso no 3GPP. En una realización, el transceptor 625 implementa múltiples transceptores lógicos utilizando diferentes protocolos de comunicación o pilas de protocolos, a la vez que utiliza hardware físico común.

[0381] En una realización, el transceptor 625 incluye un primer par transmisor/receptor utilizado para comunicarse con una red de comunicaciones móviles a través de espectro radioeléctrico con licencia y un segundo par transmisor/receptor utilizado para comunicarse con una red de comunicaciones móviles a través de espectro radioeléctrico sin licencia. En determinadas realizaciones, el primer par transmisor/receptor utilizado para comunicarse con una red de comunicaciones móviles a través del espectro radioeléctrico con licencia y el segundo par transmisor/receptor utilizado para comunicarse con una red de comunicaciones móviles a través del espectro radioeléctrico sin licencia pueden combinarse en una única unidad transceptora, por ejemplo un único chip que realice funciones para su uso tanto con el espectro radioeléctrico con licencia como sin licencia. En algunas realizaciones, el primer par transmisor/receptor y el segundo par transmisor/receptor pueden compartir uno o más componentes de hardware. Por ejemplo, ciertos transceptores 625, transmisores 630 y receptores 635 pueden implementarse como componentes físicamente separados que acceden a un recurso de hardware y/o recurso de software compartido, como por ejemplo, la interfaz de red 640.

[0383] El transceptor 625 puede incluir uno o más transmisores 630 y uno o más receptores 635. Aunque se ilustra un número específico de transmisores 630 y receptores 635, el aparato de equipo de usuario 600 puede tener cualquier número adecuado de transmisores 630 y receptores 635. Además, el (los) transmisor(es) 630 y el (los) receptor(es) 635 pueden ser cualquier tipo adecuado de transmisores y receptores. En ciertas realizaciones, el uno o más transmisores 630 y/o el uno o más receptores 635 pueden compartir hardware y/o circuitería de transceptor. Por ejemplo, uno o más transmisores 630 y/o uno o más receptores 635 pueden compartir antena(s), sintonizador(es) de antena, amplificador(es), filtro(s), oscilador(es), mezclador(es), modulador/demodulador(es), fuente de alimentación, y similares.

[0385] [0141] En diversas realizaciones, uno o más transmisores 630 y/o uno o más receptores 635 pueden implementarse y/o integrarse en un único componente de hardware, como un chip multitransceptor, un sistema-en-un-chip, un circuito integrado de aplicación específica ("ASIC"), u otro tipo de componente de hardware. En ciertas realizaciones, uno o más transmisores 630 y/o uno o más receptores 635 pueden implementarse y/o integrarse en un módulo multichip. En algunas realizaciones, otros componentes como la interfaz de red 640 u otros componentes/circuitos de hardware pueden integrarse con cualquier número de transmisores 630 y/o receptores 635 en un único chip. En dicha realización, los transmisores 630 y receptores 635 pueden configurarse lógicamente como un transceptor 625 que utiliza una señal de control más común o como transmisores modulares 630 y receptores 635 implementados en el mismo chip de hardware o en un módulo multichip. En ciertas implementaciones, el transceptor 625 puede implementar un módem 3GPP (por ejemplo, para comunicarse a través de redes de acceso NR o LTE) y un módem no 3GPP (por ejemplo, para comunicarse a través de Wi-Fi u otras redes de acceso no 3GPP).

[0387] La figura 7 representa una realización de un aparato de equipamiento de red 700 que puede utilizarse para configurar interfaces de programación de aplicaciones independientes de la plataforma, de acuerdo con realizaciones de la divulgación. En algunas realizaciones, el aparato de equipamiento de red 700 puede ser una realización de una entidad de aplicación de confianza (por ejemplo, soporte intermedio), como el servidor VAL 151, el servidor SEAL 155, el servidor de habilitación perimetral 145, el servidor de habilitación 213, el servidor SEAL/NSE 307, y/o el servidor VAL 309. Además, el aparato de equipamiento de red 700 puede incluir un procesador 705, una memoria 710, un dispositivo de entrada 715, un dispositivo de salida 720, un transceptor 725. En algunas realizaciones, el dispositivo de entrada 715 y el dispositivo de salida 720 se combinan en un único dispositivo, como una pantalla táctil. En ciertas realizaciones, el aparato de equipamiento de red 700 no incluye ningún dispositivo de entrada 715 y/o dispositivo de salida 720.

[0389] Tal como se representa, el transceptor 725 incluye al menos un transmisor 730 y al menos un receptor 735. Aquí, el transceptor 725 se comunica con una o más unidades remotas 105. Además, el transceptor 725 puede soportar al menos una interfaz de red 740, como las interfaces Nl, N2 y N3. En algunas realizaciones, el transceptor 725 soporta una primera interfaz para comunicarse con una o más funciones de red en una red central móvil (por ejemplo, un 5GC y/o EPC), una segunda interfaz para comunicarse con un sistema TSN, y una tercera interfaz para comunicarse con una unidad remota (por ejemplo, UE).

[0391] El procesador 705, en una realización, puede incluir cualquier controlador conocido capaz de ejecutar instrucciones legibles por ordenador y/o capaz de realizar operaciones lógicas. Por ejemplo, el procesador 705 puede ser un microcontrolador, un microprocesador, una unidad central de procesamiento ("CPU"), una unidad de procesamiento gráfico ("GPU"), una unidad de procesamiento auxiliar, una matriz de puertas programables en campo ("FPGA") o un controlador programable similar. En algunas realizaciones, el procesador 705 ejecuta instrucciones almacenadas en la memoria 710 para llevar a cabo los métodos y rutinas descritos en el presente documento. El procesador 705 está acoplado comunicativamente a la memoria 710, al dispositivo de entrada 715, al dispositivo de salida 720 y al transceptor 725. En varias realizaciones, el procesador 705 controla el equipo de usuario 700 para implementar los comportamientos de red descritos anteriormente.

[0393] A través del transceptor 725, en una realización, el procesador 705 recibe un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica, en el que el sistema de comunicación inalámbrica comprende una o más plataformas. El procesador 705, en ciertas realizaciones, determina una interfaz de programación de aplicaciones ("API") independiente de la plataforma basándose en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica.

[0395] El procesador 705, en una realización, publica la API independiente de la plataforma a un invocador de API para su uso por aplicaciones finales a través de diferentes sistemas de comunicación inalámbrica. En realizaciones adicionales, el procesador 705 se registra con el al menos un servicio de red para obtener acceso para invocar la al menos una API de servicio. En algunas realizaciones, el procesador 705 determina la API independiente de la plataforma basándose en un asignación de al menos una API dependiente de la plataforma.

[0397] En una realización, el procesador 705 detecta un evento de activación asociado con la API dependiente de la plataforma y actualiza la API dependiente de la plataforma en respuesta al evento de activación mientras asegura la compatibilidad con la API independiente de la plataforma. En algunas realizaciones, el evento de activación incluye una movilidad de un equipo de usuario ("UE"), una reubicación de un servidor de aplicaciones a un sistema de comunicación inalámbrica diferente, una indisponibilidad de una API de servicio del al menos un servicio de red del sistema de comunicación inalámbrica, una indicación de alta carga y/o congestión real o esperada de la API, una reubicación de un cliente de aplicación del UE a una plataforma de comunicación inalámbrica diferente, una indicación de cambio de calidad de servicio de la red, una indicación de cambio de calidad de servicio y/o calidad de experiencia del UE, una indicación de cambio de contexto del UE y una indicación de fallo de la unidad de red.

[0399] En una realización, la asignación de la al menos una API de servicio para el al menos un servicio de red a la al menos una API dependiente de plataforma se basa en la determinación de una disponibilidad de las API de servicio mediante al menos una de las siguientes acciones: la recepción, por parte del procesador 705 a través de un transceptor 725, de un mensaje de siempre activo periódico del al menos un servicio de red asociado con la al menos una API de servicio y la comprobación, por parte del procesador 705, de un servicio de habilitación de API para el al menos un servicio de red.

[0400] En una realización, el parámetro de servicio del al menos un servicio de red es para una instancia de segmento de red ("NSI") de un cliente vertical del sistema de comunicación inalámbrica y la API dependiente de la plataforma comprende una API de kit de desarrollo de software que está personalizada para el cliente vertical.

[0402] En ciertas realizaciones, el procesador 705 envía, a través del transceptor 725, una solicitud de un estado de disponibilidad de una API de gestión y capacidades relacionadas con los servicios de gestión de segmentos para la NSI a un dominio de gestión. La solicitud incluye al menos uno de los siguientes elementos: un ID de soporte intermedio, una solicitud de nombre de API, una solicitud de URI de API, una solicitud de versión de API, una solicitud de formato de datos, una solicitud de características soportadas por la API relacionadas con al menos una de las partes y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta de estado de API, puntos de finalización de API y un tiempo de validez de la solicitud.

[0404] En una realización, el procesador 705 recibe, a través del transceptor 725, un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros: MD ID, MnS ID, lista de nombres, tipos y formatos de datos de la API, funciones soportadas por la API relacionadas con al menos uno de los segmentos y el servicio, nivel de exposición de las funciones soportadas e informe de estado de la API. En una realización, el procesador 705, a través del transceptor 725, envía a un plano de control una solicitud de estado de disponibilidad de una API de plano de control y de capacidades relacionadas con los servicios de control relacionados con el segmento para la NSI. La solicitud incluye al menos uno de los siguientes elementos: un ID de soporte intermedio, una solicitud del nombre de la API en dirección norte, una solicitud del URI en dirección norte, una solicitud de la versión de la API en dirección norte, una solicitud del formato de los datos, una solicitud de las características soportadas por la API en dirección norte relacionadas con al menos uno de los segmentos y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta del estado de la API, puntos de terminación de la API y un tiempo de validez.

[0406] En una realización, el procesador 705 recibe, a través del transceptor 725, un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros: un identificador NEF, una lista de nombres, tipos y formatos de datos de API, una API soportando características relacionadas con al menos uno de los segmentos y el servicio, un nivel de exposición de las características soportadas y un informe de estado de API.

[0408] En una realización, el procesador 705, a través del transceptor 725, envía a una función relacionada con E2 una solicitud de un estado de disponibilidad de la API de la función relacionada con E2 y de capacidades relacionadas con servicios de control relacionados con el segmento para la NSI. La solicitud incluye uno de los ID de soporte intermedio, un ID de xApp y un ID de rApp, una solicitud de nombre de API relacionada con E2, una solicitud de URI relacionada con E2, una solicitud de versión relacionada con E2, una solicitud de formato de datos, una solicitud de características soportadas relacionadas con E2 relacionadas con al menos una de un segmento y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta de estado relacionada con E2, unos puntos de terminación relacionados con E2 y una validez temporal.

[0410] En una realización, el procesador 705, a través del transceptor 725, recibe un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros: ID de la función RIC, lista de nombres, tipos y formatos de datos de la API, características soportadas por la API relacionadas con al menos uno de los segmentos y el servicio, nivel de exposición de las características soportadas e informe de estado de la API.

[0412] En una realización, la asignación de la al menos una API de servicio para el al menos una NSI a la al menos una API dependiente de la plataforma se realiza coincidiendo el parámetro de servicio del al menos un servicio de red con al menos un parámetro de capacidad para la NSI. En determinadas realizaciones, la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para la NSI comprende al menos uno de los siguientes elementos: un nombre/identificación de API independiente de la plataforma, nombres de API de servicio encerrados, URI, versiones de API, información de protocolo, puntos de terminación por API, tipos de API, métodos de comunicación y validez temporal.

[0414] En una realización, el procesador 705, a través del transceptor 725, solicita el parámetro de servicio a un orquestador de gestión de servicios ("SMO") para el al menos un servicio de red. El parámetro de servicio puede basarse en al menos uno de un tipo de al menos un servicio de red y una autorización para acceder al al menos un servicio de red. En algunas realizaciones, el procesador 705, a través del transceptor 725, recibe un mensaje del SMO comprendiendo el parámetro de servicio para el al menos un servicio de red para al menos uno de un servicio, un segmento, y un tipo de aplicación.

[0416] En una realización, al menos un servicio de red comprende una aplicación externa ("xApp"). En algunas realizaciones, la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para el al menos un servicio de red comprende al menos uno de un impacto en la complejidad/latencia en general para simplificar la API, impactos a nivel de protocolo, requisitos de aplicación para la portabilidad, requisitos relacionados con las segmentos para las capacidades de exposición, aspectos de seguridad relacionados con un tipo de función de red, capacidades de una aplicación final, dependencias entre servicios y un acuerdo de nivel de servicio ("SLA").

[0417] El aparato de equipamiento de red 700 soporta una o más interfaces de aplicación 745. Cada interfaz de aplicación 745 soporta la comunicación entre instancias de aplicación que se ejecutan en el equipo de usuario 700 y/o soporta la comunicación con una instancia de aplicación externa, por ejemplo, que se ejecuta en un dispositivo de red o en un UE. En algunas realizaciones, la(s) interfaz(es) de aplicación 745 incluye(n) un conjunto de funciones y procedimientos que permiten a las aplicaciones que se ejecutan en el aparato de equipamiento de red 700 acceder a datos y características de otras aplicaciones, servicios o sistemas operativos. Como se describe adicionalmente a continuación, un cliente 107 de SEAL que se ejecuta en el aparato 700 del equipamiento de red puede utilizar una interfaz de aplicación 745 para comunicarse con un servidor 155 de SEAL. Como otro ejemplo, una aplicación VAL que se ejecuta en el aparato de equipamiento de red 700 puede utilizar una interfaz de aplicación 745 para comunicarse con un servidor de aplicaciones VAL 151.

[0419] La memoria 710, en una realización, es un medio de almacenamiento legible por ordenador. En algunas realizaciones, la memoria 710 incluye medios de almacenamiento informático volátiles. Por ejemplo, la memoria 710 puede incluir una RAM, incluyendo RAM dinámica ("DRAM"), RAM dinámica síncrona ("SDRAM"), y/o RAM estática ("SRAM"). En algunas realizaciones, la memoria 710 incluye medios de almacenamiento informático no volátiles. Por ejemplo, la memoria 710 puede incluir una unidad de disco duro, una memoria flash o cualquier otro dispositivo de almacenamiento informático no volátil adecuado. En algunas realizaciones, la memoria 710 incluye medios de almacenamiento informático tanto volátiles como no volátiles.

[0421] En algunas realizaciones, la memoria 710 almacena datos para configurar interfaces de programación de aplicaciones independientes de la plataforma, por ejemplo almacenando requisitos de servicio, requisitos de QoS, requisitos de QoE, asignaciones, requisitos de aplicación, parámetros relacionados y similares. En ciertas realizaciones, la memoria 710 también almacena código de programa y datos relacionados, como un sistema operativo ("OS") u otros algoritmos de controlador operando en el aparato de equipamiento de red 700 y una o más aplicaciones de software.

[0423] El dispositivo de entrada 715, en una realización, puede incluir cualquier dispositivo de entrada de ordenador conocido, incluyendo un panel táctil, un botón, un teclado, un lápiz óptico, un micrófono, o similares. En algunas realizaciones, el dispositivo de entrada 715 puede estar integrado con el dispositivo de salida 720, por ejemplo, como una pantalla táctil o una pantalla táctil similar. En algunas realizaciones, el dispositivo de entrada 715 incluye una pantalla táctil de tal forma que el texto puede introducirse utilizando un teclado virtual mostrado en la pantalla táctil y/o escribiendo a mano en la pantalla táctil. En algunas realizaciones, el dispositivo de entrada 715 incluye dos o más dispositivos diferentes, como un teclado y un panel táctil.

[0425] El dispositivo de salida 720, en una realización, puede incluir cualquier pantalla o dispositivo de visualización conocido controlable electrónicamente. El dispositivo de salida 720 puede estar diseñado para emitir señales visuales, audibles y/o hápticas. En algunas realizaciones, el dispositivo de salida 720 incluye una pantalla electrónica capaz de mostrar datos visuales a un usuario. Por ejemplo, el dispositivo de salida 720 puede incluir, entre otros, una pantalla LCD, una pantalla LED, una pantalla OLED, un proyector o un dispositivo de visualización similar capaz de mostrar imágenes, texto o similares a un usuario. Como otro ejemplo no limitativo, el dispositivo de salida 720 puede incluir una pantalla para llevar puesta, como un reloj inteligente, unas gafas inteligentes, una pantalla de visualización frontal o similar. Además, el dispositivo de salida 720 puede ser un componente de un teléfono inteligente, un asistente digital personal, un televisor, un ordenador de mesa, un ordenador portátil, un ordenador personal, el salpicadero de un vehículo o similares.

[0427] En ciertas realizaciones, el dispositivo de salida 720 incluye uno o más altavoces para producir sonido. Por ejemplo, el dispositivo de salida 720 puede producir una alerta o notificación audible (por ejemplo, un pitido o un timbre). En algunas realizaciones, el dispositivo de salida 720 incluye uno o más dispositivos hápticos para producir vibraciones, movimiento u otra retroalimentación háptica. En algunas realizaciones, todo o parte del dispositivo de salida 720 puede estar integrado con el dispositivo de entrada 715. Por ejemplo, el dispositivo de entrada 715 y el dispositivo de salida 720 pueden formar una pantalla táctil o una pantalla táctil similar. En otras formas de realización, todo o porciones del dispositivo de salida 720 pueden estar localizados cerca del dispositivo de entrada 715.

[0429] Como se ha comentado anteriormente, el transceptor 725 puede comunicarse con una o más unidades remotas y/o con una o más funciones de red que proporcionen acceso a una o más redes PLMN. El transceptor 725 también puede comunicarse con una o más funciones de red (por ejemplo, en la red básica móvil 120). El transceptor 725 opera bajo el control del procesador 705 para transmitir mensajes, datos y otras señales y también para recibir mensajes, datos y otras señales. Por ejemplo, el procesador 705 puede activar selectivamente el transceptor (o porciones de este) en momentos determinados para enviar y recibir mensajes.

[0431] El transceptor 725 puede incluir uno o más transmisores 730 y uno o más receptores 735. En ciertas realizaciones, el uno o más transmisores 730 y/o el uno o más receptores 735 pueden compartir hardware y/o circuitería de transceptor. Por ejemplo, uno o más transmisores 730 y/o uno o más receptores 735 pueden compartir antena(s), sintonizador(es) de antena, amplificador(es), filtro(s), oscilador(es), mezclador(es), modulador/demodulador(es), fuente de alimentación, y similares. En una realización, el transceptor 725 implementa múltiples transceptores lógicos utilizando diferentes protocolos de comunicación o pilas de protocolos, a la vez que utiliza hardware físico común.

[0432] La figura 8 representa una realización de un método 800 para configurar interfaces de programación de aplicaciones independientes de la plataforma, de acuerdo con realizaciones de la divulgación. En diversas realizaciones, el método 800 es ejecutado por una entidad de aplicación de confianza (por ejemplo, soporte intermedio), como el servidor VAL 151, el servidor SEAL 155, el servidor de habilitación perimetral 145, el servidor de habilitación 202, y/o similares, descritos anteriormente. En algunas realizaciones, el método 800 es ejecutado por un procesador, como un microcontrolador, un microprocesador, una CPU, una GPU, una unidad de procesamiento auxiliar, una FPGA, o similares.

[0434] El método 800 comienza y, en una realización, recibe 805 un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica. El sistema de comunicación inalámbrica puede incluir una o más plataformas. En una realización, el método 800 determina una interfaz de programación de aplicaciones ("API") independiente de la plataforma basándose en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica. El método 800 finaliza.

[0436] Se divulga aquí un primer aparato para configurar interfaces de programación de aplicaciones independientes de la plataforma, de acuerdo con las realizaciones de la divulgación. El primer aparato puede estar implementado por una entidad de aplicación de confianza (por ejemplo, soporte intermedio), como el servidor VAL 151, el servidor SEAL 155, el servidor de habilitación perimetral 145, el servidor de aplicación de confianza 202, y/o el aparato de red 700. El primer aparato comprende un transceptor que, en una realización, recibe un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica, en el que el sistema de comunicación inalámbrica comprende una o más plataformas. El primer aparato, en realizaciones adicionales, incluye un procesador que determina una interfaz de programación de aplicaciones ("API") independiente de la plataforma basándose en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica. El primer aparato, en otras realizaciones adicionales, incluye memoria u otro tipo de almacenamiento y puede comprender un repositorio para almacenar la API independiente de la plataforma determinada y la asignación a las API dependientes de la plataforma.

[0438] El procesador, en una realización, publica la API independiente de la plataforma a un invocador de API para su uso por aplicaciones finales a través de diferentes sistemas de comunicación inalámbrica. En una realización adicional, el procesador se registra con el al menos un servicio de red para obtener acceso para invocar la al menos una API de servicio. En algunas realizaciones, el procesador determina la API independiente de la plataforma basándose en una correspondencia con al menos una API dependiente de la plataforma.

[0440] En una realización, el procesador detecta un evento de activación asociado con la API dependiente de la plataforma y actualiza la API dependiente de la plataforma en respuesta al evento de activación al tiempo que garantiza la compatibilidad con la API independiente de la plataforma. En algunas realizaciones, el evento de activación incluye una movilidad de un equipo de usuario ("UE"), una reubicación de un servidor de aplicaciones a un sistema de comunicación inalámbrica diferente, una indisponibilidad de una API de servicio del al menos un servicio de red del sistema de comunicación inalámbrica, una indicación de alta carga y/o congestión real o esperada de la API, una reubicación de un cliente de aplicación del UE a una plataforma de comunicación inalámbrica diferente, una indicación de cambio de calidad de servicio de la red, una indicación de cambio de calidad de servicio y/o calidad de experiencia del UE, una indicación de cambio de contexto del UE y una indicación de fallo de la unidad de red.

[0442] En una realización, la asignación de la al menos una API de servicio para el al menos un servicio de red a la al menos una API dependiente de plataforma se basa en la determinación de una disponibilidad de las API de servicio mediante al menos una de las siguientes acciones: la recepción, por parte del transceptor, de un mensaje de siempre activo periódico del al menos un servicio de red asociado con la al menos una API de servicio y la comprobación, por parte del procesador, de un servicio de habilitación de API para el al menos un servicio de red.

[0444] En una realización, el parámetro de servicio del al menos un servicio de red es para una instancia de segmento de red ("NSI") de un cliente vertical del sistema de comunicación inalámbrica y la API dependiente de la plataforma comprende una API de kit de desarrollo de software que está personalizada para el cliente vertical.

[0446] En determinadas realizaciones, el transceptor envía una solicitud de estado de disponibilidad de una API de gestión y de capacidades relacionadas con los servicios de gestión de segmentos para la NSI a un dominio de gestión. La solicitud incluye al menos uno de los siguientes elementos: un ID de soporte intermedio, una solicitud de nombre de API, una solicitud de URI de API, una solicitud de versión de API, una solicitud de formato de datos, una solicitud de características soportadas por la API relacionadas con al menos una de las partes y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta de estado de<a>P<i>, puntos de finalización de API y un tiempo de validez de la solicitud.

[0448] [0174] En una realización, el transceptor recibe un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros: MD ID, MnS ID, lista de nombres, tipos y formatos de datos de la API, funciones soportadas por la API relacionadas con al menos uno de los segmentos y el servicio, nivel de exposición de las funciones soportadas e informe de estado de la API. En una realización, el transceptor envía a un plano de control una solicitud de estado de disponibilidad de una API de plano de control y de capacidades relacionadas con servicios de control relacionados con el segmento para la NSI. La solicitud incluye al menos uno de los siguientes elementos: un ID de soporte intermedio, una solicitud del nombre de la API en dirección norte, una solicitud del URI en dirección norte, una solicitud de la versión de la API en dirección norte, una solicitud del formato de los datos, una solicitud de las características soportadas por la API en dirección norte relacionadas con al menos uno de los segmentos y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta del estado de la API, puntos de terminación de la API y un tiempo de validez.

[0450] En una realización, el transceptor recibe un mensaje de respuesta que comprende al menos uno de los siguientes parámetros: un ID de NEF, una lista de nombres, tipos y formatos de datos de API, una API soportando características relacionadas con al menos uno de los segmentos y el servicio, un nivel de exposición de las características soportadas y un informe de estado de API.

[0452] En una realización, el transceptor envía a una función relacionada con E2 una solicitud de estado de disponibilidad de la API de la función relacionada con E2 y de las capacidades relacionadas con los servicios de control relacionados con segmento para la NSI. La solicitud incluye uno de los ID de soporte intermedio, un ID de xApp y un ID de rApp, una solicitud de nombre de API relacionada con E2, una solicitud de URI relacionada con E2, una solicitud de versión relacionada con E2, una solicitud de formato de datos, una solicitud de características soportadas relacionadas con E2 relacionadas con al menos una de un segmento y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta de estado relacionada con E2, unos puntos de terminación relacionados con E2 y una validez temporal.

[0454] En una realización, el transceptor recibe un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros: ID de la función RIC, lista de nombres, tipos y formatos de datos de la API, características soportadas por la API relacionadas con al menos uno de los segmentos y el servicio, nivel de exposición de las características soportadas e informe de estado de la API.

[0456] En una realización, la asignación de la al menos una API de servicio para el al menos una NSI a la al menos una API dependiente de la plataforma se realiza coincidiendo el parámetro de servicio del al menos un servicio de red con al menos un parámetro de capacidad para la NSI. En determinadas realizaciones, la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para la NSI comprende al menos uno de los siguientes elementos: un nombre/identificación de API independiente de la plataforma, nombres de API de servicio encerrados, URI, versiones de API, información de protocolo, puntos de terminación por API, tipos de API, métodos de comunicación y validez temporal.

[0458] En una realización, el transceptor solicita el parámetro de servicio a un orquestador de gestión de servicios ("SMO") para el al menos un servicio de red. El parámetro de servicio puede basarse en al menos uno de un tipo de al menos un servicio de red y una autorización para acceder al al menos un servicio de red. En algunas realizaciones, el transceptor, recibe un mensaje del SMO comprendiendo el parámetro de servicio para el al menos un servicio de red para al menos uno de un servicio, un segmento, y un tipo de aplicación.

[0460] En una realización, al menos un servicio de red comprende una aplicación externa ("xApp"). En algunas realizaciones, la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para el al menos un servicio de red comprende al menos uno de un impacto en la complejidad/latencia en general para simplificar la API, impactos a nivel de protocolo, requisitos de aplicación para la portabilidad, requisitos relacionados con las segmentos para las capacidades de exposición, aspectos de seguridad relacionados con un tipo de función de red, capacidades de una aplicación final, dependencias entre servicios y un acuerdo de nivel de servicio ("SLA").

[0462] Se divulga aquí un primer método para configurar interfaces de programación de aplicaciones independientes de la plataforma, de acuerdo con las realizaciones de la divulgación. El primer método puede ser ejecutado por una entidad de aplicación de confianza (por ejemplo, soporte intermedio), como el servidor VAL 151, el servidor de mensajería instantánea 153, el servidor de habilitación perimetral 145, el servidor de aplicación de confianza 202, y/o el aparato de red 700. El primer método incluye la recepción, en una realización, de un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica. El sistema de comunicación inalámbrica incluye una o más plataformas. El primer método, en realizaciones adicionales, incluye determinar una interfaz de programación de aplicaciones ("API") independiente de la plataforma basándose en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica.

[0464] El primer método, en una realización, publica la API independiente de la plataforma a un invocador de API para su uso por aplicaciones finales a través de diferentes sistemas de comunicación inalámbrica. En una realización adicional, el primer método se registra con el al menos un servicio de red para obtener acceso para invocar la al menos una API de servicio. En algunas realizaciones, el primer método determina la API independiente de la plataforma basándose en una correspondencia con al menos una API dependiente de la plataforma.

[0466] [0183] En una realización, el primer método detecta un evento de activación asociado con la API dependiente de la plataforma y actualiza la API dependiente de la plataforma en respuesta al evento de activación al tiempo que garantiza la compatibilidad con la API independiente de la plataforma. En algunas realizaciones, el evento de activación incluye una movilidad de un equipo de usuario ("UE"), una reubicación de un servidor de aplicaciones a un sistema de comunicación inalámbrica diferente, una indisponibilidad de una API de servicio del al menos un servicio de red del sistema de comunicación inalámbrica, una indicación de alta carga y/o congestión real o esperada de la API, una reubicación de un cliente de aplicación del UE a una plataforma de comunicación inalámbrica diferente, una indicación de cambio de calidad de servicio de la red, una indicación de cambio de calidad de servicio y/o calidad de experiencia del UE, una indicación de cambio de contexto del UE y una indicación de fallo de la unidad de red.

[0468] En una realización, la asignación de la al menos una API de servicio para el al menos un servicio de red a la al menos una API dependiente de la plataforma se basa en la determinación de una disponibilidad de las API de servicio mediante al menos una de las siguientes acciones: la recepción, por el primer método, de un mensaje de siempre activo periódico del al menos un servicio de red asociado con la al menos una API de servicio y la comprobación, por el primer método, de un servicio de habilitación de API para el al menos un servicio de red.

[0470] En una realización, el parámetro de servicio del al menos un servicio de red es para una instancia de segmento de red ("NSI") de un cliente vertical del sistema de comunicación inalámbrica y la API dependiente de la plataforma comprende una API de kit de desarrollo de software que está personalizada para el cliente vertical.

[0472] En ciertas realizaciones, el primer método envía una solicitud de estado de disponibilidad de una API de gestión y de capacidades relacionadas con los servicios de gestión de segmento para el NS I a un dominio de gestión. La solicitud incluye al menos uno de los siguientes elementos: un ID de soporte intermedio, una solicitud de nombre de API, una solicitud de URI de API, una solicitud de versión de API, una solicitud de formato de datos, una solicitud de características soportadas por la API relacionadas con al menos una de las partes y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta de estado de API, puntos de finalización de API y un tiempo de validez de la solicitud.

[0474] En una realización, el primer método recibe un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros: MD ID, MnS ID, lista de nombres, tipos y formatos de datos de la API, funciones soportadas por la API relacionadas con al menos uno de los segmentos y el servicio, nivel de exposición de las funciones soportadas e informe de estado de la API. En una realización, el primer método envía a un plano de control una solicitud de estado de disponibilidad de una API de plano de control y de capacidades relacionadas con los servicios de control relacionados con el segmento para la NSI. La solicitud incluye al menos uno de los siguientes elementos: un ID de soporte intermedio, una solicitud del nombre de la API en dirección norte, una solicitud del URI en dirección norte, una solicitud de la versión de la API en dirección norte, una solicitud del formato de los datos, una solicitud de las características soportadas por la API en dirección norte relacionadas con al menos uno de los segmentos y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta del estado de la API, puntos de terminación de la API y un tiempo de validez.

[0476] En una realización, el primer método recibe un mensaje de respuesta que comprende al menos uno de los siguientes parámetros: un identificador NEF, una lista de nombres, tipos y formatos de datos de la API, una API soportando características relacionadas con al menos uno de los segmentos y el servicio, un nivel de exposición de las características soportadas y un informe de estado de la API.

[0478] En una realización, el primer método envía a una función relacionada con E2 una solicitud de estado de disponibilidad de la API de la función relacionada con E2 y de las capacidades relacionadas con los servicios de control relacionados con el segmento para la NSI. La solicitud incluye uno de los ID de soporte intermedio, un ID de xApp y un ID de rApp, una solicitud de nombre de API relacionada con E2, una solicitud de u Ri relacionada con E2, una solicitud de versión relacionada con E2, una solicitud de formato de datos, una solicitud de características soportadas relacionadas con E2 relacionadas con al menos una de un segmento y un servicio, un requisito de nivel de exposición para las características soportadas, una consulta de estado relacionada con E2, unos puntos de terminación relacionados con E2 y una validez temporal.

[0480] En una realización, el primer método recibe un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros: ID de la función RIC, lista de nombres, tipos y formatos de datos de la API, características soportadas por la API relacionadas con al menos uno de los segmentos y el servicio, nivel de exposición de las características soportadas e informe de estado de la API.

[0482] En una realización, la asignación de la al menos una API de servicio para el al menos una NSI a la al menos una API dependiente de la plataforma se realiza coincidiendo el parámetro de servicio del al menos un servicio de red con al menos un parámetro de capacidad para la NSI. En determinadas realizaciones, la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para la NSI comprende al menos uno de los siguientes elementos: un nombre/identificación de API independiente de la plataforma, nombres de API de servicio encerrados, URI, versiones de API, información de protocolo, puntos de terminación por API, tipos de API, métodos de comunicación y validez temporal.

[0484] En una realización, el primer método solicita el parámetro de servicio a un orquestador de gestión de servicios ("SMO") para el al menos un servicio de red. El parámetro de servicio puede basarse en al menos uno de un tipo de al menos un servicio de red y una autorización para acceder al al menos un servicio de red. En algunas realizaciones, el primer método, recibe un mensaje del SMO comprendiendo el parámetro de servicio para el al menos un servicio de red para al menos uno de un servicio, un segmento, y un tipo de aplicación.

[0485] En una realización, al menos un servicio de red comprende una aplicación externa ("xApp"). En algunas realizaciones, la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para el al menos un servicio de red comprende al menos uno de un impacto en la complejidad/latencia en general para simplificar la API, impactos a nivel de protocolo, requisitos de aplicación para la portabilidad, requisitos relacionados con las segmentos para las capacidades de exposición, aspectos de seguridad relacionados con un tipo de función de red, capacidades de una aplicación final, dependencias entre servicios y un acuerdo de nivel de servicio ("SLA").

[0487] Las realizaciones pueden llevarse a la práctica de otras formas específicas. Las presentes realizaciones, por lo tanto, deben considerarse en todos los aspectos como ilustrativas y no restrictivas. Por lo tanto, el ámbito de la invención viene indicado por las reivindicaciones adjuntas y no por la descripción anterior.

Claims

1. REIVINDICACIONES

1. Un aparato (700) de comunicación inalámbrica, que comprende:

al menos una memoria (710); y

al menos un procesador (705) acoplado con al menos una memoria y configurado para hacer que el aparato: reciba (805) un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica, en el que el sistema de comunicación inalámbrica comprende una o más plataformas; y

determine (810) una interfaz de programación de aplicaciones, API, independiente de la plataforma, basada en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica.

2. El aparato de la reivindicación 1, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato publique la API independiente de la plataforma a un invocador de API para su uso por aplicaciones finales a través de diferentes sistemas de comunicación inalámbrica.

3. El aparato de la reivindicación 1, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato se registre con el al menos un servicio de red para obtener acceso para invocar la al menos una API de servicio.

4. El aparato de la reivindicación 1, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato determine la API independiente de la plataforma basándose en un asignación de al menos una API dependiente de la plataforma.

5. El aparato de la reivindicación 4, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato:

detecte un evento de activación asociado a la API dependiente de la plataforma; y

actualice la API dependiente de la plataforma en respuesta al evento de activación, garantizando al mismo tiempo la compatibilidad con la API independiente de la plataforma,

opcionalmente, en el que el evento de activación se selecciona del grupo comprendiendo:

movilidad de un equipo de usuario, UE;

reubicación de un servidor de aplicaciones en un sistema de comunicación inalámbrica diferente; indisponibilidad de una API de servicio del al menos un servicio de red del sistema de comunicación inalámbrica;

una indicación de carga elevada y/o congestión de la API real o prevista;

reubicación de un cliente de aplicación del UE en una plataforma de comunicación inalámbrica diferente; una indicación de cambio de calidad de servicio de la red;

una indicación de cambio de calidad de servicio y/o calidad de experiencia del UE;

una indicación de cambio de contexto del UE; y

una indicación de fallo de la unidad de red.

6. El aparato de la reivindicación 4, en el que la asignación de la al menos una API de servicio para el al menos un servicio de red a la al menos una API dependiente de plataforma se basa en la determinación de una disponibilidad de las API de servicio mediante al menos una de:

recibir un mensaje de siempre activo periódico del al menos un servicio de red asociado a la al menos una API de servicio; y

comprobar un servicio de habilitación de API para el al menos un servicio de red.

7. El aparato de la reivindicación 4, en el que:

el parámetro de servicio del al menos un servicio de red es para una instancia de segmento de red, NSI, de un cliente vertical del sistema de comunicación inalámbrica; y

la API dependiente de la plataforma comprende una API de kit de desarrollo de software personalizada para el cliente vertical.

8. El aparato de la reivindicación 7, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato envíe una solicitud de un estado de disponibilidad de una API de gestión y de capacidades relacionadas con servicios de gestión de segmentos para la NSI a un dominio de gestión, comprendiendo la solicitud al menos una de:

ID de soporte intermedio;

solicitud de nombre de API;

solicitud de API URI;

solicitud de versión de la API;

solicitud de formato de datos;

solicitud de funciones soportadas por la API relacionadas con al menos uno de los segmentos y un servicio;

requisito de nivel de exposición para las funciones soportadas;

consulta del estado de la API;

puntos de terminación de la API; y

tiempo de validez de la solicitud,

opcionalmente, donde el al menos un procesador está configurado adicionalmente para hacer que el aparato reciba un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros:

MD ID;

MnS ID;

lista de nombres de API, tipos y formatos de datos;

funciones soportadas por la API relacionadas con el al menos uno de los segmentos y el servicio;

nivel de exposición de las características soportadas; e

informe de estado de la API.

9. El aparato de la reivindicación 7, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato envíe a un plano de control una solicitud de un estado de disponibilidad de una API de plano de control y de capacidades relacionadas con servicios de control relacionados con segmentos para la NSI, comprendiendo la solicitud al menos una de:

ID de soporte intermedio;

solicitud del nombre de la API en dirección norte;

solicitud de URI en dirección norte;

solicitud de versión de la API en dirección norte;

solicitud de formato de datos;

solicitud de funciones soportadas por la API en dirección norte relacionadas con al menos uno de los segmentos y un servicio;

requisito de nivel de exposición para las funciones soportadas;

consulta del estado de la API;

puntos de terminación de la API; y

validez temporal,

opcionalmente, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato reciba un mensaje de respuesta comprendiendo al menos uno de los siguientes parámetros:

NEF ID:

lista de nombres de API, tipos y formatos de datos;

nivel de exposición de las características soportadas; e

informe de estado de la API.

10. El aparato de la reivindicación 7, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato envíe a una función relacionada con E2 una solicitud de un estado de disponibilidad de la API de la función relacionada con E2 y de las capacidades relacionadas con los servicios de control relacionados con el segmento para la NSI, comprendiendo la solicitud al menos una de:

un ID de soporte intermedio, un ID de xApp y un ID de rApp;

solicitud de nombre de API relacionada con E2;

solicitud de URI relacionada con E2;

solicitud de versión relacionada con E2;

solicitud de formato de datos;

solicitud de características soportadas relacionadas con E2 relativas a al menos uno de los segmentos y un servicio:

requisito de nivel de exposición para las funciones soportadas;

consulta de estado relacionado con E2;

puntos de terminación relacionados con E2; y

validez temporal,

ID de función RIC;

lista de nombres de API, tipos y formatos de datos;

nivel de exposición de las características soportadas; e

informe de estado de la API.

11. El aparato de la reivindicación 7, en el que la asignación de la al menos una API de servicio para la al menos una NSI a la al menos una API dependiente de la plataforma se realiza coincidiendo el parámetro de servicio del al menos un servicio de red con al menos un parámetro de capacidad para la NSI, o la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para la NSI comprende al menos uno de un nombre/identificación de API independiente de la plataforma, nombres de API de servicio encerrados, URI, versiones de API, información de protocolo, puntos de terminación por API, tipos de API, métodos de comunicación y validez temporal.

12. El aparato de la reivindicación 4, en el que el al menos un procesador está configurado adicionalmente para hacer que el aparato:

solicitar el parámetro de servicio a un orquestador de gestión de servicios, SMO, para el al menos un servicio de red, el parámetro de servicio basado en al menos uno de un tipo del al menos un servicio de red y una autorización para acceder al al menos un servicio de red; y

recibir un mensaje del SMO comprendiendo el parámetro de servicio para el al menos un servicio de red para al menos uno de un servicio, un segmento y un tipo de aplicación.

13. El aparato de la reivindicación 4, en el que la asignación de la API dependiente de la plataforma a una API independiente de la plataforma para el al menos un servicio de red comprende al menos uno de un impacto en la complejidad/latencia en general para simplificar la API, impactos a nivel de protocolo, requisitos de aplicación para la portabilidad, requisitos relacionados con las segmentos para las capacidades de exposición, aspectos de seguridad relacionados con un tipo de función de red, capacidades de una aplicación final, dependencias entre servicios y un acuerdo de nivel de servicio, SLA.

14. El aparato de la reivindicación 1, en el que el parámetro de servicio comprende al menos uno de un nivel de exposición para el servicio de red, una accesibilidad del servicio de red y una disponibilidad del servicio de red.

15. Un método (800) para la comunicación inalámbrica, que comprende:

recibir (805) un parámetro de servicio de al menos un servicio de red de un sistema de comunicación inalámbrica, en el que el sistema de comunicación inalámbrica comprende una o más plataformas; y

determinar (810) una interfaz de programación de aplicaciones, API, independiente de la plataforma, basada en el parámetro de servicio para el al menos un servicio de red del sistema de comunicación inalámbrica.