ES3040133T3 - Method and network entity for service api publishing - Google Patents

Method and network entity for service api publishing

Info

Publication number
ES3040133T3
ES3040133T3 ES23187266T ES23187266T ES3040133T3 ES 3040133 T3 ES3040133 T3 ES 3040133T3 ES 23187266 T ES23187266 T ES 23187266T ES 23187266 T ES23187266 T ES 23187266T ES 3040133 T3 ES3040133 T3 ES 3040133T3
Authority
ES
Spain
Prior art keywords
network entity
api
service
service api
publish
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES23187266T
Other languages
English (en)
Inventor
Wenliang Xu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES3040133T3 publication Critical patent/ES3040133T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La presente divulgación proporciona un método (400) en una primera entidad de red para la publicación de una interfaz de programación de aplicaciones (API) de servicio. El método (400) incluye: recibir (410), de una segunda entidad de red, una solicitud de publicación de API para publicar una API de servicio. Esta solicitud contiene una lista de identificadores de las entidades de red que han publicado la API de servicio; y transmitir (420), cuando un identificador de la primera entidad de red está incluido en la lista, una respuesta de publicación de API que indica un error en la publicación de la API de servicio a la segunda entidad de red, sin crear un nuevo recurso para la API de servicio en la primera entidad de red ni publicar la API de servicio a ninguna otra entidad de red. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método y entidad de red para la publicación de API de servicio
Campo técnico
La presente divulgación se refiere a la tecnología de la comunicación, y más particularmente, a un método y una entidad de red para la publicación de la interfaz de programación de aplicaciones (API) de servicio.
Antecedentes
Con el creciente interés en el Proyecto de Asociación de Tercera Generación (3GPP) para desarrollar API en dirección norte, un marco de API común (CAPIF) permite un desarrollo consistente de API en dirección norte entre múltiples grupos de trabajo, es decir, para definir API en dirección norte para abstraer o exponer las capacidades de la red 3GPP subyacente a las aplicaciones de terceros. El CAPIF ofrece un marco común para las API en dirección norte con respecto al registro, autenticación, descubrimiento, registro de actividad y facturación de las API.
En la versión 16 del 3GPP, el CAPIF se mejora con la interconexión entre diferentes dominios de proveedores de CAPIF o dentro del mismo dominio de proveedor de CAPIF. La Fig. 1 muestra un modelo arquitectónico para la interconexión CAPIF que permite a los invocadores de API de un proveedor de CAPIF utilizar las API de servicio del proveedor de CAPIF de terceros. La Fig. 2 muestra un modelo arquitectónico para la interconexión CAPIF dentro del mismo dominio de proveedor de CAPIF, que permite a los invocadores de API de la función principal de CAPIF (CCF) 1 utilizar las API de servicio de CCF 2, donde ambas CCF están alojados dentro del dominio de confianza del proveedor A de CAPIF. En la Fig. 1, los dos CCF están conectados entre sí a través de una interfaz CAPIF-6e (punto de referencia); mientras que en la Fig. 2, los dos CCF están conectados entre sí a través de una interfaz CAPIF-6 (punto de referencia). La interfaz CAPIF-6/6e admite la publicación y el descubrimiento de información de la API de servicio. Para la publicación de API de servicio, la función de publicación de API (APF) (que permite al proveedor de API publicar información de la API de servicio en la CCF para permitir el descubrimiento de API de servicio por parte de los invocadores de API) o CCF puede indicar información compartible en una solicitud de publicación de API o una solicitud de publicación de API de interconexión, tal información indica si la API de servicio se puede compartir y, en, caso afirmativo, compartida con qué dominios proveedores de CAPIF. Para obtener más información sobre estas y otras entidades funcionales, interfaces (puntos de referencia), solicitudes y respuestas de publicación de API, y solicitudes y respuestas de publicación de API de interconexión, se puede hacer referencia a la Especificación Técnica (TS) 23.222 del 3g Pp , V16.6.0. Dicho documento 3GPP TS 23.222 V16.6.0 describe la arquitectura, procedimientos y flujos de información necesarios para el CAPIF. Los aspectos de este documento incluyen la identificación de los requisitos de arquitectura para el CAPIF (p. ej., registro, descubrimiento, gestión de identidad) que son aplicables a cualquier API de servicio cuando las utilizan entidades en dirección norte, así como cualquier interacción entre el CAPIF y las propias API de servicio. El Marco Común de API se aplica tanto a EPS como a 5GS, y es independiente del acceso 3GPP subyacente (p. ej., E-UTRA, NR).
El documento "Publicación de API y descubrimiento de API para la interconexión CAPIF", Huaweiet. al.,solicitud de cambio de 3GPP, S6-181382, describe detalles sobre el modelo funcional de interconexión CAPIF. Con respecto a CAPIF-6 entre las instancias CAPIF en el mismo dominio de confianza, se debe admitir la publicación de API de servicio y el descubrimiento de API de servicio. Con respecto a CAPIF-6e entre las instancias CAPIF en los diferentes dominios de confianza, se debe soportar la publicación de la API de servicio. En comparación con la publicación de API desde la función de publicación de API a CCF, la API publicada entre dos CCF puede ser información de alto nivel, como el tipo de API, en lugar de los detalles de la API de servicio, especialmente los CCF que pertenecen a diferentes dominios de confianza. Correspondiente a la publicación de API para la interconexión CCF, una CCF puede obtener la identidad CCF que publica la información de alto nivel de las API de servicio en lugar de los detalles de las API de servicio.
Compendio
Un objeto de la presente divulgación es proporcionar un método y una entidad de red para la publicación de API de servicio.
Según la presente divulgación, se proporcionan métodos, una primera entidad de red y un medio de almacenamiento legible por computadora según las reivindicaciones independientes. Los desarrollos adicionales se exponen en las reivindicaciones dependientes.
Según un primer aspecto de la presente divulgación, se proporciona un método en una primera entidad de red para la publicación de API de servicio. El método incluye: recibir, de una segunda entidad de red, una primera solicitud de publicación de API para publicar una API de servicio, conteniendo la primera solicitud de publicación de API una lista de identificadores de entidades de red que han publicado la API de servicio; y transmitir, cuando se incluye en la lista un identificador de la primera entidad de red, una respuesta de publicación de API que indica un fallo en la publicación de la API de servicio a la segunda entidad de red.
Preferiblemente, la segunda solicitud de publicación de API se transmite en respuesta a la determinación de que un identificador de la tercera entidad de red no está incluido en la primera lista.
Preferiblemente, el método incluye además, cuando el identificador de la primera entidad de red no está incluido en la primera lista: crear un nuevo recurso para la API de servicio en la primera respuesta que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado.
Preferiblemente, cada una de la primera entidad de red, la segunda entidad de red, la tercera entidad de red, y las entidades de red que han publicado la API de servicio son una entidad CCF.
Preferiblemente, la primera entidad de red, la segunda entidad de red, la tercera entidad de red y las entidades de red que han publicado la API de servicio están todas en un único dominio de proveedor de CAPIF.
Según un segundo aspecto de la presente divulgación, se proporciona un método en una primera entidad de red para la publicación de API de servicio. El método incluye: recibir, de una segunda entidad de red, una primera solicitud de publicación de API para publicar una API de servicio, conteniendo la primera solicitud de publicación de API una primera lista de identificadores de entidades de red que han publicado la API de servicio; y cuando un identificador de la primera entidad de red no esté incluido en la primera lista, añadir el identificador de la primera entidad de red a la primera lista para obtener una segunda lista de identificadores de entidades de red.
Según un tercer aspecto de la presente divulgación, se proporciona una primera entidad de red. La primera entidad de red incluye una interfaz de comunicación, un procesador y una memoria. La memoria almacena instrucciones ejecutables por el procesador mediante las cuales la primera entidad de red está operativa para realizar el método según el primer y/o segundo aspecto anteriores.
Según un cuarto aspecto de la presente divulgación, se proporciona un medio de almacenamiento legible por ordenador. El medio de almacenamiento legible por ordenador tiene instrucciones de programa informático almacenadas en el mismo. Las instrucciones de programa informático, cuando son ejecutadas un procesador en una primera entidad de red, hacen que la primera entidad de red realice el método según el primer y/o segundo aspecto mencionados anteriormente.
Con las realizaciones de la presente divulgación, al recibir una solicitud de publicación de API para publicar una API de servicio, una entidad de red puede determinar si su identificador está incluido en una lista de identificadores de entidades de red que han publicado la API de servicio (si está contenida en la solicitud de publicación de la API). Cuando su identificador esté incluido en la lista, la entidad de red responderá con un resultado que indica un fallo en la publicación de la API de servicio, sin crear un nuevo recurso para la API de servicio ni publicar más la API de servicio en ninguna entidad de red. Por otro lado, sólo cuando su identificador no esté incluido en la lista, la entidad CCF creará un nuevo recurso para la API de servicio y/o transmitirá otra solicitud de publicación de AP I para publicar la API de servicio a otra entidad de red. La solicitud de publicación de AP adicional puede contener una lista actualizada de identificadores de entidades de red que han publicado la API de servicio, con el identificador de la entidad de red agregado a la lista. De este modo, la entidad de red puede evitar la creación de recursos redundantes para la misma API de servicio y puede evitar un bucle para publicar la API de servicio.
Breve descripción de los dibujos
En lo anterior y en lo sucesivo en el presente documento, los "ejemplos" se refieren a principios que subyacen al tema reivindicado y/o que son útiles para comprender dicho tema, mientras que las "realizaciones" se refieren al objeto reivindicado dentro del alcance de la reivindicación. El anterior y otros objetos, características y ventajas serán más evidentes a partir de la siguiente descripción de realizaciones con referencia a las figuras, en las que:
la Fig. 1 es un diagrama esquemático que muestra un modelo arquitectónico para una interconexión CAPIF a través de diferentes dominios de proveedores CAPIF según un ejemplo;
la Fig. 2 es un diagrama esquemático que muestra un modelo arquitectónico para una interconexión CAPIF dentro de un dominio de proveedor de CAPIF según un ejemplo;
la Fig. 3 es un diagrama esquemático que muestra un ejemplo de un bucle para publicar una API de servicio según un ejemplo;
la Fig. 4 es un diagrama de flujo que ilustra un método para la publicación de API de servicio según una realización de la presente divulgación; la Fig. 5 es un diagrama de flujo que ilustra un método para la publicación de API de servicio según un ejemplo;
la Fig. 6 es un diagrama de secuencia que muestra un proceso ilustrativo para la publicación de API de servicio según una realización de la presente divulgación;
la Fig. 7 es un diagrama de bloques de una entidad de red según un ejemplo; y
la Fig. 8 es un diagrama de bloques de una entidad de red según otra realización de la presente divulgación.
Siempre que en la siguiente divulgación aparezca el término "realización", se debe hacer referencia a la descripción de la figura anterior para aclarar si se refiere a una realización o a un ejemplo.
Descripción detallada
Las referencias en la memoria descriptiva a "una realización", "realización", "una realización ilustrativa", y similares indican que la realización descrita puede incluir un aspecto, estructura o característica particular, pero no es necesario que cada realización incluya el rasgo, estructura o característica particular. Asimismo, tales expresiones no se refieren necesariamente a la misma realización. Además, cuando un rasgo, estructura o característica particular se describe en relación con una realización, se sostiene que está dentro del conocimiento de una persona con conocimiento en la técnica afectar dicho rasgo, estructura o característica en relación con otras realizaciones, independientemente de si se describen explícitamente o no.
Se entenderá que, si bien los términos "primero" y "segundo", etc., pueden usarse en el presente documento para describir varios elementos, estos elementos no deben limitarse a estos términos. Estos términos solo se usan para distinguir un elemento de otro. Por ejemplo, un primer elemento podría denominarse segundo elemento y, de manera similar, un segundo elemento podría denominarse primer elemento, sin alejarse del alcance de las realizaciones ilustrativas. Como se emplea en esta memoria, el término "y/o" incluye cualquiera y todas las combinaciones de uno o más de los términos enumerados asociados.
La terminología usada en la presente memoria es para el propósito de describir implementaciones particulares únicamente y no se pretende que limite los ejemplos de realizaciones. Como se emplea en esta memoria, las formas singulares "un", "una" y "el/la" también pretenden incluir las formas plurales, a menos que el contexto indique claramente lo contrario. Se entenderá además que los términos "comprende", "comprendiendo", "tiene", "teniendo", "incluye" y/o "incluyendo", cuando se emplean en la presente memoria, especifican la presencia de las características, elementos y/o componentes indicados, etc., pero no excluyen la presencia o adición de una o más características, elementos, componentes y/o combinaciones adicionales de los mismos.
En la siguiente descripción y reivindicaciones, a menos que se defina lo contrario, todos los términos técnicos y científicos empleados en la presente memoria tienen el mismo significado que comúnmente entiende una persona con conocimientos ordinarios en la técnica a la que pertenece esta divulgación.
Para la publicación de API de servicio a través de interfaces CAPIF-6/6e, como se muestra en la Fig. 3, es posible que una API se publique primero de CCF 1 a CCF 2, luego de CCF 2 a CCF 3, y luego de CCF 3 nuevamente a CCF 1. En este caso, CCF 1 creará un nuevo recurso de API de servicio para la API, además del recurso de API de servicio que creó cuando la API se publicó inicialmente, p. ej., de una APF. Por tanto, CCF 1 tendrá recursos redundantes ocupados por la misma API. Más en serio, CCF 1 puede volver a publicar la API en CCF 2, que luego podrá publicar la API en CCF 3, y así sucesivamente, lo que resulta en un bucle de publicación de API de servicio.
La Fig. 4 es un diagrama de flujo que ilustra un método 400 para la publicación de API de servicio según una realización de la presente divulgación. El método 400 se puede realizar en una primera entidad de red, p. ej., una entidad CCF.
En el bloque 410, se recibe una primera solicitud de publicación de API para publicar una API de servicio desde una segunda entidad de red (p. ej., una entidad CCF). La primera solicitud de publicación de API contiene una primera lista de identificadores de entidades de red (p. ej., entidades CCF) que han publicado la API de servicio. En este contexto, la lista también puede denominarse "trayectoria de API publicada" o "trayectoria de API" por abreviar.
En esta realización, la primera solicitud de publicación de API puede ser una solicitud de publicación de API de interconexión como se especifica en la Sección 8.25.2 de TS 23.222. La Tabla 8.25.2.1-1 de TS 23.222 define los Elementos de Información (IE) en la solicitud de publicación de API de interconexión, que se reproduce a continuación en la Tabla 1:
Tabla 1: Solicitud de publicación de API de interconexión
La información de la API de servicio en la Tabla 8.25.2.1-1 anterior se define en detalle en la Tabla 8.2.4.2.2-1 de TS 29.222 V16.1.0, que se puede cambiar para incluir la trayectoria de API, como se muestra en la Tabla 2 a continuación:
Tabla 2: Definición del tipo DescripciónAPIservicio
El atributo "trayectoriaAPIpub" contiene identificadores de entidades CCF que han publicado la API. Por ejemplo, el tipo de datos "TrayectoriaAPIpublicada" se puede definir en la Tabla 3 a continuación:
Tabla 3: Definición del tipo TrayectoriaAPIpublicada
Para obtener más detalles sobre otros lE en la Tabla 1 y otros atributos en la Tabla 2, se puede hacer referencia a la Tabla 8.25.2.1-1 de TS 23.222 y a la Tabla 8.2.4.2.2-1 de TS 29.222, respectivamente, y aquí se omitirán los detalles de los mismos.
Cuando un identificador de la primera entidad de red se incluye en la primera lista, en el bloque 420, se transmite una respuesta de publicación de API que indica un fallo en la publicación de la API de servicio a la segunda entidad de red, sin crear un nuevo recurso para la API de servicio en la primera entidad de red ni publicar más la API de servicio en ninguna entidad de red. Es decir, cuando el identificador de la primera identidad de red se incluye en la trayectoria de API, significa que la API de servicio publicada en la primera solicitud AP que publico es una API de servicio que la primera entidad publicó. En este caso, la primera entidad de red no creará ningún recurso nuevo para la misma API de servicio ni publicará más la API de servicio en ninguna entidad de red, evitando de este modo un desperdicio de recursos y un bucle de publicación de API. En esta realización, la respuesta de publicación de API puede ser una respuesta de publicación de API de interconexión como se especifica en la Sección 8.25.2.2 de TS 23.222.
Por otra parte, cuando el identificador de la primera entidad de red no esté incluido en la primera lista, en el bloque 430, se transmite una segunda solicitud de publicación de API para publicar la API de servicio a una tercera entidad de red (p. ej., una entidad CCF). La segunda solicitud de publicación de API contiene una segunda lista de identificadores de entidades de red que se obtiene al agregar el identificador de la primera entidad de red a la primera lista.
En un ejemplo, en el bloque 430, la segunda solicitud de publicación de API se puede transmitir en respuesta a la determinación de que un identificador de la tercera entidad de red no está incluido en la primera lista. En otras palabras, si la primera entidad de red conoce el identificador de la tercera entidad de red y determina que el identificador de la tercera entidad de red está incluido en la primera lista, lo que significa que la API de servicio es una API de servicio que la tercera entidad ha publicado, la primera entidad de red no puede transmitir la segunda solicitud de publicación de API para publicar aún más la misma API de servicio en la tercera entidad de red, evitando de este modo un desperdicio de recursos y un bucle de publicación de API.
Además, cuando el identificador de la primera entidad de red no esté incluido en la primera lista, la primera entidad de red puede crear un nuevo recurso para la API de servicio en la primera entidad de red; y transmitir, a la segunda entidad de red, una respuesta de publicación de API que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado. En esta realización, la respuesta de publicación de API puede ser una respuesta de publicación de API de interconexión como se especifica en la Sección 8.25.2.2 de TS 23.222.
En un ejemplo, la primera entidad de red, la segunda entidad de red, la tercera entidad de red y las entidades de red que han publicado la API de servicio pueden estar todas en un único dominio de proveedor de CAPIF. En otro ejemplo, estas entidades de red pueden pertenecer a diferentes dominios de proveedores de CAPIF.
En una implementación, el método 400 puede incluir únicamente los bloques 410 y 420. En otra implementación, el método 400 puede incluir únicamente los bloques 410 y 430. En otra implementación más, el método 400 puede incluir los bloques 410, 420 y 430.
La Fig. 5 es un diagrama de flujo que ilustra un método 500 para la publicación de API de servicio según una realización de la presente divulgación. El método 500 se puede realizar en una primera entidad de red, p. ej., una entidad CCF.
En el bloque 510, se recibe una primera solicitud de publicación de API para publicar una API de servicio desde una entidad de función (p. ej., una entidad APF). La primera solicitud de publicación de API puede ser, p. ej., una solicitud de publicación de API de servicio según lo especificado en la Sección 8.3.2.1 de TS 23.222.
En el bloque 520, se transmite una segunda solicitud de publicación de API a una segunda entidad de red (p. ej., una entidad CCF), p. ej., en respuesta a la primera solicitud de publicación de API que no contiene ninguna trayectoria de API. La segunda solicitud de publicación de API contiene un identificador de la primera entidad de red, p. ej., en una trayectoria de API. La segunda solicitud de publicación de API puede ser una solicitud de publicación de API de interconexión según la Tabla 1 y contener "TrayectoriaAPIpub" según la Tabla 2.
En esta realización, como la primera solicitud de publicación de API no contiene ninguna trayectoria de API, la primera entidad de red puede crear un nuevo recurso para la API de servicio en la primera entidad de red, y transmitir, a la entidad de función, una respuesta de publicación de API que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado. En esta realización, la respuesta de publicación de API puede ser una respuesta de publicación de API de servicio como se especifica en la Sección 8.3.2.2 de TS 23.222.
En un ejemplo, la primera entidad de red y la segunda entidad de red pueden estar ambas en un solo dominio de proveedor de CAPIF. En otro ejemplo, estas entidades de red pueden pertenecer a diferentes dominios de proveedores de CAPIF.
La Fig. 6 es un diagrama de secuencia que muestra un proceso ilustrativo para la publicación de API de servicio según una realización de la presente divulgación. El proceso se puede realizar en un sistema de comunicación que incluye al menos una entidad APF y una pluralidad de entidades CCF (p. ej., CCF1, CCF2 y CCF3).
En 6.1, la entidad APF transmite una solicitud de publicación de API de servicio para publicar una API de servicio en CCF1. Como la solicitud de publicación de API de servicio de la entidad APF no contiene ninguna trayectoria de API, CCF1 crea un nuevo recurso para la API de servicio y transmite una respuesta de publicación de la API de servicio que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado a la entidad APF en 6.2. En 6.3, si la API de servicio se va a compartir con CCF2 (dependiendo de la información compartible en la solicitud de publicación de la API de servicio), CCF1 transmite una solicitud de publicación de API de interconexión para publicar la API de servicio en CCF2, que contiene una trayectoria de API que incluye un identificador de CCF1. Al recibir la solicitud de publicación de API de interconexión, CCF2 verifica la trayectoria de la API y determina que un identificador de CCF2 no está incluido en la trayectoria de la API. Por consiguiente, CCF2 crea un nuevo recurso para la API de servicio y transmite una respuesta de publicación de API de interconexión que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado para CCF1 en 6.4. Si la API de servicio se va a compartir con CCF3 (dependiendo de la información compartióle en la solicitud de publicación de API de interconexión de CCF1), CCF2 puede determinar primero si un identificador de CCF3 está incluido en la trayectoria de API, si es conocido para CCF2. Si se conoce el identificador de CCF3 y no está incluido en la trayectoria de la API, o si CCF2 desconoce el identificador de CCF3, en 6.5, CCF2 transmite una solicitud de publicación de API de interconexión para publicar la API de servicio en CCF3, que contiene una trayectoria de API que incluye los identificadores de CCF1 y CCF2. Al recibir la solicitud de publicación de API de interconexión, CCF3 verifica la trayectoria de la API y determina que el identificador de CCF3 no está incluido en la trayectoria de la API. Por consiguiente, CCF3 crea un nuevo recurso para la API de servicio y transmite una respuesta de publicación de API de interconexión que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado para CCF2 en 6.6.
Si la API de servicio se va a compartir con CCF1 (dependiendo de la información compartible en la solicitud de publicación de API de interconexión de CCF2), CCF3 puede determinar primero si el identificador de CCF1 está incluido en la trayectoria de API, si es conocido para CCF3. Si se conoce el identificador de CCF1 y está incluido en la trayectoria de API, CCF3 no publicará más la API de servicio en CCF1 y, por consiguiente, no habrá ningún bucle. Sin embargo, si el identificador de CCF1 es desconocido para CCF3, en 6.7, CCF3 transmite una solicitud de publicación de API de interconexión para publicar la API de servicio en CCF1, que contiene una trayectoria de API que incluye los identificadores de CCF1, CCF2 y CCF3. Al recibir la solicitud de publicación de API de interconexión, CCF1 verifica la trayectoria de la API y determina que el identificador de CCF1 está incluido en la trayectoria de la API. Por consiguiente, CCF1 transmite una respuesta de publicación de API de interconexión que indica un fallo en la publicación de la API de servicio a CCF3 en 6.8, sin crear un nuevo recurso para la API de servicio en CCF1 ni publicar más la API de servicio en ninguna entidad de red. En este caso, no habrá ningún bucle para publicar la API de servicio.
Según el método 400 o 500 como se describe en la presente memoria anteriormente, se proporciona una primera entidad de red. La Fig. 7 es un diagrama de bloques de una primera entidad 700 de red de comunicación según una realización de la presente divulgación.
La primera entidad 700 de red puede estar operativa para realizar el método 400 como se muestra en la Fig. 4. Como se ha analizado anteriormente en relación con el método 400, en una implementación, la primera entidad 700 de red puede estar operativa para ejecutar únicamente los bloques 410 y 420 en el método 400. En otra implementación, la primera entidad 700 de red puede estar operativa para ejecutar únicamente los bloques 410 y 430 en el método 400. En otra implementación más, la primera entidad 700 de red puede estar operativa para realizar los bloques 410, 420 y 430 en el método 400.
Como se muestra en la Fig. 7, la primera entidad 700 de red incluye una unidad 710 de recepción configurada para recibir, de una segunda entidad de red, una primera solicitud de publicación de API para publicar una API de servicio, conteniendo la primera solicitud de publicación de API una primera lista de identificadores de entidades de red que han publicado la API de servicio.
La primera entidad 700 de red incluye además una unidad 720 de transmisión configurada para transmitir, cuando un identificador de la primera entidad de red se incluye en la primera lista, una respuesta de publicación de API que indica un fallo en la publicación de la API de servicio a la segunda entidad de red. En este caso, la primera entidad 700 de red no creará un nuevo recurso para la API de servicio en la primera entidad de red ni publicará más la API de servicio en ninguna entidad de red.
Como alternativa o adicionalmente, la unidad 720 de transmisión se puede configurar para transmitir, cuando un identificador de la primera entidad de red no está incluido en la primera lista, una segunda solicitud de publicación de API para publicar la API de servicio en una tercera entidad de red, la segunda solicitud de publicación de API que contiene una segunda lista de identificadores de entidades de red obtenida al agregar el identificador de la primera entidad de red a la primera lista. En este caso, la segunda solicitud de publicación de API puede transmitirse en respuesta a la determinación de que un identificador de la tercera entidad de red no está incluido en la primera lista. La primera entidad 700 de red puede incluir además una unidad de creación configurada para crear un nuevo recurso para la API de servicio en la primera entidad de red, y la unidad 720 de transmisión puede estar configurada además para transmitir, a la segunda entidad de red, una respuesta de publicación de API que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado.
En una realización, cada una de la primera entidad de red, la segunda entidad de red, la tercera entidad de red, y las entidades de red que han publicado la API de servicio pueden ser una entidad CCF.
En una realización, la primera entidad de red, la segunda entidad de red, la tercera entidad de red y las entidades de red que han publicado la API de servicio pueden estar todas en un único dominio de proveedor de CAPIF.
Como alternativa, la entidad 700 de red puede estar operativa para realizar el método 500 como se muestra en la Fig. 5. Como se muestra en la Fig. 7, la entidad 700 de red incluye una unidad 710 de recepción configurada para recibir, de una entidad de función, una primera solicitud de publicación de API para publicar una API de servicio. La entidad 700 de red incluye además una unidad 720 de transmisión configurada para transmitir una segunda solicitud de publicación de API para publicar la API a una segunda entidad de red, conteniendo la segunda solicitud de publicación de API un identificador de la primera entidad de red.
En una realización, cada una de la primera entidad de red y la segunda entidad de red puede ser una entidad CCF, y la entidad de función puede ser una entidad APF.
En una realización, la primera entidad de red y la segunda entidad de red pueden estar ambas en un único dominio de proveedor de CAPIF.
Las unidades 710 y 720 se pueden implementar como una solución de hardware puro o como una combinación de software y hardware, p. ej., por uno o más de los siguientes: un procesador o un microprocesador y un software y memoria adecuados para almacenar el software, un dispositivo lógico programable (PLD) u otro componente o componentes electrónicos o circuito de procesamiento configurado para realizar las acciones descritas anteriormente e ilustradas, p. ej., en la Fig. 4 o 5.
La Fig. 8 es un diagrama de bloques de una primera entidad 800 de red según una realización de la presente divulgación.
La primera entidad 800 de red incluye una interfaz 810 de comunicación, un procesador 820 y una memoria 830. La memoria 830 puede contener instrucciones ejecutables por el procesador 820 mediante las cuales la primera entidad 800 de red está operativa para realizar las acciones, p. ej., del procedimiento descrito anteriormente junto con la Fig. 4. Como se ha analizado anteriormente en relación con el método 400, en una implementación, la primera entidad 800 de red puede estar operativa para ejecutar únicamente los bloques 410 y 420 en el método 400. En otra implementación, la primera entidad 800 de red puede estar operativa para ejecutar únicamente los bloques 410 y 430 en el método 400. En otra implementación más, la primera entidad 800 de red puede estar operativa para realizar los bloques 410, 420 y 430 en el método 400.
Particularmente, la memoria 830 contiene instrucciones ejecutables por el procesador 820 mediante las cuales la primera entidad 800 de red está operativa para recibir, de una segunda entidad de red, una primera solicitud de publicación de API para publicar una API de servicio, conteniendo la primera solicitud de publicación de API una primera lista de identificadores de entidades de red que han publicado la API de servicio.
La memoria 830 puede contener además instrucciones ejecutables por el procesador 820 mediante las cuales la primera entidad 800 de red está operativa para transmitir, cuando un identificador de la primera entidad de red se incluye en la primera lista, una respuesta de publicación de API que indica un fallo en la publicación de la API de servicio en la segunda entidad de red, sin crear un nuevo recurso para la API de servicio en la primera entidad de red ni publicar más la API de servicio en ninguna entidad de red.
Como alternativa o adicionalmente, la memoria 830 puede contener además instrucciones ejecutables por el procesador 820 mediante las cuales la primera entidad 800 de red está operativa para transmitir, cuando un identificador de la primera entidad de red no está incluido en la primera lista, una segunda solicitud de publicación de API para publicar la API de servicio en una tercera entidad de red, la segunda solicitud de publicación de API que contiene una segunda lista de identificadores de entidades de red obtenida al agregar el identificador de la primera entidad de red a la primera lista. En una realización, la segunda solicitud de publicación de API puede transmitirse en respuesta a la determinación de que un identificador de la tercera entidad de red no está incluido en la primera lista. En una realización, la memoria 830 puede contener además instrucciones ejecutables por el procesador 820 mediante las cuales la primera entidad 800 de red está operativa para, cuando el identificador de la primera entidad de red no está incluido en la primera lista: crear un nuevo recurso para la API de servicio en la primera entidad de red; y transmitir, a la segunda entidad de red, una respuesta de publicación de API que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado.
En una realización, cada una de la primera entidad de red, la segunda entidad de red, la tercera entidad de red, y las entidades de red que han publicado la API de servicio pueden ser una entidad CCF.
En una realización, la primera entidad de red, la segunda entidad de red, la tercera entidad de red y las entidades de red que han publicado la API de servicio pueden estar todas en un único dominio de proveedor de CAPIF.
Como alternativa, la memoria 830 puede contener instrucciones ejecutables por el procesador 820 mediante las cuales la primera entidad 800 de red está operativa para realizar las acciones, p. ej., del procedimiento descrito anteriormente junto con la Fig. 5. Particularmente, la memoria 830 contiene instrucciones ejecutables por el procesador 820 mediante las cuales la primera entidad 800 de red está operativa para recibir, de una entidad de función, una primera solicitud de publicación de API para publicar una API de servicio; y transmitir una segunda solicitud de publicación de API para publicar la API a una segunda entidad de red, conteniendo la segunda solicitud de publicación de API un identificador de la primera entidad de red.
En una realización, cada una de la primera entidad de red y la segunda entidad de red puede ser una entidad CCF, y la entidad de función puede ser una entidad APF.
En una realización, la primera entidad de red y la segunda entidad de red pueden estar ambas en un único dominio de proveedor de CAPIF.
La presente divulgación también proporciona al menos un producto de programa informático en forma de una memoria no volátil o volátil, p. ej., un medio de almacenamiento legible por ordenador no transitorio, una memoria de sólo lectura programable y borrable eléctricamente (EEPROM), una memoria flash y un disco duro. El producto de programa informático incluye un programa informático. El programa informático incluye: código/instrucciones legibles por ordenador, que cuando son ejecutada por el procesador 820 hacen que la entidad 800 de red realice las acciones, p. ej., del procedimiento descrito anteriormente junto con la Fig. 4 o 5.
El producto de programa informático puede configurarse como un código de programa informático estructurado en módulos de programa informático. Estos módulos de programa informático podrían realizar esencialmente las acciones del flujo ilustrado en la Fig. 4 o 5.
El procesador puede ser una única CPU (Unidad Central de Procesamiento), pero también podría comprender dos o más unidades de procesamiento. Por ejemplo, el procesador puede incluir microprocesadores de propósito general; procesadores de conjuntos de instrucciones y/o conjuntos de chips relacionados y/o microprocesadores de propósito especial como circuitos integrados específicos de la aplicación (ASIC). El procesador también puede comprender memoria de placa para fines de almacenamiento en caché. El programa informático puede transportarse por un producto de programa informático conectado al procesador. El producto de programa informático puede comprender un medio de almacenamiento legible por ordenador no transitorio en el que se almacena el programa informático. Por ejemplo, el producto del programa informático puede ser una memoria flash, una Memoria de Acceso Aleatorio (RAM), una memoria de sólo lectura (ROM), o una EEPROM, y los módulos de programa informático descritos anteriormente podrían, en realizaciones alternativas, distribuirse en diferentes productos de programa informático en forma de memorias.

