System and method for supporting application package management and lifecycle management

Abstract

The present disclosure presents systems and methods for supporting application package management and / or application lifecycle management. A second multi-access edge computing combiner (MEF) may receive a request including at least one parameter from the first MEF. The second MEF may determine to interact with a multi-access edge coordinator (MEO) associated with the second MEF for resource establishment. The second MEF may use at least one parameter to interact with the MEO associated with the second MEF.

Description

Technical Field

[0001] The present disclosure generally relates to wireless communication, including but not limited to systems and methods for supporting application package management and / or application lifecycle management. Background Art

[0002] The standardization organization Third Generation Partnership Project (3GPP) is currently specifying a new radio interface called 5G New Radio (5G NR) and a next-generation packet core network (Next Generation Packet Core Network, NG-CN or NGC). 5G NR will have three main parts: a 5G access network (5G Access Network, 5G-AN), a 5G core network (5G Core Network, 5GC), and user equipment (User Equipment, UE). To facilitate the implementation of different data services and requirements, the components of the 5GC (also called network functions) have been simplified, where some components are software-based and some components are hardware-based, so that these components can be adjusted as needed. Summary of the Invention

[0003] Exemplary embodiments disclosed herein are directed to solving problems related to one or more problems existing in the related art and providing additional features that will become apparent when the following detailed description is read in conjunction with the accompanying drawings. According to various embodiments, example systems, methods, apparatuses, and computer program products are disclosed herein. However, it should be understood that these embodiments are presented by way of example and not limitation, and various modifications to the disclosed embodiments will be apparent to those of ordinary skill in the art who have read this disclosure while remaining within the scope of this disclosure.

[0004] At least one aspect relates to the following systems, methods, apparatuses, or computer-readable media. A second Multi-Access Edge Computing (MEC) Federator (MEF) may receive a request including at least one parameter from a first MEF. The second MEF may determine to interact with a Multi-access Edge Orchestrator (MEO) associated with the second MEF for resource establishment. The second MEF may use the at least one parameter to interact with the MEO associated with the second MEF. The request may be sent by a client (e.g., a UE or an Operations Support System (OSS)) to the MEO associated with the first MEF according to the Uniform Resource Locator (URL) of the MEO associated with the first MEF (e.g., the transport-specific URL of MEO#1).

[0005] In some embodiments, the request may further include target system information, where the target system information includes at least one of the following: an identifier (ID) of a target MEC system (e.g., MEO#2 and / or MEF#2) or an Internet Protocol (IP) address of the target MEC system. The URL may be provided by the MEO associated with the first MEF to the client. The MEO associated with the first MEF may send the request to the first MEF in response to receiving the request from the client.

[0006] In some embodiments, the request may include a request to load an application. The second MEF may use the at least one parameter to generate an application package that conforms to a specific MEC definition (e.g., the European Telecommunications Standards Institute (ETSI) Multi-Access Edge Computing (MEC) definition). The interaction may include requesting the MEO associated with the second MEF to establish resources for loading the application package.

[0007] In some embodiments, the request may include a request to establish an application instance. The interaction may include requesting the MEO associated with the second MEF to establish resources for the application instance.

[0008] In some embodiments, a first Multi-Access Edge Computing (MEC) Federator (MEF) may send a request including at least one parameter. The second MEF may determine to interact with a Multi-access Edge Orchestrator (MEO) associated with the second MEF for resource establishment. The second MEF may use the at least one parameter to interact with the MEO associated with the second MEF. Brief Description of the Drawings

[0009] The following describes various exemplary embodiments of the present solution in detail with reference to the following drawings. The drawings or figures are provided for illustrative purposes only and depict only the exemplary embodiments of the present solution to facilitate the reader's understanding of the present solution. Therefore, the drawings should not be considered as a limitation on the breadth, scope, or applicability of the present solution. It should be noted that these drawings are not necessarily drawn to scale for clarity and ease of illustration.

[0010] Figure 1 Shows an example cellular communication network that can implement the technology disclosed herein according to an embodiment of the present disclosure;

[0011] Figure 2 Shows a block diagram of an example base station and UE (User Equipment) device according to some embodiments of the present disclosure;

[0012] Figure 3 Shows an example implementation of a Multi-access Edge Computing (MEC) system according to some embodiments of the present disclosure;

[0013] Figure 4 Shows another example implementation of a Multi-access Edge Computing (MEC) system according to some embodiments of the present disclosure;

[0014] Figure 5 Shows a sequence diagram according to some embodiments of the present disclosure, which shows the message flow for loading an application package;

[0015] Figure 6 Shows a sequence diagram according to some embodiments of the present disclosure, which shows the message flow for loading an application package;

[0016] Figure 7 Shows a sequence diagram according to some embodiments of the present disclosure, which shows the message flow for application instantiation; and

[0017] Figure 8 Shows a flowchart of an example method for supporting application package management and lifecycle management according to an embodiment of the present disclosure. Detailed Description of the Embodiments

[0018] 1. Mobile Communication Technologies and Environments

[0019] Figure 1FIG. 0 shows an example wireless communication network and / or system 100 that can implement the techniques disclosed herein in accordance with an embodiment of the present disclosure. In the following discussion, the wireless communication network 100 can be any wireless network, such as a cellular network or a Narrowband Internet of Things (NB-IoT) network, and the wireless communication network 100 is referred to as the "network 100" in the present disclosure. Such an example network 100 includes base stations 102 (hereinafter referred to as "BS102", also referred to as wireless communication nodes) and UE (User Equipment) devices 104 (hereinafter referred to as "UE 104"; also referred to as wireless communication devices) that can communicate with each other via communication links 110 (e.g., wireless communication channels), and a cluster of cells 126, 130, 132, 134, 136, 138, and 140 covering a geographical area 101. In Figure 1 this, BS102 and UE 104 are contained within the respective geographical boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 can include at least one base station that operates with the allocated bandwidth to provide sufficient radio coverage to its intended users.

[0020] For example, BS102 can operate on the allocated channel transmission bandwidth to provide sufficient coverage to UE 104. BS102 and UE 104 can communicate via a downlink radio frame 118 and an uplink radio frame 124, respectively. Each radio frame 118 / 124 can be further divided into subframes 120 / 127, and the subframes 120 / 127 can include data symbols 122 / 128. In the present disclosure, BS102 and UE 104 are described as non-limiting examples of "communication nodes" that can generally practice the methods disclosed herein. According to various embodiments of the present solution, such communication nodes can implement wireless and / or wired communications.

[0021] Figure 2 FIG. 9 shows a block diagram of an example wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., OFDM / OFDMA signals) in accordance with some embodiments of the present solution. System 200 can include components and elements configured to support known or conventional operating features that are not described in detail herein. In an illustrative embodiment, as described above, system 200 can be used to communicate (e.g., transmit and receive) data symbols in a wireless communication environment such as Figure 1 the wireless communication environment 100.

[0022] System 200 generally includes a base station 202 (hereinafter referred to as "BS202") and a UE device 204 (hereinafter referred to as "UE 204"). BS202 includes a BS (Base Station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, and each module is coupled and interconnected with each other via a data communication bus 220 as required. UE 204 includes a UE (User Equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, and each module is coupled and interconnected with each other via a data communication bus 240 as required. BS202 communicates with UE 204 via a communication channel 250, which can be any wireless channel or other medium suitable for data transmission as described herein.

[0023] As will be understood by those of ordinary skill in the art, system 200 may also include any number of modules other than Figure 2 the modules shown. Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logics described in connection with the embodiments disclosed herein may be implemented in hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are generally described in terms of their functions. Whether such a function is implemented as hardware, firmware, or software depends on the specific application and design constraints imposed on the overall system. Persons familiar with the concepts described herein can implement such functions in a manner suitable for each specific application, but such implementation decisions should not be construed as limiting the scope of the present disclosure.

[0024] According to some embodiments, the UE transceiver 230 may herein be referred to as an "uplink" transceiver 230, which includes a Radio Frequency (RF) transmitter and an RF receiver, both of which include circuitry coupled to an antenna 232. A duplexer switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in a time-division duplexing manner. Similarly, according to some embodiments, the BS transceiver 210 may herein be referred to as a "downlink" transceiver 210, which includes an RF transmitter and an RF receiver, both of which include circuitry coupled to an antenna 212. The downlink duplexer switch may alternatively couple the downlink transmitter or receiver to the downlink antenna 212 in a time-division duplexing manner. The operations of the two transceiver modules 210 and 230 can be coordinated in time such that the uplink receiver circuitry is coupled to the uplink antenna 232 to receive transmissions over the wireless transmission link 250 while the downlink transmitter is coupled to the downlink antenna 212. Conversely, the operations of the two transceivers 210 and 230 can be coordinated in time such that the downlink receiver is coupled to the downlink antenna 212 to receive transmissions over the wireless transmission link 250 while the uplink transmitter is coupled to the uplink antenna 232. In some embodiments, there is tight time synchronization with a minimum guard time between changes in the duplexing direction.

[0025] The UE transceiver 230 and the base station transceiver 210 are configured to communicate via a wireless data communication link 250 and cooperate with a suitably configured RF antenna arrangement 212 / 232 that can support a particular wireless communication protocol and modulation scheme. In some illustrative embodiments, the UE transceiver 210 and the base station transceiver 210 are configured to support industry standards such as Long Term Evolution (LTE) and emerging 5G standards. However, it should be understood that the present disclosure is not necessarily limited to applications to specific standards and related protocols. Instead, the UE transceiver 230 and the base station transceiver 210 can be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

[0026] According to various embodiments, for example, BS202 can be an evolved Node B (eNB), serving eNB, target eNB, femtocell, or picocell. In some embodiments, UE 204 can be embodied in various types of user equipment, such as mobile phones, smart phones, personal digital assistants (PDAs), tablet computers, laptop computers, wearable computing devices, and the like. Processor modules 214 and 236 can be implemented or accomplished by a general-purpose processor, content addressable memory, digital signal processor, application specific integrated circuit, field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof for performing the functions described herein. In this manner, the processor can be implemented as a microprocessor, controller, microcontroller, state machine, and the like. The processor can also be implemented as a combination of computing devices, such as, a combination of a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.

[0027] In addition, the steps of a method or algorithm described in connection with the embodiments disclosed herein can be directly embodied in hardware, firmware, software modules executed respectively by processor modules 214 and 236, or any actual combination thereof. Memory modules 216 and 234 can be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 can be respectively coupled to processor modules 210 and 230 such that processor modules 210 and 230 can respectively read information from and write information to memory modules 216 and 234. Memory modules 216 and 234 can also be integrated into their respective processor modules 210 and 230. In some embodiments, memory modules 216 and 234 can each include a cache memory for storing temporary variables or other intermediate information during the execution of instructions respectively executed by processor modules 210 and 230. Memory modules 216 and 234 can also each include non-volatile memory for storing instructions to be executed respectively by processor modules 210 and 230.

[0028] The network communication module 218 generally represents the hardware, software, firmware, processing logic, and / or other components of the base station 202 that enable two-way communication between the base station transceiver 210 and other network components and communication nodes configured to communicate with the base station 202. For example, the network communication module 218 may be configured to support Internet or WiMAX services. In a typical deployment, but not limited to, the network communication module 218 provides an 802.3 Ethernet interface that enables the base station transceiver 210 to communicate with a traditional Ethernet-based computer network. In this way, the network communication module 218 may include a physical interface for connecting to a computer network (e.g., a Mobile Switching Center (MSC)). As used herein, the terms "configured for", "configured to", and their conjugates, when used with respect to a particular operation or function, refer to a device, component, circuit, structure, machine, signal, etc. that is physically constructed, programmed, formatted, and / or arranged to perform the particular operation or function.

[0029] The Open Systems Interconnection (OSI) model (referred to herein as the "Open Systems Interconnection model") is a conceptual and logical layout of network communication defined for systems (e.g., wireless communication devices, wireless communication nodes) that are open to interconnection and communication with other systems. The model is divided into seven sub-components or layers, each representing a set of concepts of services provided to the layers above and below it. The OSI model also defines a logical network and effectively describes computer packet transmission by using different layer protocols. The OSI model may also be referred to as the seven-layer OSI model or the seven-layer model. In some embodiments, the first layer may be the physical layer. In some embodiments, the second layer may be the Medium Access Control (MAC) layer. In some embodiments, the third layer may be the Radio Link Control (RLC) layer. In some embodiments, the fourth layer may be the Packet Data Convergence Protocol (PDCP) layer. In some embodiments, the fifth layer may be the Radio Resource Control (RRC) layer. In some embodiments, the sixth layer may be the Non-Access Stratum (NAS) layer or the Internet Protocol (IP) layer, and the seventh layer is another layer.

[0030] The following describes various exemplary embodiments of the present solution with reference to the accompanying drawings, so that those of ordinary skill in the art can make and use the present solution. It will be apparent to those of ordinary skill in the art that after reading this disclosure, various changes or modifications can be made to the examples described herein without departing from the scope of the present solution. Therefore, the present solution is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order or hierarchy of steps in the methods disclosed herein is merely an exemplary method. Based on design preferences, the specific order or hierarchy of steps of the disclosed method or process can be rearranged while remaining within the scope of the present solution. Therefore, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or actions in a sample order, and unless otherwise explicitly stated, the present solution is not limited to the presented specific order or hierarchy.

[0031] 2. Systems and Methods for Supporting Application Package Management and / or Application Lifecycle Management

[0032] Some organizations (e.g., the European telecommunications standards institute (ETSI) Industry Specification Group (ISG) on Multi-access Edge Computing (MEC)) can specify the high-level application lifecycle management message flows between the application lifecycle management application programming interfaces (APIs) and the MEC systems in the MEC system. Some organizations (e.g., the Global system for mobile communications (GSMA) Operator Platform Group (OPG)) can specify the application lifecycle management APIs between operator platforms (OP). The East / West bound interface (E / WBI) in the OPG GSMA can serve as an interface between the MEC systems of the ETSI MEC. However, in the GSMA OPG and the ETSI MEC, for the same operation request, the Uniform Resource Identifiers (URIs) and the corresponding parameters can be different. Technical issues may exist in how to use the URIs and the corresponding parameters to support application package management and / or application lifecycle management. Updates / modifications can be used / applied to the Multi-access Edge Orchestrator (MEO) and / or the MEC Federator (MEF) to support the interaction between MEC systems. The updates can include changing / modifying / adjusting the resource tree of the existing application programming interface (API) and / or transformation operations.

[0033] Multi-access Edge Computing (MEC) can implement MEC applications as pure software entities running on top of a virtualized infrastructure, which can be located in or near the network edge. Figure 3 An example implementation / representation of a multi-access edge system reference architecture is shown. The multi-access edge system reference architecture can be defined in the European telecommunications standards institute (ETSI) Industry Specification Group (ISG) on Multi-access Edge Computing (MEC). The reference architecture can include functional elements. The functional elements can include reference points between the multi-access edge system and the functional elements.

[0034] In a MEC system, a Multi-Access Edge Orchestrator (MEO) can be a core function for MEC system-level management. The MEO can be responsible for at least one of the following functions in the MEC system. The MEO can maintain an overall view of the MEC system based on deployed MEC hosts, available resources, available MEC services, and / or topology. The MEO can manage the loading of application packages, including keeping records of the loaded packages, and / or preparing the virtualization infrastructure manager to handle the applications. The MEO can select a suitable MEC host for application instantiation based on constraints such as latency, available resources, and / or available services. The MEO can trigger application instantiation and / or termination.

[0035] Figure 4 An example implementation of a multi-access edge system reference architecture is shown. The multi-access edge system reference architecture can be a variant deployed in a MEC federation. The MEC federation can provide a solution for enabling communication between MEC systems. In addition to Figure 3 the definition of the reference architecture in

[0036] Within the MEC federation, the MEF can support at least one of the following functions. The MEF can provide registration of MEC system information through the MEO. The MEF can provide / perform MEC system discovery. The MEF can provide proxy capabilities as a one-to-many intermediary between MEFs. The MEF can provide information (e.g., MEC system information) exchange. The MEF can provide application lifecycle management (e.g., loading / instantiating / terminating) across different MEC systems. The MEF can provide application monitoring across different MEC systems.

[0037] MEC can provide a message flow for application lifecycle management (e.g., loading / instantiating) across different MEC systems. Figure 5 A sequence diagram showing the message flow for an application package (e.g., loading an application package) is shown. A client (e.g., an Operations Support System (OSS)) of MEC System #1 can trigger a loading request. The loading request can be forwarded by MEO #1 to the federated MEC System #2.

[0038] RESTful application programming interfaces (APIs) used in the application lifecycle management process / flow across different MEC systems may not have been defined in ETSI ISG MEC. The GSMA Operator Platform Group (OPG) can specify application lifecycle management APIs between operator platforms (OPs) through the East / West Bound Interface (E / WBI).

[0039] As Figure 5As shown, the E / WBI interface can operate or be used as an interface between MEF#1 and MEF#2. However, in OPAG GSMA and MEC ETSI, for the same operation request, the resource URI and corresponding parameters can be different. Tables 1, 2, 3, and 4 provide a comparison of the load operations between the GSMA OPG and ETSI MEC definitions. The application load management API can be used by the leading OP to provide application information to the partner OP. The load operation in GSMA OPG may be a one-step operation, but the load operation in ETSI MEC may be a two-step operation. For example, "POST" can be used to create a separate appPkgId resource. "PUT" can be used to provide the application package content. As Figure 5 forwarding the request from the client to MEO#2 as described in may be insufficient / inadequate / inappropriate because MEO#2 cannot handle the request without redesigning the existing API.

[0040] Table 1 shows the resources defined in the HTTP methods. The load operation in GSMA OPG can be a one-step operation.

[0041]

[0042]

[0043] Table 1

[0044] Table 2 shows the information elements that define edge applications.

[0045]

[0046] Table 2

[0047] Table 3 shows an example overview of the resources and methods for MEO / MEAO application package management. The load operation in ETSI MEC can be multiple operations (e.g., a two-step operation). The payload body can contain a ZIP file representing the application package. The "Content-Type" HTTP header can be set to "application / zip".

[0048]

[0049] Table 3

[0050] Table 4 shows the attributes of CreateAppPkg.

[0051]

[0052]

[0053] This document presents methods for how the MEO forwards application lifecycle management requests and how the MEF converts a one-step request from a client into a multi-step interaction (e.g., a two-step request). The two-step request can be processed by the MEO. The systems and methods presented in this document can include novel methods for supporting application lifecycle management (e.g., loading / instantiating) across different MEC systems.

[0054] Implementation Example 1

[0055] This disclosure provides implementation examples of multi-access edge computing (MEC) application lifecycle management across different MEC systems. To achieve this purpose, this disclosure discloses the technical solutions of the implementation examples.

[0056] To load a MEC application (e.g., application package management), this method can extend the resource uniform resource identifier (URI) on a multi-access edge computing (MEC) system (e.g., a multi-access edge orchestrator (MEO) or a MEC federator (MEF)), and can reorganize / restructure / re-implement the request to be consistent with the format / definition / standard defined on the MEC federator (MEF) (e.g., the European Telecommunications Standards Institute (ETSI) MEC definition), as Figure 6 shown. The MEO (e.g., MEO#1) can provide a transport point interface to the client. In response to the request, the MEF (e.g., MEF#2) can create a resource. The MEF can implement / perform actions based on the received request, e.g., create / establish a resource for an application package (e.g., load an application package, application loading, or load an application package). Steps 1 - 4 can have a prerequisite: a federation has been established or is already established.

[0057] In step 1, the client / client entity / client function can send a request (e.g., a load application package request) to a specific uniform resource locator (URL) of the multi-access edge orchestrator (MEO) #1 to transport the request (e.g., the transport specific URL of MEO#1). The body of the request can include at least one of the following: at least one parameter (e.g., a message parameter) or target system information. The target system information can contain / include at least one of the following: the identifier (ID) of the target system (e.g., the target MEC system) or the Internet protocol (IP) address of the target system (e.g., the target MEC system). In some embodiments, the target MEC system can include MEO#2 and MEF#2. If MEC system - to - system forwarding is required / involved, the MEO (e.g., MEO#1) can provide the client with a specific URL for transporting the request. The MEO (associated with the specific URL) for transporting the request can receive the client's request to forward / transport the request to another MEC system.

[0058] As Figure 6As shown in the implementation example in , the left part is a resource tree with new leaves. The new specific URL to be transmitted can be "{apiRoot} / app_pkgm / v1 / transfer_point". The client can send a request to load an application to {apiRoot} / app_pkgm / v1 / transfer_point of MEO#1. The target uniform resource identifier (URI) in the federation and appInformation parameters defined by GSMA OPG can be encapsulated in the body of the request (e.g., based on the POST method).

[0059] In step 2, MEO#1 can receive the request. MEO#1 can identify that the request is a transfer request (e.g., a request to be transferred). MEO#1 can forward / transmit the request (from the client) including at least one message parameter and target system information to the MEC aggregator (MEF) #1.

[0060] In step 3, MEF#1 can forward / transmit the request to MEF#2 (e.g., at the target system) based on the target system information.

[0061] In step 4, MEF#2 can reorganize / re-implement / re-structure the received request and at least one parameter defined by the API, which can be consistent with the defined format / definition / standard (e.g., ETSI MEC definition). If necessary, MEF#2 can prepare to convert the received one-step request into multiple interactions with the MEO (e.g., two-step interaction). MEF#2 can convert the received one-step request into multiple interactions (e.g., two-step interaction). MEF#2 can use at least one parameter to implement / perform multiple interactions with the MEO (e.g., MEO#2).

[0062] As Figure 6 As shown in the implementation example in , MEF#2 can reorganize / re-implement / re-structure at least one parameter to build an application package consistent with the defined format / definition / standard (e.g., ETSI MEC definition). In some embodiments, MEF#2 can encapsulate the request and / or at least one parameter as a zip file.

[0063] The following steps 5-8 can be examples of multiple interactions between MEF#2 and MEO#2 to implement / perform the request to load an application, which is received as described in step 1, for example.

[0064] In step 5, MEF#2 can send a request to MEO#2 to create / establish / configure / assign a new resource for the application package (e.g., load the application package, application loading, load the application package or the application).

[0065] In step 6, MEO#2 may send an HTTP response to MEF#2. The HTTP response may include a "Location" HTTP header that contains / includes the Uniform Resource Identifier (URI) of the created resource.

[0066] In step 7, MEF#2 may send a request to upload the content of the application package to the URI of the resource created on MEO#2.

[0067] In step 8, MEO#2 may send a response to MEF#2.

[0068] In steps 9 - 11, the response may be forwarded / delivered to the client via MEF#1 and MEO#1.

[0069] Implementation Example 2

[0070] To instantiate a MEC application (e.g., application lifecycle management), the present disclosure describes a method of extending a resource Uniform Resource Identifier (URI) and reorganizing requests to be consistent with the format / definition / standard defined on a Multi-Access Edge Orchestrator (MEF) (e.g., the European Telecommunications Standards Institute (ETSI) MEC definition), as Figure 7 shown. The MEO may provide to the client or operate as a transport point interface. In response to a request, the MEF may create a resource. The MEF may implement / perform actions based on the received request, e.g., create / establish a resource for an instance of an application. Steps 1 - 4 may have a prerequisite: a federation has been established or is being established.

[0071] In step 1, a client / client entity / client function may send a request (e.g., an application instantiation request) to a specific Uniform Resource Locator (URL) of a Multi-Access Edge Orchestrator (MEO)#1 to transmit the request (e.g., the transmit-specific URL of MEO#1). The body of the request may include at least one of the following: at least one message parameter or target system information. The target system information may contain / include at least one of the following: an identifier (ID) of the target system (e.g., the target MEC system) or the Internet Protocol (IP) address of the target system (e.g., the target MEC system). In some embodiments, the target MEC system may include MEO#2 and MEF#2. If MEC system - to - system forwarding is required / involved, the MEO (e.g., MEO#1) may provide the client with a specific URL for transmitting the request. The MEO (associated with the specific URL) for transmitting the request may receive the client's request to forward / transmit the request to another MEC system located at / with the transmit-specific URL.

[0072] As Figure 7As shown in the implementation example in, the left part is a resource tree with new leaves. The new specific URL to be transmitted can be "{apiRoot} / app_lcm / v1 / transfer_point". The client can send a request for application instantiation to {apiRoot} / app_lcm / v1 / transfer_point of MEO#1. The union defined by GSMA OPG and the target uniform resource identifier (URI) in at least one request parameter can be encapsulated in the body of the request (associated with the specific URL) for transmitting the request (e.g., based on the POST method).

[0073] In step 2, MEO#1 can receive the request. MEO#1 can identify that the request is a transfer request (e.g., a request to be transferred). MEO#1 can forward / transmit the request (from the client) including at least one message parameter and target system information to the MEC orchestrator (MEF) #1.

[0074] In step 3, MEF#1 can forward / transmit the request to MEF#2 (e.g., at the target system) based on the target system information.

[0075] In step 4, MEF#2 can reorganize / re-implement / re-structure the received request and at least one parameter defined by the API, which can be consistent with the defined format / definition / standard (e.g., ETSI MEC definition). If necessary, MEF#2 can prepare to convert the received one-step request into multiple interactions with the MEO (e.g., two-step interaction). MEF#2 can convert the received one-step request into multiple interactions with the MEO (e.g., MEO#2) (e.g., two-step interaction). MEF#2 can use at least one parameter to implement / perform multiple interactions with the MEO (e.g., MEO#2). As Figure 7 shown in the implementation example in, MEF#2 can reorganize / re-implement / re-structure at least one parameter and can prepare multiple interactions with the MEO (e.g., MEO#2).

[0076] The following steps 5-8 can be examples of multiple interactions between MEF#2 and MEO#2 to implement / perform the request for application instantiation, which is received as described in step 1 for example.

[0077] In step 5, MEF#2 can send a request to MEO#2 to create a resource for the instance of the application.

[0078] In step 6, MEO#2 can send an HTTP response to MEF#2. The HTTP response can include a "Location" HTTP header that contains the uniform resource identifier (URI) of the created resource.

[0079] In step 7, MEF#2 can send a request to the URI of the resource created on MEO#2 to instantiate an instance of the application.

[0080] In step 8, MEO#2 can send an HTTP response to MEF#2. The HTTP response can include a "Location" HTTP header that contains / includes the URI of the newly created "Application Life Cycle Management (LCM) Operation Occurred" resource. The "Application LCM Operation Occurred" resource can correspond to the instantiation operation of the application instance.

[0081] In steps 9 - 11, the response can be forwarded / delivered to the client via MEF#1 and MEO#1.

[0082] It should be understood that one or more features from the above embodiments are not exclusive to a particular embodiment, but can be combined in any way (e.g., in any priority and / or order, simultaneously, or otherwise).

[0083] Figure 8 A flowchart of a method 800 for supporting application package management and / or application life cycle management is shown. Method 800 can be implemented using any one or more of the components and devices described in detail herein Figures 1 to 7 Generally, in some embodiments, method 800 can be performed by a multi - access edge computing orchestrator (MEF). According to an embodiment, additional, fewer, or different operations can be performed in method 800. At least one aspect of the operations relates to a system, method, apparatus, or computer - readable medium.

[0084] A second multi - access edge computing (MEC) orchestrator (MEF) can receive a request including at least one parameter from a first MEF. The second MEF can determine to interact with the multi - access edge coordinator (MEO) associated with the second MEF for resource establishment. The second MEF can use the at least one parameter to interact with the MEO associated with the second MEF. The request can be sent by a client (e.g., a UE or an operation support system (OSS)) to the MEO associated with the first MEF according to the uniform resource locator (URL) of the MEO associated with the first MEF (e.g., the transport - specific URL of MEO#1).

[0085] In some embodiments, the request may further include target system information, which includes at least one of the following: an identifier (ID) of a target MEC system (e.g., MEO#2 and / or MEF#2) or an Internet Protocol (IP) address of the target MEC system. The URL may be provided to the client by the MEO associated with the first MEF. The MEO associated with the first MEF may send a request to the first MEF in response to receiving the request from the client.

[0086] In some embodiments, the request may include a request to load an application. The second MEF may use at least one parameter to generate an application package that conforms to a specific MEC definition (e.g., the European Telecommunications Standards Institute (ETSI) Multi-Access Edge Computing (MEC) definition). The interaction may include requesting the MEO associated with the second MEF to establish resources for loading the application package.

[0087] In some embodiments, the request may include a request to establish an application instance. The interaction may include requesting the MEO associated with the second MEF to establish resources for the application instance.

[0088] In some embodiments, a first Multi-Access Edge Computing (MEC) Aggregator (MEF) may send a request that includes at least one parameter. The second MEF may determine to interact with the Multi-Access Edge Orchestrator (MEO) associated with the second MEF for resource establishment. The second MEF may use at least one parameter to interact with the MEO associated with the second MEF.

[0089] Although various embodiments of the present solution have been described above, it should be understood that they are given by way of example only and not by way of limitation. Similarly, the various figures may depict example architectures or configurations provided to enable those of ordinary skill in the art to understand the exemplary features and functions of the present solution. However, these persons will understand that the present solution is not limited to the example architectures or configurations shown, but can be implemented using a variety of alternative architectures and configurations. Additionally, as will be understood by those of ordinary skill in the art, one or more features of one embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above exemplary embodiments.

[0090] It should also be understood that any reference to elements using names such as "first", "second", etc. generally does not limit the number or order of those elements. Instead, these names are used herein as a convenient means for distinguishing between two or more elements or instances of an element. Thus, the reference to a first and a second element does not imply that only two elements can be employed, or that the first element must be located before the second element in some manner.

[0091] In addition, those of ordinary skill in the art will understand that any of a variety of different technologies can be used to represent information and signals. For example, the data, instructions, commands, information, signals, bits, and symbols that may be referred to in the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0092] Those of ordinary skill in the art will further understand that any of the various illustrative logical blocks, modules, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination of both), firmware, various forms of programs or design code containing instructions (which may be referred to herein, for convenience, as "software" or "software modules"), or any combination of these techniques. To clearly illustrate this interchangeability of hardware, firmware, and software, the various illustrative components, blocks, modules, circuits, and steps have been generally described above in terms of their functionality. Implementing this functionality as hardware, firmware, or software, or a combination of these techniques, depends on the particular application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in various ways for each particular application, but such implementation decisions do not depart from the scope of the present disclosure.

[0093] In addition, those of ordinary skill in the art will understand that the various illustrative logical blocks, modules, devices, components, and circuits described herein can be implemented within or performed by an integrated circuit (IC) including a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, or any combination thereof. The logical blocks, modules, and circuits can further include antennas and / or transceivers to communicate with various components within a network or within a device. The general-purpose processor can be a microprocessor, but alternatively, the processor can be any conventional processor, controller, or state machine. The processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other suitable configuration to perform the functions described herein.

[0094] If implemented in software, the functions can be stored as one or more instructions or codes on a computer-readable medium. Thus, the steps of the methods or algorithms disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media include computer storage media and communication media, and communication media include any medium that can transfer a computer program or code from one place to another. The storage media can be any available medium accessible by a computer. By way of example and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, and any other medium that can be used to store the desired program code in the form of instructions or data structures and can be accessed by a computer.

[0095] As used herein, the term “module” refers to software, firmware, hardware, and any combination of these elements to perform the related functions described herein. Additionally, for purposes of discussion, the various modules are described as discrete modules; however, it will be apparent to those of ordinary skill in the art that two or more modules can be combined to form a single module that performs the related functions according to embodiments of the present solution.

[0096] Additionally, a memory or other storage and communication components can be employed in embodiments of the present solution. It should be understood that, for clarity, the above description has described embodiments of the present solution with reference to different functional units and processors. However, it will be apparent that any suitable functional distribution between different functional units, processing logic elements, or domains can be used without departing from the present solution. For example, functions illustrated as being performed by separate processing logic elements or controllers can be performed by the same processing logic element or controller. Thus, the reference to a particular functional unit is only a reference to a suitable device for providing the described function, and does not indicate a strict logical or physical structure or organization.

[0097] Various modifications to the embodiments described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the scope of the disclosure. Thus, this disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as set forth in the following claims.

Claims

1. A method, comprising: A second Multi-Access Edge Computing Aggregator (MEF) receives a request including at least one parameter from a first MEF; The second MEF determines to interact with a Multi-Access Edge Orchestrator (MEO) associated with the second MEF for resource establishment; and The second MEF uses the at least one parameter to perform the interaction with the MEO associated with the second MEF.

2. The method according to claim 1, wherein, The request is sent by a client to the MEO associated with the first MEF according to the Uniform Resource Locator (URL) of the MEO associated with the first MEF.

3. The method according to claim 1 or 2, wherein, The request further includes target system information, where the target system information includes at least one of the following: an identifier (ID) of a target Multi-Access Edge Computing (MEC) system or an Internet Protocol (IP) address of the target MEC system.

4. The method according to claim 2, wherein, The URL is provided by the MEO associated with the first MEF to the client.

5. The method according to claim 2, wherein, The MEO associated with the first MEF sends the request to the first MEF in response to receiving the request from the client.

6. The method according to claim 1, wherein: The request includes a request to load an application, and The method further includes: The second MEF uses the at least one parameter to generate an application package consistent with a specific Multi-Access Edge Computing (MEC) definition, where the interaction includes requesting the MEO associated with the second MEF to establish resources for loading the application package.

7. The method according to claim 1, wherein: The request includes a request to establish an application instance, and The interaction includes requesting the MEO associated with the second MEF to establish resources for the application instance.

8. A method, comprising: A first Multi-Access Edge Computing Aggregator (MEF) sends a request including at least one parameter to a second MEF, wherein the second MEF determines to interact with a Multi-Access Edge Orchestrator (MEO) associated with the second MEF for resource establishment, and uses the at least one parameter to perform the interaction with the MEO associated with the second MEF.

9. A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 - 8.

10. An apparatus, comprising: At least one processor configured to implement the method according to any one of claims 1 - 8.

Images