Claims (11)

REIVINDICACIONES
1. Un método (400) en una primera entidad de red para la publicación de interfaz de programación de aplicaciones, API, de servicio, que comprende:
recibir (410), de una segunda entidad de red, una primera solicitud de publicación de API para publicar una API de servicio, conteniendo la primera solicitud de publicación de API una lista de identificadores de entidades de red que han publicado la API de servicio; y
transmitir (420), cuando se incluye en la lista un identificador de la primera entidad de red, una respuesta de publicación de API que indica un fallo en la publicación de la API de servicio a la segunda entidad de red.
2. El método (400) de la reivindicación 1, que comprende además, cuando el identificador de la primera entidad de red no está incluido en la primera lista:
crear un nuevo recurso para la API de servicio en la primera entidad de red; y
transmitir, a la segunda entidad de red, una respuesta de publicación de API que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado.
3. El método (400) de la reivindicación 1 o 2, en donde cada una de la primera entidad de red, la segunda entidad de red, la tercera entidad de red, y las entidades de red que han publicado la API de servicio es una entidad de función central del Marco Común de API, 'CAPIF', CCF.
4. El método (400) de la reivindicación 3, en donde la primera entidad de red, la segunda entidad de red, la tercera entidad de red y las entidades de red que han publicado la API de servicio están todas en un único dominio de proveedor de CAPIF.
5. Un método (400) en una primera entidad de red para la publicación de interfaz de programación de aplicaciones, API, de servicio, que comprende:
recibir (410), de una segunda entidad de red, una primera solicitud de publicación de API para publicar una API de servicio, conteniendo la primera solicitud de publicación de API una primera lista de identificadores de entidades de red que han publicado la API de servicio; y
cuando un identificador de la primera entidad de red no está incluido en la primera lista, añadir el identificador de la primera entidad de red a la primera lista para obtener una segunda lista de identificadores de entidades de red.
6. El método (400) de la reivindicación 5, comprendiendo además el método (400):
transmitir (430) una solicitud a una tercera entidad de red, en donde la solicitud contiene la segunda lista de identificadores de entidades de red, en respuesta a la determinación de que un identificador de la tercera entidad de red no está incluido en la primera lista.
7. El método (400) de la reivindicación 5 o 6, que comprende además, cuando el identificador de la primera entidad de red no está incluido en la primera lista:
crear un nuevo recurso para la API de servicio en la primera entidad de red; y
transmitir, a la segunda entidad de red, una respuesta de publicación de API que indica el éxito de la publicación de la API de servicio y que contiene un identificador del nuevo recurso creado.
8. El método (400) de cualquiera de las reivindicaciones 5 a 7, en donde cada una de la primera entidad de red, la segunda entidad de red, la tercera entidad de red, y las entidades de red que han publicado la API de servicio es una entidad de función central del Marco Común de API, 'CAPIF', CCF.
9. El método (400) de la reivindicación 8, en donde la primera entidad de red, la segunda entidad de red, la tercera entidad de red y las entidades de red que han publicado la API de servicio están todas en un único dominio de proveedor de CAPIF.
10. Una primera entidad (800) de red que comprende una interfaz (810) de comunicación, un procesador (820) y una memoria (830), comprendiendo la memoria (830) instrucciones ejecutables por el procesador (820) de modo que la primera entidad (800) de red está operativa para realizar el método según cualquiera de las reivindicaciones 1 a 9.
11. Un medio de almacenamiento legible por ordenador que tiene instrucciones de programa informático almacenadas en el mismo, haciendo las instrucciones de programa informático, cuando son ejecutadas por un procesador en una primera entidad de red, que la primera entidad de red realice el método según cualquiera de las reivindicaciones 1 a 9.
ES23187266T 2020-02-14 2020-11-20 Method and network entity for service api publishing Active ES3040133T3 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2020075379 2020-02-14

Publications (1)

Publication Number Publication Date
ES3040133T3 true ES3040133T3 (en) 2025-10-28

Family

ID=73544182

Family Applications (1)

Application Number Title Priority Date Filing Date
ES23187266T Active ES3040133T3 (en) 2020-02-14 2020-11-20 Method and network entity for service api publishing

Country Status (9)

Country Link
US (1) US20230046570A1 (es)
EP (2) EP4104417B1 (es)
JP (2) JP7346745B2 (es)
CN (2) CN117221385A (es)
ES (1) ES3040133T3 (es)
MX (1) MX2022007792A (es)
PL (1) PL4239982T3 (es)
WO (1) WO2021160307A1 (es)
ZA (1) ZA202209969B (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118844044A (zh) * 2022-02-07 2024-10-25 康维达无线有限责任公司 通过用户装备应用启用通用应用编程接口框架调用
WO2025017627A1 (en) * 2023-07-14 2025-01-23 Jio Platforms Limited Method and system for managing endpoint for a service application programming interface (api)

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7302439B2 (en) * 2002-06-28 2007-11-27 Sun Microsystems, Inc. Information model mapping with shared directory tree representations
US7716357B2 (en) * 2003-10-24 2010-05-11 Microsoft Corporation Service discovery and publication
US8595625B2 (en) * 2007-10-09 2013-11-26 Tellabs San Jose, Inc. Method and apparatus to automate configuration of network entities
WO2016045602A1 (en) * 2014-09-24 2016-03-31 Zte Corporation Identification and discovery of exposed services in a digital communication network
US10091086B2 (en) * 2015-04-03 2018-10-02 Oracle International Corporation System and method for providing an application programming interface manager for use with a service bus runtime
US10417060B2 (en) * 2016-06-27 2019-09-17 Verizon Patent And Licensing Inc. Automated API publication for Internet of Things platform
KR102607571B1 (ko) * 2017-05-02 2023-11-30 삼성전자주식회사 무선 통신 시스템에서 네트워크 기반의 노스바운드 어플리케이션 프로그래밍 인터페이스를 제공하기 위한 장치 및 방법
US11303676B2 (en) * 2017-11-16 2022-04-12 Samsung Electronics Co., Ltd. Method and system for authenticating application program interface (API) invokers
CN110046001B (zh) * 2018-01-15 2022-03-25 华为技术有限公司 一种授权撤回的方法及装置
CN108111629A (zh) * 2018-01-19 2018-06-01 京东方科技集团股份有限公司 应用编程接口服务装置和应用编程接口服务系统
CN112438041B (zh) * 2018-04-06 2024-07-19 三星电子株式会社 用于执行接入的方法与装置
JP7040632B2 (ja) * 2018-04-06 2022-03-23 日本電気株式会社 次世代ネットワークにおける共通ａｐｉフレームワークのセキュリティ手順
CN110362412A (zh) * 2018-04-09 2019-10-22 华为技术有限公司 一种服务api调用方法和相关装置
CN110730499B (zh) * 2018-07-16 2021-06-15 华为技术有限公司 一种mec信息获取方法及装置
CN110233791B (zh) * 2019-06-06 2022-04-15 北京百度网讯科技有限公司 数据去重方法和装置
US12574831B2 (en) * 2019-09-25 2026-03-10 Samsung Electronics Co., Ltd. Method and system for distributed discovery and notification for edge computing
CN110688142B (zh) * 2019-10-10 2020-07-07 星环信息科技（上海）有限公司 应用程序编程接口的发布方法、设备及存储介质
KR102802497B1 (ko) * 2020-09-30 2025-04-29 텔레폰악티에볼라겟엘엠에릭슨(펍) 애플리케이션 프로그래밍 인터페이스 관리를 위한 방법 및 장치

Also Published As

Publication number Publication date
JP2024009797A (ja) 2024-01-23
EP4239982B1 (en) 2025-09-03
CN115023931A (zh) 2022-09-06
WO2021160307A1 (en) 2021-08-19
EP4239982A3 (en) 2023-10-25
JP2023516243A (ja) 2023-04-19
EP4104417B1 (en) 2023-07-26
MX2022007792A (es) 2022-09-27
US20230046570A1 (en) 2023-02-16
JP7346745B2 (ja) 2023-09-19
CN115023931B (zh) 2023-10-03
EP4239982A2 (en) 2023-09-06
ZA202209969B (en) 2024-11-27
JP7664982B2 (ja) 2025-04-18
PL4239982T3 (pl) 2026-01-26
EP4104417A1 (en) 2022-12-21
EP4239982C0 (en) 2025-09-03
CN117221385A (zh) 2023-12-12

Similar Documents

Publication Publication Date Title
US11729143B2 (en) Methods for internet communication security
US20250370784A1 (en) Methods for Internet Communication Security
US11734458B2 (en) Extensible layered trusted computing base for computing devices
US11930007B2 (en) Methods for internet communication security
US12113916B2 (en) Method and apparatus for hardware based file/document expiry timer enforcement
El Majdoubi et al. [Retracted] SmartMedChain: A Blockchain‐Based Privacy‐Preserving Smart Healthcare Framework
KR102447251B1 (ko) 실링 엔클레이브로써의 데이터 실링해제
US11030217B2 (en) Blockchain implementing cross-chain transactions
ES2767048T3 (es) Método y aparatos para gestionar comunicaciones para el internet de las cosas (IoT)
US20190109822A1 (en) Methods for Internet Communication Security
US10575273B2 (en) Registration of devices in secure domain
BR112020008394A2 (pt) método e sistema de estabelecimento de sessão, entidades de gerenciamento de sessão e de mobilidade, e meio de armazenamento
ES3040133T3 (en) Method and network entity for service api publishing
CN110199285A (zh) 从属包围区二进制文件
Nguyen et al. Toward a unique IoT network via single sign-on protocol and message queue
CN110214321A (zh) 嵌套包围区身份
US9191391B1 (en) Cross-domain object models for securely sharing information between network security domains
WO2017181863A1 (zh) 资源访问控制方法及装置
Joshi et al. Secure and interoperable EHR management via hyperledger fabric: the Mrblock framework
Pasquier et al. Information flow control for strong protection with flexible sharing in PaaS
CN111736917A (zh) 数据校验方法、装置、计算机设备和存储介质
Peterson et al. Towards a comprehensive planetlab architecture
Turcanu Providing Trusted Computing Services for Multi-access Edge Cloud Computing
Luong et al. Toward a Unique IoT Network via Single Sign-On Protocol and Message Queue
Fischer User management of a privacy-based carpooling platform